facultad de ciencias administrativas...quiero agradecer a mis padres: eva maría armijos y jorge...
TRANSCRIPT
ESCUELA POLITÉCNICA NACIONAL
FACULTAD DE CIENCIAS ADMINISTRATIVAS
UNIDAD DE TITULACIÓN
ESTUDIO COMPARATIVO ENTRE EL MODELO OFFSHORE Y EL
MODELO INHOUSE EN EL DESARROLLO DE SOFTWARE PARA
LAS EMPRESAS ECUATORIANAS. CASOS DE ESTUDIO TATA
CONSULTANCY SERVICES Y MINISTERIO DE SALUD PÚBLICA
DEL ECUADOR.
TRABAJO DE TITULACIÓN PREVIO A LA OBTENCIÓN DEL GRADO DE
MAGISTER EN GERENCIA EMPRESARIAL
VIZCARRA LARA MARÍA FERNANDA
RUALES ARMIJOS DANNY PATRICIO
Director: Ing. Fernando Herrera PhD
2018
APROBACIÓN DEL DIRECTOR
Como director del trabajo de titulación ESTUDIO COMPARATIVO ENTRE EL
MODELO OFFSHORE Y EL MODELO INHOUSE EN EL DESARROLLO DE
SOFTWARE PARA LAS EMPRESAS ECUATORIANAS CASOS DE ESTUDIO
TATA CONSULTANCY SERVICES Y MINISTERIO DE SALUD PÚBLICA DEL
ECUADOR, desarrollado por María Fernanda Vizcarra Lara y Danny Patricio
Ruales Armijos, estudiantes de la Maestría en Gerencial Empresarial habiendo
supervisado la realización de este trabajo y realizado las correcciones
correspondientes, doy por aprobada la redacción final del documento escrito para
que prosiga con los trámites correspondientes a la sustentación de la Defensa
oral.
Ing. Fernando Herrera PhD
DIRECTOR
DECLARACIÓN DE AUTORÍA
Yo, María Fernanda Vizcarra Lara, declaro bajo juramento que el trabajo aquí
descrito es de mi autoría; que no ha sido previamente presentada para ningún
grado o calificación profesional; y, que he consultado las referencias bibliográficas
que se incluyen en este documento.
La Escuela Politécnica Nacional puede hacer uso de los derechos
correspondientes a este trabajo, según lo establecido por la Ley de Propiedad
Intelectual, por su Reglamento y por la normatividad institucional vigente.
María Fernanda Vizcarra Lara
DECLARACIÓN DE AUTORÍA
Yo, Danny Patricio Ruales Armijos, declaro bajo juramento que el trabajo aquí
descrito es de mi autoría; que no ha sido previamente presentada para ningún
grado o calificación profesional; y, que he consultado las referencias bibliográficas
que se incluyen en este documento.
La Escuela Politécnica Nacional puede hacer uso de los derechos
correspondientes a este trabajo, según lo establecido por la Ley de Propiedad
Intelectual, por su Reglamento y por la normatividad institucional vigente.
Danny Patricio Ruales Armijos
DEDICATORIA
Queremos dedicar este trabajo de titulación a nuestros queridos hijos Martín
Alejandro y Esteban Andrés, por ser el motor que empuja nuestras vidas
diariamente. Gracias por el tiempo y la paciencia mientras cursábamos los dos
años de capacitación obligatoria en los cuales tuvimos grandes sacrificios, todo
este esfuerzo los dedicamos a ustedes queridos hijos, esperamos que les sirva de
ejemplo en su vida diaria.
María Fernanda y Danny
AGRADECIMIENTO
Quiero agradecer a mis padres: Eva María Armijos y Jorge Ruales por haber
hecho de mí un hombre de bien, por brindarme todo su apoyo para poder
culminar este proceso de capacitación, gracias por ser un ejemplo a seguir para
mí y para sus nietos, tengo una deuda pendiente con ustedes el resto de mi vida.
A nuestro director Ing. Fernando Herrera y co-director Ing. Antonio Franco por el
apoyo incondicional recibido durante todo el tiempo de ejecución de la tesis, por
saber transmitirnos sus conocimientos y orientar el trabajo hacia una conclusión
exitosa.
Danny
A Dios y la Virgen Santísima por todas las bendiciones que han puesto en mi vida,
a mis padres por mostrarme cada día que la vida es cuestión de actitud viendo la
forma que han afrontado sus adversidades de salud, a mi esposo por todo el
apoyo en el desarrollo del presente trabajo y a mis suegros porque siempre han
estado presentes y dispuestos a ayudarme con mis hijos cuando he necesitado.
A todas las personas que entregaron su tiempo para expresar sus opiniones y
experiencias profesionales siendo una parte muy importante en el desarrollo del
presente trabajo.
A nuestro director Ing. Fernando Herrera y co-director Ing. Antonio Franco por
brindarnos su apoyo y guiarnos durante todo el proceso del desarrollo de la
presente tesis.
María Fernanda
ÍNDICE DE CONTENIDO
LISTA DE FIGURAS............................................................................................................ I
LISTA DE TABLAS ........................................................................................................... III
LISTA DE ANEXOS .......................................................................................................... IV
RESUMEN .......................................................................................................................... V
ABSTRACT ........................................................................................................................ VI
1. INTRODUCCIÓN ......................................................................................................... 1
1.1. PLANTEAMIENTO DEL PROBLEMA Y PREGUNTA DE INVESTIGACIÓN .... 1
1.2. OBJETIVO GENERAL ............................................................................................... 3
1.3. OBJETIVOS ESPECÍFICOS ....................................................................................... 3
1.4. JUSTIFICACIÓN ........................................................................................................ 3
1.5. DESCRIPCIÓN DE LAS ORGANIZACIONES ESTUDIADAS .............................. 3
1.5.1. TATA CONSULTANCY SERVICES (TCS) .................................................................. 4
1.5.2. MINISTERIO DE SALUD PÚBLICA (MSP) ............................................................ 8
1.6. MARCO TEÓRICO ................................................................................................... 11
1.6.1. INDUSTRIA DEL DESARROLLO DE SOFTWARE .............................................. 12
1.6.2. EL SOFTWARE Y LA INGENIERÍA DE SOFTWARE ............................................ 14
1.6.2.1. SOFTWARE: DEFINICIÓN E IMPORTANCIA.................................................. 14
1.6.2.2. INGENIERÍA DE SOFTWARE ............................................................................ 15
1.6.2.3. PROCESO DEL SOFTWARE .............................................................................. 16
1.6.2.4. MODELOS DE PROCESOS DE SOFTWARE..................................................... 17
1.6.2.5. TIPOS DE DESARROLLO DE SOFTWARE ....................................................... 19
1.6.3. SISTEMAS DE INFORMACIÓN Y ORGANIZACIÓN ......................................... 20
1.6.3.1. LAS TIC DINAMIZADORAS DE LAS FORMAS ORGANIZATIVAS ........... 20
1.6.3.2. INSOURCING DE TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIÓN . 21
1.6.3.3.OUTSOURCING DE TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIÓN 21
1.6.3.4. RAZONES PARA EXTERNALIZAR UN SERVICIO ....................................... 22
1.6.3.5. ¿QUÉ SERVICIOS SE PUEDEN EXTERNALIZAR? ........................................ 24
1.6.3.6. MODELOS DE EXTERNALIZACIÓN ............................................................... 25
1.6.3.6.1. OFFSHORE ..................................................................................................... 26
1.6.3.6.2. NEARSHORE................................................................................................... 27
1.6.3.6.3. ONSHORE ....................................................................................................... 27
1.6.3.6.4. ONSITE ............................................................................................................ 27
1.6.3.6.5. GLOBAL DELIVERY ....................................................................................... 27
2. METODOLOGÍA ........................................................................................................ 28
2.1. DEFINICIÓN DEL TIPO DE INVESTIGACIÓN .................................................... 28
2.1.1. ENFOQUE CUALITATIVO ..................................................................................... 28
2.1.2. ENFOQUE CUANTITATIVO .................................................................................. 29
2.2. RECOLECCIÓN DE INFORMACIÓN .................................................................... 30
2.2.1. TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN.......................................... 30
2.2.2. DEFINICIÓN DEL NÚMERO DE ENTREVISTAS Y ENCUESTAS A ....................
REALIZAR EN EL PROCESO DE INVESTIGACIÓN .......................................... 31
2.2.3. DEFINICIÓN DEL NÚMERO DE PROYECTOS A EXAMINAR ......................... 33
3. RESULTADOS Y DISCUSIÓN ............................................................................... 35
3.1. ANÁLISIS CUANTITATIVO DE LOS RESULTADOS OBTENIDOS ................. 35
3.1.1. RESULTADOS DE LAS ENCUESTAS SOBRE EL MODELO OFFSHORE ....... 35
3.1.2. RESULTADOS DE LAS ENCUESTAS SOBRE EL MODELO INHOUSE ........... 51
3.1.3. ANÁLISIS DE RESULTADOS POR PROYECTOS EJECUTADOS ..................... 66
3.2. ANÁLISIS CUALITATIVO DE LOS RESULTADOS OBTENIDOS .................... 71
3.2.1. PERSPECTIVA FINANCIERA ................................................................................ 71
3.2.2. PERSPECTIVA DE LA ESTRATEGIA ORGANIZACIONAL .............................. 72
3.2.3. PERSPECTIVA DEL CLIENTE ............................................................................... 73
3.2.4. PERSPECTIVA DEL APRENDIZAJE ..................................................................... 74
3.2.5. ANÁLISIS COMPARATIVO POR PERSPECTIVA DE LAS ...................................
ORGANIZACIONES ESTUDIADAS ...................................................................... 76
3.2.5.1. PERSPECTIVA FINANCIERA ........................................................................... 76
3.2.5.2. PERSPECTIVA DE LA ESTRATEGIA ORGANIZACIONAL ......................... 77
3.2.5.3. PERSPECTIVA DEL CLIENTE .......................................................................... 78
3.2.5.4. PERSPECTIVA DEL APRENDIZAJE ................................................................ 79
3.3. MODELO DE EVALUACIÓN DE PROYECTOS .................................................. 80
4. CONCLUSIONES Y RECOMENDACIONES ....................................................... 87
4.1. CONCLUSIONES ..................................................................................................... 87
4.2. RECOMENDACIONES ............................................................................................ 90
REFERENCIAS BIBLIOGRÁFICAS ............................................................................. 92
GLOSARIO ........................................................................................................................ 94
ANEXOS ............................................................................................................................ 95
i
LISTA DE FIGURAS
Figura 1 - Organigrama institucional de TCS Ecuador ............................................................. 5
Figura 2 - Estructura interna para la gestión de proyectos en TCS Ecuador ......................... 6
Figura 3 - Organigrama del MSP por viceministerios y subsecretarías .................................. 9
Figura 4 - Organigrama del MSP por coordinaciones y direcciones........................................ 9
Figura 5 - Estructura interna para la gestión de proyectos en el MSP .................................. 10
Figura 6 - Pasos para el análisis de una decisión de outsourcing. ........................................ 25
Figura 7 - Formas de outsourcing basadas en las distancia. ................................................. 26
Figura 8 - Distribución porcentual: Pregunta 1 de la encuesta sobre modelo offShore ....... 36
Figura 9 - Distribución porcentual: Pregunta 2 de la encuesta sobre modelo offShore ....... 37
Figura 10 - Distribución porcentual: Pregunta 3 de la encuesta sobre modelo offShore..... 39
Figura 11 - Distribución porcentual: Pregunta 4 de la encuesta sobre modelo offShore..... 40
Figura 12 - Distribución porcentual: Pregunta 5 de la encuesta sobre modelo offShore..... 41
Figura 13 - Distribución porcentual: Pregunta 6 de la encuesta sobre modelo offShore..... 42
Figura 14 - Distribución porcentual: Pregunta 7 de la encuesta sobre modelo offShore..... 43
Figura 15 - Distribución porcentual: Pregunta 8 de la encuesta sobre modelo offShore..... 44
Figura 16 - Distribución porcentual: Pregunta 9 de la encuesta sobre modelo offShore..... 45
Figura 17 - Distribución porcentual: Pregunta 10 de la encuesta sobre modelo offShore .. 46
Figura 18 - Distribución porcentual: Pregunta 10-1 de la encuesta sobre modelo offShore ....... 47
Figura 19 - Distribución porcentual: Pregunta 11 de la encuesta sobre modelo offShore .. 48
Figura 20 - Distribución porcentual: Pregunta 12 de la encuesta sobre modelo offShore .. 49
Figura 21 - Distribución porcentual: Pregunta 13 de la encuesta sobre modelo offShore .. 50
Figura 22 - Distribución porcentual: Pregunta 14 de la encuesta sobre modelo offShore .. 51
Figura 23 - Distribución porcentual: Pregunta 1 de la encuesta sobre modelo inHouse ..... 52
Figura 24 - Distribución porcentual: Pregunta 2 de la encuesta sobre modelo inHouse ..... 53
Figura 25 - Distribución porcentual: Pregunta 3 de la encuesta sobre modelo inHouse ..... 54
Figura 26 - Distribución porcentual: Pregunta 4 de la encuesta sobre modelo inHouse ..... 55
Figura 27 - Distribución porcentual: Pregunta 5 de la encuesta sobre modelo inHouse ..... 57
Figura 28 - Distribución porcentual: Pregunta 6 de la encuesta sobre modelo inHouse ..... 58
Figura 29 - Distribución porcentual: Pregunta 7 de la encuesta sobre modelo inHouse ..... 59
ii
Figura 30 - Distribución porcentual: Pregunta 8 de la encuesta sobre modelo inHouse ..... 60
Figura 31 - Distribución porcentual: Pregunta 9 de la encuesta sobre modelo inHouse ..... 61
Figura 32 - Distribución porcentual: Pregunta 10 de la encuesta sobre modelo inHouse ... 63
Figura 33 - Distribución porcentual: Pregunta 11 de la encuesta sobre modelo inHouse ... 64
Figura 34 - Distribución porcentual: Pregunta 12 de la encuesta sobre modelo inHouse ... 64
Figura 35 - Distribución porcentual: Pregunta 13 de la encuesta sobre modelo inHouse ... 65
Figura 36 - Distribución porcentual: Pregunta 14 de la encuesta sobre modelo inHouse ... 66
Figura 37 - Pantalla principal del modelo ................................................................................. 80
Figura 38 - Ingreso de los valores a evaluar en el modelo ..................................................... 81
Figura 39 - Resultado de la evaluación en el modelo. ............................................................ 82
Figura 40 - Ingreso a la consulta de parámetros. .................................................................... 82
Figura 41 - Consulta de parámetros de la variable esfuerzo. ................................................. 83
Figura 42 - Consulta de parámetros de la variable número de desarrolladores................... 83
Figura 43 - Consulta de parámetros de la variable presupuesto. .......................................... 84
Figura 44 - Consulta de parámetros de la variable duración. ................................................. 84
Figura 45 - Consulta de parámetros de la variable tipo de proyecto. .................................... 85
Figura 46 - Consulta de parámetros de la variable tipo de tecnología. ................................. 85
Figura 47 - Modificación de parámetros para la variable esfuerzo. ....................................... 86
Figura 48 - Actualización de parámetros para la variable esfuerzo. ...................................... 86
iii
LISTA DE TABLAS
Tabla 1 - Descripción de conocimientos por perfil en TCS Ecuador ......................... 7
Tabla 2 - Descripción de conocimientos por perfil en el MSP .................................. 11
Tabla 3 - Número total de personas por perfil en las instituciones estudiadas. ..... 31
Tabla 4 - Cantidad de entrevistas a realizar por institución y rol. ............................. 32
Tabla 5 - Distribución de entrevistas por institución y rol. ......................................... 32
Tabla 6 - Cantidad de encuestas a realizar por institución y rol. .............................. 33
Tabla 7 - Clasificación del tamaño de los proyectos por su duración...................... 33
Tabla 8 - Clasificación del tamaño de los proyectos por su presupuesto. .............. 33
Tabla 9 - Cantidad de proyectos a analizar por tamaño e institución. ..................... 34
Tabla 10 - Descripción de proyectos ejecutados en TCS Ecuador. ........................ 67
Tabla 11 - Descripción de proyectos ejecutados en el MSP ..................................... 68
iv
LISTA DE ANEXOS
Anexo I - Formato de entrevista sobre el modelo offShore....................................... 96
Anexo II - Formato de entrevista sobre el modelo inHouse ...................................... 98
Anexo III - Formato de encuesta sobre el modelo offShore ................................... 100
Anexo IV - Formato de encuesta sobre el modelo inHouse. .................................. 103
Anexo V - Tabulaciones de la encuesta sobre el modelo offShore. ...................... 106
Anexo VI - Tabulaciones de la encuesta sobre el modelo inHouse. ..................... 107
v
RESUMEN
La presente tesis de maestría compara los modelos de desarrollo de software
offShore e inHouse usados en el desarrollo de proyectos por las empresas Tata
Consultancy Services y Ministerio de Salud Pública del Ecuador (MSP). Dos
modelos diferentes aplicados a una misma realidad nacional, entorno
macroeconómico y fuerza laboral. El modelo offShore usado por una multinacional
domiciliada en Ecuador y el modelo InHouse usado por una institución pública
normada bajo estatutos, políticas y procedimientos del estado ecuatoriano, lo cual
evidentemente genera variabilidad en los resultados que podrían obtenerse en los
proyectos administrados por una u otra institución. La consideración de estudiar a
dos instituciones con funciones comunes, pero de características, estructura y
procesos diferentes generan un conjunto de puntos interesantes a ser
consideradas en el presente estudio.
La investigación realizada es de tipo cualitativo y cuantitativo. Para su desarrollo
se usaron encuestas, entrevistas y estadísticas de los proyectos ejecutados como
herramientas de recolección de información. Las entrevistas realizadas enfocaron
sus preguntas en cuatro perspectivas: financiera, de la estrategia organizacional,
del cliente, y del aprendizaje. Tanto las entrevistas como las encuestas fueron
realizadas a empleados de las empresas estudiadas de acuerdo con su perfil.
Posteriormente a la aplicación de las entrevistas y encuestas se analizaron
también los resultados de tres proyectos ejecutados en cada organización
buscando identificar las variables que intervienen directa e indirectamente dentro
de la ejecución de proyectos de software. Una vez identificadas las variables que
influyen en los modelos de desarrollo se construyó un software que ayuda a los
gestores de proyectos a tomar una decisión acertada del modelo de desarrollo a
aplicarse en un proyecto.
Palabras clave: Externalización de Servicios. Outsourcing. OffShore. InHouse
vi
ABSTRACT
This master's thesis compares the offShore and Onsite software development
models used in the projects developed by Tata Consultancy Services and the
Ministry of Public Health, Ecuador (MSP). These two software development
models are applicable for current location, macroeconomic environment and
others. The offShore model used by a multinational organization established in
Ecuador and the onsite model used by a public institution regulated by structures,
policies and procedures of the Ecuadorian state law, which evidently generates
variability in the results that could be followed in projects managed by one or more
institutions. In this process of studying two institutions with common functions, but
with different characteristics, structure and processes generate a set of interesting
points to be considered in this study.
The research carried out is qualitative and quantitative. For its development,
surveys, interviews and statistics for projects execution were used as information
gathering tools. The interviews conducted were focused on four perspectives:
financial, organizational strategy, client, and learning. Both the interviews and
surveys were conducted to employees of the organization according to their
profile. In next step, a percentage analysis was made from the results for each
one. Subsequently, the results of three projects executed in each organization
were analyzed and to identify the inputs that intervene directly and indirectly within
the execution of software projects. Once the inputs that influence the development
models were identified, software was created that helps the project managers to
come to an accurate decision of the development model to apply in a particular
project.
Key words: Outsourcing, OffShore, InHouse
1
1. INTRODUCCIÓN
En esta sección se sustenta porque es importante y necesario efectuar este trabajo de
investigación, fundamentándolo primero desde un entorno global con conceptos
alineados desde una perspectiva total y luego orientándolo a una problemática específica
existente en dos organizaciones que se encuentran en Ecuador desarrollando sus
actividades en un entorno y cultura organizacional particulares. Describimos las
organizaciones objeto de nuestro estudio y sustentamos nuestro análisis en el marco
teórico que permite dar a conocer los conceptos básicos necesarios en el desarrollo de la
presente investigación. Explicamos como la ingeniería ha aportado en el desarrollo del
software a nivel mundial, luego nos enfocamos en las estadísticas internas reportadas
para América Latina y Ecuador a nivel del número de empresas y total de ventas para las
empresas relacionadas con la actividad de programación informática. Posteriormente se
describen los conceptos relacionados con el desarrollo de software: procesos,
metodologías, y herramientas que permiten elaborar productos de software para
finalmente detallar los conceptos relacionados con la externalización de servicios
informativos y sus diferentes tipos.
1.1. Planteamiento del problema y pregunta de investigación
Ecuador ha mostrado una mayor destreza en desarrollo de software para áreas de
servicios bancarios, financieros, gestión y control empresarial. Estos sectores, por
naturaleza generadores de empleo, enfocan sus esfuerzos en la construcción de
soluciones de software financieras y bancarias, inteligencia empresarial, automatización
de procesos (Bussines Process Managment – BPM), E-Learning1, consultoría,
outsourcing especializado, entre otros (Oficina Comercial de ProChile en Ecuador, 2012).
Gran parte de las empresas que conforman dichos sectores son empresas con fines de
lucro. Es decir, estas enfocan sus esfuerzos en obtener ganancias explotando al máximo
la actividad económica a la que pertenecen; dejando así la administración de sus TICs y
el desarrollo de software a un tercero (Maldonado, Proaño, & Ekos, 2015).
1 Sistema de formación cuya característica principal es que se realiza a través de internet o conectados a la
red.
2
Sin embargo, existen otras organizaciones sin fines de lucro que cuentan con un
departamento propio de TICs y tienen como funciones el desarrollo de software visto
desde el punto de vista interno como una necesidad de distintos departamentos que
conforman la organización. En estas organizaciones el objetivo no es construir un
producto de software para venderlo sino construir un producto para satisfacer una
demanda interna.
En ambos casos, ya sea desarrollo de software con un tercero o casa adentro, se marca
el uso de una metodología específica que saca a relucir lo mejor de cada organización.
Cuando hablamos de una multinacional deducimos una alta capacidad de cobertura y un
alto margen de respuesta. En cambio, si hablamos de microempresas hablamos de
ciertas limitantes relacionadas con el presupuesto; y estas variables pueden de alguna
manera determinar el éxito o fracaso de los proyectos de desarrollo de software.
La ejecución de proyectos de desarrollo de software trae consigo la decisión de evaluar el
modelo con el cual se ejecutará la construcción del producto. Para ello existen distintas
opciones documentadas por las cuales las organizaciones pueden optar como el modelo
inHouse u offShore. Ambos pueden ser utilizados desde el punto de vista en que las
organizaciones tienen su propio departamento de TICs o en el caso que hayan
contratado los servicios por medio de terceros.
Cada uno de los modelos antes mencionado cuenta con fortalezas y debilidades desde el
punto de vista técnico y administrativo. Sin embargo, en la presente tesis se pretende
evaluar también factores no técnicos (conocimiento del negocio, idioma, barrera horaria,
presencia física, procesos) que influyen en el éxito o fracaso de los modelos de acuerdo
con una cultura organizacional específica.
La comparación cuantitativa y cualitativa de los dos modelos (inHouse y offShore)
permitirá identificar y entender las variables que influyen de manera positiva o negativa
en cada uno de ellos, y ayudará a plantear un esquema que oriente a las organizaciones
sobre qué modelo adoptar en un proyecto de desarrollo de software con el fin de poder
obtener los mejores resultados posibles. Por lo tanto, cabe preguntarse: ¿Cuáles son las
ventajas y desventajas de aplicar los modelos inHouse y offShore en el desarrollo de
software de las empresas ecuatorianas?
3
1.2. Objetivo general
Comparar los modelos de desarrollo de software inHouse y offShore con el fin de
identificar las variables que determinan el éxito o fracaso de un modelo u otro. Casos de
estudio TCS Ecuador y el Ministerio de Salud Pública del Ecuador.
1.3. Objetivos específicos
Comparar los dos modelos de desarrollo de software desde las perspectivas:
financiera, estrategia organizacional, cliente, y aprendizaje.
Determinar las variables técnicas y no técnicas que influyen en los modelos de
desarrollos estudiados.
Construir un modelo que permita evaluar si un proyecto de desarrollo de
software debe construirse mediante el modelo offShore o inHouse.
Evaluar y concluir sobre los resultados de la comparación de los modelos.
1.4. Justificación
En el Ecuador casi el 50% del total de las empresas relacionadas con las Tecnologías de
la Información y Comunicación se dedican a actividades de programación y que la
industria de software genera ventas por el orden de USD 500 millones, con un
crecimiento anual de 17% en los 7 años previos, lo que demuestra el auge de esta
industria y el incremento en la participación del mercado de las empresas ecuatorianas,
pretendemos analizar las variables que influyen en los resultados finales de los proyectos
de desarrollo para determinar el éxito o no de los mismos contando con modelos de
ejecución de proyectos que permitan a las empresas obtener el mayor beneficio posible
maximizando sus ingresos, reduciendo costos y sobre todo evitando pérdidas
ocasionadas por la ejecución errada de un proyecto.
1.5. Descripción de las organizaciones estudiadas
La siguiente sección tiene por objetivo presentar en un vistazo rápido y conciso las dos
organizaciones objeto de este estudio. Con esto pretendemos dar a conocer la naturaleza
y los objetivos de cada una de ellas.
4
1.5.1. Tata Consultancy Services (TCS)
En la actualidad TCS Ecuador es la mayor empresa del país en externalización de
procesos de negocio a través de la sistematización y mejoramiento de procesos
operativos y de negocio basados en plataformas tecnológicas y administración global de
servicios. Ofrece además servicios de infraestructura tecnológica y consultoría de
negocios. Su centro de servicios de externalización de procesos de negocio o Business
Process Outsourcing (BPO), por sus siglas en inglés, cuenta con unidades de negocio de
Help Desk y Call Center, entre las más grandes de América. TCS Ecuador es parte
fundamental de TCS Latinoamérica que opera a lo largo de toda la región con sus centros
de entrega global en Argentina, Brasil, Chile, Colombia, Ecuador, Perú y Uruguay (Tata
Consultancy Service, 2010 - 2018).
TCS Ecuador fue creada en nuestro país con el nombre de Tata Solution Center
encontrándose domiciliada en el país desde el año 2006. Su presencia correspondió al
cumplimiento del compromiso contractual de externalización de procesos de negocio
adquirido con el Banco Pichincha (Super Intendencia de Compañias, 2017).
A partir de entonces se ha convertido en la opción de varias organizaciones locales y
extranjeras tales como: Banco Pichincha (2006 – Actualidad), Banco General Rumiñahui
(2007 - Actualidad), Banco del Instituto de Seguridad Social (2012-2014), Movistar -
Telefónica (2013-2015), Servicio de Rentas Internas (2016-2017) y Banco Financiero del
Perú (2015-2016).
Actualmente, cuenta con una estructura organizacional definida, la misma que hace
posible atender a sus diferentes clientes de acuerdo con sus necesidades. Ver Figura 1.
5
Figura 1 - Organigrama institucional de TCS Ecuador (Tata Consultancy Services Ecuador)
La Gerencia de Tecnología cuenta con cuatro sub gerencias, siendo la de Proyectos la
encargada de llevar a cabo el desarrollo de los proyectos de software en la organización.
La estructura interna definida en cada uno de los proyectos se muestra en la Figura 2.
GER
ENC
IAG
ENER
AL
GERENCIA DE TECNOLOGÍA
Sub-Gerencia de Diseño
Sub-Gerencia de Contact Center
Sub-Gerencia de Proyectos
Sub-Gerencia de Servicios Operativos
GERENCIA DE RRHH
Learning
Seguridad y SaludGERENCIA
ADMINISTRATIVA Y FINANCIERA
6
Figura 2 - Estructura interna para la gestión de proyectos en TCS Ecuador (Tata Consultancy Services Ecuador)
TCS Ecuador, basa el desarrollo de proyectos de software en la metodología y principios
del Project Management Institute (PMI) guiado por (PMBOK® Guide) que es una guía en
la que se desglosa todo el método de gestión de proyectos.
El equipo del proyecto está conformado por aquellas personas a las que se les han
asignado roles y responsabilidades para completar el proyecto. El tipo y la cantidad de
miembros del equipo del proyecto pueden variar con frecuencia a medida que el proyecto
avanza. Los miembros del equipo del proyecto también pueden denominarse personal del
proyecto. En la Tabla 1 se detalla el perfil y experiencia con que cuentan los integrantes
de los equipos de desarrollo de proyectos en TCS Ecuador. Esta información será
relevante al momento de seleccionar las personas a entrevistar y/o encuestar en el
proceso de la investigación.
Del
iver
yM
an
ag
er
Desarrollador Senior
Project Manager
Desarrollador Junior
Experto de Diseño
Ingeniero de QA
Ingeniero de Seguridad
Release Manager
7
Tabla 1 - Descripción de conocimientos por perfil en TCS Ecuador
PERFIL DESCRIPCIÓN
Delivery
Manager
De 10 a 15 años de experiencia en gerenciamiento de proyectos.
Certificación Project Management Professional (PMP).
Conocimiento de metodologías de gerenciamiento de proyectos.
Conocimiento básico de plataformas de desarrollo.
Project Manager
De 5 a 10 años de experiencia gerenciamiento de proyectos.
Certificación Project Management Professional (PMP).
Conocimiento de metodologías de gerenciamiento de proyectos.
Conocimiento básico de plataformas de desarrollo.
Desarrollador
Senior
De 5 a 10 años de experiencia en diseño de aplicaciones Java y Punto
Net
Conocimiento avanzado de bases de datos: Sql, Oracle, MySQL.
Dominio de plataformas de desarrollo: Java, IBM WebSphere y Punto
Net.
Desarrollador
Junior
De 1 a 3 años de experiencia en construcción de aplicaciones Java,
Punto Net.
Conocimiento intermedio de bases de datos: Sql, Oracle, MySQL.
Conocimiento intermedio de plataformas de desarrollo: Java, IBM
WebSphere y Punto Net.
Experto de
Diseño
De 5 a 10 años de experiencia en diseño de aplicaciones Java, Punto
Net.
Conocimiento del esquema funcional bancario.
Conocimiento del levantamiento de requerimientos funcionales.
Conocimiento avanzado de bases de datos: Sql, Oracle, MySQL.
Dominio de plataformas de desarrollo: Java, Punto Net, IBM WebSphere
Ingeniero de QA
De 1 a 2 años de experiencia en diseño de aplicaciones Java y Punto Net
Conocimiento básico de plataformas de desarrollo: Java y Punto Net
Conocimiento del esquema de pruebas y certificación: UAT, BUAT y
regresiones.
Conocimiento de pruebas de carga y estrés.
Ingeniero de
Seguridad
De 5 a 10 años de experiencia en diseño de aplicaciones Java, Punto Net
Conocimiento avanzado de bases de datos: Sql, Oracle, MySQL.
Dominio de plataformas de desarrollo: Java, IBM WebSphere y Punto Net
Conocimiento avanzado en esquemas de seguridad de aplicaciones.
Release
Manager
Conocimiento avanzado networking.
Conocimiento avanzado en sistemas operativos Windows.
Conocimiento avanzado en sistemas operativos AIX, HPUX.
Conocimiento avanzado en configuración Firewall.
(Elaborado por los autores)
8
1.5.2. Ministerio de Salud Pública (MSP)
El MSP ejerce la rectoría, regulación, planificación, coordinación, control y gestión de la
Salud Pública ecuatoriana a través de la gobernanza, vigilancia y control sanitario
garantizando el derecho a la Salud de los ecuatorianos. Avilés (s.f) afirma:
Fue creado por la Asamblea Constituyente de 1967, mediante decreto 084 publicado
en el Registro Oficial No. 149 del 16 de junio de ese mismo año durante el gobierno
del Dr. Otto Arosemena Gómez. Anteriormente las funciones de la salud formaban
parte del Ministerio de Previsión Social y Trabajo, y el primer paso para su creación
se dio en 1963, cuando se creó la Subsecretaría de Salud, que dependía del mismo
ministerio.
Entre los fines y objetivos del Ministerio de Salud Pública están la coordinación e
integración progresiva de los servicios de salud con miras a aumentar su cobertura;
llegar a todos los estratos sociales y lograr una descentralización administrativa; la
intensificación de los programas de agua potable y alcantarillado, especialmente en
las zonas marginales; el impulso y desarrollo de la medicina preventiva y la
educación sanitaria; la regionalización de los servicios de salud; el abaratamiento de
las medicinas mediante la reducción de impuestos, control de precios, producción de
drogas genéricas y la instalación de farmacias populares; investigación y educación
nutricional y el desarrollo de programas de alimentación básica para la madre
embarazada, el recién nacido y los niños en edad escolar; el apoyo a la
investigación científica; entre otros.
Como parte de la estructura organizacional de MSP se encuentra la Coordinación
General de Gestión Estratégica; la misma que en su misión contempla dirigir,
implementar, administrar y evaluar la gestión de procesos, tecnologías de la información
y comunicaciones, cultura y reforma institucional, así como los planes de innovación y
mejora, orientados a la eficiencia, eficacia y calidad de la gestión del Ministerio de Salud.
Esta coordinación a su vez abarca a la Dirección Nacional de Tecnologías de la
Información y Comunicaciones (DNTIC), la cual actualmente es la encargada de las TICs
del MSP a nivel central.
9
Actualmente, el MSP cuenta con una estructura organizacional definida por
viceministerios, subsecretarías, coordinaciones y direcciones, tal como se muestra en las
Figuras 3 y 4.
Figura 3 - Organigrama del MSP por viceministerios y subsecretarías
Adaptado (Ministerio de Salud Pública del Ecuador)
Figura 4 - Organigrama del MSP por coordinaciones y direcciones Adaptado (Ministerio de Salud Pública del Ecuador)
Ministerio de Salud Pública
Viceministerio de Gobernanza y
Vigilancia de Salud
Subsecretaría Nacional de Gobernanza de la Salud
Pública
Subsecretaría Nacional de Vigilancia de la Salud
Pública
Subsecretaría Nacional de Promoción de la Salud e
Igualdad
Viceministerio de Atención Integral en
Salud
Subsecretaría Nacional de Provisión de Servicios de
la Salud
Subsecretaría Nacional de Garantía de la Calidad de los Servicios de la Salud
Ministerio de Salud Pública
Coordinación General de Desarrollo
Estratégico en Salud
Coordinación General de Gestión
Estratégica
Dirección Nacional de Gestión de Procesos
Dirección Nacional de Tecnologías de Información y Comunicaciones
Dirección Nacional de Cambio de Cultura Organizacional
Coordinación General
Administrativa y Financiera
Coordinación General de
Planificación
Coordinación General de Asesoría
Jurídica
10
Según el (Ministerio de Salud Pública, 2012), mediante acuerdo Ministerial N.- 2880, se
establece aprobar, autorizar y aplicar dentro de la Dirección Nacional de Tecnologías de
Información y Comunicaciones (DNTIC) las políticas de servicios de red y servicios
informáticos, en la que se norma el desarrollo de software mediante políticas para la
Gestión Interna de Ingeniería de Software (GIIS), que en la sección cuatro subsección
“Del Desarrollo de Software” numeral 3 detalla las consideraciones necesarias para
ejecutar un proyecto de desarrollo de software y la metodología a utilizarse. Textualmente
se menciona lo siguiente: “El área de ingeniería de sistemas es responsable de dar a
conocer y vigilar la correcta aplicación de la metodología estándar, para el desarrollo de
software a todas y cada una de las personas involucradas en la fabricación de programas
informáticos”.
La Gestión Interna de Ingeniería de Software (GIIS) es una coordinación interna de la
DNTIC encargada del desarrollo de los proyectos de software dentro del MSP, dicha
gestión hasta hace pocos meses atrás usaba solamente la metodología Project
Management Institute (PMI) en el desarrollo de sus productos. Sin embargo, en la
actualidad se impulsa también el desarrollo de productos de software basados en la
metodología Agile Project Management2, pues permiten tener mayor rapidez y flexibilidad
en su ejecución. La estructura interna definida para el desarrollo de proyectos con
metodología PMI se muestra en la Figura 5.
Figura 5 - Estructura interna para la gestión de proyectos en el MSP
(Ministerio de Salud Pública del Ecuador)
2 Conjunto de metodologías para el desarrollo de proyectos orientados hacia una especial rapidez y
flexibilidad en su ejecución.
Líder del Proyecto
Analista Funcional
Ingeniero de QAAreas de Soporte
Lider Técnico
Desarrollador
11
Seguidamente en la Tabla 2, se detallan los conocimientos y experiencia con que
cuentan los integrantes de los equipos. Esta información será relevante al momento de
seleccionar a las personas a entrevistar y/o encuestar en el proceso de la investigación.
Tabla 2 - Descripción de conocimientos por perfil en el MSP
PERFIL DESCRIPCIÓN
Líder de
Proyectos
De 5 a 10 años de experiencia en gerenciamiento de proyectos.
De 5 a 10 años de experiencia en diseño de aplicaciones Java,
Sinfony, Oddo y Php.
Conocimiento intermedio de bases de datos: Sql, Oracle, MySQL.
Líder Técnico
De 5 a 10 años de experiencia en diseño de aplicaciones Java,
Sinfony, Oddo, Php
Conocimiento avanzado de bases de datos: Sql, Oracle, MySQL.
Dominio de plataformas de desarrollo utilizadas por el MSP.
Desarrollador De 1 a 3 años de experiencia en construcción de aplicaciones
Java, Sinfony y Php.
Conocimiento intermedio de bases de datos: Sql, Oracle, MySQL.
Analista
Funcional
Conocimiento en esquema funcional asociado a las necesidades
propias del MSP.
Conocimiento en el levantamiento de requerimientos funcionales.
Ingeniero de
Pruebas
Conocimiento básico de plataformas de desarrollo: Java, Sinfony y
Php.
Conocimiento de esquema de pruebas certificación UAT, BUAT.
Conocimiento de pruebas de cargas, estrés.
Áreas de
Soporte
Seguridad Informáticas.
Servidores.
Comunicaciones.
Soporte en Sitio.
(Elaborado por los autores)
1.6. Marco Teórico
El marco teórico que se desarrolla a continuación permite dar a conocer los conceptos
básicos necesarios en el desarrollo del presente proyecto. Explicamos como la ingeniería
ha aportado en el desarrollo del software a nivel mundial, luego nos enfocamos en las
estadísticas internas reportadas para América Latina y Ecuador a nivel del número de
empresas y total de ventas para las empresas relacionadas con la actividad de
programación informática.
12
Posteriormente se describen los conceptos relacionados con el desarrollo de software:
procesos, metodologías, y herramientas que permiten elaborar productos de software.
Finalmente, revisaremos los conceptos relacionados con la externalización de servicios
informativos y sus diferentes tipos.
1.6.1. Industria del desarrollo de software
La industria de desarrollo de software y provisión de servicios de informática constituye
uno de los puntales de la denominada economía de la información, generando además
las bases sobre las que se asienta la operación de las nuevas tecnologías de información
y comunicación (TICs). Su contribución a la economía de los países es cada vez mayor
en términos de inversiones, producción y nivel de empleo generado, además de ser una
actividad cuya vinculación a las demás actividades económicas va en aumento al generar
la infraestructura tecnológica sobre la que se realiza la modernización y tecnificación de
sus operaciones. (Acebo y Nuñez, 2017, p. 6)
Según la Asociación Ecuatoriana de Software (AESOF, 2011) el continente americano
figura como el principal mercado a nivel global, con una participación del 40.3% del total
en productos y servicios de software y un 35.6% del total en hardware (computadoras y
periféricos.); seguido de Europa con una participación del 27.1% y 36.7% del total
respectivamente; y Asia-Pacífico, con 29.5% del total en productos y servicios de
software y el 22.4% del total en hardware; lo que describe claramente el potencial de
mercado que puede aprovechar la industria de desarrollo de software en nuestro
continente.
Por otro lado, mundialmente las exportaciones de informática y servicios informáticos
alcanzaron alrededor de USD 215 mil millones de ventas en 2010, habiéndose más que
duplicado desde el valor de cinco años atrás como resultado de la externalización que se
ha dado en este tipo de servicios. El mayor exportador de servicios informáticos y de
información en 2010 fue Irlanda, cuyas exportaciones por este rubro representaban 15%
de su PIB, mientras que entre los países en desarrollo los principales exportadores de
estos servicios fueron India, China y Filipinas. Los tres principales mercados
importadores se encontraban en la Unión Europea, EE.UU. y Japón (Acebo & Nuñez,
2017).
13
Según el Observatorio TIC (2016) Ecuador tuvo 14.096 empresas relacionadas con las
Tecnologías de la Información y Comunicación. De estas 2.297 empresas están
relacionadas con la categoría de las Tecnologías de la Información abarcando 1250
empresas relacionadas con las actividades de programación informática, las mismas que
en su mayoría son PYMES. Así pues, el ingreso total de ventas fue de 506’618.610 de
dólares para la categoría Tecnologías de la Información y de 170’982.116 de dólares para
las actividades de programación informática.
De forma similar la industria de software en Ecuador generó ventas del orden de USD
500 millones (0.5% del PIB), creciendo anualmente el 17% en los 7 años previos, siendo
la actividad más importante la provisión de servicios informáticos con un 53%, al tiempo
que las ventas de software al sector público representan 22% del total. (Acebo & Nuñez,
2017)
Por otro lado, creemos que el software es imprescindible en las tareas corporativas de
cualquier organización. La automatización de los procesos de negocio en una empresa
es un ejemplo de ello. No se puede concebir a una organización en expansión sin
considerar un grado mínimo de automatización de los procesos, ya sea mediante el uso
de software estándar o software a medida. La industria del desarrollo de software se
fundamenta en el uso de fuerza laboral provista por desarrolladores e implementadores
que se encargan de transformar los requerimientos funcionales de los clientes en
realidades.
Según la Secretaría de Educación Superior, Ciencia, Tecnología e Innovación
(SENESCYT, 2015) la preparación académica en nuestro país se encuentra segmentada
en 160 carreras a nivel técnico, en pregrado y posgrado, relacionadas directamente a las
tecnologías de información y comunicación, de las cuales 85 carreras corresponden a
tercer nivel y aportan con el 52% de la participación total en profesionales de carreras
relacionadas con la informática. Los centros tecnológicos y los posgrados representan el
45% y 3% de la participación total de profesionales, respectivamente.
14
1.6.2. El software y la ingeniería de software
1.6.2.1. Software: definición e importancia
Muchas personas asocian el término software con los programas de computadora. Sin
embargo, Sommervile (2005), prefiere dar una definición más amplia donde el software
no son sólo programas, sino todos los documentos asociados a la configuración de datos
que se necesitan para hacer que estos programas operen de manera correcta. Por lo
general, un sistema de software consiste en diversos programas independientes, archivos
de configuración que utilizan para ejecutar estos programas, un sistema de
documentación que describe la estructura del sistema, la documentación para el usuario
que explica cómo utilizar el sistema y sitios web que permitan los usuarios descargar la
información de productos recientes. Los ingenieros de software se concentran en el
desarrollo de productos de software. Es decir, el software que se vende a un cliente.
Existen dos tipos de productos de software:
a) Productos genéricos: son sistemas producidos por una organización de desarrollo
que se venden al mercado abierto a cualquier cliente que le sea posible
comprarlos. Por ejemplo, software para computadores personales tales como
procesadores de texto, paquetes de dibujo, entre otros.
b) Productos personalizados (o hechos a medida): son sistemas requeridos por un
cliente en particular. Un contratista de software desarrolla el software
especialmente para ese cliente. Por ejemplo, sistemas de control para
instrumentos electrónicos, sistemas desarrollados para llevar a cabo procesos de
negocios específicos, sistemas de control de tráfico aéreo, entre otros.
Una diferencia importante entre estos diferentes tipos de software es que en los
productos genéricos la organización que desarrolla el software controla su especificación.
La especificación de los productos personalizados, por lo general, es desarrollada y
controlada por la organización que compra el software. Los desarrolladores de software
deben trabajar con esa especificación.
No obstante, la línea de separación entre estos tipos de productos se está haciendo
borrosa. Cada vez más compañías de software empiezan con un sistema genérico y lo
adaptan a las necesidades de un cliente en particular. Los sistemas de planificación de
15
recursos empresariales (ERP), como los sistemas SAP, son el mejor ejemplo de este
enfoque. Aquí, un sistema largo y complejo se adapta a una compañía incorporando
información sobre reglas de negocio y de procesos, informes, entre otros.
Pressman (2006) afirma que el software es importante porque afecta a casi todos los
aspectos de nuestras vidas y ha invadido nuestro comercio, cultura y actividades
cotidianas. El software transforma los datos personales (por ejemplo, las transacciones
financieras de un individuo) de modo que puedan ser más útiles en un contexto local,
administra la información de negocios para mejorar la competitividad, provee una vía para
las redes mundiales de información y brinda los medios para obtener información en
todas sus formas.
En el último medio siglo, el papel del software de cómputo ha sufrido un cambio
significativo. Las notables mejoras en el funcionamiento del hardware, los profundos
cambios en las arquitecturas de computadora, el gran incremento en la memoria y
capacidad de almacenamiento, y una amplia variedad de opciones de entradas y salidas
exóticas han propiciado la existencia de sistemas basados en computadora más
sofisticados y complejos. Cuando un sistema tiene éxito, la sofisticación y complejidad
producen resultados deslumbrantes, pero también plantean problemas enormes para
aquellos que deben construir sistemas complejos. En la actualidad, la enorme industria
del software se ha convertido en un factor dominante en las economías del mundo
industrializado. Equipos de especialistas de software, cada uno centrado en una parte de
la tecnología que se requiere para llegar a una aplicación compleja, han reemplazado al
programador solitario de los primeros tiempos.
1.6.2.2. Ingeniería de software
La ingeniería del software es una disciplina de la ingeniería que comprende todos los
aspectos de la producción de software desde las etapas iniciales de la especificación del
sistema hasta el mantenimiento de este después de que se utiliza. La ingeniería del
software no solo comprende los procesos técnicos del desarrollo de software, sino
también con actividades tales como la gestión de proyectos de software y el desarrollo de
herramientas, métodos y teorías de apoyo a la producción del software. (Sommervile,
2005, p.6)
Las aplicaciones de software no se fabrican a partir de materia prima ni se ensamblan a
partir de piezas más pequeñas. El software presenta esta característica especial en
16
comparación con otro tipo de productos. Es decir, no se fabrican en el sentido clásico,
sino que se desarrollan a través de un proceso de ingeniería. (Pressman, 2006) afirma:
Es una tecnología con varias capas como: compromiso con la calidad, proceso, métodos
y herramientas. Cualquier enfoque de ingeniería, incluso la de software, debe basarse en
un compromiso organizacional con la calidad. La administración total de la calidad como
Six Sigma3 y otras filosofías similares alimentan la cultura de mejora continua, y es esta
cultura la que lleva al desarrollo de enfoques cada vez más eficaces de la ingeniería de
software.
Según Cortés (2008) el objetivo principal de la ingeniería de software es construir una
solución eficiente que satisfaga las necesidades requeridas por el cliente. Pareciera fácil
de enunciar, pero es difícil conseguirlo si no se tienen los procedimientos, metodologías y
herramientas adecuadas.
1.6.2.3. Proceso del software
La definición de proceso de software varía de acuerdo con los autores. Algunos ahondan
en el detalle y otros sugieren una forma más general. Pressman (2006) afirma:
Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan
cuando va a crearse algún producto del trabajo. Una actividad busca lograr un
objetivo amplio y se desarrolla sin importar el dominio de la aplicación, tamaño del
proyecto, complejidad del esfuerzo o grado de rigor con el que se usará la
ingeniería de software. Una acción (diseño de la arquitectura) es un conjunto de
tareas que producen un producto importante del trabajo (por ejemplo, un modelo
del diseño de la arquitectura). Una tarea se centra en un objetivo pequeño, pero
bien definido (por ejemplo, realizar una prueba unitaria) que produce un resultado
tangible. En el contexto de la ingeniería de software, un proceso no es una
prescripción rígida de cómo elaborar software de cómputo. Por el contrario, es un
enfoque adaptable que permite que las personas que hacen el trabajo (el equipo
de software) busquen y elijan el conjunto apropiado de acciones y tareas para el
trabajo. Se busca siempre entregar el software en forma oportuna y con calidad
suficiente para satisfacer a quienes patrocinaron su creación y a aquellos que lo
usarán. La estructura del proceso establece el fundamento para el proceso
3 Es un método, basado en datos, para llevar la calidad hasta niveles próximos a la perfección, diferente de otros enfoques ya que también corrige los problemas antes de que se presenten.
17
completo de la ingeniería de software por medio de la identificación de un número
pequeño de actividades estructurales que sean aplicables a todos los proyectos
de software, sin importar su tamaño o complejidad (p.12)
Sommervile (2005) nos dice que un proceso de software es un conjunto de actividades y
resultados asociados que originan un producto de software. Estas actividades son
llevadas a cabo por los ingenieros de software y existen cuatro fundamentales que son
comunes para todos los procesos del software. Estas actividades son:
a) Especificación del software, donde los clientes e ingenieros definen el software a
producir y las restricciones sobre su operación.
b) Diseño e implementación del software, donde el software se diseña y se programa
(construcción).
c) Validación del software, donde el software se certifica para asegurar que es lo que
el cliente requiere.
d) Evolución del software, donde el software se modifica para adaptarlo a los cambios
requeridos por el cliente y el mercado.
Por otro lado, Noriega (2017) concluye: un proceso de desarrollo de software es una
estructura utilizada para el desarrollo de un producto de software. Entre sus sinónimos
están ciclo de vida y proceso de software. Hay muchos modelos para estos procesos,
cada uno de ellos describiendo enfoques diferentes para una variedad de tareas y
actividades a ser ejecutados a lo largo del proceso. (p.6)
1.6.2.4. Modelos de procesos de software
Según Sommervile (2005) un modelo de procesos de software es una descripción
simplificada de un proceso de software que presenta una visión de ese proceso. Estos
modelos pueden incluir actividades que son parte de los procesos y productos de
software y el papel de las personas involucradas en la ingeniería del software. Algunos
ejemplos de estos tipos de modelos que se pueden producir son:
1. Modelo de flujo de trabajo: que muestra la secuencia de actividades en el proceso
junto con sus entradas, salidas y dependencias. Las actividades en este modelo
representan acciones humanas.
18
2. Modelo de flujo de datos o de actividad: que representa el proceso como un
conjunto de actividades, cada una de las cuales realiza alguna transformación en
los datos. Muestra como la entrada en el proceso, tal como una especificación, se
transforma en una salida, tal como un diseño. Pueden representar
transformaciones llevadas a cabo por las personas o por las computadoras.
3. Modelo de rollacción: que representa los roles de las personas involucradas en el
proceso del software y las actividades de las que son responsables.
La mayor parte de los modelos de procesos del software se basan en uno de los tres
modelos generales o paradigmas de desarrollo de software:
1. El enfoque en cascada: considera las actividades anteriores y las representa
como fases de procesos separados, tales como la especificación de
requerimientos, el diseño del software, la implementación, las pruebas, entre
otras. Después de que cada etapa queda definida «se firma» y el desarrollo
continúa con la siguiente etapa.
2. Desarrollo iterativo: este enfoque entrelaza las actividades de especificación,
desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de
especificaciones muy abstractas. Este se refina basándose en las peticiones del
cliente para producir un sistema que satisfaga las necesidades de dicho cliente. El
sistema puede entonces ser entregado. De forma alternativa, se puede
reimplementar utilizando un enfoque más estructurado para producir un sistema
más sólido y mantenible.
3. Ingeniería del software basada en componentes (CBSE)4: esta técnica supone
que las partes del sistema existen. El proceso de desarrollo del sistema se enfoca
en la integración de estas partes más que en desarrollarlas desde el principio.
4 CBSE: Component-Based Software Sngineering
19
1.6.2.5. Tipos de desarrollo de software
Según Noriega (2017) existen tres tipos de desarrollo:
1. Desarrollo basado en prototipos: el desarrollo está basado en prototipos que
parten en cierto modo de la base de “construya algo y vea si eso es lo que se
pretende”. Se pueden tratar de un proceso de desarrollo completo o pueden ser
simples bocetos anticipándose al ciclo de vida del proyecto o de la
implementación.
2. Desarrollo interactivo e incremental: el desarrollo interactivo defiende la
construcción inicial de un pequeño pedazo de software que va creciendo de forma
gradual, ayudando a los involucrados en el proceso a descubrir, lo más pronto
posible, problemas o inconformidades antes de que puedan llevar al desastre al
proyecto.
Los procesos interactivos son los preferidos por los desarrolladores comerciales
porque ofrecen potencial de alcanzar los objetivos del proyecto para un cliente
que no sabe como comunicar lo que quiere.
3. Desarrollo ágil: el desarrollo ágil de software defiende algunos puntos de vista en
detrimento de otros:
Individuos e interacciones por procesos y herramientas
Un software funcionando por una documentación comprensible
Colaboración con el cliente por negociación de contratos
Respuesta al cambio por seguir un planteamiento
Los procesos ágiles utilizan la retroalimentación en lugar de la planificación como
su mecanismo de control primario. La retroalimentación se orienta a través de
pruebas y liberaciones periódicas del software desarrollado.
20
1.6.3. Sistemas de información y organización
1.6.3.1. Las TIC dinamizadoras de las formas organizativas
Según De Pablos et al. (2011) las TIC promueven nuevas formas de organizar las
diferentes áreas de la empresa. El desarrollo de las TIC y su aplicación suponen ante
todo facilidad y rapidez a la hora de trasmitir la información de la empresa. La ubicuidad,
la instantaneidad en la comunicación, así como la capacidad de integración de procesos
que permiten las TIC, hacen posible que las empresas se planteen decisiones sobre si
comprar o producir e incluso relocalizar a sus propios empleados. Los costos de
transacción que se generan en los procesos de producción y de intercambio de
información constituyen la base sobre la que las organizaciones plantean una decisión
final a este respecto. Es necesario comprender lo que suponen estas prácticas en las
empresas, pues es preciso profundizar un poco en el detalle y analizar el contexto en el
que se han ido generando.
En la concepción tradicional de las empresas, una organización lleva a cabo actividades
específicas de forma interna. Las personas que trabajaban en la empresa pertenecían
generalmente a la misma, pues las fronteras de las organizaciones estaban bien
definidas. Normalmente eran los clientes los que se mantenían fuera de las fronteras de
la empresa. La empresa mantenía grandes inventarios tanto de productos finalizados
como de materias primas, competía con economías de escala, mejoraba su eficiencia e
intentaba anticiparse a las necesidades de los clientes. La innovación en productos
permitía a la empresa anticiparse a sus competidores.
Sin embargo, hacia mediados de los ochenta se empezó a ver que este modelo ya no
funcionaba. Los clientes eran más sofisticados y exigían productos más personalizados.
El mundo se estaba globalizando. Con costos más bajos en algunos países la
subcontratación se iba haciendo cada vez más popular. Paralelamente las TIC iban
tomando mayor protagonismo e iban haciéndose más asequibles. A su vez se empezaba
a hacer cambios en las organizaciones. Las empresas empezaban a disminuir las
jerarquías. La subcontratación de servicios que la empresa no consideraba clave para su
desarrollo empezaba a ser una práctica habitual. En este contexto aparecen las prácticas
y formas organizativas nuevas, como la subcontratación, el teletrabajo, las
organizaciones virtuales y los sistemas de información compartidos.
21
1.6.3.2. Insourcing de tecnologías de información y comunicación
El insourcing de las TIC o también conocido como modelo inHouse se fundamenta en el
hecho de que la organización cuenta con una fuerza laboral interna con la que se hace
cargo y administra sus activos tecnológicos, de esta manera intenta tener un control más
detallado de todos los eventos que podrían producirse y ejecutar planes de acción que
permita obtener los mejores beneficios a los usuarios finales.
Este modelo es ampliamente usado en organizaciones que tienen la capacidad logística
de albergar a todos los colaboradores en sus propias instalaciones y de brindarles todo el
equipo tecnológico necesario requerido para sus labores diarias.
1.6.3.3. Outsourcing de tecnologías de información y comunicación
El outsourcing de las TIC consiste en la subcontratación de TIC como un proceso en el
que una organización decide la contratación externa o vender activos de TI en la
empresa, y además las personas y/o actividades a proveedores que a cambio
proporcionan y gestionan estos bienes y servicios. El outsourcing implica que las
actividades de gestión y los recursos de la organización sean gestionados por terceros. El
outsourcing de servicios de información se ha popularizado más en los últimos años,
pues las empresas necesitan posicionarse en un entorno de rápida evolución externa.
(De Pablos et al.,2011).
Según Fórneas (2008) algunos de los matices por lo que la subcontratación es
considerada una externalización son:
Es un servicio.
Se contrata por un tiempo relativamente largo, generalmente más de un año.
Puede incluir productos activos.
El contratado tiene un grado de autonomía significativo.
Existen responsabilidades del contratante que pasan a ser parte del contratado.
Existen riesgos indirectos al servicio contratado o de responsabilidad ante
terceros.
Lleva asociados parámetros de calidad medibles objetivamente.
Las condiciones de variación del servicio son acordadas en el momento de la
primera contratación.
22
Finalmente, Del Peso (2003) afirma que el outsourcing lejos de ser una moda pasajera se
está convirtiendo en un instrumento valioso para la gestión de las organizaciones. Las
áreas donde más se desarrolla el outsourcing son: redes de datos, gestión de redes de
voz y sistemas de integración de proyectos.
1.6.3.4. Razones para externalizar un servicio
Según Fórneas (2008) existen varias razones para externalizar un servicio y es muy
frecuente que ellas no sean del todo independientes ni argumentadas de forma única.
Las principales, por orden de importancia, son:
1. Reducción del costo del servicio subcontratado: este aspecto es el objetivo a
conseguir más nombrado entre los gestores que adoptan una estrategia de
externalización, tanto antes de ejecutarla como después de contratar. La esperanza
de la reducción de costos se basa en aspectos como:
Ineficiencias externas debido a que la empresa no es especialista en el servicio.
Acceso a economías de escala por volumen de los implementos. necesarios para
el servicio.
Calidad de servicio inaceptable.
Falta de profesionales para la realización del servicio.
Claros ejemplos que muestran que estas razones tienen gran peso son la
contratación de servicios de limpieza, la gestión de documentos, el procesamiento de
facturación, entre otros.
2. Concentración en las actividades principales de la empresa: es una razón empleada
por empresas con múltiples localizaciones (no necesariamente multinacionales) o con
un gran número de empleados. La concentración en las actividades de la empresa se
desea por:
Excesiva complejidad de los procesos de negocio, que hacen difícil la gestión.
Desplazamientos de los poderes fácticos de la empresa a los gestores de los
procesos no principales.
23
Estructura organizacional muy compleja para ser manejada por la gerencia.
Necesidad de concentrar la inversión en los procesos principales.
3. Mejora de la calidad del servicio: esta razón suele venir originada por los clientes
insatisfechos causada por:
Falta de conocimiento de la tecnología para soportar el negocio principal.
Inadecuadas estructuras del personal: horarios, incentivos, ubicación, entre otras.
Falta de alineación con el negocio principal de la empresa.
Falta de liderazgo por parte de los gestores de servicios.
4. Acceso al personal adecuadamente capacitado: existen dos causas raíz para dicha
razón. El personal tiene excesiva capacitación para las necesidades reales del
servicio, lo que causa frustración, o el personal tiene que ser reciclado para que
disponga de una capacitación adecuada pues no realiza correctamente el servicio.
Ambos casos son perjudiciales y difíciles debido a la rigidez que puede imponer la
legislación laboral.
Esta razón es de gran peso en la externalización de mantenimiento de software que
usa una empresa o en la externalización de servicios de seguridad.
5. Simplificación de los procesos de negocio: la complejidad de los procesos conlleva
errores, excepciones, necesidad de estructuras de gestión costosas, entre otras. Su
simplificación mejora resultados por la vía de reducción de costos estructurales,
reproceso, de oportunidad, entre otros.
Además, la simplicidad de los procesos de negocio induce a la posibilidad de nuevas
líneas de negocio, acceso a nuevos mercados, desarrollo de nuevos productos y
mejora el control sobre los riesgos de negocio.
6. Reducción del tiempo de llegada al mercado de los productos o servicios de la
empresa del cliente: la reducción del tiempo en la llegada a los mercados es una
razón muy argumentada en negocios donde el lanzamiento de nuevos productos es
importante. La necesidad de soporte adecuado dificulta la puesta efectiva de nuevos
productos y servicios, lo que permite a los competidores más rápidos adquirir ventajas
en la captación de cuota de mercado. La externalización en este sentido puede
24
aprovechar la dimensión de los proveedores y proporcionar el acceso a las
tecnologías adecuadas sin realizar costosas inversiones.
7. Reducción de los riesgos indirectos asumidos por la empresa cliente: muchas
empresas ven en diversas funciones que están adquiriendo riesgos que no están
relacionados con el negocio. Al realizar la externalización de servicios estos riesgos
son asumidos por la empresa contratista, la que debe aplicar todas las acciones
correctivas necesarias que se requieran de acuerdo a cada situación particular.
Además, se tiene un aumento en la eficiencia dado que la empresa contratista se
especializa en proveer el personal idóneo para cada requerimiento.
1.6.3.5. ¿Qué servicios se pueden externalizar?
Una de las primeras preguntas que debe hacerse una empresa que desea externalizar
algún tipo de trabajo es: ¿Qué puedo externalizar?. Los servicios de outsourcing pueden
ser muy diversos. Por lo tanto, la empresa debe saber qué tipo de outsourcing necesita y
quiere contratar, antes de dar por cerrado un contrato. El outsourcing que se contrate
tiene que ser un servicio a medida, que incluya todas las operaciones para que el servicio
contratado cubra todas las necesidades de la empresa. (Time of Software, 2016). En
función de la amplitud de los servicios que se contraten podemos hablar de dos tipos
diferentes de outsourcing:
Total, donde se transfieren las infraestructuras y el personal al proveedor, se hace
cargo de todas las fases de implementación y se asume el riesgo de la propiedad de
los recursos. La empresa cliente asume el riesgo asociado a la dependencia completa
de un único proveedor.
Selectivo, donde se permite al cliente cubrir ciertas necesidades minimizando riesgos
respecto al outsourcing total.
La razón más importante de recurrir al outsourcing es la de delegar la responsabilidad y
preocupación de la administración operacional. Un punto clave en toda empresa que
quiera recurrir al outsourcing es evitar tener un único proveedor, ya que podría llegar a
depender de él.
25
En la Figura 6 se observa el proceso definido por Drtina(1994) que resulta muy útil a la
hora de identificar lo que se puede externalizar en la organización, éste realiza varias
preguntas que permiten establecer aquellos procesos y/o actividades que se puede
externalizar.
Figura 6 - Pasos para el análisis de una decisión de outsourcing. Adaptado (Drtina, Ralph E, The Outsourcing Decision: Seize the Opportunity to Focus on
Activities that Give Your Company the Competitive Edge, 1994)
Una vez evaluados los procesos y/o actividades que se puede externalizar en la
empresa, se debe definir qué tipo de escenario de externalización se desea implementar.
1.6.3.6. Modelos de externalización
Según González et al. (2006) existen diferentes modelos de externalización que han
utilizado las principales compañías y que se diferencian entre sí por la distancia entre el
cliente y el proveedor de la externalización.
En la Figura 7 se puede ver las diferentes formas de externalización basadas en la
distancia entre cliente y proveedor.
26
Figura 7 - Formas de outsourcing basadas en las distancia.
Adaptado (González et al., “El offshore outsourcing de sistemas de información”, 2006).
1.6.3.6.1. Offshore
Es el tipo de externalización en el que la empresa el cliente contrata a un proveedor de
un país diferente al suyo para llevar a cabo ciertas funciones/proyectos de su propia
empresa.
En este modelo de externalización, los husos horarios entre el cliente y el proveedor son
completamente diferentes. A la hora de realizar una externalización usando el modelo
offShore se deben evaluar los siguientes criterios:
Diferencia salarial entre el país cliente y el país proveedor.
Posibilidad de teletrabajo.
El trabajo puede ser enviado por internet.
Trabajo repetitivo.
Trabajo con alto contenido de información.
Trabajo fácil de realizar.
El mayor propulsor de este tipo de externalización ha sido la aparición de internet, ya que
permite interactuar en tiempo real con cualquier parte del mundo y poder realizar
cualquier tipo de tarea que se pueda realizar con un ordenador. La razón principal de
llevar a cabo esta externalización es la reducción de costos por parte del cliente al
externalizar a países donde la mano de obra es más barata que en el propio país de la
compañía.
27
1.6.3.6.2. Nearshore
Es un modelo de externalización derivado de offShore en el que la externalización se
realiza a países vecinos con mismos husos horarios y con salarios inferiores al país de la
compañía. Los principales aspectos a la hora de realizar una externalización de este tipo
son: proximidad, afinidad cultural, facilidad para hacer negocios, huso horario similar o
parecido, lenguaje de comunicación, y reducción de costos.
1.6.3.6.3. Onshore
Es un modelo de externalización derivado de Nearshore y que algunas organizaciones
utilizan indistintamente, ya que la diferencia principal radica en que los servicios de
outsourcing en onshore se están prestando dentro del mismo país.
1.6.3.6.4. Onsite
En este modelo de externalización el proveedor está prestando los servicios en las
propias oficinas del cliente.
1.6.3.6.5. Global Delivery
El concepto de Global Delivery está asociado a empresas que prestan sus servicios a
nivel mundial, tanto de consultoría como de prestación de servicios tecnológicos. Estas
empresas tienen distribuidos sus equipos por todo el mundo, lo que les permite poder
responder antes a cualquier tipo de necesidad o peticiones de sus clientes.
El modelo de Global Delivery se basa en la reducción del riesgo operacional del
proyecto/servicio, a la vez que reduce el costo asociado al mismo para los clientes, en
este modelo se adoptan cualquiera de los modelos expuestos anteriormente como:
Offshore, Nearshore, Onshore y Onsite.
28
2. METODOLOGÍA
En el presente capitulo se describe el tipo de investigación aplicado desde un enfoque
cualitativo y cuantitativo. Se define el proceso de recolección de información, las técnicas
e instrumentos a efectuar y el número de entrevistas, encuestas y proyectos a analizar
para profundizar en el análisis buscando identificar las variables que intervienen directa e
indirectamente dentro de la ejecución de proyectos de software desde el punto de vista
de las opiniones de los entrevistados y de los resultados obtenidos en los proyectos
ejecutados.
2.1. Definición del tipo de investigación
Para efectuar el estudio comparativo propuesto en la presente investigación se usó un
enfoque cualitativo y cuantitativo. Esto permitió por un lado describir y concluir acerca de
la comparación de los dos modelos de desarrollo de software: offShore e inHouse
considerando para ello la opinión de los participantes de la investigación, y, por otro lado,
tener una perspectiva desde el análisis numérico de los resultados de la ejecución de los
proyectos bajo los modelos antes mencionados.
En este contexto se buscó identificar las variables que intervienen directa e
indirectamente dentro de la ejecución de proyectos de software, profundizando en las
experiencias y opiniones de los principales actores involucrados en la ejecución diaria de
dichos proyectos.
2.1.1. Enfoque cualitativo
Según Hernández et al., (2010) el enfoque cualitativo se guía por áreas o temas
significativos de investigación. Sin embargo, en lugar de que la claridad sobre las
preguntas de investigación e hipótesis preceda a la recolección y el análisis de los datos,
los estudios cualitativos pueden desarrollar preguntas e hipótesis antes, durante o
después de la recolección de los datos. Las actividades planteadas sirven primero, para
descubrir cuáles son las preguntas de investigación más importantes, y después, para
depurarlas. Utiliza métodos de recolección de datos no estandarizados ni
29
predeterminados completamente, no se efectúa una medición numérica por lo que el
análisis no es estadístico. El investigado hace preguntas abiertas a través del lenguaje
verbal y no verbal, los cuales son analizados y descritos.
Por tanto, el enfoque cualitativo fue usado en esta investigación para determinar cómo se
comportan varias variables de percepción de los participantes profundizando en sus
experiencias, perspectivas y opiniones en un proyecto de desarrollo de software. Se
indagó sobre tópicos como: estructura de equipo de trabajo, grado de dificultad de
gerenciamiento, grado de dificultad de administración de recursos, percepción de
resultados del proyecto, predisposición a juicios de valor, barreras de idioma barreras
culturales, barreras de horario, adopción de procesos, entre otros.
2.1.2. Enfoque cuantitativo
El enfoque cuantitativo es secuencial y probatorio. Cada etapa precede a la siguiente y
no se puede evitar ninguna de ellas, el orden es riguroso. Parte de una idea, que va
acotándose y, una vez delimitada, se derivan objetivos y preguntas de investigación; se
revisa la literatura y se construye un marco o una perspectiva teórica. De las preguntas
se establecen hipótesis y determinan variables; se desarrolla un plan para probarlas
(diseño); se miden las variables en un determinado contexto; se analizan las
mediciones obtenidas (con frecuencia utilizando métodos estadísticos), y se establece
una serie de conclusiones respecto de la(s) hipótesis. (Hernández et al.,2010)
Por tanto, el enfoque cuantitativo fue usado para obtener información de los proyectos
ejecutados bajo los modelos offShore e inHouse. Se indagó sobre tópicos como:
presupuesto del proyecto, duración, esfuerzo, desviación de tiempo, número de controles
de cambios e indicadores como: Schedule Performance Index (SPI)5 y Cost Performance
Index (CPI)6.
5 Schedule Performance Index (SPI) es un índice que compara lo avanzado contra lo que se tenía pensado
avanzar a un momento dado.
6 Cost Performance Index (CPI), es un índice que expresa la "eficiencia" en los costos reales del proyecto,
comparando el Valor Ganado (costo presupuestado para el trabajo realizado), versus el Costo Real.
30
2.2. Recolección de información
En el proceso de recolección de información acotar el tamaño de la muestra es
fundamental ya que es donde se espera encontrar a las unidades de análisis de las
cuales se extraerá información, facilitando de esta manera el desarrollo de la
investigación. En ambos procesos de investigación las técnicas de recolección de datos
pueden ser múltiples, desde el punto de vista de investigación cuantitativa como
cuestionarios cerrados, registros de datos estadísticos, pruebas estandarizadas, sistemas
de mediciones, desde el punto de vista cualitativa entrevistas profundas, pruebas
proyectivas, cuestionarios abiertos, sesiones de grupos, biografías, revisión de archivos,
observación entre otros (Hernández et al.,2010).
La recolección de información para el enfoque cualitativo utilizó muestreo por
conveniencia, no se efectuó una tabulación numérica debido a que el análisis no es
estadístico. Esto significa que podremos explotar la profundidad de significados, la
riqueza interpretativa y contextualización de los fenómenos. Para el enfoque cuantitativo
se utilizó fuentes primarias y secundarias de información provistas por las organizaciones
analizadas.
2.2.1. Técnicas e instrumentos de recolección
Con el objetivo de recopilar datos para comparar los modelos de desarrollo de software:
offShore e inHouse desde las perspectivas: financiera, estrategia organizacional, cliente y
aprendizaje. Se elaboró una encuesta de opinión, una entrevista y un análisis de los
indicadores del proyecto como presupuesto, duración, esfuerzo, desviación de tiempo,
número de controles de cambio, entre otros.
Las encuestas de opinión se fundamentaron en un cuestionario de preguntas
previamente diseñadas. Fueron dirigidas a empleados de las organizaciones estudiadas
que forman parte del desarrollo de productos de software en los que se incluyeron
gestores, desarrolladores, analistas funcionales, entre otros.
Las entrevistas realizadas fueron semiestructuradas, aquí el investigador llevo la pauta o
guía con los temas a cubrir, los términos a usar y el orden de las preguntas que, a
diferencia de las encuestas, aportaron con una mayor flexibilidad. Fueron dirigidas a los
31
empleados de las organizaciones estudiadas con conocimiento en la gestión del
desarrollo de productos de software.
Finalmente, se realizó un análisis de contenido basado en las estadísticas de proyectos
en las organizaciones de estudio.
2.2.2. Definición del número de entrevistas y encuestas a realizar en el
proceso de investigación
Para la definición del número de entrevistas, encuestas y estadísticas de los
proyectos analizados, se tomó en cuenta el número de casos necesarios para
responder a la pregunta de investigación, el tiempo de recolección de la
información y la capacidad de recolección de información por parte de los
investigadores.
El número total de personas por rol asignadas en cada organización para realizar
el desarrollo de proyectos de software bajo el modelo offShore e inHouse se
muestra en la Tabla 3.
Tabla 3 - Número total de personas por perfil en las instituciones estudiadas.
NÚMERO TOTAL DE PERSONAS POR
ROL ASIGNADAS PARA EL OFFSHORE
EN TCS ECUADOR
NÚMERO TOTAL DE
PERSONAS POR ROL EN EL
MSP
4 Delivery Managers. 5 Líderes de Proyectos.
5 Project Managers. 5 Líderes Técnicos.
4 Desarrolladores Senior. 29 Desarrolladores.
16 Desarrolladores Junior. 4 Analistas funcionales.
3 Expertos de Diseño. 4 Ingenieros de QA.
6 Ingeniero de QA.
2 Ingeniero de Seguridad.
2 Release Manager.
(Elaborado por los autores)
32
En los apartados 1.5.1 y 1.5.2 donde se realiza un breve resumen de las organizaciones
estudiadas y en las Tablas 1 y 2 de la misma sección se muestra a detalle los
conocimientos de las personas por cada perfil. Esto permite identificar los perfiles sobre
los cuales se debe realizar las entrevistas, ya que no todos los perfiles tienen los
conocimientos de gestión de proyectos. La Tabla 4 muestra a continuación el número de
entrevistas a realizar por cada perfil.
Tabla 4 - Cantidad de entrevistas a realizar por institución y rol.
POR TCS ECUADOR POR MSP
2 Delivery Manager 2 Líderes de Proyectos
3 Project Manager 2 Líderes Técnicos
1 Gerente de Proyecto
1 Director Nacional de Tecnologías
(Elaborado por los autores)
La distribución de las entrevistas por perfil e institución a lo largo de la investigación se
muestra en la Tabla 5.
Tabla 5 - Distribución de entrevistas por institución y rol.
NÚMERO PERFIL INSTITUCIÓN
Entrevista 1 Delivery Manager TCS Ecuador
Entrevista 2 Delivery Manager TCS Ecuador
Entrevista 3 Project Manager TCS Ecuador
Entrevista 4 Project Manager TCS Ecuador
Entrevista 5 Project Manager TCS Ecuador
Entrevista 6 Líder de Proyectos MSP
Entrevista 7 Líder de Proyectos MSP
Entrevista 8 Líder Técnico MSP
Entrevista 9 Líder Técnico MSP
Entrevista 10 Gerente de proyecto MSP
Entrevista 11 Director Nacional de Tecnologías MSP
(Elaborado por los autores)
33
De forma similar al proceso de selección del número de entrevistas se determina el
número de encuestas a realizar por perfil y organización. Las mismas se detallan en la
Tabla 6.
Tabla 6 - Cantidad de encuestas a realizar por institución y rol.
POR TCS ECUADOR POR MSP
1 Delivery Manager 1 Líder de Proyecto
2 Project Managers 2 Líderes Técnicos
1 Desarrollador Senior 5 Desarrolladores
5 Desarrolladores Junior 1 Analista funcional
1 Experto de Diseño 1 Ingenieros de QA
1 Ingeniero de QA
(Elaborado por los autores)
2.2.3. Definición del número de proyectos a examinar
TCS Ecuador y MSP realizan una clasificación del tamaño de sus proyectos dependiendo
de su duración y presupuesto. Las Tablas 7 y 8 describen a detalle cada uno de ellos.
Tabla 7 - Clasificación del tamaño de los proyectos por su duración.
EMPRESA GRANDE MEDIANO PEQUEÑO
TCS Ecuador Mayor a 3 meses De 1 a 3 meses De 1 a 2 meses
MSP Mayor a 6 meses De 3 a 6 meses De 1 a 3 meses
(Elaborado por los autores)
Tabla 8 - Clasificación del tamaño de los proyectos por su presupuesto.
EMPRESA GRANDE MEDIANO PEQUEÑO
TCS Ecuador Mayor a
$300.000
Mayor a $200.000 y
menor a $300.000
Mayor a $100.000 y
menor a $200.000
MSP Mayor a
$100.000
Mayor a $50.000 y
menor a $100.000
Mayor a $10.000 y
menor a $50.000
(Elaborado por los autores)
34
Tomando en cuenta la clasificación de los proyectos antes expuesta, se realizó un
análisis de las estadísticas de los proyectos de acuerdo a su tamaño. Se observó sus
índices de satisfacción, desviaciones de esfuerzo y tiempo, estado de los proyectos
desarrollados bajo el modelo offShore e inHouse y los comparamos desde el punto de
vista de la perspectiva financiera.
Tabla 9 - Cantidad de proyectos a analizar por tamaño e institución.
TAMAÑO DEL PROYECTO TCS ECUADOR MSP
Grande 1 1
Mediano 1 1
Pequeño 1 1
(Elaborado por los autores)
35
3. RESULTADOS Y DISCUSIÓN
La presente sección muestra los resultados cuantitativos derivados de las encuestas y
estadísticas de proyectos. Se comparan conjuntamente las respuestas de las encuestas y
las entrevistas ejecutadas desde el punto de vista cualitativo para determinar si ambos
enfoques son coincidentes o mantienen contradicciones. Posteriormente, para
complementar la investigación, se analizan varios indicadores extraídos de los “proyectos
tipo” desde el punto de vista financiero y de gestión. Por último, se proyectan los
resultados de las entrevistas desde las perspectivas: financiera, estrategia
organizacional, del cliente y de aprendizaje, para luego construir un análisis de
semejanzas y diferencias por cada una de ellas en las organizaciones en estudio.
3.1. Análisis cuantitativo de los resultados obtenidos
3.1.1. Resultados de las encuestas sobre el modelo offShore
En la siguiente sección se presenta la distribución porcentual de los resultados por cada
una de las preguntas con su respectivo análisis y gráfico. Las catorce preguntas de la
encuesta aplicada en TCS Ecuador sobre el modelo offShore se pueden observar en el
Anexo C y la tabulación de los resultados en el Anexo E. A continuación, se presentan
cada una de las preguntas:
1. Seleccione los principales criterios que se toman en cuenta para la selección del
modelo de desarrollo de software offShore en un determinado proyecto.
a. Presupuesto asignado
b. Duración del proyecto (meses)
c. Tamaño del proyecto (pequeño – grande – mediano)
d. Tecnologías de desarrollo involucradas
e. Experiencia de los integrantes del equipo de trabajo
36
Figura 8 - Distribución porcentual: Pregunta 1 de la encuesta sobre modelo offShore (Elaborado por los autores)
De acuerdo a las encuestas, los principales criterios que se toman en cuenta en TCS
Ecuador para elegir el modelo de desarrollo offShore son el presupuesto asignado y
el tamaño del proyecto.
En cambio, desde el punto de vista de los entrevistados se consideran el tamaño del
proyecto, los presupuestos, las tecnologías involucradas, pues la estrategia
corporativa de la organización es utilizar toda la capacidad instalada de la
“multinacional” para ofrecer al cliente soluciones tecnológicas de pronta liberación
por lo tanto son aquellos proyectos catalogados como grandes y medianos los más
propensos a utilizar este modelo de trabajo. Esto se corrobora cuando uno de los
entrevistados afirma que:
“A veces el presupuesto del proyecto no se acopla a la realidad nacional, el costo de
los recursos es mayor aquí que en la India, es preferible utilizar el offShore en estos
casos, de tal manera que se pueda ahorrar costos en las horas hombre de los
recursos, se pueden asignar más personas para el desarrollo del producto si fuese
necesario y liberarlo más rápido”. (Entrevista 1, comunicación personal, 2 de abril de
2018)
En el mismo sentido, otro de los entrevistados menciona: “Ahora mismo tú vez que si
un recurso local renuncia por definición corporativa no puede ser reemplazado con
26,92%23,08%
19,23%15,38% 15,38%
Presupuesto asignado
Tamaño del proyecto ( pequeño – grande – mediano)
Tecnologías de desarrollo involucradas
Duración del proyecto (meses)
Experiencia de los integrantes del equipo de trabajo
37
una nueva contratación porque la estrategia es aprovechar los recursos del offShore,
ellos son más baratos y con los proyectos grandes y medianos es la mejor estrategia,
cuestan igual al cliente y los entregables son mucho más rápidos”. (Entrevista 3,
comunicación personal, 2 de abril de 2018)
2. ¿Cómo fue la experiencia de trabajar con un proyecto de desarrollo de software bajo
el modelo offShore desde el punto de vista de gerenciamiento del proyecto?
a. Buena
b. Mala
c. Ni buena ni mala
¿Por qué?
Figura 9 - Distribución porcentual: Pregunta 2 de la encuesta sobre modelo offShore
(Elaborado por los autores)
El 45.45% de los encuestados indica que su experiencia no fue ni mala ni buena, con
lo que se podría considerar que el modelo offShore para el desarrollo software es
usado en la organización como parte del trabajo diario del personal de gestión de
proyectos de TCS Ecuador. Por otro lado, un porcentaje considerable, el 36.36%,
dice haber tenido una mala experiencia con el modelo offShore para el desarrollo de
software. Comparando estos resultados con los de la pregunta 10 de la misma
encuesta, donde el 81.82% de los encuestados dice que existen barreras culturales
que dificultan la iteración con los desarrolladores y consideran que el 75% de estas
18,18%
36,36%
45,45%
Buena Mala Ni buena ni mala
38
barreras se centran en el idioma, se puede explicar que la mala experiencia tiene
relación con el manejo de una lengua extranjera (inglés) que dificulta el
entendimiento de los requerimientos del proyecto.
En base a las entrevistas, y para afianzar lo indicado en el párrafo anterior, se puede
considerar que otra de las dificultades al trabajar con un proyecto de desarrollo de
software bajo el modelo offShore desde el punto de vista de gerenciamiento del
proyecto está asociada a la diferencia horaria, que es de más de 15 horas en
relación con los centros de desarrollo offShore que se encuentran en la India. Uno de
los entrevistados menciona:
“En relación con el offShore la comunicación es la pieza clave de los procesos, y se
convierte en un aspecto crítico. Trabajar con personas en otra parte del mundo con
otro horario, otra cultura y otro idioma requiere una buena gestión en la
comunicación. Es necesario establecer mecanismos y herramientas de comunicación
a diferentes niveles, formales e informales, desde las comunicaciones en situaciones
normales a las que tienen que producirse en casos emergentes”. (Entrevista 3,
comunicación personal, 2 de abril de 2018)
Asimismo, otro de los entrevistados afirma: “Definitivamente, el dominio del inglés
hablado y escrito es importante, trabajamos mucho con medios electrónicos escritos
debido a la diferencia horaria existente entre los centros de desarrollo, pero también
con videoconferencias en donde se explica y se entienden mejor los requerimientos.
Esto hace que se viabilice de mejor manera el desarrollo y ejecución de los
proyectos”. (Entrevista 2, comunicación personal, 6 de abril de 2018)
3. Seleccione el índice de satisfacción de los clientes al tener un producto desarrollado
bajo el modelo offShore.
a. Entre 0 y 50%
b. Entre 51% y 75%
c. Entre 76% y 90%
d. Entre 91% y 100%
39
Figura 10 - Distribución porcentual: Pregunta 3 de la encuesta sobre modelo offShore
(Elaborado por los autores)
Un porcentaje significativo (45,45%) de los encuestados indica que el índice de
satisfacción del cliente se ubica entre el 76% y 90%. Sin embargo, se visualiza un
porcentaje del 54.54% en el que el índice de satisfacción de un proyecto de desarrollo
de software con el modelo offShore está entre el 0% y el 75% de satisfacción, lo cual
para una empresa multinacional no se encuentra dentro del estándar corporativo que
debe ser superior al 90%, pues se corre el riesgo de perder fácilmente la relación con
el cliente e incurrir en penalidades. Adicionalmente, es preciso recalcar que ninguno
de los encuestados se acogió a la opción que señalaba un índice de satisfacción
entre 91% y 100%.
4. ¿De su participación en proyectos desarrollados bajo el modelo offShore en general
hubo optimización de recursos (gasto menos de lo planificado)?
a. Si
b. No
45,45%
36,36%
18,18%
0,00%
Entre 76% y 90% Entre 51% y 75% Entre 0 y 50% Entre 91% y 100%
40
Figura 11 - Distribución porcentual: Pregunta 4 de la encuesta sobre modelo offShore
(Elaborado por los autores)
De acuerdo a lo reportado por las personas encuestadas todos concuerdan en que el
desarrollo de proyectos bajo el modelo de desarrollo offShore no optimiza recursos ni
permite ahorrar en los costos asignados al proyecto.
En concordancia con la pregunta 2 sobre la perspectiva financiera de la entrevista
sobre el modelo offShore: ¿Cree usted que el modelo offShore de desarrollo de
software permite optimizar el uso de recursos financieros?, se puede evidenciar que
el criterio coincide, pues las personas entrevistadas creen que actualmente no
optimizan recursos financieros debido a la falta de madurez del modelo.
Uno de los entrevistados menciona: “Creo que el modelo si te permite optimizar
recursos financieros, la mano de obra afuera es más barata, y el proyecto puede dejar
mejores ganancias para la empresa. Sin embargo, actualmente tenemos otros
inconvenientes que no han permitido que los proyectos optimicen sus recursos; el
idioma y el entendimiento del giro del negocio como tal no ha permitido que estas
optimizaciones se conviertan en una realidad palpable”. (Entrevista 4, comunicación
personal, 4 de abril de 2018)
Otro de los entrevistados afirma: “Evitamos todos los gastos que involucran el tener
las personas especialistas en el core bancario en nuestro país, pero ahora gastamos
en la gente ecuatoriana que está desplazada en la India”. (Entrevista 1, comunicación
personal, 2 de abril de 2018)
0,00%
100,00%
Si No
41
Un tercer entrevistado menciona que debido al poco tiempo de implementación del
modelo no se ha podido obtener los mejores resultados. El menciona lo siguiente:
“Hay que considerar que el modelo offShore empezó el año anterior y por tanto no
estamos totalmente adaptados al modelo ni con la madurez del mismo”. (Entrevista 1,
comunicación personal, 2 de abril de 2018)
5. ¿De su participación en proyectos desarrollados bajo con modelo offShore en general
hubo atrasos en el proceso de construcción de la solución tecnológica?
a. Si
b. No
Figura 12 - Distribución porcentual: Pregunta 5 de la encuesta sobre modelo offShore (Elaborado por los autores)
El 81.82% de los encuestados manifiesta que la etapa de construcción de la solución
tecnológica presenta atrasos. Al relacionar estos resultados con las preguntas
referentes a la perspectiva de aprendizaje de la entrevista sobre el modelo offShore
se puede relacionar los atrasos a factores como:
Entendimiento de los requerimientos a causa del idioma.
Experiencia del equipo de trabajo en los aplicativos objeto de cambio del
proyecto.
Franja horaria con varias horas de diferencia entre los centros offShore que
mantiene la multinacional.
Cambios en el alcance del proyecto.
81,82%
18,18%
Si No
42
Uno de los entrevistados afirma: “De igual forma las tecnologías usadas y el nivel de
madurez de la aplicación condicionan la externalización. La utilización de tecnologías
muy recientes o ya obsoletas dificulta la localización del personal técnico disponible
con la suficiente experiencia para el offShore. La formación del personal técnico se
convierte en un factor crítico para el éxito del proyecto”. (Entrevista 2, comunicación
personal, 6 de abril de 2018)
6. ¿En relación al modelo de predicción Rayleigh utilizado por la corporación, el número
de defectos reales que fueron levantados en la etapa de pruebas y certificación para
proyectos desarrollados bajo modalidad offShore fueron?
a. Mayor a la cantidad esperada
b. Menor a la cantidad esperada
Figura 13 - Distribución porcentual: Pregunta 6 de la encuesta sobre modelo offShore
(Elaborado por los autores)
El 81.82% de los encuestados dice haber tenido mayor cantidad de defectos a lo
esperado. A decir de los investigadores por su experiencia en el desarrollo de
proyectos, este incremento o disminución del número de defectos de una solución
tecnológica pueden explicarse por los siguientes factores:
Experiencia de los desarrolladores en lenguajes de programación y en los
aplicativos impactados por parte del proyecto.
81,82%
18,18%
Mayor a la cantidad esperada Menor a la cantidad esperada
43
Experiencia del ingeniero de pruebas (QA) para ejecutar el proceso de
certificación.
Revisión periódica al código desarrollado por parte del responsable técnico de
la solución asignado al proyecto.
7. ¿En promedio cuantos controles de cambios fueron levantados dentro de la ejecución
de los proyectos desarrollados bajo el modelo offShore?
a. Uno
b. Dos
c. Tres
d. Más de tres
e. Ninguno
Figura 14 - Distribución porcentual: Pregunta 7 de la encuesta sobre modelo offShore
(Elaborado por los autores)
La mayoría de las personas encuestadas (54.55%) manifiesta que no se levantó
ningún control de cambios dentro de la ejecución del proyecto. Habría que decir, de la
experiencia laboral de los investigadores en TCS Ecuador que los controles de
cambio normalmente se crean cuando existe impacto por parte del cliente en razón
del cambio de alcance funcional, retiro del proyecto, normativa gubernamental, entre
otros. Por otro lado, TCS Ecuador mantiene una política rigurosa de cumplir con los
9,09%
0,00% 0,00%
36,36%
54,55%
0,00%
10,00%
20,00%
30,00%
40,00%
50,00%
60,00%
1
Uno Dos Tres Más de tres Ninguno
44
cronogramas pactados y cualquier atraso imputable a la organización debe ser
recuperada de manera interna con los asociados asignados al proyecto.
8. ¿Se levantó algún riesgo asociado al uso del modelo de desarrollo offShore?
a. Si
b. No
En caso de escoger la opción SI indique cuales fueron los riesgos levantados.
Figura 15 - Distribución porcentual: Pregunta 8 de la encuesta sobre modelo offShore
(Elaborado por los autores)
La mayor parte de los encuestados (72.73%) coincide en manifestar que no se
identificó ningún riesgo asociado al uso del modelo offShore. Desde otro punto de
vista, el 27.27% dice lo contrario; y al entrar en el detalle de las respuestas cuando
han elegido la opción Si nos damos cuenta que los riesgos levantados fueron
asociados al idioma, entendimiento de los requerimientos, barrera horaria,
entendimiento integral de la solución y funcionamiento del negocio.
Esto coincide con las entrevistas cuando se manifiesta que estos riesgos se
evidencian en el día a día de la ejecución de los proyectos, pues mencionan que la
comunicación es parte importantísima del modelo y además muchas veces necesitan
de aclaraciones del negocio para el entendimiento de los requerimientos. Uno de los
entrevistados dice al respecto:
27,27%
72,73%
Si No
45
Una de las personas entrevistadas menciona: “En el desarrollo de proyectos de gran
tamaño es difícil no tener contacto con el cliente para clarificar ciertas dudas que
surgen, la gestión de situaciones excepcionales, resolución de incidencias o la
necesidad de aclaraciones hacen necesaria la comunicación directa”. (Entrevista 3,
comunicación personal, 2 de abril de 2018)
Otro de ellos afirma que “El proceso de transferencia de conocimientos se realiza en
varias etapas, es necesario trasferir el conocimiento funcional, la documentación
técnica, el diseño de las aplicaciones, entre otros. Y teniendo en cuenta las
diferencias culturales aun cuando se hable en el mismo idioma los malos entendidos y
las confusiones son causa de retrasos e ineficiencias. Es complejo gestionar las
diferencias culturales. Sin embargo, debemos garantizar que se hayan comprendido
los documentos y no progresar los errores de comprensión hasta niveles cuyas
consecuencias sean difíciles de identificar”. (Entrevista 2, comunicación personal, 6
de abril de 2018)
9. ¿Indique el nivel del manejo de lengua extranjera (inglés) requerido para proyectos
con modelo offShore?
a. Entre 0 y 50%
b. Entre 50% y 75%
c. Entre 75% y 100%
Figura 16 - Distribución porcentual: Pregunta 9 de la encuesta sobre modelo offShore
(Elaborado por los autores)
9,09% 9,09%
81,82%
Entre 0 y 50% Entre 50% y 75% Entre 75% y 100%
46
A lo largo del análisis de las preguntas anteriores se ha evidenciado que el tema del
idioma es muy importante en el desarrollo del modelo. En varias de ellas se ha notado
la preocupación de los entrevistados y/o encuestados. Las diferencias culturales y las
diferencias horarias son fundamentales, razón por la cual se concuerda que el
81.82% de los encuestados expresan que el nivel del manejo de lengua extranjera
debe ser entre el 75% y el 100%.
10. ¿Existieron barreras culturales que dificultaron la iteración con los desarrolladores
extranjeros?
a. Si
b. No
En caso de escoger Si a la respuesta marque con una X indicando cuáles:
Religiosas
Idioma
Étnicas
Costumbres
Figura 17 - Distribución porcentual: Pregunta 10 de la encuesta sobre modelo offShore
(Elaborado por los autores)
81,82%
18,18%
Si No
47
Figura 18- Distribución porcentual: Pregunta 10-1 de la encuesta sobre modelo offShore
(Elaborado por los autores)
La principal barrera que encuentran los encuestados es el manejo de una lengua
extranjera. Así pues, el 81.82% dice que existen barreras culturales que dificultan la
iteración con los desarrolladores, y de estos el 75% se centran en el idioma. No se
observan como un factor determinante los temas étnicos, religiosos, y/o costumbres.
Igualmente, en las entrevistas realizadas se ha notado una gran preocupación por el
idioma, pues, a decir de los entrevistados, aunque se haya establecido el inglés como
el idioma en que se realizan las actividades, en la mayoría de los casos los
interlocutores no son nativos de este idioma y por ello los errores y las confusiones
son frecuentes.
Uno de los entrevistos dice que: “Las dificultades idiomáticas han hecho que las
comunicaciones se tornen demasiado formales, lo que para nosotros ralentiza el
proceso completo”. (Entrevista 3, comunicación personal, 2 de abril de 2018)
Otro de ellos coincide cuando afirma: “Aunque el idioma para la documentación del
código, de las librerías comunes, del framework, de la interfaz del usuario y del
entorno de desarrollo está establecido, ha sido difícil realizar la transferencia del
conocimiento”. (Entrevista 4, comunicación personal, 4 de abril de 2018)
0,00%
75,00%
0,00%
25,00%
Religiosas Idioma Étnicas Costumbres
48
11. ¿Existieron eventos de entendimiento incorrecto de los requerimientos funcionales y
técnicos aducidos al idioma y/o cultura de los desarrolladores?
a. Si
b. No
Figura 19 - Distribución porcentual: Pregunta 11 de la encuesta sobre modelo offShore
(Elaborado por los autores)
Con una afirmación categórica se puede evidenciar que las personas encuestas
responden haber tenido eventos de entendimiento incorrecto de los requerimientos
funcionales y técnicos aducidos al idioma y/o cultura de los desarrolladores. Esta
confirmación, a decir de los investigadores determina que el idioma es crucial en el
modelo de desarrollo offShore.
12. ¿Existieron problemas con el manejo de franjas horarias que dificultaron la ejecución
del proyecto?
a. Si
b. No
100,00%
0,00%
Si No
49
Figura 20 - Distribución porcentual: Pregunta 12 de la encuesta sobre modelo offShore
(Elaborado por los autores)
La pregunta 2 de la encuesta offShore, que consultaba la experiencia de trabajar con
el modelo offShore desde el punto de vista del gerenciamiento del proyecto, afirmo en
parte los resultados mostrados en la presente pregunta, pues un 90.91% dice haber
tenido problemas con el manejo de franjas horarias. Igualmente, las entrevistas
concuerdan en decir que existen esfuerzos en la comunicación con los centros
offShore.
Uno de los entrevistados afirma que: “Definitivamente, el dominio del inglés hablado y
escrito es importante, trabajamos mucho con medios electrónicos escritos debido a la
diferencia horaria existente entre los centros de desarrollo, pero también con
videoconferencias en donde se explica y se entienden mejor los requerimientos. Esto
hace que se viabilice de mejor manera el desarrollo y ejecución de los proyectos”.
(Entrevista 2, comunicación personal, 6 de abril de 2018).
13. ¿Indique el número de desarrolladores promedio asignados a un proyecto de tipo
offShore?
a. De 1 a 3
b. De 4 a 5
c. De 6 a 8
d. Más de 8
90,91%
9,09%
Si No
50
Figura 21 - Distribución porcentual: Pregunta 13 de la encuesta sobre modelo offShore
(Elaborado por los autores)
De acuerdo con los resultados mostrados, el 81.82% de los encuestados menciona
que, en promedio, los desarrolladores asignados al desarrollo de un proyecto tipo
offShore es de 1 a 3. A decir de los investigadores este número se maneja sin
mayores problemas y los Project Managers con los que cuenta la corporación tienen
la capacidad y habilidad para manejar adecuadamente a este equipo.
14. Si podría catalogar en una franja de evaluación el conocimiento técnico de los
desarrolladores offShore cual escogería:
a. Bajo
b. Bajo - Medio
c. Medio
d. Medio – Alto
81,82%
18,18%
0,00% 0,00%
De 1 a 3 De 4 a 5 De 6 a 8 Más de 8
51
Figura 22 - Distribución porcentual: Pregunta 14 de la encuesta sobre modelo offShore
(Elaborado por los autores)
Los resultados mostrados en esta pregunta indican que el 72.73% de los encuestados
cree que el nivel del conocimiento de los desarrolladores offShore esta entre bajo y
medio – bajo. A decir de los investigadores esta apreciación en las personas
encuestadas puede estar relacionada con las dificultades presentadas al momento de
realizar el traspaso del conocimiento.
3.1.2. Resultados de las encuestas sobre el modelo inHouse
En la siguiente sección se presenta la distribución porcentual de los resultados por cada
una de las preguntas con su respectivo análisis y gráfico. Las catorce preguntas de la
encuesta aplicada en el Ministerio de Salud Pública sobre el modelo inHouse se pueden
observar en el Anexo D y la tabulación de los resultados en el Anexo F. A continuación,
se presentan cada una de las preguntas:
72,73%
27,27%
0,00% 0,00%
Medio Bajo - Medio Bajo Medio – Alto
52
1. Seleccione los principales criterios que se toman en cuenta para la selección del
modelo de desarrollo de software inHouse en un determinado proyecto.
a. Presupuesto asignado
b. Duración del proyecto (meses)
c. Tamaño del proyecto (pequeño – grande – mediano)
d. Tecnologías de desarrollo involucradas
e. Experiencia de los integrantes del equipo de trabajo
f. Normativa gubernamental
Figura 23 - Distribución porcentual: Pregunta 1 de la encuesta sobre modelo inHouse (Elaborado por los autores)
Los principales criterios a tomar en cuenta para el desarrollo de software bajo el
modelo inHouse son el tamaño del proyecto, la experiencia de los integrantes del
equipo de trabajo y las normativas gubernamentales. Los tres criterios tienen un
porcentaje del 21.43% del total de encuestados.
Análogamente, las personas entrevistadas coinciden en que los criterios a tomar en
cuenta son el presupuesto asignado y la normativa gubernamental, pues al ser esta
una institución pública debe regirse por los lineamientos ministeriales y/o
presidenciales, y por los presupuestos asignados para la salud y los programas de
17,86%
7,14%
21,43%
10,71%
21,43% 21,43%
Presupuesto asignado
Duración del proyecto (meses)
Tamaño del proyecto ( pequeño – grande – mediano)
Tecnologías de desarrollo involucradas
Experiencia de los integrantes del equipo de trabajo
Normativa Gubernamental
53
desarrollo social priorizados por el gobierno central. Uno de los entrevistados
menciona:
“Se dan disposiciones a nivel ministerial de desarrollar un producto por la necesidad
de cumplir con las estrategias gubernamentales”. (Entrevista 6, comunicación
personal, 12 de abril de 2018)
2. ¿Cómo fue la experiencia de trabajar con un proyecto de desarrollo de software bajo
el modelo inHouse desde el punto de vista de gerenciamiento del proyecto?
a. Buena
b. Mala
c. Ni buena ni mala
¿Por qué?
Figura 24 - Distribución porcentual: Pregunta 2 de la encuesta sobre modelo inHouse
(Elaborado por los autores)
El 50% de los encuestados indica que su experiencia no fue ni buena ni mala. Sin
embargo, el 20% dice haber tenido una mala experiencia. Analizando las respuestas
para este grupo, sobre una mala experiencia, se aduce que la falta de definiciones
por parte del negocio, la carencia de normativa, el incumplimiento de los tiempos
30,00%
20,00%
50,00%
Buena Mala Ni buena ni mala
54
establecidos en las entregas de definiciones, los cambios en los requerimientos, el
desconocimiento del negocio y las trabas burocráticas son algunos de los factores
que indican que pueden existir eventos ajenos a la metodología que complican el
normal desarrollo del proyecto.
3. Seleccione el índice de satisfacción de los clientes al tener un producto desarrollado
bajo el modelo inHouse.
a. Entre 0 y 50%
b. Entre 51% y 75%
c. Entre 76% y 90%
d. Entre 91% y 100%
Figura 25 - Distribución porcentual: Pregunta 3 de la encuesta sobre modelo inHouse
(Elaborado por los autores)
Los índices de satisfacción del cliente se encuentran muy por debajo de la estadística
esperada de gestión de proyectos. Es alarmante verificar que el 70% de las personas
encuestadas eligieron el intervalo de 0% a 75%, lo cual refleja que existen varias
necesidades de mejora que deben revelarse y abordarse. Probablemente las
falencias no se asocien directamente al modelo de desarrollo de software, sino a
causas como la falta del conocimiento por parte del usuario funcional, cambios en los
30,00%
40,00%
10,00%
20,00%
Entre 0 y 50% Entre 51% y 75% Entre 76% y 90% Entre 91% y 100%
55
requerimientos o la falta de infraestructura necesaria para despliegue de los
aplicativos.
Uno de los entrevistados afirma: “Lamentablemente en el MSP existe mucha rotación
del personal en las diferentes direcciones, lo que ocasiona que los usuarios del
negocio no tengan un buen entendimiento del mismo, generalmente los usuarios que
se encuentran en el territorio conocen mejor los procesos que las personas que se
encuentran en la planta central cuando debería ser al contrario”. (Entrevista 6,
comunicación personal, 12 de abril de 2018)
Otro de los entrevistados menciona: “Los procesos que se realizan en territorio por los
usuarios finales, no se acoplan en su totalidad a los procesos implementados en el
software desarrollado. Se genera un descontento por los productos antes de
conocerlos, pues no existe un buen manejo de las capacitaciones entregadas a los
usuarios finales”. (Entrevista 6, comunicación personal, 12 de abril de 2018)
4. ¿De su participación en proyectos desarrollados bajo el modelo inHouse en general
hubo optimización de recursos (gasto menos de lo planificado)?
a. Si
b. No
Figura 26 - Distribución porcentual: Pregunta 4 de la encuesta sobre modelo inHouse
(Elaborado por los autores)
70,00%
30,00%
1Si No
56
El 70% de los encuestados cree que el uso del modelo de desarrollo inHouse propicia
la optimización de recursos asignados. Comparando esto con las respuestas de las
entrevistas se puede evidenciar que el criterio coincide, ya que se indica que si existe
una optimización de recursos.
La persona entrevistada menciona: “Definitivamente la contratación a proveedores o
terceros fue bastante costosa para el MSP a pesar de que, en los varios intentos, las
primeras contrataciones si se entregaron productos, se entregó por ejemplo en un
contrato que tuvimos hardware y software pero el software no estaba con fuentes
entonces no podíamos hacer ningún cambio, no éramos dueños del software.
Posteriormente se contrató solo software, pero la empresa no cumplió con el contrato
y se tuvo que finalizarlo unilateralmente y cobrar las garantías, el ministerio no perdió
dinero, pero si tiempo. Pero en relación de los productos que ya se ven muy visibles
en el ministerio de salud frente a todo lo que nos costaba o todo lo que involucraban
los contratos anteriores definitivamente el desarrollo inHouse es mucho menos
costoso”. (Entrevista 7, comunicación personal, 13 de abril de 2018)
Otra de las personas entrevistadas menciona que también se optimizan recursos
humanos y dice: “Ahora que usamos metodologías ágiles para el desarrollo de
software se puede evidenciar que existe una mejor gestión de las personas asignadas
al desarrollo; con el modelo en cascada mientras se esperaba alguna definición por
parte del cliente no se podía asignar a las personas a otro proyecto, pero actualmente
cuando no existe una definición por parte del usuario la persona encargada del
desarrollo pasa a colaborar en otro proyecto”. (Entrevista 6, comunicación personal,
12 de abril de 2018)
5. ¿De su participación en proyectos desarrollados bajo con modelo inHouse en general
hubo atrasos en el proceso de construcción de la solución tecnológica?
a. Si
b. No
57
Figura 27 - Distribución porcentual: Pregunta 5 de la encuesta sobre modelo inHouse (Elaborado por los autores)
El 100% de los encuestados manifiesta que en la etapa de construcción de la solución
tecnológica se presentan atrasos. A decir de los investigadores por su experiencia en
el desarrollo de proyectos dentro del MSP, los atrasos están relacionados con la falta
de definiciones por parte del usuario funcional, ausencia de un método estándar de
estimación, disposiciones superiores a nivel ministerial o gubernamental para dar
prioridad a ciertos proyectos sin efectuar un análisis detallado de impacto en tiempo y
esfuerzo, falta de experiencia del equipo de trabajo en los aplicativos objeto de
cambio del proyecto, y retraso en asignaciones presupuestarias para la compra de
licencias de plataformas de desarrollo indispensables para la ejecución del proyecto.
6. Los defectos encontrados en la etapa de pruebas y certificación fueron:
a. Mayor a la cantidad esperada
b. Menor a la cantidad esperada
100,0%
0,0%
Si No
58
Figura 28 - Distribución porcentual: Pregunta 6 de la encuesta sobre modelo inHouse (Elaborado por los autores)
En esta pregunta es importante analizar la relación existente entre la satisfacción del
cliente y la cantidad de errores esperados en etapa de pruebas. Si la cantidad de
errores es mucho mayor a la esperada se presume que ocurre por dos motivos: el
producto en la etapa de desarrollo no cumplió con los requerimientos mínimos
necesarios para ser puesto en ambiente de pruebas y/o el área de calidad tiene un
conocimiento superior del negocio.
Si hablamos del producto en la etapa de desarrollo se puede pensar que es el
resultado de malas prácticas que se están llevando cabo en el proceso de
construcción del software. Sin embargo, no siempre estos errores son atribuidos a la
persona que construyó el producto, ya que pueden existir otros factores como las
definiciones funcionales incorrectas, la infraestructura implementada no es la
adecuada, entre otros.
Por otro lado, si se analiza el punto de vista de la calidad, hay que entender que los
proyectos que son desplegados en el ambiente productivo -en territorio- han pasado
por una certificación profunda y, por tanto, el índice de satisfacción del cliente debería
tener un valor más alto que el expresado en la pregunta 3 de la encuesta del modelo
inHouse. Ninguno de los encuestados dijo haber tenido un índice de satisfacción de
entre el 91% y 100%. Con este razonamiento se llega a pensar que las respuestas de
las preguntas 3 y 6 de la encuesta sobre modelo inHouse se contradicen.
60,0%
40,0%
Mayor a la cantidad esperada Menor a la cantidad esperada
59
Uno de los entrevistados afirma: “Las dificultades encontradas en el desarrollo de los
productos no son técnicas puramente, sin duda existen personas técnicas que se
encuentran en el desarrollo de un producto y no son expertos en los conceptos y
temas propios del negocio; pero en mi opinión esto es normal en todas las empresas.
El técnico adquiere el conocimiento funcional con el pasar del tiempo y hasta se
vuelve experto; pero el responsable de conocer el negocio como tal es el usuario
funcional y aquí muchas veces los usuarios no saben ni lo que quieren”. (Entrevista 8,
comunicación telefónica, 12 de abril de 2018)
7. ¿En promedio cuantos controles de cambios fueron levantados dentro de la ejecución
de los proyectos desarrollados bajo el modelo inHouse?
a. Uno
b. Dos
c. Tres
d. Más de tres
e. Ninguno
Figura 29 - Distribución porcentual: Pregunta 7 de la encuesta sobre modelo inHouse (Elaborado por los autores)
El 50% de los encuestados dicen haber tenido más de tres controles de cambios en
promedio. Si observamos la totalidad, todos los proyectos tienen al menos un control
de cambios ejecutado. Relacionando los resultados con lo expuesto en preguntas
10,0%
20,0% 20,0%
50,0%
0,0%
Uno Dos Tres Más de tres Ninguno
60
anteriores, se puede afirmar que los atrasos producidos en la etapa de construcción
pueden darse por factores como: el desconocimiento funcional del usuario de
negocio, alta rotación de personal funcional y/o técnico, necesidades ambiguas, entre
otras.
8. ¿Se levantó algún riesgo asociado al uso del modelo de desarrollo inHouse?
a. Si
b. No
En caso de escoger la opción SI indique cuales fueron los riesgos levantados.
Figura 30 - Distribución porcentual: Pregunta 8 de la encuesta sobre modelo inHouse
(Elaborado por los autores)
El 60% de los encuestados dice que se levantaron riesgos asociados al modelo de
desarrollo inHouse. Sin embargo, analizando las respuestas detallas al elegir la
opción SI, nos damos cuenta que los riesgos mencionados no son asociadas al
modelo de desarrollo como tal, sino al desarrollo de productos. Los riesgos detallados
fueron: alta rotación del personal, falta de definiciones por las áreas involucradas,
cambio en el alcance, cambio en la normativa legal vigente, falta de normativa,
cambios en el requerimiento, prioridades de asignaciones y cambio de autoridades de
turno.
60,0%
40,0%
Si No
61
9. ¿Indique el nivel del manejo de lengua extranjera (inglés) requerido para proyectos
desarrollados bajo el modelo inHouse?
a. Entre 0 y 50%
b. Entre 50% y 75%
c. Entre 75% y 100%
Figura 31 - Distribución porcentual: Pregunta 9 de la encuesta sobre modelo inHouse (Elaborado por los autores)
El 60% de los encuestados indica que se necesita un manejo mínimo de lengua
extranjera, catalogado entre el 0% y 50%. Como se puede revisar en las expresiones
de las entrevistas abajo presentadas, dicho resultado está relacionado con que todos
los integrantes del equipo de trabajo son locales y no requieren tener un dominio
extenso del inglés para el desarrollo de software. Sin duda, desde el punto de vista
tecnológico, es importante tener un nivel básico del inglés, debido a que la mayoría de
lenguajes de programación tienen como origen países de habla inglesa.
Adicionalmente, la asesoría y ayuda en línea es más amplia y completa, los artículos
de comunidad tecnológica y el vocabulario técnico en el área de informática están, en
su mayoría, en inglés.
60,0%
40,0%
0,0%
Entre 0 y 50% Entre 50% y 75% Entre 75% y 100%
62
Uno de los entrevistados afirma: “En el medio en que nos encontramos no considero
que el dominio del idioma en los desarrolladores viabilicen de una mejor manera la
ejecución de los proyectos, en la actualidad es importante saber inglés por la
competencia profesional del mercado, pero centrándonos en nuestro medio como tal
el inglés aporta en medida de que las personas se capaciten, despejen sus dudas en
cuanto a los aplicativos, funcionamiento, entre otros. Trabajamos una planta local,
100% ecuatoriana, no tenemos problemas con el idioma ni la cultura, en ese sentido
todos nos entendemos sin ningún problema”. (Entrevista 10, comunicación personal,
28 de abril de 2018)
Otro de ellos menciona: “El inglés que un programador necesita es básico, no necesita
dominar el vocabulario, la gramática y la ortografía. No es necesario que hablen con
un acento perfecto ni mucho menos porque en nuestro medio no nos relacionamos
con extranjeros. El día a día de un desarrollador suele incluir momentos de dudas, y
no pueden evitar recurrir a foros online para actualizarse en información sobre los
entornos de trabajo, interfaces de desarrollo, etc. La mayoría de estos foros y
documentos están en inglés, pero actualmente tienen un buen nivel de inglés, las
universidades les obligan a que salgan con un nivel mucho mejor que el que teníamos
en años anteriores”. (Entrevista 9, comunicación personal, 15 de abril de 2018)
10. ¿Existen barreras culturales que dificultan la iteración con los desarrolladores locales?
a. Si
b. No
En caso de escoger Si a la respuesta marque con una X indicando cuáles:
Religiosas
Idioma
Étnicas
Costumbres
63
Figura 32 - Distribución porcentual: Pregunta 10 de la encuesta sobre modelo inHouse (Elaborado por los autores)
Con un porcentaje del 100% los encuestados indican que no existen barreras
culturales, religiosas, étnicas, costumbres o idioma. Se puede inferir tácitamente que
dichas barreras no dificultan la iteración con los desarrolladores. Además, al tener en
su totalidad una planta conformada por personas ecuatorianas que cumplen
funciones de desarrolladores, líderes de proyecto, líderes técnicos, ingenieros de
pruebas e ingenieros de soporte, estas barreras definitivamente son mínimas en el
entorno de trabajo del Ministerio de Salud Pública.
11. ¿Existieron eventos de entendimiento incorrecto de los requerimientos funcionales y
técnicos aducidos al idioma y/o cultura de los desarrolladores?
a. Si
b. No
0,0%
Si No
64
Figura 33 - Distribución porcentual: Pregunta 11 de la encuesta sobre modelo inHouse
(Elaborado por los autores)
Ratificando lo indicado en la pregunta anterior, el 100% de los encuestados dice que
no han existido eventos de mal entendimiento de los requerimientos funcionales y
técnicos relacionados al idioma y/o cultura de los desarrolladores.
12. ¿Existieron problemas con sobretiempos no planificados en la ejecución del proyecto?
a. Si
b. No
Figura 34 - Distribución porcentual: Pregunta 12 de la encuesta sobre modelo inHouse (Elaborado por los autores)
0,0%
100,0%
Si No
90,0%
10,0%
Si No
65
El 90% de los encuestados dice que existen sobretiempos no planificados en la
ejecución de proyectos. En relación directa con la pregunta 7 del modelo inHouse, en
la que se evidenció que a lo largo de la ejecución del proyecto se levanta al menos
un control de cambios, se puede concluir que al existir cambios no planificados en la
funcionalidad se incurre en sobretiempos de trabajo no planificados.
13. ¿Indique el número de desarrolladores promedio asignados a un proyecto de tipo
inHouse?
a. De 1 a 3
b. De 4 a 5
c. De 6 a 8
d. Más de 8
Figura 35 - Distribución porcentual: Pregunta 13 de la encuesta sobre modelo inHouse (Elaborado por los autores)
Según el 40% de los encuestados los proyectos que siguen el modelo de desarrollo
inHouse mantiene una asignación de más de 8 personas. El 30% indica que el
número de desarrolladores en promedio se encuentra entre 1 y 3 o 4 y 5. Con ello se
puede decir que dentro del ministerio los proyectos son de diferente tamaño.
30,0% 30,0%
0,0%
40,0%
De 1 a 3 De 4 a 5 De 6 a 8 Más de 8
66
14. Si podría catalogar en una franja de evaluación el conocimiento técnico de los
desarrolladores asignados a los proyectos cual escogería:
a. Bajo
b. Bajo - Medio
c. Medio
d. Medio – Alto
Figura 36 - Distribución porcentual: Pregunta 14 de la encuesta sobre modelo inHouse
(Elaborado por los autores)
El 50% de los encuestados expresa que el conocimiento técnico de los
desarrolladores tiene un nivel medio-alto. Ninguna persona relacionó el conocimiento
técnico a un nivel bajo, lo que indica que la planta de desarrolladores cumple las
expectativas de las personas que llevan a cabo la gestión de los proyectos.
3.1.3. Análisis de resultados por proyectos ejecutados
Conocedores que los indicadores del proyecto permiten determinar si se ha cumplido o
no con los objetivos planteados en términos de resultados, tanto en el ámbito financiero
como de gestión, se enfoca el estudio en el análisis del cumplimiento, evaluación,
eficiencia y eficacia que han tenido los proyectos en las organizaciones de estudio. Como
se definió en el apartado de la metodología se ha tomado en cuenta tres proyectos en
cada organización, los mismos que tienen tamaño grande, mediano y pequeño para
enfocar el estudio.
En las Tablas 10 y 11 se resumen los datos entregados por las organizaciones de estudio
que se usaron para realizar el análisis de los indicadores de resultados y de gestión.
0,0%
20,0%
30,0%
50,0%
Bajo Bajo - Medio Medio Medio – Alto.
67
Tabla 10 - Descripción de proyectos ejecutados en TCS Ecuador.
NOMBRE DEL PROYECTO PRY_WAP MIGRACION MIDDLEWARE FII
Objetivo
Migrar todos los servicios web desde los servidores WebSphere Broker 6.0 hacia WebSphere Integration Bus 10 y Process Server 6.5 hacia Process Server 8.5.5.
Tamaño del proyecto Grande
Presupuesto estimado $773.164,00
Fecha de inicio planificada 07-Marzo-2016
Fecha de finalización planificada 31-Marzo-2017
Fecha de inicio real 07-Marzo-2016
Fecha de finalización real 13-Octubre-2017
Duración en días 405
Esfuerzo estimado de horas hombre 22090
Número de controles de cambios
levantados 2
% Desviación en Tiempo 50
% Completado 99%
SPI 0,77
CPI 0,67
NOMBRE DEL PROYECTO PRY_BID LAPE MUJERES FIII
Objetivo Habilitar en el aplicativo Logic Flow el producto microcrédito mujeres con características especiales para el segmento.
Tamaño del proyecto Mediano
Presupuesto estimado $345.310,00
Fecha de inicio planificada 23-Agosto-2016
Fecha de finalización planificada 21-Julio-2017
Fecha de inicio real 23-Agosto-2016
Fecha de finalización real 20-Octubre-2017
Duración en días 292
Esfuerzo estimado de horas hombre 9866
Número de controles de cambios levantados
1
% Desviación en Tiempo 27,51
% Completado 94
SPI 0,77
CPI 0,83
68
NOMBRE DEL PROYECTO PRY_REFERIMIENTOS
Objetivo
Cumplir con la regulación RB103 de la Súper Intendencia de Bancos y Seguros que obliga a las entidades a ofrecer dos opciones de carteras de seguros en sus productos de crédito.
Tamaño del proyecto Pequeño
Presupuesto estimado $244.898,00
Fecha de inicio planificada 03-Julio-2017
Fecha de finalización planificada 09-Enero-2018
Fecha de inicio real 03-Julio-2017
Fecha de finalización real 24-Enero-2018
Duración en días 142
Esfuerzo estimado de horas hombre 6290
Número de controles de cambios levantados
1
% Desviación en Tiempo 8,4
% Completado 100
SPI 0.94
CPI 0,87
(Elaborado por los autores)
Tabla 11 - Descripción de proyectos ejecutados en el MSP
NOMBRE DEL PROYECTO PRY.2017.05. NUEVOS MÓDULOS HISTORIA CLÍNICA FASE 2
Objetivo
Construcción e implementación de los módulos: Core, registro y admisión, ordenes médicas, medicamentos y dispositivos médicos y atención medica
Tamaño del proyecto Grande
Presupuesto estimado $122.569,92
Fecha de inicio planificada 01-Febrero-2017
Fecha de finalización planificada 31-Diciembre-2017
Fecha de inicio real 01-Febrero-2017
Fecha de finalización real 14-Diciembre-2017
Duración en días 217
Esfuerzo estimado de horas hombre 15476
Número de controles de cambios levantados
0
% Desviación en Tiempo 0
% Completado 100
SPI 1,28
CPI 1,32
69
NOMBRE DEL PROYECTO PRY.2017.08 DISEÑO E IMPLEMENTACIÓN DE
LA ARQUITECTURA PARA EL BUS DE SERVICIO
EMPRESARIAL
Objetivo Diseñar una arquitectura de interoperabilidad e implementar el bus de servicios empresariales para el MSP
Tamaño del proyecto Mediano
Presupuesto estimado $25.3233,12
Fecha de inicio planificada 01-Marzo-2017
Fecha de finalización planificada 31-Diciembre-2017
Fecha de inicio real 01-Marzo-2017
Fecha de finalización real 10-Noviembre-2017
Duración en días 175
Esfuerzo estimado de horas hombre 3186
Número de controles de cambios levantados
0
% Desviación en Tiempo 0
% Completado 100%
SPI 1,37
CPI 1,54
NOMBRE DEL PROYECTO PRY.2017.06.2. GEOSALUD
Objetivo
Actualizar el Geovisualizador, el mismo que permite administrar y desplegar el catastro y directorio de establecimientos de salud a nivel nacional. Esto permitirá que el MSP obtenga en tiempo real la información necesaria para el análisis de información.
Tamaño del proyecto Pequeño
Presupuesto estimado $11.293,92
Fecha de inicio planificada 28-Septiembre-2016
Fecha de finalización planificada 23-Marzo-2017
Fecha de inicio real 28-Septiembre-2016
Fecha de finalización real 16-Octubre-2017
Duración en días 514
Esfuerzo estimado de horas hombre 1426
Número de controles de cambios levantados
3
% Desviación en Tiempo 53,7
% Completado 100%
SPI 1
CPI 0,61
(Elaborado por los autores)
70
Dentro del análisis de los indicadores de proyectos ejecutados tenemos los siguientes:
Porcentaje de cumplimiento del proyecto: sabiendo que el cumplimiento tiene que
ver con la finalización de un trabajo, se puede observar que en este indicador se
cumple en los tres proyectos del MSP. Sin embargo, en TCS Ecuador se cumple solo
en uno de los tres. Los proyectos catalogados como grande y mediano no llegaron a
finalizarse, y registran un porcentaje de avance del 99% y 94% respectivamente.
Porcentaje de cumplimiento del tiempo del proyecto: al examinar las fechas de
finalización planificadas con las fechas reales de los proyectos, se observa que TCS
Ecuador no cumple con las fechas pactadas en los tres proyectos. A su vez, al
analizar los seguimientos realizados a los proyectos se determina una causa común
por la cual ocurrió la desviación: la estimación del tiempo necesario para completar
determinados requisitos no era adecuada. TCS Ecuador cuenta con un área
denominada Unidad de Diseño conformada por un equipo técnico “experto”
encargado de construir las estimaciones de desarrollo. Sin embargo, este equipo no
acompaña hasta el final de la evolución del proyecto. Al momento de realizar la
estimación, el equipo de diseño omitió varios requerimientos que fueron encontrados
en la ejecución de la construcción del software. Adicionalmente, se identificó que los
tres proyectos modificaron su alcance a través de controles de cambio solicitados por
el cliente, lo que influye de igual forma en el incremento de las fechas acordadas para
la entrega.
Por otro lado, al analizar los tres proyectos del MSP se observa que uno de ellos no
cumple con la fecha de entrega acordada. En la documentación se evidencian tres
controles de cambio solicitados por el cliente para modificar su alcance, motivo por el
cual se incurre en este atraso. Finalmente, es necesario recalcar que los dos
proyectos restantes fueron entregados a tiempo e incluso con varios días de
anticipación a la fecha pactada.
Número de controles de cambio levantados
Como se mencionó en párrafos anteriores, los tres proyectos ejecutados por TCS
Ecuador incurrieron en la creación de controles de cambio solicitados por el cliente,
debido a la necesidad de modificar los requerimientos iniciales del proyecto. Los
costos de los controles de cambio son imputados al cliente. En cambio, en los
71
proyectos ejecutados en el MSP se observó que uno de los tres proyectos analizados
incurrió en la modificación del alcance solicitado por el cliente.
SPI (Schedule Performance Index)
Este índice mide la eficiencia del trabajo y el progreso de un proyecto, comparando el
trabajo real realizado con el trabajo planeado. Analizando los proyectos ejecutados
por TCS Ecuador se evidencia que todos cuentan con un valor menor a 1, como
consecuencia de que estos terminaron con retrasos. Por otro lado, en los tres
proyectos ejecutados en el MSP se observa que este indicador es mayor o igual a
uno, lo que indica que los proyectos terminaron antes de lo planificado.
CPI (Cost Performance Index)
El CPI mide la eficiencia del uso de recursos o eficiencia de costos para un proyecto.
Para TCS Ecuador los tres proyectos muestran un valor menor a 1, lo que indica que
el valor del trabajo completado es menor al de los recursos gastados. Es decir, por
encima de lo presupuestado. Esto representa un riesgo de que el proyecto pueda
quedarse sin dinero antes de que finalice. Por su parte, para el MSP los tres
proyectos tienen un CPI mayor o igual a 1, lo que indica que el presupuesto del
proyecto está dentro de lo planificado.
3.2. Análisis cualitativo de los resultados obtenidos
3.2.1. Perspectiva Financiera
Desde el punto de vista financiero de la ejecución de proyectos offShore se determina
que no existe ninguna evidencia que materialice un ahorro de presupuesto, reducción de
tarifas o deflación del importe económico (costos) necesario para la ejecución de un
determinado proyecto.
Uno de los entrevistados menciona: “En mi dashboard del proyecto el valor de utilización
de recursos extranjeros no tiene ninguna relación con disminución del costo de proyecto,
la tarifa aplicada no es menor a la usada por recursos locales”. (Entrevista 5,
comunicación personal, 12 de abril de 2018).
72
Por su parte, el modelo inHouse permite a los gestores de proyectos tener un control más
adecuado de los costos incurridos y recursos utilizados. Esto debido a que el MSP se
alinea a un presupuesto anual asignado a la DNTIC proveniente del presupuesto general
del estado y que debe ser utilizado en el año en curso, de tal manera que con antelación
cada periodo se efectúa una planificación con todos los proyectos que van a ser
ejecutados. Uno de los entrevistados menciona:
“Los recursos de desarrollo de software son asignados por proyecto y perfil de acuerdo a
la prioridad existente de ejecución del mismo, si es requerido y existe las partidas
presupuestarias se puede contratar personal (temporal) para suplir la necesidad”.
(Entrevista 6, comunicación personal, 12 de abril de 2018)
Otro de los entrevistados responde: “Al finalizar el año la DNTIC realiza la planificación de
los proyectos que van hacer ejecutados el año siguiente, esto permite tener una
definición aproximada del número de recursos que vamos a necesitar durante el año, en
este escenario se puede determinar la necesidad de contratación (temporal) de recursos
adicionales”. (Entrevista 11, comunicación telefónica, 26 de abril de 2018)
Un tercero menciona que: “Al ser una institución pública nos regimos a la asignación
anual del presupuesto general del estado, esto podría ser considerado como una
limitante ya que por contextos políticos y/o circunstancias propias de la política
ecuatoriana podríamos tener una reducción, sin contar con que somos sujetos de
auditoria económica por parte de la Contraloría General del Estado”. (Entrevista 11,
comunicación telefónica, 26 de abril de 2018)
3.2.2. Perspectiva de la Estrategia Organizacional
Desde el punto de vista de la estrategia organizacional, los dos modelos facilitan el
desarrollo de nuevos productos de software orientados a satisfacer las necesidades del
cliente y/o departamentos.
Uno de los entrevistados en relación con el modelo Offshore menciona: “La puesta en
marcha del proyecto determinó una gran ayuda para el departamento beneficiario, tenían
una imperiosa necesidad de reducir costos operativos de procesamiento manual y errores
productos del mismo, independiente del modelo de desarrollo con el que se ejecute el
73
proyecto la necesidad existe y debe ser satisfecha”. (Entrevista 5, comunicación personal,
12 de abril de 2018)
Tanto en el modelo inHouse como en el offShore los objetivos estratégicos de la
organización se materializan cuando existen herramientas tecnológicas que los usuarios
pueden aprovechar para desarrollar y cumplir cada meta que ha sido pactada a corto,
mediano y largo plazo.
La persona entrevistada, en relación con el modelo Offshore menciona: “Cada
departamento de la organización tiene un conjunto de metas que necesitan ser cubiertas,
la suma de todas estas metas individuales (de cada departamento) determinan que la
organización cumpla sus objetivos estratégicos”. (Entrevista 2, comunicación personal, 6
de abril de 2018)
Otro de ellos afirma: “Los proyectos que son desarrollados por TCS deben guardar una
garantía mínima de éxito de tal manera que contribuya con el cumplimiento de objetivos
estratégicos que son alineados por la multinacional. Sin embargo, nuestros proyectos
también logran que el cliente pueda materializar sus perspectivas organizacionales”.
(Entrevista 1, comunicación personal, 2 de abril de 2018)
Las lecturas obtenidas del proceso de entrevista permiten tener varias interpretaciones
asociadas a la estrategia organizacional. Se hace mención en detalle lo siguiente:
Como resultado de las entrevistas ejecutadas se puede decir que TCS Ecuador opta por
el desarrollo de software bajo el modelo offShore para cumplir con los objetivos
estratégicos organizaciones y para facilitar el cumplimiento de los objetivos estratégicos
organizacionales del cliente. Por otro lado, el Ministerio de Salud Pública opta por el
desarrollo de proyectos inHouse para cumplir con los objetivos estratégicos alineados al
gobierno central.
3.2.3. Perspectiva del Cliente
Desde el punto de vista del cliente se verifica que ambas instituciones (MSP y TCS)
tienen claridad sobre la necesidad de satisfacer las altas expectativas que tienen los
clientes acerca de la ejecución de un determinado proyecto.
74
Hay que recalcar que independientemente del modelo de desarrollo de software utilizado
para la construcción de un determinado producto todos los entrevistados manifiestan
explícitamente que el trabajo del equipo está orientado a que los entregables del proyecto
tengan la calidad esperada y se alineen a los requerimientos levantados en su momento
por parte del cliente.
Uno de los entrevistados en relación con el modelo offShore afirma: “Todos los proyectos
que son ejecutados por TCS tienen la necesidad de satisfacer las altas expectativas
levantadas por nuestros clientes, tenemos una metodología que mide periódicamente
este índice con el fin de poder tomar las acciones correctivas necesarias permitiendo que
la estadística muestre niveles superiores al 90%”. (Entrevista 5, comunicación personal,
12 de abril de 2018)
Otro de los entrevistados menciona: “Contamos con un departamento llamando DEG
(Delivery Excelence Group) que se encarga de guiar a los proyectos de tal manera que
se pueda establecer un análisis causal cuando existen niveles de satisfacción de cliente
por debajo del 90% esto facilita aplicar acciones correctivas para llegar a cumplir la meta
corporativa”. (Entrevista 3, comunicación personal, 2 de abril de 2018)
Asimismo, uno de los entrevistados que labora con el modelo InHouse afirma: “Los
proyectos desarrollados por el MSP tienen el objetivo de satisfacer los requerimientos
levantados por direccione, coordinaciones zonales, o áreas internas, cada proyecto tiene
una prioridad de atención y está bajo el seguimiento de la DNTIC”. (Entrevista 11,
comunicación telefónica, 26 de abril de 2018)
3.2.4. Perspectiva del aprendizaje
Esta perspectiva analizada dentro del desarrollo de las entrevistas fue una de las que
generó mayor preocupación, debido a que existen diversos puntos de vista sobre como
los recursos deben tener un ciclo de capacitación continua, de tal manera que les permita
enfrentar los retos que se presentan con cada proyecto. A continuación, se exponen los
temas más relevantes.
Uno de los entrevistados que trabaja con el modelo inHouse afirma: “No tenemos un plan
de capacitación definido que nos permita afrontar el uso de nuevas tecnologías de
desarrollo de software, al momento existen en vigencia nuevas plataformas, pero no las
75
conocemos, no tenemos dominio sobre estas lo que genera la imposibilidad de poder
usar las mismas”. (Entrevista 6, comunicación personal, 12 de abril de 2018)
En el mismo sentido, uno de los entrevistados sobre el modelo OffShore menciona: “Acá
en TCS si bien existen un departamento de Learning nuestro sentir es que el presupuesto
no es focalizado a las áreas que requieren de una actualización de conocimientos, no es
lo mismo efectuar un entrenamiento vía online que uno presencial con instructor y
seguimiento, lo hemos manifestado en las distintas encuestas de clima laboral”.
(Entrevista 4, comunicación personal, 4 de abril de 2018)
Otro de ellos afirma: “Debería existir un plan de capacitación continuo que evolucione
directamente con las nuevas propuestas del mercado para plataformas de desarrollo, la
tecnología es cada vez más compacta y los procesos más simplificados, la inversión en
cualquier proceso de capacitación regresa como retorno al contar con personal
totalmente calificado y que asegure la calidad de los entregables”. (Entrevista 3,
comunicación personal, 2 de abril de 2018).
76
3.2.5. Análisis comparativo por perspectiva de las organizaciones estudiadas
3.2.5.1. Perspectiva Financiera
ASPECTOS SEMEJANZAS DIFERENCIAS
OffShore – TCS Ecuador InHouse - MSP
FIN
AN
CIE
RA
Reducción de Costos
Los proyectos, independientemente del modelo de desarrollo utilizado internamente, buscan reducir costos de tal manera que puedan generar un espacio donde puedan gestionar temas emergentes o inesperados. Sin embargo, muchas veces este intento no se materializa por atrasos imputados al proyecto.
TCS tiene una tarifa por el costo de recursos nacionales y extranjeros.
El costo de recursos locales está normado por la contratación y escalas salariales que determina el Ministerio de Relaciones Laborales.
Indicadores Financieros
Los índices financieros pueden ser obtenidos desde el Gantt del proyecto con mucha facilidad. Los entrevistados coinciden que se requiere entender claramente para que sirven y poder aplicarlos en la gestión de los proyectos.
El Índice de Desempeño del Cronograma (SPI) mide la eficiencia del trabajo y el progreso de un proyecto. Comparando el trabajo real realizado con el trabajo planeado del proyecto, en las entrevistas levantadas se muestran indicadores SPI menores a 1, lo que indica que el proyecto está retrasado.
Se evidencian índices SPI mayores o iguales a 1, lo que señala que el proyecto está ajustado al cronograma.
El índice de rendimiento de costos (CPI) es una relación que mide la eficacia financiera de un proyecto al dividir el costo presupuestado del trabajo realizado por el costo real del trabajo realizado. En este caso se evidencia que este indicador muestra valores menores a 1, lo que significa que el costo del proyecto está por encima del presupuesto.
Se evidencian índices SPI mayores o iguales a 1, lo que muestra que el proyecto está exactamente ajustado al presupuesto planificado. No obstante, existen casos reportados donde dicho índice no se ajusta.
77
3.2.5.2. Perspectiva de la estrategia organizacional
ASPECTOS SEMEJANZAS DIFERENCIAS
OffShore - TCS InHouse - MSP
ES
TR
AT
EG
IA O
RG
AN
IZA
CIO
NA
L
Cumplimiento de metas organizacionales.
Ambos modelos están orientados a cumplir las metas planteadas por la organización. Por un lado, TCS Ecuador desarrolla soluciones para un tercero en donde ayuda a cumplir las metas de sus clientes. Por otro lado, el MSP se orienta a sus direcciones internas beneficiarias de los proyectos de desarrollo.
El modelo offShore al tener un alcance mayor y global, desde el punto de vista corporativo, busca facilitar que las metas organizacionales de TCS Ecuador de expansión mundial se cumplan progresivamente. No se concibe una multinacional con alcance limitado y con trabajo específico de recursos locales.
Este modelo cuenta solamente con recursos locales. N busca una expansión multiplicativa. El rango de acción es local y específico para las necesidades internas propias de las direcciones del MSP.
Cumplimiento de objetivos organizacionales.
Los objetivos organizacionales de los clientes de TCS Ecuador y MSP deben ser cubiertos. Cada proyecto de desarrollo que fue planteado tiene que cubrir una necesidad ya sea normativa, estratégica o de crecimiento, por lo que los esfuerzos se enfocan en cubrir las necesidades del cliente.
El modelo offShore al tener un alcance mayor y global, desde el punto de vista corporativo, busca facilitar que los objetivos organizacionales de expansión de TCS Ecuador se cumplan progresivamente. No se concibe una multinacional con alcance limitado y con trabajo específico de recursos locales.
El cumplimiento de los objetivos organizacionales está alineado al objetivo de contar con un ministerio que brinde a sus usuarios una atención con calidad, utilizando herramientas tecnológicas que viabilicen este cometido. No existen planes de expansión, sino más bien de atención de la demanda.
78
3.2.5.3. Perspectiva del cliente
ASPECTOS SEMEJANZAS DIFERENCIAS
OffShore - TCS InHouse – MSP
CLIE
NT
E
Encuestas de Satisfacción del Cliente.
En ambas instituciones se busca tener una retroalimentación del cliente que sea lo más objetiva posible.
Se aplica una encuesta de satisfacción trimestral. Si los resultados del índice son menores al límite mínimo permitido (90%) se debe efectuar un análisis causal para determinar las acciones correctivas necesarias y así poder mejorar en la estadística.
No se cuenta con un instrumento documental claramente definido que permita determinar el índice de satisfacción del cliente.
Retroalimentación del cliente y lecciones aprendidas.
Ambas instituciones buscan tener una retroalimentación del cliente, que permita apreciar su sentir. Cada punto que sea levantado por este debe ser lo más claro posible, de tal manera que sea asimilado por las partes involucradas.
Existen documentos específicos y plantillas que permiten tomar la retroalimentación del cliente y tabularla. Existe el formato de lecciones aprendidas, donde se puede retroalimentar a todos los proyectos de ciertos eventos que puede darse y la forma en que deben ser administrados.
No se cuenta con un instrumento claramente definido que permita obtener retroalimentación del cliente y/o lecciones aprendidas.
79
3.2.5.4. Perspectiva del aprendizaje A
PR
EN
DIZ
AJE
ASPECTOS SEMEJANZAS DIFERENCIAS
OffShore - TCS InHouse – MSP
Programa de capacitación continua.
Para tener una participación activa en la ejecución de proyectos de desarrollo de software los desarrolladores deben estar correctamente capacitados.
Se cuenta con un programa de capacitación y desarrollo de competencias en plataformas virtuales provistas por la organización. Si bien los cursos no son presenciales logran exponer el principio fundamental del entrenamiento.
No se cuenta con ningún programa de capacitación formal, pero estas pueden darse por algún tipo de convenio con el proveedor, con otras instituciones gubernamentales o por iniciativas propias. Sin embargo, no es una constante.
Plan de capacitación acorde a nuevas tecnologías de desarrollo de software.
Los proyectos de desarrollo de software mantienen necesidad directa con las nuevas tecnologías que están disponibles en el mercado. Desde ese punto de vista existe la necesidad de contar con un plan que permita adoptar dichas tecnologías con el fin que sean consideradas en futuros desarrollos.
Existe un plan de capacitación que no necesariamente está focalizado en las áreas donde realmente existe la necesidad.
No existe una definición clara de adaptación de nuevas tecnologías de desarrollo de software.
Departamento de Learning encargado del proceso formal de capacitación.
Ambas instituciones remarcan la necesidad prioritaria de contar con un departamento que administre las necesidades de capacitación de todos los empleados y/o asociados.
Se cuenta con un departamento propio encargado de gestionar las capacitaciones obligatorias y necesarias por cada recurso, según el lineamiento corporativo.
No se cuenta con un departamento encargado de gestionar la capacitación de los empleados.
80
3.3. Modelo de evaluación de proyectos
Una vez analizados los datos de las encuestas, entrevistas y estadísticas de los
proyectos se identificó que las siguientes variables: esfuerzo (horas hombre), duración,
presupuesto asignado, número de desarrolladores, tipo de proyecto y tecnología
predominante influyen en los modelos de evaluación de proyectos. En base a estas
variables se ha desarrollado un software que ayuda a los gestores de proyectos a tomar
una decisión acertada del modelo de desarrollo a aplicarse en un proyecto.
El software desarrollado identifica, mediante puntuaciones, el mejor modelo para el
desarrollo de un proyecto. Las variables identificadas pueden ser parametrizadas de
acuerdo con los criterios de la organización. La Figura 37 muestra la pantalla principal del
software, donde se pueden ingresar los valores de las variables para procesar y mostrar
los resultados de evaluación de los modelos.
Figura 37 - Pantalla principal del modelo (Elaborado por los autores)
81
De acuerdo con los datos ingresados el modelo evalúa y muestra la puntuación para los
modelos offShore e inHouse. En la Figura 38 se observa el puntaje obtenido para cada
modelo una vez que se han ingresado los valores a las variables.
Figura 38 - Ingreso de los valores a evaluar en el modelo (Elaborado por los autores)
Dependiendo de los valores ingresados en las variables el software despliega un mensaje
en el que muestra el modelo por el que se debe realizar el desarrollo del proyecto de
software. En la Figura 39 se muestra el mensaje desplegado para los valores ingresados.
82
Figura 39 - Resultado de la evaluación en el modelo. (Elaborado por los autores).
La Figura 40 muestra las configuraciones del modelo, en el que se puede consultar y
editar los parámetros para las variables de esfuerzo, número de desarrolladores,
presupuesto, duración, tipo de proyecto y tecnología.
Figura 40 - Ingreso a la consulta de parámetros. (Elaborado por los autores).
83
La Figura 41 muestra la configuración del peso por modelo de desarrollo para la
variable esfuerzo.
Figura 41 - Consulta de parámetros de la variable esfuerzo. (Elaborado por los autores)
La Figura 42 muestra la configuración del peso por modelo de desarrollo para la
variable número de desarrolladores.
Figura 42 - Consulta de parámetros de la variable número de desarrolladores. (Elaborado por los autores)
84
La Figura 43 muestra la configuración del peso por modelo de desarrollo para la
variable presupuesto.
Figura 43 - Consulta de parámetros de la variable presupuesto. (Elaborado por los autores)
La Figura 44 muestra la configuración del peso por modelo de desarrollo para la
variable duración.
Figura 44 - Consulta de parámetros de la variable duración. (Elaborado por los autores)
La Figura 45 muestra la configuración del peso por modelo de desarrollo para la
variable tipo de proyecto.
85
Figura 45 - Consulta de parámetros de la variable tipo de proyecto. (Elaborado por los autores)
La Figura 46 muestra la configuración del peso por modelo de desarrollo para la variable
tipo de tecnología.
Figura 46 - Consulta de parámetros de la variable tipo de tecnología. (Elaborado por los autores)
Adicionalmente, se puede modificar los pesos asignados a las variables a través de la
edición del parámetro elegido. En la Figura 47 se puede observar la modificación al
parámetro PARA00003 (configuración para esfuerzo) y en el Figura 48 se muestra el
mensaje de que la actualización ha sido ejecutada correctamente.
86
Figura 47 - Modificación de parámetros para la variable esfuerzo. (Elaborado por los autores)
Figura 48 - Actualización de parámetros para la variable esfuerzo.
(Elaborado por los autores)
87
4. CONCLUSIONES Y RECOMENDACIONES
4.1. Conclusiones
Una vez concluido el presente trabajo de investigación listamos las conclusiones a las
cuales hemos llegado.
Desde la perspectiva financiera el modelo de desarrollo offShore muestra mayor
fortaleza, pues permite potenciar las capacidades instaladas de la multinacional
abaratando principalmente los costos de mano de obra. Por otro lado, los centros de
construcción de software ubicados en varias localidades a nivel mundial pueden
coordinarse entre sí y trabajar como una fábrica de software sin necesidad de
reubicar a sus desarrolladores en lugares donde se encuentra el cliente. Trabajan en
el desarrollo de un producto en forma modular y luego lo ensamblan para la entrega
del producto final.
Desde la perspectiva de la estrategia organizacional el modelo de desarrollo inHouse
demuestra tener mejores resultados a nivel interno de la organización pues permite
tener una comunicación más fluida entre los integrantes del equipo comunicarse en
un único idioma (español), como consecuencia de esto el entendimiento de los
requerimientos funcionales es más rápido. Por otro lado la dinámica y cultura
organizacional local fomenta un ambiente laboral agradable, las decisiones y planes
de acción relacionados a los proyectos se toman rápidamente a fin para cumplir los
objetivos planteados.
Desde la perspectiva de cliente ambos modelos de desarrollo de software intentan
llegar a satisfacer las expectativas de los clientes en relación al producto terminado
objetivo de ejecución del proyecto. Sin embargo, creemos que esta perspectiva más
bien debe ser analizada por institución y no por modelo. Habría que analizar
internamente en cada organización que se está haciendo para entender la voz del
cliente. Se ha observado que en el MSP la retroalimentación no es completa solo
está enfocado en un grupo base especifico, TCS tiene varias herramientas para
procesar dicha retroalimentación y se ha notado un proceso establecido de mejora
continua mucho más maduro con resultados que son medidos constantemente.
88
Desde la perspectiva de aprendizaje se determina que el modelo offShore presenta
mayores desafíos que el inHouse, el dominio de al menos un idioma extranjero es el
que representa mayor reto para todos los integrantes del proyecto y es considerado
fundamental debido a que este viabiliza el correcto entendimiento del equipo de
trabajo, desde el punto de vista técnico los desafíos no son menores: actualización
constante en nuevos lenguajes de programación, bases de datos y metodologías son
indispensables, las dos organizaciones estudiadas tienen un punto de mejora
importante para sus asociados en esta perspectiva.
Las variables técnicas que influyen fuertemente en los modelos de desarrollo de
proyectos son: tecnología de desarrollo de software y base de datos, claridad en los
requerimientos funcionales y técnicos y número de desarrolladores involucrados. Las
variables técnicas que no influyen son ambientes de despliegue del proyecto,
infraestructura relacionada y comunicaciones. Por otro lado, las variables no técnicas
que influyen en los modelos de desarrollo de proyectos son: presupuesto, duración,
tipo de proyecto y esfuerzo. Y las variables no técnicas que no influyen en los
modelos de desarrollo de proyectos son: cultura organizacional, costumbres y
religión.
El modelo de desarrollo de software offShore entrega mejores resultados cuando
existen factores que favorecen la ejecución del mismo. Entre estos:
El dominio del idioma inglés oral y escrito.
La aplicación se da a proyectos de tamaño mediano a grande
Los integrantes del equipo tienen posibilidad de trabajar en horario diferido en
concordancia con los centros offShore distribuidos a nivel mundial.
Se emplean tecnologías estándar de desarrollo a nivel mundial.
El alcance del proyecto modifica aplicativos con complejidad funcional media -
baja.
Los requerimientos están correctamente definidos y existe muy poca
probabilidad de ser cambiados por el cliente en el tiempo.
El modelo de desarrollo de software inHouse entrega mejores resultados cuando
existen factores que favorecen la ejecución del mismo. Entre estos:
89
La aplicación a proyectos de tamaño pequeño a mediano.
El alcance del proyecto modifica aplicativos con complejidad funcional media –
alta.
Se usan tecnologías de desarrollo específicas y de poco uso.
Los requerimientos tienen probabilidad de ser cambiados por influencias ajenas
al equipo técnico.
El modelo de desarrollo offShore es el modelo seleccionado por el Ministerio de
Salud Pública para ejecutar los proyectos de desarrollo de software. Dicho modelo se
encuentra totalmente adoptado por la organización y es parte de su metodología.
Con el pasar del tiempo todos los miembros de equipo han aprendido a explotar las
bondades de dicho modelo. Sin embargo, existe un número importante de puntos de
mejora que deberán ser analizados y de ser requerido debe plantearse un plan de
mejora.
La gestión interna de ingeniería de software que es la encargada del desarrollo de
software en la DNTIC del Ministerio de Salud Pública levanta constantemente el
riesgo de retraso en la liberación de los entregables de los proyectos desarrollados
pues aducen principalmente que los requerimientos funcionales cambian
constantemente, por lo cual no es posible mantener un alcance establecido. Sin
embargo, es importante resaltar que al ser esta una variable ajena al modelo
(cambios de alcance) no se puede concluir que el modelo funciona inadecuadamente
en la mencionada institución.
Las instituciones públicas como el MSP, al ser parte del gobierno, se ven
influenciadas por variables externas a la de administración del proyecto, Ejemplos de
esto son la influencia política o la priorización ministerial, las cuales pueden tener un
efecto negativo en la ejecución de los proyectos, cambiando el alcance y por ende
generando un impacto a nivel de duración y esfuerzo.
En el MSP, el índice de satisfacción del cliente no está correctamente enfocado y
actualmente no se obtiene una retroalimentación adecuada que posibilite realizar
mejoras en los proyectos. Los usuarios funcionales asignados a los proyectos de
desarrollo pertenecen a la planta central, y son los únicos que evalúan este índice de
satisfacción. No se toma en cuenta a los usuarios que se encuentran desplazados en
90
las instituciones de salud a nivel nacional que diariamente usan los aplicativos
desarrollados, por lo que se pierden opiniones valiosas que aportarían en la mejora
de los productos.
No se puede afirmar que un modelo de desarrollo de software sea mejor que otro.
Los modelos de desarrollo de software: offShore e inHouse presentan ventajas y
desventajas en su implementación. Uno u otro entregan mejores resultados cuando
existen factores que favorecen su ejecución. Su elección dependerá de las
necesidades de la organización y a su vez de las circunstancias en las que se desea
desarrollar. Sin embargo, su correcta ejecución será fundamental en el éxito o
fracaso del proyecto.
Dentro del proceso de ejecución del presente trabajo de investigación, y cumpliendo
con uno de sus objetivos específicos, se desarrolló un software que permite evaluar
un determinado proyecto tomando en cuenta las principales variables que fueron
identificadas en el proceso de encuestas, entrevistas y análisis de las estadísticas de
proyectos Estas son: esfuerzo (horas), duración (días), presupuesto (dólares),
número de desarrolladores, tipo de proyecto y tecnología de desarrollo de software.
Entonces, aplicando un algoritmo basado en los pesos de cada variable se puede
obtener una conclusión de cual modelo de desarrollo de software es el recomendable
para ejecutar un proyecto.
El algoritmo de evaluación de proyectos puede ser afinado por medio de un conjunto
de parámetros que se aplican sobre las variables antes mencionadas (esfuerzo,
duración, presupuesto, número de desarrolladores, tipo de proyecto y tecnología). Es
decir, conforme se requiera mayor grado de exactitud se pueden colocar más y
mejores rangos de evaluación con sus pesos respectivos.
4.2. Recomendaciones
Para elegir un modelo de desarrollo de software se debe considerar ciertas variables
en las cuales el modelo offShore e inHouse son sensibles. El modelo que mejor se
acople a cada organización y a su estrategia empresarial, más la valoración del
software de evaluación de proyectos, son los inputs que se recomiendan sean
utilizados
91
La correcta selección de un modelo de desarrollo de software puede ser una ventaja
competitiva para la organización y/o departamentos beneficiarios de la ejecución del
proyecto. Por esta razón, se recomienda efectuar un análisis que incluya revisión de
las ventajas, desventajas, riesgos y mitigación, para de esta manera sustentar
adecuadamente la elección.
Se recomienda establecer mediciones periódicas que permitan evidenciar la
satisfacción que el cliente va reportando durante la ejecución del proyecto. Esto
permitirá determinar si los entregables van cumpliendo con las necesidades
planteadas inicialmente.
Se recomienda efectuar un ciclo de capacitación en idioma extranjero
específicamente “inglés”, que permita a todos los asociados de TCS interactuar más
fluidamente con sus pares extranjeros.
Se recomienda acordar cual es el mejor horario para atender reuniones coordinadas
con aquellos equipos técnicos de TCS que se encuentran en localidades extranjeras.
Se debe definir cuál es la prioridad de atención, legislación local y demás factores
que pueden influir en costos adicionales.
92
REFERENCIAS BIBLIOGRÁFICAS
Acebo, M., & Nuñez, A. (Enero de 2017). Estudios Industriales Orientación Estratégica
para la toma de decisiones. ESPAE. Obtenido de
http://www.espae.espol.edu.ec/wp-content/uploads/2016/12/industriasoftware.pdf
Asociación Ecuatoriana de Software AESOF. (Septiembre de 2011). Estudio de Mercado
del Sector Software y Hardware en Ecuador. Obtenido de
https://es.slideshare.net/AESOFT/ot-20489-microsoftfolleto
Avilés, E. (Sin fecha). Ministerio de Salud Pública. Enciclopedia del Ecuador. Obtenido de
http://www.enciclopediadelecuador.com/historia-del-ecuador/ministerio-salud-
publica/
Cortés, R. (1998). Introducción al análisis de sistemas y las ingeniería de software.
EUNED.
Crespo, S. P. (2008). Nuevas Tecnologias, Nuevos Empleos y Nuevas Organiaciones.
Barcelona: Ariel S.A.
De Pablos, C., López, J., Romo, S., & Medina, S. (2011). Organización y transformación
de los sistemas de información en la empresa. Madrid: ESIC.
Del Peso, E. (2003). Manual de outsourcing informático (2 ed.). Madrid: Edigrafos S. A.
Drtina, R. E. (1994). The Outsourcing Decision: Seize the Opportunity to Focus on
Activities that Give Your Company the Competitive Edge (Vol. 75). Managment
Accounting.
Fórneas, J. (2008). Outsourcing.: Saque el máximo partido de sus proveedores. Madrid:
Netbiblo, S.L.
Garrido Carrillo, A. (2006). Fundamentos de Programación en C++. Madrid: Delta
Publicaciones, S.L.
González, M., Llopis, J., & Garcó, J. (2006). El offShore outsourcing de sistemas de
información. Universia Business Review, 80-91.
Hernández , R., Fernández, C., & Baptista, L. (2010). Metodologia de la Investigación.
Mexico DF: McGraw Hill.
Maldonado, F., Proaño, G., & Ekos, E. (Junio de 2015). Grandes Empleadores Top 250.
EKOSNEGOCIOS.COM. Obtenido de
http://www.ekosnegocios.com/revista/pdfTemas/1241.pdf
Ministerio de Salud Pública. (Octubre de 2012). Políticas de la Gestión Interna de
Ingeniería de Software. Obtenido de
93
http://instituciones.msp.gob.ec/images/Documentos/Ministerio/tic/Politica_Coordin
acion_Ingenieria_Software.pdf
Murillo, J. (s.f.). Estudio de casos. Obtenido de
https://www.uam.es/personal_pdi/stmaria/jmurillo/InvestigacionEE/Presentaciones/
Curso_10/EstCasos_Trabajo.pdf
Noriega, R. (2017). El proceso de desarrollo de software (2da ed.). IT Campus Academy.
Observatorio TIC. (2016). Empresas Sector Tic. Empleo, Remuneración y Ventas.
Obtenido de https://observatoriotic.mintel.gob.ec/estadistica/
Observatorio TIC. (2016). Información relacionada al empleo, remuneraciones y ventas
de las empresas TIC ecuatorianas. Obtenido de
https://observatoriotic.mintel.gob.ec/estadistica/index.html
Oficina Comercial de ProChile en Ecuador. (2012). Estudio de Mercado Servicio
Desarrollo de Software en Ecuador. Asexma Chile exportador. Obtenido de
http://asexma.cl/wp-content/uploads/2013/04/Ecuador-Software.pdf
Pressman, R. (2006). Ingeniería del software. Un enfoque práctico. México: McGraw-Hi.
Reponen. (1993). OutSourcing or InSourcing. International Conference on Information
Systems.
Sampieri, R. H. (2010). Metodologia de la Investigación. Mexico D: McGraw Hill.
Secretaría de Educación Superior, Ciencia, Tecnología e Innovación SENESCYT. (2015).
Obtenido de http://www.educacionsuperior.gob.ec/
Sommervile, I. (2005). Ingeniería del Software. Madrid: Pearson Addison Wesley.
Super Intendencia de Compañias. (2017). Portal de Información/Sector Societario.
Obtenido de
http://appscvs.supercias.gob.ec/portalInformacion/sector_societario.zul
Tata Consultancy Service. (2010 - 2018). Ecuador. Obtenido de
http://worldwide.tcs.com/worldwide/es/es/ecuador/Pages/default.aspx
Time of Software. (2016). Entiende el Desarrollo Global de Software. . Obtenido de
http://timeofsoftware.com/desarrollo-global-de-software/
94
GLOSARIO
Software a medida, es aquel que se diseña, a la medida del usuario, de la empresa y de
su forma de trabajar. Es decir, busca complacer todas las necesidades y adaptarse lo
mejor posible a lo que una empresa necesita.
Software estándar o "enlatado", es un software genérico, que resuelve múltiples
necesidades, y la empresa probablemente sólo empleará algunas. En general, es un
software que no se adapta completamente al vocabulario, necesidades y funciones que
necesita la empresa.
Requerimiento funcional, es una condición o necesidad de un usuario para resolver un
problema o alcanzar un objetivo.
Business Process Outsourcing o externalización de procesos de negocio es
la subcontratación de funciones del proceso de negocio en proveedores de servicios, ya
sean internos o externos a la empresa.
Six Sigma, es un método, basado en datos, para llevar la calidad hasta niveles próximos
a la perfección, diferente de otros enfoques ya que también corrige los problemas antes
de que se presenten.
95
ANEXOS
96
Anexo I - Formato de entrevista sobre el modelo offShore
FORMATO DE ENTREVISTA
Objetivo: Identificar en los entrevistados las concepciones que expresan sobre el modelo inHouse
en el desarrollo de software desde las perspectivas financiera, estructura organizacional, cliente y
aprendizaje.
Perspectiva Pregunta
Financiera
1. Describa sus impresiones acerca del presupuesto financiero utilizado para
el desarrollo de proyectos modelo offShore, lo percibe como más costoso
en relación al modelo inHouse.
2. ¿Cree usted que el modelo offShore de desarrollo de software permite
optimizar el uso de recursos financieros?
3. ¿Cree usted que el modelo offShore de desarrollo de software genera
rentabilidad para la organización/áreas?
4. ¿Cree usted que el modelo offShore de desarrollo de software permite tener
un control más estricto de los índices financieros?
5. ¿Percibe que al tener la organización un modelo de desarrollo de software
offShore aumentarán las ventas e ingresos por ejecución de proyectos?
6. ¿Cree usted que el modelo offShore propicia una mayor participación de
mercado de la organización?
7. ¿Cree usted que los productos desarrollados bajo modelo offShore son
percibidos con mayor costo de mantenimiento vs un modelo de desarrollo
inHouse?
De la
estrategia
Organizacional
1. ¿Cree usted que el modelo offShore viabiliza la apertura para desarrollar
nuevos productos de software?
2. ¿Cree usted que el modelo offShore viabiliza la apertura para innovar
productos de software?
3. ¿Cree usted que el modelo offShore viabiliza la apertura para mejorar la
velocidad de mercadeo de productos de software?
4. ¿Cree usted que el software desarrollado bajo el modelo offShore facilita a
la organización cumplir sus objetivos estratégicos?
5. ¿Cree usted que el software desarrollado bajo el modelo offShore facilita la
proyección de la empresa hacia el futuro con crecimiento constante?
97
Cliente
Cliente
1. ¿Cree usted que los productos desarrollados con el modelo inHouse son
percibidos por el cliente como de mejor calidad vs otros modelos de
desarrollo que usted conozca?
2. ¿Cree usted que los productos desarrollados con el modelo offShore son
percibidos por el cliente con entrega tardía vs otros modelos que usted
conozca?
3. ¿Cree usted que los productos desarrollados con el modelo offShore son
percibidos por el cliente con menor tiempo de vida útil?
4. ¿Cree usted que los productos desarrollados con el modelo offShore son
percibidos por el cliente con mayor incidencia de defectos post producción?
5. ¿Cree usted que los productos desarrollados con el modelo offShore son
percibidos con mayores problemas en su etapa de certificación vs otros
modelos que usted conozca?
Aprendizaje
1. ¿Cree usted que los recursos offShore utilizados en proyectos de desarrollo
están capacitados acorde a la necesidad de la organización?
2. ¿Piensa usted que si existen dificultades técnicas en el proyecto estas se
relacionan con la formación académica de los recursos asignados?
3. ¿Cree usted que el dominio de otro idioma extranjero puede viabilizar de
mejor manera la ejecución de un proyecto de desarrollo de software?
4. ¿Cree usted que el tener un título de tercer y cuarto nivel viabiliza de mejor
manera la ejecución de un proyecto de desarrollo de software?
98
Anexo II - Formato de entrevista sobre el modelo inHouse
FORMATO DE ENTREVISTA
Objetivo: Identificar en los entrevistados las concepciones que expresan sobre el modelo inHouse
en el desarrollo de software desde las perspectivas financiera, estructura organizacional, cliente y
aprendizaje.
Perspectiva Pregunta
Financiera
1. Describa sus impresiones acerca del presupuesto financiero utilizado para
el desarrollo de proyectos modelo inHouse, lo percibe como costoso en
relación a otros modelos.
2. ¿Cree que el modelo inHouse de desarrollo de software permite optimizar
el uso de recursos financieros?
3. ¿Cree usted que el modelo inHouse de desarrollo de software genera
beneficios para la organización?
4. ¿Cree usted que el desarrollo de proyectos de software realizados bajo el
modelo inHouse permite tener un control más estricto de los índices
financieros del proyecto?
5. ¿Cree usted que el modelo de desarrollo inHouse permite tener una
mayor participación de mercado de la organización en el mercado global
de servicios de software?
6. ¿Cree usted que los productos desarrollados bajo modelo inHouse son
percibidos con mayor costo de mantenimiento respecto a un modelo de
desarrollo offShore?
De la estrategia
Organizacional
1. ¿Cree usted que el modelo de desarrollo inHouse permite tener mayor
flexibilidad en el desarrollo de nuevos productos de software?
2. ¿Cree usted que el modelo inHouse permite mejorar la velocidad de
adopción de productos de software en la organización?
3. ¿Cree usted que el desarrollo de proyectos de software en modelo
inHouse permite y/o facilita a la organización cumplir sus objetivos
estratégicos? ¿Porque?
4. ¿Cree usted que el modelo de desarrollo inHouse facilita la proyección de
la empresa hacia el futuro con crecimiento constante?
1. ¿Cree usted que los productos desarrollados con el modelo inHouse son
percibidos por el cliente como de mejor calidad vs otros modelos de
desarrollo que usted conozca?
2. ¿Cree usted que los productos desarrollados con el modelo inHouse son
percibidos por el cliente con entrega tardía vs otros modelos de desarrollo
que usted conozca?
99
Cliente
3. ¿Cree usted que los productos desarrollados con el modelo inHouse son
percibidos por el cliente con menor tiempo de uso práctico vs otros
modelos de desarrollo que usted conozca?
4. ¿Cree usted que los productos desarrollados bajo el modelo inHouse son
percibidos con mayores defectos vs otros modelos de desarrollo que
usted conozca?
5. ¿Cree usted que los productos desarrollados con el modelo inHouse son
percibidos con mayores defectos en su construcción vs otros modelos de
desarrollo que usted conozca?
Aprendizaje
1. ¿Cree usted que las personas encargadas del desarrollo de productos
bajo el modelo inHouse están capacitados y/o entrenados acorde a la
necesidad de la organización?
2. ¿Cree usted que las dificultades técnicas en el caso que se presenten en
el desarrollo del proyecto de software están relacionadas con la formación
académica de los recursos asignados?
3. ¿Cree usted que el dominio de otro idioma en el desarrollador de
productos de software puede viabilizar de mejor manera la ejecución de
un proyecto de desarrollo de software?
4. ¿Cree usted que el tener un título de tercer y cuarto nivel viabiliza de
mejor manera la ejecución de un proyecto de desarrollo de software?
100
Anexo III - Formato de encuesta sobre el modelo offShore
ENCUESTA
Estimad@, estamos realizando una investigación de carácter académico con el objetivo
de comparar el desarrollo de proyectos de software bajo el modelo inHouse con
el modelo offShore. Solicitamos su gentil ayuda llenando la presente encuesta. La
información se usará con absoluta confidencialidad y es anónima. Agradecemos
mucho por el tiempo prestado.
1. Seleccione los principales criterios que se toman en cuenta para la selección del
modelo de desarrollo de software offShore en un determinado proyecto.
a. Presupuesto asignado.
b. Duración del proyecto (meses)
c. Tamaño del proyecto (pequeño – grande – mediano)
d. Tecnologías de desarrollo involucradas
e. Experiencia de los integrantes del equipo de trabajo
2. ¿Cómo fue la experiencia de trabajar con un proyecto de desarrollo de software bajo
el modelo offShore desde el punto de vista de gerenciamiento del proyecto?
a. Buena
b. Mala
c. Ni buena ni mala
Porque: _____________________________________________________________
____________________________________________________________________
3. Seleccione el índice de satisfacción de los clientes al tener un producto desarrollado
bajo el modelo offShore.
a. Entre 0 y 50%
b. Entre 51% y 75%
c. Entre 76% y 90%
d. Entre 91% y 100%
4. ¿De su participación en proyectos desarrollados bajo el modelo offShore en general
hubo optimización de recursos (gasto menos de lo planificado)?
a. Si
b. No
5. ¿De su participación en proyectos desarrollados bajo con modelo offShore en
general hubo atrasos en el proceso de construcción de la solución
tecnológica?
a. Si
b. No
101
6. ¿En relación al modelo de predicción Rayleigh utilizado por la corporación, el número
de defectos reales que fueron levantados en la etapa de pruebas y
certificación para proyectos desarrollados bajo modalidad offShore fueron?
a. Mayor a la cantidad esperada
b. Menor a la cantidad esperada
7. ¿En promedio cuantos controles de cambios fueron levantados dentro de la
ejecución de los proyectos desarrollados bajo el modelo offShore?
a. Uno
b. Dos
c. Tres
d. Más de tres
e. Ninguno
8. ¿Se levantó algún riesgo asociado al uso del modelo de desarrollo offShore?
a. Si
b. No
En caso de escoger Si a la respuesta indique cuál fue el/los riesgos levantados:
___________________________________________________________________
___________________________________________________________________
9. ¿Indique el nivel del manejo de lengua extranjera (inglés) requerido para proyectos
con modelo offShore?
a. Entre 0 y 50%
b. Entre 50% y 75%
c. Entre 75% y 100%
10. ¿Existieron barreras culturales que dificultaron la iteración con los desarrolladores
extranjeros?
a. Si
b. No
En caso de escoger Si a la respuesta marque con una X indicando cuáles:
Religiosas
Idioma
Étnicas
Costumbres
11. ¿Existieron eventos de entendimiento incorrecto de los requerimientos funcionales y
técnicos aducidos al idioma y/o cultura de los desarrolladores?
a. Si
b. No
102
12. ¿Existieron problemas con el manejo de franjas horarias que dificultaron la ejecución
del proyecto?
a. Si
b. No
13. ¿Indique el número de desarrolladores promedio asignados a un proyecto de tipo offShore?
a. De 1 a 3
b. De 4 a 5
c. De 6 a 8
d. Más de 8
14. Si podría catalogar en una franja de evaluación el conocimiento técnico de los desarrolladores offShore cual escogería:
a. Bajo
b. Bajo - Medio
c. Medio
d. Medio – Alto
103
Anexo IV - Formato de encuesta sobre el modelo inHouse.
ENCUESTA
Estimad@, estamos realizando una investigación de carácter académico con el objetivo
de comparar el desarrollo de proyectos de software bajo el modelo inHouse con el
modelo offShore. Solicitamos su gentil ayuda llenando la presente encuesta. La
información se usará con absoluta confidencialidad y es anónima. Agradecemos mucho
por el tiempo prestado.
1. Seleccione los principales criterios que se toman en cuenta para la selección del
modelo de desarrollo de software inHouse en un determinado proyecto.
a. Presupuesto asignado.
b. Duración del proyecto (meses)
c. Tamaño del proyecto (pequeño – grande – mediano)
d. Tecnologías de desarrollo involucradas
e. Experiencia de los integrantes del equipo de trabajo
f. Normativa gubernamental
2. ¿Cómo fue la experiencia de trabajar con un proyecto de desarrollo de software bajo
el modelo inHouse desde el punto de vista de gerenciamiento del proyecto?
a. Buena
b. Mala
c. Ni buena ni mala
Porque: _____________________________________________________________
3. Seleccione el índice de satisfacción de los clientes al tener un producto desarrollado
bajo el modelo inHouse.
a. Entre 0 y 50%
b. Entre 51% y 75%
c. Entre 76% y 90%
d. Entre 91% y 100%
4. ¿De su participación en proyectos desarrollados bajo el modelo inHouse en general
hubo optimización de recursos (gastó menos de lo planificado)?
a. Si
b. No
5. ¿De su participación en proyectos desarrollados bajo el modelo inHouse en general
hubo atrasos en el proceso de construcción de la solución tecnológica?
a. Si
b. No
104
6. Los defectos encontrados en la etapa de pruebas y certificación fueron:
a. Mayor a la cantidad esperada
b. Menor a la cantidad esperada
7. ¿En promedio cuantos alcances al requerimiento fueron realizados en la ejecución
de los proyectos desarrollados bajo el modelo inHouse?
a. Uno
b. Dos
c. Tres
d. Más de tres.
e. Ninguno
8. ¿Se levantó algún riesgo asociado al uso del modelo de desarrollo inHouse?
a. Si
b. No
En caso de escoger Si a la respuesta indique cuál fue el/los riesgos levantados.
_________________________________________________________________
_________________________________________________________________
9. ¿Indique el nivel del manejo de lengua extranjera (inglés) requerido para proyectos
desarrollados bajo el modelo inHouse?
a. Entre 0 y 50%
b. Entre 50% y 75%
c. Entre 75% y 100%
10. ¿Existen barreras culturales que dificultan la iteración con los desarrolladores
locales?
a. Si
b. No
En caso de escoger Si a la respuesta marque con una X indicando cuáles.
Religiosas
Idioma
Étnicas
Costumbres
11. ¿Existieron eventos de entendimiento incorrecto de los requerimientos funcionales y
técnicos aducidos al idioma y/o cultura de los desarrolladores?
a. Si
b. No
105
12. ¿Existieron problemas con sobretiempos no planificados en la ejecución del
proyecto?
a. Si
b. No
13. ¿Indique el número de desarrolladores promedio asignados a un proyecto de tipo inHouse?
a. De 1 a 3
b. De 4 a 5
c. De 6 a 8
d. Más de 8
14. Si podría catalogar en una franja de evaluación el conocimiento técnico de los desarrolladores asignados a los proyectos cual escogería.
a. Bajo
b. Bajo - Medio
c. Medio
d. Medio – Alto
106
Anexo V - Tabulaciones de la encuesta sobre el modelo offShore. Pregunta 1 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Presupuesto asignado 1 1 1 1 1 1 1
Duración del proyecto (meses) 1 1 1 1
Tamaño del proyecto ( pequeño – grande – mediano)
1 1 1 1 1 1
Tecnologías de desarrollo involucradas 1 1 1 1 1
Experiencia de los integrantes del equipo de trabajo
1 1 1 1
Pregunta 2 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Buena 1 1
Mala 1 1 1 1
Ni buena ni mala 1 1 1 1 1
Pregunta 3 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Entre 0 y 50% 1 1
Entre 51% y 75% 1 1 1 1
Entre 76% y 90% 1 1 1 1 1
Entre 91% y 100%
Pregunta 4 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Si
No 1 1 1 1 1 1 1 1 1 1 1
Pregunta 5 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Si 1 1 1 1 1 1 1 1 1
No 1 1
Pregunta 6 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Mayor a la cantidad esperada 1 1 1 1 1 1 1 1 1
Menor a la cantidad esperada 1 1
Pregunta 7 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Uno 1
Dos
Tres
Más de tres 1 1 1 1
Ninguno 1 1 1 1 1 1
Pregunta 8 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Si 1 1 1
No 1 1 1 1 1 1 1 1
Pregunta 9 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Entre 0 y 50% 1
Entre 50% y 75% 1
Entre 75% y 100% 1 1 1 1 1 1 1 1 1
Pregunta 10 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Si 1 1 1 1 1 1 1 1 1
No 1 1
Pregunta 11 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Si 1 1 1 1 1 1 1 1 1 1 1
No
Pregunta 12 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Si 1 1 1 1 1 1 1 1 1 1
No 1
Pregunta 13 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
De 1 a 3 1 1 1 1 1 1 1 1 1
De 4 a 5 1 1
De 6 a 8
Más de 8
Pregunta 14 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
Bajo 1 1 1 1 1 1 1 1
Bajo - Medio 1 1 1
Medio
Medio – Alto
107
Anexo VI - Tabulaciones de la encuesta sobre el modelo inHouse.
Pregunta 1 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Presupuesto asignado 1 1 1 1 1
Duración del proyecto (meses) 1 1
Tamaño del proyecto ( pequeño – grande – mediano)
1 1 1 1 1 1
Tecnologías de desarrollo involucradas 1 1 1
Experiencia de los integrantes del equipo de trabajo
1 1 1 1 1 1
Normativa Gubernamental 1 1 1 1 1 1
Pregunta 2 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Buena 1 1 1
Mala 1 1
Ni buena ni mala 1 1 1 1 1
Pregunta 3 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Entre 0 y 50% 1 1 1
Entre 51% y 75% 1 1 1 1
Entre 76% y 90% 1
Entre 91% y 100% 1 1
Pregunta 4 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Si 1 1 1 1 1 1 1
No 1 1 1
Pregunta 5 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Si 1 1 1 1 1 1 1 1 1 1
No
Pregunta 6 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Mayor a la cantidad esperada 1 1 1 1 1 1
Menor a la cantidad esperada 1 1 1 1
Pregunta 7 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Uno 1
Dos 1 1
Tres 1 1
Más de tres 1 1 1 1 1
Ninguno
Pregunta 8 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Si 1 1 1 1 1 1
No 1 1 1 1
Pregunta 9 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Entre 0 y 50% 1 1 1 1 1 1
Entre 50% y 75% 1 1 1 1
Entre 75% y 100%
Pregunta 10 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Si
No 1 1 1 1 1 1 1 1 1 1
Pregunta 11 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Si
No 1 1 1 1 1 1 1 1 1 1
Pregunta 12 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Si 1 1 1 1 1 1 1 1 1
No 1
Pregunta 13 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
De 1 a 3 1 1 1
De 4 a 5 1 1 1
De 6 a 8
Más de 8 1 1 1 1
Pregunta 14 E1 E2 E3 E4 E5 E6 E7 E8 E9 E10
Bajo
Bajo - Medio 1 1
Medio 1 1 1
Medio – Alto 1 1 1 1 1