core.ac.uk · Estudio empírico sobre el proceso y la productividad de la ingeniería de requisitos en las empresas antioqueñas de software 2 UNIVERSIDAD EAFIT ESCUELA DE

UNIVERSIDAD EAFIT

DEPARTAMENTO DE INFORMÁTICA

MAESTRÍA EN INGENIERÍA

ESTUDIO EMPÍRICO SOBRE EL PROCESO Y LA PRODUCTIVIDAD DE LA

INGENIERÍA DE REQUISITOS EN LAS EMPRESAS ANTIOQUEÑAS DE

SOFTWARE

2013

LUZ JANETTE VÉLEZ MEJÍA

Marzo de 2014

Estudio empírico sobre el proceso y la productividad de la ingeniería de requisitos en las empresas

antioqueñas de software

2

UNIVERSIDAD EAFIT

ESCUELA DE INGENIERÍA




SOFTWARE

Trabajo de Investigación dirigido a optar

el título de Magister en Ingeniería

Asesor

Doctor

Alberto Antonio Restrepo Velásquez

Escuela de Ingeniería Universidad Eafit

Medellín, Marzo de 2014



3

Dedicatoria

A mi familia motor de mi vida



4

AGRADECIMIENTOS

Doy gracias a Dios por brindarme posibilidades tan impensables en mi vida como esta y

por rodearme a lo largo del camino de familia y amigos.

Agradezco inmensamente además a mi asesor por acompañarme en el proceso

entregándome no solo sus capacidades académicas, sino además por compartir su

conocimiento y experiencia que me abrieron y abonaron el camino posibilitando alcanzar

este objetivo.

Y doy gracias muy especialmente a todas las personas amigos y colegas de las

organizaciones que participaron en este estudio, quienes depositaron su confianza

suministrando información de sus empresas y atreviéndose a relatar sus sueños y

expectativas en un tema tan importante para las organizaciones como es el proceso de

desarrollo software, esperando lograr con este estudio mejoras en el proceso.



5

RESUMEN

Este estudio tiene como finalidad, encontrar las mejores prácticas, retos y desafíos que

enfrentan las empresas que desarrollan productos de software a medida en el departamento

de Antioquia - Colombia, considerando específicamente del proceso de desarrollo software

la Ingeniería de Requisitos. La base de esta investigación fue un estudio realizado en Brasil

[1]. Sin embargo el presente estudio se investiga el desarrollo de Software a medida en

aspectos como la metodología utilizada, las herramientas de apoyo, el proceso como tal y

las mejores prácticas y fue realizado sobre doce (12) empresas a nivel regional. Entre las

principales conclusiones del estudio se puede destacar: 1) Se requiere que durante la IR se

logre mayor conocimiento del negocio y se ofrezcan soluciones que orienten al cliente y le

generen valor, sin esperar que sea necesariamente este quien las encuentre. 2) La IR

requiere de una documentación clara, corta y entendible para todo el equipo de desarrollo.

3) Se deben establecer procesos que permitan gestionar los cambios y estos deben ser claros

para los desarrolladores y conocidos por el cliente.

Palabras claves: Ingeniería de Requisitos, elicitación, mejores prácticas, desafíos, retos,

negocio, documentación y gestión del cambio

ABSTRACT

Abstract: This study aims to find the best practices and challenges that the Antioquia-

Colombia’s enterprises who sell tailor made software have to face, considering specifically

the IR development process. This document is a replica of a study that was made in Brazil.

This study analyzes some aspects such as the methodology, the support tools, the process

and best practices. And it was realized about twelve (12) regional enterprises. The principal

conclusions are: 1) It´s necessary to get during the IR the best business knowledge and it´s

also necessary to offer solutions that mean some value. 2) The Requirements Engineering

needs a clear documentation and understandable for all development group. 3) It´s

necessary make enabled process to the change management.

Key words: Requirements engineering, elicitation, challenges, business, documentation and

Change management.



6

Nota de aceptación

----------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------

Asesor:

------------------------------------------------

----------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------

Jurado 1:

------------------------------------------------



7

Contenido

Contenido

AGRADECIMIENTOS ......................................................................................................... 4

RESUMEN ............................................................................................................................. 5

ABSTRACT ........................................................................................................................... 5

Contenido ............................................................................................................................... 7

LISTA DE TABLAS............................................................................................................ 10

LISTA DE FIGURAS .......................................................................................................... 11

LISTA DE GRÁFICAS ....................................................................................................... 12

1. CAPITULO INTRODUCCIÓN................................................................................... 13

1.1. Motivaciones ......................................................................................................... 13

1.2. Alcance de la Tesis ................................................................................................ 14

1.3. Contribuciones ....................................................................................................... 16

2. CAPÍTULO INGENIERÍA DE SOFTWARE ............................................................ 20

2.1. Definición del ámbito ............................................................................................ 20

2.2. Enfoque de tecnología multicapa .......................................................................... 21

2.3. Fases de ingeniería de software ............................................................................. 24

2.4. Descripción general de Ingeniería de Requisitos .................................................. 28

2.4.1 Definiciones de requisitos. ............................................................................. 29

2.4.2 Elicitación de Requisitos ................................................................................ 32

2.4.3 Técnicas de elicitación de requisitos .............................................................. 33

2.4.4 Los requisitos del negocio. ............................................................................. 36

2.4.5 Los casos de uso o escenarios: ....................................................................... 36

2.4.6 Las reglas de negocio. .................................................................................... 37

2.4.7 Requisitos funcionales. .................................................................................. 37

2.4.8 Atributos de calidad. ...................................................................................... 37

2.4.9 Requisitos de interfaz externos. ..................................................................... 37

2.4.10 Restricciones. ................................................................................................. 37

2.4.11 Las definiciones de datos. .............................................................................. 38

2.4.12 Ideas solución. ................................................................................................ 38

2.4.13 Algunas precauciones Acerca de la Elicitación ............................................. 38



8

2.5. Una visión general de Experimentación en Ingeniería de Software [22] .............. 41

2.5.1. Aportes del software experimental................................................................. 41

2.5.2. Definición de software experimental: ............................................................ 42

2.5.3. Fines de la experimentación: .......................................................................... 42

2.5.4. Paradigma utilizado en experimentación ....................................................... 43

2.6. Definición del experimento ................................................................................... 44

2.7. Planificación del experimento ............................................................................... 45

2.8. Realización del experimento ................................................................................. 46

2.9. Interpretación del experimento .............................................................................. 46

2.10. Final ................................................................................................................... 46

3. CAPÍTULO IMPACTO DE LA INGENIERÍA DE REQUISITOS DE SOFTWARE

DESARROLLO DE PRODUCTOS .................................................................................... 48

3.1. Realidades acerca de la ingeniería de requisitos de software ................................ 49

3.2. El Triage ................................................................................................................ 55

3.3. Las necesidades de los actores: ............................................................................. 56

3.4. La definición y Gestión de Requisitos: ................................................................. 58

3.5. Consideraciones Finales: ....................................................................................... 59

4. CAPÍTULO PARADIGMA CUALITATIVO ............................................................. 61

4.1. Resumen del Método de Investigación.................................................................. 61

4.2. Paradigma cuantitativo .......................................................................................... 62

4.3. Paradigma cualitativo ............................................................................................ 62

4.4. Formulación del problema ..................................................................................... 66

4.5. Técnicas de recolección de datos .......................................................................... 66

4.5.1. Encuestas ........................................................................................................ 66

4.5.2. Entrevista Semi-Estructurada ......................................................................... 68

4.5.3. Grupo de Discusión ........................................................................................ 70

4.5.4. Observación y Etnográfica ............................................................................. 72

4.5.5. Pre-Testing ..................................................................................................... 73

4.5.6. Recopilación de datos .................................................................................... 73

4.5.7. Datos de transcripción .................................................................................... 74

4.5.8. Análisis e Interpretación de los Datos ............................................................ 75

4.5.9. Teoría de Códigos .......................................................................................... 75



9

4.5.10. Codificación temática ................................................................................. 77

4.5.11. Análisis cualitativo de contenido................................................................ 78

Se citan a continuación una serie de pasos para el análisis cualitativo. Donde ................... 79

4.6. Comparación de las características principales del método Cualitativa y

Cuantitativa ...................................................................................................................... 80

4.7. Final ....................................................................................................................... 83

5. CAPÍTULO PRESENTACIÓN DEL ESTUDIO EMPÍRICO ................................... 84

5.1. Definición del Estudio ........................................................................................... 84

5.2. Planteamiento del Estudio: ................................................................................. 105

5.3. Finalización del Estudio ...................................................................................... 110

5.4. Observaciones finales .......................................................................................... 113

6. CAPITULO RESULTADOS DEL ESTUDIO EMPÍRICO ...................................... 115

6.1. Interpretación del Estudio.................................................................................... 115

6.2. Resultados............................................................................................................ 116

6.2.1. Caracterización de las Organizaciones......................................................... 117

6.2.2. Caracterización de los Empleados Adscritos a la Organización ................. 119

6.2.3. Caracterización de los clientes de las organizaciones .................................. 125

6.2.4. Caracterización del Proceso de Desarrollo en la Organización ................... 133

6.3. Algunos aspectos a mejorar en Ingeniería de Requisitos: ................................... 164

7. CAPÍTULO CONCLUSIONES, TRABAJOS FUTUROS, MEJORES PRÁCTICAS

167

7.1. Conclusiones........................................................................................................ 167

7.2. Estudios futuros: .................................................................................................. 171

7.3. Buenas Prácticas: ................................................................................................. 171

8. Apéndice A Encuesta sobre la Caracterización de Las Empresas que Desarrollan

Productos Software en Antioquia Colombia. ..................................................................... 173

9. Apéndice B Entrevista sobre la Caracterización del proceso de Desarrollo Software y

la Ingeniería de Requisitos en las Empresas que Desarrollan Productos Software en

Antioquia Colombia. .......................................................................................................... 182

BIBLIOGRAFÍA................................................................................................................ 187



10

LISTA DE TABLAS

Tabla 1. Sample CRUDL matriz for the chemical tracking system. (Tomada de 10-

1SW_Requirements_Ch7).................................................................................................... 39

Tabla 2. Escopos Empiricos. Tomada de [per] en [11]. ..................................................... 45

Tabla 3. Caracterización de las Empresas ......................................................................... 118

Tabla 4. Nivel de inglés entre los empleados adscritos al proceso de desarrollo software120

Tabla 5. Certificaciones .................................................................................................... 124

Tabla 6. Criterios de clasificación de clientes. .................................................................. 127

Tabla 7. Insatisfacción de los clientes en el proceso de desarrollo software .................... 129

Tabla 8. Relación de roles presentes en las organizaciones .............................................. 134

Tabla 9. Lenguajes de desarrollo software utilizados por las organizaciones .................. 136

Tabla 10. El Cómo del Proceso de Ingeniería de Requisitos. ........................................... 142

Tabla 11. Metas futuras para el proceso............................................................................ 145

Tabla 12. Buenas prácticas de Ingeniería de Requisitos para clientes que ocultan

información ........................................................................................................................ 146

Tabla 13. Buenas prácticas de Ingeniería de Requisitos para clientes que desconocen sus

necesidades ......................................................................................................................... 147

Tabla 14. Estrategias para involucrar al cliente en el proceso .......................................... 155

Tabla 15. Técnicas de priorización ................................................................................... 157

Tabla 16. Estrategias para realizar gestión de cambio de requisitos .................................. 158

Tabla 17. Propiedades deseables de los requisitos ............................................................ 159

Tabla 18. Técnicas y criterios de validación de datos ....................................................... 161

Tabla 19. Estrategias de gestión de requisitos. ................................................................. 164

Tabla 20. Estrategias de versionamientos de requisitos .................................................... 165

Tabla 21. Proyectos con mayor destreza en ingeniería de requisitos ................................ 165



11

LISTA DE FIGURAS

Figura 1. Capas de la Ingeniería de Software Tomado de Pressman, R, Ingeniería del

Software: Un enfoque práctico, McGraw Hill 1997. .......................................................... 21

Figura 2. Proceso de Desarrollo Software............................................................................ 22

Figura 3. Ciclos de Vida del Desarrollo Software ............................................................... 24

Figura 4. Guía del Conocimiento de la Ingeniería Software Swebook ............................... 24

Figura 5. Fases Preestablecidas en el Proceso de Desarrollo Software .............................. 26

Figura 6. Software. Adaptado de Synerplus........................................................................ 27

Figura 7. Actividades Básicas del Proceso de Desarrollo Software ................................... 28

Figura 8. Objetivos esperados por los actores de la Ingeniería de Requisitos ................... 29

Figura 9. Visión de Ingeniería de Requisitos ...................................................................... 30

Figura 10. Plan de Ingeniería de Requisitos........................................................................ 32

Figura 11. Classifying the voice of the customer (Tomada de 10-1SW_Requirements_Ch7)

.............................................................................................................................................. 36

Figura 12. El proceso de ingeniería de Requisitos tal vez terminó. (Basada en 10-

1SW_Requirements_Ch7).................................................................................................... 40

Figura 13. Some typical software Project stakeholders (Tomada de 1-cosmictruths.pdf).. 52

Figura 14. Visión de conjunto en el triage de los requisitos. Adaptado de (5-Notes on The

Art of Requirements Triage by Alan M Davis) ................................................................... 56

Figura 15. Contenidos del Plan de Elicitación. Adaptado de (10-1SW_Requirements_Ch7) .............................................................................................................................................. 57

Figura 16. Pautas para una Buena Administración de los Requisitos Adaptado de

(RM_WP_TenStepsToBetterRM.pdf) ................................................................................. 59

Figura 17. Paradigma de Investigación ............................................................................... 63

Figura 18. Una visión general del proceso de investigación cualitativa .............................. 65

Figura 19. Encuesta ............................................................................................................. 68

Figura 20. Tipos de Entrevista semi-estructurada. Adaptada de [2] en [36]....................... 70

Figura 21. Entrevista Semi-estructurada. ............................................................................. 70

Figura 22. Pasos para el Análisis Cualitativo...................................................................... 79

Figura 23. Fases de los Enfoques Cualitativo y cuantitativo .............................................. 81

Figura 24. Características de los Métodos Cualitativo y Cuantitativo ................................ 82

Figura 25. Comparativo entre los modelos cuantitativo y cualitativo. ............................... 82

Figura 26. Requisitos de Ingeniería. Basada en When Telepathy Won’t Do: Requirements

Engineering Key Practices1 ............................................................................................... 100

Figura 27. Actividades Realizadas durante la especificación del estudio ......................... 110

Figura 28. Actividades de Validación y Control de las herramientas de investigación .... 112

Figura 29. Subdisciplinas de Ingeniería de Requisitos. Tomado de Ian Sommerville y

Sawyer Pete, Ingeniería de Requerimientos: Una Guía de Buenas Prácticas (Wiley, 1997).

............................................................................................................................................ 140

Figura 30. Requisitos de Software .................................................................................... 141

Figura 31. Mejoras sugeridas en la documentación ........................................................... 150

Figura 32. Mejoras sugeridas en la elicitación de los requisitos. ...................................... 151



12

LISTA DE GRÁFICAS

Gráfica 1. Dominio de inglés entre los empleados adscritos al proceso de desarrollo

software .............................................................................................................................. 121

Gráfica 2. Experiencia laboral........................................................................................... 122

Gráfica 3. Tiempo de Vinculación de los Empleados con la misma Organización .......... 123

Gráfica 4. Ubicación de los clientes .................................................................................. 126

Gráfica 5. Desarrollos Contratados ................................................................................... 127

Gráfica 6. Porcentaje de clientes que atienden las organizaciones del estudio ................. 128

Gráfica 7. Herramientas de Gestión del Cliente................................................................ 131

Gráfica 8. Estrategias para captar nuevos clientes ............................................................ 132

Gráfica 9. Estrategias para Captar Nuevos Clientes ......................................................... 135

Gráfica 10. Metodologías de desarrollo utilizadas por la organización ............................ 136

Gráfica 11. Metodologías de Apoyo a la Ingeniería de Requisitos................................... 145

Gráfica 12. Resumen de resultados mejoras en Ingeniería de Requisitos.......................... 154

Gráfica 13. Apoyo del proceso de Ingeniería de Requisitos a los proyectos de desarrollo

............................................................................................................................................ 155

Gráfica 14. Propiedades deseables de los requisitos ......................................................... 160

Gráfica 15. Herramienta más utilizada por las organizaciones en Ingeniería de Requisitos

............................................................................................................................................ 162



13

1. CAPITULO INTRODUCCIÓN

1.1. Motivaciones

En este capítulo se analizará las motivaciones, que llevaron a la elaboración de este trabajo

de investigación, así como el alcance, las contribuciones y la estructura para su elaboración.

A través de los diferentes experiencias ha quedado demostrada la importancia que tiene

para el desarrollo de software con calidad, la Ingeniería de Requisitos (IR) [3], además,

estudios como los de Standish Group International y Chaos Report [4] reportan para el año

2011, que el 42% de los proyectos de software deben ser mejorados y el 21% fracasaron

debido a causas como: requisitos incompletos (13,1%) y requisitos cambiantes (8,7%). Por

su parte, el Software Engineering Institute afirma que el 40% de los proyectos requieren

sobreesfuerzo para reparar defectos causados por la mala calidad de los requisitos y el 60%

de estos se deben a la ineficiente implementación de los requisitos en los procesos. En este

sentido, el estudio realizado por National Institute of Standards and Technology, muestra

que el 42% de los proyectos cambian debido a los requisitos, afirmación que complementa

las ya mencionada The Standish Group.y Chaos Report, al sostener que en los procesos

solo se implementa el 54% de los requisitos originales y el 55% de los requisitos no son

usados por los usuarios o clientes [4], por lo tanto aproximadamente el 60-70% de los

fracasos ocurridos en los proyectos de desarrollo de software se deben a las insuficiencias

de la elicitación, gestión y análisis de requisitos.

Apoyando lo anterior, son los estudios empíricos uno de los mecanismos que permite

obtener evidencias del estado de la práctica de la ingeniería de software con el propósito de

identificar brechas entre la práctica y la teoría. El presente artículo, muestra los resultados

de replicación de “Un estudio empírico sobre IR de Empresas Productos de software”

realizado en Pernambuco Brasil [1]. Aplicado en Antioquia-Colombia y que tiene como

motivación presentar un conjunto de prácticas actualmente realizadas por la industria del

desarrollo software, en materia de IR y que son llevadas a cabo por las organizaciones que

desarrollan software a medida con el fin de apalancar la calidad, brindando soluciones

tendientes a satisfacer las necesidades y expectativas de los clientes en los diferentes

contextos de uso. [5], [6], [7].

Con este estudio entonces se genera la posibilidad de conocer el estado de la IR hoy en las

organizaciones de software a medida, develando las mejores prácticas, experiencias y

procesos de apoyo a las actividades. Respecto a la pertinencia esta se da considerando la

concentración que tiene la industria de software en el departamento de Antioquia y que este

se ubica en segundo lugar a nivel de economía del país tras la capital que es Bogotá.

En este sentido está también el estudio WEST realizado en Medellín-Colombia y quien

incluyó ésta dentro de sus tareas generar un trabajo investigativo donde se demostró la



14

necesidad de implementar una nueva metodología de Ingeniería de Requisitos en la

industria. (IDEAS 2004). [2]

Se destaca entonces, que desde los diferentes estudios y experiencias revierte gran

importancia el proceso de Ingeniería de Requisitos para lograr productos software de

calidad y las implicaciones en sobrecostos, demoras e insatisfacción del cliente, que

generan las malas prácticas, en este sentido. Se conoce la incidencia en la calidad del

producto que tiene la Ingeniería de Requisitos, de acuerdo con su objetivo principal al crear

productos software que es “crear soluciones que satisfagan las necesidades y expectativas

de los clientes en diferentes contextos de uso, lo que redunda en calidad del producto

software”. [5].

Lo anterior sin olvidar el hecho de que para que un producto de software cumpla con

expectativas tales como ser innovador, tener acceso web, entre otros, primero debe ser

atrayente y claro con el fin de que los clientes lo usen y así proporcionar beneficios más

allá de la tecnología, además el producto software debe lograr valor por encima de entregar

nuevas funcionalidades y este valor debe aportar para la organización mejoras en la calidad

de sus productos y una reducción en costos.

En consecuencia, basados en el hecho de que los requisitos de software expresan las

necesidades y limitaciones que debería soportar el producto software y que este debe

contribuir a la satisfacción de necesidades reales con usuarios reales, dicha aplicación debe

generar requisitos que encuentren la oportunidad de apoyar el negocio generando valor

como es el caso de un nuevo mercado por ejemplo [6]

Se puede afirmar en consecuencia que, cuando se habla de definir los atributos de calidad

se hace alusión de inmediato al cumplimiento de las necesidades del cliente, necesidades

estas expresadas en los requisitos funcionales, sin embargo [7] hace comenta que la

participación del cliente no es suficiente cuando esta, no está adecuadamente enfocada a

declarar las expectativas de eficiencia y otros atributos no funcionales de los usuarios

referente al sistema, pese a que sus necesidades funcionales sean resueltas es necesario

entender cómo funciona el sistema y cómo llevará a cabo sus funciones para lograr la

satisfacción.

Todo lo anterior nos lleva a pensar en que el fracaso del lanzamiento del producto software

se produce debido a que este no cumple con la satisfacción de las necesidades de los

clientes, este aspecto es el que se conoce dentro del proceso de desarrollo software como el

objetivo de la ingeniería de requisitos. En este contexto este estudio genera la posibilidad

de conocer el estado de la ingeniería de requisitos hoy en las empresas que desarrollan

productos software además de las mejores prácticas, experiencias y procesos de apoyo a las

actividades, todo en el contexto del software a medida.

1.2. Alcance de la Tesis



15

En este contexto y tomando como fuente de motivación las expectativas y necesidades en la

calidad y satisfacción del software presentadas en el medio, además basados en la tarea

efectuada por el proyecto WEST [2] “Aplicación de una metodología de Ingeniería de

Requisitos a un caso real” y apoyados por la los lineamientos adoptados por el estudio

realizado en Pernambuco, Brasil [1] “Um Estudo Empírico sobre Engenharia de Requisitos

em empresas de Productos de Software”, este trabajo se propone realizar investigaciones

empíricas con las empresas que desarrollan productos software a medida en el

departamento Antioquia - Colombia.

En este sentido, el objetivo de este estudio es investigar las principales prácticas retos y

desafíos que enfrentan las organizaciones en el proceso de desarrollo software,

específicamente durante la Ingeniería de Requisitos.

Dado que no hay información específica del tema en el contexto, esta investigación es de

naturaleza exploratoria, tiene el propósito de conocer el fenómeno, realizar la consiste

búsqueda del conocimiento refinado sobre cuestiones particulares y el contexto en el que

existen; empleando los enfoques cualitativo y cuantitativo que serían los más adecuados

para este estudio, el uso de ellos simultáneamente se derivó de que en algunos casos la

información recogida se centró en la cuantificación de la información cualitativa.[48]

En la elección de la región también se tuvo en cuenta, en el miramiento del hecho que, los

desafíos generados por la globalización han incrementado las brechas existentes entre los

países desarrollados y los llamados emergentes, lo que lleva a identificar a la tecnología

como la principal herramienta de transformación productiva, condición fundamental para

alcanzar y mantener la competitividad de un país. Muestra de ello es el resurgir de países

emergentes como India, Irlanda, Israel, Brasil y China, que han ingresado a las nuevas

tecnologías y se han consolidado con éxito en un mercado tecnológico tan competitivo

como el de Software, aprovechando el dinamismo y la juventud del sector, y haciendo uso

efectivo de sus capacidades de innovación para aprovechar las ventajas comparativas. [8].

En este sentido, la muestra analizada es Antioquia, un departamento colombiano con alta

presencia emprendedora y donde existen notables esfuerzos por desarrollar una industria

del software competitiva internacionalmente y que cumple con preceptos como los de

Torrisi en 1988 donde escribe: “la producción de software, más que cualquier otra actividad

industrial, debe suponer por definición una actividad de innovación porque aspira a

producir nuevos productos o nuevas maneras de ejecutar las tareas y funciones conocidas”.

Basado en lo anterior, la producción de software implica innovación en cada uno de sus

eslabones de la cadena de valor, por lo que el aprendizaje tecnológico y la integración de

todos los actores y agentes en un sistema son requisitos esenciales para construir, fortalecer

y acumular las capacidades de innovación en la industria. En ese sentido Antioquia, se ha

destacado por el enorme esfuerzo que ha emprendido para el fortalecimiento y la

integración empresarial, sobresaliendo en competitividad sobre otras regiones del país,

logrando una exitosa internacionalización y cohesionando de los esfuerzos de actores

privados, gremiales, empresariales, científicos, financieros, del gobierno y del sector



16

educativo, además, desde una perspectiva local, Antioquia lidera iniciativas que promueven

el desarrollo de su industria SSA, articulando las acciones de los actores, las instituciones y

el potencial económico local, además existen pequeñas y medianas empresas antioqueñas

que son altamente exitosas y cuentan con abundante conocimiento acumulado gracias a sus

fuertes trayectorias tecnológicas, el software antioqueño también, dadas las potencialidades

que ofrece para alcanzar el catch-up tecnológico se ha convertido en estrategia de

desarrollo y hace parte de las agendas económicas de los países como motor de crecimiento

[8] [49].

Es importante citar que a nivel mundial las pequeñas empresas de desarrollo software con

menos de cincuenta (50) empleados, son fundamentales para el crecimiento de economías

como las de Brasil, Canadá, China, India, Finlandia, Irlanda, Hungría, entre otras, sin

embargo, al persistir y crecer, las empresas de software pequeñas necesitan soluciones de

ingeniería de software eficientes y eficaces para sostenerse en el mercado. En este sentido,

se suele creer que las buenas prácticas y soluciones consumen tiempo y están dirigidas a

apalancar las grandes organizaciones, por lo tanto en todo el mundo se presenta un

porcentaje de pequeña organizaciones que requieren de un proceso de desarrollo software

adecuado y del aporte de mejores prácticas para el desarrollo de software con calidad. [8].

1.3. Contribuciones

Esta tesis presenta las siguientes contribuciones generales:

o Estudiar los aspectos relacionados con la Ingeniería del Software.

o Presentar conceptos básicos del tema experimentación en Ingeniería de Software.

o Dar a conocer las necesidades de los actores que intervienen en el proceso de

desarrollo software.

o Caracterizar los conceptos básicos, los temas y actividades en relación con la

ingeniería de requisitos para los productos de software.

o Mostrar las diferentes etapas del proceso de Ingeniería de Requisitos y los objetivos

que deben alcanzar en el proceso de desarrollo del producto software.

o Dar a conocer el impacto de la Ingeniería de Requisitos de software desarrollo de

productos software en la región.

o Proporcionar una visión general del método de investigación para apoyar

realización del estudio empírico

o Estudiar y presentar los conceptos básicos del paradigma cualitativo

o Mostrar elementos comparativos de los métodos cualitativo y cuantitativo de datos.

o Formular un problema acorde con las necesidades del entorno

o Formular hipótesis entorno al estado actual de la Ingeniería de Requisitos.

o Caracterización de las empresas que desarrollan software en el medio

o Estudiar y caracterizar los conceptos básicos, las cuestiones y actividades relativas a

los requisitos de ingeniería para los productos de software

o Definir la gestión de Requisitos

o Comentar realidades acerca de la Ingeniería de Requisitos



17

o Generar la posibilidad de conocer el estado actual de la Ingeniería de Requisitos hoy

en las empresas que desarrollan productos software además de las mejores prácticas,

experiencias y procesos de apoyo a las actividades del software a medida.

o Llevar a cabo un estudio empírico sobre las pequeñas y medianas empresas que

desarrollan productos software a la medida en Antioquia, para investigar las

prácticas y retos que enfrentan en el proceso de desarrollo específicamente en la

etapa de Ingeniería de Requisitos.

o Analizar los resultados de este estudio de acuerdo con los aspectos de relevancia en

el medio como mejores prácticas y experiencias en la Ingeniería de Requisitos.

o Resultados del estado actual de la Ingeniería de Requisitos en las empresas

antioqueñas de software.

o Contrastar la realidad con lo esperado de la Ingeniería de Requisitos.

o Diferenciar la visión del cliente y del desarrollador en ingeniería de requisitos.

Además del capítulo de introducción, esta obra presenta nueve capítulos en los que se

analizan aspectos que llevan a generar las conclusiones finales del estudio así:

Capítulo 2 - Ingeniería de Software

En este capítulo se presentará una introducción sobre Ingeniería de Software, algunas

definiciones, enfoques como el multicapa, el ciclo de vida y las fases que constituyen el

proceso. Posteriormente, se define la Ingeniería de Requisitos con sus fases, objetivos se

hace un recuento de las actividades técnicas y prácticas utilizadas durante el proceso y se

dan a conocer sus fines. Por último, se muestra una perspectiva de Experimentación en

Ingeniería de Software, su definición y sus fases proceso.

Capítulo 3 - Impacto de la ingeniería de requisitos de software desarrollo de

productos

Este capítulo presenta el impacto generado por la Ingeniería de Requisitos en el proceso de

desarrollo de software personalizado, para ello se abordaron algunas realidades del proceso

tales como: Si no se logran los requisitos correctos, no va importar que tan bien se ejecute

el resto del proyecto, los requisitos de desarrollo son un descubrimiento y no solamente

una colección de procesos, el cambio sucede, todos los interesados del proceso intervienen

en los requisitos, la participación de los clientes es el factor más crítico a la calidad del

software, el cliente no siempre tiene la razón pero siempre tiene un punto, la primera

pregunta que un analista debe hacerse frente a un nuevo requisito propuesto es: "¿está este

requisito en el alcance?, incluso el mejor documento sobre las necesidades no puede y no

debe reemplazar el diálogo humano, los requisitos pueden ser vagos pero el producto será

específico, no utilice la incertidumbre como una excusa para la falta de precisión. Y para

finalizar el capítulo presenta como tema el triage, donde se muestran algunos factores

importantes a tener en cuenta al realizar el primer acercamiento con la ingeniería de

requisitos de un proyecto y se generan ejemplos de justificación, se presenta las



18

necesidades de los actores y exhibe algunas pautas de elicitación y se muestra la

importancia de tener una adecuada gestión de requisitos.

Capítulo 4 - Una Perspectiva Paradigma cualitativo

Este capítulo realiza una presentación referente al enfoque de la investigación cualitativa.

Para ello inicialmente se realiza una definición del método de investigación donde se

abordan aspectos como: Algunas actividades y técnicas básicas que se pueden tener en

cuenta, cuándo se utiliza el enfoque cualitativo como método de investigación,

comparaciones entre los métodos cualitativo y cuantitativo, las actividades propias del

método, sus fases y finalmente se realiza una comparación de las características principales

de los métodos cualitativa y cuantitativa.

Capítulo 5 - Introducción al Estudio Empírico

Este capítulo de la tesis presenta las actividades de la definición, planificación y realización

del estudio empírico realizado entre las empresas que desarrollan productos de software a

medida en el departamento de Antioquia. Este estudio toma como base la tesis realizada en

la ciudad de Pernambuco, en Brasil, bajo el nombre: “Un estudio empírico sobre Ingeniería

de Requisitos de Empresa Producto de Software” [1] de donde aplicado al contexto

antioqueño, se generó este estudio bajo el tema: “Estudio del estado actual del proceso de

ingeniería de requisitos en las empresas antioqueñas de software”, con el objetivo principal

investigar las buenas prácticas, los principales retos y desafíos que enfrentan las empresas

que desarrollan productos de software a medida, durante el proceso de Ingeniería de

Requisitos.

Capítulo 6 –Resultados del Estudio Empírico.

En este capítulo se presenta la interpretación del estudio empírico y los resultados

obtenidos a partir de la realización de la investigación llevada a cabo entre las empresas que

desarrollan productos de software en Antioquia - Colombia. Los resultados se organizaron

tomando en cuenta: la manera de generar deducciones, la caracterización de las empresas

del estudio, identificación de aspectos positivos y oportunidades de mejora, los resultados

obtenidos en algunas etapas del proceso de Ingeniería de Requisitos y los desafíos que se

enfrentan durante el proceso, para llegar posteriormente a la validación de las hipótesis y a

la generación de algunas consideraciones finales. Además se presentan varios referentes de

información tales como: Aspectos de las organizaciones, metodologías de desarrollo que

utilizan, los tipos de productos que desarrollan, las etapas de desarrollo que llevan a cabo y

el manejo de los repositorios entre otros. En cuanto a los empleados adscritos al proceso de

desarrollo software, se evalúan: Sus niveles de experiencia, dominio de inglés,

certificaciones, tiempo de vinculación y rolles en la organización, entre otros. En cuanto a

los referentes de clientes, se analizan: Los nichos de mercado que son atendidos, su

tipificación, los niveles de satisfacción, los tipos de contratación que se generan y el nivel

de conocimiento de los clientes respecto al proceso de desarrollo software. Respecto al

proceso de ingeniería de software en general este capítulo genera datos respecto a los roles



19

asignados por las organizaciones, las metodologías de desarrollo, lenguajes más utilizados,

el seguimiento que se realiza a los productos entregados, la gestión realizada por las

organizaciones para generar nuevas versiones del producto, el tiempo de entrega entre

versiones y finaliza con los datos porcentuales de desarrollo de nuevos productos,

migración, componentes y mejores prácticas de seguimiento a las versiones y productos

finales, termina esta sección con el control de tiempo de entrega entre versiones. En cuanto

al proceso de Ingeniería de Requisitos este capítulo presenta el detalle de los insumos, la

metodología, los aspectos críticos, las herramientas y las mejores prácticas.

Capítulo 7- Conclusiones y Trabajos Futuros

En este capítulo presenta las conclusiones generadas con el desarrollo del estudio, además

de la generación de investigaciones futuras a que este estudio dio pie y finaliza con el

enunciado de algunas de las mejores prácticas encontradas en el medio.

Capítulo 8- Apéndice A Encuesta

Identifica el instrumento encuesta que se utilizó con el objetivo de buscar la caracterización

de Las Empresas que Desarrollan Productos Software en Antioquia Colombia.

Capítulo 9- Apéndice B Entrevista

El apéndice muestra el documento entrevista que contiene un conjunto de preguntas para

ser contestadas por uno o más representantes de las empresas que forman parte del estudio

empírico, con el fin de obtener información más detallada sobre el proceso de desarrollo, la

interacción con los clientes, la ingeniería de requisitos y sobre todo tiene como fin

identificar los retos y problemas enfrentado durante el proceso de Ingeniería de Requisitos.

Capítulo 10 – Bibliografía

Este documento termina con el registro de los apoyos bibliográficos utilizados durante esta

investigación.



20

2. CAPÍTULO INGENIERÍA DE SOFTWARE

Este capítulo proporciona una fundamentación básica de Ingeniería de Software, Ingeniería

de Requisitos y Experimentación en Ingeniería de Software, además, presenta una visión

general de los conceptos y técnicas relacionadas con los temas mencionados anteriormente,

mostrando las principales definiciones y actividades de acuerdo con el enfoque de este

estudio.

2.1. Definición del ámbito

La ingeniería de software tiene su origen relacionado con la ingeniería y los sistemas de

hardware. Cubre los métodos, herramientas y procedimientos que proporcionan el control

del proceso de desarrollo de software y es la base fundamental para su construcción [1] en

[89].

El concepto Ingeniería de Software fue introducido por primera vez a fines de 1960, en una

conferencia destinada a su discusión, la cual fue posteriormente llamada “crisis del

software”, que fue el resultado directo de la introducción del hardware de tercera

generación computacional. [9].

Para la [10]. El concepto de ingeniería apunta al uso de un enfoque sistemático,

disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software; es

decir, la aplicación de ingeniería al software. Pressman define Ingeniería de Software como

una disciplina del área de la informática o ciencias de la computación, que ofrece métodos

y técnicas para desarrollar y mantener software de calidad que resuelven los problemas de

todo tipo. [11] por lo tanto la Ingeniería de Software se puede definir como desarrollo

disciplinado y evolución de los sistemas de software basado en un conjunto de principios,

procesos y tecnologías. [1] en [10].

La Ingeniería de Software es "una disciplina de la ingeniería que se ocupa de todos los

aspectos de la producción de software desde las primeras etapas de la especificación del

sistema hasta el mantenimiento del sistema después de ponerse en funcionamiento". [2] en

[105].

Por lo tanto, en conjunto las definiciones anteriores demuestran que la ingeniería de

software tiene su enfoque en los sistemas computacionales y utiliza el término de ingeniería

como: Ingenio para producir y crear realidad usando componentes técnicos y no técnicos.

Cabe anotar que este estudio abarca todas las fases del ciclo de vida del desarrollo de

cualquier sistema de información y es aplicable todas las áreas.

En este sentido, un proceso de software detallado y completo suele denominarse

“Metodología”. Las metodologías se basan en una combinación de los modelos de proceso

genéricos como: cascada, evolutivo, incremental, etc. Dado lo anterior, el proceso de



21

desarrollo software se le conoce también como ciclo de vida del software. Mientras que

adicionalmente una metodología debería definir con precisión los artefactos, roles y

actividades involucradas, junto con prácticas y técnicas recomendadas, guías de adaptación

de la metodología al proyecto, guías para uso de herramientas de apoyo, etc., hoy

habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías

asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo.

Como consecuencia y para apoyar las diferentes metodologías de la ingeniería del software,

algunos autores han generado aportes o enfoques como los que se citan a continuación:

2.2. Enfoque de tecnología multicapa

Pressman señala un enfoque que apoya la calidad en la ingeniería de software, vista como

“una tecnología multicapa”, como se ilustrada en la Figura 1, lo anterior basado en la

premisa que un software de calidad es aquel concordante con los requisitos del cliente y los

estándares funcionales de desarrollo en la industria del software. [11]

Teniendo en cuenta que cualquier disciplina de ingeniería (incluida la ingeniería del

software) debe aportar para evitar el sobre esfuerzo que las organizaciones invierten en la

calidad. La gestión total de la calidad y las filosofías similares fomentan una cultura

continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez más

robustos para la ingeniería del software. A continuación se grafican las capas del modelo de

ingeniería de software en Figura 1. Capas de la Ingeniería de Software Tomado de

Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.

Figura 1. Capas de la Ingeniería de Software Tomado de Pressman, R, Ingeniería del

Software: Un enfoque práctico, McGraw Hill 1997.

Modelo de Desarrollo por Capas

El fundamento de la ingeniería de software es la capa proceso. El proceso define un

marco de trabajo para un conjunto de áreas clave, las cuales forman la base del control



22

de gestión de proyectos de software y establecen el contexto en el cual: se aplican los

métodos técnicos, se producen resultados de trabajo, se establecen hitos, se asegura la

calidad y el cambio se gestiona adecuadamente.

Los métodos de la ingeniería de software indican cómo construir técnicamente el

software. Los métodos abarcan una gran gama de tareas que incluyen análisis de

requisitos, diseño, construcción de programas, pruebas y mantenimiento. Estos métodos

dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología

e incluyen actividades de modelado y otras técnicas descriptivas.

Las herramientas de la ingeniería del software proporcionan un soporte automático o

semi-automático para el proceso y los métodos, a estas herramientas se les llama

herramientas CASE (Computer-Aided Software Engineering).

Concluyendo lo anterior podemos decir que el proceso de desarrollo software está

compuesto por un conjunto de capas cuya intención es la de cumplir el objetivo con

calidad. Por tanto el objetivo de la ingeniería de software es lograr productos de software

de calidad tanto en su forma final como durante su elaboración, utilizando procesos

métodos y herramientas de apoyo. Bajo este contexto, un proceso de desarrollo de software

tiene como propósito la producción eficaz y eficiente de un producto software que reúna los

requisitos del cliente, como lo indica [12] “La aplicación de buenas prácticas en la gestión

de requisitos de software es una condición fundamental para lograr productos de calidad”

Como se observa en la Figura 2. Procesos de Desarrollo Software, los insumos básicos del

proceso de desarrollo software son los requisitos.

Figura 2. Proceso de Desarrollo Software

En apoyo a lo anterior, este estudio toma las figuras de cada ciclo de vida del proceso de

desarrollo software, expresados por diferentes autores y las muestra en la Figura [3], Ciclos

de Vida del Desarrollo Software, con el fin de observar la posición y el papel que

desempeña la Ingeniería de Requisitos en los diferentes modelos de desarrollo software, y

se observa como para todos los modelos de desarrollo software, la Ingeniería de Requisitos

es la base del proceso.

Requisistos Proceso de Desarrollo Sistema



23

Modelo de desarrollo evolutivo.

Modelo Lineal Secuencial Tomado de [31]

Modelo de Construcción de Prototipos

Tomado de:

http://informaticastec.blogspot.com/2010/11/modelos-de-construccion-de-prototipos.html

Tomado de: http://elprocesodedesarrollodelsoftware.blogspot.com/

Análisis Diseño Código Pruebas



http://elprocesodedesarrollodelsoftware.blogspot.com/

http://elprocesodedesarrollodelsoftware.blogspot.com/



24

Figura 3. Ciclos de Vida del Desarrollo Software

2.3. Fases de ingeniería de software

En este contexto, la ingeniería de software empieza con una serie de tareas de modelado

que llevan a una especificación completa de los requisitos y a una representación del diseño

general del software a construir para continuar con una cadena de tareas que apoyan el

proceso de desarrollo en las Figura 4. Guía del Conocimiento de la Ingeniería Software

Swebook.

Figura 4. Guía del Conocimiento de la Ingeniería Software Swebook

Al analizar en la figura 4, los roles, las actividades y tareas realizadas en el proceso de

desarrollo software, incluso las de nivel técnico, son evidentes varias cosas: una es la

necesidad de la participación del cliente en cada parte, dos, se infiere la necesidad de un

equipo de trabajo y la participación de este en el desarrollo unificado y fortalecido como



25

grupo de trabajo que requiere el conocimiento de la ciencia del comportamiento humano

para lograr no solo su interacción y entendimiento como equipo, sino además obtener la

información referente a las necesidades de los clientes para expresarlas en la ingeniería de

requisitos. [13][34]

Apoyado en lo anterior, podemos decir que cuando en los equipos e trabajo de las

organizaciones existe una filosofía corporativa a partir de principios de formalidad,

disciplina y orden y se puede observar que el grupo de trabajo ha desarrollado proyectos

por varios años, unido como un equipo identificado con esa filosofía, la organización se

comienzan a ver como una sola unidad compacta, sistémica y con un mismo enfoque. Y es

a partir de ese momento que la experiencia se convierte en principio y la comunicación

entre los miembros se unifica en un mismo lenguaje. Que es lo que facilita el entendimiento

por parte de todo el equipo de desarrollo de los artefactos obtenidos en la ingeniería de

requisitos. [14]

Cabe anotar además, que no es solo en el proceso inicial la presencia de la ingeniería de

requisitos, más bien es una actividad que está presente en todas las fases del ciclo de vida,

apoyando el diseño, la implementación y sirviendo de guía para el desarrollo que se

realizan de acuerdo a las especificaciones generadas al inicio del proyecto y que

posteriormente constituyen la base de las pruebas y la validación del proyecto.

En ese sentido, es también importante destacar que la Ingeniería de Requisitos se va

enriqueciendo con los hallazgos a lo largo del proceso de desarrollo con el fin de generar

futuras entregas de productos. Dado que durante las etapas de mantenimiento y evolución

del software, la Ingeniería de Requisitos, involucra la creación de nuevos requisitos,

compromete a nuevas funcionalidades para futuras entregas y permite evaluar las

capacidades fijadas para la puesta en producción.

La Ingeniería de Requisitos es además el factor más aportante a la calidad del software,

puesto que refleja las necesidades de los usuarios de donde depende en gran medida el

cumplimiento de las expectativas reveladas y la generación de valor para el cliente que

posteriormente se traduce indicadores de satisfacción o en su defecto de calidad.

Por lo anterior, el papel que desempeña la Ingeniería de Requisitos en el proceso de

desarrollo software, es de vital importancia lo que se demuestra en la figura 5. Fases

preestablecidas en el proceso de desarrollo software, dado que satisface necesidades y

cumple objetivos recogidos durante el proceso de requisitos.



26

Figura 5. Fases Preestablecidas en el Proceso de Desarrollo Software

En tal sentido podríamos decir que, la calidad en el producto software depende

directamente de la adecuada Ingeniería de Requisitos y está a su vez de la habilidad para

vislumbrar las necesidades de los usuarios.

En cuanto al grupo de usuarios involucrados en el producto software a su vez podemos

decir, que es cualquier grupo o individuo identificable al que pueda afectar el logro de los

objetivos en una organización o que es afectado por el software, la teoría de los

stakeholders los define como: Cualquier grupo o individuo identificable, respecto del cual

la organización es dependiente para su supervivencia (empleados, segmentos de clientes,

ciertos proveedores, agencias gubernamentales clave, accionistas, ciertas instituciones

financieras, y otros). En el caso del desarrollo software los stakeholder no solo no son

ajenos a la supervivencia del software, sino más bien son la columna vertebral para que el

proceso se lleve a cabo de manera exitosa. [15]

Referente a los stakeholders, para Pressman existen dos grupos: Internos y externos, los

grupos de interés internos son los desarrolladores, que trabajan en el proyecto a desarrollar

en darle valor para el cliente. Y los usuarios finales son los interesados externos clientes,

usuarios finales, patrocinadores, accionistas, consultores o expertos del dominio,

consultores técnicos que influyen en el éxito o fracaso del proyecto pero no son los que

trabajan directamente en el diseño de software y tienen el conocimiento de la información

importante y necesaria para que los desarrolladores construyan los objetivos del sistema y

producto de software. [16].

Según Karl E. Wiegers, el centro de Ingeniería de Requisitos, está en la identificación de

las necesidades y limitaciones de los distintos actores de un software de sistema, su

Pruebas y validación Mantenimiento y

Evolución

Software Requisitos

Diseño

Implementación

Desarrollo

Satisfacer necesidades y

Cumplir los objetivos

expuestos en los requisitos

Ingeniería de Requisitos



27

obtención se centra en descubrir las necesidades de los usuarios y clasificarlas para su

atención en las diferentes categorías. [17][38].

Referente a los usuarios del producto, la agrupación es: los clientes y usuarios se clasifican

en usuario final que es la persona que utiliza el producto en sí y cliente que es la persona

que solicita el software, paga por ello y por lo general especifica cual es el requisitos que

debe contener el producto. Sin embargo, es importante tener en cuenta que el usuario no es

siempre el que paga, sino quien es apoyado en sus tareas por el software, por tanto es de

gran significación conocer los diferentes intereses de los usuarios del producto para

convertirlos en usuarios clave a lo largo del ciclo de vida software que brinda [2] en [30].

En conclusión respecto al proceso de desarrollo software, se puede decir que es el que se

sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una

idea hasta la entrega y el retiro del sistema, todo lo anterior enmarcado dentro de un

conjunto de requisitos y ejecutando todas las actividades y artefactos necesarios para

desarrollar una aplicación por compleja que ella sea.

Según Humphrey el proceso de desarrollo software es “El conjunto completo de actividades

de ingeniería de software necesarias para transformar los requisitos del usuario en

software.” [18] como lo indica el Figura 6. Transformación de requisitos en software.

TRANSFORMACIÓN DE REQUISITOS EN SOFTWARE

Figura 6. Software. Adaptado de Synerplus



28

Resumiendo, las actividades básicas con que cuenta el ciclo de vida del software se

muestran en la figura 7. Actividades Básicas del Proceso de desarrollo software.

Figura 7. Actividades Básicas del Proceso de Desarrollo Software

Conocido ya el contexto del proceso de desarrollo software y la posición que en este tiene

la Ingeniería de Requisitos, como se mostró en la sección 2.1, de este capítulo donde se

presenta una breve introducción a la Ingeniería Software y se describen algunas

definiciones y pasos clave que caracterizar el proceso de desarrollo de software. Luego en

la sección 2.2 y la sección 2.3 donde se presenta una visión general de los enfoques

Ingeniería de Software.

Posteriormente, este trabajo se centra en la Sección 2.4, en la Ingeniería de Requisitos

describiendo, algunos conceptos básicos, así como las definiciones y categorización de su

elemento clave - los requisitos - y finalmente se abordan las fases de Ingeniería Requisitos

como la obtención, el análisis y la negociación, documentación y validación. Tratando en

cada actividad las características propósitos de ella, así como las técnicas y prácticas

actuales que la apoyan.

Finalmente se presenta en este capítulo, una perspectiva de experimentación Ingeniería de

Software con la descripción de algunos paradigmas (método científico, la ingeniería,

matemáticas y empíricas) y las etapas de experimentación Ingeniería del Software:

definición, planificación, ejecución e interpretación de experimento, en pro de la calidad

del desarrollo software.

2.4. Descripción general de Ingeniería de Requisitos

Cuando hablamos de ingeniería en el contexto del software, se presentan varias

definiciones tales como:

Req

uis

ito

s • Descripción de las necesidades del producto

• Meta identificar y documentar lo que en realidad se necesite y la forma de comunicarlo al cliente y al equipo desarrollador

Dis

eño

• Para desarrollar una aplicación, es necesario contar con descripciones detalladas y de alto nivel de la solución lógica y saber cómo satisface los requerimientos y las restricciones.

• Muestra una solución lógica: como el sistema cumple con los requisitos. (hardware y software)

Imp

lem

en

taci

ón

• Realizar especificación como un software u sistema de cómputo.

• Generación de código para resolver cierto problema P

rueb

as

• Verificación que el programa generado entregue los resultados de acuerdo a las especificaciones del usuario.

• Demostrar que el programa realiza las funciones para las cuales fue creado y que estan especificadas en los requisitos.

Man

ten

imie

nto

• Se pone el sistema en marcha para el usuario final.

• Se realizan corerecciones al producto despues de entregado y con base en los requisitos.

• Se identificar nuevos requisitos.



29

Es la aplicación práctica del conocimiento científico al diseño y construcción de

programas de computadora y a la documentación asociada requerida para desarrollar,

operar y mantenerlos. (Bohem, 1976).

Trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener

software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).

Es el estudio de los principios y metodologías para el desarrollo y mantenimiento de

sistemas software (Zelkovitz, 1978).

La Ingeniería de software en general hace entonces, referencia al proceso creativo cuyo

objetivo es la generación de software. Este proceso tiene varios componentes a lo largo de

su ejecución, siendo la Ingeniería de Requisitos la columna vertebral para conducir y

soportar el proceso de desarrollo software.

La comprensión dada al término Ingeniería de Requisitos mostrada a partir de lo que se

espera que realice para cada participante en el proceso Ingeniería de Requisitos se muestra

en la figura 8. Objetivos esperados por los actores de la Ingeniería de Requisitos basado en:

[19]

Figura 8. Objetivos esperados por los actores de la Ingeniería de Requisitos

(Basado en: IEEE Guide to Software Requirements Specification)

2.4.1 Definiciones de requisitos.

Se presentan algunas maneras de definir requisitos en el entorno del desarrollo software

como:

•Describir con precisión lo que desean

obtener

Los clientes

•Entender exactamente lo que

quiere el cliente

Proveedores •Desarrollar un esquema estándar de

especificación de requisitos del software para su propia organización.

•Definir el formato y el contenido de sus especificaciones de requisitos de software específicos

•Desarrollar elementos adicionales locales de apoyo, como listas de control de calidad o un escritor manual.

Las personas



30

Una especificación para un producto de software determinado.

Programa o conjunto de programas que realizan ciertas funciones en un entorno

específico.(IEEE)

Condición o capacidad que un usuario necesita para poder resolver un problema o

lograr un objetivo. (IEEE)

Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato,

estándar, especificación, u otra documentación formalmente impuesta (IEEE)

Algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson -

Robertson).

Condición o capacidad a la que el sistema debe responder (RUP).

Otra definición, dado por [2] en [29], sugiere que un requisito es "un necesidad del

usuario o de un servicio, función o atributo necesario de sistema que puede ser

percibido desde una posición fuera de ese sistema".

En resumen, el propósito de un proyecto de desarrollo de software es crear un producto que

genere valor a un conjunto particular de clientes esto apoyado en el desarrollo de Ingeniería

de Requisitos el propósito es lograr determinar la mezcla de capacidades de los productos y

las características más idóneos para conseguir este valor para el cliente. [20] [65].

En conjunto las definiciones apuntan a especificar las características un software mediante

la Ingeniería de Requisitos que abarca la visión que se muestra en la figura 9

VISIÓN DE INGENIERÍA DE REQUISITOS

Figura 9. Visión de Ingeniería de Requisitos

Visionar a los Requisitos con eje fundamental para precisar

las funciones del sistema comprende:

La vista de los usuarios ante las necesidades del sistema

Conducta sistema

Visión del desarrollador

Comportamiento interno del sistema

Documentación de requisitos

http://es.wikipedia.org/wiki/RUP



31

Basado en Karl E. Wiegers se realiza el siguiente escrito referente a Ingeniería de

Requisitos, teniendo en cuenta que para el autor el centro de la Ingeniería de Requisitos es

la identificación de las necesidades y limitaciones de los distintos actores de un software, y

que para otros actores que intervienen en el proceso, la Ingeniería de Requisitos se debe

centrar en descubrir las necesidades de los usuarios, proceso que incluye las tareas que se

van a llevar a cabo con el sistema, las expectativas de rendimiento de los usuarios, la

facilidad de uso, y otros atributos de calidad.[17] [63]

Por tanto el proceso del analista requiere saber no solo "¿Que desea el usuario? " sino

conocer “¿qué hay?” y "¿Qué que hay que hacer? Para esto se usan diferentes técnicas entre

las que están por ejemplo los casos de uso [21] [30]

Es importante tener presente que el producto del desarrollo de la Ingeniería de Requisitos

es un entendimiento común entre los interesados en el proyecto de las necesidades que se

están abordando. Por tanto si y solo si, se debe explorar una alternativa de solución por

parte del equipo de desarrollo, una vez que los desarrolladores entiendan completamente las

necesidades de los usuarios. De lo contrario se esperaran múltiples problemas como:

Reproceso, demoras en la entrega y confusiones al interior del equipo de desarrollo,

quienes con ideas inicialmente preconcebidas y equivocadas han generado su propio

esquema mental que los lleva a múltiples interpretaciones de la solución y a disgregación

del equipo de trabajo. Por algo la psicología advierte que “Desaprender es el enemigo del

aprendizaje”.

Por lo anterior se hace necesario realizar una planificación de la Ingeniería de Requisitos,

con el mínimo de expectativas como se demuestra en la figura 10. Plan de ingeniería de

Requisitos, basada en [17].



32

Figura 10. Plan de Ingeniería de Requisitos

2.4.2 Elicitación de Requisitos

La elicitación de requisitos es la forma de adquirir conocimientos, esta se hace a través de

diferentes técnicas como: entrevistas, encuestas, workshop, prototipos, entre otras, las

técnicas son importantes porque existen diferencias de opinión respecto la efectividad

lograda en la utilización de cada una para el conseguir el objetivo de la recolección de la

información clara completa y concreta para el proceso de Ingeniería de Requisitos, pese a

que no existen estudios comparativos que permitan analizar el potencial de cada técnica en

sí misma, estudios arrojan resultados como que: Las entrevistas, preferentemente

estructuradas, parecen ser una de las técnicas de obtención más eficaces en una amplia

gama de ámbitos y situaciones de los diferentes tipos de desarrollo. Por otra parte varias

técnicas frecuentemente citadas en la literatura, como tarjeta de clasificación, o pensando

en voz alta, tienden a ser menos eficaces que las entrevistas. En este sentido, aunque no se

encontraron mediciones importantes para el uso de los prototipos, estos muestran tenerse

como buena práctica con resultados positivos en la mayoría de las organizaciones. Según

observaciones realizadas en este estudio se puede afirmar que el éxito de la técnica depende

directamente de la pericia de quien la aplica y no de factores como el tiempo que lleve

ejecutando su labor o de la técnica en sí misma. [38].

Lo más relevante entonces en la utilización de la técnica de elicitación es saber leer el

factor contextual del stakeholders para determinar la técnica más exitosa a utilizar en cada

Objetivos elicitación

validación de los datos del mercado

Exploración de casos de uso, o en vías de desarrollo

Un conjunto detallado de requisitos funcionales para el sistema

Estrategias y procesos

Alguna combinación de elicitación de encuestas, talleres, visitas a clientes, entrevistas individuales y otras técnicas, posiblemente utilizando diferentes enfoques para diferentes grupos de interés

Documentos de los esfuerzos de elicitación

Una lista de casos de uso detallados

Un análisis de los resultados de la encuesta, o el rendimiento y la calidad

Especificaciones de los atributos

Horario y estimaciones de recursos

Identificar el desarrollo y participantes de los clientes en las diversas actividades de educción

Estimaciones del esfuerzo y el tiempo de calendario requerido

Riesgos elicitación

Identificar los factores que podrían obstaculizar su capacidad para completar las actividades de elicitación

Cómo se pretende, estimar

La severidad de la cada riesgo, y decidir cómo se puede mitigar o controlar



33

caso apoyada del conocimiento previo de las características de los participantes, del entorno

del negocio, del tamaño de la muestra, entre otros elementos, como la disponibilidad del

tiempo, y el nivel de compromiso de ellos, etc. [22] [32].

Por lo tanto la elicitación es la etapa más propensa a errores dado que solo se puede obtener

mediante comunicación humana, por tanto, requiere habilidades especiales del analista

quien debe crear un entorno propicio para una exploración exhaustiva del producto a ser

especificado. Debe además lograr comunicación clara, usar el vocabulario del manejo del

cliente en lugar de forzar a los clientes a comprender lenguaje técnico, captura términos

significativos del dominio de la aplicación en un glosario, en lugar de suponer que todos los

participantes comparten las mismas definiciones, dejar claro a los clientes que esta es una

discusión sobre la posible funcionalidad y no es un compromiso para incluirlo en el

producto. [17].

2.4.3 Técnicas de elicitación de requisitos

A continuación se presentan algunas técnicas de elicitación relevantes en el medio

acompañadas de una serie de factores a tener en cuenta para su elección y/o durante

su aplicación.

Lluvia de ideas:

o Esta técnica se deben tener separadas las prioridades

o Los interesados deben centrarse y priorizar la lista de deseos de cielo azul, es

decir la lista de los deseos habituales y sin contratiempos.

o Se requiere experiencia para manejar los debates dados conflictos grupales que

puedan surgir

o El analista debe identificar las necesidades que no son evidentes. Una estrategia

es preguntar varias veces "¿Por qué?".

o Emplear preguntas abiertas para entender procesos de negocio que ayudados por

el sistema generen mayor valor.

o Indagar sobre usuarios que hagan la misma tarea

o Indague por las excepciones. ¿Qué podría evitar que el usuario completara

exitosamente una tarea? ¿Cómo debe responder el sistema a varios errores o

condiciones? Haga preguntas que comienzan con "¿Qué más podría ...", "¿Qué

pasa cuando ... "," ¿Alguna vez tenga que ... "," ¿De dónde sacas ... "," ¿Por qué

usted (o qué no) ... ", y" ¿Alguien alguna vez ... "documentar el origen de cada

requisito para que pueda obtener más aclaraciones si es necesario y trace

actividades de desarrollo de nuevo a los orígenes específicos de los clientes.

o Es necesario sacar a la luz los supuestos de los clientes.

o En lugar de limitarse a transcribir lo que los clientes dicen, el analista debe ser

creativo, generar ideas y alternativas.

o Observar trabajar y sugerir maneras de automatizar partes del trabajo a los

usuarios con dificultad para expresarse.



34

o Buscar oportunidades de reúso de los sistemas existentes.

Entrevistas individuales y grupales

o Requieren involucrar a los usuarios en el proceso de obtención

o Entender los pensamientos de los usuarios

o Extraer la lógica subyacente. Flujos, tablas y árboles de decisión son formas

útiles para representar estos caminos decisiones lógicas.

o Asegurarse de que todo el mundo entiende por qué el sistema debe cumplir

ciertas funciones. o Identificar los requisitos obsoletos o ineficaces y los procesos de negocio que no

deben incorporarse en un nuevo sistema.

o Después de cada entrevista, documentar los elementos que el grupo discutió y

pedir los entrevistados para revisar la lista y hacer correcciones. La revisión

temprana es esencial se para saber si hubo precisión en la información.

o Utilizar nuevas conversaciones para resolver las incoherencias y para llenar los

espacios en blanco.

Talleres elicitación

o Permite vincular a los usuarios y a los desarrolladores

o El taller se debe planificar y seleccionar los participantes

o Utilizar un facilitador externo para que el analista pueda dedicar toda su

atención a la discusión y un escribano para capturar los puntos de discusión.

Sin tomar en cuenta cual sea la estrategia de elicitación utilizada esta debe tener en

cuenta: [17]

o Iniciar y terminar las secciones a tiempo

o Sostener una sola conversación a la vez

o Lograr que todos contribuyan

o Centrarse en comentarios y críticas sobre los problemas, no en los individuos

Permanecer en el alcance

o Utilice el documento de visión y alcance para confirmar si las necesidades de los

usuarios están contempladas dentro del alcance.

o Evite discusiones que no permitan avanzar en temas del alcance.

o Evite los detalles que ponen restricciones innecesarias al proceso y generan

demora y desvío de la atención.

Detenerse para capturar los temas que se examinaran más adelante.



35

o Tener registrada la información expresada por los usuarios y que se examinará

más adelante

Tiempo de Discusión:

o Asignar un tiempo fijo para discutir cada caso de uso y asignar otro momento de

ser necesario.

Equipos de discusión Pequeños:

o Reducidos grupos (5) cinco personas generan rápidas discusiones

o Incluir representantes de los usuarios finales, expertos, analistas de requisitos y

desarrollador.

Mantener a todos participando:

o Mantener el interés y la participación de los integrantes dando valor a sus

aportes y motivándolos.

Demasiados participantes

o Demasiados participantes o datos lentifican el proceso por largas discusiones.

Clasifique la información

o La figura 11. Clasificación de la voz del cliente, muestra algunas formas de

catalogar la información obtenida en la elicitación de los requisitos, esta figura

es tomada de [17].

o Sin embargo, cabe anotar que cuando la información no encaja en uno de estos

cubos esta podría catalogarse como:

- Un requisitos no relacionado con el desarrollo software, (necesidad de usuario).

- Una restricción (restricción de diseño o implementación)

- Un supuesto

- Uno de los requisitos de datos, (que almacena los datos en un ordenador)

- Información adicional de un establecimiento de contexto histórico.

CLASIFICACIÓN DE LA VOZ DEL CLIENTE



36

Figura 11. Classifying the voice of the customer (Tomada de 10-

1SW_Requirements_Ch7)

2.4.4 Los requisitos del negocio.

Son la descripción financiera de mercado u otro beneficio comercial que los clientes

o la organización requieren del desarrollo. Y se oirán como:

"Aumentar la participación en el mercado en un X%."

"Guardar $ Y al año en electricidad ahora desperdiciada por las unidades

ineficientes."

"Ahorre $ Z por año en costos de mantenimiento que son consumidos por el sistema de W. "

2.4.5 Los casos de uso o escenarios:

Son las declaraciones generales de los objetivos del usuario o tareas empresariales

que los usuarios necesitan llevar a cabo, los casos de uso son un solo camino

específico a través de un escenario de uso [21].

o Se puede recoger casos de uso pidiendo a los usuarios describir su flujo de

trabajo empresarial. O pedir a los usuarios que “necesitan” que haga el sistema.



37

2.4.6 Las reglas de negocio.

o Cuando un cliente dice que sólo ciertas clases de usuarios pueden

o Algunas frases que identifican reglas de negocio:

"Hay que cumplir con la ley o <some Policy> corporativa"

"Debe cumplir con Estándar <some>"

"Si la condición es <some true>, entonces <something happens>"

"Debe ser calculado según formula> <some"

2.4.7 Requisitos funcionales.

o Describen el observable comportamientos del sistema

o Describen lo que el sistema deberá hacer en respuesta a una necesidad de

usuario.

2.4.8 Atributos de calidad.

o Declaraciones que indican qué tan bien funciona el sistema

o Escuche: rápido, fácil, intuitiva, robusto, confiable, segura y eficiente.

o Más allá de Funciones son atributos de calidad de software.

2.4.9 Requisitos de interfaz externos.

o Describe las conexiones entre el sistema y el resto del universo.

o Frases que identifican:

"Hay que leer las señales de <some dispositivo>"

"Debe enviar mensajes a otros <some system>"

"Debe ser capaz de leer (o escribir) archivos en <some Formato>"

"Debe controlar pieza <some de hardware>"

"Elementos de la interfaz de usuario deben ajustarse a <some Estándar>

estilo de interfaz de usuario"

2.4.10 Restricciones.

o Son limitaciones que restringen las opciones del desarrollador

o Se recomienda registrar la razón de ser de cada restricción para que todos los

participantes en el proyecto sepan de donde viene.

o Limitaciones y restricciones innecesarias inhiben la creación de la mejor

solución.

o Debe preguntarse por qué existe la restricción para validarla

o Frases que indican que el cliente está describiendo una restricción:

"Debe ser escrito en <a específica idioma> programación"



38

"No se puede exigir más que la cantidad de <some memoria>"

"Hay que operar de forma idéntica a (o ser compatible con) <otro

Sistema>”

"Se debe usar <a específica de interfaz de usuario comandos>"

2.4.11 Las definiciones de datos.

o Cuando los clientes describen el formato, tipo de datos, valores permitidos, o el

valor predeterminado de un elemento de datos o la composición de una

estructura de datos.

o Un ejemplo el código postal

o El mejor ejemplo de definición de datos lo brinda el caso Y2K

2.4.12 Ideas solución.

o Describen la manera específica para interactuar con el sistema para llevar a cabo

algún tipo de acción se presentará una propuesta de solución.

o Frases que sugieren ideas de solución de parte del usuario:

o "Entonces, selecciono el estado en el que desea enviar el paquete de una lista

desplegable. "La frase de una lista desplegable indica que es una idea

solución. Que deben ser validadas y sustentadas por el analista.

2.4.13 Algunas precauciones Acerca de la Elicitación

o Definir adecuadamente los usuarios representantes del proceso.

o Si el alcance no es correcto ejecute los requisitos que generen mayor valor al

negocio.

o Utilice modelos bocetos y prototipos para aclarar los requisitos dejando claro que

son ilustrativos.

o Realice investigación de la viabilidad del proyecto en la organización.

Encontrar requisitos faltantes:

Los requisitos faltantes se encuentran al descomponer requisitos de alto nivel en el detalle

suficiente para revelar exactamente lo que se está solicitando. Un requisito vago y de alto

nivel que deja mucho a la interpretación del lector dará lugar a una brecha entre lo que el

solicitante tiene en mente y lo que el desarrollador construye.

o Asegúrese de que todas las clases de usuarios, han contribuido.

o Trazar los requisitos del sistema, casos de uso, listas de eventos de respuestas,

normas empresariales y sus requisitos funcionales detallados para asegurarse que el

analista obtiene toda la funcionalidad necesaria.



39

o Comprobar los valores límite para los requisitos faltantes.

o El modelado representa visualmente los requisitos a un alto nivel de abstracción el

bosque, no los árboles.

o Los conjuntos de requisitos con la lógica booleana compleja a menudo son

incompletos. Se debe representar en una tabla.

o Otra forma rigurosa para buscar los requisitos que faltan es crear un CRUD (crear,

leer, actualizar y eliminar) en una matriz.

o Algunas personas agregan una L a la matriz de indican que el elemento de datos

aparece como una selección de lista según lo muestra la Tabla [1], Sample CRUDL

matriz for the chemical tracking system, tomada de [17]

Tabla 1. Sample CRUDL matriz for the chemical tracking system. (Tomada de 10-


Entoty

Use Case

Order Chemical Requester Vendor Catalog

Place order C R R R,L

Change order U,D R R,L

Manage chemical inventory C,U,D

Report on orders R R,L R,L

Edit requesters C,U,L

o ¿Cómo saber cuándo estás hecho?

Los requisitos tal vez terminan cuando, como lo muestra la figura 12. El proceso de

ingeniería de Requisitos tal vez terminó, basada en [17]. Sucede que los usuarios:



40

Figura 12. El proceso de ingeniería de Requisitos tal vez terminó. (Basada en 10-


A pesar de sus mejores esfuerzos para descubrir todos los requisitos, no lo hará, por lo que

hay que esperar para hacer los cambios a medida que avanza la construcción. Y es

importante recordar, que el objetivo es que los requisitos sean lo suficientemente buenos

para que proceda a la construcción de una solución aceptada y minimicen el nivel del riesgo

en la aceptación del producto final.

o Pasos siguientes y Finales

Es necesario pensar acerca de los requisitos que se descubrieron a finales de desaparecidos su último proyecto y preguntarse ¿Por qué fueron pasados por

alto durante la provocación? ¿Cómo has podido descubrir cada uno de estos

requisitos antes?

La Tabla [1] puede servir como base, Sample CRUDL matriz for the chemical

tracking system

A continuación se debe clasificar cada elemento de ese fragmento de requisitos en las categorías. Este proceso se muestra en Figura 11, esto con el fin de saber

si realizo una adecuada clasificación.

Finalmente es necesario enumerar los métodos de elicitación y requisitos que se utilizan en el actual proyecto y preguntarse ¿Cuáles funcionaron bien? ¿Por qué?

¿Cuáles no funciona tan bien? ¿Por qué no?, para identificar las técnicas de

obtención que podría funcionar mejor y decidir cómo se aplicadas la próxima

Los Usuarios

No pueden pensar en más casos de uso

Proponen nuevos casos de uso, pero

que ya derivados de los requisitos funcionales

Repiten cuestiones que ya se

examinaron en anteriores discusión

Sugieren nuevas funcionalidades

fuera del alcance

Proponen requisitos de baja prioridad.

Proponen que podrìa incluirse

alguna vez

Se crea una lista de áreas funcionales

comunes a tener en cuenta para sus

proyectos.

Solicitan lo ya especificado



41

vez, y así identificar los obstáculos que pueden surgir a las técnicas de trabajo

para pensar sobre las maneras de superar las barreras.

2.5. Una visión general de Experimentación en Ingeniería de Software [22]

Siguiendo con la estructura basada en [2] una visión general del software experimental y

partiendo de los conceptos universales, es importante entonces tener presente los aportes

que genera el software experimental al proceso de desarrollo software. Según [23]

2.5.1. Aportes del software experimental.

Las tecnologías que se emplean en el desarrollo de software carecen de evidencias

sobre su adecuación, límites, cualidades, costos y riesgos (Jedlitschka).

No existe evidencia alguna que apoye la mayoría de las creencias sobre las que se

basa la construcción de software.

La experimentación contribuye a contrastar las creencias y las opiniones para

convertirlas en hechos.

El fin de la experimentación es identificar las causas por las que se producen

determinados resultados.

Un experimento modela en el laboratorio, en condiciones controladas, las

principales características de una realidad lo que permite estudiarla y comprenderla

mejor.

La fortaleza de la experimentación en laboratorio es que permite variar

iterativamente aspectos de la realidad para estudiar el impacto que tienen tales

manipulaciones.

La Experimentación en Ingeniería de Software (ISE) hará posible la comprensión e

identificación de las variables que entran en juego en la construcción de software y

las conexiones que existen entre ellas.

Experimentar con la construcción de software permitirá aumentar la comprensión de

lo que hace al software bueno y cómo hacer software bien [Pfleeger].

El objetivo de la ISE es hacer del desarrollo de software una actividad predecible

científicamente, gracias al conocimiento de las relaciones entre los procesos de

producción de software y los productos que se obtienen.

La ISE traslada a la Ingeniería del Software (IS) el paradigma experimental.

Todas las disciplinas experimentales necesitan adaptar los principios del

experimentalismo a su propio contexto.

El desarrollo de una metodología experimental específica para la IS en lo que

consiste la investigación en ISE.



42

Desde que la ISE surgió como una disciplina, se ha progresado en la realización de

experimentos aislados, pero éste es sólo un primer paso en la secuencia de

actividades del paradigma experimental.

2.5.2. Definición de software experimental:

Según [1] en [10], la Ingeniería de Software Experimental es la disciplina que implica no

sólo el desarrollo de un proceso de modelo de sistema de software. Tal disciplina también

involucra la planificación, el análisis y la información de los diferentes aspectos (por

ejemplo, el análisis de la organización de las personas y el medio ambiente en modelo de

software del sistema que se construyeron proceso) así como la validación de la

investigación.

2.5.3. Fines de la experimentación:

Teniendo en cuenta que el fin de la experimentación es identificar las causas por las que se

producen determinados resultados; un experimento modela en el laboratorio (es decir, en

condiciones controladas) las principales características de una realidad (en nuestro caso el

desarrollo de software) lo que permite estudiarla y comprenderla mejor. La fortaleza de la

experimentación en laboratorio es que permite variar iterativamente aspectos de la realidad

para estudiar el impacto que tienen tales manipulaciones.

La experimentación en Ingeniería de Software, hará posible la comprensión e identificación

de las variables que entran en juego en la construcción de software y las conexiones que

existen entre ellas.

Mientras que experimentar con la construcción de software nos permitirá, en palabras de

[Pfleeger 99] “Aumentar la comprensión de lo que hace al software bueno y cómo hacer

software bien”. La meta de la Ingeniería de Software Experimental, es hacer del desarrollo

de software una actividad predecible científicamente gracias al conocimiento de las

relaciones entre los procesos de producción de software y los productos que se obtienen.

En este sentido, La Nacional Science Foundation estadounidense ha establecido la

experimentación como uno de los objetivos prioritarios en el que centrar parte de la

investigación en ingeniería de software: “Avanzar nuestra comprensión del proceso de

negocio de software mediante la experimentación” [22].

Según el autor, la Experimentación en Ingeniería de Software tiene como objetivo

desarrollar fundamentos científicos de la ingeniería de software con el fin que futuros

investigadores puedan replicarla.



43

2.5.4. Paradigma utilizado en experimentación

En la historia de todas las disciplinas ingenieriles se ha producido un paso similar al que la

ingeniería de software experimental propugna para la ingeniería de software. La

información usada para construir artefactos transita por etapas que van desde las creencias,

especulaciones y aciertos casuales, hasta el conocimiento científico por medio del cual la

disciplina ingenieril alcanza resultados predecibles. La ingeniería de software experimental

establece los cimientos para realizar investigaciones experimentales en ingeniería de

software, con el fin de llegar a conclusiones científicamente válidas sobre las que basar el

desarrollo de software. Este conocimiento debe permitir identificar las condiciones de

aplicabilidad, las debilidades y las fortalezas de las distintas tecnologías de desarrollo de

software. [24], [25]

Se señalan respecto al paradigma experimental, diversas metodologías utilizadas en otras

disciplinas que pudieran estar siendo utilizadas en el paradigma experimental del software y

estos a su vez hacen uso de diversos paradigmas experimentales o analíticos. En [2] en [11]

De igual manera las investigaciones sobre el tema afirman que los paradigmas

experimentales requieren planificación, observación, recopilación de datos y el proceso de

validación o química, analizando los siguientes modelos experimentales: el método

científico y sus variaciones, método de ingeniería y método empírico, así como un

paradigma analítico el método matemático que se analizan brevemente a continuación. [2]

en [10]

o El método científico: este método inductivo consiste en observar el mundo,

proponiendo un modelo o teoría del comportamiento, medida para analizar o validar los

supuestos del modelo o teoría, y si es posible, repetir el proceso.

En la ingeniería de software, este paradigma puede ser la mejor opción en la búsqueda

de la comprensión del proceso de software, el producto, las personas y el medio

ambiente. El objetivo es tratar de extraer modelos del mundo y evaluar si son

representativos (ambas actividades basándose en la observación (s) de evento (s)

observado (s)).

Dos variaciones de este enfoque inductivo son: El método de ingeniería y El método

empírico. El primero consiste en observar la existencia de soluciones para

solucionarlas, construir o desarrollar, recopilar y analizar y repetir el proceso hasta que

mejorarlo. Se trata de un enfoque dirigido que supone que los modelos de procesos

evolutivos ya existen en software como, productos, personas y ambientes. De los

cambios realizados en el modelo o aspectos de modelo, se pueden lograr mejoras. En

cuanto al el método empírico, puede decirse que consiste en proponer un modelo con

la aplicación de métodos cualitativos y cuantitativos para estudios de casos con el

objetivo de recopilar y analizar los datos para validarlo. Se trata de un enfoque dirigido

que tiene como objetivo proponer un nuevo modelo, que puede o no estar basado en

uno ya existente, este puede sugerir los efectos de los procesos o productos a través del



44

nuevo modelo. Tanto para el éxito del Método de ingeniería como para el Método

empírico son las actividades fundamentales de recogida y el análisis.

o El método matemático: este método deductivo para proponer una teoría formal o un

conjunto de axiomas, desarrollar una teoría, derivar los resultados y las observaciones

se pueden comparar con empírica. Este modelo no requiere un diseño experimental,

pero proporciona un marco analítico para desarrollar modelos y comprender sus límites

basan en la manipulación de su propio modelo.

En este contexto, es necesario precisar y organizar algunas medidas en el ensayo con el

objetivo de ofrecer una mejor comprensión y la evaluación del estudio tales como el

Marco, [2][11], que tiene cuatro fases en el proceso de ensayo: definición, planificación,

ejecución e interpretación. A continuación, cada uno de serán discutidos estos pasos.

2.6. Definición del experimento

Es la primera etapa del proceso experimental. Esta fase especificación consta de seis temas

principales: motivación, objeto estudio, propuesta de estudio, la perspectiva, el dominio y el

alcance.

La motivación en un estudio puede definirse como: entender, evaluar o mejorar el objeto

del estudio.

El objeto de estudio es la entidad principal en el que examinar por ejemplo, un proceso de

desarrollo, un producto modelo de software, entre otros.

La propuesta puede incluir: la caracterización de los cambios en un sistema para evaluar la

eficacia de los procesos de pruebas, para evaluar los costos en la implantación de un

modelo, motivar a la validación de una teoría a través del estudio empírico, etc.

La perspectiva específica desde qué punto de vista del estudio es logrado, por ejemplo, la

perspectiva del desarrollador, un cliente, entre otros.

El dominio puede considerarse bajo dos aspectos: individual o de grupo individuos y el

programa o proyecto. Persona o grupo son los trabajando por separado y el programa o

proyecto en el persona o grupo de trabajo (m). Se especifica lo general El ámbito de

aplicación en los estudios empíricos como lo muestra la Tabla [2] Escopos Empiricos,

tomada de [2] en [11].



45

Tabla 2. Escopos Empiricos. Tomada de [per] en [11].

Cantidad de

Personas por

Proyecto

Cantidad de proyectos

Uno Más de uno

Una

Single Project

Multi-Project Variation

Más de una

Replicated Projet

Blocked Subjet-Project

El objeto del proyecto

o Proyectos múltiples o aplicaciones son estudiado, que se analizan en diferentes temas

cada proyecto. Este tipo de diseño ayuda a reducir interpretaciones mal formulados.

Sin embargo, el costo de los experimento se incrementa.

o Proyecto Replicado. En un proyecto o aplicación son analizó diversos temas. Los

estudios de este tipo de uso diversos temas o personas (equipos), todos trabajando en

el mismo proyecto o aplicación

o Multi-Proyecto Variación Inicialmente, uno o más los sujetos se observan en un

proyecto o aplicación antes y después de realizar un tratamiento en un proyecto o

aplicación específica, que se compara con un proyecto o aplicación que no tenía

ningún tratamiento

o El Proyecto Individual es similar a la notación de estudio de casos por una sola

persona involucrada en un proyecto o aplicación.

Se destaca en el estudio empírico varios elementos: motivaciones, objeto de estudio,

propuestas o puntos de vista, entre otros. Sin embargo, es importante destacar la manera

como se describen y detallan los puntos mencionados para que otros investigadores puedan

entender el propósito del estudio y tener como base las referencias para estudios

posteriores.

2.7. Planificación del experimento

La segunda fase del proceso experimental es el diseño. Esta fase especificación comprende

tres actividades: diseño, criterios y evaluación.

o El diseño de un experimento une el alcance de los métodos de estudio análisis y

especifica la muestra a estudiar. Diferentes motivaciones, objetos de estudio, propuestas, perspectivas, dominios y ámbitos requieren la verificación de criterios



46

diferentes. Los criterios tienden a ser clasificados en aspectos relacionados con el

costo, errores, cambios de tamaño, complejidad, la visibilidad de la información, entre

otros. Como último paso de las actividades, sería el logro de los criterios de evaluación

específicos, que implicaría la especificación y recopilación de métrica, así como la

descripción de las técnicas de recolección.

2.8. Realización del experimento

La tercera fase del proceso experimental consiste en hacerlo efectivo. Esta fase comprende

tres actividades: preparación, ejecución y análisis. La preparación es el establecimiento

de procedimientos antes de la ejecución real del experimento. Un ejemplo sería realizar tres

tex piloto, que permitieran los posibles ajustes y correcciones del experimento. La

aplicación o ejecución consiste en la recogida de los experimentos. Esta colección general

se lleva a cabo de acuerdo con el uso de las denominadas herramientas de búsqueda como,

cuestionarios, entrevistas y entre otras. El análisis se fundamenta en la evaluación

preliminar de los datos recogidos antes la formulación de una hipótesis o interpretación

efectiva de los mismos. En este paso de la actividad se puede incluir métodos cualitativos y

cuantitativos.

2.9. Interpretación del experimento

La cuarta fase del proceso experimental es la fase de interpretación de los datos del estudio.

Esta fase consta de tres actividades: el contexto de la interpretación, extrapolación

(Extrapolación) y los impactos. Después de analizar los datos, deben ser interpretadas de

acuerdo a los contextos, es decir, se deben comprobar si los resultados están en línea con el

estudio propuesto, el conocimiento del campo de la investigación, etc. La representatividad

de la muestra analizada en el estudio califica extrapolación de los resultados en otros

entornos. El impacto sugerido debe de ser con respecto a los debates y las implicaciones

generadas a partir del estudio, por ejemplo, la posibilidad de la replicación experimento y la

aplicación de mejoras en los métodos para desarrollo, gestión y software de investigación.

Se puede afirmar que el ensayo es importante para la zona Ingeniería de Software, se

sugiere que antes de la especificación de un modelo o proceso, la construcción de un

sistema o producto software, los estudios empíricos realizado con la intención de conocer o

investigar los problemas, los desafíos, así como contexto en el que se producen, al ser más

objetivos bien fundadas construcción y mejoras sugeridas. Por último, a través de la

experimentación, el área de Ingeniería de Software victorias sobre la naturaleza de la

ciencia como la búsqueda de nuevas experiencias conocimiento, y que se refiere al "cómo"

y "qué" procedimientos y métodos deben ser utilizados para organizar y evaluar los

conocimientos adquiridos.

2.10. Final

Para concluir se puede decir que la ingeniería de software es un área que cubre varios

aspectos pertinentes y estos son extremadamente importantes para el éxito de los diseños de



47

sistemas de software. En el próximo capítulo, vamos a contemplar el tema específico

Ingeniería de software, las principales características y peculiaridades que impregnan las

actividades de la ingeniería de requisitos que se centran en el desarrollo de productos

software.



48

3. CAPÍTULO IMPACTO DE LA INGENIERÍA DE REQUISITOS DE

SOFTWARE DESARROLLO DE PRODUCTOS

Este capítulo presenta el impacto generado por la ingeniería de requisitos en el proceso de

desarrollo de software personalizado, para ello se abordaron algunas realidades del proceso

como: - Si no se logran los requisitos correctos no va importar que tan bien se ejecute el

resto del proyecto de todos modos el resultado no será el adecuado, lo anterior se debe a

que los requisitos de desarrollo son un descubrimiento y no solamente una colección de

procesos. - El cambio sucede en las organizaciones y la Ingeniería de Requisitos no debe

ser ajena a esta situación, en este contexto hay que tener presente que todos los interesados

del proceso intervienen en los requisitos generando visiones propias, lo que hace que la

participación de los clientes sea el factor más crítico a la calidad del software, sin embargo,

aunque pensemos que el cliente no siempre tiene la razón es innegable que este siempre

tiene un punto de vista que es válido y necesario para tenerlo en cuenta, en ese sentido, el

analista debe utilizar como filtro, no solo preguntarse si estos apoyan los procesos del

negocio sino so además si: "¿está este requisito en el alcance?” para así saber si debe

considerarlo para esa o para una siguiente puesta en producción.

Otro aspecto al que se hace referencia en el capítulo es a la necesidad de la comunicación

humana, a este respecto se dice que incluso el mejor documento sobre las necesidades de

usuario no puede y no debe reemplazar el diálogo humano donde no solo se comprenden

requisitos con las palabras expresadas sino con otras lecturas como la expresión corporal

entre otros y se hace énfasis en que en materia de los requisitos, estos pueden ser vagos, sin

embargo el producto siempre será específico, por tanto no se debe utilizar la incertidumbre

en los requisitos como una excusa para la falta de precisión en el producto.

Terminando, este capítulo se presenta el tema denominado “El triage”, donde se muestran

algunos factores importantes a tener en cuenta al realizar el primer acercamiento con el

cliente en la ingeniería de requisitos de un proyecto y finalmente este capítulo termina

presentando algunas formas de encontrar las verdaderas necesidades de los stakeholders,

con la exhibición de algunas pautas de elicitación y concluir reiterando la importancia que

tiene para el producto software de calidad, el hecho de tener una adecuada gestión de

requisitos.

Tomando en cuenta lo anterior este capítulo se basa en la afirmación de que para el

contexto actual de calidad en el desarrollo, en la ingeniería de Software es importante

destacar el gran impacto que presenta en este sentido la Ingeniería de Requisitos.

Respecto a la ingeniería de software podemos afirmar que: “Como cada consultor sabe, la

respuesta correcta para casi cualquier pregunta con respecto a software, Es depende". Bajo

esta afirmación, el mejor consejo para la forma de proceder a ejecutar Ingeniería de

Requisitos en una situación determinada es depender de la naturaleza del proyecto, sus

limitaciones, la cultura de la organización y del equipo y el ambiente de negocios entre



49

otros factores. En consecuencia la Ingeniería de Requisitos no es una actividad estática que

se aplique a todas las organizaciones, personas o grupos de la misma manera, más bien que

el análisis de los requisitos es un proceso de comunicación que atraviesa una barrera

cultural entre el desarrollador y el cliente. [20] [13]

De igual manera se sabe que la ingeniería de requisitos es una rama de la Ingeniería de

Software, que tiene que ver con el entendimiento en una forma ordenada de lo que se

requiere en un sistema software por parte de clientes y usuarios. Y que dicha Ingeniería

direcciona el proceso de elicitación, definición, modelado, análisis, especificación y

validación de los requisitos para lograr un sistema y de su software, lo anterior, lo hace

basado en un enfoque sistemático, separando el "que" del "como" del diseño. Cada una de

estas actividades se considera como crítica dentro del desarrollo de sistemas de

información, dado que los errores no detectados en las primeras etapas del proceso de

desarrollo pueden tener amplias repercusiones en fases posteriores. Por lo tanto, disponer

de un modelo de procesos acompañado de una herramienta para la gestión de requisitos es

un avance importante y necesario para lograr calidad en la industria del desarrollo software.

[2]

Los requisitos de software entonces, expresan las necesidades y limitaciones que

corresponde colocar en un producto de software y que deben contribuir a la satisfacción de

alguna necesidad en el mundo real, en este sentido la ingeniería de requisitos puede

constituirse en una peligrosa trampa para el proceso de desarrollo software que llevan a

cabo las organizaciones y que de quedar atrapados en ella genera consecuencias terribles

para el negocio tanto del lado del cliente como de la empresa de desarrollo. Dichas trampas

aparecen de la incorrecta definición de los requisitos y como resultado generan excesos de

costos, plazos incumplidos, productos mal diseñados y en última instancia, un fracaso por

no poder ofrecer lo que el cliente en realidad necesita. [6] [26].

3.1. Realidades acerca de la ingeniería de requisitos de software

Para adentrarse en las realidades del software, este estudio cita algunas afirmaciones

propias del tema, encontradas en la literatura así:

Si no se logran los requisitos correctos, no va importar que tan bien se ejecute el resto

del proyecto: Es importante tener en cuenta que cuando se hable de requisitos, no solo se

hace mención a los que se tuvieron en cuenta en el inicio del proyecto, sino también a los

requisitos que a lo largo de la ejecución del proyecto se van adquiriendo mediante la

experiencia y el conocimiento de las necesidades del cliente y su organización y que

proporciona valor, mezclando capacidades del producto en apoyo a las características

propias del negocio solo de esta manera se logran establecer los requisitos verdaderamente

correctos para un proyecto. [20]

Todo lo anterior se consolida mediante exploración y análisis de los requisitos obtenidos,

que incluye la etapa correspondiente a la validación, la que tiene como característica



50

principal, la participación de los usuarios correctos para lograr el objetivo de aceptación del

cliente y por ende la utilización del producto y su futuro inversión en él. [20]

Lo que lleva a pensar, que la aceptación de usuario del producto es un criterio de

validación, que parte del apoyo que el producto genere a las tareas y que como

consecuencia mide la calidad del producto. Son estos criterios entonces los que indican y

miden realmente si los requisitos fueron o no bien elaborados y advierte de la calidad del

producto final, porque fueron los requisitos validados la base para la ejecución del resto de

fases del proyecto. [20]

“Cuando la gestión de requisitos es mala, los resultados en proyecto son incompatibles”.

Esta es una de las llamadas trampas del desarrollo software, que hace que los productos se

desborden en tiempo y presupuesto. La afirmación inicial tiene predominio, dado que se

tiende a pensar que los requisitos se pueden hacer de la misma manera en los diferentes

proyectos por tanto hay etapas que pueden ser supuestas por el ingeniero o que no es

necesario ejecutarlos con la rigurosidad que lleva cada etapa de gestión de requisitos. Se

sabe en este sentido que la identificación y la gestión de los requisitos debe ayuda reducir el

riesgo en el producto final, a aislar a sus necesidades y por tanto a evitas ejecutar requisitos

incorrectos, situación que se da cuando se tiene una visión aislada de los requisitos,

mirándolos como si fueran entidades incomunicadas, sin reconocer las dependencias entre

ellos; lo que da lugar a un aumento de los riesgos del proyecto en los reproceso y al

incumplimientos en funcionalidades y tiempos de entrega. Se recomienda entonces, hacer

una interacción que muestre la relación que hay entre los requisitos del proyecto, los

requisitos de negocios y otros elementos subsecuentes, como modelos, casos de prueba y

defectos para garantizar la satisfacción de las necesidades de las partes interesadas. [26 ]

Por otro lado, cuando se identifican relaciones entre los requisitos, pese a que no se

administren juntos, lo recomendable es crear el nivel adecuado de trazabilidad entre ellos

generando; nuevas prioridades, considerando el efecto del cambio, utilizando las

herramientas que permitan visualizar fácilmente las relaciones. Esta es pues una excelente

base de mitigación de riesgos del proyecto y ayuda a asegurar la alineación que el negocio

requiere para generar valor y que se traduce en menores los costes de desarrollo. [26]

Los requisitos de desarrollo son un descubrimiento y no solamente una colección de

procesos: Es indudable que los requisitos no se recogen simplemente, es necesario ahondar

con estrategias que permitan descubrirlos, lo cual requiere interacción con los participantes,

investigación exploratoria, análisis, estrategias de descubrimiento de lo oculto y generación

de nuevas ideas, para finalmente lograr requisitos que permitan proponer funcionalidades

que satisfagan las necesidades del cliente y le añadan valor creativo al producto, siendo ese

el éxito esperado en los requisitos. [20]

Otra dificultad se hace evidente cuando durante la Ingeniería de Requisitos se presentan

exceso de documentos, lo que los hace difíciles de manejar los requisitos, además tal

exceso es evidencia de que existe una colección de procesos de tal magnitud que desvirtúa

y confunde el papel que deben cumplir estos en el desarrollo software y hace que se



51

conviertan en improductivos para el equipo alrededor de quienes se crea y un obstáculo

para la búsqueda de la información necesaria para hacer su trabajo. La causa general de este

desbordamiento de datos es el añadir demasiado detalle a los requisitos y la manera de

manejarlo es utilizando herramientas de requisitos, técnicas visuales (gráficos, mapas) y

glosarios de términos. [26].

Por otro lado cuando la documentación es centrada y retroalimentada como recompensa, se

presenta aumento en la eficiencia de todos los interesados, se reducen detalles extraños en

los requisitos y la trazabilidad y se presenta aumento en la calidad, dado que puede

centrarse la atención en la información más importante. Respecto a la documentación es

importante también tener en cuenta, que esta es presentada como un reto que implica que

durante el proceso de ingeniería de requisitos se generen artefactos que sean comprensibles

para todo el equipo de trabajo. [26], [27]

En apoyo a lo anterior, una de las maneras de afrontar el reto de la documentación es

generar un adecuado glosario de términos para lograr un vocabulario común manejado por

los diferentes participantes. [2]

El cambio sucede: Las empresas cambian, evolucionan en sus reglas de negocio, sus

clientes, sus usuarios, su mercado, por ende sus necesidades, usuarios, etc. Esto es

inevitable por tanto en la Ingeniería de Requisitos el cambio se debe gestionar en lugar de

inhibir, se debe anticipar y adaptarse, sin embargo hoy, se está generando agitación y

sobrecostos por carecerse de estructuras y procesos de control de cambios, lo que convierte

el cambio en una barrera en la producción y en la calidad final del producto, es necesario

entonces determinar: quién evalúa el cambio con autoridad, el proceso de gestión de

cambio como tal, tener conocimiento y capacidad de decisión además de pleno

conocimiento del crecimiento típico de los proyectos y su impacto a largo plazo, los planes

de contingencia, las líneas base y los costos generados. [20]

Los requisitos entonces no se pueden fijar en una piedra, por el contrario debe darse cabida

a esos cambios mediante la utilización de estrategias de apoyo como: manejar un

repositorio de requisitos basado en circunstancias cambiantes, tener un plan de proyecto

que se ajuste a los intervalos, mantener informados a los interesados de los cambios que se

producen, recibir sus aportes y justificación para la priorización, la capacidad de

planificación para el cambio en los requisitos del proyecto ayuda a mitigar riesgos y evita

los sobrecostos. [26]

Todos los interesados del proceso intervienen en los requisitos: Cumplir con el conjunto

de todos los requisitos, las limitaciones y las expectativas de las partes interesadas es clave

para la generación de un producto de calidad, por tanto un punto a favor es hacer claridad

respecto a la diferencia entre deseo y necesidad y las implicaciones que cada nuevo

requisitos generan al presupuesto en cuanto a tiempo y costo y con relación a su generación

de valor para el negocio. Por tal razón, es necesario tener claridad en cuanto a que es un

stakeholders o Interesado, "Un interesado es una persona física o grupo que participa

activamente en el proyecto, que se ve afectado por el proyecto, o que pueden influenciar



52

sus resultados”, en nuestro caso se puede apreciar en la Figura 13, Some typical software

Project stakeholders, tomada de la Figura 2-1 en esta figura se identifican algunos grupos

interesados en un proyecto de software típico. Como se observa los interesados son de

diversos tipos, por tanto se requiere del ingeniero, habilidades y capacidades especiales

para identificarlos y para reaccionar frente a situaciones como actores que tienen intereses

contrapuestos, resolver conflictos e identificar a los principales tomadores de decisiones.

[20].

Figura 13. Some typical software Project stakeholders (Tomada de 1-

cosmictruths.pdf)

Cuando se tienen artefactos de proyecto ocultos o sin fácil acceso, los desarrolladores y

probadores a menudo no son conscientes de la visión del proyecto o no pueden encontrar la

documentación de la arquitectura o la empresa los requisitos. Algunas recomendaciones a

este nivel son: Mantener todos los artefactos del proyecto en un repositorio central que es

accesible por el proyecto, tener los documentos clasificados y gestionados, informar los

cambios al equipo. Tener la información al acceso de todos evita la repetición del trabajo,

disminuye los residuos y promueve la reutilización, ya que hace la colaboración y la

comunicación más fácil. [26]

La participación de los clientes es el factor más crítico a la calidad del software: Hoy

los clientes no tienen tiempo para acompañar el proceso, hacer críticas y evitar los errores.

Esta alternativa de participación activa serían menos costosa, dolorosa y más ágil, además

tiene el mayor porcentaje para garantizar el éxito del proyecto. Al respecto se ha generado

muchas estrategias que motiven e involucren al cliente en el proceso como las técnicas de

identificación de usuarios, líderes o campeones de producto, construcción de prototipos y

claridad en el establecimiento de las responsabilidades. [20].

Como aporte a lo anterior es necesario tener en cuenta en la relación cliente-requisitos, que

la comunicación debe ser frecuente, para evitar los posibles problemas que puedan surgir

con el desarrollo paulatino del producto y la falta de consulta frecuente con el cliente lo que



53

lleva a imaginar soluciones y requisitos, “la falta de comunicación de frecuencia es una

trampa entonces para el desarrollo de software” por lo tanto se recomienda elegir un

representante de cada grupo para comunicarse con regularidad, usar expertos para dirigir

talleres grandes, establecer controles regulares con sus grupos de interés y determinar

previamente la frecuencia de la participación. Solo la comunicación regular ayuda a ofrecer

el producto que el cliente realmente quiere. [26]

El cliente no siempre tiene la razón, pero el cliente siempre tiene un punto: Por tanto el

analista debe estar alerta a situaciones para identificar el estado del cliente, su grado de

conocimiento de las necesidades y negociar con él [20].

Cuando se habla de pedir a los clientes lo que quieren parece contradictorio, pero, los

clientes tienden a hablar acerca de las características que desean, sueñan o maginan y poco

de lo que realmente necesitan. La verdad es que la gente a menudo no sabe lo que quiere de

un producto software e imagina que este es la respuesta a una serie de impresiones y

dificultades que representan caos en la organización y que no necesariamente tienen como

solución total un producto software. A este nivel, cuando los clientes no saben lo que

quieren y los desarrolladores no entienden el problema, se generan mal concebidas

soluciones y productos defectuosos. Algunas sugerencias a este nivel serian: utilizar

estrategias diversas para preguntar a los clientes sus necesidades concretas y así orientar el

debate lejos de centrarse en las características, preguntar lo que quieren que el software

haga, crear discusiones por separado de cómo se utilizarán los productos, identificar los

actores adecuados sin combinar público objetivo, usuario final y cliente. [26]

La primera pregunta que un analista debe hacer acerca de un nuevo requisito

propuesto es: "¿Está este requisito en el alcance?": El crecimiento controlado de los

requisitos es normal sin embargo, algunas influencias hacen que este se desborde evitando

que el producto sea entregado a tiempo. Para evitar esto es necesario tener claro y

concertado el alcance del producto, que debe ser conocido y expuesto al equipo de

desarrollo. Así frente a un nuevo requisito se debe crear la cultura en el equipo de

desarrollo de preguntarse "¿Está este requisitos en el alcance?" dicha información también

debe ser de dominio del usuario, quien deberá comprenderla como necesaria para la

ejecución exitosa de la primera entrega y como la base de recolección de requisitos para

entregas futuras. [20].

Por lo tanto, la falta de conocimiento del alcance, es una de las trampas para el desarrollo

software que se generan desde el momento inicial de la Ingeniería de Requisitos y cuyo

resultado funestamente acarrea el aumento del costo, del tiempo y la insatisfacción del

cliente y por ende genera reportes de baja a calidad en el producto final. De aquí, que se

generen planes de contingencia como: “Los equipos de desarrollo prevén las trampas de la

gestión de requisitos e intencionalmente subvierten la creación de presupuestos y

cronogramas precisos y con antelación”. [26]

Como ya se indicó la corrupción del alcance conlleva al aumento de los recursos, tiempo y

presupuesto dado que el crecimiento sin control en un proyecto, puede ocurrir cuando los



54

equipos de desarrollo crean soluciones antes de determinar lo que realmente necesita el

negocio. Por lo tanto la mala observación de los requisitos trae como resultado al negocio

un proyecto aun sin validar y con vago nivel para aplicarlos al desarrollo, que llevan por lo

tanto, al equipo de desarrollo por desconocimiento a querer centrarse en el detalle del

producto. [26]

Se debe tener en cuenta que los requisitos del negocio son las necesidades reales de la

organización y que son a su vez las que el producto software debe apoyar generando valor,

por tanto estos deben ser lo suficientemente detallados para evitar la corrupción del alcance.

Al cumplir con el producto, los requisitos debe satisfacer las necesidades del negocio y por

lo tanto los equipos no pueden desarrollar soluciones que tengan exceso en la adición de

características. Los requisitos deben proporcionar valor, acomodarse al cambio, centrarse

en lo que la empresa requiere, identificar y trabajar con las partes interesadas para entender

el negocio y tener pleno control de los cambios. Como recompensa se evita la corrupción

del alcance, se facilita la planificación, se mantienen intactos los presupuestos y los pazos,

se genera valor y se logran productos de calidad. [26]

Incluso el mejor documento sobre las necesidades no puede y no debe reemplazar el

diálogo humano: Aunque se reconoce el valor de la documentación y las ventajas que esta

aporta a la preparación previa de los analistas, esta no reemplaza la comunicación verbal

directa. La comunicación sigue siendo necesaria, para tener acercamiento personal de parte

de los analistas y desarrolladores con los usuarios-conocedores y expertos en la materia,

esto procura afinar detalles, aclarar ambigüedades, y llenar los espacios en blanco.

"¿Cuánto detalle se necesita?”. [20].

“Comunicarse con las partes interesadas es la mejor manera de comprenderse fácilmente”,

“la comunicación efectiva minimiza el tiempo y optimiza el esfuerzo” esas son dos de las

premisas referente a las trampas que para el desarrollo de software implica una óptima y

personalizada comunicación de los requisitos del producto, lo que además hace pensar en

pautas para generar una comunicación efectiva y eficaz y así obtener un conocimiento

previo del público al que se va a dirigir cada sección. Con este fin se pueden utilizar

estrategias pedagógicas como los diagramas, historias de usuarios, bocetos y storyboards,

crear glosarios, plantillas de documentos y formularios de comentarios que sean claros,

concisos y fáciles de diligenciar, usar prototipos para ayudar a los interesados a visualizar

la solución. Usar la comunicación por lo tanto, propicia la obtención y retroalimentación de

todos los representantes de los interesados, esto debe hacerse con sutileza y evitando la

crítica de los puntos de vista, para esto se recurre a estrategias que permitan manejar

palabras como "incorporaré", "colocaré esto en una lista de deseos" o "No se puede dar

cabida esto ahora”, La recompensa de la comunicación efectiva es la eficiencia y la ayuda

que brinda al evitar malentendidos que descarrilen los proyectos. [26]

Los requisitos pueden ser vagos, pero el producto será específico: Es normal que se

presente el caso que la especificación de requisitos carezca de precisión y por tanto sea



55

difícil de entender o se preste para múltiples interpretaciones. Especialmente cuando el

producto es nuevo, en este caso las partes interesadas deben tener claridad y registro de las

impresiones dejadas en los requisitos y los supuestos asumidos. [20].

La consecuencia del mal manejo de la situación anterior es decir, de los requisitos

ambiguos, llevan a confusión, reproceso y que se pase demasiado tiempo tratando de

obtener aclaraciones a la información. La ambigüedad también tiende a generar riesgos a

las siguientes fases del proyecto. Se recomienda utilizar referencias por escrito, crear

glosarios, escribir y redactar del mismo modo que se le haría alguien recién ingresado a la

organización, usar imágenes y redacciones paso a paso, leer a tiempo después de haber

escrito. De esta manera se logrará la comprensión a las necesidades del proyecto de

software. [26]

No utilice la incertidumbre como una excusa para la falta de precisión: Una manera de

hacerle frente a la incertidumbre es mediante el uso de técnicas de prototipos que evitan la

redundancia en los análisis y permiten descongelar los requisitos además, de abrir la puerta

de entrada a la realización de una mejor estimación de recursos y costo. [20].

Lo anterior puede hacernos caer en cuenta que a causa de la falta de medición y evaluación

en los procesos de requisitos, esta se convierte en una tarea compleja e imprecisa, dado que

no se tienen mecanismos de control ni de mejora que permitan evaluar, las organizaciones.

Al respecto, se debe tener la capacidad de revisar, evaluar y mejorar los requisitos y así

poder lograr una visión precisa de datos, procesos y prácticas que es la clave del

componente de éxito.

A partir de lo anterior es recomendable realizar retroalimentación de lecciones aprendidas,

fomentar la mejora continua, definir y recopilar métricas que aseguran su éxito. Un ejemplo

sería medir el impacto de los cambios en sus necesidades, la cobertura de caso de prueba, la

prioridad, el costo y el esfuerzo de las empresas y los requisitos del producto. En este

sentido, a la vez que se experimenta con la medida se encontrará la combinación adecuada

de indicadores que permitirán realizar mejoras en la Ingeniería de Requisitos. La

recompensa en la medición depende del desempeño de los proyectos, y es revelar los

pequeños problemas antes de que se conviertan en grandes problemas, que pasen a formar

parte de la incertidumbre en los proyectos. [26]

3.2. El Triage

Según Cook y Sinclar, quienes afirman que los requisitos requieren de una sección de

triage: “el triage es el proceso mediante el cual un paciente es valorado a su llegada para

determinar la urgencia del problema y asignar el recurso de salud apropiado para el cuidado

del problema identificado; el paciente es clasificado de acuerdo con prioridades”, esto tiene

gran similitud a lo que representa el primer acercamiento que es la Ingeniería de Requisitos

para el caso del proceso de desarrollo software “los requisitos requieren de una sección de

triage”, donde se clasifiquen según algunos conceptos previos y es de allí de donde se parte

para tener solidez y calidad en la Ingeniería de Requisitos que acompaña y apoya al proceso



56

de desarrollo software. En la Figura 14. Visión de conjunto en el triage de los requisitos, se

explican en su orden las actividades previas a la Ingeniería de Requisitos y las partes que lo

componen como la identificación de los actores, el establecer prioridades, definir los

recursos y finalmente establecer los peligros. [36]

Figura 14. Visión de conjunto en el triage de los requisitos. Adaptado de (5-Notes on

The Art of Requirements Triage by Alan M Davis)

3.3. Las necesidades de los actores:

El centro de la Ingeniería de Requisitos está en desarrollar procesos que identifiquen las

necesidades y limitaciones de los distintos actores en un producto software por tanto el

descubrimiento de las necesidades de los usuarios es el punto de partida. En consecuencia

se puede afirmar que la fase de elicitación es la base que conduce a una óptima Ingeniería

de Requisitos y por tanto la que genera mayor impacto en el proceso de desarrollo software,

dado que es en la elicitación donde se logran identificar las necesidades, limitaciones y

aportes que debe generar el software. [17]

Para complementar lo anterior, se citan a continuación algunas técnicas que se deben tener

en cuenta durante la elicitación de los requisitos y que además se han convertido en

alternativas para el entendimiento de las necesidades de los interesados y la capacidad de

respuesta del producto: [17]

- Resistir la tentación de diseñar el sistema hasta no entender el problema no hacerlo así,

lo que lleva a confusión en el equipo de trabajo y genera reprocesos. La Figura [15],

basada en [17] muestra los contenidos del plan de elicitación con el fin de tener un

completo entendimiento del problema, con algunos ítems que deben ser parte vital del

plan de elicitación.

CONTENIDOS DEL PLAN DE ELICITACIÓN

Identificar los actores

Establezcer prioridades

Definir los recursos

necesarios

Establecer peligros



57

La base de una buena elicitación debe ser: [17]

Crear un ambiente propicio:

Facilitar la comunicación

Capturar los términos significativos

Generar discusión

Priorizar

Mostrar cielo azul

Sondear bajo la superficie

Indagar sobre las excepciones

Indagar sobre los sistemas existentes

Sacar a luz supuestos

Gestar ideas y alternativas

Buscar oportunidades de reúso de otros sistemas

Documentar luego de cada actividad

Resolver incoherencias

Realizar talleres

Clasificar los requisitos por las categorías en requisitos de negocio, casos de uso y

escenarios, reglas de negocio, requisitos funcionales, atributos de calidad, interfaz

externa de requisitos, restricciones, definición de datos, solución de ideas.

Clasificar la información adicional encontrada.

Objetivos

Estrategias de procesos

Artículos de los

esfuerzos de elicitación

Horario y estimación

de los recursos

Riesgos de elicitación

Figura 15. Contenidos del Plan de Elicitación. Adaptado de (10-1SW_Requirements_Ch7)



58

Ser un buen oyente es necesario porque las palabras orientan la clasificación del

requisito.

Se debe prestar especial atención dado que al elicitar se puede hacer variar el alcance

Buscar los requisitos faltantes

Buscar las señales de terminación de la ingeniería de requisitos.

Entendiendo la Ingeniería de Requisitos como el procesos que identifica las necesidades y

limitaciones de los distintos actores en un software, se puede decir entonces que el proceso

de desarrollo software necesita la Ingeniería de Requisitos para existir y que la elicitación

es el corazón de ésta.

Respecto al marcado interés que demuestran los diferentes autores por la elicitación de

requisitos cabe anotar el siguiente aporte: “De todas las actividades relacionadas con el

desarrollo de software, la comprensión de los requisitos del cliente es una de las más

importantes”, sin embargo pese a la gran importancia de la elicitación hoy vemos como se

siguen aplicando las mismas técnicas para tratar de generar resultados mejores. Las técnicas

de elicitación entonces no deben generalizarse, estas deben ser estrategias pedagógicas que

dependen del entorno, del participante, de las características y el clima organizacional.

Apoyados en lo anterior no podemos decir que un proceso de elicitación de requisitos es

inadecuado, o que deba o no utilizarse una u otra técnica, más bien se puede decir que es

más productivo el uso de una técnica de acuerdo al caso particular de un determinado

cliente. Sin embargo, cabe anotar que el empoderamiento de la técnica depende en gran

medida de la pericia, observación y conocimiento que tenga el elicitador. [29].

Por su parte, las técnicas individuales utilizadas tienden a representar la voz de un usuario,

mientras que las técnicas grupales aunque requieren de mayores habilidades para su

manejo, entregan como resultados la voz de un grupo. [29]

3.4. La definición y Gestión de Requisitos:

El tema de este capítulo, define a la gestión de requisitos como un paso necesario para el

éxito, es la entrega exitosa de los sistemas y proyectos de software y es la disciplina

requerido por estándares, reglamentos e iniciativas de mejora de calidad como CMMI®.

[39].

En este contexto, el éxito en la definición de requisitos parte de la claridad en el proceso de

creación y gestión de los mismos y se constituye en un reto para los sistemas y productos

que desarrolla TI y de hecho para cualquier actividad en la que se requiera el manejo de una

relación contractual. [39].

Sin olvidar, que una gestión eficaz de requisitos garantiza el cumplimiento de las

necesidades de los clientes, en el tiempo y los recursos estimados. Es entonces importante

conocer no solo que existen unos requisitos, sino también controlar su calidad. Un requisito



59

está correctamente definido cuando es correcto, completo, claro, consistente, verificable,

trazable, factible, modular y de diseño independiente. [39]

Teniendo en cuenta que la buena administración mejora y acelera el retorno de la inversión

de los recursos en los proyectos y que además vigila que los requisitos estén expresados de

manera clara, por el contrario, la falta de claridad lleva a producir el proyecto equivocado,

por lo tanto, se podría afirmar que el primer paso de la gestión es tener requisitos claros,

que sustenten los objetivos del proyecto y de futuros proyectos. En este sentido se

presentan importantes aportes en la Figura 16. Pautas para una Buena Administración de

los Requisitos, que es ajustada de [39]

PAUTAS DE ADMINISTRACIÓN DE REQUISITOS

Figura 16. Pautas para una Buena Administración de los Requisitos Adaptado de

(RM_WP_TenStepsToBetterRM.pdf)

3.5. Consideraciones Finales:

La definición de proyecto exitoso, es un proyecto a tiempo, dentro del presupuesto, y con

toda características planeadas. Por lo tanto, las realidades descritas en el capítulo reafirman

que la base de un proyecto de desarrollo software exitoso está en sus requisitos y más

específicamente se centra en una buena elicitación que incluya conocimiento de las

necesidades del cliente y claridad en el alcance, partiendo de la aseveración que para

conocer las necesidades del cliente se deben idear estrategias personalizadas, de

Requisitos de estructura

Administrar y vincular las

necesidades del cliente, requisitos y

Contratos

Especificar las restricciones

Especificar los requisitos de

calidad

Visualizar Requisitos

Requisitos de prueba

Cerrar la brecha entre el negocio y

el Desarrollo

Control de Cambio de los requisitos

Captura y seguimiento de las

métricas y tendencias

Ofrecer ejemplos de buenas Requisitos

Requerimientos de Re-uso



60

motivación, inclusión, escucha y depuración que deben estar sustentadas en un alcance

claro y concertado. [4] [27…].

El producto de software por sí solo no puede satisfacer las necesidades de los usuarios, es

fundamental la manera en la que los requisitos del producto son manejados

independientemente del software, para lograr que sea este quien apoye las necesidades de

los usuarios y no quien las limite.

Llegado a este punto, uno de los principales objetivos de la ingeniería de requisitos es

descubrir cómo analizar el sistema, para identificar qué requisitos deben ser asignados a los

componentes. En algunos sistemas, todos los componentes se ejecutarán en software en

otros se comprenderá la necesidad de una mezcla de las diferentes tecnologías, casi todo

tendrá usuarios humanos pero a veces los componentes del sistema deben ser asignados

(por ejemplo, para guardar costos o para explotar la capacidad de adaptación humana y el

ingenio). Debido a esto la Ingeniería de Requisitos es fundamentalmente una actividad de

ingeniería de sistemas, en lugar de una que es específica a la ingeniería de software. [6].

También cabe anotar, que en todo proyecto se debe generar un primer acercamiento con

resultados donde se Identifiquen los actores, se establezcan las prioridades, se definan los

recursos y se establezcan los peligros.

Apoyados en lo anterior podemos afirmar que la elicitación de los requisitos es una de las

tareas más importantes de la Ingeniería de Requisitos por tanto se plasmaron en este

capítulo algunas recomendaciones básicas de cómo realizar un plan de elicitación que debe

cubrir: Objetivos, estrategias de procesos, artículos de los esfuerzos de elicitación, horario y

estimación de los recursos, riesgos de elicitación, para garantizar éxito en el proceso.

Además, reafirmando la importancia de la elicitación, se presentan algunas pautas que giran

en torno a lograr acercamiento a los participantes y a motivar en ellos un ambiente de

participación en el proceso, dentro de esas pautas se destaca la de ser buen oyente y

canalizador de la información.

El procesos de desarrollo software en sí, necesita en lugar de una cantidad de requisitos

lograr una adecuada administración de ellos, teniendo en cuenta que esta mejoraría y

acelera el retorno de la inversión de los recursos en los proyectos y además vigila que los

requisitos estén expresados de manera clara, dado que, la falta de claridad genera el

proyecto equivocado, se podría afirmar por lo tanto, que el primer paso de la gestión es

tener requisitos claros, que sustenten los objetivos del proyecto actual y de futuros

proyectos. En este sentido algunas pautas de administración de requisitos serian, el conocer

la estructura, administrar y vincular las necesidades del cliente, requisitos y contratos,

especificar las restricciones, especificar los requisitos de calidad, visualizar requisitos,

requisitos de prueba, cerrar la brecha entre el negocio y el desarrollo, el control de cambio

de los requisitos, captura y seguimiento de las métricas y tendencias y ofrecer ejemplos de

buenas requisitos y los requisitos de re-uso, entre otros.



61

4. CAPÍTULO PARADIGMA CUALITATIVO

Una Perspectiva Paradigma cualitativo

Este capítulo realiza una presentación referente al enfoque de la investigación cualitativa.

Para ello inicialmente se efectúa una definición del método de investigación donde se

abordan aspectos como: Actividades y técnicas básicas que se pueden tener en cuenta

cuándo se utiliza el enfoque cualitativo como método de investigación y finalmente se

realiza una comparación de las características principales de los métodos cualitativo y

cuantitativo. [41…]. Teniendo en cuenta que el paradigma cualitativo es la metodología de

este estudio empírico, en este capítulo se presentan los temas con el fin de generar una

visión global del método. [40], [41…] [48]

4.1. Resumen del Método de Investigación

Según Lüdke y André (1986), para llevar a cabo una búsqueda, es necesario promover

confrontación entre los datos, la evidencia, la información recopilada sobre un tema

determinado y el conocimiento teórico acumulado en él. Así se está construyendo una parte

del saber. Y este conocimiento no es sólo el resultado de la curiosidad, la inquietud, la

inteligencia y actividad de investigación del investigador, sino también la continuación de

lo que se ha preparado y sistematizado referente al tema en trabajos anteriores. [2] en [95].

Se puede decir, en general, que en el método fundamental de investigación es la elección de

procedimientos sistemáticos para llevar a cabo o para describir fenómenos en el mundo.

Ese por su parte es el objeto de conocimiento científico, que tiene elementos que lo

componen y características propias del tiempo y espacio. En otras palabras, el fenómeno es

el hecho, evento, o sujeto a ser estudiado a través de la ejecución de las medidas ordenadas,

la obtención de información, características y peculiaridades de los mismos.

Si damos un vistazo, podemos decir que la investigación tiene como objeto el descubrir

algo, indagar, dar respuesta de manera sistemática a las múltiples preguntas que se hace el

ser humano. Con relación a esto, en este estudio se analizan las diversas definiciones que

proporcionan algunos autores como Garza Mercado Ario quien define a la investigación

como: "... un proceso que mediante la aplicación de métodos científicos, procura obtener

información relevante y fidedigna, para extender, verificar, corregir o aplicar el

conocimiento”. Otros autores afirman que en la actualidad existe en la literatura una gran

variedad de métodos que se puede utilizar en la investigación científica, como los métodos

de investigación cuantitativos y métodos cualitativos. No obstante, cada método tiene

diferentes hipótesis y objetivos, las ideas principales de la investigación cuantitativa son

diferentes las utilizadas en la investigación cualitativa. [40], [2]en [36], [95]



62

Para la contextualización de este capítulo presenta la sección 4.1.1 de las ideas principales

del paradigma cuantitativo y en la sección 4.2 de las principales características del

paradigma cualitativo. Posteriormente, sección 4.3, se presenta una comparación entre las

principales características de métodos cuantitativos y cualitativos.

4.2. Paradigma cuantitativo

El paradigma cuantitativo, más ligado a la perspectiva distributiva de la investigación social

que al resto, básicamente persigue la descripción lo más exacta de lo que ocurre en la

realidad social. Para ello se apoya en las técnicas estadísticas, sobre todo la encuesta y el

análisis de datos secundarios, dado que lo importante es construir un conocimiento lo más

objetivo posible, deslindado de posibles distorsiones de información que puedan generar

los sujetos desde su propia subjetividad. Con este método se permitirá establecer leyes

generales de la conducta humana a partir de la producción de generalizaciones empíricas.

El método cuantitativo además se caracteriza por medir fenómenos utilizando la ya

mencionada estadística y empleando experimentación, el proceso que utiliza para ello

puede ser secuencial o deductivo y presenta dentro de sus bondades la precisión. [41].

El objetivo de este trabajo de investigación es comprender el hoy de la Ingeniería de

Requisitos, la manera “cómo” se está llevando a cabo, “que” desafío y retos enfrenta hoy,

es decir el “As” el estado actual de la ingeniería de requisitos entre las organizaciones que

desarrollan productos de software a medida en Antioquia, además en esta investigación se

expresan situaciones de contexto que llevan al “porqué” se están desarrollando de

determinada forma.

Lo anterior genera un contexto propio del paradigma cualitativo que se presenta a

continuación con sus características.

4.3. Paradigma cualitativo

El método de investigación cualitativa se basa en un análisis de situación de la

investigación compleja, en la búsqueda del conocimiento refinado en cuestiones

particulares, así como el descubrimiento y la investigación de los fenómenos con el fin de

comprender la naturaleza y contexto en el que se insertan [2] en [95] [36] [82] [90].

Este paradigma utiliza la recolección de datos sin medición numérica, evalúa el desarrollo

natural del de los hechos y no requiere ni utiliza hipótesis. Según lo apoya la figura 17.

Paradigma de Investigación.



63

Figura 17. Paradigma de Investigación

En esta investigación el método cualitativo no permitió la formulación de hipótesis con

base en la literatura dado que el método es también influenciado por el conocimiento

teórico, sin embargo, la investigación cualitativa no utiliza teorías como punto de partida,

pero no un estudio empírico basado en “el principio abertura".[2].

De acuerdo con el principio anterior, el investigador debe suspender el conocimiento

Teórico adquirido a priori, para evitar problemas tales como el descubrimiento de cualquier

cosa más allá, así como la falsificación de datos recogidos de acuerdo a las expectativas

esperadas.

Sin embargo cabe señalar también que el aspecto cualitativo de la investigación no se

pierde cuando cierta información se transforma en datos cuantitativos, porque el objetivo

aquí no es promover generalizaciones, pero si tratar de garantizar exactitud de los

resultados [2] en [95].

Ampliando lo anterior el paradigma cualitativo consta de ocho aspectos esenciales: [2] [36]

o Métodos de apropiabilidad y teorías:

Antes de comenzar la búsqueda recomendada para analizar el problema a ser estudiado y

constatar si se pueden ser investigados de acuerdo con los criterios y procedimientos

disponibles por el método de búsqueda. Cada método tiene sus objetivos propios,

procedimientos y herramientas específicas para investigar y su objeto de estudio.

Paradigmas de investigación

Cualitativo

Realidas por interpretar

Realidades subjetivas

Mundos construidos por el investigador

Cambia por observaciones

Cuantitativo

Hay realidad por conocer

Relidad objetiva

Mundo es externo al investigador

las mediciones no cambian



64

En la investigación cualitativa la premisa principal es la búsqueda conocimiento a través

del análisis de las relaciones complejas, mediante el estudio empírico de descubrir nuevos

conceptos y teorías a través del "principio de apertura" y la diversidad de sus instrumentos

(cuestionarios de investigación, entrevistas, grupos de discusión o grupos focal).

Perspectiva de los participantes y su diversidad

¿Por qué hacer frente a relaciones complejas y tener en cuenta el tiempo, lugar, contexto

sobre el objeto de estudio? En la investigación cualitativa se aprecia toda la gama de

información, ya sea: la perspectiva de los participantes (Investigador, observador,

entrevistado, entre otros), las prácticas que se han realizado, así como los significados

subjetivos y sociales que les Relacionados.

La reflectividad del investigador y la investigación

La investigación cualitativa tiene en cuenta las reflexiones del investigador o los que

forman parte de la investigación, así como cualquier campo de interacción, ya sea

investigador o investigador-participante, teniendo en cuenta ambos casos como parte de la

producción de conocimiento.

Variedad de enfoques y métodos de investigación cualitativa

A diferencia de la investigación cuantitativa, que tiene normas obligatorias y conceptos

teóricos y metodológicos unificados en la investigación cualitativa, se puede involucrar

varios enfoques teóricos distintos o no, porque sus métodos tienen razones de las líneas y

las influencias diferente.

Entender como principio epistemológico

Investigación cumplir con el (s) evento objetivo cualitativo (s) estudiado (s) de su

observación y la investigación. Sin embargo, la manera de expresar y entender esta en

términos metodológicos depende de la posición teórica subyacente a la investigación.

Reconstrucción de los casos como punto de partida

Se llama "caso": A cualquier individuo que es parte del estudio, su punto de vista, contexto

en el que se inserta y su interacción con otros individuos. Por lo tanto, antes de la redacción

de declaraciones estudiamos cada caso y más tarde, de la totalidad de la caja se hacen

supuestos estudios

Construcción de la realidad basada

Como se mencionó en el punto anterior, a partir del estudio de casos es posible reconstruir

la realidad estudiada. Se ve así que en realidad no es la investigación cualitativa



65

determinada, pero si reconstruida a partir de los casos, los individuos el contexto, la hora y

el lugar en el que viven.

El texto como empírica

Cuando se realizan estudios de casos, se producen los textos. A partir de estos análisis y

empíricos se pueden hacer interpretaciones. La investigación sobre el objeto de estudio, de

acuerdo con la investigación cualitativa es guiada por los siguientes procedimientos

básicos: técnicas de recolección de datos, recolección, la transcripción y análisis de datos e

interpretación de los datos.

Estos procedimientos pueden ser descritos de forma independiente, pero presentar un orden

en particular. En la práctica, este orden se puede representar a través de un orden lineal o

circular, aunque ambos procesos abarcan todos pasos que guían el método cualitativo. El

proceso difiere de ser lineal o circular para llevar al investigador a reflexionar

constantemente sobre todo el proceso, así como sobre los pasos específicos. Se infiere, por

lo tanto, a que este proceso requiere el uso de más de tiempo que lineal.

Por razones como el tipo de proyecto, el tiempo y la base del estudio, se eligió el modelo

lineal, que se muestra en la Figura 18. Una visión general del proceso de investigación

cualitativa, donde se presentan las secciones parte del proceso de investigación cualitativa.

[2].

Figura 18. Una visión general del proceso de investigación cualitativa

Apoyado en lo anterior se presenta una breve descripción de las actividades llevadas a

cabo en el proceso del modelo lineal.

Por otra parte, al realizar un abstract del paradigma cualitativo se puede decir que es el

enfoque que utiliza la recolección de datos sin medición numérica para descubrir preguntas

Formulación del problema

Tecnicas de recolección de Datos

Recolección de datos

Analisis de datos

Transcripción de datos



66

de investigación partiendo de estudios de caso que parten del investigador o de su

interacción con el campo.

4.4. Formulación del problema

La formulación del problema en este estudio consiste en el análisis de la situación, la

especificación y delimitación del tema que se estudiará, es decir encontrar los elementos

esenciales, partiendo del criterio de que formular un problema es caracterizarlo, definirlo,

enmarcarlo teóricamente, sugerir propuestas de solución para ser demostradas, establecer

unas fuentes de información y unos métodos para recoger y procesar dicha información

bien sea cualitativos o cuantitativos.

Basado en lo anterior aunque la formulación del problema es independiente del método de

investigación, el análisis de la formulación del problema lleva a la elección del método de

investigación, cualitativa por ejemplo en el caso de esta investigación y el análisis del

problema u objeto de estudio demostró una buena comprensión y se comprobó si se

cumplen los supuestos y objetivos, esto determinó la adecuación del método estudio del

fenómeno o tema a estudiar. Lo anterior en contraste con la investigación cuantitativa que

genera comprobación a teorías.

4.5. Técnicas de recolección de datos

Esta es la actividad que sirve como estrategia para alcanzar el objetivo, a continuación se

describe los instrumentos utilizados para la obtención de los datos.

En las investigaciones se utilizan varias técnicas para la obtención de datos tales como:

Entrevistas, encuestas, observación y secciones grupales. El método cualitativo de esta

investigación condujo a la utilización de los siguientes instrumentos:

4.5.1. Encuestas

La función de una encuesta es obtener información definida, esta abarca el estudio del

universo o contexto. Para este estudio la encuesta permitió conocer aspectos generales de

las empresas, describiendo aspectos como: Datos del encuestado y datos de la Organización

(nombre, dirección web, teléfonos, etc.)

Además y con el objetivo de contextualizar los empleado adscritos al procesos de

desarrollo software se solicitaron datos dentro de la encuesta como: las certificaciones, sus

niveles de inglés, tiempo de prevalencia en las organizaciones y roles entre otros.



67

Por otro lado, se requirió información respecto a estrategias, metas y necesidades de

capacitación por parte de las organizaciones y de estas, sus nichos de mercado, metodología

de desarrollo utilizadas, tipos de desarrollo que son su fortaleza y tipos de clientes.

Referente al proceso de desarrollo software con este instrumento encuesta se obtuvieron

datos referentes a niveles de satisfacción de los clientes en las diferentes etapas del proceso

de desarrollo software, formas de contratación modo de incorporación de la Ingeniería de

Requisitos en el proceso de desarrollo software [38].

Es necesario aclarar que no hay reglas claras en cuanto a planificación de cuestionarios. Por

lo tanto, es responsabilidad del investigador determinar el tamaño, la naturaleza y el

contenido del instrumento. [2] en [95]

Las encuestas se pueden clasificar de dos formas: por el tipo de pregunta de los encuestados

(preguntas cerradas, abiertas o una combinación de ambos) y el modo de aplicación de la

encuesta (contacto directo o cuestionario enviada por correo).

En cuanto a los instrumentos con preguntas cerradas son aquellas con categorías o las

opciones de respuesta fija y predeterminada. Hay varios tipos de preguntas cerradas, las

más utilizados son las preguntas con alternativas dicotómica (es decir sí o no, verdadero o

falso), y preguntas con respuestas múltiples (por ejemplo, a menudo, a veces, nunca). Entre

las ventajas de utilizar Las preguntas cerradas son las formas rápidas para el llenado del

cuestionario y codificación de datos (análisis e interpretación de datos). Sin embargo, hay

desventajas, tales como la limitación de las respuestas del entrevistado y la falta de la

respuesta de control (por ejemplo, el entrevistado puede señalar al azar respuestas con el

objetivo de terminar rápidamente el cuestionario).

A su vez las encuestas con preguntas abiertas, son aquellas en las que el encuestado debe

responder a las preguntas que hacen uso de frases y oraciones, es decir, el objetivo es que el

entrevistado exprese su opinión o punto de vista, en lugar de que su respuesta sea directa y

predefinido. La gran ventaja de la utilización de preguntas abiertas es permitir al

entrevistado exponer su opinión o punto de vista. Sin embargo, hay desventajas como la

dificultad de la clasificación y codificación de las respuestas y el tiempo requerido al ser

contestadas.

Para este estudio sin embargo, se tuvo en cuenta que cada una de las preguntas del

instrumento apoyara en el objetivo de la investigación, además como es típico de los

investigadores, se tuvo en cuenta el uso de ambos tipos de preguntas, el cuestionario que

brinda la información y tiende a preguntas fijas, y la profundidad de búsqueda o punto de

vista acerca de la entrevistados con preguntas abiertas.

En cuanto a la forma de aplicación de una encuesta se puede decirse que:

o Una manera es en contacto directo con el encuestado y otra el envío del cuestionario por correo, este estudio utilizó las dos maneras ya que se contactó al encuestado, se



68

contextualizó del estudio y posteriormente se envió el instrumento, que de ser necesario

sería retroalimentado por el encuestador en referencia a preguntas o necesidad de

expresar puntos de vista, para posteriormente recibir el instrumento en la organización

al momento de aplicar la entrevista.

Referente a las ventajas y desventajas de una encuesta la Figura 19. Encuesta, señala

claramente cada una.

Figura 19. Encuesta

4.5.2. Entrevista Semi-Estructurada

La entrevista, desde un punto de vista general, es una forma específica de interacción

social. El investigador se sitúa frente al investigado y le formula preguntas, a partir de

cuyas respuestas habrán de surgir los datos de interés. Se establece así un diálogo, pero un

Desventajas

Planteamiento cokmplejo en concenso

Requiere para su diseño de profesionales

Hay un mayor riesgo de sesgo muestral

Ventajas

Bajo costo

Información más exacta

(mejor calidad,

selectiva)

Rapidez enlos

resultados

Permite obtener

información de cualquier

tipo de población.

Permite obtener

información sobre hechos pasados de

encuestados.

Gran capacidad

para estandarizar

datos

Permite su tratamiento

informático y el análisis

estadístico.

Relativamente barata para

la información

que se obtiene con

ello.

Conocer el copntexto de

la investigación



69

diálogo peculiar, asimétrico, donde una de las partes busca recoger informaciones y la otra

se nos presenta como fuente de estas informaciones.

Dentro de las características deseables de una entrevista están:

o Ambiente personas y diálogo

o Saber identificar la persona con quien nos entrevistamos y dominar el diálogo.

o Utilizar el método impresionista como una visión instantánea en la que se recogen aquellos rasgos y detalles que destacan del conjunto

o Generar diálogo sincero

o Hacer que el entrevistado se sienta cómodo

o Permitir la expresión de ideas propias del entrevistado

Teniendo en cuenta que es la entrevista semi-estructurada la utilizada en este estudio puesto

que la estructurada es donde investigador planifica previamente las preguntas mediante un

guion preestablecido, secuenciado y dirigido, por lo que dejan poca o ninguna posibilidad

al entrevistado de réplica o de salirse del guion, utilizando preguntas cerradas (si, no o una

respuesta predeterminada). Mientras que la entrevista semi-estructurada determina de

antemano, cual es la información relevante que se quiere conseguir, se hacen preguntas

abiertas dando oportunidad a recibir más matices de la respuesta, permite ir entrelazando

temas, pero requiere de una gran atención por parte del investigador para poder encauzar y

estirar los temas. El investigador tiene como referentes la información sobre el tema, la

entrevista se va construyendo a medida que avanza y con las respuestas que se dan.

Requiere de gran preparación por parte de investigador, documentándose previamente

sobre todo lo que concierne a los temas que se tratan.

La Figura 20. Tipos de Entrevista semi-estructurada. Adaptada de [2] en [36] señala

algunos de los distintos prototipos de entrevista semi-estructurada.



70

Figura 20. Tipos de Entrevista semi-estructurada. Adaptada de [2] en [36]

En las entrevistas semi-estructuradas se pueden enumerar algunos aspectos importantes que

a tenerse en cuenta cuando se utiliza tal instrumento de investigación. La Figura 21.

Entrevista Semi-estructurada.

Figura 21. Entrevista Semi-estructurada.

4.5.3. Grupo de Discusión

Entr

evi

sta

foca

l •Después de enviar un vídeo, un documento, un sistema o un problema, se busca información entrevistado acerca de lo que se presentó.

Entr

evi

sta

Sem

i-n

orm

aliz

ado

•Se busca el usuario conocimiento genérico acerca de un tema o en la estructuración determinado medio ambiente.

Entr

evi

stas

se

mi-

est

and

ariz

adas

•Pueden ser complementada por técnicas de presentación gráfica para la validación comunicativa

Entr

evi

sta

Etn

ogr

áfic

a

•Técnica utilizada para la observación obtención de información adicional por parte del usuario durante la ejecución sus tareas o actividades.

• Ninguna dirección

•Tenga cuidado de que la referencia investigador no se impone a los puntos de vista del demandado;

• Cubrir todo el espectro de la Guía

•Asegúrese de que todos los aspectos y temas relacionados con el tema u objeto de estudio son dirigida, así como dar la oportunidad a la parte demandada para insertar temas propias y nuevas entrevistas

• El mantenimiento de la pertinencia y profundidad

•Reorientar involucrados o demandado cuando no está cubriendo un tema pertinente.



71

En este estudio las entrevistas se realizaron a pequeños grupos de personas cuando la

organización destinaba para ello diferentes roles o grupos de personas que ejecutan el

mismo rol. El empleo de dinámicas de grupo se utilizó para discutir un tema en particular,

que en una entrevista semi-estructurada. A esta técnica se le denomina entrevista grupal, la

que se aplicó con pocas preguntas y el empleo de grabaciones para evitar obviar las

observaciones de los participantes. Para la obtención de la información y propiciar la

discusión con las entrevistas se puede utilizar dos tipos de técnicas diferentes: entrevistas

grupales y grupos de discusión. [1] en [36]

Las entrevistas en grupo deben aplicarse cuando se trata de una pequeño grupo de

personas, lo que propiciará los debates sobre un tema específico. En esta técnica, el

entrevistador debe desempeñar el papel de mediador entre participantes o entrevistados, así

como fomentar la participación de los miembros pocos involucrados con la discusión. El

entrevistador debe saber buscar el equilibrio y cumplir con el objetivo de enfocar la

información sobre un tema y no generar una discusión alrededor de un problema.

Las discusiones en grupo, son una forma de actividad mediadora para construir

conocimiento compartido que logre una visión común y debe tenerse un entrevistador que

puede moderar de tres formas:

Targeting formal - El moderador se limita al control de programar de oradores y

determinar el inicio y el final discusión;

Dirección Tema - El moderador realiza preguntas como una forma de dirigir el curso de la

discusión

Dirección de la dinámica de la interacción - Se aplica el moderador preguntas

provocativas con el fin de polarizar una discusión o cabida a las relaciones de dominación.

Puede ser presentando documentos, gráficos y prototipos como estimuladores. Con el fin de

facilitar la comprensión de las discusiones de grupo, pueden figurar los siguientes pasos:

1. La discusión de grupo comienza con la explicación de los procedimientos y las

mismas metas. Para este estudio se envió una invitación y un documento de breve

contextualización.

2. Breve presentación de cada miembro

3. El facilitador debe generar sensación de grupo

4. La discusión comienza con un estímulo, que puede ser anuncio el problema o la

demostración de un sistema

5. Luego se espera que ocurra el curso de la discusión: fases del interrogatorio,

orientación, adaptación alterna, familiarización y el cumplimiento

6. Tema o tiempo agotamiento

7. Programar otra reunión si es necesario.

Problemas que se presentan con respecto al uso de las discusiones en grupo:



72

Dificultad para hacer un pronóstico de cómo será la discusión que se lleva a cabo

No existen criterios claros de si un grupo ha agotado o no discusión del problema

Dificultad para estimular involucrados mientras dirigir la reunión

Puede ser difícil programar un tiempo que todo el mundo puede participar.

4.5.4. Observación y Etnográfica

La observación directa del fenómeno en estudio es una técnica cualitativa y objetiva de

recolección; con ella puede obtenerse información aun cuando no exista el deseo de

proporcionarla y es independiente de la capacidad y veracidad de las personas a estudiar;

por otra parte como los hechos se estudian sin intermediarios, se evitan distorsiones, sin

embargo desde cuidarse el entrenamiento del observador para que la observación tenga

validez científica.

Dentro de la observación se presentan modalidades como:

Según los medios utilizados o clasificación o Observación estructurada: Es donde se observan los hechos, estableciendo de

antemano que aspectos hay que estudiar

o Observación No estructurada: Consiste en recoger y anotar todos los hechos

que suceden en determinado momento sin poseer guía de lo que se va a observar

Según el papel o modo de la participación del observador: o Observación participante: Participación directa del observador con la

comunidad, el grupo o la situación determinada.

o Observación no participante: El observador permanece ajeno a la situación que

observa

Según el número de observadores o Individual: Es la que realiza una sola persona y el investigador debe centrarse en

lo que observa.

o Colectiva: Todos pueden observar lo mismo o cosas diferentes.

Según el lugar donde se realiza:

o Campo: Los hechos se captan tal como se realizan.

o Laboratorio: Con carácter experimental, es la observación minuciosa y detallada

de un fenómeno en un sitio previsto para la observación.

Ventajas o Los hechos se estudian sin intermediarios.

o Se obtiene información independiente del deseo que tengan los sujetos de

proporcionarla

o Los fenómenos se estudian en el momento en que ocurren.

o Es independiente de la capacidad que tenga la persona de suministrar la

información.

o No depende de la memoria.

Desventajas



73

o No sirve para estudiar muestras grandes.

o Técnica costosa, requiere personas altamente entrenadas que empleen su parte

visual, auditiva, tacto y olfato.

o No brinda información de acontecimientos pasados ni futuros.

o Si la persona se siente observada puede cambiar la conducta habitual.

o El procesamiento de resultados tan variados resulta de difícil cuantificación.

4.5.5. Pre-Testing

Algunos investigadores recomiendan realizar pruebas previas o testes piloto al instrumento

de la encuesta. Tal actividad implica la aplicación de un número reducido de los elementos

del instrumento que tienen las mismas características que los elementos seleccionados de la

muestra y no se pueden utilizar elementos pertenecientes a la muestra específica para el

estudio. Según [1] en [95].

En concordancia con [1] este estudio se establece que es responsabilidad del investigador

elegir para analizar el problema a ser estudiado y su adecuación a las técnicas especificadas

por el método de investigación con el objetivo de determinar qué técnicas de recopilación

de datos son más apropiadas.

4.5.6. Recopilación de datos

La elección del método depende de la estrategia de recopilación de datos, el tipo de

variable, la precisión necesaria del dato, además de los vínculos entre una variable, su

origen y los métodos prácticos para su recopilación adoptados por el elicitador.

Habría que decir también que la recolección de datos incluye el acceso al campo,

(entendiéndose por campo según una institución, una sub-cultura, una familia, un grupo

específico de personas, quienes toman las decisiones en las organizaciones), el estudio tiene

como fin, especificar el tipo de compromiso entre el entrevistado y el investigador para

definir las funciones que el investigador debe tener para entrar en el tema de estudio, así

como la realización efectiva recolección datos. [1], en [36].

La entrada del campo es uno de los temas más importantes en la investigación cualitativa.

Se podría decir que esta importancia se debe a aspectos de la investigación cualitativa

esencialmente (adecuación de los métodos y teorías, la perspectiva de los participantes y su

diversidad, la reflexividad del investigador y la investigación, variedad de enfoques y

métodos, la comprensión con el principio epistemológico, caso la reconstrucción como

punto de partida, la construcción de la realidad como base) discutido en la sección 4.2, así

como los problemas que enfrentan comúnmente como la garantía de los participantes y la

colaboración, la disponibilidad material de demostración y el acceso a las personas y la

información relevante para el estudio.

En algún momento, estos problemas están relacionados con el tipo de papel, la habilidad

comunicativa y la posición adoptada o designada por el investigador, ya que el acceso o



74

eliminar cierta información depende esencialmente de la adopción de roles y postura

adecuada (por ejemplo, un investigador particular podrá adoptar el papel moderador en una

discusión de grupo y sus puntos de vista no debe imponerse en el entrevistado) o asumir y

asignar un papel, o la postura debe ser visto como un proceso de negociación entre los

participantes (personas a entrevistar, y si la encuesta se llevó a cabo en una organización,

también se refiere a los que han de permitir o facilitar el acceso) [2] en [36].

En la recolección de datos es importante evitar errores en el entrevistador como: hacerse un

juicio positivo o negativo del entrevistado, generar ideas preconcebidas o prejuicios,

dejarse llevar por el tipo de experiencia que tiene el candidato sobre el trabajo en cuestión,

tener tendencia a comparar características del candidato con las suyas propias o con las de

personas conocidas, evitar preguntas incomprensibles.

Respecto al acceso a las instituciones se realizó de manera directa visitando y o contactando

telefónicamente cada organización, este estudio tuvo además muy presente el tema de

gobierno institucional previendo situaciones como: los niveles de confidencialidad de las

organizaciones, y los diferentes temas de regulación del acceso y dedicación de tiempo y

recursos de los entrevistados. [1] en [36], llama a esto relación cliente usuario.

A este respecto este estudio se contactó con las personas encargadas del gobierno directo de

las organizaciones y se les contextualizó respecto a los beneficios y aportes que requería y

generaba el estudio, en cuanto a tiempo y recursos institucionales. Partiendo de la base del

interés y compromiso de estas personas se recibió la lista de asignados por cada

organización y sus datos para enviarles la información y concertar las citas. De esta manera

el problema de disponibilidad presente en la recolección de datos fue minimizado.

4.5.7. Datos de transcripción

Al proceso de recopilación y organización de datos con objeto de identificar tendencias y

patrones se le denomina transcripción y análisis de datos. El análisis de datos consiste en la

realización de las operaciones a las que el investigador somete los datos con la finalidad de

alcanzar los objetivos del estudio. Teniendo en cuenta que no todas estas operaciones

pueden definirse de antemano, de manera rígida la recolección de datos y ciertos análisis

preliminares pueden revelar problemas y dificultades que des actualizarán la planificación

inicial del análisis de los datos.

Sin embargo, en este estudio se proyectaron los principales aspectos del plan de análisis en

función de la verificación de cada una de las hipótesis formuladas ya que estas definiciones

condicionaron a su vez la fase de recolección de datos, que se almacenaron en grabaciones

y textos para su posterior análisis.

Entendiéndose que el proceso de textos de investigación cualitativa sirven para dos

propósitos: el primero para representar no sólo los datos esenciales que son la base de

descubrimientos, sino también la base para la realización de las interpretaciones y el

segundo para la presentación y comunicación de lo que es posible descubrir. [2] [36].



75

4.5.8. Análisis e Interpretación de los Datos

Dentro de las técnicas de análisis de datos que existen están, las técnicas cualitativas en las

que los datos son presentados de manera verbal con grabaciones y con notas en

documentos. Y técnicas cuantitativas en las que los datos son presentados de manera

numérica. En ambos casos el análisis y la interpretación de datos tienen diferente manejo.

Como en el análisis cualitativo no existen reglas formales se realizó para este estudio una

descripción del material en bruto, se evaluaron y redujeron los datos y se analizaron Así:

1. Se conoció la trazabilidad y existencia de la información

2. Se despejaron componentes o variables de interés para la investigación con

resúmenes para reducir la masa de la información y codificación que atribuyó

categorías la material.

3. Se aplicó el método de análisis por emparejamiento que analiza casos, el método

teórico y construcción progresiva de una explicación iterativo de abordaje de los

datos con mínima formalización

4. Se verificó la réplica de resultados con un análisis transversal.

Para la parte del análisis cuantitativo de esta investigación se realizó un ligado a las

hipótesis donde cada una de ellas, planteadas en el estudio fue objeto de verificación,

apoyada en los datos recogidos. Las demás técnicas existentes de análisis de datos no se

abordaron en esta tesis por estar fuera del alcance de los trabajos.

4.5.9. Teoría de Códigos

Para este estudio, la interpretación de los datos es considera dependiente de la recogida y

muestreo de material, y es el ancla para las decisiones sobre qué datos o casos serán los

próximos en ser analizados y qué métodos deben utilizarse para recogerlos. [2] en [36].

En la teoría de la codificación, se puede decir que hay varias etapas de interpretación:

codificación abierta, codificación axial y codificación selectiva. Es decir que el proceso de

interpretación comienza con la codificación abrir y cuando nos acercamos a la culminación

del proceso de análisis da lugar la codificación selectiva.

Entendido como codificación una representación de las operaciones para que los datos

que están fragmentados, conceptualizados y en conjunto reincorporen nuevas formas [2]

en [36]. Además de acuerdo con esta comprensión, la codificación consiste en una

comparación constante de los fenómenos, conceptos y casos, la formulación de preguntas

basados en el material textual y el uso del proceso de abstracción para el desarrollo teorías.

Habrá objetivos de codificación para expresar datos y fenómenos en forma de conceptos o

definiciones. Inicialmente, un fragmento de material textual (una entrevista, por ejemplo)

está fragmentada (una sola palabra, secuencias cortas de palabras) de barras y un número



76

superíndice. Después de la segmentación texto, cada número se refiere a un título, notas y

que puede representar, sobre todo, los "conceptos" (códigos).

Como resultado de esta codificación, hay cientos de veces códigos. A su vez, el siguiente

paso clasifica estos códigos agrupándolos entorno a los fenómenos descubiertos en los

datos que son particularmente relevantes para pregunta de investigación. Por lo tanto, estas

categorías se relacionan con los códigos, sin embargo, estos son más abstractos que los

utilizados inicialmente y debe representar los contenidos de una categoría notablemente.

En el caso del código abierto, pueden hacer uso de los diversos grados de detalle. El texto

puede ser codificado línea por línea, frase por frase o párrafo por párrafo, se puede conectar

a textos enteros (un protocolo, un caso, etc.). Lo que define el uso de una u otra alternativa

es la pregunta de investigación, el material, el estilo personal el investigador y la fase de la

investigación a la que se ha llegado. Vale la pena señalar también que el uso de este tipo de

clasificación es adecuado para las piezas específicas del texto, por objetivo es contribuir a

la comprensión de la materia cuando se presenta pasajes oscuros. Por encima de todo, el

punto más importante de este tipo de codificación no se pierde el objetivo principal, que es

la fragmentación y entender un texto y añadir y desarrollar categorías, colocarlos en un

orden cronológico.

El resultado de codificación abierta es una lista de códigos y categorías que se han añadido

al texto. Dicha lista también contendrá subtítulos con el objetivo de explicar y definir el

contenido de los códigos y categorías, así como notas con observaciones sobre el material y

los pensamientos relevantes para el desarrollo de la teoría. La codificación axial es para

mejorar y diferenciar las diversas categorías resultantes de la codificación abierta. Para

esto, las categorías consideradas más prometedoras se enriquecen según la mayor cantidad

de piezas encontradas. Para mejorar aún más, estas categorías están sujetas a las

comparaciones.

Por último, establecer relaciones entre estas categorías y otras, así poder establecer o

aclarar la relación entre las categorías y subcategorías. De acuerdo con [2] en [36], "el

investigador se mueve continuamente de un lado a vuelta entre el pensamiento inductivo (el

desarrollo de conceptos, categorías y relaciones del texto) y el pensamiento deductivo

(conceptos de pruebas, categorías y relaciones en oposición al texto, especialmente las

partes que son diferentes casos o aquellas de las que se han desarrollado)". Se puede

resumir la codificación axial como el proceso de relación de subcategorías en una categoría.

Este es un proceso de pensamiento inductivo y deductivo de varios pasos, que se celebran a

las comparaciones y preguntas. La codificación selectiva continúa imponiendo una

codificación axial un mayor nivel de abstracción. El objetivo de este paso es el desarrollo

de la categoría esencial en alrededor del cual otras categorías pueden agruparse y

desarrollados por la que se integran. En este punto, se entiende que el foco está en un caso

en lugar de en una persona o entrevista.

En caso de seguir, se debe ofrecer una visión general (descriptiva) histórica, donde el

análisis va más allá del nivel descriptivo debido a elaboración de la línea de la “historia



77

reúne a un concepto central para el fenómeno de la historia, relacionándolo con otras

categorías"[36]. El análisis y el desarrollo de objetivo es la teoría para descubrir patrones

en los datos, así como las condiciones bajo las cuales éstas se aplican.

En el procedimiento de interpretación de los datos, así como en la integración del material

adicional se incluye como premisa que se ha alcanzado la saturación teórica, cuando nada

nuevo se puede añadir a lo que está.

En la siguiente sección se presentarán los principales aspectos relacionados con la otra

técnica para el análisis e interpretación de datos como los números de codificación que

flexibiliza la utilización de los mismos textos y códigos con un tema diferente y que

aportan a otra materia.

4.5.10. Codificación temática

Según [2] en [36], la codificación del tema es desarrollada para estudios comparativos

donde los grupos definen y priorizan basado en la teoría o asunto investigación y donde el

objeto de investigación es la distribución de perspectivas sobre un fenómeno o proceso.

Las premisas son aquellas que en -mundos o en diferentes grupos- pueden ser encontradas

con visiones distintas. Para evaluar esta hipótesis y desarrollar unas características teóricas

de cada grupo, pueden ser necesarias de hecho comparaciones del material empírico. Para

que esto sea posible, el muestreo es específico a los grupos en los que los puntos de vista

sobre el tema parecen ser instructivo de revisión, es decir, grupos en los que se puede

comprar conocimiento sobre el objeto de estudio.

Un punto importante a tener en cuenta es que la elección de una u otra técnica de

recolección de datos debe garantizar el objetivo principal es decir una comparación casos.

Un ejemplo de herramientas de recogida de datos que se pueden utilizar sería las entrevistas

episódicas y entrevistas semi-estructuradas.

El análisis de textos en codificación temática, es para codificar las declaraciones y relatos

en categorías, desarrollados a partir de los datos empíricos con el fin de verificar las

diferencias y similitudes encontradas entre los grupos definido.

La interpretación se divide en varias etapas, a saber:

o Los casos en cuestión se analizaron de acuerdo a un número de estudios de caso

o Cada caso se analiza en detalle y se sugiere una orientación para guiar este análisis

[2] en [36]

o Tras la finalización del análisis individual de todos los casos, que formarán parte de

los resultados, y cualquier posible revisiones

o Por lo tanto, se trata de un análisis en profundidad de un caso se desarrolla un

sistema de categorías, utilizando codificación abierta y selectiva, donde se pretende



78

generar categorías temáticas que el único caso, en lugar del desarrollo de una

categoría esencial a tierra en todos los casos que se trate

o Después de analizar el primer caso, las categorías desarrolladas y áreas temáticas a

los casos individuales son cuidadosamente facturados. Esta revisión tiene como

resultado una estructura temática. Este estructura puede cambiar a medida que

nuevos aspectos o contradictorias surgen y se utiliza en el análisis de todos los casos

que forman parte de la interpretación

o El resultado del proceso es una exposición de los aspectos el caso, incluyendo los

temas que se pueden identificar en diferentes puntos de vista. La estructura temática

servirá como parámetro para la comparación de los casos y los segundos grupos

diferencias y similitudes encontradas.

Por último, se concluye que este procedimiento es adecuado para los estudios que

involucran las comparaciones entre los grupos definidos de antemano y cuya emisión la

investigación es específica. En la siguiente sección se analizan los principales aspectos

relacionados con la otra técnica para el análisis e interpretación de datos: un análisis

cualitativo.

4.5.11. Análisis cualitativo de contenido

El despliegue de técnicas de análisis cualitativo, que apuntan a la lógica de producción y

análisis de información textual y su interpretación, requiere luego de un adecuado proceso

de organización. No existe una única forma de análisis cualitativo. Las técnicas de análisis

dependen del tipo de técnica empleada y ciertamente, del tipo de "dato" obtenido el cual

debe lograrse reducir para una mayor comprensión.

Se reconocen varias prácticas analíticas. Semántica-estructurales: estas son de mayor

reconocimiento por ser más auditables, las semiológicas que son de reconocida utilidad

interpretativa en diversas disciplinas científicas y las de triangulación hermenéutica que son

más ambiguas y artesanales, de menor uso por su escaso nivel de auditabilidad. Cada una

de éstas supone un nivel de organización y reducción de datos dependiendo del tipo de

información procesada.

Para realizar el análisis cualitativo del contenido se debe considerar que dados los datos en

texto o audio se requiere habilidad especial del investigador quien debe reconocer un

proceso común.

Teniendo en cuenta que el dato cualitativo encierra las interacciones de los sujetos entre sí,

con el investigador y con el entorno, éste debe ser un conjunto de manipulaciones,

transformaciones y operaciones realizadas sobre los datos con el fin de extraer significados

que permitan comprender la situación del objeto de estudio. Con el análisis se generan

modelos interpretativos conceptuales o analíticos que aportan ilustraciones de la realidad.

Se presentan en este contexto algunas dificultades como: la cantidad de datos, carácter

polisémico, falta de definición de la estrategia de análisis, dudas en la credibilidad.



79

Por otra parte es sabido que el análisis cualitativo tiene dos enfoques: inductivo, teoría

fundamentada y deductivo etnográfico, por tanto no hay un modo único de realizar análisis,

pero si existen algunas tareas necesarias como la descripción del texto, la reducción de

datos, la categorización de unidades, la codificación y el nombramiento a cada

categorización.

Se citan a continuación una serie de pasos para el análisis cualitativo. Donde se detallan

estos para una mejor comprensión y desarrollo del contenido del análisis cualitativo. Según

la Figura 22. Pasos para análisis cualitativo, basada en [2].

Figura 22. Pasos para el Análisis Cualitativo.

Las técnicas de análisis que se pueden utilizar en el análisis cualitativo los contenidos son:

o Análisis de Corto el contenido: en esta técnica, el material es parafraseado, donde

extractos y paráfrasis con significados similares están omiten y paráfrasis como se

condensan y se resumen.

o Análisis de contenido explicativo: esta técnica trabaja a la inversa de la técnica

anterior, es decir, que tiene como objetivo aclarar pasajes difusos, ambiguos o

contradictorios, con la participación material del contexto en el análisis. Los

Primer Paso

•Básicamente, para definir el material, seleccione entrevistas o grupos considerados relevantes solución de la investigación.

Segundo paso

•Analizar la situación de la recolección de datos (Debido a que se recogieron los datos, quien participó en la actividad colección, los participantes que participaron en la entrevista entre otros);

Tercer paso

•La caracterización formal de los materiales, o Es decir, tal como se documenta y material editado;

Cuarto paso

•Configurar la dirección del análisis de los textos seleccionado y "lo que realmente se espera de interpretarlos" (la pregunta de investigación).

Quinto paso

•La pregunta de investigación se diferencia en base a teorías y se establece entonces una de las tres técnicas de análisis (Estos serán discutidos más abajo)

Último paso

•Definir las unidades de análisis: la unidad codificación que es el elemento más pequeño que el material que puede ser el análisis de la unidad contextual que es el mayor factor que puede ser categorizada y finalmente, la unidad analítica que define la secuencia de pasajes de texto.



80

diccionarios se utilizan para definir conceptos y la gramática se utiliza para formular

definiciones.

o Análisis del contexto: Explicar la sección a analizar en un contexto más amplio, que

busca información fuera del texto básico inicial y a partir de ahí formula pruebas, es

decir, son una "paráfrasis explicativa", con contenido de estructuración. El análisis de

esta técnica busca tipos o estructuras formales en la materia.

4.6. Comparación de las características principales del método Cualitativa

y Cuantitativa

En las Figuras [23], [24] y [25]. Fases de los Enfoques Cualitativo y cuantitativo,

Características de los Métodos Cualitativo, Cuantitativo y Comparativo entre los modelos

cuantitativo y cualitativo, respectivamente, se aprecian los beneficios de cada uno y las

características que presentan. Lo que lleva a la conclusión que la elección del método

puede ser cualitativa o cuantitativa porque finalmente depende del objetivo que el estudio

pretenda alcanzar.

Para este estudio y el método cuantitativo solo, no sería adecuado para el establecimiento

de la muestra a estudiar que debe ser determinado no solo por la relevancia

representatividad sino que debe ser dirigido principalmente al método cualitativo para la

generación de la información recogida.



81

Figura 23. Fases de los Enfoques Cualitativo y cuantitativo

Ben

efic

ios

de

los

enfo

qu

es

Cualitativo

Resultados generales

Resultados replicables

Puntos especificos

Facil comparación

Control de datos

Cuantitativo

Profundidad de los datos

Riqueza interpretativa

Contextualización

Flexibilidad

Propio punto de vista

obtension de detalles



82

Figura 24. Características de los Métodos Cualitativo y Cuantitativo

Figura 25. Comparativo entre los modelos cuantitativo y cualitativo.

Idea

Planteamiento del Problema

Revisión de la literatura

Visualización del estudio

Elaboración de hipótess

Desarrollo del diseño de la investigación

Definición y selección de la miestra


Análisis de datos

Elaboración de reporte de resultados

Cuantitativo Idea

Planteamiento del problema

Inmersión inicial en el campo

Concepción del diseño del estudio

Dificinión de la muestra inicial y acceso a esta


Análisis de datos

Interpretación de resultados

Elaboración de reporte final

Cualitativo

Mét

od

o C

ual

itat

ivo

•Punto de partida estudio empirico

•Hipotesis formualdas con conocimiento adquirido o influenciadas por la teoría

•Se pregunta: "porqué", "quien" y "Cómo"

•Selecciona el objeto de estudio y determina su relevancia

•Se puede ser parte del proceso

•Analisa las relaciones complejas y considera el contexto

•Los datos se pueden analizar utilzando diferentes métidos

• la valides del estudio tiene que ver con determinar si los resultados se basan en material empirico solido y los métodos fueron debidamente seleccionados y aplicados al objeto de estudio Mét

od

o C

uan

tita

tivo

•Punto de partida teorías preexistentes

•Hopotesis formuladas con base en el conocimiento teórico

•Se pregunta que es?

•Selecciona el objeto de estudio y determina su representatividad

• intenta que el investigador no influye en el proceso de investigación

•Las declaraciones de caracter general y las relaciones complejas se fragmentan en variables únicas

•Analiza los datos con el uso de técnicas estadisticas

•La validez del estudio se relaciona con las hipotesis formuladas y hacer uso de las teorías existentes, aclarando las razones preexistentes



83

4.7. Final

En este capítulo se presentaron los fundamentos de la metodología de investigación, así

como una breve descripción del paradigma cuantitativo desde el punto de vista de este

estudio y en concordancia con el de base en [2].

La investigación se basa en el paradigma cualitativo del que se presentó un panorama

general, algunos conceptos, actividades, técnicas que se pueden utilizar cuando se adopta

este enfoque como método de investigación, así como su esencial (idoneidad de los

métodos y teorías, perspectiva de los participantes y su diversidad, la reflexividad del

investigador e investigación, una variedad de enfoques y métodos, la comprensión en

principio de casos de reconstrucción epistemológica como punto de partida, la construcción

de la realidad como base).

También se presentaron algunas actividades del paradigma cualitativo: Técnicas para la

recolección de datos, recolección de datos, las pruebas previas, la transcripción de los datos

y análisis e interpretación de datos.

Entre las técnicas de recolección de datos fueron discutidos los cuestionarios, entrevistas

semi-estructuradas, grupos de discusión, observación y la etnografía.

Para el análisis e interpretación de los datos se propusieron estrategias para la

categorización de datos como la codificación teórica, codificación y temáticos del análisis

cualitativo.

Dado que el propósito de este estudio es de carácter exploratorio, -es decir, cuando no se

tiene información sobre un tema determinado y quieren saber el fenómeno- se encontró

información a partir de las características que se indican en el paradigma cualitativo, a

través de la adecuación del método a la investigación empírica. Por lo tanto, el enfoque

cualitativo como metodología de la investigación, se utilizará como estudio empírico, que

se presenta en el capítulo siguiente con las fases de definición, planificación y ejecución del

estudio.

La adecuación de la propuesta se centra en las características del paradigma cualitativo. La

Elección del método se basó en la comprensión del problema y en el conocimiento de

aspectos relevantes relacionados con estos métodos de Investigación cualitativa y

cuantitativa, de manera que condujo a la realización de una investigación exploratoria, la

perspectiva como en la muestra se convertiría en su mayor parte en forma de generalizables

logrando resultados.



84

5. CAPÍTULO PRESENTACIÓN DEL ESTUDIO EMPÍRICO

Este capítulo de la tesis presenta las actividades de la definición, planificación y realización

del estudio empírico realizado entre las empresas que desarrollan productos de software en

el país.

Lo anterior tomando en cuenta los muchos desafíos y problemas que enfrentan las pequeñas

y medianas, empresas de Software a la medida con respecto a cómo generar productos de

calidad dando cumplimiento al cliente, entregando los productos a tiempo y con el

acatamiento adecuado de los requisitos que generan valor, se decide iniciar este estudio que

fue motivado por el proyecto WEST (IDEAS 2004), quien incluyó dentro de sus tareas la

implementación de una nueva metodología de Ingeniería de Requisitos en la industria

colombiana [2]. En este contexto se han desarrollados varias investigaciones en diferentes

regiones del mundo, esta investigación se apoya en los lineamientos seguidos por la tesis

doctoral realizada en Pernambuco Brasil [1], y se tiene como fin encontrar las mejores

prácticas, retos y desafíos que enfrentan las empresas que desarrollan productos de software

a medida en el departamento de Antioquia, considerando específicamente la Ingeniería de

Requisitos. Para ello se analizan aspectos como: el proceso en sí, la metodología utilizada,

las herramientas de apoyo y las mejores prácticas [49].

La adecuación para la propuesta del estudio se fundamentó en las características del

enfoque del paradigma cualitativo. La elección del método se basó en la comprensión del

problema y en el conocimiento de aspectos relevantes relacionados con los métodos de

investigación cualitativa y cuantitativa, lo que condujo a la ejecución de una investigación

exploratoria dado que en perspectiva la muestra no sería suficiente como para lograr

resultados generalizables. La demostración de este enfoque se sustenta a lo largo de este

estudio en los apartes: Apartes 5.2. Planteamiento del estudio, 5.3. Finalización del estudio

y 5.4. Observaciones finales.

5.1. Definición del Estudio

Definición de este estudio: Incluye la especificación de aspectos como la motivación, el

objeto de estudio, la propuesta, perspectiva y el alcance del área de estudio. A continuación

se define cada uno de los aspectos.

Motivación del estudio: Desde hace varios años se ha reconocido la importancia que para

el desarrollo de software tiene el proceso de Ingeniería de Requisitos. Sin embargo, no se

han realizado investigaciones que permita a la comunidad del software conocer el estado

actual del proceso al interior de las empresas, es decir, el “cómo vamos” en el proceso, las

experiencias y retos, en que apoyar la realización del mismo, ni existen unas buenas

prácticas registradas y compendiadas. Es ese sentido, este estudio tiene como fin,

investigar y comprender las prácticas de Ingeniería de Requisitos que realizan hoy las



85

pequeñas y medianas empresas antioqueñas de software a medida para luego, apoyados en

este conocimiento, generar registro de aportes de buenas prácticas, experiencias y retos que

ayuden a mejorar la calidad del proceso de la Ingeniería de Requisitos y por ende, sean un

aporten para optimizar la calidad del producto software.

Objeto del estudio: Las actividades generadas por el proceso de Ingeniería de Requisitos

en el desarrollo de software a medida.

Propuesta del estudio: Investigar las prácticas, retos y desafíos que en Ingeniería de

Requisitos enfrentan las pequeñas y medianas empresas de desarrollo de software a medida.

Como lo menciona IBM “Una aplicación de software comienza con una fuerte recogida de

requisitos sólida…”, en contraste, una y otra vez, las encuestas muestran que en la

industria las desarrollo software, la Ingeniería de Requisitos, es uno de los mayores

desafíos que enfrentan las organizaciones hoy. [35…]

Perspectiva del estudio: Desde el miramiento de los jefes de proyecto, arquitectos y

administradores, analistas y empresas clientes con departamento de desarrollo.

Dominio del estudio: Una ingeniera de sistemas, especialista en desarrollo software y

estudiante de maestría apoyada por profesor experimentado y experto en el tema Ingeniería

de Requisitos, adscrito a la planta docente de la Universidad Eafit, en el departamento de

Informática y sistemas y miembro del grupo de investigación en desarrollo de software, que

tienen como finalidad indagar las prácticas llevadas a cabo en el proceso Ingeniería de

Requisitos.

Ámbito del estudio: Esta trabajo toma elementos de la investigación realizada en Recife

Pernambuco a productos software COTS, sin embargo se centra en el estudio de productos

de software a medida y es aplicada al contexto de las organizaciones antioqueñas de

software. Para lograr el objetivo se realizó una revisión de la literatura de Ingeniería de

Requisitos para el desarrollo de software. Para lograr la efectividad de estas actividades se

decidió elegir el método de investigación cualitativo y el desarrollo de diez (10) hipótesis

que caracterizan los desafíos a los que se enfrentan los desarrolladores de productos de

software a nivel mundial, este desarrollo se presenta en este capítulo con: una breve

descripción de la hipótesis, las referencias bibliográficas que se alinean con la descripción y

finaliza con las consecuencias generadas en el medio o implicaciones. [1]

Hipótesis 1: La competencia en el mercado es un objetivo estratégico clave en las empresas

que desarrollan productos de software.

Fuente: La competencia en el mercado ha sido el principal obstáculo encontrado por las

empresas que desarrollan productos de software, dado que los clientes desean sus productos

rápidamente y la competencia presiona para que así sea, esto genera que las empresas

permeen las etapas del ciclo de vida producto, [2], en este sentido las organizaciones se han

dado cuenta que el tiempo dedicado a la comprensión del problema de la empresa, es una



86

excelente inversión y que los clientes están tomando en serio la fase de Ingeniería de

Requisitos, debido al efecto bola de nieve que les ha causado haber construido productos

carentes de requisitos. [7]

Refrendando lo anterior se puede afirmar que “Impulsado por un mercado cada vez más

competitivo, las empresas tratan de agregar características nuevas al producto y comprimir

los plazos de entrega, lo que resulta en una falta de coincidencia completa de los requisitos

y recursos, dando lugar a productos que no satisfacen las necesidades del cliente.” [36.]

Por otro lado, referente a la competencia en el mercado se sabe que el propósito de toda

organización es ser competitiva a nivel nacional e internacional, por tanto las

organizaciones buscan estrategias para desarrollar capacidad de competir y ganar un

espacio importante en los mercados mundiales de tecnología, dado que el mundo avanza y

la velocidad es una característica de las organizaciones modernas, junto con la información

que es el activo más valioso y el recurso humano en continuo entrenamiento, estos factores

constituyen la clave para alcanzar los niveles de éxito que exigen las condiciones del nuevo

orden mundial, la globalidad.[14]

Implicaciones: En este estudio, la hipótesis uno (1) se refleja en la analogía, si se acorta el

tiempo los procesos quedan incompletos y los productos con defectos. Esta afirmación es

coherente con los resultados que arroja la investigación referente a las causas de

insatisfacción de los clientes a saber:

- El inicio tardío de los proyectos a causa del desconocimiento de las necesidades del cliente

- Realizar ajustes de última hora a los productos

- Discusiones sobre la claridad en requisitos (lo que el cliente esperaba difiere de lo que le fue entregado).

Los anteriores ítems producen como resultado las demoras en las entregas de los productos

que son la consecuencia de deficiencias en la etapa de Ingeniería de Requisitos, por tanto

este estudio encontró que la Ingeniería de Requisitos en las organizaciones, aunque se

realiza y tiene un grado de importancia alto en el proceso de desarrollo software, carece de

una adecuada gestión que permita, la obtención correcta y concreta de una especificación

de requisitos que demuestre apalancar un proceso claro, apoyar la estimación del tiempo y

agilizar el proyecto y generar valor en el tiempo adecuado.

A sabiendas que no siempre lo que dice el mercado, es lo que los clientes desean, esta

investigación, hace un rastreo de las propiedades deseables en los requisitos desde la

perspectiva de los clientes encontrando factores deseables tales como: todo requisitos

debería tener una identificación adecuada para poder ser rastreable, los requisitos deben ser

entendibles y deben comunicar realmente las necesidades.

En consecuencia, las empresas desarrolladoras de productos software a la medida coinciden

en afirmar que pese a tener una fuerte competencia en el medio, la permanencia en él



87

depende de la satisfacción del cliente. Por tanto, ellos prefieren tener clientes fijos

conocedores del proceso de desarrollo y participes de este, que a su vez sean conscientes de

la necesidad de cumplir con cada una de las etapas del desarrollo a cabalidad, por encima

de agilizar los tiempos de entrega, en lugar de tener mayor cantidad de clientes con

demandas que obligan a realizar entregas rápidas y sin que se cumplan de manera cociente

todas las etapas del proceso de desarrollo, que a la larga generan mayor daño a la

organización desarrolladora del producto software, por temas de calidad.

Las organizaciones hoy tienen presentes en su planta de cargos los roles inherentes al

cumplimiento de todas las etapas para soportar el proceso de desarrollo software, en

cumplimiento a las certificaciones de calidad obtenidas.

En conclusión, para las empresas de este estudio, la competencia en el mercado es un

objetivo estratégico clave en las empresas que desarrollan productos de software.

Hipótesis 2: Los mayores desafíos para el crecimiento y gestión del mercado, no son los

aspectos relacionadas con problemas técnicos. [1].

Fuente: Resultados de una de las más grandes encuestas realizadas a empresas que

desarrollan productos de software en Finlandia demostraron que los desafíos más críticos

que enfrentan las empresas no son desafíos tecnológicos, los más críticos desafíos son los

relacionados el conocimiento del negocio y el mercadeo. En estas empresas generalmente

los desarrolladores tienen conocimientos técnicos altos, pero conocimiento limitado de la

gestión y de negocios. Como consecuencia, muchas compañías presentan problemas al

interior, como la falta de habilidad en ventas, marketing y alta rotación de personal. [1] en

[44].

En este sentido el proceso de la Ingeniería de Software sobre el cual están basadas las

organizaciones que desarrollan productos software, no puede ser visto como una fórmula

para hacer productos tangibles, esta ingeniería proporciona prácticas y enfoques

estratégicos fundamentados en las ciencias básicas, que proveen elementos para darle

solución a problemas específicos de los clientes que requieren de sistemas que apoye sus

procesos productivos. [14]

En apoyo a lo anterior, los requisitos de ingeniería son principalmente una actividad de

comunicación, no un conjunto de actividades técnicas. En consecuencia, los problemas de

comunicación pueden comenzar desde el principio si los participantes del proyecto tienen

diferentes ideas de lo que son exactamente "requisitos", o simplemente si no se tiene

claridad de lo que se desea y lo que realmente se necesita. Esto focaliza la existencia de los

desafíos en el proceso de desarrollo software en las dificultades de comunicación y los

distancias de los desafíos técnicos. [7]

Teniendo en cuenta lo anterior, algunos autores señala que los requisitos son “... una

especificación de lo que debería ser implementado. Son descripciones de cómo el sistema

debe comportarse, o de una propiedad o atributo del mismo. Que puede ser un obstáculo o



88

la herramienta de apoyo en el proceso de desarrollo software de un producto”, por lo tanto,

se debe tener en cuenta que existen tres (3) niveles de requisitos que abordar, que provienen

de diferentes fuentes en diferentes etapas del proyecto a saber: [42]

Los requisitos del negocio consisten en describir por qué el producto se está

construyendo. Para esto se deben exponer los beneficios a los clientes para que el

negocio progrese y de frutos.

Los requisitos de usuario, capturados en forma de casos de uso, éstos son la

descripción de las tareas o procesos de negocio que un usuario será capaz de realizar

con el producto.

Requisitos funcionales. Los que describen las conductas específicas del sistema que

debe ser implementadas o también las declaraciones en una especificación de

requisitos de software.

Otro aspecto que vale la pena considerar es “Si no se logran los requisitos correctos, no va

importar que tan bien se ejecute el resto del proyecto”, se tiene presente, que para lograr

excelencia en los requisitos es necesaria una adecuada exploración y análisis, que debe

hacerse con los participantes y lograr motivar en ellos la aceptación del producto, se debe

confirmar claramente que el reto de la Ingeniería de Requisitos no es solo técnico, sino que

requiere de criterios de comprensión humana que son los que miden realmente si los

requisitos fueron o no bien elaborados, porque al final lograron ser o no la base para la

ejecución del todo del proyecto con calidad. [20].

Implicaciones: En esta tesis, las implicaciones de la hipótesis dos (2) se refleja en los

resultados que arroja la contextualización de los empleados adscritos al proceso de

desarrollo software en las organizaciones, donde se les perfila de acuerdo a una serie de

certificaciones técnicas y metas de certificación a mediano y corto plazo expresadas por

ellos, además, se obtuvieron las respuestas de las organizaciones en materia de las

necesidades de conocimiento en sus empleados acordes con sus clientes y requisitos del

negocio, estando estas últimas también presentes en las estrategias que tienen

implementadas a nivel de capacitación las organizaciones para hacer de sus empleados

personas aptas a nivel técnico.

Sin embargo, hoy cuando las organizaciones utilizan estrategia para potenciar sus clientes,

no logra la adquisición de empleados con buenos niveles de competencias gerenciales, para

alcanzar con ellos un muy buen entendimiento del negocio, de tal forma que puedan

realizar un buen análisis de las necesidades y deseos de sus clientes generando aportes en la

solución que genere valor.

Como resultado las organizaciones desarrolladoras de software en el medio, expresan

deficiencias en el conocimiento que se logra en los requisitos del negocio y en los aportes

que como empresa de desarrollo se están generando a los clientes para encaminarlos a

priorizar sus necesidades y llevarlos a generar requisitos que logren que la solución genere

valor significativo al negocio. En consecuencia, las empresas del estudio responden que



89

dentro de las características que consideran deseables para el proceso de Ingeniería de

Requisitos está, esperar lograr que los analistas puedan desarrollar un mejor modelado del

negocio.

En conclusión el estudio demostró que los mayores desafíos para el crecimiento y gestión

del mercado, no son los aspectos relacionadas con problemas técnicos.

Hipótesis 3: Los requisitos suelen ser inventados por los desarrolladores internos de la

compañía.

Fuente: El análisis de los requisitos es un proceso de comunicación que debe atravesar

entre otras las barreras culturales, existentes entre el desarrollador y el cliente, es decir para

asimilar el proceso de Ingeniería de Requisitos se requiere de un profesional con cualidades

humanas y técnicas adecuadas de comunicación, dado que son los ingenieros quienes deben

encontrar las necesidades del usuario y a su vez tener el universo necesario para realizar el

análisis que les brinde elementos para priorizar y para diferenciar sus necesidades de sus

deseos partiendo de la ayuda del ingeniero. [1] en [87].

Por otro lado, es indiscutible que la experiencia en el campo es esencial para desarrollar un

sistema con conocimiento del dominio del negocio por tanto el personal del proyecto no

puede hacer un proceso alejado de los usuarios y en la práctica esperar buenos resultados.

[43]

Debido a la importancia y relevancia para la Ingeniería de Requisitos de la fase de

elicitación, se hace la observación de la evidente necesidad tener durante esta, grados altos

de creatividad, para dar cumplimiento a etapa fase de forma satisfactoria para los diferentes

niveles de usuario y para los diferentes tipos de negocio. En la elicitación también es

necesario el uso del razonamiento de exploración combinatoria y de transformación para

estimular el pensamiento creativo y llevar a los usuarios a generar soluciones que apoyen

procesos reales y que aporten valor al negocio. [1] en [71].

Es también importante señalar que la mejor manera de alcanzar el éxito en los proyectos

basado en la Ingeniería de Requisitos, es mediante la aplicación de las buenas prácticas

preestablecidas, en este sentido, se deben desarrollar normas y procedimiento incorporados

en la fase de requisitos. Una práctica clave es la adopción de una técnica adaptable a las

necesidades de proyecto y a la cultura organizacional y evitar la implementación de normas

con estándares rígidos. 7.

En apoyo a lo anterior, la elicitación de requisitos debe ser vista la practica donde se

identifican las contradicciones, intereses y se establecen las verdaderas relaciones entre el

comprador, el cliente, los usuarios y el equipo de desarrollo, por tanto debe ser

particularizado según las necesidades y características del cliente y del proyecto. [44].



90

Para dar apoyo a la importancia que para el proceso de Ingeniería de Requisitos revierte la

fase de elicitación, este estudio cita algunas situaciones presentadas durante esta fase y que

pueden llevar a falta de claridad en los requisitos: [20] [44].

Problemas de Alcance: Las fronteras del Sistema están mal definidas o los

Clientes/Usuarios definen detalles técnicos innecesarios que pueden confundir, más

que aclarar los objetivos generales del sistema.

En este sentido es importante anotar que La primera pregunta que un analista

debe hace acerca de un nuevo requisito propuesto es:"¿Es este requisito parte

del alcance?". El crecimiento controlado de los requisitos es normal, la aparición o

suposición de requisitos también está dentro del contexto de normalidad, sin

embargo, una manera de evitar el desbordamiento es tener claro y concertado el

alcance del producto.

Problemas de Comprensión: Los clientes/usuarios no están completamente

seguros de lo que necesitan, tienen una comprensión deficiente de las capacidades y

limitaciones del entorno informático, no tienen una plena comprensión del dominio

del problema, tienen dificultades para comunicar sus necesidades, omiten

información que consideran "evidente", definen requisitos que entran en conflicto

con las necesidades de otros clientes/usuarios, o definen requisitos que son

ambiguos o incomprobables.

Problemas de volatilidad: Los requisitos cambian con el tiempo, para ayudar a superar estos problemas, los ingenieros de software deben ejecutar de forma

organizada la captura de requisitos.

Un punto de vista que ratifica la mejor manera de hacer requisitos es pensar en el objetivo

de los mismos, el producto del desarrollo de requisitos es un entendimiento común entre los

interesados en el proyecto de las necesidades puntuales que se están abordando. [17]

Implicaciones: En el caso de este estudio con relación a la hipótesis tres (3), se encontró

que los clientes no son siempre consultados a profundidad para encontrar la totalidad de sus

necesidades y que los stakeholders, no logran ser identificados en su totalidad por los

ingenieros puesto que prevalece un desconocimiento de la población objetiva.

Por otro lado, las técnicas utilizadas durante el proceso son dejadas a criterio del

profesional quien en la mayoría de los casos se inclina a realizar entrevistas, obviando otras

técnicas grupales pueden generan resultados de mayor confiabilidad puesto que logran

opiniones en consenso.

Otra situación presentada es la referente a la cantidad de conocimiento tácito que se genera

en los proyectos, lo que dificulta en gran medida la labor del equipo de trabajo, esto se

evidencia en la necesidad que expresaron los usuarios de mejorar la claridad y la



91

completitud en el contenido de la documentación que hoy está llevando a los equipos de

trabajo a confusión y a imaginar los requisitos.

El estudio demuestra la necesidad que hoy se presenta en que los ingenieros de requisitos, o

analistas desarrollen habilidades comunicativas, pedagógicas y de lectoescritura que logren

el objetivo de ayudarle a analizar las insuficiencias del negocio, interpretar las necesidades

de los usuarios y transmitir esas mismas al equipo interdisciplinario de manera clara,

concreta y comprensible, evitando la pobreza en los requisitos y/o que estos sean producto

de la invención o de la mala interpretación.

En el contexto se encontró que referente a las metodologías de desarrollo tradicionales y

agiles, que cuando se usan correctamente los enfoques tales como el desarrollo incremental

o ágil estos métodos pueden reducir los riesgos de contraer los requisitos equivocados o

inventarlos dado que se asegura que los sistemas son desarrollados en trozos más pequeños

y que cada trozo se puede demostrar al cliente para su aprobación. Sin embargo, la mejor

manera de desarrollar un sistema de alta calidad con un mínimo esfuerzo sigue siendo,

conseguir los requisitos bien la primera vez y así dar respuesta a lo que el cliente realmente

necesita [37] [29].

Es importante anotar que independientemente de la metodología de desarrollo utilizada, es

manifiesto que los requisitos, siguen siendo un problema persistente en las organizaciones.

[35][56].

Por tanto el estudio demostró como dadas diversas circunstancias los requisitos suelen ser

inventados por los desarrolladores internos de la compañía.

Hipótesis 4: Los requisitos son pobremente documentados

Fuente: En el desarrollo de software a medida, el documento de requisitos debería actuar

como un contrato entre las partes y debe ser la base de la estimación del proyecto, que se

genera a través de la evaluación final de los requisitos cumplidos. [1]

En el argumento de este estudio podemos decir que las organizaciones antioqueñas, no

cifran totalmente su confianza para la las actividades de estimación en la Ingeniería de

Requisitos en temas como la asignación de los recursos y tiempos, más bien, la

documentación de requisitos es utilizada como un insumo complementario a la utilización

de técnicas ad hoc. O de juicio experto.

Adema, cuando se habla de problemas en documentación se hace inevitable asociar el tema

a las diferentes metodologías de desarrollo, lo que es específicamente polémico cuando se

discute sobre metodologías ágiles y uso de la documentación en contraste con las

metodologías de desarrollo tradicionales. En este sentido, aunque el manifiesto ágil no

rechaza el hecho de que se documente en los proyectos, si antepone y prioriza otras muchas

cosas frente a documentar y muchos proyectos han interpretado esto al extremo de

considerar que, en un proyecto ágil no se debe escribir ningún documento. Este es un error



92

que muchos estudios con los años han sufrido como problema, e incluso se han visto

imposibilitados a la hora de cambiar de proveedor de desarrollo software o de plataforma.

En ese sentido este estudio sugiere este punto como importante para futuras

investigaciones. [37]

Además se sabe que la industria del software está mostrando un creciente interés en la

Ingeniería de Requisitos, es decir, en la comprensión de lo que va a construir antes de

terminar su construcción, estas industrias, se han dado cuenta que el tiempo invertido en la

comprensión del problema en este negocio es una excelente inversión y esta comprensión

requiere ser documentada, dada la necesidad de entendimiento por parte de todo el equipo

de desarrollo. Respecto a esto, los clientes han manifestado haber tenido grandes

dificultades por tener construidos los productos atendiendo pobres requisitos lo que ha

generado problemas demasiado grandes y perdidas de gran magnitud en los negocios y por

tanto baja calidad. [7].

A este respecto existen algunos pronunciamientos como: “Los requisitos de desarrollo

son un descubrimiento y no solamente una colección de procesos”, apoyando lo anterior

es importante anotar que para que los requisitos generen valor, hay que descubrirlos,

interactuar con los participantes, investigar, explorar, analizar, crear nuevas ideas alrededor

de los requisitos, todo enmarcado en un excelente conocimiento del negocio y deben ser

estos requisitos además pensados como un instrumento de transferencia de conocimiento a

los diferentes roles del equipo de desarrollo por tanto deben contener una clara y correcta

documentación. [21]

En lo que respecta a la documentación, pensar en calidad no es igual a pensar en cantidad.

Se sabe que el exceso de datos es equivalente a la mala documentación en requisitos dado

que se hace difícil de manejar gran cantidad de documentos lo que lleva a obviar su uso y

se torna improductiva para la persona que la crea la documentación y un obstáculo para las

personas que buscan la información concreta y clara necesaria para desempeñar un rol en el

proceso de desarrollo software. [26].

Implicaciones: En esta tesis las organizaciones coinciden en señalar que la falta de un

documento de requisitos formal tiene dentro de sus implicaciones la de limitar la capacidad

de rastrear la información obtenida durante el proceso de desarrollo, lo cual revierte alguna

gravedad frente a la necesidad de cambios surgida a lo largo del proyecto, así lo confirman

las empresas antioqueñas de software donde se trataron diferentes aspectos que se están

viendo afectados por la documentación incompleta de los requisitos, tales como la

rastreabilidad en los mismos, actividad que es particularmente importante puesto que una

de las características principales del proceso de desarrollo software es el manejo de

requisitos cambiantes, que de no hacerse de manera adecuada causa demoras, sobrecostos y

desarrollo no acordes con las necesidades del cliente, e impide el desarrollo del proceso de

gestión de cambio y por tanto afecta directamente la calidad del producto. [1].

La pobre documentación de requisitos además tiene afectación directa en propiedades

deseables de los requisitos como la claridad, completitud, determinación (requisitos



93

concretos) identificación de las necesidades reales de los usuarios, enfoque en resultados,

verificación, validación entre otros. Lo anterior sumado a que ésta situación de deficiente

documentación causa conflictos al interior de los equipos de trabajo e impide la elaboración

de artefactos reusables de software.

Es importante destacar que hoy las empresas presentan como una de las necesidades más

sentidas durante el proceso de Ingeniería de Requisitos el conocimiento del negocio y la

generación de ideas al cliente que lo encaminen a requisitos que generen valor, en contraste

cuando los requisitos son raramente documentados esta labor presenta gran dificultad y

escaso éxito dada la falta de entendimiento que el cliente pueda presentar de los mismos y

los errores del equipo de desarrollo al interpretar.

Hipótesis 5: Priorización de las necesidades y la planificación de la nueva versión son

procesos cruciales para la ventaja competitiva.

Fuente: Se sabe que la priorización de las necesidades y el procesos de planificación son

aspectos que resultan cruciales para generar ventaja competitiva, en cada liberación o nueva

versión y se observa una brecha entre las prioridades de los clientes y las funcionalidades

de la versión, la base para lograr una adecuada planeación se genera en la realización de

una priorización acorde con el orden y necesidades primarias del cliente. [1] en [92]

Es conocido que la búsqueda de un buen proceso de priorización y la planificación genera

ventaja competitiva ya que las diferentes versiones son basadas en la selección de los

requisitos que se ejecutarán en cada puesta a producción, la prioridad de una requisito

"refleja la importancia de la exigencia para el éxito del mercado, la urgencia para su

aplicación, su impacto en el desarrollo futuro". [1] en [18] [91]

Las ventajas competitivas que menciona la hipótesis cinco (5) son muy derivas de la

generación de unos buenos requisitos de negocio que, deben explicar con claridad cómo los

desarrolladores del producto y sus clientes se beneficiarán de este producto. Se sabe que los

requisitos priorizados deben ser una declaración de visión corta que describa lo que el

producto final podría llegar a ser, con las limitaciones y lo requisitos del negocio. [7].

Se puede afirmar entonces que el logro de una amplia participación de los usuarios es

crucial en el momento de priorizar las necesidades. A este respecto, múltiples estudios

demuestran insuficiente participación de los usuarios como una razón común para una

inadecuada priorización por lo que se recomienda que cada proyecto debe identificar sus

distintas clases de usuarios y sus características, así como sus diferencias en frecuencia de

uso del producto, las funciones utilizadas, los niveles de privilegios, o los niveles de

habilidad. Además se debe determinar cuál de las clases de usuario se llevan el mayor peso

en las discusiones de prioridad, cuando la resolución de conflicto entre las peticiones de

características se origina, y en el impulso de opciones de diseño. [7].

También es importante tener en cuenta que cualquier proyecto con recursos limitados deben

establecer las prioridades relativas de las características solicitadas, en casos de uso, o en



94

exigencias funcionales. En apoyo a esto la priorización en el plan ayuda al jefe de proyecto

para las gestionar las diferentes entregas, o trade-off de decisiones, y responder a las

solicitudes de inclusión de una mayor funcionalidad y puede evitar la traumática "fase

descoping rápida" que se da al final del proyecto, cuando se empiezan a tirar por la borda

las características para obtener un producto entregable a tiempo. [7].

Es importante anotar que la priorización a menudo se convierte en política y es

emocionalmente cargada, cuando todas las partes insisten en que sus necesidades son más

importantes. Un mejor enfoque es que las prioridades surjan de la base de un análisis

objetivo de cómo entregar el máximo valor del producto dentro de la programación, el

presupuesto y las limitaciones de personal.

En este sentido, muchas organizaciones clasifican a los requisitos en necesidades y deseos,

o utilizan tres clasificaciones de prioridad (alta, media y baja). Importando realmente las

prioridades abarcan un espectro del negocio, en lugar de solo un ajuste adecuadamente de

unos cuantos cubos.

De la misma manera, tener un enfoque más analítico es decir evaluar el valor relativo de los

clientes y el costo concerniente al riesgo técnico de cada función es muy útil en el momento

de priorizar pensando en la generación de entregas nuevas. En este sentido es importante

destacar que el valor para el cliente debe encontrar tanto el beneficio si una característica

está presente y la consecuencia si no lo está, teniendo en cuenta que las características más

deseables deben ser aquellos que ofrecen el mayor valor al menor costo ajustado por riesgo

y lógicamente al negocio del cliente.

Implicaciones: Para priorizar las necesidades es necesario definirlas y contrastarlas con el

alcance, a este respecto, se generan una serie de pasos críticos en los que definir las

necesidades del producto de negocio es el primero, la anterior afirmación se extrae de la

experiencia probada en el estudio de donde se relata: que casi todo el mundo ha trabajado

en proyectos que han sufrido de la corrupción del alcance y como característica estos

proyectos carecían de un alcance documentado o visión clara. La pregunta es ¿Cómo saben

que el alcance se está arrastrando, si nadie lo tiene claramente definido? documentar los

requerimientos del negocio ayudará a responder esta primera pregunta que se hace cada vez

que alguien propone una nueva funcionalidad o requisito al sistema: "¿Es esto en su

alcance?", este planteamiento en apoyo a la hipótesis cinco (5) es la base de la adecuada y

exitosa planificación del desarrollo. [7].

En el sentido de la hipótesis cinco (5), para priorizar las necesidades, la descripción del

alcance debe tener en cuenta las principales características incluidas en la entrega inicial y

describir más plenamente consciente la visión a través de las diferentes entregas o versiones

posteriores.

Por lo tanto éste estudio apoya lo dicho referente a que la correcta selección de los

requisitos en la planificación de la nueva versión de un producto implica el análisis de la

importancia de los requisitos, las estimaciones de costos y las interdependencias de los



95

requisitos. Esto teniendo en cuenta que un proceso de estimación requiere el conocimiento

claro de los requisitos que cubre cada versión para que se puedan estimar el tiempo de

desarrollo y los recursos humanos y técnicos involucrados, lo que garantiza cumplimiento

en tiempo y satisfacción de las necesidades y expectativas reales del usuario y por tanto

calidad del software y la competitividad en el mercado. [1] [31].

Esta investigación, además genera aportes como que los desarrolladores de software tienen

que entender los segmentos de mercado y el negocio de los clientes con el propósito de

orientar a los clientes para priorizar basándose en la estrategia costos y beneficio.

En conclusión, un proceso adecuado de priorización genera el conjunto de requisitos

prioritarios y forjan la posibilidad de nuevas entregas con los requisitos ya conocidos,

además permite orientar al usuario para satisfacer sus necesidades acordes con costo-

beneficio y presupuestos restringidos, es por ello que se debe analizar y fortalecer la técnica

utilizada para realizar la priorización de los requisitos que constituye una base competitiva

para las organizaciones de desarrollo software.

Hipótesis 6: La relación entre los desarrolladores y los clientes suele ser larga, pero con la

proximidad limitada.

Fuente: Los requisitos para un producto de software en particular se derivan de una

variedad de fuentes, tales como estudios de mercado, aunados a los requisitos que se

suscitan de las necesidades de los clientes y el conocimiento del negocio, en este sentido se

evidencia como hay una marcada distancia entre quienes desarrollan productos de software

y sus clientes. [1] en [61], [77].

En apoyo a lo anterior y como muestra de la importancia de tener proximidad con los

clientes se expresan a continuación una secuencia de pasos básicos que debe tener un

proceso de Ingeniería de Requisitos y donde necesariamente se requiere la orientación del

usuario para llevarlos a cabo: [7]

1. Definir la visión del proyecto y su alcance.

2. Identificar las clases de usuario.

3. Identificar los representantes apropiados de las clases de usuario.

4. Identificar los requisitos de los tomadores de decisiones y su proceso de toma de

decisiones.

5. Seleccionar las técnicas de obtención que va a utilizar.

6. Aplicar las técnicas de obtención de desarrollar y dar prioridad a los casos de uso de una

parte del sistema.

7. Recopilar información sobre las características de calidad y requisitos no funcionales de

los usuarios.

8. Elaborar los casos de uso en los requisitos funcionales necesarios y documentarlas.

9. Revise las descripciones de casos de uso y los requerimientos funcionales.

10. Desarrollar modelos de análisis, si es necesario para mejorar la comprensión de los

participantes provocación "de las porciones de los requisitos.



96

11. Desarrollar y evaluar prototipos de interfaz de usuario para las porciones de los

requisitos que no se entienden claramente.

12. Desarrollar casos de prueba conceptual de los casos de uso.

13. Usar los casos de prueba para verificar la calidad de los casos de uso, requisitos

funcionales, los modelos de análisis y prototipos.

14. Repetir los pasos 6 a 14 para las demás partes del sistema hasta que el equipo llega a la

conclusión de que el levantamiento de requerimientos es tan completa como debe ser.

15. Línea de base los requisitos documentados.

Lo anterior demuestra que “la participación de los clientes es el factor más crítico a la

calidad del software”, sin embargo, el tiempo que los clientes deben dedicar al

acompañamiento al proceso de desarrollo y a hacer críticas y aportes durante la

construcción lo están destinando solo al finalizar el producto haciendo las observaciones en

el momentos en el que estas son más costosa y dolorosa ya que sacrifica la agilidad y

calidad del producto. Como consecuencia se incrementa los costos y se evidencian demoras

en las entregas e inconformidades. [20].

De lo anterior uno podría atreverse a decir en contravía con las estrategias de mercadeo en

software, los clientes no siempre tienen la razón, pero siempre tienen un punto de vista

referente a los requisitos del producto que merece no solo ser evaluado, sino ser tenido en

cuenta desde el inicio. [20].

Implicaciones: Para este estudio referente a la proximidad limitada del cliente y la larga

relación citadas en la hipótesis seis (6), se analizaron algunas situaciones con el fin de

demostrar la proximidad entre los clientes y los desarrolladores en diferentes categorías de

proyectos medidos según el tiempo de duración y tamaño: Proyectos grandes, medianos y

pequeños. Se logró establecer que el mercado de desarrollo de software antioqueño se

enfrenta a varias situaciones que demuestran proximidad limitada con los clientes, entre

estas está: los clientes que ocultan información por no considerarla relevante o bien por

considerarla secreto del negocio, esta situación obstaculiza en gran medida el desarrollo del

proyecto y evidencia proximidad limitada al entregar la información clara concreta y

correcta, entre clientes y equipo de desarrollo. [20].

Otra situación se da cuando los clientes no tienen claridad en sus necesidades y presentan

en cada acercamiento, un cumulo de ideas encontradas y cambiantes que se entremezclan

entre necesidades de la organización y los deseos de los usuarios. Todo esto genera

confusión, desgaste y hace que la relación cliente equipo de desarrollo se tensione y se

retarde el proceso de Ingeniería de Requisitos, labor que requiere alto niveles de

conocimiento del negocio y de actividades de elicitación productivas.

Ante las anteriores situaciones, las organizaciones han generado diversas estrategias y

documentos de confidencialidad con el fin de generar confianza y claridad entre los

usuarios, además han tratado de establecer nichos de mercado donde la experiencia le

brinda a la empresa de desarrollo elementos de conocimiento del negocio. Sin olvidar que

se presta gran atención a que el proceso de desarrollo software genere confianza y



97

transparencia para el cliente con estrategias como hacer pública la trayectoria de

experiencias de desarrollos y clientes. [64]

Respecto a la proximidad limitada, es decir los niveles de comunicación que deben existir

entre el equipo de desarrollo y el cliente entorno a los requisitos del producto se apoya que

“La comunicación ineficaz es a menudo una de las causas del fracaso del proyecto. La

perspectiva de los equipos de desarrollo, clientes, usuarios finales y ejecutivos es diferente

para cada grupo, como lo son sus necesidades de comunicación”. [26]

En conclusión, la comunicación es un factor crítico en el desarrollo de software y que

afecta directamente la calidad del producto dada la necesidad de la intervención del cliente

en las diferentes etapas del procesos por tanto es necesario incluir al cliente desde el inicio

del proyecto mostrándole con claridad las implicaciones en la calidad del producto de su no

participación, esta hipótesis es apoyada por las organizaciones del estudio, para lo que se

han creado estrategias como: la generación obligatoria del documento de confidencialidad,

el tener desde el inicio agendas concertadas con el cliente y respaldadas por el gobierno de

la organización cliente, informar al cliente su participación en cada etapa, generar confianza

en el cliente informando la trayectoria de la organización desarrolladora entre otros.

Finalmente se puede afirmar entonces que la comunicación eficaz ayuda optimizar el

tiempo y esfuerzo del proyecto.

Hipótesis 7: El fracaso del lanzamiento del producto a menudo se produce debido a que el

producto no cumple con las necesidades de los clientes.

Fuente: Fuentes como Standish Group International para el 2011, Chaos Report, reportan

que los proyectos que deben ser mejorados son 42% y los proyectos fracasados fueron

21%. Respecto a los principales factores de fracaso son por requisitos incompletos 13,1%,

requisitos cambiantes 8,7%, se presentan además datos como: El 40% del proyecto es

sobreesfuerzo para reparar defectos causados por mala calidad de los requisitos. Según

Software Engineering Institute, el 60% de los defectos son desde los requisitos, en apoyo

National Institute of Standards and Technology, revela que el 42% Proyectos cambian por

culpa de los requisitos, mientras que según The Standish Group, Chaos Manifesto en 2011,

el 54% Requisitos originales solo son implementados (Fuente: The Standish Group, Chaos

Report) mientras que el 55% de los requisitos no son usados por los usuarios o clientes

(Fuente: Jacobe). Para Gartner Group, aproximadamente el 60-70% de los fracasos

ocurridos en los proyectos de desarrollo de sistemas de software son debido a las

insuficiencias de la adquisición, gestión y análisis de requisitos. [3].

En el mismo sentido, hoy se presenta como prioridad emplear diferentes técnicas para

entender las necesidades de las partes interesadas. Y se hace énfasis en que el objetivo

principal en el desarrollo de productos de software es crear soluciones que satisfagan las

necesidades y expectativas de los clientes en diferentes contextos de uso. Además se apoya

el hecho de que para que un producto de software cumpla con expectativas tales como ser

innovador, primero debe ser atrayente y claro para que los clientes lo usen, y así



98

proporcionar beneficios más allá de la tecnología como una nueva funcionalidad, una mejor

calidad o reducir los costos. [1] en [31], [55], [4].

En consecuencia, cuando se menciona definir los atributos de calidad se hace alusión de

inmediato al cumplimiento de las necesidades del cliente expresadas en los requisitos

funcionales, sin embargo no hay que olvidar que la participación del cliente no es suficiente

cuando esta no está adecuadamente enfocada a declarar las expectativas de eficiencia y

otros atributos no funcionales de los usuarios referente al sistema, pese a que sus

necesidades funcionales sean resueltas es necesario entender, ¿cómo funciona el sistema? Y

¿si llevará a cabo sus funciones para lograr la satisfacción del cliente? [7].

Se recomienda entonces, tener cuidado sobre las características de disponibilidad del

sistema, eficiencia, integridad, fiabilidad, robustez y facilidad de uso, además de

preocuparse por las características como la flexibilidad, facilidad de mantenimiento,

portabilidad y reutilización. Aunque sin olvidar que es probable que se tenga que hacer

concesiones mutuas para lograr el equilibrio óptimo entre los atributos de calidad, no se

puede crear el mejor de los mundos posibles.

De manera curiosa se expresa que los usuarios rara vez presentan requisitos no funcionales

de forma espontánea, más allá de la demanda que el sistema sea "user-friendly", "Fácil" lo

que es demasiado subjetivo y polifacético y debe llevar a explorar las características que

tendría una aplicación que parece fácil de usar para sus diferentes usuarios. Es importante

considerar la posibilidad de preguntar sobre los atributos deseables antes de sumergirse en

discusiones funcionalidad. Esto puede revelar los objetivos fundamentales de diseño que un

enfoque de funcionalidad puede hacer que falte, a menos que se hagan preguntas para

entender las expectativas de los usuarios, de lo contrario cuando se piensa que la calidad es

implícita, sólo la suerte permitirá crear un producto que satisfaga esas expectativas. [7].

Afirmaciones como: “Incluso el mejor documento sobre las necesidades no pueden y no

debe reemplazar el diálogo humano” son dirigidas a pensar que algunas veces

consideramos que la sola documentación es garantía del conocimiento de las necesidades

del cliente, sin tener en cuenta que dicha documentación se encuentra expuesta a factores

como falta de completitud, a obviar el conocimiento o dejan gran cantidad de conocimiento

sin explicitar, por tanto es indispensable para dar cabal cumplimiento a las necesidades del

cliente tener contacto verbal y frecuente con él, siendo el contacto verbal el que brinda la

capacidad de realizar lecturas corporales, de estados de ánimo, de tonos de voz que nos

referencien frente a aceptación o no de requisitos. [20].

Implicaciones: Este estudio en lo referente al fracaso del lanzamiento del producto debido

a menudo a que no cumple con las necesidades de los clientes según la hipótesis siete (7)

refiere que la realidad es que los productos se entregan a los clientes en forma tardía, lo que

genera como resultado el mayor índice de insatisfacción en los clientes del estudio por

entregas fuera del límite del tiempo, esto debido a que efectivamente en el momento de la

puesta en producción el producto aun no cumple con las necesidades de los clientes y por

tanto se debe ampliar el plazo, las causas de estos retrasos son frecuentemente, la alta



99

rotación de personas en las organizaciones de desarrollo software, lo que hace difícil el

cumplimiento a tiempo de los objetivos de cada puesta en producción y la satisfacción

completa de las necesidades del cliente, esto por la curva de aprendizaje que debe adoptar

el nuevo integrante del equipo de desarrollo. Otra causa de retraso en los proyectos es el

inicio tardío de los mismos por el desconocimiento de las necesidades del cliente en los

requisitos y las posteriores demoras en la construcción de ellos o la realización de ajustes

de última hora a los productos por deficiencias en la gestión de los cambios de los

requisitos.

Un dato importante y que apoya lo antes mencionado es que la Ingeniería de Requisitos es

deficiente en el 75% de las empresas siendo la gestión de requisitos uno de los factores

críticos para lograr un producto software de calidad. [3].

Con el fin de verificar la hipótesis, se indagó también la realidad antioqueña en aspectos

referentes a los niveles de satisfacción de los clientes, la técnica de verificación de

requisitos utilizada, el grado de cumplimiento de las necesidades de los usuarios, el enfoque

en los resultados y su verificación, además de las etapas de mayor y las de menor

porcentaje de satisfacción del cliente, las causas más frecuentes de insatisfacción, las

estrategias para involucrar al cliente en el proceso e información de las actividades llevadas

a cabo para la verificación y validación de los productos, encontrándose que los clientes al

recibir los productos continúan detectando defectos y necesidades insatisfechas.

Hipótesis 8: Los requisitos son evaluados sólo después de su lanzamiento en el mercado.

Fuente: La falta de clientes antes de la primera versión del producto afecta directamente a

la fase de validación de los requisitos. Y la validación final de los productos de software

sólo puede hacerse mediante la comprobación de la aceptación del producto en el mercado.

[1] en [27] [31].

Considerando que la falta de evaluación a tempo se origine por falta de disponibilidad del

cliente es recomendable dividir el dominio de la Ingeniería de Requisitos del software en

los requisitos de desarrollo y las necesidades de gestión como lo muestra la Figura 26.

Requisitos de Ingeniería, donde el desarrollo de los requisitos se subdivide en la obtención,

análisis, especificación y verificación. Cada una de las prácticas de los requisitos clave de

la ingeniería se inscribe en una de estas subdisciplinas. La entrega de los requisitos de

desarrollo es una línea de base que constituye un acuerdo entre las partes interesadas clave

del proyecto en cuanto a las capacidades del nuevo producto. Durante la gestión de

requisitos, el proyecto de control de cambios en la línea de base las necesidades y los

monitores de implementación de los requisitos. [7].



100

Figura 26. Requisitos de Ingeniería. Basada en When Telepathy Won’t Do:

Requirements Engineering Key Practices1

En apoyo a lo anterior es importante también tener en cuenta el punto de vista que hace

mención “El cambio sucede”, es innegable que las empresas cambian, evolucionan en sus

reglas de negocio, sus clientes, sus usuarios, su mercado, etc. Esto es inevitable por tanto el

cambio se debe gestionar, anticipar, adaptarse en lugar de inhibirse, con el fin de que los

lanzamientos iniciales pueden proyectarse para no generar altos niveles de desconcierto por

considerarse en desuso para las necesidades actuales de la organización, tener un proceso

de gestión del cambio claro e institucionalizado es de gran ayuda en este sentido. [20].

En consecuencia cuando se habla de control de cambios se debe tener en cuenta un reporte

de cambios al software, el cual suministra información muy valiosa como el impacto no

solo en el ámbito de casos de uso, requisitos funcionales, sino el impacto al nivel de

desarrollo, esfuerzo estimado para el cambio, costos, cambios en diseño y base de datos,

etc. Adicionalmente entregar tres documentos importantes como la Matriz de Requisitos

que es un documento que presenta una especie de sumario de requisitos, con el estado, la

persona responsable, el requisito, propia de la empresa, la matriz de rastreabilidad y la

plantilla las reglas del negocio. […2]

No hay que olvidar que “Los requisitos pueden ser vagos, pero el producto será

específico”. Este comentario apoya el hecho de que la especificación de requisitos es

difícil, especialmente cuando el producto es nuevo y no hay nadie exactamente seguro de lo

Req

uis

ito

s d

e In

gen

ierí

a

Requisitos de Desarrollo

Elicitación

Análisis

Especificación

Verificación

Requisitos de Admon



101

que el producto debe ser y hacer, lo que en la mayoría de los casos lleva a que sea después

del lanzamiento al mercado que se evalúen los requisitos del producto. [20]

Implicaciones: En el caso de la hipótesis ocho (8), requisitos evaluados solo después del

lanzamiento al mercado, en el caso de los productos de software realizados por las

organizaciones antioqueñas la puesta en producción demuestra que pese a que se realizan

procesos de verificación y validación de requisitos previos a dicho lanzamiento y se tiene

como política en la mayoría de los casos involucrar al cliente durante todo el proceso, los

resultados no son los esperados y aun se requieren ajustes significativos luego de la puesta

en producción, lo que evidencia falencias en la validación y verificación de los requisitos.

Sin embargo existen estrategias para involucrar al cliente durante el proceso y así evitar

errores en el producto final, pero estas no logran ser completamente efectivas ante

situaciones como el tiempo destinado por el cliente al proceso, mantener vivo el interés del

cliente en el producto y hacer de casa encuentro con el cliente una actividad productiva.

Lo anterior representa demoras en los procesos tendientes en la elaboración de cada

entregable, retrasan la entrega y esto sumado a la presión que ejerce el cliente por recibir

entregas rápidas, lleva a que el producto sea puesto en producción sin tener todos los

controles de fallos previstos y necesarios, incluso sin ser evaluados. Pese a tenerse

suficiente conciencia que resulta más costoso realizar las reparaciones de errores que

descubra el usuario en producción, que de fallos que se encuentren antes.

Algunos factores que hacen que aun después del lanzamiento el producto presente fallos

son según el estudio, la utilización continua de la misma técnica de elicitación, la falta de el

discernimiento adecuado en el elicitador para saber que técnica utilizar de acuerdo al

stakeholders y al tipo de desarrollo, el desconocimiento de la totalidad de los participantes,

quienes solo en el momento de conocer la salida a producción pasan a realizar la evaluación

de la versión del producto encontrando errores en los requisitos después del lanzamiento al

mercado de la nueva producción.

Hipótesis 9: Los desarrolladores de productos de software por lo general tienen un proceso

de ad hoc, la Ingeniería de Requisitos.

Fuente: La mayoría de los desarrolladores del paquete de software trabajan bajo

restricciones presupuestarias y de recursos lo que se constituye en una de las causa que el

proceso de ingeniería sea ad hoc otras causas son además de las condiciones de restricción

de presupuesto las de la competencia en el mercado, en cuanto a rápidas entregas y bajos

costos, que incluyen la eliminación de tareas como la de documentación de la Ingeniería de

Requisitos, contrastado todo esto con los tiempos en pasos, que genera inicialmente un

adecuado proceso de desarrollo que inicia con los procesos de Ingeniería de Requisitos,

aunque como ya es sabido al finalizar dicha inversión en el proceso completo resulta ser

más beneficiosa, menos costosa y de mejor calidad, aún siguen los clientes cayendo en la

trampa y las empresas de desarrollo desmejorando su calidad para alcanzar alguna gran

negociación. [1] en [55] [100].



102

Respeto a las prácticas ad hod en ingeniería de Requisitos, es de anotar que la realización

de adecuadas prácticas de análisis permite develar cuando se está incurriendo en la

elaboración de un proceso a ad hoc en estas claves de análisis dado que el análisis de

requisitos incluye la descomposición de alto nivel requisitos detallados en los requisitos

funcionales, requisitos de construcción de modelos de gráfica y la construcción de

prototipos. Estos modelos de análisis y prototipos ofrecen visiones alternativas de los

requisitos, que a menudo revelan errores y conflictos que son difíciles de detectar en un

texto y que suelen ser producto de supuestos generados desde la experiencia. [7].

Apoyando lo anterior, escribir las especificaciones estructurar a los requisitos en un

formato aceptado, establecido que los reúne y analiza es el objetivo de desarrollo de la

Ingeniería de Requisitos, pues esto conlleva a comunicar un entendimiento compartido del

nuevo producto entre todos los interesados en el proyecto. Históricamente, este

entendimiento se refleja en la forma de un texto escrito en un lenguaje natural, aumentado

por los modelos de análisis apropiados, que de manera clara evitan que el proceso sea

realizado ad hoc.

Cabe anotar la frase “No utilice la incertidumbre como una excusa para la falta de

precisión” La incertidumbre no puede ser la justificación para que la ingeniería de

requisitos sea un proceso ad hoc, se debe recurrir más bien a la utilización de técnicas tales

como prototipos para generar claridad. [20]

Implicaciones: Este estudio pudo detectar en medio respecto a la utilización por los

desarrolladores de prácticas ad hot en requisitos según la hipótesis nueve (9) que las

empresas no llevan a cabo la mayoría de tareas de la fase de análisis de requisitos, por

considerar que dichas tareas forman parte de la fase de análisis del sistema. Por lo tanto se

presentaron dificultad en establecer una frontera clara entre el análisis de requisitos y el

análisis del sistema y se presentó esta como una necesidad de que las metodologías

establezcan objetivos claros de alcance que diferencie dichas actividades.

Se encontró también que el lenguaje natural seguirá siendo el medio de elección, a pesar de

sus ambigüedades y deficiencias. Sin embargo, puede superar las limitaciones de los

requisitos de almacenamiento si en un documento de texto se utiliza una adecuada

herramienta de gestión de requisitos, que permita almacenar información relacionada con

los requisitos y administrarla con enlaces de trazabilidad entre los requisitos individuales y

otros elementos del sistema, esto ayudará a evaluar el impacto de cambiar o eliminar un

requisito creados ad-doc.

En este sentido aparecen algunas herramientas de ingeniería de requisitos que se han

convertido en herramientas de gran peso, pero en muchos casos, también han sido parte de

la estantería del software, el cambio se debe a las cuestiones de facilidad y a que

comúnmente carecen de las habilidades y los procesos de BA (busines analys) con que

cuentan otras de las herramienta [35].



103

En complemento a lo anterior, está la comprobación, es decir la verificación, que consiste

en la evaluación de la exactitud e integridad de los requisitos, para asegurar que un sistema

diseñado satisfaga las necesidades de los usuarios y sus expectativas y cuyo objetivo es la

verificación y certificar que los requisitos constituyen una base adecuada para proceder con

el diseño, construcción y pruebas de una forma eficaz. Cuando se inspecciona el requisito,

se está evitando el costo de corregir los defectos más adelante en el proceso de desarrollo,

la inspección formal de los requisitos es quizás la más práctica de aprovechar el software de

calidad disponible y evitar que el proceso sea ad hoc.

En el medio de la muestra investigada se reconoce que una adecuada gestión de requisitos

evita que el proceso se realice ad-hoc porque la gestión incluye la evaluación del impacto

de los cambios propuestos, la localización de necesidades individuales de los productos del

trabajo corriente abajo y seguimiento del estado de los requisitos durante el desarrollo.

Además permite monitorear el estado del proyecto para saber qué porcentaje de los

requisitos recibidos se han implementado y verificado, implementado solo, o todavía están

sin realizar completamente. Sin embargo las organizaciones del medio admiten gestionar

requisitos pero reconocen deben hacer ajustes al proceso para realizar una adecuada gestión

que impida que se dé por momentos el desarrollo ad hod.

Otro de los hallazgos para un desarrollo ad hod en el caso de las organización antioqueñas

de Software a medida se presenta por situaciones como falta de coordinación con el tiempo

del cliente por tanto el ingeniero realiza interpretaciones a requisitos vagos, o imprecisos.

Un caso más que genera requisitos a doc. es, el exceso de confianza en los saberes previos

del equipo de desarrollo que lleva a imaginar requisitos que en muchas ocasiones están

fuera del contexto y por tanto no satisfacen las necesidades de esa organización en

particular, aunque si lo hagan en organizaciones con el mismo tipo de negocio.

Se dice además que el exceso de confianza en la labor del experto lleva a que los ingenieros

realicen una pobre labor de Ingeniería de Requisitos dado que consideran la opinión del

experto como la de mayor valor por encima de las de los usuarios del sistema. En sentido

contrario el bajo nivel de conocimiento del negocio lleva a los ingenieros a la falta de

generación de requisitos claves.

En conclusión y dado que en el medio, se presentan la situación planteada en la hipótesis

nueve (9), hoy las organizaciones han creado estrategias para evitar el proceso ad hoc tales

como: tener el proceso de ingeniería de requisitos formalizando, utilizar metodologías que

lo apoyen y realizar seguimientos que midan los niveles de satisfacción de los usuarios

durante el proceso, entre otros, sin embargo, con todo y eso aún existen factores de

ambigüedad en los requisitos como falta documentación clara y de habilidades en la

elicitación acordes con los diferentes stakeholders y desarrollos.

Hipótesis 10: El desarrollo de paquetes software en el proceso de Ingeniería de Requisitos

difiere del proceso utilizado en el desarrollo del software personalizado; y las prácticas



104

tradicionales de Ingeniería de Requisitos del software personalizado no pueden ser

utilizadas para los paquetes de software en lo absoluto.

Fuente: El proceso de Ingeniería de Requisitos para el desarrollo de paquetes de software,

difiere de los requisitos del proceso de ingeniería para desarrollo de software personalizado.

[1] en [31] [100] [98] [44] [51] [55] [78]

Es una realidad que entre el 40% y el 60% de los errores y defectos del software son el

resultado de una pobre gestión y definición de requisitos, en palabras simples, esto significa

que aproximadamente la mitad de los problemas encontrados se podrían haber evitado,

simplemente con dejar claro, desde el principio, lo que el cliente espera del proyecto, bajo

este contexto se deja ver la necesidad manifiesta de tener en el desarrollo de software a

medida, contacto con el cliente y conocer sus necesidades para lograr calidad, mientras que

a esta tarea en el software COTS no se le puede dar cumplimiento detallado dado que no se

tienen clientes específico sino consumidores varios y estrategias de marketing. [44] [63].

No se puede olvidar que en la visión general del proceso de ingeniería de software

personalizada, los requisitos del producto son cruciales para el desarrollo de cualquier

software, ya sea un producto o un sistema personalizado y que mientras que del desarrollo

de software a medida se afirma que la clave para un buen producto radica en que Todos los

interesados del proceso intervengan en los requisitos, el hecho que todos deban aportar

para cumplir con el conjunto los requisitos, las limitaciones y las expectativas hace la gran

diferencia con los productos donde no se tiene conocimiento de tallado de los interesados,

ni de su ámbito que por su diversidad puede requerir de habilidades y capacidades

especiales en el producto. [20]

Se ratifica lo antes mencionado, cuando se afirma que el centro de Ingeniería de Requisitos

es desencadenar el proceso que identifique las necesidades y limitaciones de los distintos

actores de un software y que la obtención se centra en descubrir las necesidades de los

usuarios. Asunto este que en el caso del software a medida se logra mediante la

comunicación directa con los usuarios, el conocimiento y la clasificación de ellos. [17]

Implicaciones: En el medio referente a las organizaciones de este estudio, se entiende que

mientras para el desarrollo de software a medida es necesaria la interacción y conocimiento

con los stakeholders, para el desarrollo de paquetes se debe contar con un excelente proceso

de marketing, se entiende también que el desarrollo de productos de software trae nuevos

retos y oportunidades para las empresas que los desarrollan. Por lo tanto, se necesita

investigación para determinar si las prácticas de Ingeniería de Requisitos para el desarrollo

de software a medida se pueden utilizar para desarrollar productos de software, así estos no

constituyan la base de este tipo de desarrollos, así como si se utilizan enfoques del

marketing de paquetes para orientar algunas particularidades del software a medida.

Este estudio no realiza investigación referente a los procesos de Ingeniería de Requisitos

para productos de software empaquetados, sin embargo si tiene conocimiento y claridad

respecto a algunas prácticas realizadas en el desarrollo de software personalizado que



105

requieren necesariamente la participación del cliente y por tanto, no pueden ser apoyadas

solamente en estrategias de mercadeo, como es el caso de productos COTS. [66]. En conclusión se demuestra la necesidad para la Ingeniería de Requisitos del software a

medida de la presencialidad de los participantes para garantizar buenos resultados finales es en

esencia la participación activa del cliente durante todo el proceso, que este conozca el desarrollo de

software llevado a cabo para su producto y hacer medición de los índices de satisfacción de las

etapas, tener repositorios de requisitos, hacer verificación y validación entre otros.

5.2. Planteamiento del Estudio:

El diseño del estudio, incluye la especificación de los proyectos, criterios y evaluaciones

que deben realizarse, definidos a continuación:

El diseño en una investigación realizada en Antioquia, Colombia, consiste en una ingeniera

de sistemas, especialista en desarrollo software y estudiante de maestría apoyada por

profesor experimentado y experto en el tema Ingeniería de Requisitos, adscrito a la planta

docente de la Universidad Eafit, en el departamento de Informática y sistemas y miembro

del grupo de investigación en desarrollo de software, quienes apoyados por el gobierno

institucional de doce empresas de desarrollo de software a medida y acompañados por

analistas, arquitectos, gerentes de proyecto y gerentes de las organizaciones deciden

investigar las prácticas llevadas a cabo en el proceso de desarrollo software,

específicamente en la Ingeniería de Requisitos, del que se investigan: los principales retos

y desafíos a los que se enfrentan, las organizaciones, sus empleados y sus clientes, vale la

pena destacar además que el estudio se llevó a cabo dentro de las pequeñas y medianas

empresas que desarrollan productos de software de Antioquia Colombia.

Lo anterior es justificable dado que después de Bogotá, es la segunda ciudad más

importante de Colombia. Su excepcional arquitectura, creativo diseño de espacios lúdicos y

sus constantes planes de desarrollo, la han transformado en poco tiempo en una urbe con un

amplio potencial de crecimiento. [45]

Hoy Medellín se ha convertido en un avanzado epicentro de comercio, industria y

tecnología. El 20% de las empresas más importantes del país tienen su sede allí y

mensualmente la ciudad acoge a empresarios de todos los rincones del mundo interesados

en las variadas oportunidades que ofrece la región.

Antioquia alberga un potencial en los sectores de tercerización de servicios, software y

servicios TI, cosméticos y productos de aseo, e infraestructura de hotelería y turismo. La

ciudad cuenta con un moderno sistema urbano de transporte metro, y tiene 2 aeropuertos: el

internacional José María Córdova, situado en el vecino municipio de Rionegro; y el Olaya

Herrera, destinado a vuelos regionales y nacionales, lo anterior teniendo en cuenta que El

gobierno está decidido a apoyar y dar impulso al sector por medio del Programa de

Transformación Productiva, como una estrategia consolidada para el fomento y crecimiento



106

de sector, que en los últimos años han generado un ambiente adecuado para su

potencialización y reconocimiento a nivel mundial.[45]

En general en Colombia:

- La industria de Software ha crecido 230% en los últimos 5 años.

- Demuestra su compromiso con el sano desarrollo de la industria, junto con Brasil, ya que tiene la tasa de Piratería más baja de la región, 53% 2011.

- Cuenta con una infraestructura capaz de soportar operaciones de talla mundial, con

5 cables submarinos que generan un ancho de banda de 550 GPS.

- Entre 2005 y 2011 los ingresos del sector de TI en Colombia se triplicaron.

Es importante añadir que la búsqueda y el estudio bibliográfico motivo a la elaboración de

este estudio porque en ellos, permitieron la observación de saberes similares llevados a

cabo por investigadores de las compañías de software de otros países donde se presenta los

resultados preliminares de un estudio como el de Suecia en cinco empresas que desarrollan

productos de software. El objetivo de este estudio fue investigar las características de las

empresas, el proceso de desarrollo y cuestiones relacionadas con los artefactos generados

durante la ingeniería de requisitos. Como dato curioso está, que los estudios no mencionan

las actividades relacionadas con el proceso de experimentación. [1] en [55], [27].

Complementando lo anterior están también como motivación el proyecto WEST, quien

incluyó dentro de sus tareas la implementación de una nueva metodología de Ingeniería de

Requisitos (IR) en la industria de Antioquia-Colombia en (IDEAS 2004) [2]

Y finalmente pero no menos importante está el estudio para tesis doctoral que apoya esta

investigación y que es un estudio, empírico en trece empresas que desarrollan software

productos de Recife - Pernambuco. El estudio empírico se basa en Ingeniería de Software

Experimental y el paradigma cualitativo, y tiene como objetivo investigar las prácticas se

llevan a cabo y se enfrentó a los principales retos y problemas de las empresas pequeñas y

medianas empresas durante el proceso de Ingeniería de Requisitos.[1]

Por otra parte en el tema referente a este tipo de investigación, consiste en la búsqueda del

conocimiento refinado en cuestiones particulares y el contexto donde se encuentran, la

metodología cualitativa, sería más apropiado para el estudio. Inferir que el uso de un

método cuantitativo solo, podría no ser adecuado para el estudio porque se centra en la

generalización de la información recogida para toda la población (como para un censo de

población, por ejemplo).

Referente a la recopilación de la información inicialmente se realizó un estudio con el fin

de recopilar información sobre las empresas que desarrollan productos de software en

Antioquia. Luego se realizaron contactos para la promulgación del estudio, y así se

describió la finalidad y se estableció el contacto empresarial de gobierno, al que luego se

envió información detallando el estudio y anexando la encuesta y una contextualización,



107

posterior a esto se estableció nuevamente contacto y se gestionó cita para la entrevista

donde se concretó que previamente a esta cita la organización debían enviar diligenciado el

instrumento encuesta y los datos de las personas por esta para representar a la organización

para finalmente visitar las organizaciones y aplicar la entrevista.

Referente a los datos elegidos para incluir en la encuesta, estos fueron seleccionados, con la

finalidad de lograr contextualizar la organización. Algunos de ellos fueron: número de

empleados que laboran en la organización, número empleados dedicados directamente al

proceso de desarrollo, certificaciones de la organización, certificaciones de los empleados,

tiempo de experiencia de los empleados, roles presentes en la organización, nichos de

mercado que atiende la organización, metodología de desarrollo utilizadas, ubicación de los

clientes atendidos, tipos de software desarrollado, niveles de satisfacción de los clientes

entre otras.

Como resultado de la investigación se obtuvo una lista con doce (12) empresas interesadas

en participar en el estudio prospectivo y que cumplían requisitos tales como tener

experiencia en el medio superior a dos años, contar con certificaciones de calidad y realizar

proceso de Ingeniería de Requisitos. Lo anterior, previa presentación del estudio y los

objetivos ante el gobierno de la organización. Con estas empresas se establecieron

contactos vía email y telefónicos, se les enviaron los instrumentos de encuesta y entrevista

y la solicitud de agenda para la entrevista, con los requisitos de resolver previamente la

encuesta, ser parte activa del proceso de desarrollo de la empresa.

A fin de establecer la muestra del estudio, todas las empresas fueron invitadas a través del

teléfono y por e-mail y agendada y confirmada la invitación.

Complejidad: La complejidad estuvo basada en la comprensión de las actividades que

desempeña cada organización al interior de sus proyectos, su manera de ejecutar los

procesos y la obtención del conocimiento tácito en referencia al proceso de desarrollo

software y más específicamente a la Ingeniería de Requisitos de donde se investigaron

aspectos como:

La manera como se tiene formalizado el proceso de Ingeniería de Requisitos en la

organización

La metodologías utilizadas durante el proceso

Los insumos que utiliza la organización en el proceso de Ingeniería de Requisitos

El tipo de metodología que utiliza la organización durante el proceso de Ingeniería

de Requisitos

El futuro que espera la organización del proceso de Ingeniería de Requisitos que

realiza

El manejo de los clientes críticos

Los aspectos a mejorar en el proceso de ingeniería requisitos en la organización

La Ingeniería de Requisitos en la organización y los procesos que apalanca

Descripción de las estrategias utiliza la organización para involucrar al cliente en el

proceso de Ingeniería de Requisitos



108

Las técnicas de priorización de requisitos.

Las técnicas de gestión de requisitos

El proceso de gestiona el cambio

Las propiedades deseables de los requisitos

Las herramientas de gestión de clientes utiliza la organización

Algunas situaciones que demuestran aspectos a mejorar en el proceso de Ingeniería

de Requisitos de la organización.

Estrategia para gestionar los cambios y versiones de los requisitos

Proyectos que presentan mayor destreza y fuente de éxito para la organización al

realizar el proceso de ingeniería de requisitos

Referente al método científico utilizado para este estudio, en concordancia con [1] en [95],

el método científico puede ser considerado algo así como un telescopio, las lentes de

diferentes aberturas y distancias producen diferentes formas de ver los fenómenos y/o el

objeto de estudio. Por lo tanto, el uso de sólo un punto de vista no puede proporcionar un

resultado satisfactorio o representación del espacio que desea entender. Basados en lo

anterior, este estudio tiene claridad respecto a situaciones reales. Consciente de que nuestro

comportamiento y pensamiento humano está frecuentemente influido por muchos y

diferentes factores consecutivos y no simplemente por un solo factor, este estudio busca

tener fuentes bibliográficas de apoyo frente a cada uno de los resultados.

En ese mismo sentido a nivel de herramientas de investigación el uso de sólo una

herramienta de investigación podría derivar resultados parciales del objeto de estudio. Otra

consideración importante es que la elección de una u otra técnica de recogida de datos

deben estar alineadas con las estrategias de análisis y la interpretación de los datos. Por

tanto, los instrumentos de recolección de datos deben garantizar la clasificación,

codificación y categorización del material empírico. Así, se prevé la elaboración de un

cuestionario y luego la realización semi-estructurada y semi-estandarizada para asegurar la

comparecencia de la técnica y la alineación para el análisis y la investigación propuesta por

el estudio.

Así entonces, el cuestionario está dirigido a obtener información general sobre las

empresas, como la identificación del encargado del proceso y de la empresa misma, sus

principales características respecto a los productos ofrecidos al mercado, el proceso general

de desarrollo y la ingeniería requisitos adoptada.

El envío previo de los instrumentos como la entrevista y encuesta, incluyó la definición de

una estructura y el diseño que permitió la contextualización del estudio con temas como:

objetivos, descripción de la investigación, beneficios para las empresas entre otros.

Preparación de las preguntas: En dicha preparación se tuvieron en cuenta las

características del estudio y las ventajas y desventajas que aportan la realización de

determinado tipo de preguntas cerradas o abiertas para este, encontrando que: las preguntas

abiertas admiten identificar fortalezas y debilidades en el razonamientos, ofrecen

oportunidades de retroalimentación, lo que a la luz de este estudio permite encontrar las



109

mejores prácticas que es el objetivo principal del estudio por otro lado es necesario realizar

mediciones exactas identifiquen tendencias para lo cual fue necesaria la utilización de

preguntas cerradas.

Por lo tanto, se realizaron preguntas abiertas y cerradas, con el uso de éstas pretendió

responder a la información. Con las primeras se logró buscar más información o punto de

vista acerca del entrevistado (preguntas abiertas) y con las segundas, tener datos

preestablecidos y fijos (preguntas cerradas).

Referente a los instrumentos: se realizaron encuestas y entrevistas, la utilidad que se logró

de la encuesta fue proporcionar una clasificación más fácil de ciertas variables. Además de

poder averiguar datos y circunstancias referentes al contexto y al público que sería

entrevistado. En cuanto a la entrevista se utilizó la ya mencionada semi-estructuradas y

semi-estandarizada buscando obtener el conocimiento del usuario sobre el tema y la

estructura del ambiente, en este caso conocer la manera como es llevado a cabo el proceso

de Ingeniería de Requisitos en las empresas antioqueñas de software. En ese contexto, con

la entrevista se logró el objetivo principal de la investigación y una mayor exploración de

las cuestiones pertinentes dentro del objeto de estudio.

Dentro de la planificación para realizar la entrevista se tuvo en cuenta: La especificación de

la metodología que se utiliza, especificación de los objetivos que se persiguen con la

conclusión de las entrevistas desarrollo de preguntas abiertas para obtener el foco de

estudio. Los modelos de los instrumentos utilizados tanto entrevistas como encuesta se

pueden ver en el apéndice A y B respectivamente.



110

Figura 27. Actividades Realizadas durante la especificación del estudio

5.3. Finalización del Estudio

Este trabajo, adoptó los métodos de investigación donde se contextualizaron el tipo de

organizaciones, elementos del estudio, investigación de los fenómenos y el contexto en que

ocurren, los desafíos y mejores prácticas de Ingeniería de Requisitos utilizadas por las

organizaciones pequeñas y medianas que desarrollan productos software a medida en una

región la región Antioquia Colombia. [2]

Referente al método de investigación elegido que fue el paradigma cualitativo su elección

se basó en los siguientes puntos:

1. Entender el problema y el enfoque de los métodos de investigación (cualitativa y

cuantitativa): Basado en los detalles del problema y en el cómo el tema fue elegido para ser

estudiado, junto con el estudio de los conceptos relacionados con los métodos de

Búsqueda en internet de las organizaciones

Anális de la información

Envío invitación y contextulización del

estudio

Recepción de respuesta

Comunicación telefonica

confirmando participación

Recepción de datos de asignados

Envío de instrumentos encuesta

Solicitud de agenda de cita de entrevista

Envio e instrumento entrevista

Realización de la entrevista y

recolección de datos encuesta

Especificación del Estudio



111

investigación, de la adecuación del objeto de estudio de las estrategias y objetivos

presentados por el método cualitativo, ya que se propone la investigación de los fenómenos

y el contexto en que ocurren.

2. El carácter exploratorio de la investigación. El tema en cuestión, es decir, “Estudio

empírico sobre el proceso y la productividad de la Ingeniería de Requisitos en las empresas

antioqueñas de software” está investigando los desafíos de las prácticas de Ingeniería de

Requisitos utilizados por las empresas pequeñas y medianas que desarrollan productos de

software y está sujeta al carácter exploratorio, por lo tanto cumple con el objetivo de la

investigación, la información cualitativa y la búsqueda de temas específicos.

3. Los elementos en el estudio, las personas o situaciones, pueden no ser suficiente para

generar estudios de cuantificación y descubrimiento generalizado, por lo que mediante el

método de búsqueda cuantitativa podría no ser adecuado. La definición del experimento se

completó con el límite del estudio propuesto. Ella es investigar las prácticas de Ingeniería

de Requisitos realizados por empresas pequeñas y medianas empresas que desarrollan

productos de software a medida de Antioquia, Colombia.

Se concluye que la revisión de la literatura se consideró relevante, ya que trató de adquirir

el conocimiento de la zona, tales como definiciones, contextualizad y obras relacionadas,

entre otros. Se podría decir que esta es una actividad común en cualquier estudio científico

y su objetivo es construir una base de conocimientos sobre el objeto original que desea

estudiar.

Como se mencionó anteriormente, dentro de los métodos utilizados para este estudio

empírico fueron los análisis cualitativos los que llevaron a la apropiabilidad de las teorías,

acorde con la perspectiva de los participantes y su diversidad, con la reflexividad del

investigador y la investigación, además se generó apoyo para los resultados de una variedad

de enfoques y métodos, que llevaron a la comprensión con el principio epistemológico, a la

reconstrucción de los casos como punto de partida y a la construcción de la realidad como

base.

Desde el análisis de problemas y planificación de los procedimientos del estudio se llevaron

a cabo: los cuestionarios, el análisis preliminar de los cuestionarios, entrevistas y los

análisis preliminares. En este sentido la Figura 27. Actividades Realizadas Durante la

Especificación del Estudio, compendia cada una de las actividades mientras que la Figura

28. Actividades de Validación y Control de las Herramientas de Investigación, detalla cada

de las actividades tenidas en cuenta para la utilización del instrumento.



112

Figura 28. Actividades de Validación y Control de las herramientas de investigación

La pre-prueba a los instrumentos se realizaron con base en los conocimientos del asesor

miembro del grupo de investigación en desarrollo de software y en la experiencia lograda

durante el evento WER 06 (Taller de Ingeniería de Requisitos), celebrada en Río de

Janeiro en julio de 2006 [46].

El cuestionario se aplicó también a un grupo de tres expertos de las compañías de software,

con el objetivo de asegurar que las preguntas eran claras y fáciles de entender. En esta

prueba antes de los tres expertos tenían las mismas características de la muestra

seleccionada, sin embargo, no formaban parte de la muestra especificada.

El propósito de las pruebas preliminares es proporcionar el descubrimiento o la discusión

de la información y los ajustes que permiten que sea posible, la corrección de errores y

defectos contenidos en las preguntas. A partir de entonces se puede dividir el estudio en dos

etapas. El primero se caracteriza por la aplicación y el análisis preliminar del cuestionario y

el segundo para la realización y análisis preliminar de entrevistas semi-estructuradas con

semi-estandarizado para cada empresa participante. [47]

Referente al tiempo dedicado por las personas al diligenciamiento de los instrumentos

podemos afirmar que la encuesta contiene treinta y nueve (39) preguntas, lo que requería la

parte demandada de tres horas (3) dado que los datos de contextualización de la

organización que allí se pidieron requerían búsqueda en diferentes fuentes de información

de la compañía. Mientras que la entrevista se realizó con veintiuna preguntas (21) de donde

se obtuvieron los datos referentes a las mejores prácticas y experiencias durante el proceso

y se logró realizar, previo envío del instrumento en una hora (1) presencial.

Referente a los roles que desempeñan los encuestados dentro de las organizaciones

tenemos: Coordinador de Investigación y Tecnología, Gerente de producción,

Vicepresidente de Servicios de Ingeniería, Directora de Entrenamiento, Gerente General,

Analistas de requisitos, Analistas de calidad. A todos ellos se les suministraron los

•Analisis preliminar

•Corrección

•Aplicación

•Recolección y revisión

Realización de cuestionarios

•Analisis preliminar

•Corrección

•Aplicación

•Recolección y tabulación

Realización test entrevista



113

instrumentos acompañados de las características básicas del estudio como objetivos y la

importancia que para la industria del software representa tener datos confiables.

Además es importante anotar otro aspecto del paradigma cualitativo de acuerdo con [48],

en este paradigma, la clasificación tiene en cuenta el punto esencial, el punto de vista de los

participantes y su diversidad de opiniones, las prácticas llevadas a cabo, así como los

significados subjetivos y sociales relacionados. El análisis preliminar de los instrumentos se

completó con una reunión cuyo propósito fue promover la discusión de la información que

se encuentra en ellos y hacer hincapié en los detalles importantes a considerar cuando se

realizan entrevistas, que se iniciaron posteriormente, con el envío previo de los

instrumentos, la solicitud de agenda y teniendo presente que el entrevistador no impusiera

sus puntos de vista sobre el entrevistado y que se cumplieran con este instrumento los

siguientes objetivos básicos:

Las oportunidades de mejoras en los procesos de Ingeniería de Requisitos.

La metodología utilizada para garantizar el adecuado manejo de los datos de la entrevista

fue grabar la entrevista y transcribirla según se estipuló, a más tardar siete días después de

su ejecución con el fin de facilitar la redacción de los textos. Posteriormente, los textos

preparados de acuerdo con las transcripciones de las entrevistas fueron revisados, con el

objetivo de asegurar la exactitud y uniformidad del proceso.

Los datos posteriormente y con el objetivo de detectar los grandes grupos de variables se

segmentaron y categorizaron según la interpretación del investigador. Quien finalmente

presenta las pruebas que hacen referencia a las categorías, en el análisis descriptivo a través

de tablas y figuras. Teniendo en cuenta que la actividad de presentación de prueba sobre la

base de material empírico es la clasificación selectiva.

5.4. Observaciones finales

En este capítulo se presenta la definición, planificación y ejecución del estudio empírico

con doce (12) empresas que desarrollan productos de software a medida en Antioquia. La

metodología utilizada se basó en el paradigma cualitativo, ya que su principal objetivo es la

búsqueda del conocimiento perfeccionado a lo largo cuestiones complejas y particulares, y

es compatible con el objeto de estudio. Otro punto importante es que el enfoque cualitativo

se compone de pasos y técnicas que fomentan las preguntas la comprensión, la

investigación y el análisis de "por qué" y "cómo". Por lo tanto en objetivo principal de este

estudio fue investigar cómo las pequeñas y medianas empresas que desarrollan productos

de software logran llevar a cabo los requisitos en el proceso de ingeniería software y cuáles

son los principales retos y problemas enfrentan.

Buscando la correcta clara e imparcial representación de los resultados, el área de estudio

se encasillo en dos instrumentos de recogida de datos: encuestas y entrevistas semi-

estructuradas y semi-estandarizadas.



114

El cuestionario dirigido a obtener información general sobre las empresas, como la

identificación del demandado y la empresa, las principales características de los productos

ofrecidos y el proceso de desarrollo, y cumplir con las actividades de Ingeniería de

Requisitos adoptados por ellos, y la entrevista con el objetivo principal la investigación y

una mayor exploración de las cuestiones pertinentes dentro del objeto de estudio, es decir,

el Proceso de Ingeniería de Requisitos realizado en las organizaciones.

En el siguiente capítulo se presentarán los resultados e interpretaciones de los datos

obtenidos.



115

6. CAPITULO RESULTADOS DEL ESTUDIO EMPÍRICO

En este capítulo se presenta la interpretación del estudio empírico y los resultados

obtenidos a partir de la realización del estudio llevado a cabo entre las empresas que

desarrollan productos de software en el departamento Antioquia. Los resultados se

organizaron analizando aspectos como: la manera de generar deducciones, la

caracterización de las empresas del estudio, identificación de aspectos positivos y mejoras

los resultados obtenidos en algunas etapas del proceso de Ingeniería de Requisitos y los

desafíos que enfrentan durante el proceso, para llegar después a la validación de las

hipótesis y a la generación de algunas consideraciones finales. [1].

Este capítulo ofrece información respecto a las organizaciones considerando aspectos

cómo: Las metodologías de desarrollo que utilizan, los tipos de productos que desarrollan,

las etapas de desarrollo que llevan a cabo y el manejo de los repositorios.

En cuanto a los empleados adscritos al proceso de desarrollo software, el capítulo hace una

diferenciación tomando el número de empleados que laboran con la organización y cuántos

de ellos están directamente involucrados en el proceso de desarrollo software y de estos,

sus niveles de experiencia, dominio de inglés, certificaciones, tiempo de vinculación y

rolles en la organización, entre otros.

Referente a los clientes, el capítulo muestra los nichos de mercado que atienden, los

tipifica, indaga por los niveles de satisfacción, los tipos de contratación que se generan y el

nivel de conocimiento de los clientes respecto al proceso de desarrollo software.

Del proceso de ingeniería de software en general este capítulo genera datos respecto a los

roles asignados por las organizaciones, las metodologías de desarrollo, lenguajes más

utilizados, el seguimiento que se realiza a los productos entregados, la gestión realizada por

las organizaciones para generar nuevas versiones del producto, el tiempo de entrega entre

versiones y finaliza con los datos porcentuales de desarrollo de nuevos productos,

migración, componentes y mejores prácticas de seguimiento a las versiones y productos

finales, termina esta sección con el control de tiempo de entrega entre versiones.

Respecto al proceso de Ingeniería de Requisitos este capítulo presenta el detalle de los

insumos, la metodología, los aspectos críticos, las herramientas y las mejores prácticas.

6.1. Interpretación del Estudio

La declaración de los datos de este estudio consistió en lograr primero la interpretación de

los instrumentos, entrevistas, encuestas, posteriormente los resultados obtenidos fueron



116

sometidos a debate con el asesor para generar el análisis preliminar y para reiterar la

concordancia con los objetivos del estudio.

A continuación, se analizaron los datos y se concretó la forma de redacción de los

resultados. Por último, se tuvo en cuenta presentación del producto, con este fin se examinó

la conveniencia de las diferentes maneras de presentación de los resultados y la forma de

hacerlo sin desviar la atención frente al objetivo de la investigación, teniendo en cuenta,

que hasta hace poco tiempo un estudio de este tipo no se realizaba con métodos

cuantitativos, sino cualitativos, pero retomando por otro lado la necesidad de utilizar

métodos que permitan la clasificación y caracterización de la información.

Por lo anterior, basados en la premisa de que la investigación cuantitativa se dedica a

recoger, procesar y analizar datos, que precisamente lo que este estudio requiere; el análisis

de aspectos relacionados con tendencias, muestras de muchas comparaciones, producto de

resultados matemáticos claramente se requiere el uso de la metodología cuantitativa. Lo

anterior apoyados en que “el aspecto cualitativo de la investigación no se pierde cuando la

información se transforma en datos cuantitativos con el fin, de garantizar la precisión en

términos de resultados”. [2] en [95],

Actividades efectuadas para la caracterización

- Previa recolección de los datos, se realizó la interpretación con un análisis individual de las organizaciones, lo que permitió la formulación de los aspectos relevantes

relacionados con la propuesta base de este estudio a saber: Encontrar las mejores

prácticas, necesidades, retos y desafíos que enfrentan las empresas que desarrollan

productos de software en el departamento de Antioquia.

- Se almacenaron las pruebas de toma de referencia basadas en el material empírico

mediante clasificación selectiva. Con ello se formularon categorizaciones y se

realizaron tablas de las categorías y los resultados.

6.2. Resultados

Uno de los objetivos al caracterizar las organizaciones fue la obtención de los resultados

que como derivación permitió la detección de los aspectos positivos, a mejorar, las mejores

prácticas y necesidades que enfrentan las empresas adscritas al estudio durante el proceso

de Ingeniería de Requisitos. La caracterización del estudio se enfocó en cuatro (4) aspectos

fundamentales para cada organización.

o Aspectos para definir las organizaciones del estudio.

o Aspectos que identifican a los empleados adscritos al proceso de desarrollo

software.

o Aspectos que definen el proceso de desarrollo software en la organización.

o Aspectos que caracterizan el proceso de Ingeniería de Requisitos.



117

La obtención de los resultados de este estudio se apoyó en la evaluación de hipótesis y se

expresa los valores porcentuales acordes con la cantidad de organizaciones que

respondieron cada pregunta.

6.2.1. Caracterización de las Organizaciones

Se utilizaron como instrumento para la caracterización de las organizaciones los

cuestionarios, que fueron elaborados con el objetivo de obtener información del contexto de

las empresas adscritas en aspectos como: cantidad de empleados involucrados directamente

al proceso de desarrollo software, las certificaciones, dominio del segundo idioma entre el

grupo de empleados, tiempo de vinculación en la organización, roles, estrategias de

actualización para el grupo de empleados, los principales nichos de mercado para la

organización, sus clientes, metodologías y estrategias utilizadas en el proceso de desarrollo

software en general y específicamente en la Ingeniería de Requisitos.

Basado en lo anterior, es claro que los cuestionarios, como herramienta de investigación,

han permitido la formulación de resultados preliminares acerca de la caracterización de las

empresas, por consiguiente se requiere preservar loa niveles de confidencialidad de las

organizaciones clasificándolas a lo largo del estudio con letras.

Posteriormente se clasifican las organizaciones según la definición de Tamaño Empresarial

Micro, Pequeña, Mediana o Grande empresa, según los lineamientos dictados por el

ministerio de Comercio de Industria y comercio "Definición de las Micro Pequeña y

Mediana Empresa, en aplicación del parágrafo 2o del artículo 43 d la ley 1450 de 2011 y se

realiza como hallazgo importante que la mayoría de las empresas son identificadas como

pequeñas y medianas, como lo evidencian los resultados de la Tabla 3. Este es un aspecto

que posee gran importancia para esta investigación, dado que varios estudios han

demostrado gran relevancia y necesidad de que las empresas medianas y pequeñas adopten

buenas prácticas para el proceso de desarrollo software, lo que es una base para afirmar que

de persistir y crecer, las pequeñas empresas de software necesitan soluciones eficientes y

efectivas de ingeniería de software. [58][49].



118

Tabla 3. Caracterización de las Empresas

Empresa Años Número total de empleados

en la organización

Número de empleados

dedicados al proceso de

desarrollo software

A 15 850 350

B 08 76 70

C 05 340 140

D 25 350 320

E 16 No responde No responde

F 16 No responde No responde

G 11 No responde No responde

H 05 37 37

Cabe agregar, que las empresas demostraron gran interés en generar productos de calidad y

en medir sus procesos para lograr mejora continua y estándares de calidad. Este dato cobra

gran relevancia cuando se evidencia el papel fundamental que cumplen las pequeñas y

medianas empresas en el tejido industrial de los países y sus esfuerzos por adoptar prácticas

eficientes y de calidad eficientes como lo citan en Competisoft: “Las micro, pequeñas y

medianas empresas -Pymes- son una pieza muy importante en el engranaje de la economía

mundial. La industria del software en la mayoría de los países está formada por tejido

industrial compuesto en gran parte por Pymes desarrolladoras de software. Para fortalecer

este tipo de organizaciones se necesitan prácticas eficientes de Ingeniería del Software

adaptadas a su tamaño y tipo de negocio. La comunidad de Ingeniería del Software en la

última década ha expresado especial interés en la mejora de procesos software con el fin de

aumentar la calidad y productividad del software…”. En este sentido las organizaciones

expresaron tener como meta fundamental la conservación de las certificaciones y buenas

prácticas actuales a las que están llevando a medir para lograr mejora continua de los

procesos. [50]

Las Certificaciones que presentan las empresas participantes en el estudio son:

- ISO 9000 y CMMi nivel 5

- CMMI NIVEL II

- CMMi dev nivel 3.0, ISO 2001: 2008

- Software Process Achievement Award, IEEE/SEI Software Process Achievement Award 2006. Ganador del premio a la excelencia otorgado por el Instituto de

Software de Europa (European Software Institute), Nivel 5 del modelo CMMI ,

Nivel 5 del modelo SW – CMM, Certificación ISO 9001:94 y 2000, Certificación

ISO 27001

- Proceso de certificación CMMI nivel 3



119

Ligado a lo anterior este estudio consultó las metas de calidad a corto mediano y largo

plazo de las organizaciones encontrando como base común:

- Metas a corto plazo : Ser Nivel 3 de CMMI

- Metas a mediano plazo: Ser CMMI NIVEL III, CMMi for Services nivel 3.0

- Metas a largo plazo: Adoptar las practicas Itil

Resultados como los expresados anteriormente, llevan a pensar que el tema de metas

institucionales es de gran importancia para realizar investigaciones futuras, sin embargo,

partiendo de los objetivos de esta investigación, se enumeran las metas de las

organizaciones y se clasifican como metas a corto, mediano y largo plazo.

6.2.2. Caracterización de los Empleados Adscritos a la Organización

Conocidos ya aspectos generales de las organizaciones y sus metas, este estudio se enfoca

ahora a generar una contextualización de los empleados que laboran en las organizaciones y

que están adscritos directamente al proceso de desarrollo software e intervienen en la

calidad de los productos.

Unido a lo anterior y teniendo en cuenta además, la necesidad en el medio de desarrollo

software, el cual requiere personas con perfil técnico a nivel de conocimientos certificados

y acreditados y con una buena preparación académica y humana para cimentar esas

capacidades técnicas en las llamadas fortalezas complementarias, hoy totalmente

prioritarias como lo citó Churchill: “las actitudes son más importantes que las aptitudes”.

Complementando lo anterior, se dice que la base de la estructura de una organización de TI

competitiva que desarrolla software, debe ser el recurso humano calificado, y que para

lograrlo la organización debe ofrecerles oportunidad de seguir avanzando en su desarrollo

profesional, el solo pregrado, no es suficiente, se requieren especialistas, profesionales con

maestrías y doctorados en áreas de la tecnología de la información, con estos niveles es que

se puede competir y ganar espacios en la comunidad mundial. En la medida que se cuente

con un recurso de alto nivel de formación, se tendrá más capacidad de crear e innovar,

además es evidente que las compañías que contratan servicios, se sienten mejor respaldadas

con personas que tengan competencias humanas y no solo técnicas. [14]

En virtud de lo anterior, nos podemos centra en que son los empleados adscritos al proceso

de desarrollo software, deben lograr entender las necesidades de las organizaciones

compuestas por personas, que requieren los servicios de desarrollo software, y son

precisamente estas personas con quienes es necesario interactuar hasta lograr su

satisfacción con los productos entregados, satisfacción que solo se logra cuando la

interacción con el usuario es adecuada como resultado de un trabajo coordinado en el

equipo al interior de la compañía de desarrollo y producto software, lo que es la

demostración evidente de que los equipos de desarrollo software deben ser formados con

personas con capacidades no solo técnicas sino con amplio desarrollo humano. [14]



120

Como investigación de lo anterior, se decide conocer algunos aspectos de los empleados

que actualmente hacen parte del proceso de desarrollo software en las organizaciones tales

como: el dominio de inglés, necesario entre otros para el cubrimiento de la atención y la

comunicación con los clientes extranjeros, los niveles de experiencia, la estabilidad laboral

y las certificaciones entre otros.

Tabla 4. Nivel de inglés entre los empleados adscritos al proceso de desarrollo

software

Organización Nivel de Inglés

Alto Medio Bajo

A 14% 43% 43%

B 21% 36% 43%

C 8% 33% 58%

D 11% 20% 69%

H 24% 52% 24%

Al interpretar la figura1, se observa como en quince (15) datos pertenecientes a cinco (5)

organizaciones el nivel de inglés es bajo entre el grupo de los empleados adscritos al

proceso de desarrollo software es del 40% en contraste con el nivel alto que no sobrepasa

en ninguno de los casos el 24% de los empleados de las organizaciones.

El factor anterior nivel de inglés cobra gran relevancia para el avance y desarrollo de la

industria del software en la región dado que tiende a limita o a impulsar la incursión de

clientes extranjeros, esto solo por señalar un aspecto importante, sin tener en cuenta las

deficiencias técnicas que un disminuido manejo de inglés genera entre los empleados a

causa de que la gran mayoría de la tecnología se escribe en inglés, lo que lo vuelve un

medio directo de acceder al conocimiento de tecnologías de punta. [28]

Así lo ratifican dos (2) grandes conocedores de la industria del software en la región a un

periódico, donde los empresarios Juan José Mejía y Jorge Aramburo afirman: Concluyen

que la falta de talento calificado en áreas específicas de tecnologías y la falta del idioma

inglés, están generando una barreras sicológicas para concretar los planes de expansión en

la región de las grandes empresas de tecnología. "Sin inglés no se puede aprender a la

velocidad que se produce la tecnología…, ni se puede exportar", añade Aramburo. [51].

“Es tan importante que se lea inglés como si lo hiciera en español; vale, por lo menos, que

se escuche aunque no se hable, porque todo el conocimiento que se deriva de las empresas

está en la web”. [51].



121

"La tecnología se escribe en inglés y ya no se traduce. Este es el idioma en el que habla el

mundo, el que le meta ideología a esto es un tonto", remata Aramburo. [51].

En esta misma publicación el doctor Camilo Gómez director de C2 Game Studio, afirma

respecto a las características básicas que deben perfilar a un empleado de desarrollo

software. “el buen dominio de dicho idioma es básico, así como la adaptación al cambio y

la voluntad para el aprendizaje continuo”.

Gráfica 1. Dominio de inglés entre los empleados adscritos al proceso de

desarrollo software

La gráfica 1, Dominio de inglés entre los empleados adscritos al proceso de desarrollo

software, evidencia otra lectura de los niveles de dominio de inglés entre los empleados

que intervienen directamente en el proceso de desarrollo software en la región, se observa

cómo más de la mitad de los empleados de las organizaciones en general, un 53% presentan

niveles de dominio de inglés catalogados como bajos y sólo el 13% presentan niveles altos

de dominio de inglés.

Es entonces el nivel de inglés un factor que debe fortalecerse en el medio de las empresas

antioqueñas de software para lograr tener libertad en el momento de asumir clientes y retos

propios de la globalización. Además el fortalecimiento en los niveles de inglés debe

apalancar el logro de avances significativos en la capacitación técnica que los empleados

deben alcanzar dentro de la llamada sociedad del conocimiento, que exige certificaciones y

dominio de nuevas tecnologías.



122

No obstante los niveles de experiencia de los empleados en las organizaciones juegan un

papel importante en la clasificación de los equipo de trabajo que apoyan el proceso, por

tanto este estudio realizó investigación encontrando los resultados que se evidencian en la

gráfica 2, a saber: El 10% de los empleados adscritos al proceso de desarrollo software

poseen más de 10 años de experiencia mientras que la concentración mayor de niveles de

experiencia se encuentra entre los 1 a 5 años de vida laboral, reiterando estas cifras lo

nuevo de la disciplina ingeniería de software con relación a otras disciplinas y que en

consecuencia requiere vivenciar muchas experiencias para lograr un surgimiento de

competencias adecuadas basadas en la experiencia.

Gráfica 2. Experiencia laboral

A razón de lo anterior se esbozan en el estudio algunas expresiones con respecto a las

consecuencias que para las empresas generan los altos índices de rotación de los

empleados: “Los costos generados por nuevas curvas de aprendizaje son altos”, “la baja

productividad en los proyectos es casi siempre una consecuencia”, “esto hace que se

presente cambio en el nivel de desempeño de la organización”, “tenemos dificultades de

adaptación en el equipo” las anteriores son por poco sólo algunas de las dificultades

causadas pues las empresas quienes coinciden en que la alta rotación conlleva directamente

a la afectación en la calidad del producto, dado que genera reproceso y tiempos adicionales

que hacen que los clientes se sientan insatisfechos con el proceso y en algunos casos hasta

con el producto que no satisface completamente las necesidades expresadas desde el inicio

del proyecto.

Este estudio decide, apoyado en lo anterior, conocer el porcentaje de tiempo de vinculación

de los empleados con la misma organización, en la figura 4 se observan los resultados de la

rotación de los empleados y se muestra que el 59% de ellos permanece entre uno (1) y

cinco (5) años en la misma organización, se observa además un notable descenso en la

estabilidad luego de cinco años donde el resultado cambia de 59% a 12%. Según la gráfica



123

3. Tiempo de Vinculación de los Empleados con la misma Organización.

Gráfica 3. Tiempo de Vinculación de los Empleados con la misma Organización

Los resultados anteriores muestran la necesidad de repensar estrategias que generen

estabilidad en los empleados del equipo de desarrollo, teniendo presente que los factores

motivadores para ellos no son necesariamente económicos a consecuencia de que cada persona

tiene necesidades y prioridades diferentes, hay quienes consideran estímulos, a los asensos, la

asistencia a cursos, los días libres, etc., Aunque es innegable que el buen apoyo económico es

necesario es importante considerar que con este tipo de estímulo se corre el riesgo de perder el

objetivo de estímulo y pasar a ser visto como una justa retribución por la labor realizada, y por

tanto sentir el empleado aún la carencia de estímulo por la organización, según lo apoya

Microsoft en la su página Pymes Autónomos donde realiza una serie de planteamientos

referentes a las maneras de motivar a sus empleados, para ello se apoya en pensamientos de

autores y se centra básicamente en descubrir los porqués de la conducta humana y a partir de

allí se generan planteamientos como: “Las empresas que cuentan con personas motivadas son

también las que presentan mejores números en la cuenta de resultados”. “Las personas que

tienen una alta motivación suelen rendir más en sus trabajos, aprovechan mejor el tiempo y

alcanzan con mayor facilidad los objetivos marcados por la empresa. Esto supone un claro

beneficio tanto para la empresa como para el propio empleado”. Él articulo además fija diez

(10) ejes de motivación que son: “Sea agradecido, dedique tiempo a sus trabajadores,

proporcione feedback, cuide el ambiente de trabajo, proporcione información sobre la

empresa, involucre a los empleados, fomente la autonomía, establezca alianzas con cada

trabajador, celebre los éxitos y utilice el desempeño para discriminar la tarea realizada”. [52].

De la misma manera cobra vida hoy el concepto de “Sociedad del conocimiento” donde, las

personas son quienes construyen conocimiento a partir de sus experiencias y saberes además



124

tomando específicamente el concepto que dice que “el conocimiento es materia prima para el

crecimiento económico”. Y que “el trabajo especializado y los servicios basados en

conocimiento contienen el potencial de desarrollo de un país”. [53]

Apoyado en lo anterior, se pidió a las organizaciones detallar las certificaciones de sus

empleados, obteniendo los datos de la tabla 5, datos que posteriormente, fueron contrastados

con los resultados de las metas de certificación o estudios que esperan las organizaciones para

sus empleados. A este nivel se observa desarticulación entre las certificaciones logradas por

los empleados y las que el mercado laboral está requiriendo, seguidamente, se obtuvo

información respecto a los métodos y/o estrategias que utilizan en la actualidad las empresas

para capacitar y actualizar a sus empleados en las competencias necesarias para su entorno

laboral, a continuación se citan las respuestas

Estrategias de Capacitación para los empleados:

• Programas de certificación de los fabricantes, elearning y cursos presenciales.

• Capacitaciones internas y apoyo en el horario para que la gente estudie

• Capacitaciones externas, Capacitaciones internas, Grupos de estudio internos,

Grupos de practica (comité de analistas funcionales, comité de arquitectura)

• Entrenamientos internos, certificaciones, entrenamientos externos

• Utilizamos planes de formación integral y planes orientados a las carreras

específicas.

Tabla 5. Certificaciones

Tabla 5 CERTIFICACIONES

Certificaciones de los

empleados

Certificaciones requeridas por las

organizaciones

JAVA 10 Tecnologías Java

PuntoNET 5 PuntoNET

Microsoft27 Certificaciones en tecnologías Microsoft

CMMI 4. Certificación en CMMI.

Oracle2 Tecnologías Oracle

PMP3 PMP

Sql Server4

Sun Java24

UML2

RUP3

Java Sun

Programmer 12

J2ME 2

Itil1

PMO para gerencia de proyectos

JAVA

Tecnologías SAP

Arquitecturas SOA

Especialización en Desarrollo de

Software

Maestría en Ingeniería de Software



125

6.2.3. Caracterización de los clientes de las organizaciones

En el mundo del desarrollo software, donde los niveles de competencia son cada vez más

altos, las organizaciones deben generar productos de calidad para ser competitivas y

sabemos ya, que la calidad está basada en la satisfacción de las necesidades de los clientes.

Apoyado en lo anterior, se presenta en este estudio una caracterización de los clientes,

motivada desde la importancia comercial que genera para la organización tener claro quién

es su cliente, en este sentido este estudio investiga a qué público se dirige el producto, con

el fin de tener un concepto claro que posibilite la satisfacción de sus necesidades de manera

exitosa y así poder medir su satisfacción y la calidad de los productos, esto teniendo en

cuenta que para [27] el éxito de un sistema de software depende de lo bien se adapta a las

necesidades de sus usuarios y su entorno.

De la misma manera, tener una adecuada caracterización de los clientes de la organización

es una de las tácticas comerciales que permite establecer una estrategia de marketing y

comunicación y utilizar los canales adecuados para llegar hasta los clientes y poder

establecer verdaderas relaciones de permanencia. La atención al cliente, ha sido en la

última década un factor clave para que una empresa se diferencie de la competencia. Hoy

no tiene tanta relevancia el costo del servicio, la base de la negociación está en la

satisfacción de las necesidades del producto a los clientes. En ese sentido este estudio

permite vislumbrar algunos datos como: nichos de mercado de los clientes, ubicación y

finalmente se realiza una clasificación de los clientes como grandes medianos y pequeños.

Referente a los principales nichos de mercados que atienden las organizaciones antioqueñas

de software adscritas al estudio, los resultados generales fueron: Desarrollo a la medida

para compañías de Servicios y finanzas, OutSourcing para desarrollo de software a la

medida de productos genéricos orientados a las comunicaciones y la optimización de

procesos (CEBP), Retail, Sector financiero y bancario, Sector petrolero, Sector de la

construcción, Empresas en el exterior en sectores financieros y reales.

Concerniente a la ubicación geográfica de los clientes, factor de gran importancia para el

conocimiento y para la preparación de las organizaciones, se encontró según la gráfica 4 la

ubicación de los clientes. Así se presenta un gran número de clientes nacionales 47%, sin

embargo, los resultados para los clientes extranjeros son 24% lo que evidencia la necesidad

de generación de este tipo de mercados entre las industrias antioqueñas de software.

Lo anterior nos lleva a preguntarnos como miembros de un mundo globalizado ¿Qué

estrategias utilizar para formar parte y aprovecharse de los beneficios de este mundo?



126

Gráfica 4. Ubicación de los clientes

En este sentido, conocer la ubicación de los clientes llevó a este estudio a la necesidad de

investigar respecto a los porcentaje de desarrollos que las organizaciones realizan a cada

tipo cliente; nacional, extranjero y local, puesto que puede darse el caso que una

organización atienda pocos clientes pero que el número de desarrollo generados sea

superior a organizaciones que tienen muchos clientes esporádicos, la gráfica 5. Desarrollos

Contratados. Muestra los resultados, donde observamos que los clientes nacionales generan

el 52% de los contratos de desarrollo, seguidos por mucho de los clientes locales que

atienden el 27% y de los clientes extranjeros que representan el 21% de los contratos de

desarrollo software, se evidencia así, la necesidad de potenciar el mercado extranjero y

local. En el caso de los clientes locales, tal vez el atender las pequeñas organizaciones sería

una estrategia interesante para aplicar en el mercado, para ello este estudio aporta los datos

concernientes a los tipos de clientes atendidos por las organizaciones y la manera de

clasificarlos en las grafica 5 y tabla 6.



127

Gráfica 5. Desarrollos Contratados

Cabe agregar que las organizaciones clasifican a sus clientes en grandes, medianos y

pequeños, con base en criterios como la cantidad de puestos de trabajo, de tecnología que

usan, de empleados y otras características propias de sus instalaciones contenidas en la

tabla 6, criterios de clasificación de clientes, resume los datos de los criterios que utilizan

las organizaciones del estudio para clasificar a sus clientes.

Tabla 6. Criterios de clasificación de clientes.

CRITERIOS DE CLASIFICACIÓN DE CLIENTES

CLIENTES A C D H

Grandes .+ 1000

PCs

más de

1000

empleados

con ventas

superiores a

100.000.000.000

Compañías con

áreas instaladas de

tecnología

Medianos 500 a

1000 PCs

200 y 1000

empleados

con ventas

superiores a

50.000.000.000

Compañías sin


tecnología pero

con esencia de la

inversión en TI

Pequeños 0 a 500

PCs

menos de

200

empleados

Los demás Compañías sin


tecnología y sin

esencia de la

inversión en TI



128

No obstante, se tiene en cuenta el contexto global de la manera cómo se llega a clasificar a las

organizaciones, es interesante conocer ahora porcentualmente los tipos de clientes que son

atendidos por las empresas que desarrollan software, según la gráfica 6. Porcentaje de clientes

que atienden las organizaciones del estudio. El 66% de los clientes que contratan desarrollos

software son clientes grandes, el 29% de los clientes que requieren desarrollos software son

empresas medianas y solo el 5% de las pequeñas empresas compran software a la medida.

Algunas empresas señalaron como estrategia de negocio para mejorar sus resultados informar

a los clientes cómo un desarrollo software apalancaría su negocio y generaría valor. En este

sentido, es adecuado conocer los niveles de satisfacción de los clientes y las etapas del proceso

de desarrollo en las que presentan mayores niveles de satisfacción.

Gráfica 6. Porcentaje de clientes que atienden las organizaciones del estudio

Basado en lo anterior se obtuvo la información de una buena práctica a saber, que el cliente

conozca las etapas del proceso de desarrollo software que llevará elaborar su producto, y

conozca además su nivel de responsabilidad al involucrarse en cada una de ellas, para que,

posteriormente, se generen los resultados de satisfacción esperados en cada una de las etapas

del proceso de desarrollo software.

Este estudio presenta ahora algunas respuestas referentes a satisfacción así: El 80% de las

organizaciones encuestadas respondieron que los niveles de satisfacción de sus clientes oscilan

entre el 81% y 90%. Para los clientes de las organizaciones B y C las etapas donde los

clientes reportan mejores índices de satisfacción son: Elicitación, análisis y construcción. La

empresa C reporta mayor satisfacción de sus clientes en la etapa de diseño, la empresa H

presenta fortalezas respecto a los niveles de satisfacción de sus clientes durante las etapas de

Visión, implantación, especificación detallada construcción y diseño de componentes.

La tabla 7 muestra de manera explícita la causa más frecuente de insatisfacción por parte de

los clientes y evidencia que los tiempos de entrega y los motivos de las demoras apuntan a

fallas en el proceso de Ingeniería de Requisitos en la organización, esta afirmación es apoyada

por:



129

Standish Group International para el 2011, Chaos Report, los proyectos exitosos fueron

37%, los proyectos que deben ser mejorados son 42% y los proyectos fracasados fueron

21%. Y los principales factores fracaso son por requisitos incompletos 13,1%, falta

involucrar usuarios 12,4%, falta de recursos 10,6% expectativas no realistas 9,9%, falta

de planeación, 8,1% Falta de apoyo de gerencia 9,3% requisitos cambiantes 8,7%,

plazos poco realistas 7,5%, falta de gestión de TI 6,2%. Otras estadísticas interesantes

son: El 40% del proyecto es sobreesfuerzo para reparar defectos causados por mala

calidad de los requisitos según Software Engineering Institute, el 60% de los defectos

son desde los requisitos, National Institute of Standards and Technology, 42% Proyectos cambian por culpa de los requisitos según The Standish Group, Chaos

Manifesto 2011, el 54% Requisitos originales solo son implementados Fuente: The

Standish Group, Chaos Report) 55% Requisitos no son usados por los usuarios o

clientes (Fuente: Jacobe)

Gartner Group, aproximadamente el 60-70% de los fracasos ocurridos en los proyectos

de desarrollo de sistemas de software son debido a las insuficiencias de la adquisición,

gestión y análisis de requisitos. Según, los estudios empíricos sugieren que el proceso

de Ingeniería de Requisitos es deficiente en el 75% de las empresas de software y

gestión de requisitos es uno de los factores críticos de éxito para mejorar el proceso de

software.

Tabla 7. Insatisfacción de los clientes en el proceso de desarrollo software

INSATISFACCIÓN DE LOS CLIENTES EN EL PROCESO DE DESARROLLO SOFTWARE

ORGANIZACIONES MOTIVO DE

INSATISFACCIÓN CAUSA DE INSATISFACCIÓN

A Tiempos de entrega Inicio tardío de los proyectos a causa del

desconocimiento de las necesidades del

cliente

B Entrega no a tiempo Arreglos de última hora a los productos

C Oportunidad en la

entrega

Se demoran en la construcción porque

se demoraron en tener los requisitos

listos

D Demora en la entrega

del producto

Discusiones sobre la claridad en

requisitos (lo que el cliente esperaba vs

lo entregado)

H Retrasos en el

proyecto en la

entrega final

Comunicación entre gestores del

proyecto Respecto a la claridad de la

especificación de los requisitos del

proyecto



130

Vemos como la actualidad, lograr "satisfacción del cliente" es un requisito indispensable para

ganarse un lugar en la "mente" de ellos y por ende, en el mercado por ello el objetivo principal

es “satisfacer el cliente,” sin miramientos de área de la organización a la que pertenezca, es la

base de los buenos niveles de calidad en los productos y es el soporte para lograr la empresa

exitosas; algunos beneficios tangibles de lograr la satisfacción fueron expresados así por los

participantes del estudio:

El cliente satisfecho, por lo general, vuelve a comprar. Por tanto, la empresa obtiene

como beneficio su lealtad y por ende, la posibilidad de venderle el mismo u otros

productos adicionales en el futuro.

El cliente satisfecho comunica a otros sus experiencias positivas con un producto o

servicio. Por tanto, la empresa obtiene como beneficio una difusión gratuita que el

cliente satisfecho realiza a sus familiares, amistades y conocidos.

• El cliente satisfecho deja de lado a la competencia. Por tanto, la empresa obtiene como

beneficio un determinado lugar (participación) en el mercado.

En síntesis, toda empresa que logre la satisfacción del cliente obtendrá como beneficios:

La lealtad del cliente (que se traduce en futuras ventas).

Difusión gratuita (que se traduce en nuevos clientes).

Una determinada participación en el mercado.

Se evidencia tanto la importancia de conocer las tendencias que hacen que fracasen los

proyectos y lograr generar satisfacción en los clientes como lo señala la tabla 7.

Dentro del contexto de satisfacción de los clientes es importante conocer el tipo de

contratación o relación comercial que se tiene, claro está, que la prevalencia y satisfacción no

están directamente ligadas al tipo de contratación sino más bien a la correcta interpretación de

las necesidades del cliente y a su satisfacción. A continuación se listan las formas de

contratación que son utilizadas por las empresas desarrolladoras de software antioqueñas:

Fábrica de Software, Application services y staff augmentation en formato de insourcing y outsourcing

Proyecto valor cerrado y outsourcing

Contrato Marco, Tiempo fijo y costo fijo, Contrato por etapas

Contrataciones por tiempo y materiales o a costo fijo dependiendo del nivel de

conocimiento del proyecto y del riesgo que este implique.

Por Outsourcing Insitu, Por Outsourcing en TF, Proyecto llave en mano

Basado en lo anterior, la satisfacción del cliente sugiere prevalencia y por tanto para lograrlo

es necesario tener conocimiento de sus necesidades lo cual parte de tener niveles de

comunicación adecuados y Estrategias de permanente contacto. Este estudio cita a

continuación la lista de las herramientas de comunicación utilizadas por las organizaciones y



131

las estrategias de prevalencia, en la gráfica 7. Herramientas de Gestión del Cliente se observa

a CRM como la herramienta de mayor uso en el grupo de organizaciones con 50%.

Gráfica 7. Herramientas de Gestión del Cliente

No obstante, aunque la utilización de una herramienta de gestión clientes es muy positiva,

porque promete prevalencia de las relaciones, además que aporta conocimientos a la

organización para realizar prácticas de mejora continúa. Sin embargo cómo no es el objeto de

este estudio se solicitó se expresara el nombre de los sistemas de información, con el fin de

apoyar este estudio referente al conocimiento y manejo de los clientes con la organización,

pero no se obtuvo información precisa sobre las practicas con la herramienta ni de la forma en

sí de aprovechamiento ni de los resultados logrados, este tema es interesante para realizar

futuras investigaciones. Para este estudio se logró concretar que algunas estrategias de

seguimiento y comunicación con los clientes son:

Modelo comercial de ejecutivos de cuenta y especialistas de producto

Nombrar siempre en los proyectos un gerente que esté haciendo planeación.

Reuniones de seguimiento

Contacto cercano y reiterativo de los mismos en todo los momentos, tanto cuando hacemos desarrollo como no

Ejecutivos de cuenta [7]

La investigación además se interesó por conocer las estrategias para la captación de nuevos

clientes y obtuvo la información registrada en la gráfica 8, que muestra a las compañías de

marketing como la estrategia más usadas en el momento de captar nuevos clientes para las

50%

13% 13% 13% 13%

HERRAMIENTAS DE GESTIÓN DEL CLIENTE



132

empresas de desarrollo software con 60% de utilización, mientras que estrategias como

eventos, ferias, publicidad y referencias de clientes alcanzan el 40% de su uso.

Gráfica 8. Estrategias para captar nuevos clientes

Cabe anotar, que la disminución en los índices de satisfacción del cliente no siempre

significa una disminución en la calidad de los productos o servicios; en muchos casos, es el

resultado de un aumento en las expectativas del cliente, situación que es atribuible a las

actividades de mercadotecnia que generan expectativas muy altas.

Es sabido que la satisfacción del cliente la determina su punto de vista, el desempeño

esperado del producto, según su percepción generada a partir de expectativas y promesas

acerca de los beneficios que brinda el producto de ahí la importancia de generar en los

clientes expectativas claras, concretas y posibles, para evitar la decepción y la

insatisfacción y que esto afecte directamente la calidad de los productos.

En apoyo a lo anterior es de vital importancia que este proceso sea medido regularmente

para determinar si las expectativas de los clientes están dentro de lo que la empresa puede

proporcionarle o está a la par, o por debajo o encima de las expectativas y lo que la

competencia puede generarle y si coincide con lo que el cliente promedio espera, si el

producto tiene y es reconocido por el cliente el valor agregado, todo esto para animar una

negociación que finalmente cumpla expectativas de calidad.

Es importante dar a conocer los parámetros utilizados para medir los niveles de satisfacción

que son: Insatisfacción, cuando el producto no alcanza las expectativas, satisfacción,

cuando el desempeño percibido coincide con las expectativas del cliente y complacencia,

Compañíasde

Marketing

Eventos Ferias Publicidad Referencias

60%

40% 40% 40% 40%

ESTRATEGIAS PARA CAPTAR NUEVOS CLIENTES



133

cuando el desempeño percibido accede a las expectativas del cliente. Es dependiendo el

nivel de satisfacción del cliente, que se puede conocer el grado de lealtad hacia una marca o

empresa. Un cliente insatisfecho cambiará de proveedor inmediatamente, el cliente

satisfecho se mantendrá leal pero, tan sólo hasta que encuentre otro proveedor que tenga

una oferta mejor y el cliente complacido será leal a una marca o proveedor porque siente

una afinidad emocional que supera ampliamente a una simple preferencia racional. Por ese

motivo, las empresas inteligentes buscan complacer a sus clientes mediante prometer solo

lo que pueden entregar y entregar después más de lo que prometieron.

En este sentido este estudio describe la lista de estrategias utilizadas por la organización

para potenciar clientes:

- Metodología de ventas consultivas

- Haciendo las cosas bien

- Creación de nuevos productos con enfoques tecnológicos y de negocio innovadores

- Un entendimiento profundo del dominio del negocio y de las necesidades de información y procesos del mismo. Mantenernos al tanto de los últimos avance de

ingeniería de software y plataformas tecnológicas que disminuyan los costos y

aumenten la velocidad en nuestros desarrollos

- Charlas de temas de interés, Asesoría tecnológica

6.2.4. Caracterización del Proceso de Desarrollo en la Organización

Las relaciones sistémicas presentes entre las categorías del proceso de desarrollo de software y las características de calidad correspondientes al

producto, establecen que las metas para la calidad del producto de

software van a determinar los objetivos del proceso para su desarrollo

según [5].

La calidad es un término que ha adquirido gran relevancia con el paso del tiempo, ya que es considerada como uno de los principales activos

con los que cuenta un país para mejorar su posición competitiva global

[...].

Para lograr la buena calidad en los productos software es esencial utilizar los modelos y métodos apropiados para controlar el proceso de

desarrollo software. [5]

A la hora de definir la calidad del software se debe diferenciar entre la

calidad del producto software y la calidad del proceso de desarrollo de

éste (calidad de diseño y fabricación). No obstante, las metas que se

establezcan para la calidad del producto van a determinar los objetivos



134

del proceso de desarrollo, ya que la calidad del primero va a depender,

entre otros aspectos, de éstos. Sin un buen proceso de desarrollo es casi

imposible obtener un buen producto. [5]

Callaos y Callaos propone el concepto de calidad sistémica del software,

involucrando las características internas del contexto organizacional, lo

que lleva a un enfoque sistémico del concepto de calidad de software

[54].

Las anteriores premisas llevan a este estudio a pensar en la caracterización del proceso de desarrollo software de las empresas antioqueñas de desarrollo que buscan calidad,

competitividad y posicionamiento global entre otros.

Este estudio genera datos respecto a los roles asignados por las organizaciones, las

metodologías de desarrollo, lenguajes más utilizados según el tipo de desarrollo, el

seguimiento realizado a los productos entregados, la gestión realizada por las

organizaciones para generar nuevas puestas en producción, el tiempo de entrega entre cada

una y finaliza con los datos porcentuales de desarrollos nuevos, migración y componentes.

El proceso de desarrollo software realzado en las organizaciones del estudio se lleva a cabo

con las funciones realizadas por los roles expuestos en la tabla 8. Relación de roles

presentes en las organizaciones. Estos datos generan una idea global de los aspectos que se

tienen presentes en el proceso de desarrollo software.

Tabla 8. Relación de roles presentes en las organizaciones

RELACIÓN DE ROLES PRESENTES EN LAS

ORGANIZACIONES

Administrador de Base de Datos

Administrador de configuración

Administrador de Redes, Comunicaciones y Sistemas Operativos

Administrador de Seguridad

Analista de Procesos

Analista de Sistemas/Analista Técnico Funcional

Analista QA (Quality Assurance)

Arquitecto

Aseguradores de calidad

Consultor Funcional Junior

Consultor Funcional Sénior

Desarrollador de Aplicaciones Cliente Servidor

Desarrollador de Aplicaciones Web

Diseñador de Soluciones

Ejecutivo Comercial



135

Especialista en Seguridad de Aplicaciones

Especialistas en Tecnología

Ingeniero de validación y verificación

Líder / Gerente/ Responsable de Calidad

Líder de Proyecto

Programador

Project Manager / Director de Proyectos

Tester

En este sentido uno de los retos que suelen presentarse al proceso de desarrollo software en

las organizaciones es la adaptación y capacidad de respuesta del proceso frente a los

diferentes tipos de desarrollo que el mercado presenta tales como desarrollos nuevos,

migraciones y utilización de componentes, la gráfica 9. Estrategias para captar nuevos

clientes. Muestra el porcentaje de negocios realizados por las organizaciones para cada tipo

de desarrollo, vemos como, aunque el porcentaje de desarrollos nuevos ocupa el 55%, los

desarrollos migración y componentes ocupan el 45%, por tanto el proceso de desarrollo que

adelante la organización de software debe prestar atención y soportar los diferentes tipos de

desarrollos.

Gráfica 9. Estrategias para Captar Nuevos Clientes

No obstante como lo muestra la gráfica 10. Metodologías de desarrollo utilizadas por la

organización, las organizaciones del estudio utilizan diferentes metodologías en el proceso

de desarrollo que van desde las más tradicionales hasta algunas relativamente nuevas

dependiendo del tipo de desarrollo contratado, el tiempo y hasta del cliente, a este respecto,

sería interesante en un estudio futuro investigar los criterios que hacen que una

organización utilice una u otra metodología de desarrollo, dado que muy probablemente

existan mitos respecto a la utilización de metodologías de desarrollo para proyectos

grandes o para proyectos por fases entre otros.



136

Gráfica 10. Metodologías de desarrollo utilizadas por la organización

Es importante conocer la tendencia del lenguaje de desarrollo utilizado según el desarrollo

o proyecto, en este sentido, se observó que las organizaciones del estudio basadas en la

experiencia, habilidades y en la cultura organizacional, asocian los lenguajes de desarrollo a

los tipo de proyectos contratados, en la tabla 9, Lenguajes de desarrollo software utilizados

por las organizaciones, se muestra un resumen de lo antes mencionado, donde llama

también la atención cómo para un mismo desarrollo existen diversos puntos de vista acerca

del lenguaje utilizado para la solución, un estudio futuro podría generar indicios de los

criterios tenidos en cuenta en el momento de utilizar cada lenguaje para un tipo de solución.

Tabla 9. Lenguajes de desarrollo software utilizados por las organizaciones

LENGUAJE DE DESARROLLO SOFTWARE UTILIZADOS POR LAS

ORGANIZACIONES

TIPO DE DESARROLLO

LENGUAJES

Uso

Web

J2EE, DotNet 35%

Java con Oracle, Java con SqlServer, Java

con Postgress, Java con MySql, PuntoNet

con SqlServer

80%

JAVA - PuntoNET – PB – PHP 80%



137

Sistemas embebidos JAVA - PuntoNET – PB – PHP 10%

Sistemas de información,

ambiente y lenguajes de

desarrollo utilizados

PuntoNET, Java, VB, Powebuilder, RPG y

Cobol

100%

ABAP/SAP 10%

Sistemas en tiempo real JAVA - .NET – PB – PHP 10%

Desarrollos móviles PhoneGap, J2ME, PuntoNet Mobile 20%

J2EE, DotNet 20%

SmartClient DotNet 10%

Integración de aplicaciones BizTalk, Wesphere Integration Developer 10%

Inteligencia de negocios SQL SERVER, Oracle BI 10%

Consultoría en arquitectura

de software

Enterprise Architect 5%

En apoyo a lo anterior se genera información respecto a buenas prácticas llevadas a cabo por

las organizaciones para el proceso en aspectos como: Seguimiento a los productos, gestión

de nuevas entregas y control de tiempo entre ellas.

Buenas Prácticas de Seguimiento a los productos:

o Tener una área de calidad encargada de apoyar y realizar el seguimiento

o Realizar encuestas de satisfacción a los clientes

o Monitorear constantemente el desempeño de los productos con métricas de

desempeño mientras son desplegados

o Realizar la vigilancia tecnológica definida por Tecnnova

Buenas Prácticas de Gestión de Nuevas Puestas en producción:

o Tener un proceso de gestión de la configuración claramente constituido, con líneas

base, patrones de gestión de la configuración establecido (branch, trunk, etc) y

numeración de reléase.

o Utilizar las definiciones de CMMI para bajo estas implementar la gestión de

configuración en la organización.



138

o Buenas prácticas para el control de tiempo entre la entrega de versiones:

o Tener un proceso definido, formalizado y detallado, cómo es el caso del 40% de las

organizaciones

o Caracterización del Proceso de Ingeniería de Requisitos en las Organizaciones

o Según Pressman 2000 en [16] la calidad del software es “la concordancia con los

requisitos funcionales y de rendimiento explícitamente establecidos, con los

estándares de desarrollo explícitamente documentados y con las características

implícitas que se espera de todo software desarrollado profesionalmente”.

o Para Sommerville [42] “Los requisitos son... una especificación de lo que debería

ser implementado. Son descripciones de cómo el sistema debe comportarse, o de

una propiedad o atributo del sistema. Ellos pueden ser una limitación en el

desarrollo del sistema.” Basado en ello, se puede afirmar que los requisitos del

software son la base de las medidas de calidad. La falta de concordancia con los

requisitos es una falta de calidad.

o Según [7] “El tiempo dedicado es una excelente inversión según...”. El costo de

reparar un sistema es más alto que el de aplicar un proceso adecuado de requisitos,

la proporción es, puede costar 100 veces más abordar un error después de la puesta

en producción.

o Durante el desarrollo software, ninguno de los enfoques tendrán éxito a menos que

la cultura organizacional incluya un compromiso común de construir productos de

alta calidad de software de una manera disciplinada. [7]

o Según estudios de Standish Group y Gartner Group… International para el 2011,

Chaos Report el proceso de ingeniería de software sigue presentando dificultades en

la etapa de Ingeniería de Requisitos. [3]

De la misma manera este estudio presenta la caracterización de la Ingeniería de Requisitos

para las empresas antioqueñas de desarrollo de software. Tomando aspectos como: el nivel

de importancia en la organización, la formalización, la manera cómo se realiza, los insumos

metodologías, las expectativas futuras, los aspectos a mejorar, los procesos que apalanca, la

elicitación, priorización, gestión del cambio, verificación y validación, los software

utilizados y finalmente las habilidades, estrategias y mejores prácticas, esperas futuras del

proceso, aspectos a mejorar, y aporten las organizaciones al estudio, entre otros.

Apoyando lo anterior, la importancia que tiene la Ingeniería de Requisitos en la

organización por lo que debe ser caracterizado, la IEEE respecto a la Ingeniería de

Requisitos en si la menciona como: “Una condición o necesidad de un usuario para resolver

un problema o alcanzar un objetivo”. “Una condición o capacidad que debe estar presente

en un sistema o componentes de sistema para satisfacer un contrato, estándar,



139

especificación u otro documento formal”. “Una representación documentada de una

condición o capacidad como... ” Como se observa en las definiciones la Ingeniería de

Requisitos gira en torno a la satisfacción de los usuarios que es finalmente el indicador de

calidad del producto. [65]

Este estudio referente a lo anterior, consulta el punto de vista de las organizaciones en

cuanto a la importancia que tiene para cada una de ellas tener formalizado el proceso de

ingeniería de requisitos y la respuesta de todas fue que es 100% necesario tener el proceso

formalizado, algunas respuestas se citan a continuación:

- En nuestra organización sin requisitos prefieren no realizar el proyecto

- En todo el proceso de desarrollo desde la parte comercial y durante toda la ejecución

del proyecto se tiene en cuenta la Ingeniería de Requisitos como herramienta

fundamental del proyecto, desde preventa y formulación de propuesta y todo el ciclo

está basado en los requisitos (CU).

- Es un eje transversal, que está involucrado en varias partes del proceso de desarrollo software, desde ventas, especificación, diseño y construcción. “Ingeniería de requisitos

es una herramienta transversal al proceso”.

- Nuestra Ingeniería de Requisitos está diseñado, formalizado, documentado, con estrategias de capacitación, grupos de discusión, líderes del proceso de requisitos, EPG

de seguimiento, portal de gestión de conocimiento, portal de inquietudes de requisitos,

respuestas de expertos, para ellos, Ingeniería de Requisitos es uno de los procesos más

maduros que tiene la organización.

En apoyo a lo anterior algunos autores se citan a continuación para describir la forma, el

cómo realizar Ingeniería de Requisitos.

- Según Telepaty [7] un proyecto debe abordarse desde tres (3) niveles: Requisitos de

negocio, requisitos usuario y requisitos funcionales.

- Los requerimientos del negocio deben describir por qué el producto se está construyendo e identificar los beneficios a los clientes y el negocio va a cosechar.

- Los requisitos de usuario, deben ser capturados en forma de casos de uso, para describir las tareas o procesos de negocio del usuario y que debe ser capaz de

realizar con el producto.

- Los Requisitos funcionales describen las conductas específicas del sistema que debe ser implementado.

- Sommerville [42] describe la Ingeniería de Requisitos con sus su disciplinas, como

lo muestra la figura 29 Subdisciplinas de Ingeniería de Requisitos



140

Figura 29. Subdisciplinas de Ingeniería de Requisitos. Tomado de Ian Sommerville y

Sawyer Pete, Ingeniería de Requerimientos: Una Guía de Buenas Prácticas (Wiley,

1997).

- En Swebok [59] la Ingeniería de Requisitos se realiza como lo muestra la figura 30. Requisitos de Software.



141

Figura 30. Requisitos de Software

- La versión 1.2 del Capability Maturity Model Integration-Development –CMMI–

divide los requisitos del software en dos áreas de proceso: la primera es el

Desarrollo de Requisitos, que incluye la elicitación, la definición, el análisis, la

especificación y la validación; la segunda es la Gestión de Requisitos, que implica

la gestión de requisitos que se han desarrollado, incluyendo el control de cambios y

la verificación.

Como referente teórico que orienta respecto a la manera cómo debería realizarse el proceso Ingeniería de Requisitos, se decide investigar cómo se realiza el proceso hoy en las

Captura Elicitación

Encustas

Entrevistas

Worshop

Análisis

Conflictos

Límites

Descripción

Clasificicación

Funcionales

No Funcionales

Modelado UML

Arquitectura

Rq Negocio

Rq conflicto

Validación

Entiende el ingeniero?

Entiende usuario?

Revisión Prototipos

Validación modelo

Puebas



142

organizaciones antioqueñas que desarrollan software y los insumos utilizados para ello, a

continuación se citan ocho (8) experiencias relevantes en la tabla 10. El Cómo del Proceso

de Ingeniería de Requisitos.

Tabla 10. El Cómo del Proceso de Ingeniería de Requisitos.

EL CÓMO DEL PROCESO DE INGENIERÍA DE REQUISITOS

REALIZADO Y LOS INSUMOS

Experiencia A

Basados en RUP. Los pasos son: Identificar necesidades, entender el

problema, definir CU, priorizar, afinar y transversalmente realizar control

cambios.

Insumos

- Work shop

- Documento de especificación

- Documento CU

- Documento de atributos de requisitos

- Documento de visión

- Trazabilidad

Experiencia B

Los pasos son: Entrevista, reunión grabada y bien documentada, vaciado a

herramienta de requisitos y (filtrado), reconocimiento de requisitos funcionales

y no nacionales, etc. recepción de documentos con requisitos, elaboración de

prototipos.

Insumos

- Entrevista, encuesta, documentos usuario

Experiencia C

Se realiza entrevista, se refina, se completa la información, se analiza, se vacía

en herramienta de requisitos y se regresó al cliente para validarla.

Insumos

Plantillas propias prestablecidas en la herramienta de Ingeniería de Requisitos



143

Experiencia D

Partiendo de las necesidades del negocio se detallan características, requisitos

funcionales, no funcionales y se realizan prototipos que se validan.

Insumos

- WBS, dentro se tiene para cada proceso tenemos la lista de los entregables,

hay instructivos para llevar a cabo dada proceso, listas de chequeo,

participación de arquitectos para dar vía libre al requisitos.

Experiencia E

Se hace Elicitación, validación, Cu

Insumos

- Cuestionarios

- EAP

- Balsamiq (para prototipos)

- Excel

Experiencia F

Reuniones de contextualización, para conocer la técnica de elicitación,

entrevista, lectura de documentos previos, depuración de requisitos.

Insumos

- Software Oasis, Documentación del cliente

Experiencia G

Dada la especificad del negocio, hay catálogo de requisitos donde el cliente

construye un perfil y determina el método y hacen la prueba que desea.

Insumos

- Proceso de mercadeo y ventas, Catálogo de requisitos, (preventa)

documenta en oportunidad comercial, y cada servicio tiene un costo basado

en una encuesta se sabe cuántos campos (una tabla).

- En la prueba se toman los requisitos de seguridad y con base en la elección

del cliente en el catálogo se llama prueba de más o menos rigurosidad y se

presta el servicio al cliente.



144

Experiencia H

Se estructura todo el proyecto basado en el concepto de arquitectura

empresarial que luego se divide en 4 niveles de arquitectura: procesos,

sistemas, componentes y física. Hay interpretación de requisitos en las 4

arquitecturas. El mayor apoyo de la Ingeniería de Requisitos está en la parte

de arquitectura de sistemas (parte de productos software) requisitos no

funcionales se involucran en la vista de componentes a través del diseño de

componentes. Es un modelo iterativo incremental definido basado en

requisitos

Insumos

En la venta y la visión el insumo es el conocimiento de que hay en la empresa,

y que en el medio, normas gubernamentales, antes de ir al cliente para que

cuente sus necesidades. En la especificación funcional el insumo es la visión

construida en los 4 niveles. En diseño se usan más el insumo de componentes

y el de infraestructura y en la implantación es totalmente el tema de

infraestructura (poner en marcha el sistema).

Por lo tanto, algunas maneras cómo se realizan Ingeniería de Requisitos en las empresas

antioqueñas de software con relación a las metodologías que sirven de apoyo durante el

proceso, se obtuvieron los datos de la gráfica 40. Metodologías de Apoyo a la Ingeniería de

Requisitos, donde se evidencia que en las organizaciones en un 35,29% generan su propia

metodología, este resultado se logró a partir de las respuestas, apoyada en las características

de sus clientes y en su cultura organizacional, demostrado en la gráfica 11, Metodología de

apoyo a ingeniería de requisitos. Para [7], ninguno de los métodos tendrá éxito a menos

que su cultura organizacional incluya un compromiso común de construir productos de alta

calidad de software de una manera disciplinada.



145

Gráfica 11. Metodologías de Apoyo a la Ingeniería de Requisitos

Por lo anterior, cada organización fija sus metas de crecimiento para sus procesos y las

esquematiza según un orden de prioridades y beneficios para su negocio, de allí parte la

pregunta que realiza este estudio ¿Qué espera la organización a futuro del proceso de

Ingeniería de Requisitos que realiza?, evidenciadas las respuestas en la tabla 11.

Tabla 11. Metas futuras para el proceso

METAS FUTURAS PARA EL PROCESO

Capacitar al grupo de trabajo X

Afinar las prácticas existentes X

Que los requisitos sean la base de estimación XX

Mejorar el diseño X

Mejorar el análisis de los CU X

Que el analista funcional entregue productos

desarrollables

X

Hacer un mejor modelado de procesos de negocio X



146

Simplificar el proceso X

Mejorar el tiempo dedicado al proceso de requisitos XX

Mitigar los riesgos del alcance X

Mejorar la interpretación de las necesidades del cliente X

Cerrar la brecha entre lo elicitado y lo entregado X

Por otro lado, sabemos que el mundo de la tecnología sugiere soluciones para aspectos que

no están totalmente claros, creando nuevas necesidades por lo cual es imposible lograr

satisfacer a clientes que no tengan claridad este estudio consiente de lo anterior y

sumándolo al tema que la competitividad en el mercado ha hecho que algunas

organizaciones-clientes se muestren prevenidas y tomen medidas para ocultar información

del proceso y de su negocio en el momento de ser requerida por la empresa de desarrollo

software, generando una tipificación de clientes llamados en este estudio, críticos, que son

aquellos que ocultan información, en conjunto con los que carecen de claridad entre lo que

desean y lo que la organización necesita, o simplemente respecto a lo que verdaderamente

desean del programa, desconociendo totalmente sus necesidades reales, que se sabe

dificultan la tarea del desarrollo software e impiden la elaboración de productos con calidad

y además generan incrementos en los costos debido a los reprocesos.

Situación la anterior que afecta directamente el proceso de desarrollo software y muy

específicamente a la etapa de Ingeniería de Requisitos, esta investigación recopila las

estrategias utilizadas por las organizaciones para atender las problemáticas anteriormente

citadas en las tablas 12 y 13 bajo los títulos, Buenas prácticas de ingeniería de requisitos

para clientes que ocultan información y Buenas prácticas de ingeniería de requisitos para

clientes que desconocen sus necesidades.

Tabla 12. Buenas prácticas de Ingeniería de Requisitos para clientes que ocultan

información

BUENAS PRÁCTICAS DE INGENIERÍA DE REQUISITOS

PARA CLIENTES QUE OCULTAN INFORMACIÓN

Generar un documento de acuerdo de confidencialidad esta buena práctica está presente el 100% de las

organizaciones del estudio, como una medida para generar relaciones de confianza.

Informar de manera clara, sincera y concreta al cliente respecto al tipo de negocio que es una empresa de

desarrollo software y sus responsabilidades y políticas de tal manera que se genere confianza con el cliente.

Realiza un proceso de psicología con el cliente para generar confianza.



147

Mostrar dominio y capacitación en ese tipo de negocios frente al cliente, capacitando previamente a las

personas que están en contacto directo con él.

Generar cuestionarios, entrevistas y demás actividades que permitan generar acercamiento y conocimiento de

aspectos del negocio.

Mantener inmerso al cliente inmerso en el proceso para que pueda evidenciar la necesidad de la información.

Tabla 13. Buenas prácticas de Ingeniería de Requisitos para clientes que desconocen

sus necesidades

BUENAS PRÁCTICAS DE INGENIERÍA DE REQUISITOS PARA CLIENTES

QUE DESCONOCEN SUS NECESIDADES

La organización de desarrollo debe acudir ante un experto del dominio para poder orientar el proceso y como

valor agregado poner el conocimiento adquirido al servicio del cliente.

Buscar y consultar organizaciones que hayan tenido experiencias de implementado similares.

Indagar bastante sobre el proceso que quiere intervenir y definirlo en conjunto.

Adentrarse completamente en el proceso del cliente y generar sugerencias con el valor que aporta al negocio.

Orientar al cliente respecto al valor entre lo que desea y lo que necesita.

Tener pleno conocimiento de la documentación del negocio y sugerir al cliente ayudarle a delimitar.

Indicarle claramente al cliente la diferencia entre lo que desea y lo que realmente necesita y le aporta valor a

su negocio.

Aliarse con las personas especializadas en negocio.

Usar prototipos de negocio para hacer demostraciones al cliente con claridad.

Referenciar al cliente mediante la presentación de una propuesta preliminar, teniendo presentes los acuerdos

de confidencialidad.

Conocer el estado del arte en el sector productivo del cliente y hacerle saber que se dispone de este

conocimiento.



148

Realizar instrumentos como catálogos, listas de chequeo, u otros instrumentos para que el cliente sitúe sus

necesidades.

Realizar un buen proceso de preventa con personas capacitadas.

Partiendo de la arquitectura de procesos se pintan lo que será el proyecto, con esto se logra saber qué es lo que

en realidad quiere el cliente en un prototipo guiado por la arquitectura de base.

En la arquitectura mostrar los procesos que tiene el cliente y los procesos que desea apoyar con el sistema.

Evitar totalmente hablar de tecnología, hasta llegar a la fase de acuerdos de confidencialidad.

La organización de desarrollo debe acudir ante un experto del dominio para poder orientar el proceso y como

valor agregado poner el conocimiento adquirido al servicio del cliente.

Buscar y consultar organizaciones que hayan tenido experiencias de implementado similares productos

Indagar bastante sobre el proceso que quiere intervenir y definirlo en conjunto.

Adentrarse completamente en el proceso del cliente y generar sugerencias con el valor que aporta al negocio.

Orientar al cliente respecto al valor entre lo que desea y lo que necesita.

Tener pleno conocimiento de la documentación del negocio y sugerir al cliente ayudarle a delimitar.

Indicarle claramente al cliente la diferencia entre lo que desea y lo que realmente necesita y le aporta valor a

su negocio.

Aliarse con las personas especializadas en negocio.

Usar prototipos de negocio para hacer demostraciones al cliente con claridad.

Referenciar al cliente mediante la presentación de una propuesta preliminar, teniendo presentes los acuerdos

de confidencialidad.

Conocer el estado del arte en el sector productivo del cliente y hacerle saber que se dispone de este

conocimiento.



149

Respecto a la mejor continua no obstante, se debe entender la Mejora Continua del Servicio

como Crear y Mantener Valor esta premisa asociada a las expresiones de las

organizaciones del estudio referentes a mejora continua a la importancia que le dan, sus

aspiraciones y los beneficios esperados, llevan a este estudio a realizar seguimiento a

algunos aspectos que las organizaciones consideran a mejorar en la de ingeniería requisitos,

referente a documentación, elicitación, técnicas, tiempo dedicado al proceso y acercamiento

al cliente. [60]

Mejoras requeridas en la documentación de los requisitos en el contexto de ISO 9000: 2000

[61]

- Desarrollar un grupo simple de normas que sean igualmente aplicables a las pequeñas, a las medianas y a las grandes organizaciones.

- Dar mayor relevancia a los resultados derivados de las actividades y los procesos que a

la cantidad y detalles de la documentación requerida.

No obstante, se requiere mostrar eficacia en la documentación se debe documentar un

requisito en vez de tener un sistema de documentos para un requisito, experiencias de casos

de éxito con simplicidad en los productos está por ejemplo Steve Jobs con el iPhone, que

deja una sola tecla en el celular cuando en ese momento los teléfonos tenían más de treinta

(30), esto es dar cuenta del valor de lo simple y la comprobación de sus buenos resultados

al ver aumentar las ventas de la marca iPhone.

En ese sentido, la Figura 31. Mejoras sugeridas en la documentación, muestra, las mejorar

que las organizaciones consideran como necesarias respecto a la documentación de los

requisitos, para los proyectos de software, es importante considerar que el medio de las

organizaciones de desarrollo consideran necesario que los ingenieros desarrollen

competencias de escritura y redacción correctas, para mejorar el entendimientos del proceso

que en muchas ocasiones aunque está bien elaborado carece de claridad para ser entendido

por los diferentes roles del proceso.



150

MEJORAS SUGERIDAS EN LA DOCUMENTACIÓN DE LOS REQUISITOS

Figura 31. Mejoras sugeridas en la documentación

Mejoras requeridas en la Elicitación de los requisitos: Al definir elicitar como la manera de

descubrir, hacer explicita y obtener información tomando algunas fases como:

Identificación de las fuentes de información: que incluye stakeholders, conocimiento explicito, software existente.

Recolección de los datos: técnicas para obtener información, como entrevistas worshop, encuestas entre otros.

Comunicación de los datos: La manera de retroalimentar los datos para

documentación y modelado.

Por lo tanto, este documento en la figura 15, muestra las mejoras necesarias en la

elicitación que las empresas que forman parte del estudio expresaron. Entre el grupo de

empresas se observa la tendencia marcada a utilizar la entrevista como única técnica de

elicitación. Frente a la solicitud de sustentación, las organizaciones expresaron la necesidad

de preparar a los ingenieros de requisitos para variar la técnica, utilizando métodos

pedagógicos, que se amolden a los diferentes tipos de clientes y generen información más

valiosa, de otro modo, expresaron simpatía especial por las técnicas que llevan a conocer

los diferentes puntos de vista de los stakeholders y posteriormente a consenso.

Como buenas prácticas en elicitación de requisitos se presentan:

o La variación de la técnica acorde con el cliente.

o Una vez finaliza elicitación llevar los resultados a casos de uso y reunir con el

equipo de trabajo para para clarificar aspectos de negocio.

• Las técnicas de redacción

• Las técnicas gramaticales

• Evitar ambiguedad

• Cantidad de los documentos

• Mejorar el control de cambios

• Lograr claridad en la comunicación

• Utilizar herramientas de rq para documentar

• Mejorar el nivel de detalle

Mejoras necesarias en la Documentación de los requisitos



151

o Evitar hablar de tecnología durante la elicitación evita que el usuario se sienta

confundido.

o La fortaleza en la elicitación de requisitos, radica en una buena preparación humana,

antes de iniciar el proceso es decir “en la formación de personas, que hablan con

personas”.

Los ingenieros deben ser más proactivos, generando estrategias de elicitación diferentes

para cada tipo de público y realizando propuestas que lleven a los usuarios a efectuar la

toma de decisiones. En ese contexto, una de las técnicas más usadas es la entrevista para

que hay que tener en cuenta, las sugerencias de la Figura 32. Mejoras sugeridas en la

elicitación de los requisitos.

Figura 32. Mejoras sugeridas en la elicitación de los requisitos.

Respecto al tiempo dedicado al proceso: La literatura no hace señalamientos respecto al

porcentaje de tiempo del proyecto que se debe dedicar a la Ingeniería de Requisitos, sin

embargo, para las organizaciones del estudio este depende en gran medida de factores

como:

Mej

ora

s n

eces

aria

s en

la e

licit

ació

n d

e lo

s re

qu

isit

os.

Te

cnic

a En

trev

ista

.

Son hechas utilizando términos muy vagos.

Se quedan temas sin tratar por el corto tiempo destinado

La mezcla de diferentes temas en la misma sección genera confusión

El ingeniero debería dirigir mejor la entrevista siendo menos introvertido.

El ingeniero debería conocer mas y mejor la técnica

Se debe tener conicimiento previo y detallado del cliente



152

o Experiencia del ingeniero, quien tiene la capacidad de encontrar los stakeholders de

mayor aportación, incluirlos en el proceso y encontrar estrategias que generen

información valiosa.

o El entrenamiento que tenga el equipo para realizar el proceso.

o Otras opiniones dicen que el tiempo del proceso depende de su duración y que es al

pensar en la duración del proyecto que se asigna el tiempo que se destinará para

Ingeniería de Requisitos.

o Como factor de demora está el hecho de que cuando el cliente entrega documentos

de requisitos (como se ha vuelto costumbre en el medio), se debe dedicar más

tiempo al proceso para esclarecer el documento ante la organización desarrolladora

y de encontrarse fallas en el proceso es más difícil tener acceso a los stakeholders

para realizar las aclaraciones

Como buena práctica: Se señala la utilización de plantillas que agilizan el proceso y

orientan al usuario en la consecución de sus deseos.

Referente al acercamiento al cliente: Standish Group International para el 2011, Chaos

Report, informa que principales factores de fracaso de los proyectos son por requisitos

incompletos el 13,1%, y en segundo renglón por qué falta involucrar usuarios 12,4%.

Además según Jacobe el 55% de los requisitos no son usados por los usuarios o clientes, a

este nivel, este estudio encuentra que las organizaciones están conscientes de la necesidad

de involucrar a los clientes en el proceso y para ello han generado estrategias como tener un

paquete de capacitación previo que se aplica a las organizaciones cliente y donde se

evidencia la necesidad de la participación activa de éste en cada etapa del proceso, otras

organizaciones aunque no tienen elaborado el curso, si generan estrategias que hacen que el

cliente conozca sus grados de involucramiento en el proceso, las consecuencias de no

involucrarse y por el contrario las ventajas de estar presente en cada etapa además de las

actividades generadas en cada una de ellas. Para las organización del estudio, la falta de

compromiso inicial del usuario después de hacer esfuerzos por contactarlo e involucrarlo,

genera no contratar el proyecto, pues de hacerlo los riesgos son de alto nivel por tanto no se

expresa como un aspecto a mejorar.

Como mejores prácticas para involucrar al cliente en la Ingeniería de Requisitos esta:

o Generar estrategias que informen al cliente su importancia al formar parte y las

consecuencias de no estar activo.

o Tener claro el gobierno institucional

o Hacer claridad desde antes de la contratación de la necesidad de tener clientes

dispuestos y comprometido.

o Los prototipos representan un acercamiento a la realidad del cliente por tanto es una

buena manera de motivarlo a participar.

o Tranquilizar al cliente informándole qué tipo de preguntas se usaran y que no

deberá tener conocimientos de ingeniería para formar parte.



153

En apoyo a lo anterior se presentan algunos otros aspectos que hoy son fuente de mejora

continua en las organizaciones del estudio en el proceso Ingeniería de Requisitos, a saber:

o La rastreabilidad en los requisitos.

o Generar adecuados controles de cambios y gestión de la configuración

o Simplificar la Ingeniería de Requisitos para acortar el tiempo transcurrido entre la

elicitación y el proyecto. La simplificación podría venir de la elaboración de los

documentos que hacen parte del proceso.

o Que la Ingeniería de Requisitos sea en realidad la base de estimación de los

productos

o Lograr la homologación de los conceptos que hoy son subjetivos en la organización,

como casos de uso.

La gráfica 12 resumen de resultados mejoras en Ingeniería de Requisitos, Muestran el

resumen del resultado generado por las organizaciones respecto a las necesidades de mejora

en aspectos de Ingeniería de Requisitos.

RESUMEN DE RESULTADOS MEJORAS EN INGENIERÍA DE REQUISITOS

Figura Interpretación

La documentación de la Ingeniería de

Requisitos requiere ser mejorada, para

lograr entre otros beneficios, el

entendimiento de los requisitos en todo el

equipo de desarrollo para el 62% de las

organizaciones.

Es necesario generar mejores estrategias y

técnicas de elicitación en Ingeniería de

Requisitos, para lograr entre otros

beneficios, obtener datos relevantes a la IR

para 37% de la organización del estudio.



154

El 12% de las organizaciones consideran

necesario mejorar el tiempo que dedican a

IR, esta consideración ligada a la

experiencia del equipo de trabajo, al tipo de

proyecto y hasta a las características del

cliente

Gráfica 12. Resumen de resultados mejoras en Ingeniería de Requisitos

No obstante, la Ingeniería de Requisitos en una organización desarrolladora de software es

un proceso apalancado de otros procesos organizacionales como el conocimiento del

alcance del proyecto, la destinación de los recursos necesarios, la estimación del tiempo, la

estimación del costo y la incidencia en la calidad de los proyectos. Este trabajo, da a

conocer en qué medida la Ingeniería de Requisitos cumple su función de apoyar cada

proceso en la organización en la gráfica 13. Apoyo la de Ingeniería de Requisitos a los

proyectos de desarrollo

APOYO DE LA INGENIERÍA DE REQUISITOS A LOS PROYECTOS DE

DESARROLLO

Gráfico Interpretación

Para el 75% de las organizaciones IR apoya el

conocimiento del alcance del proyecto de

manera total mientras que para el 25% el

apoyo es parcial y asociado a otros procesos

Para el 75% de las organizaciones IR apoya la

destinación de los recursos del proyecto de

manera total mientras que para el 25% el

apoyo de IR es parcial es decir, solamente

para la estimación inicial mientras que

durante el proyecto el apoyo es asociado a

otros procesos.



155

Para el 63% de las organizaciones IR apoya la

estimación del costo del proyecto de manera

total mientras que para el 25% el apoyo de IR

es parcial. Aunque se toma en cuenta no es el

apoyo principal a la estimación.

Como apoyo en la calidad de los productos IR

es un factor 100% determinante.

Gráfica 13. Apoyo del proceso de Ingeniería de Requisitos a los proyectos de

desarrollo

Otros aspectos que apalanca la Ingeniería de Requisitos en las organizaciones son:

- Conocimiento del negocio y sus estrategias

- Estimación del tiempo

- Claridad al cliente con relación al proyecto

En este sentido, las tareas asociadas con el análisis y especificación de requisitos existen

para dar una representación que pueda ser revisada y aprobada por el cliente, en un mundo

ideal el cliente desarrolla una especificación de requisitos del software completamente por

sí mismo. Pero esto se presenta raramente en el mundo real del software, donde en el mejor

de los casos, la especificación se desarrolla conjuntamente entre el cliente y el técnico.

Basado en ello y buscando resultados y buenas practicas, que lo logren involucrar en la

Ingeniería de Requisitos se indagó sobre las estrategias que utilizan las organizaciones en el

proceso de Ingeniería de Requisitos los resultados se muestran en la Tabla 14. Estrategias

para involucrar al cliente en el proceso, esto sin dejar de tener en cuenta que para todas las

organizaciones involucrar al cliente en el proceso es el paso más importante, por tanto se

presta la mayor atención a este aspecto antes de iniciar el proyecto.

Tabla 14. Estrategias para involucrar al cliente en el proceso

ESTRATEGIAS PARA INVOLUCRAR AL CLIENTE EN EL PROCESO

Presentar al cliente el proceso en términos de las ventajas y beneficios que le aporta el

hecho que el proceso de requisitos sea completamente realizado en conjunto con la

empresa.



156

Hacer énfasis en costo beneficio sin olvidar el tiempo como ventajas de usuario.

Mostrar los riesgos, en caso de no delegar a una persona idónea para que atienda el proceso

de requisitos con la empresa desarrolladora.

Negociar los requisitos del cliente claramente, explicándole la diferencia entre lo que

quiere y necesita y la ganancia obtenida al realizar buenas elecciones.

Tener ingenieros encargaos del proceso de requisitos con la pericia y experiencia

suficientes para involucrar al cliente en todo el proceso.

Tener programadas capacitaciones en video que de manera general muestran a cada cliente

la metodología utilizada para el desarrollo de los productos y cada una de las fases

haciendo énfasis en el papel que desempeña el usuario en cada unan y los riesgos de no

estar presentes.

Educación al cliente, mostrándole la definición de roles para su proyecto, las

responsabilidades de cada rol y la dependencia del cliente para cada responsabilidad.

Utilizar estrategias de capacitación como entrevista, encuesta en forma personalizada para

el proyecto

Sensibilizar al cliente y hace que se involucre

Tener claras las líneas de autoridad para que las personas no desistan de participar en el

proyecto y se sientan apoyadas.

Presentarle al cliente un catálogo de requisitos que podrían encaminarlo hacia lo que él

espera del producto.

Tomar al cliente en cuenta y validar con él cada etapa, sin dejarlo largos períodos de tiempo

sin tener comunicación.

Hacer reuniones donde públicamente se diga la participación del cliente.

Ser claros al informar que la participación debe ser durante todo el proyecto y para todas las

fases.

Cabe agregar respecto a la priorización de los requisitos que es el paso donde se busca

identificar la importancia que tiene un requisito en términos de implementación y la



157

secuencia en que ocurrirán las actividades de diseño y prueba de cada de ellos. La

priorización de cada requisito debe depender de las necesidades que tenga el negocio.

Por consiguiente en la Ingeniería de Requisitos la priorización es un aspecto donde se debe

tener especial cuidado, tacto, delicadeza y claridad con los clientes quienes tienen

diferentes expectativas con respecto al sistema a desarrollar, ya sea por opiniones diferentes

o por conflicto de intereses [62], dado que fácilmente se puede generar polémica entre la

visión de la empresa de desarrollo y el cliente quien en muchas ocasiones requiere ser

llevado a pensar y a diferenciar sus deseos de sus necesidades o de las necesidades que

hacen que el producto apoye a la organización.

Basados en la prioridad, cada requisitos puede ser clasificados como mandatorio, deseables

o innecesarios. Un requisito es mandatorio si afecta una operación crítica del negocio. Si

existe algún proceso que se quiera incluir para mejorar los procesos actuales, estamos ante

un requisito deseable; y si se trata de un requisito informativo o que puede esperar para

fases posteriores, el requisito es catalogado como innecesario. Como se observa la prioridad

depende de las necesidades del negocio.

El trabajo con el usuario no termina allí pues una vez categorizados los requisitos, una

estrategia general sería incluir los mandatorios, discutir los deseables y descartar los

innecesarios, analizando el costo, complejidad, riesgos y otros factores. Como se observa

para esta terea se requiere una especial pericia, capacidad de argumentación y sobretodo

acercamiento y comunicación con el cliente y con el equipo de desarrollo. La clave para la

negociación es poder determinar el conjunto de requisitos prioritarios, este estudio generó

alrededor de la priorización de los requisitos la pregunta ¿Qué técnica se utiliza la

organización para priorizar requisitos? Los resultados se encuentran en la tabla 15.

Técnicas de priorización.

En este sentido para [2…] poder ir desde las características generales de los requisitos y

llegar a las especificaciones detalladas, facilita su validación en cuanto a lo que requieren

los clientes y los usuarios dada su posibilidad de rastreabilidad.

Tabla 15. Técnicas de priorización

La priorización la define el cliente los ingenieros somos los guías simplemente.

En un desarrollo iterativo, primero se deben negociar los requisitos

arquitectónicamente de mayor complejidad.

Antes de negociar se debe tener el concepto de la parte técnica referente a la

priorización.

A cada requisito se le debe colocar el porcentaje de importancia durante la



158

negociación de priorización para luego llevar al cliente a decidir.

Se realiza negociación de las necesidades de cliente con relación a los riesgos de

arquitectura y se generan acuerdos.

Es mejor hacer la priorización por cada caso de uso.

De la misma manera, en este apartado se van a tratar actividades relacionadas con la gestión

de requisitos. Entendida como el conjunto de actividades que ayudan al equipo de trabajo a

identificar, controlar y seguir los requisitos y sus cambios en cualquier momento, es

gestionar los cambios de los requisitos y las relaciones entre ellos, las dependencias entre la

especificación de requisitos y otros documentos producidos por el proceso de desarrollo de

software para asegurar consistencia entre los requisitos y el sistema construido es establecer

una línea base para llevar a cabo la ingeniería y gestión del software o mantener

consistencia entre los planes, productos y actividades de software y los requisitos de

sistema asignados al software. Según [53].

La gestión de requisitos implica entonces formalizar los cambios de estos y mantener la

consistencia y otros productos de trabajo del proyecto esto ya que los requisitos presentan

gran variación durante el proceso por factores como los cambios tecnológicos, cambios en

las estrategias o prioridades del negocio, modificaciones en leyes, mal análisis de

problemas que surgen, el problema que se estaba resolviendo cambió, los usuarios

cambiaron su forma de pensar o sus percepciones, cambió el ambiente de negocios, cambió

el mercado en el cual se desenvuelve el negocio. Los cambios deben controlarse y

documentarse, es decir, hay que convivir con ellos y por ello la gestión de cambios es

esencial este apartado del estudio describe en la Tabla 16 Estrategias para realizar gestión

de cambio de requisitos, la forma como se realiza el proceso en las organizaciones

antioqueñas de software, que formaron parte de este estudio.

Tabla 16. Estrategias para realizar gestión de cambio de requisitos

ESTRATEGIAS PARA REALIZAR GESTIÓN DE CAMBIO DE REQUISITOS

Hay línea base, todo cambio entra por solicitud de cambio y de acuerdo al nivel se

conforma comité de cambios.

En cada proyecto hay un grupo que evalúa cambios y miden el impacto: técnico,

funcional y económico para negociar con el cliente el cambio

Se evalúa el impacto del cambio en cada proceso, presentarlo al CCB (configuración

control board) existe un comité encargado de aprobar o no los cambios de requisitos, se

comunica al cliente su impacto, se realizan estadísticas de cambios y estabilidad de



159

requisitos.

Hay un proceso definido de gestión de cambio, luego se negocia los cambios con el

cliente

De cada cambio se mide impacto, se hace seguimiento y rastreabilidad.

El proceso se inicia: cliente, ventas director de proyecto, y es el comité quien lo hace

La gestión del cambio es por tanto de una u otra manera medida por todas las

organizaciones del estudio, todas miden el impacto de los cambios.

Por lo tanto, se sabe por la literatura que los requisitos de software deben tener propiedades

como las de ser claros, completos, identificar al usuario que los requiere, estar enfocados en

el resultado establecido, ser verificables, evitar conflictos al interior de los miembros del

proyecto, agilizar el proyecto, ser consistentes, suficientes y rastreables. A continuación en

la Tabla 17 se citan las propiedades deseables para los requisitos en las organizaciones.

Tabla 17. Propiedades deseables de los requisitos

PROPIEDADES DESEABLES DE LOS REQUISITOS

o Ser entendidos por todo el equipo de trabajo

o Deben ser el insumo base de la estimación y no el insumo de apoyo

o Ser consistentes

o Ser rastreables

o Deben identificar los stakeholders

o Tener adecuados niveles de detalle de las necesidades

o No permitir niveles de conocimiento tácito

o Reflejar las necesidades del negocio

o No prestarse para varias interpretaciones (ambigüedad)

o Deben agilizar el proceso

o No causar conflicto



160

o Ser entendidos por todo el equipo de trabajo

Se puede afirmar que la documentación en los requisitos es la actividad que mayor atención

requiere con el 65% de la productividad para las empresas, mientras que la consistencia y el

hecho de que los requisitos sean concretos está generando el 70% de productividad, en el

proceso están los ítems de claridad como completitud y rastreabilidad con el 75%, entre el

80% y el 85% están en las propiedades enfoque a resultados, suficiencia, verificación y

apoyo en la estimación. Las mejores propiedades que presenta la Ingeniería de Requisitos

hoy es la identificación de los stakeholder y la agilidad en los resultados, lo anterior se

muestra en la gráfica 14. Propiedades deseables de los requisitos.

Gráfica 14. Propiedades deseables de los requisitos

No obstante, como buena práctica de validación y para evitar conflictos cada una de las

personas cuando recibe los requisitos los aprueba como entendidos y para continuar la

validación con quien los hizo es necesario saber si los entendió a cabalidad para poder

continuar con el proceso.

En este sentido, la validación es la etapa final de la Ingeniería de Requisitos. Su objetivo es

verificar todos los requisitos que aparecen en el documento especificado para asegurarse

que representan una descripción por lo menos aceptable del sistema que se debe

implementar. Esto implica verificar que los requisitos sean consistentes y que estén

completos.

El proceso de validación de requisitos tiene como finalidad comprobar que los mismos,

poseen todos los atributos de calidad enunciados. Este estudio pidió a las organizaciones



161

relatar los criterios y/o técnicas que utilizan para validar los requisitos la Tabla 18. Técnicas

y criterios de validación de datos. Muestra las técnicas y los criterios de validación.

Tabla 18. Técnicas y criterios de validación de datos

TÉCNICAS Y CRITERIOS DE VALIDACIÓN DE DATOS

Realizar revisión por pares, que posteriormente se almacena en buctraker, con una

lista de chequeo.

Tener un área capacitada, con estándares y encargarla del proceso, por ejemplo el

área de calidad.

Tener documentos de referencia, con criterios, con ejemplos y contra ejemplos para

que allí puedan referenciarse los ingenieros.

Solo se valida lo que se encuentre en la herramienta de requisitos.

“El cliente decide que desea” sin esa aprobación no se lleva a cabo el requisito.

Hacer EPG como prueba adherencia al proceso de verificación de requisitos.

Hacer revisiones internas con una lista de chequeo y con los clientes, o utiliza

planilla.

Utilización de una base de datos de conocimiento.

De la misma manera, referente a las herramientas para realizar el proceso de Ingeniería

de Requisitos, es importante ver que esta fungen como un medio facilitador para

agilizar y mejorar los procesos involucrados en todo el ciclo de vida presentado por la

Ingeniería de Requisitos, y que en conjunto ayudan a la construcción final de un

producto de software terminado. Estas herramientas permiten entre otras cosas tener un

mayor control en proyectos complejos, reducir costos y retrasos en los proyectos,

ayudan a determinar la complejidad y los esfuerzos necesarios. En este apartado se

presentan características generales de una de las herramientas más utilizadas para este

propósito por las organizaciones que participaron en la investigación. La gráfica 15.

Herramienta más utilizada por las organizaciones en Ingeniería de Requisitos. Donde se

muestra el porcentaje de uso de cada herramienta en Ingeniería de Requisitos.



162

HERRAMIENTA MAS UTILIZADA POR LAS ORGANIZACIONES

EN INGENIERÍA DE REQUISITOS

Gráfica 15. Herramienta más utilizada por las organizaciones en Ingeniería de

Requisitos

Por consiguiente, un repositorio es un sitio centralizado donde se almacenan un conjunto de

servicios e información ofrecidos por una institución con el objeto de gestionar, difundir y

facilitar el acceso a las personas miembros de un equipo. Dentro de las ventajas que aporta

el repositorio está la descarga, publicación y desarrollo colaborativo y que facilita el

seguimiento de proyectos y el acceso de manera centralizada e incentiva la gestión

colectiva del conocimiento. Aquí se evidencia que el 100% de las organizaciones tienen

repositorio; el cuestionamiento es si lo utilizan o no como fuente de consulta para

estructurar un requisito. En los resultados que propiciaron las organizaciones consultadas se

demuestra que para el 60% de ellas la consulta es de más del 90%, mientras que el 40%

dicen que su repositorio es consultado entre el 51% y el 60%.

Por lo anterior se puede afirmar, que la incorporación de los procesos en la cultura

organizacional es tal vez el eje central del éxito de este proceso, por tanto este estudio pide

a las organizaciones describir la forma como cómo tiene incorporada la organización en su

cultura organizacional, la Ingeniería de Requisitos y los aspectos en que es necesario

generar planes de mejora. Algunas estrategias de incorporación de IR a la cultura

organizacional fueron:



163

- La implementación de áreas de REQM y RD según el modelo de CMMi, con

analistas de requisitos especializados

- Tener un proceso IR claro y definido

- Valerse de auditorías para monitorear el estado de la IR

- Tener clara la trazabilidad de IR

- Mantener alineado IR con la arquitectura empresarial

- Especificar los niveles de detalle de la especificación

- Generar estrategias de transferencia de conocimiento

- Formar a los ingenieros en habilidades para la IR

- Utilizar manuales en la intranet como DR-20

Por consiguiente, el entorno juega un papel importante en la Ingeniería de Requisitos,

pues de él se desprenden situaciones de conocimiento de la cultura de las empresas

clientes, las necesidades del mercado, los hábitos de consumo entre otros, para ello las

organizaciones realizan investigación de mercado que posteriormente se visualizan a

través de cambios en los requisitos. Por tanto este apartado del estudio decide indagar si

en las organizaciones que participaron del estudio, la investigación de mercado parte de

la Ingeniería de Requisitos, por lo que la respuesta es que el 60% de las organizaciones

no tienen las investigaciones de mercado como parte de IR. El 40% de organizaciones

que tienen incorporadas a IR la investigación de mercado señalan que es una buena

práctica y que genera aportes significativos al desarrollo.

Es por esto que uno de los aspectos que requieren mejora en Ingeniería de Requisitos en

la documentación es que deja un alto porcentaje al conocimiento tácito, las

organizaciones señalan las siguientes estrategia para lograr disminuir los niveles de

conocimiento tácito en la Ingeniería de Requisitos:

Tener un banco de Ideas, PA OID CMMi N5, lecciones aprendidas y plataforma de KM

Ya que por medio de entrevistas, nunca se obtiene el 100% del conocimiento, se especializa al ingeniero en el negocio y se usa el stakeholder del lado del cliente

Tener grupos de práctica representados en los comités de arquitectura y analistas

funcionales.

Valerse del conocimiento que tienen los usuarios de los procesos y problemas de los clientes

Por otro lado, para garantizar el éxito en un proyecto software, una de las premisas más

importantes es el conocimiento del público objetivo y sus necesidades, no se trata de

llegar a cuanta más gente mejor, sino a todo el público que le interesa y que tiene real

inferencia en los procesos. Un buen proceso de Ingeniería de Requisitos se basa en

conocer el público interesado para lograr hacer un buen proceso de elicitación, de lo

contrario las posibilidades de fallas son muy altas. El fracaso en los proceso lo causa la

resistencia de las personas, por no sentirse parte, no conocerlo o no aportar sus ideas y

necesidades en la ejecución, basado en ellos las organizaciones definen como



164

fundamental a la Ingeniería de Requisitos para conocer el público objetivo y enmarcan el

cumplimiento de los objetivos del proyecto.

6.3. Algunos aspectos a mejorar en Ingeniería de Requisitos:

- Falta de plantillas para requisitos

- Es necesaria la adopción y adaptación de RUP con sus artefactos para que sean fáciles de entender por el cliente y mantener esa adopción.

- La documentación existente es insuficiente

- Aún queda mucho conocimiento tácito

- Mejorar el entendimiento entre el Ingeniero de desarrollo y el proceso del analista

- Algunas veces los clientes que entienden la propuesta de solución

- Se debe agilizar el proceso

- El cierre del proceso debe ser más ágil

- Algunas veces se presentan polémicas al interior del equipo por la forma cómo se entiende un requisitos se debe unificar el lenguaje interno

- Se deben formalizar reglas internas

- Se debe detallar mejor el alcance y saber qué se hace dentro y fuera del proceso

En ese sentido, la definición de gestión de requisitos es: Un enfoque sistemático para

levantar, organizar y documentar los requerimientos del sistema y un proceso que establece

y mantiene el acuerdo entre el cliente y el equipo del proyecto sobre los requerimientos cambiantes del sistema. En Tabla 19. Estrategias de gestión de requisitos. Se citan las

tácticas utilizadas por las organizaciones para gestionar los requisitos, en la Tabla 20

Estrategias de versiones de los requisitos se muestran las maniobras para versionar los

requisitos y en la tabla 21. Proyectos con mayor destreza en ingeniería de requisitos. Se

citan los proyectos que en el mercado del software Antioqueño presentan fortalezas en su

elaboración por parte de las empresas desarrolladoras. [33]

Tabla 19. Estrategias de gestión de requisitos.

ESTRATEGIA DE GESTIÓN DE REQUISITOS

Revisión de pares que se almacena en buctraker

Listas de chequeo

Se hace EPG como prueba adherencia al proceso

Negociación con el cliente

Utilizar una herramienta de modelamiento automatizada, capacitación a personas

involucradas en el proceso

Usar de todas las técnicas de elicitación

Sensibilizar al cliente

Comunicación permanente con el cliente

Revisión por pares



165

Documentos propios de la organización con listado de requisitos

Creación de rol de coaching como apoyo al proceso

Tabla 20. Estrategias de versionamientos de requisitos

ESTRATEGIAS PARA VERSIONAR LOS REQUISITOS

Estrategia de gestión de versionamientos

Uso de herramienta Visual sorseis, partiendo de línea base, hay proceso de

gestión de cambio y control de versiones

Proceso de Gestión de Configuración, EAP Por cada fase se versiona (fase de

elicitación, fase diseño…)

Se realiza gestión de la configuración, un equipo se reúne para determinar el

impacto del cambio y lo aprueba, luego lo negocia con el cliente.

Todo el proceso de gestión de la configuración, más herramientas para

manejo de versiones

Gestión de la configuración en Tim System

Por cada cambio se genera una nueva versión una vez validado el cambio

Con catálogo de fox wiki, se tienen los versionamientos

Gestión de configuración de CMMI, hay versionamientos y rastreabilidad

Tabla 21. Proyectos con mayor destreza en ingeniería de requisitos

PROYECTOS CON MAYOR DESTREZA EN INGENIERÍA DE

REQUISITOS

Software a la medida

Sector financiero

Proyectos muy grandes

Sector de seguros

Desarrollo de servicios

Seguros

Se presentan ante los clientes con un proceso de desarrollo muy definido.

Consultoría SAP

Automatización de procesos

Criterio de seguridad

Migración de legassi a web

Comunicación con sistemas, (SAP con otro sistema)



166

Relacionamientos entre sistemas y la organización

Según lo antes dicho, se puede apreciar que el proceso de Ingeniería de Requisitos es un

conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra

dar un mantenimiento adecuado al documento de especificación de requisitos, que es el

documento final, de carácter formal, que se obtiene de este proceso. Es necesario recalcar,

que no existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada

organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté

desarrollando, a la cultura organizacional y al nivel de experiencia y habilidad de las

personas involucradas en la Ingeniería de Requisitos. Por tanto hay muchas maneras de

organizar la Ingeniería de Requisitos.



167

7. CAPÍTULO CONCLUSIONES, TRABAJOS FUTUROS, MEJORES

PRÁCTICAS

7.1. Conclusiones

Se ha hablado mucho al respeto a la incidencia de una deficiente Ingeniería de Requisitos

en la calidad del producto final y en este mismo sentido la incidencia en la satisfacción del

cliente, en consecuencia esta es la supervivencia de las organizaciones desarrolladoras de

software.

La literatura ha generado métodos procesos propuestas tendientes a mejorar el proceso de

desarrollo software en general sin embargo en ellos se hacen especial énfasis en que el

éxito del desarrollo software depende de la adecuada ingeniería de requisitos.

La producción de software implica innovación en cada uno de sus eslabones de la cadena

de valor, por lo que el aprendizaje tecnológico y la integración de todos los actores y

agentes en un sistema son requisitos esenciales para construir, fortalecer y acumular las

capacidades de innovación en la industria.

Los resultados del estudio tendientes la confirmación de las hipótesis fueron:

Hipótesis 1: La competencia en el mercado es un objetivo estratégico clave en las empresas

que desarrollan productos de software:

Resultado del estudio: Las empresas coinciden en que la competencia en el mercado es un

objetivo estratégico clave, ya que frente a un mercado cada vez más competitivo, las

empresas tienden a agregar características adicionales a los productos y a comprimir los

plazos de entrega, lo que resulta en una falta de coincidencia completa de los requisitos y

recursos, dando lugar a productos que no satisfacen las necesidades del cliente en tiempo y

calidad.

Además aunque las organizaciones reconocen la importancia del proceso en muchos casos

no lo tienen institucionalizado, aunque en la mayoría de los casos si lo tienen descrito, lo

que se presta para la realización de cambios y adiciones de última hora que pueden no estar

contempladas en el alcance, que carezcan de rastreabilidad o que requieran para su

desarrollo recursos adicionales.

Hipótesis 2: Los mayores desafíos para el crecimiento y gestión del mercado, no son los

aspectos relacionadas con problemas técnicos

Resultado del estudio: Se demostró que los niveles de estudio de los empleados son

competentes para sus funciones y que además las organizaciones aplican planes y

estrategias de capacitaciones periódicas. Los mayores desafíos se presentan en:



168

- La necesidad de conocimiento del negocio que es la base para orientar al cliente brindándole elementos para la generación de ideas que logren que el producto genere

valor.

- Teniendo en cuenta que la elicitación es un proceso humano y no técnico, es necesario fomentar las habilidades comunicativas y pedagógicas en el ingeniero para que logre

adaptar sus estrategias de elicitación al tipo de negocio, de proyecto y de stakeholders

logrando obtener toda la información necesaria sin excesos ni faltantes.

- Es necesario fomentar niveles adecuados de redacción y escritura en los ingenieros para

que la documentación realizada durante el proceso de ingeniería sea clara y concreta

para todos los miembros del equipo de desarrollo.

Hipótesis 3: Los requisitos suelen ser inventados por los desarrolladores internos de la

compañía

Resultados del Estudio: Los problemas de definición de alcance, volatilidad en requisitos y comprensión de los mismos, lleva a que en determinados casos estos sean inventados por

los desarrolladores internos de la compañía, por tanto se hace necesario tener la técnica de

IR institucionalizada e implementada que brinde claridad en cuanto a la gestión del cambio

y que tenga estándares de documentación claros para el entendimiento de todo el equipo y

que muestren claramente el alcance y de cada uno de los requisitos para cada entrega.

Hoy es muy sentida la invención de los requisitos como respuesta a la falta de claridad en la

documentación o a la necesidad de completar el requisito o de incluir una funcionalidad

nueva que no está correctamente documentada desde el inicio del proyecto sino que aparece

como respuesta a un cambio que no se gestionó completamente por falta de tiempo u

decisión de última hora.

Hipótesis 4: Los requisitos son pobremente documentados

Resultados del Estudio: La documentación es considerada en el medio uno de los

factores críticos, puesto que la documentación debe permitir que los requisitos sean

entendibles y claros para todo el equipo de desarrollo, debe ser el medio para logra claridad

de lo que se va a desarrollar, el alcance de lo que se va a desarrollar y de la estimación en

recursos, tiempo y costos.

- En la actualidad las estimaciones del alcance del proyecto y sus recursos se realizan basadas en técnicas ad hoc o juicio experto dejando la documentación como un

apoyo y no como el soporte del proceso de estimación del proyecto.

- Se encuentran en algunos casos mucha documentación lo que no solo retrasa el

proceso sino que se sabe que el concepto la calidad en los requisitos no

necesariamente es igual la cantidad, más bien se requieren datos concretos, por el

contrario el exceso de datos es equivalente a la mala documentación en requisitos



169

pues se hace difícil de manejar y se torna improductiva para la persona que la crea y

un obstáculo para las personas que buscan la información.

- Se presenta documentación incompleta o que se presta para ser interpretada de diferentes maneras, lo que impide la rastreabilidad del requisitos, actividad que es

particularmente importante porque una de las características principales del proceso

de desarrollo software es el manejo de requisitos cambiantes.

- La documentación realizada en la ingeniería de requisitos carece de formalidad para apoyar la negociación.

Hipótesis 5: La priorización de las necesidades y la planificación de la nueva versión son

procesos cruciales para la ventaja competitiva

Resultados del Estudio: La correcta selección de los requisitos en la planificación de

cada entrega de un producto implica el análisis de importancia para el cliente y el hecho de

resolverlas según el proceso de priorización implicara siempre una ventaja competitiva

pues está directamente ligada a la satisfacción del cliente. Es por eso importante que el

cliente tenga claridad referente a: los resultados del proceso de priorización que indican el

orden en el que se desarrollará el producto, el alcance de cada entrega, las implicaciones en

estimación de un cambio. En este sentido se debe tener en cuenta que un proceso de

estimación requiere el conocimiento claro del alcance de los requisitos cumplimiento en

tiempo y satisfacción de las necesidades y expectativas reales del usuario y por tanto

calidad del software y la competitividad en el mercado.

Hipótesis 6: La relación entre los desarrolladores y los clientes suele ser larga, pero con la

proximidad limitada

Resultados del Estudio: Se logró establecer que el mercado de desarrollo de software

antioqueño enfrenta varias situaciones que demuestran proximidad limitada con los

clientes, entre estas están: los clientes que ocultan información por no considerarla

relevante o bien por considerarla secreto del negocio y los clientes que desconocen lo que

necesitan del sistema y tienden a confundir sus necesidades y sus deseos, en ambos casos

estos son llamados en este estudio clientes críticos y que situaciones como estas

obstaculizan el proceso, generan reproceso y deterioran la calidad de los productos.

Hipótesis 7: El fracaso del lanzamiento del producto a menudo se produce debido a que el

producto no cumple con las necesidades de los clientes

Resultados del Estudio: Las fallas en el proceso de IR espacialmente durante la

elicitación y la documentación hacen que los productos iniciales presenten defectos en su

primera puesta en producción y se requiere hacer reparaciones que retrasa la entrega

definitiva, otra causas está ligada a las deficiencias al procesar los cambios.



170

Todo lo anterior esta evidenciado en este estudio cuando se muestra como la mayor causa

de insatisfacción de los clientes está en las entregas tardías de los productos por causas

orientadas a insatisfacción en los requisitos.

Hipótesis 8: Los requisitos son evaluados sólo después de su lanzamiento en el mercado.

Resultados del Estudio: Factores como la falta de proximidad con el cliente, la

aceptación de requisitos fuera del alcance debido entre en muchos casos por la presión del

mercado competitivo, entre otros hacen que en muchos casos los requisitos sean evaluados

después del lanzamiento.

En el medio antioqueño los ajustes que es necesario hacer a un producto luego de su

lanzamiento demuestran que pese a que se realizan procesos de verificación y validación

previos al lanzamiento y se tiene como política en la mayoría de los casos involucrar al

cliente durante todo el proceso, los productos no tienen los resultados esperados, lo cual

demuestra que solo en este momento se realiza la real validación y verificación de los

requisitos.

Hipótesis 9: Los desarrolladores de productos de software por lo general tienen un proceso

de ad hoc, para definir y gestionar los requisitos

Resultados del Estudio: Las organizaciones tienen en muchos casos documentado el

proceso Ingeniería de Requisitos, sin embargo este carece de institucionalización y o de

completitud frente a situaciones como la gestión del cambio lo que lleva a aplicar

soluciones ad hoc. Por otro lado, hoy las organizaciones han creado estrategias tales como:

tener el proceso formalizando, utilizar metodologías que lo apoyen, realizar seguimientos

que midan los niveles de satisfacción de los usuarios durante el proceso, etc. No obstante,

aún existen factores de ambigüedad en los requisitos, falta documentación clara y de

habilidad en la elicitación que hace que los procesos sean ad hot.

En la realidad antioqueña las organizaciones expresaron la ausencia del usuario como un

factor que los motiva a suponer requisitos, que posteriormente pueden no ser los adecuados

en el momento de la validación.

Hipótesis 10: El proceso utilizado para IR en el desarrollo de software a medida difiere del

utilizado para el desarrollo de paquetes de software, a tal grado que las prácticas de

Ingeniería de Requisitos tradicionales usadas en el desarrollo a la medida no pueden

emplearse para desarrollar paquetes software.

Resultados del Estudio: Es una realidad que entre el 40% y el 60% de los errores y

defectos del software a medida son el resultado de una pobre gestión y definición de

requisitos, aproximadamente la mitad de los problemas encontrados se podrían haber

evitado, simplemente con dejar claro desde el principio, lo que el cliente espera del

proyecto, bajo este contexto se deja ver la necesidad manifiesta de tener contacto con el



171

cliente y conocer sus necesidades para lograr calidad en el software a medida, mientras que

a esta tarea en el software COTS no se le puede dar cumplimiento detallado por que no se

tienen clientes específico sino consumidores varios y estrategias de marketing para

apoyarse. Sin embargo es un hecho que las estrategias de marketing son un insumo

importante para apoyar la Ingeniería de Requisitos en el software a medida, pero teniendo

en cuenta que la calidad de este depende directamente es de la relación directa con el

cliente.

7.2. Estudios futuros:

Los siguientes son una lista de temas que a lo largo de este estudio se encontraron como

aportantes, necesarios y que de ejecutarse generan valor al medio del desarrollo software.

Replicar este estudio en otras regiones con el fin de obtener un conjunto de buenas prácticas en Ingeniería de Requisitos.

Compendiar las buenas prácticas en Ingeniería de Requisitos realizadas hasta el

momento.

Conocer el manejo, la estructura y las buenas prácticas a nivel de los repositorios de software específicamente la manera como se maneja la parte de repositorio en el tema

Ingeniería de Requisitos y los niveles y documentos de reúso.

Conocer las competencias que poseen y las buenas prácticas usadas por los ingenieros analistas de requisitos que hacen que su labor sea exitosa y la formación brindada por

las universidades a este nivel.

7.3. Buenas Prácticas:

Buenas prácticas en elicitación de requisitos:

o No hay que olvidar que los aspectos humanos de la ingeniería son responsables de más

del 50% del éxito del proceso.

o Los analistas deben tener suficientes habilidades pedagógicas y de comunicación que

permitan acercamiento y lectura de los mensajes de los stakeholders

o Por norma general se debe tener conocimiento del negocio previo al inicio de la

elicitación.

o El hecho de que los clientes entreguen sus requisitos no garantiza que estén en estado

tal que se pueda iniciar el de inmediato el desarrollo, sin que sea necesario ajustarlos o

rehacerlos, por tanto al estimar no se debe dar esta actividad como hecha.

o La utilización de un experto en manejo de técnicas grupales, permite al elicitado tomar

nota de asuntos importantes para el proceso, observar las actividades en búsqueda de

líderes.



172

o Tener en una actividad grupal de elicitación a dos personas tomando nota evita que la

información se pierda y garantiza mayor grado de validez.

o Las organizaciones deben tener estructuradas capacitaciones donde se eduque al cliente

mostrándole la importancia de su participación, los roles, las etapas y sus niveles de

intervención hasta llegar a un esbozo de sus tareas, para que este se programe.

Buenas prácticas en Documentación de requisitos.

o El manejo de prototipos es una herramienta fundamental para dar claridad al desarrollo.

o Es necesario asegurarse de que el analista maneje técnicas adecuadas de lectoescritura.

o La cantidad de documentación en lugar de agilizar obstaculiza ya que no siempre se

puede leer toda la información y además se puede prestar a diferentes interpretaciones

por lecturas incompletas.

Verificación y Validación de Requisitos.

o El ingeniero de requisitos debe entender la necesidad y plantear la solución que orienten

al cliente en la solución.

o El cliente debe conocer claramente las implicaciones de no involucrarse en el proceso.

o Los requisitos no funcionales deben tener un nivel de importancia alto para la ingeniería

de Requisitos y deben ser acordes con la organización por tanto se requiere hacer

lectura específicas de ella para obtenerlos.

o Se debe conocer negocio con el fin de orientar el cliente en la solución que genera

mayor valor.

o El cliente debe conocer de manera detallada el proceso de gestión del cambio y sus

implicaciones.

o Para evitar que el tiempo afecte el proyecto una estrategia fragmentar las entregas

o Estas expresiones como las siguientes indican presión y afectan la calidad de los

productos: “Se acabó el tiempo, entreguemos ya lo que tenemos y probamos después,

además esto debería funcionar”, “ya se contrató hay que hacerlo...”, “tenemos tres (3)

meses para hacer…”, “esto es para ya”, “toca trabajar este fin de semana”, “toca

trabajar día y noche”.



173

8. Apéndice A Encuesta sobre la Caracterización de Las Empresas que

Desarrollan Productos Software en Antioquia Colombia.

Basados en la tesis doctoral (1) se ha venido adelantando un estudio algo similar en el

medio colombiano. Contando con la colaboración de un grupo significativo de empresas

que llevan más de diez (10) años de estar en el mercado del software, y que se han

vinculado al estudio generando aportes de conocimiento.

La intención con el instrumento encuesta es obtener las información con el fin de

caracterizar a las organizaciones participantes en el estudio, brindándoles garantía de

confidencialidad en la información y garantizando comunicar los resultados del estudio.

Este documento encuesta, contiene un conjunto de preguntas para ser contestadas por uno o

más representantes de las empresas que forman parte del estudio empírico.

El objetivo de este instrumento de la encuesta es obtener información que contextualice la

organización en temas como identificación, número de empleados y una serie de

particulares más que permiten determinar el tamaño de la empresa y sus características en

el desarrollo del producto software.

Beneficios son: Las empresas que participan en este estudio tendrán acceso a todos los

informes y artículos publicados sobre la investigación. Basado en resultados de la

búsqueda, las empresas reciben un informe contiene directrices específicas para las

empresas participantes sobre la manera de mejorar sus procesos de ingeniería de requisitos

durante el desarrollo de productos de software. Otro beneficio importante es estimular el

debate entre los profesionales industria de software local.

Cualquier duda o aclaración sobre esta encuesta sobre el proyecto de investigación,

“Estudio Sobre el Proceso y la Productividad de la Ingeniería de Requisitos en las

Empresas Antioqueñas de Software, puede comunicarla con Luz Janette Vélez Mejía en el

e-mail: [email protected].



174

Apéndice A



SOFTWARE

ENCUESTA

DOCENTE ASESOR: DOCTOR ALBERTO ANTONIO RESTREPO VELÁSQUEZ

ESTUDIANTE: INGENIERA LUZ JANETTE VÉLEZ MEJÍA

UNIVERSIDAD EAFIT


2012



175

Se aplica este instrumento en el estudio “EL PROCESO Y LA PRODUCTIVIDAD DE

LA INGENIERÍA DE REQUISITOS EN LAS EMPRESAS ANTIOQUEÑAS DE

SOFTWARE”, con la finalidad de conocer aspectos generales de las empresas, los

procesos que se llevan a cabo en materia de ingeniería de requisitos y las mejores prácticas

en el proceso.

Agradecemos su compromiso y objetividad ejes fundamentales para alcanzar el éxito en

este proyecto de investigación

Datos del encuestado Fecha

Nombre del encuestado:

Tiempo que lleva laborando en la organización:

Email

Teléfono: Cargo:

Datos de la Organización

Nombre de la organización:

Dirección web:

Teléfonos:

Los siguientes datos se solicitan con el fin de medir en los empleados implicados

directamente proceso de desarrollo, el predominio o déficit de certificaciones, sus niveles

de inglés, y la prevalencia de los empleados en las organizaciones.

1. ¿Número de empleados que laboran en la organización?

2. ¿Número de empleados que intervienen directamente en el proceso de desarrollo

software?

3. Certificaciones

Detalle de las Certificación de los empleados adscritos al proceso de

desarrollo

Número de

empleados

4. Dominio de inglés entre los empleados adscritos al proceso de desarrollo software

Número de empleados con

nivel alto de inglés

Número de empleados con nivel

medio de inglés

Número de empleados

con nivel bajo de inglés

5. Experiencia de los empleados adscritos directamente al proceso de desarrollo software



176

Número de empleados con

Menos de 1 año de

experiencia

1 a 5 años de

experiencia

6 a 10 años de

experiencia

Más de 10 años de

experiencia

6. Tiempo de vinculación de los empleados adscritos al proceso de desarrollo software en

la organización

Tiempo laborado con la empresa

Menos de 1 año 1 a 5 años 6 a 10 años Más de 10

7. ¿Qué metas de certificación o estudio espera lograr la organización para sus empleados?

8. Describa los certificados y valoraciones con que cuenta la organización.

9. Que metas de certificación o valoración espera alcanzar la organización a corto y

mediano plazo.

10. En el contexto del desarrollo de software ¿Cuáles roles de la lista siguiente tiene

definidos la organización?

Analista de Sistemas/Analista Técnico Funcional

Ingeniero de validación y verificación

Tester

Diseñador de Soluciones

Especialista en Seguridad de Aplicaciones

Administrador de Redes, Comunicaciones y Sistemas Operativos

Administrador de Seguridad

Administrador de Base de Datos

Consultor Funcional Junior

Consultor Funcional Sénior

Líder de Proyecto

Project Manager / Director de Proyectos

Ejecutivo Comercial

Administrador de configuración

Líder / Gerente/ Responsable de Calidad

Analista QA (Quality Assurance)

Analista Tester (con Orientación Técnica y/o Funcional)



177

Otros

.

.

.

11. Describa los métodos y/o estrategias que utiliza la organización para actualizar a sus

empleados.

12. ¿Cuáles son los principales nichos de mercado que atiende la organización?

SERVICIOS Y FINANZAS

13. De la siguiente lista selecciones la metodología de desarrollo utilizada por la

organización, en caso de utilizar varias, describa los criterios que llevan a utilizar una

metodología para un proyecto.

Programación extrema

Código abierto

Desarrollo de software adaptable Highsmith

Scrum

Desarrollo manejado por rasgos

Método de desarrollo de sistema dinámico

Manifiesto para desarrollo de software ágil

Otros métodos

RUP

Cascada

.

.

.

14. Si en su organización se desarrolla software complete la siguiente tabla:

TIPO DE

DESARROLLO

PORCENTAJE DE

PRODUCCIÓN

AMBIENTES (y lenguajes)

DE DESARROLLO

UTILIZADO

Juegos

Web

Sistemas embebidos

Sistemas de información



178

Sistemas inteligentes

Sistemas en tiempo real

Desarrollos móviles

Otro

Para empresas desarrolladores de software complete:

15. La cantidad porcentual de sus clientes locales 100% nacionales ______, y

extranjeros_____ con que cuenta la organización.

16. Por cada tipo de cliente el porcentaje de desarrollos realizados anualmente es:

desarrollos clientes locales 100% nacionales______, extranjeros_____

17. Exprese los criterios que tiene la organización desarrolladora de software para clasificar

sus clientes en grandes, medianos y pequeños.

17.1. Clientes grandes son: _________________________________________________

17.2. Clientes medianos son: _______________________________________________

17.3. Clientes pequeños son: ____________________________________________

18. Basado en la información del punto anterior complete

18.1. Porcentaje de clientes grandes que atiende la organización ____

18.2. Porcentaje de medianos clientes que atiende la organización ____

18.3. Porcentaje de pequeños clientes que atiende la organización ____

19. En ¿qué porcentaje y qué tipo de clientes, conocen el proceso software llevado a cabo

en su organización?

Tiempo y trayectoria de los clientes con la organización

20. Cite las etapas del desarrollo más satisfactorias para los clientes de la organización en

orden de satisfacción:

Construcción

Elicitación

Análisis

.



179

21. ¿Cuál es el nivel de satisfacción que presentan los clientes de la organización, en una

escala de uno a diez, siendo diez, el mayor grado de satisfacción? ¿en qué porcentaje de

satisfacción que presentan los clientes de la organización?

Entre 1% y 10%

Entre 21% y 30%

Entre 31% y 40%

Entre 41% y 50%

Entre 51% y 60%

Entre 61% y 70%

Entre 71% y 80%

Entre 81% y 90%

Entre 91% y 100%

22. Describa las causas frecuentes de insatisfacción por parte de los clientes y las etapas

donde se presentan:

23. Cite las formas de contratación que utiliza la organización para los proyectos software:

24. ¿Existe en la organización repositorio de requisitos?

25. Si existe repositorio de requisitos en la organización en qué porcentaje es consultado

por el personal de desarrollo software.

Entre 1% y 10%

Entre 21% y 30%

Entre 31% y 40%

Entre 41% y 50%

Entre 51% y 60%

Entre 61% y 70%

Entre 71% y 80%

Entre 81% y 90%

Entre 91% y 100%



180

26. Describa la forma como se evidencia que tiene la organización incorporada el proceso

de ingeniería de requisitos como parte de su cultura organizacional, y/o que aspectos es

necesario mejorar a este nivel.

27. ¿Es en la organización la investigación de mercado parte del proceso de ingeniería de

requisitos?

28. ¿Qué estrategias se utilizan para extraer el conocimiento tácito?

29. ¿En qué porcentaje, se conoce en los proyectos el público objetivo?

30. ¿Qué estrategias utiliza la organización para captar nuevos clientes?: Publicidad____

ferias ___ eventos ______ compañías de marketing ______ Referenciados por otros

clientes___

31. Explique ¿Qué estrategias utiliza la organización para potenciar sus clientes?

32. ¿Qué estrategias realiza la organización para hacerle seguimiento a los clientes?

33. ¿Realiza la organización seguimiento a los productos y qué estrategias utiliza?

34. ¿Cuál es el proceso que realiza la organización con sus clientes para gestionar nuevas

versiones del producto?

35. ¿Tiene la organización control de tiempo entre la entrega de versiones?

36. Cite los porcentajes de desarrollo software realizados por la organización al clasificar

así: Desarrollos nuevo 60%, Desarrollos por componentes 20%, Desarrollos por

migración 20%

ELICITACIÓN DE REQUISITOS actividad comúnmente llamada levantamiento de

requisitos.

Teniendo presente que elicitar requisitos es según el SEI: “El proceso de identificar

necesidades y conciliar las disparidades entre las comunidades involucradas para el

propósito de definir y refinar los requisitos para satisfacer las restricciones de esas

comunidades”



181

Elicitar requisitos es entonces el proceso a través del cual los clientes, compradores o

usuarios de un sistema descubren, revelan, articulan o entienden sus requisitos y se logran

identificar, recoger, extraer.

37. Diligencia la siguiente información basado técnica en el proceso de elicitación de

requisitos en la organización.

Técnica Porcentaje

de

utilización

Tipo de software

(Juegos, web, sistemas

información, sistemas

inteligentes, sistemas en

tiempo real, desarrollos

móviles)

Tiempo

destinado para

ingeniería de

requisitos

Tiempo que

dura el

proyecto

Introspección

Lectura de

documentos

existentes

Hard date

(datos

escritos)

Entrevista

Encuestas

Cuestionarios

Reuniones

Análisis de

tareas

Análisis de

protocolo

Adquisición

del

conocimiento

Focus groups

Tormenta de

ideas

Workshops

(talleres)

Respecto a la especificación de los requisitos, es decir la forma de registrar los requisitos

38. ¿Qué notación, patrón lingüístico, plantilla utiliza la organización? Describa.

39. Al clasificar los proyectos como grandes, medianos y pequeños complete:

Proyecto Tiempo estimado de Porcentaje de proyectos que Número de empleados



182

desarrollo realizan asignados

Grandes

Medianos

Pequeños

40. iste por lo menos 10 productos software realizados por la organización durante los

últimos meses y diligencia el siguiente formato.

Nombre

del

proyect

o

Cliente

extranjer

o

nacional

o local

Tiempo

total del

proyect

o

Método

para

costear

el

proyect

o

Roles

asignado

s

Número

de

empleado

s por rol

Tiempo

empleado

para

ingenierí

a de

requisitos

Estrategi

a

empleada

realizar

ingenierí

a de

requisitos

9. Apéndice B Entrevista sobre la Caracterización del proceso de Desarrollo

Software y la Ingeniería de Requisitos en las Empresas que Desarrollan

Productos Software en Antioquia Colombia.

El instrumento entrevista, tiene las características de Semi-estructurada y estandarizada.

Este documento contiene un conjunto de preguntas para ser contestadas por uno o más

representantes de las empresas del estudio y se realiza en forma presencial con la

investigadora.

El objetivo de este instrumento es obtener información más detallada sobre el proceso de

desarrollo, la interacción con los clientes, la ingeniería de requisitos y sobre todo para

identificar retos y problemas enfrentado durante el proceso de ingeniería de requerimientos,

esta información además es un complemento a la recopilada en el instrumento encuesta.

La duración de la entrevista es de una (1) hora.



183

Detalladamente los objetivos de la encuesta son: Comprender cómo las empresas llevan a

cabo la ingeniería de requisitos, investigar formas de interacción y el compromiso con los

clientes durante el desarrollo de productos de software, conocer las herramientas utilizadas

en el proceso y la justificación para su uso, descubrir los principales desafíos que enfrentan

en la ingeniería de Requisitos. Pero sobre todo documentar en forma detallada las

experiencias y mejores prácticas.

Apéndice B

PLANEACIÓN DE LA INVESTIGACIÓN



SOFTWARE

ENTREVISTA


ASIGNATURA: PROYECTO DE INVESTIGACIÓN

ASESOR: DOCTOR ALBERTO ANTONIO RESTREPO VELÁSQUEZ

UNIVERSIDAD EAFIT


2012

INTRODUCCIÓN



184

La entrevista es una parte vital del proyecto de investigación ya que, a través de una serie

de preguntas que proponen análisis, se obtendrá información cualitativa y cuantitativa, que

permite relacione las organizaciones, con el proceso de ingeniería de requisitos esto con el

fin de lograr generar un informe de las características, retos desafíos y mejores prácticas de

la Ingeniería de Requisitos en las empresas Antioquenas de Software.

Preguntas de la Entrevista

1. ¿Es importante para la organización en el proceso de ingeniería de requisitos? ____

describa la manera de evidenciar su respuesta.

2. ¿Tienen formalizado el proceso de ingeniería de requisitos la organización?

3. Describa la manera ¿Cómo se realiza el proceso de ingeniería de requisitos en la

organización?

4. Cite y describa los insumos que utiliza la organización en el proceso de ingeniería de

requisitos.

5. ¿Qué el tipo de metodología utiliza la organización durante el proceso de ingeniería de

requisitos?

6. ¿Qué espera la organización a futuro del proceso de ingeniería de requisitos que

realiza?

7. Cuando la organización atiende clientes críticos, es decir clientes: que ocultan

información, que no saben lo que desean, que tienen el tiempo muy limitado, o manejan

políticas altas de privacidad, ¿qué estrategias utiliza la organización para realizar

ingeniería de requisitos? en cada caso.

8. Los aspectos a mejorar en el proceso de ingeniería requisitos en la organización hacen

referencia a, y en ¿qué porcentaje?:

Documentación

Elicitación

Técnicas

Tiempo de dicado al proceso

Acercamiento al cliente

Otros, explique.



185

9. Es la ingeniería de requisitos en la organización un proceso que apalanca:

Conocimiento del alcance del proyecto a desarrollar

Destinación de los recursos necesarios

Estimación del tiempo del proyecto

Estimación del costo del proyecto

Incide en la calidad del proyecto

Otros

10. Describa las estrategias utiliza la organización para involucrar al cliente en el proceso

de ingeniería de requisitos.

11. ¿En la organización se priorizan requisitos? En caso afirmativo ¿qué técnica utilizan?

12. Si se realiza, describa el proceso, de gestiona el cambio de los requisitos en la

organización.

13. Durante el proceso de desarrollo ¿Cuáles de las siguientes propiedades deseables de los

requisitos están presentes en la organización y en qué porcentaje?

Requisitos claros _____

Requisitos completos _____

Requisitos concretos _____

Requisitos que identifican al usuario que los requiere_____

Requisitos que se enfocan en el resultado establecido _____

Requisitos verificables _____

Requisitos que evitan conflictos al interior de los miembros del proyecto ____

Requisitos que agilizan el proyecto _____

Requisitos consistentes _____

Requisitos que impiden un costeo adecuado del proyecto _____

Requisitos suficientes _____

Requisitos documentados _____

Requisitos rastreables _____

Otros



186

14. Describa las herramientas de gestión de clientes utiliza la organización

15. Relate los criterios y/o técnicas que utiliza la organización para validar los requisitos.

16. Describa los criterio y/o técnicas utiliza la organización para verificar los requisitos

17. Cite los software que utiliza la organización para llevar a cabo el proceso de requisitos

18. Cite algunas situaciones que demuestran aspectos a mejorar en el proceso de ingeniería

de requisitos de la organización.

19. Describa la estrategia para gestionar los requisitos en la organización

20. Detalle la estrategia para gestionar las versiones de los requisitos

21. Relate el tipo de proyectos que presentan mayor destreza y fuente de éxito para la

organización al realizar el proceso de ingeniería de requisitos

MUCHAS GRACIAS



187

BIBLIOGRAFÍA

1. [1] Cássia Pereira S. Um Estudo Empírico sobre Engenharia de Requisitos en Empresas

de Productos de Software. [posgrado en Ciencias de la computación] Recife:

Universidad Federal de Pernambuco, Centro de informática; 2007.

2. [2] RESTREPO, Alberto; HENAO, Mónica; ANAYA, Raquel. Aplicación de una

metodología de Ingeniería de Requisitos a un caso real. VII Workshop Iberoamericano

de Ingeniería de Requisitos y Desarrollo de Ambientes de Software, IDEAS2004.

Arequipa – Perú, Mayo 2004.

3. [3] Standish Group International (2011) – www.standishgroup.com. Last Access

Engineering”. 3rd Conference for the Promotion of Research in IT at New Universities

and University Colleges in Sweden.

4. [4] The Standish group. Chaos tuesday #20: • project success verses project value

[internet] [consultado 2013 Ago 25]. Disponible en:

http://blog.standishgroup.com/about-standish

5. [5] Mendoza L, Pérez M, Grimán A. Análisis del Impacto del Proceso de Desarrollo en

las Características de Calidad del Software. [Internet] [consultado 2013 Ago 25]

Disponible en:

http://www.researchgate.net/publication/228556854_Anlisis_del_Impacto_del_Proceso

_de_Desarrollo_en_las_Caractersticas_de_Calidad_del_Software.

6. [6] Sawyer P, Kotonya G. Chapter 2 Software Requeriments [internet]. [consultado

2013 Ago 25]. Disponible en:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.135.6794&rep=rep1&type=p

df.

7. [7] Wiegers KE. When Telepathy Won’t Do: Requirements Engineering Key Pratices

[internet]. [consultado 2013 Ago 25] Disponible en:

http://www.processimpact.com/articles/telepathy.html.

8. [8] Castañeda Zamora. Sistema regional de innovación para potenciar la industria del

software en Antioquia. [internet]. [consultado 2013 Ago 25]. Disponible en:

http://www.dane.gov.co/candane/images/DT_DANE/wp_sistema_innovacion_software

_antioquia.pdf

9. [9] Sommerville, I. (2007) “Software Engineering”. Addison Wesley; 7ª

http://www.researchgate.net/publication/228556854_Anlisis_del_Impacto_del_Proceso_de_Desarrollo_en_las_Caractersticas_de_Calidad_del_Software

http://www.researchgate.net/publication/228556854_Anlisis_del_Impacto_del_Proceso_de_Desarrollo_en_las_Caractersticas_de_Calidad_del_Software

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.135.6794&rep=rep1&type=pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.135.6794&rep=rep1&type=pdf

http://www.processimpact.com/articles/telepathy.html

http://www.dane.gov.co/candane/images/DT_DANE/wp_sistema_innovacion_software_antioquia.pdf

http://www.dane.gov.co/candane/images/DT_DANE/wp_sistema_innovacion_software_antioquia.pdf



188

10. [10] “IEEE Standard Glossary of Software Engineering Terminology” (Stad. 610.12-

1990).

11. [11] Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.

Pressman, R. S. (2006) ”Engenharia de Software”. Makron Books. 6ª Edición.

12. [12] “Engenharia de Software”. Makron Books. 6ª EdiciónLondoño LF, Anaya R,

Tabares MS. Análisis de la Ingeniería de Requisitos orientada por aspectos según la

industria del Software. EIA [internet]. 2008; 9: 43-52 [consultado 2013 Ago 25].

Disponible en: http://revista.eia.edu.co/articulos9/43-52%20(articulo%203).pdf

13. [13] Potts C. Invented Requirements and imagined customers: Requirements

Engineering for Off-the-Shelf Software [internet] [consultado 2013 Ago 25] Disponible

en: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=00512553

14. [14] Londoño Londoño LF. Recomendaciones para la Formación de una Empresa de

Desarrollo de Software Competitiva en un país como Colombia. [internet]. [consultado


http://biblioteca.universia.net/html_bura/ficha/params/title/recomendaciones-

formacion-empresa-desarrollo-software-competitiva-pais-como-

colombia/id/54667899.html

15. [15] Romald Edward Freeman, Tesis doctoral, Programa doctoral en Gobierno y

Cultura de las Organizaciones, Instituto Empresa y Humanismo, Universidad de

Navarra, Pamplona, 2009. Newsletter Nº 5 – Otro punto de vista Noviembre 2009.

16. [16] Pressman, R. S. (2006) ”Engenharia de Software”. Makron Books. 6ª Edition.

17. [17] Wiegers K. Software Requeriments, Second edition (internet) Ciudad: Microsoft;

2003 (consultado el 2013 Ago 20) Disponible en: http://www.amazon.com/Software-

Requirements-2-Karl-Wiegers/dp/B00CVDWS5O.

18. [18] Humphrey W. Introducción al proceso software personal (internet) (consultado

2013 Ago 18) Disponible en: https://mail-

attachment.googleusercontent.com/attachment/u/0/?ui=2&ik=234fd0ea8e&view=att&t

h=14174512bd719097&attid=0.2&disp=inline&realattid=f_hm96ysz01&safe=1&zw&

saduie=AG9B_P9iL5pN4d0pCOoxS18YVyxY&sadet=1380661969830&sads=QNgB4

wnA3ag5kJ6WVsOpp66h-OY

19. [19] IEEE Std. 830 (1984). “IEEE Guide to Software Requirements Specification” The

Institute of Electrical and Electronics Engineers, New York, EUA. (usada en el cap2).

20. [20] Wiegers K. More about software requeriments: Thorny issues and practical advice

(internet) Ciudad: Microsoft Press; 2005 (consultado el 2013 Ago 17) Disponible en:

http://revista.eia.edu.co/articulos9/43-52%20(articulo%203).pdf

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=00512553

http://biblioteca.universia.net/html_bura/ficha/params/title/recomendaciones-formacion-empresa-desarrollo-software-competitiva-pais-como-colombia/id/54667899.html



http://www.amazon.com/Software-Requirements-2-Karl-Wiegers/dp/B00CVDWS5O

http://www.amazon.com/Software-Requirements-2-Karl-Wiegers/dp/B00CVDWS5O

https://mail-attachment.googleusercontent.com/attachment/u/0/?ui=2&ik=234fd0ea8e&view=att&th=14174512bd719097&attid=0.2&disp=inline&realattid=f_hm96ysz01&safe=1&zw&saduie=AG9B_P9iL5pN4d0pCOoxS18YVyxY&sadet=1380661969830&sads=QNgB4wnA3ag5kJ6WVsOpp66h-OY







189

http://my.safaribooksonline.com/book/software-engineering-and-

development/software-requirements/0735622671

21. [21] The Unified Modeling Language User Guide (2nd Edition) [Hardcover]

Rumbaugh--UML_2.0_Reference_CD

22. [22] UPM. La experimentación en Ingeniería del Software [internet] [consultado 2013

Ago 25] Disponible en: http://www.fi.upm.es/docs/estudios/postgrado-

admision/537_Seminario%20ESE.pdf.

23. [23] Mon A, Vinjoy M, Estayno M, Serra D. Experimentación en Ingeniería de Sotware

– Análisis de la influencia de la personalidad en los equipos en el desarrollo de

Software [internet] [consultado 2013 Ago 25] Disponible en:

http://sedici.unlp.edu.ar/bitstream/handle/10915/19097/Documento_completo.pdf?sequ

ence=1

24. [24] Basili VR. The Experimental Paradigm in Software Engineering [internet].

[consultado 2013 Ago 25]. Disponible en:

http://www.cs.umd.edu/~basili/publications/chapters/C17.pdf

25. [25] Basili VR. The Role of Controlled Experiments in Software Engineering Research

[internet].[cosultado 2013 Ago 25] Disponible en:


26. [26] IBM. Getting requirements right: avoiding the top 10 traps. [internet] [consultado

2013 Ago 25] Disponible en:

http://www.batimes.com/images/pdfs/GettingRequirementsRight.pdf

27. [27] Cheng B, Atlee J. Research directions in requirements engineering. , Perú

[internet]. [consultado 2013 Ago 25]. Disponible en: http://www-

users.cselabs.umn.edu/classes/Fall-2010/seng5801/readings/future-of-RE.pdf

28. [28] Palomino KC. Estudio del comportamiento de la industria del software en

Colombia ante escenarios de capacidades de innovación y ventajas comparativas por

medio de dinámica de sistemas. [Trabajo de grado como requisito parcial para optar al

título de Magíster en ingeniería de sistemas] (Medellín) Universidad Nacional de

Colombia, Facultad de Minas, Escuela de Sistemas; 2011.

29. [29] Neill CJ, Laplante PA. Requirements engineering: the state of teh practice.

[internet]. [consultado 2013 Ago 25]. Disponible en:

http://www.personal.psu.edu/users/c/j/cjn6/Personal/Reprints/Software%20v20n6%200

3.pdf

30. [30] Rumbaugh J, Jacobson I, Booch G. The unifed modeling language reference

manual. Second edition. Canadá: Copyright; 2004

http://www.fi.upm.es/docs/estudios/postgrado-admision/537_Seminario%20ESE.pdf

http://www.fi.upm.es/docs/estudios/postgrado-admision/537_Seminario%20ESE.pdf

http://sedici.unlp.edu.ar/bitstream/handle/10915/19097/Documento_completo.pdf?sequence=1




http://www.batimes.com/images/pdfs/GettingRequirementsRight.pdf

http://www-users.cselabs.umn.edu/classes/Fall-2010/seng5801/readings/future-of-RE.pdf

http://www-users.cselabs.umn.edu/classes/Fall-2010/seng5801/readings/future-of-RE.pdf

http://www.personal.psu.edu/users/c/j/cjn6/Personal/Reprints/Software%20v20n6%2003.pdf

http://www.personal.psu.edu/users/c/j/cjn6/Personal/Reprints/Software%20v20n6%2003.pdf



190

31. [31] Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.

Pressman, R. S. (2006) ”Engenharia de Software”. Makron Books. 6ª Edición cap 7.

32. [32] Davis A, Dieste O, Hickey A, Juristo N, Moreno AM. Effectiveness of

Requeriments Elicitation Techniques: Epirical Results derived from a Systematic

review. [internet] [consultado 2013 Ago 25] Disonible en:

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1704061

33. [33] Marco para la selección de técnicas de educción de requisitos

34. [34] Kujala, S. (2002) “User Studies: A practical Approach to User Involvement for

Gathering User Needs and Requirements”. PhD Thesis. Helsinki University of

Technology, Department of Computer Science and Engineering, Espoo, Finland [1] en

[66].

35. [35] IBM. ALM trends: requirements and the role or business anlysts. [internet]

[consultado 2013 Ago 25] Disponible en:

http://searchsoftwarequality.techtarget.com/ebook/Requirements-management-tools-

and-the-changing-role-of-business-analysts

36. [36] Davis AM. 5-Notes on The Art of Requirements Triage by Alan M. Davis.

[internet] [consultado 2013 Ago 25] Disponible en:

http://www.cs.scranton.edu/~mccloske/courses/se507/davis_req_triage_notes.html

37. [37] Agile Manifesto (2001) Disponible en: http://agilemanifesto.org/iso/es/

38. [38] Dieste O, Juristo N, Shull F. Understing the Customer: What do we know about

requirements elicitation? [internet] [consultado 2013 Ago 25] Disponible en:


39. [39] Tavassoli D. Ten steps to better Requirements Management [internet] [consultado

2013 Ago 25] Disponible en: http://dc318.4shared.com/doc/pW_CfB3P/preview.html

40. [40] Landreani NF. Métodos cuantitativos versus métodos cualitativos: Un falso

dilema* Management [internet]. [consultado 2013 Ago 25]. Disponible en:

http://www.revistacdyt.uner.edu.ar/articulos/descargas/cdt25_landreani.pdf

41. [41] Lázaro M, Mar1234cos E, Vegas S. Experiencias en integración de métodos

cualitativos y cuantitativos. [internet]. [consultado 2013 Ago 25]. Disponible en:

https://mailattachment.googleusercontent.com/attachment/?ui=2&ik=234fd0ea8e&view

=att&th=140b30f118fa55c5&attid=0.11&disp=inline&realattid=f_hkrkch5110&safe=1

&zw&saduie=AG9B_P9iL5pN4d0pCOoxS18YVyxY&sadet=1377483028417&sads=3

W_MwTWJMQlvmCEXMIS1eA6FDX4


http://searchsoftwarequality.techtarget.com/ebook/Requirements-management-tools-and-the-changing-role-of-business-analysts

http://searchsoftwarequality.techtarget.com/ebook/Requirements-management-tools-and-the-changing-role-of-business-analysts

http://www.cs.scranton.edu/~mccloske/courses/se507/davis_req_triage_notes.html

http://agilemanifesto.org/iso/es/


http://dc318.4shared.com/doc/pW_CfB3P/preview.html

http://www.revistacdyt.uner.edu.ar/articulos/descargas/cdt25_landreani.pdf

https://mailattachment.googleusercontent.com/attachment/?ui=2&ik=234fd0ea8e&view=att&th=140b30f118fa55c5&attid=0.11&disp=inline&realattid=f_hkrkch5110&safe=1&zw&saduie=AG9B_P9iL5pN4d0pCOoxS18YVyxY&sadet=1377483028417&sads=3W_MwTWJMQlvmCEXMIS1eA6FDX4






191

42. [42] Ian Sommerville y Sawyer Pete, Ingeniería de Requisitos: Una Guía de Buenas

Prácticas (Wiley, 1997).

43. [43] Potts, C “The Other Interface: Specifying and visualizing computer systems”, in G.

Van der Veer, T. Green, J.-M. Hoc and D. Murray (eds.) Working with

Computers:Theory versus outcome, Academic Press, 1988.

44. [44] Manies M, Nikual U. La elicitación de requisitos en el contexto de un proyecto

Software. Ing.USBMed [internet]. 2011; 2: 25-29 [consultado 2013 Ago 25].

Disponible en: http://web.usbmed.edu.co/usbmed/fing/v2n2/v2n2a4.pdf

45. [45] http://www.inviertaencolombia.com.co/informacion-regional/medellin.html

proexport Colombia

46. [46] Pressman, R. Ingeniería del Software. Un enfoque práctico, McGraw-Hill

Interamericana, Madrid, España, 2002, p. 48.

47. [47] Richardson, R. J. (1999) “Pesquisa Social: Métodos e Técnicas”. ISBN 85-224-

2111-0. Sao Paulo: Atlas.

48. [48] Flick, U. (2004) “An Introduction to Qualitative Research”. Second Edition,

Bookman Editora.

49. [49] Richardson, I. and Wangenheim, C. (2007) “Why Are Small software

Organizations Different?” IEEE Software, January/February.

50. [50] Pino FJ, García F, Piattini M, Oktaba H. Revisión sistemática de mejora se

procesos Software en pequeñas y medianas empresas de software. COMPETISOFT

[internet]. 2006; 0.2 [consultado 2013 Ago 25]. Disponible en: http://alarcos.inf-

cr.uclm.es/competisoft/publico/downloads/Inf_T%C3%A9cnicos/COMPETISOFT_IT_

1.pdf

51. [51] Botero NE. Faltan ingenieros y programadores bilingües. [internet]. [consultado


http://www.elcolombiano.com/BancoConocimiento/F/faltan_ingenieros_y_programado

res_biling%C3%BCes/faltan_ingenieros_y_programadores_biling%C3%BCes.asp

52. [52] Pereira Davila R. 10 formas de motivar a sus empleados. [internet]. [consultado

2013 Ago 25]. Disponible en: http://www.microsoft.com/business/es-

es/Content/Paginas/article.aspx?cbcid=266

53. [53] INTECO – Instituto Nacional de Tecnologías de la Comunicación. Guía avanzada

de gestión de requisitos. [internet]. [consultado 2013 Ago 25]. Disponible en:

http://www.pymesonline.com/uploads/tx_icticontent/R02638_gestioncontratos.pdf.

http://web.usbmed.edu.co/usbmed/fing/v2n2/v2n2a4.pdf

http://www.inviertaencolombia.com.co/informacion-regional/medellin.html

http://alarcos.inf-cr.uclm.es/competisoft/publico/downloads/Inf_T%C3%A9cnicos/COMPETISOFT_IT_1.pdf



http://www.elcolombiano.com/BancoConocimiento/F/faltan_ingenieros_y_programadores_biling%C3%BCes/faltan_ingenieros_y_programadores_biling%C3%BCes.asp

http://www.elcolombiano.com/BancoConocimiento/F/faltan_ingenieros_y_programadores_biling%C3%BCes/faltan_ingenieros_y_programadores_biling%C3%BCes.asp

http://www.microsoft.com/business/es-es/Content/Paginas/article.aspx?cbcid=266

http://www.microsoft.com/business/es-es/Content/Paginas/article.aspx?cbcid=266

http://www.pymesonline.com/uploads/tx_icticontent/R02638_gestioncontratos.pdf



192

54. [54] Callaos, N. y Callaos, B., “Designing with Systemic Total Quality”, in

International Conference on Information Systems, N. Callaos and B. Sánchez (eds.),

International Institute of Informatics and Systemics, Orlando, 1996, pp. 548-560.

55. Nada

56. [56] Standish Group International (2011) – www.standishgroup.com. Last Access

Engineering”. 3rd Conference for the Promotion of Research in IT at New Universities

and University Colleges in Sweden.

57. [57] Cohn M. agile succeeds three times more often than waterfall. [internet].

[consultado 2013 Ago 25]. Disponible en:

http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-

than-waterfall

58. [58] Definición Tamaño Empresarial Micro, Pequeña, Mediana o Grande

http://www.mipymes.gov.co/publicaciones.php?id=2761&dPrint=1

59. [59] Guide to the software engineerind body of knowledge. Swebok. IEEE (version

2004)

http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-i/otros-recursos-

1/SWEBOK_Guide_2004.pdf

60. [60] An Introductory Overview of ITIL V3. ITSMF [internet] 2007 [consultado 2013

Ago 25]. Disponible en: http://www.best-management-

practice.com/gempdf/itsmf_an_introductory_overview_of_itil_v3.pdf.

61. [61] ISO 2001. Guía sobre los requisitos de la documentación ISO 9000:2000.

[internet]. [consultado 2013 Ago 25]. Disponible en:

http://www.iie.org.mx/bolISO02/tecni2.pdf

62. [62] Martínez Carod N. Priorización de requerimientos de software utilizando una

estrategia cognitiva. [internet]. [consultado 2013 Ago 25]. Disponible en:

http://sedici.unlp.edu.ar/bitstream/handle/10915/20793/Documento_completo.pdf?sequ

ence=1

63. [63] Leffingwell D, Widrig D. Managing Software Requeriments: A Use Case

Approach, Second edition. Boston, USA; Addison – Wesley Professional, 2003

64. [64] Cysneiros LM, Benjamin Wemeck VM. An initial analysis on how software

transparency and trust influence each other. [internet]. [consultado 2013 Ago 25].

Disponible en: http://www.inf.puc-

rio.br/~wer/WERpapers/artigos/artigos_WER09/cysneiros.pdf

http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall

http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall

http://www.mipymes.gov.co/publicaciones.php?id=2761&dPrint=1

http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-i/otros-recursos-1/SWEBOK_Guide_2004.pdf

http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-i/otros-recursos-1/SWEBOK_Guide_2004.pdf

http://www.best-management-practice.com/gempdf/itsmf_an_introductory_overview_of_itil_v3.pdf

http://www.best-management-practice.com/gempdf/itsmf_an_introductory_overview_of_itil_v3.pdf

http://www.iie.org.mx/bolISO02/tecni2.pdf



http://www.inf.puc-rio.br/~wer/WERpapers/artigos/artigos_WER09/cysneiros.pdf

http://www.inf.puc-rio.br/~wer/WERpapers/artigos/artigos_WER09/cysneiros.pdf



193

65. [65] IEEE (1998). “IEEE Recommended practice for software requirementents

secifications”. [internet]. [consultado 2013 Ago 25]. Disponible en:

http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf.

66. [66] Alves, C., Pereira S., Valença, G., Pimentel, J. and Andrade, R. V. C. L. (2007)

“Preliminary Results from an Empirical Study in Market-Driven Software Companies”.

10th Workshop of Requirements Engineering.

Documents

core.ac.uk · Estudio empírico sobre el proceso y la productividad de la ingeniería de requisitos en las empresas antioqueñas de software 2 UNIVERSIDAD EAFIT ESCUELA DE