Metodología para la elicitación de requerimientos de software

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


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


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


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


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


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


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


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


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


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


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


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.


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.


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.


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.


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


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.


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.


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.


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.


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).

http://buscon.rae.es/draeI/SrvltObtenerHtml?origen=RAE&LEMA=necesitar&SUPIND=0&CAREXT=10000&NEDIC=No

http://buscon.rae.es/draeI/SrvltObtenerHtml?origen=RAE&LEMA=inducir&SUPIND=0&CAREXT=10000&NEDIC=No#0_1


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.


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


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


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.


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.


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)


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.


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.


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


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)


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).


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:


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.


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.


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.


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.


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:


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).


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:


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


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)


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.


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


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


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


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.


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


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


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.


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.


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


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.


41

Figura 9. ISO/IEC 26702. Análisis de requerimientos. Traducción libre. Extraído de (ISO/IEC 26702 IEEE, 2007)


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


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


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.


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.


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.


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.


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.


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


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:


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.


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.


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


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.


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)


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)


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.


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:


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.


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.


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


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.


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.


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.


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)


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.


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


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


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.


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


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


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.


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.


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:


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)


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:


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ó.


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)


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)


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)


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


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.


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


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.


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.


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


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


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.


88

Resumen narrativo de

objetivos Indicadores Medios de verificación Supuestos


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.


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.


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.


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:


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


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:


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.


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.


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).


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á


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?


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.


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.


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


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.


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.


104





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.


105





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.


106





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.


107





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.


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.


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


110

METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL

MARCO LOGICO



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.


111

METODOLOGIA PARA LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE BASADA EN EL

MARCO LOGICO



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.


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.


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.


marco lógico. Actividades de la metodología

Y su estructura se muestra en la figura 28.


113

Figura 28. Metodología para la elicitación de requerimientos de software basada en el marco lógico: Estructura de la metodología.


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.


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:



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).


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).


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


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)


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.


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.


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.


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.


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).


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


Actividad 5.1 Identificar/revisar las acciones.

Actividad 5.2. Elaborar la matriz de acciones.


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).


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.



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).


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


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


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,


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:


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).


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.


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.).


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. √


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.


125


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.


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


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:


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.


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.


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.


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.


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.


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.


134


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.


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


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:


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


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:


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


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.


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:


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


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


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:


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.


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.


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.


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.


marco lógico. Plantilla: PAIGIP. Análisis incorporación grupos involucrados al proyecto


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:


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:


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


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:


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


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:


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


marco lógico. Plantilla: POS. Objetivos del Sistema.


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:


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 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


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:


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 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


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:


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


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:


DECLARACION DEL ALCANCE FIN: <Fin del proyecto> OBJETIVO GENERAL: <Objetivo del proyecto>

No.

OBJETIVOS ESPECIFICOS DEL

SISTEMA REQUERIMIENTOS


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


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


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.


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


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:


PROBLEMA CENTRAL

Efecto 1


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:


PROBLEMA CENTRAL

Causa 1


EAC. Árbol de Causas

Causa 2

Causa 2.1 Causa 2.2

Causa 3

Causa 3.1

Causa 3.1.1


el marco lógico. Esquema: EAC. Árbol de causas


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:


PROBLEMA CENTRAL

Causa 1


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


el marco lógico. Esquema: EAP. Árbol de problemas.


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:


OBJETIVO CENTRAL

Medio 1


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


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:


Medio MedioMedio

AcciónAcción Acción

Acción

Medio


EAA. Árbol de Acciones


el marco lógico. Esquema: EAA. Árbol de Acciones


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:


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


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


Propietarios y usuarios del sistema

Administrador del proyecto


2.

Análisis de involucrados e identificación de participantes en el proyecto.




Propietarios y Administrador del proyecto


3. Identificación y análisis del problema






4. Análisis de Objetivos de mejora del sistema






5. Análisis de Acciones de mejora del sistema.






6. Identificación/revisión de los objetivos del sistema a desarrollar.






7. Identificación/revisión de los requerimientos del sistema.






8. Diseño de la Estructura analítica del proyecto.


Analista de sistemas Administrador

del proyecto Administrador del proyecto

9. Administración de la estructura del proyecto.






marco lógico: Matriz de Roles y responsabilidades en la metodología.


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.


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:


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:



indirectamente con el proyecto en varios niveles.


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.


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


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


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


158


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


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


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




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.


proyecto.


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


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:


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


software basada en el marco lógico. Plantilla: PLP. Listado de Problemas.


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


EFECTOS

PROBLEMA CENTRAL

Decisiones incorrectas basadas en el informe no confiable de facturación

Insatisfacción del cliente


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


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


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


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.


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


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


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


Fallas en el control de actualización de estado

de habitaciones


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.


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


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:


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


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


Correcto control de actualización de estado

de habitaciones


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.


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


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.


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


datos de clientes

Implantar sistema confiable para el registro y control de la

actualización de tarifas de habitaciones en el sistema

ACCIONES


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


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


software basada en el marco lógico. Plantilla: PMA. Matriz de Acciones.


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


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


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.


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.


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


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.


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


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.


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


175


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

-


RNF-03 Portabilidad Descripción El sistema deberá poder ser portable al sistema operativo Microsoft Windows 8. Objetivos asociados - Requerimientos asociados

-



software basada en el marco lógico. Plantilla: PRNFS. Requerimientos no funcionales del sistema


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


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.


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


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


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


C-03. Eliminación habitación



C-04. Consulta habitación


OE-02. Gestionar datos de los clientes del hotel


C-05. Ingreso cliente



178

FIN O META OBJETIVO GENERAL O PROPOSITO

OBJETIVOS ESPECIFICOS DEL SISTEMA

REQUERIMIENTOS FUNCIONALES DELSISTEMA COMPONENTE/ PRODUCTO ACTIVIDADES

C-06. Edición cliente


C-07. Eliminación cliente



C-08. Consulta clientes


OE-03. Gestionar datos de reservas de habitaciones del hotel


C-09. Ingreso reserva


C-10. Edición reserva


C-11. Eliminación reserva


RFS-06. Consulta de información de reservas de habitaciones

C-12. Consulta Reservas



179




OE-04. Gestionar la facturación del servicio de alojamiento


C-13. Ingreso factura


C-14. Edición factura


C-15. Eliminación factura


RFS-08. Consulta de información de facturas servicio alojamiento

C-16. Consulta factura


OE-05. Gestionar el informe de facturación semanal del hotel por

servicios de alojamiento.


C-17. Ingreso Informe


C-18. Edición Informe


C-19. Eliminación Informe



180




RFS-10. Consulta de información de informe de facturación semanal del hotel por servicios de alojamiento.

C-20. Consulta informe


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.


181

Actividad 9. Administración de la estructura del proyecto.


proyecto.


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


SUPUESTOS DE LA ACTIVIDAD

Recursos Costos

1

OE-01. Gestionar

información de

habitaciones del hotel


C-01. Ingreso habitació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







C-03. Eliminación habitación








C-04. Consulta habitación








183

No. OBJETIVOS







Recursos Costos

2

OE-02. Gestionar

datos de los clientes del

hotel


C-05. Ingreso cliente







C-06. Edición cliente







C-07. Eliminación cliente








C-08. Consulta clientes







3

OE-03. Gestionar datos de

reservas de habitaciones

del hotel


C-09. Ingreso reserva








184

No. OBJETIVOS







Recursos Costos

C-10. Edición reserva







C-11. Eliminación reserva







RFS-06. Consulta de información de reservas de habitaciones

C-12. Consulta Reservas







4

OE-04. Gestionar la facturación del servicio

de alojamiento


C-13. Ingreso factura







C-14. Edición factura








185

No. OBJETIVOS







Recursos Costos

C-15. Eliminación factura







RFS-08. Consulta de información de facturas servicio alojamiento

C-16. Consulta factura







5

OE-05. Gestionar el informe de facturación semanal del

hotel por servicios de alojamiento.


C-17. Ingreso Informe







C-18. Edición Informe







C-19. Eliminación Informe








186

No. OBJETIVOS







Recursos Costos

RFS-10. Consulta de información de informe de facturación semanal del hotel por servicios de alojamiento.

C-20. Consulta informe







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


187


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.


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 √


software basada en el marco lógico. Plantilla: PRMAEP. Revisión Matriz de Administración de la estructura del proyecto.


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


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


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.


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:


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 √ √ √


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


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.


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.


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


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


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.


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.


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.


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:


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.


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.


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.

http://www.processimpact.com/goodies.shtml.%20Consultado%20el%2009/09/2009

http://www.processimpact.com/goodies.shtml.%20Consultado%20el%2009/09/2009

http://www.sei.cmu.edu/reports/92tr012.pdf


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.

http://webs.montevideo.com.uy/nicolasd.%20Cosultado%20el%2009/09/2009

http://webs.montevideo.com.uy/nicolasd.%20Cosultado%20el%2009/09/2009

http://buscon.rae.es/draeI/

http://www.dsi.uclm.es/asignaturas/42541/pdf/metodologia_elicitacion.pdf

http://www.dsi.uclm.es/asignaturas/42541/pdf/metodologia_elicitacion.pdf


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

http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER09/hadad.pdf

http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER09/hadad.pdf


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.


(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.


(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.

http://www.extension.uner.edu.ar/sites/default/files/manual%2042%20ILPES%20MML.pdf

http://www.extension.uner.edu.ar/sites/default/files/manual%2042%20ILPES%20MML.pdf

http://www.ts.mah.se/RUP/RationalUnifiedProcess

http://www.clab.edc.uoc.gr/application/requirements_engineering.pdf

http://www.sei.cmu.edu/reports/10tr033.pdf


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)

http://blog.standishgroup.com/

http://blog.standishgroup.com/


209

ANEXOS


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. _____________________________________________________________________


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. _____________________________________________________________________


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

________________________________________________________________________________________________________________________________________________________


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__


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.


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.


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í.


Rta Si se diseñó un esquema que visualiza las 9 actividades centrales de la metodología propuesta y su ciclo de desarrollo debidamente diagramado.


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.


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.


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.


Rta Si, cada actividad planteada define y describe las técnicas a utilizar para su desarrollo.


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.


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.


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.


de cambios? Rta Si pero como una casilla, podría crearse dentro del código nomenclador.


Rta No, ya que solo se habla de analista de sistemas, pero no se identificó dentro del ciclo otros roles.


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.




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.


del proyecto?

Rta Si, y de forma clara. 20. ¿Ayuda la metodología a identificar los problemas de los involucrados?

Rta Si,


215


relacionados con éste? Rta Si, y aporta información en cuanto al rol que desempeñan.


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.


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.


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.


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.


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.


Rta Si, y lo mejor es que tomaron el modelo de marco lógico para apoyar este proceso.


216

III. ANALISIS DE LA METODOLOGIA CON RESPECTO A LOS USUARIOS DE LA METODOLOGIA


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


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__



Rta. El objetivo es muy claro


componen la metodología? Rta La descripción es bastante clara.


elicitación de requerimientos de software? Rta Si. Las actividades presentan coherencia con el objetivo de la metodología


Rta Si.


Rta Si, la ejecución de cada una permite continuar de manera lógica y coherente con la siguiente.


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


Rta Totalmente


Rta Si, es muy claro


Rta Debería ampliarse la descripción de las mismas.


metodología?


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


Rta Si


de cambios? Rta Si


Rta Si


Rta Si

II. ANALISIS DE LA METODOLOGIA CON RESPECTO A LA ELICITACION DE REQUERIMIENTOS DE SOFTWARE


Rta Si. De una forma muy clara

18. ¿Ayuda la metodología a identificar, analizar, clasificar a los involucrados en el problema?

Rta Si


del proyecto?

Rta Si 20. ¿Ayuda la metodología a identificar los problemas de los involucrados?

Rta Si


relacionados con éste? Rta SI


a desarrollar? Rta Si


sistema de software a desarrollar?


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


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


para el logro de los objetivos y cumplimiento de los requerimientos? Rta Si


Rta Si


cumplimiento de los objetivos y requerimientos del sistema de software a desarrollar? Rta Si


Rta Si

III. ANALISIS DE LA METODOLOGIA CON RESPECTO A LOS USUARIOS DE LA

METODOLOGIA


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.


220


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


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__



Rta _Si, es claro el planteamiento


componen la metodología? Rta Si, son claras y bien descritas


elicitación de requerimientos de software? Rta Si, son coherentes


Rta Si, se presenta un esquema claro


Rta. Si, según otras metodologías existentes, ésta posee un proceso ordenado


Rta. Si…

7. ¿En cada actividad se obtiene un producto que apoye el proceso de la elicitación de requerimientos de software? Rta. Si


Rta. Si son coherentes…


Rta. Si, dentro del esquema y de manera textual


Rta. Si


metodología? Rta. Si, están acordes


222

12. ¿Se indica en que actividad emplear cada herramienta (esquemas y plantillas)? Rta. Si, se indica


Rta. Si


de cambios? Rta. Si


Rta. Si


Rta. SI




Rta. Claro que si 18. ¿Ayuda la metodología a identificar, analizar, clasificar a los involucrados en el problema?

Rta. Si, de manera adecuada


del proyecto?

Rta. Si, cada Stakeholder 20. ¿Ayuda la metodología a identificar los problemas de los involucrados?

Rta. Si.


relacionados con éste? Rta. Si


a desarrollar? Rta. Si, además codifica cada uno de ellos


sistema de software a desarrollar? Rta. Si los identifica/revisa


223

24. ¿Los requerimientos identificados están relacionados con el fin, objetivo general y específicos del sistema a desarrollar? Rta. Si..


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…..)


para el logro de los objetivos y cumplimiento de los requerimientos? Rta. Si..


Rta. Si


cumplimiento de los objetivos y requerimientos del sistema de software a desarrollar? Rta. Si


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


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

Documents

Metodología para la elicitación de requerimientos de software