instituto politÉcnico nacional · 2019. 1. 25. · modelo de planificación de procesos...

INSTITUTO POLITÉCNICO NACIONAL

CENTRO DE INVESTIGACIÓN EN COMPUTACIÓN

“Modelo de mejora de procesos basado en la

implementación de la estrategia CRM y la

metodología SCRUM (MOPICS). Caso de

estudio: Sector Consultoría en Tecnologías de la

Información como Outsourcing”

TESIS

QUE PARA OBTENER EL GRADO DE

MAESTRÍA EN CIENCIAS DE LA COMPUTACIÓN

PRESENTA:

ING. DIANA BELEM ROMERO RUÍZ.

DIRECTORA DE TESIS:

DRA. SANDRA DINORA ORANTES JIMÉNEZ.

CIUDAD DE MÉXICO DICIEMBRE 2017

Modelo de planificación de procesos involucrados en la implementación de un software incluyendo CRM. Caso de estudio: Sector

Consultoría en Tecnologías de la Información como Outsourcing.

1

Resumen

En los últimos años, el crecimiento del desarrollo de software se está convirtiendo en

una necesidad para las empresas, ya que se encarga de desarrollar productos y servicios a

bajo costo al sistematizar procesos. Debido a ello, han surgido una gran variedad de

metodologías, modelos, procedimientos y herramientas, que brindan productividad y

calidad; a través de las cuales, se promueve el uso de las buenas prácticas de la Ingeniería

de Software, que abordan marcos de trabajo enfocados al ciclo de vida del software,

abarcando la captura de requerimientos, diseño, desarrollo, prueba, implantación y

mantenimiento.

Entre las metodologías que más se están usando hoy en día se encuentran las ágiles, de las

cuales se pueden mencionar: SCRUM, XP, Six Sigma, y Kanban, entre otras; sin embargo,

debido a considerarse su adopción una tarea engorrosa, esto da como resultado que las

organizaciones las empleen empíricamente y en algunas ocasiones, por desconocimiento,

no se siguen ni los principios marcados en el manifiesto ágil.

Por consiguiente, con esta investigación se propone un modelo de desarrollo de software

iterativo para outsourcing llamado MOPICS (MOdelo de mejora de Procesos basado en la

Implementación de la estrategia CRM y la metodología SCRUM), que toma como

fundamento buenas prácticas de desarrollo, destacando la metodología ágil SCRUM y la

estrategia CRM (Gestión de las Relaciones con los Clientes), que en conjunto apoyan al

flujo de información a llegar a todos los miembros de la organización y optimizar procesos

para así crear productos de calidad.



2

Abstract

In recent years, the growth of software development is becoming a necessity for

companies, which is responsible for developing products and services at low cost by

systematizing processes. Due to this, a great variety of methodologies, models, procedures

and tools have emerged, which provide productivity and quality; through which, the use of

good practices of Software Engineering is promoted, which adopt frameworks focused on

the software life cycle, covering the capture of requirements, design, development, testing,

implementation and maintenance.

Nowadays, the most used methodologies are the agile, of which we can mention: SCRUM,

XP, Six Sigma, Kanban, and others; However, because its adoption is complicated, the

result that the organizations were considered empirically and in some cases, due to

ignorance, was not maintained nor the principles indicated in the agile manifesto.

Therefore, this research proposes an iterative software development model for outsourcing

called MOPICS (Process Improvement Model based on the Implementation of the CRM

strategy and the SCRUM methodology). MOPICS takes as a basis, good development

practices, highlighting the SCRUM methodology and the CRM strategy (Customer

Relationship Management), which together supports the flow of information to reach all

members of the organization and thus induce deliverables of quality.



3

Agradecimientos

Al Instituto Politécnico Nacional (IPN), alma mater que ha permitido formarme

profesionalmente, sintiéndome orgullosa de ser parte ella.

Al Centro de Investigación en Computación (CIC), por haberme brindado los

conocimientos y formación de alto nivel.

Al Consejo Nacional de Ciencia y Tecnología (CONACyT), por el apoyo económico

otorgado.

A mi asesora la Dra. Sandra Dinora Orantes Jiménez, que gracias a los conocimientos

compartidos y consejos, me ha guiado en mi trabajo de tesis.

A mis sinodales, por sus observaciones y recomendaciones que ayudaron a mejorar mi

trabajo de tesis. En especial a la Dra. Graciela Vázquez Álvarez, por sus sabios consejos

que me han impulsado a cambiar aspectos personales y profesionales.

A mi padre Tomás, por su apoyo incondicional que me motiva a ser mejor persona cada día

y a superarme profesionalmente.

A mi mama Mary, que siempre está al pendiente de todo y por su comprensión que me

alientan a seguir adelante.

A mi novio, que me anima y motiva para cumplir mis metas.

A mis amigos y compañeros de generación que conocí a través de mi estancia en el centro,

con los que compartí conocimientos y momentos únicos.



4

Índice

Resumen ............................................................................................................................................. 1

Abstract .............................................................................................................................................. 2

Agradecimientos ................................................................................................................................ 3

Lista de figuras .................................................................................................................................. 7

Lista de tablas .................................................................................................................................... 8

Capítulo 1. Introducción ................................................................................................................. 17

1.1. Antecedentes .................................................................................................................... 17

1.2. Planteamiento del problema ........................................................................................... 17

1.3. Objetivos de la tesis ......................................................................................................... 18

1.4. Justificación ..................................................................................................................... 19

1.5. Beneficios esperados ........................................................................................................ 20

1.6. Alcances y limitaciones ................................................................................................... 20

1.7. Organización de la tesis .................................................................................................. 21

Capítulo 2. Marco teórico y estado del arte. ................................................................................. 24

2.1. Customer Relationship Management (CRM) ............................................................... 24

2.1.1. Ecosistema CRM ..................................................................................................... 25

2.1.2. CRM analítico .......................................................................................................... 25

2.1.3. CRM operacional .................................................................................................... 26

2.1.4. CRM colaborativo ................................................................................................... 26

2.1.5. CRM estándar ......................................................................................................... 26

2.2. Metodologías ágiles ......................................................................................................... 27

2.2.1. Manifiesto ágil ......................................................................................................... 27

2.2.2. Beneficios de usar metodologías ágiles .................................................................. 28

2.2.3. Comparativa de metodologías ágiles ..................................................................... 30

2.2.4. SCRUM .................................................................................................................... 32

2.3. Estado del Arte ................................................................................................................ 35

2.4. Resumen ........................................................................................................................... 40

Capítulo 3. Descripción MOPICS .................................................................................................. 42

3.1. Introducción .......................................................................................................................... 42



5

3.2. Diseño de MOPICS (MOdelo de mejora de Procesos basado en la Implementación de la

estrategia CRM y la metodología SCRUM) .............................................................................. 42

3.3. Características del modelo ................................................................................................... 43

3.4. Roles ...................................................................................................................................... 44

3.5. Descripción de las etapas para la implementación de MOPICS ...................................... 45

3.5.1. Etapa cero (Diagnóstico organizacional) .................................................................... 46

3.5.2. Etapa uno (Plan de desarrollo)..................................................................................... 49

3.5.3. Etapa dos (Implementación) ........................................................................................ 51

3.5.4. Etapa tres (Entrega de valor y liberaciones) ............................................................... 52

3.5.5. Etapa cuatro (Satisfacción del cliente) ........................................................................ 54

3.6. Resumen ................................................................................................................................ 55

Capítulo 4. Caso Práctico ............................................................................................................... 58

4.1. Introducción .......................................................................................................................... 58

4.2. Descripción de empresas participantes .............................................................................. 58

4.2.1. Empresa de consultoría y desarrollo de software (proveedor).................................. 58

4.2.2. Descripción de la Empresa cliente ............................................................................... 58

4.3. Actividades y tareas de MOPICS ....................................................................................... 59

4.4 Evaluación de MOPICS ........................................................................................................ 71

Capítulo 5. Conclusiones y trabajos a futuro................................................................................ 78

5.1. Cumplimiento de objetivos .................................................................................................. 78

5.2. Beneficios logrados ............................................................................................................... 80

5.3. Evaluación de la calidad ...................................................................................................... 81

5.4. Aportaciones ......................................................................................................................... 82

5.5. Divulgación de la investigación ........................................................................................... 84

5.6. Estancia de investigación ..................................................................................................... 84

5.7. Trabajos futuros ................................................................................................................... 84

Referencias ....................................................................................................................................... 86

Apéndices ......................................................................................................................................... 91

1. Carpeta del proyecto ........................................................................................................... 91

2. Normas de calidad ............................................................................................................... 97

3. Herramienta para la evaluación del modelo de calidad de productos de software ..... 101

4. Gestión de proyectos ......................................................................................................... 103

5. Ciclo de Deming ................................................................................................................. 104



6

6. Satisfacción del cliente ...................................................................................................... 105

Anexos ............................................................................................................................................ 107

1. Artículo derivado de la investigación .............................................................................. 107



7

Lista de figuras

Figura 1. Porcentajes de metodologías y/o modelos para el desarrollo de software usado por

empresas mexicanas. Corona (2016). ..................................................................................... 18

Figura 2. Gráfica con el incremento del outsourcing en los últimos años. INEGI (2015). ....... 20

Figura 3. Proceso SCRUM. Gestión de Proyectos. (2012). .......................................................... 34

Figura 4. Procesos integrados en MOPICS. (Elaboración propia). ............................................ 42

Figura 5. Flujo de comunicación entre roles. (Elaboración propia). .......................................... 45

Figura 6. Etapas en MOPICS. (Elaboración propia). .................................................................. 46

Figura 7. Etapa cero (Diagnóstico organizacional). (Elaboración propia). ............................... 47

Figura 8. Etapa uno (Planeación del desarrollo). (Elaboración propia). ................................... 49

Figura 9. Etapa Dos (Implementación). (Elaboración propia).................................................... 51

Figura 10. Etapa tres (Entrega de valor). (Elaboración propia). ................................................ 53

Figura 11. Etapa cuatro (Satisfacción del cliente). (Elaboración propia). ................................. 54

Figura 12. Elementos del modelo de negocio. (Elaboración propia). ......................................... 62

Figura 13. Proceso de vinculación de las partes involucradas. (Elaboración propia). .............. 69



8

Lista de tablas

Tabla 1. Beneficios de aplicar metodologías ágiles en el desarrollo de software. (Pastrana,

2014). ........................................................................................................................................ 29 Tabla 2. Características de algunas metodologías ágiles. (Elaboración propia). ...................... 30 Tabla 3. Ranking de “agilidad” (Los valores más altos representan una mayor agilidad). SEI

(2010). ....................................................................................................................................... 32 Tabla 4. Comparación de trabajos de investigación con enfoque ágil basados en la

comunicación con el cliente. (Elaboración propia). .............................................................. 39 Tabla 5. Roles en el modelo propuesto. (Elaboración propia). ................................................... 44 Tabla 6. Actividades y tareas de la etapa cero. (Elaboración propia). ....................................... 47 Tabla 7. Actividades y tareas de la etapa uno. (Elaboración propia). ........................................ 50 Tabla 8. Actividades y tareas de la etapa dos. (Elaboración propia).......................................... 51 Tabla 9. Actividades y tareas de la etapa tres. (Elaboración propia). ........................................ 53 Tabla 10. Actividades y tareas de la etapa cuatro. (Elaboración propia). ................................. 54 Tabla 11. Normalización de las métricas para la evaluación del software. ................................ 72 Tabla 12. Calidad externa e interna. ............................................................................................. 72 Tabla 13. Calidad de uso................................................................................................................. 73 Tabla 14. Calidad del producto de software. ................................................................................ 74 Tabla 15. Modelo de calidad........................................................................................................... 74 Tabla 16. Calidad del modelo. ........................................................................................................ 75 Tabla 17. Comparación de MOPICS con trabajos de investigación similares. ......................... 83



9

Glosario de términos

Actividad Conjunto de tareas propias de una entidad. RAE, (2001).

Agilismo Es una respuesta a los fracasos y frustraciones de modelos

tradicionales para el desarrollo de software. Basado en los valores y

principios que emanan del manifiesto ágil. Ble, (2013).

Auditoria Examen crítico y sistemático que realiza una persona calificada o

grupo de personas independientes del sistema, puede ser una

persona, organización, sistema, proyecto o producto, con el objeto

de emitir una opinión independiente y competente. DICIEA,

(1993).

Base de datos Es una colección de datos interrelacionados almacenados

conjuntamente en uno o más ficheros de computadora. IEEE,

(1990).

Benchmark Punto de referencia. Evaluación por comparación. WR, (2017).

Buenas prácticas Conjunto coherente de acciones que han rendido bien en un

determinado contexto y que se espera que rinda en contextos

similares con similares resultados. Abdoulaye, (2003).

Calidad Adecuación de un producto o servicio a las características

especificadas. RAE, (2001).

Consultoría Servicio profesional prestado por empresas, o por profesionales en

forma individual con experiencia o conocimiento específico en un

área, asesorando personas, asesorando a otras empresas, a grupos

de empresas, a países o a organizaciones en general. Actividad del

consultor. RAE, (2001).

Crecimiento

organizacional

Es el conjunto de resultados cuantitativos obtenidos por la

organización a través del tiempo. La medición de estos resultados

es objetiva. Alles, (2011).

Data mart Versión especial de data warehouse, subconjuntos de datos con el

propósito de ayudar a que un área específica dentro del negocio

pueda tomar mejores decisiones. SIN, (2016).



10

Data mining Minería de datos o exploración de datos, es un campo de la

estadística y las ciencias de la computación referida al proceso que

intenta descubrir patrones en grandes volúmenes de conjuntos de

datos. SIN, (2016).

Data warehouse Almacén de datos, es una colección de datos orientada a un

determinado ámbito, integrado, no volátil y variable en el tiempo,

que ayuda a la toma de decisiones en la entidad en la que se utiliza.

SIN, (2016).

Estrategia Según su etimología griega la palabra estrategia significa conductor

del ejército, siendo el ámbito militar el primero que la usó para

referirse a los medios y la disposición adecuada de los mismos para

llegar al fin perseguido, que en este caso era ganar las batallas. La

estrategia supone anticipar acciones, prever consecuencias, advertir

riesgos y elaborar el camino para posicionarse satisfactoriamente

en donde se desea estar. François, (2004).

Etapa Tiene su origen en el vocablo francés “étape” y puede hacer

referencia tanto a una porción del camino de un trayecto específico,

como al sitio en el cual se hace una pausa para descansar en el

marco de un traslado o a una fase en el desarrollo de una

determinada actividad o acción. François, (2004).

Evaluación de

calidad

Examen sistemático del grado al cual una entidad es capaz de

cumplir los requisitos especificados. Espinoza, (1996).

Front office Conjunto de las estructuras de una organización que gestionan la

interacción con el cliente. MG, (2017).

Híbrido Se dice de todo lo que es producto de elementos de distinta

naturaleza. RAE, (2001).

Ingeniería de

Software

Es la aplicación de un enfoque sistemático, disciplinado y

cuantificable al desarrollo funcional y mantenimiento del software.

IEEE, (1993).

Integración Construir un todo. Completar un todo con partes faltantes. RAE,

(2001).

Iteración Acción y efecto de iterar. Acto de repetir un proceso con la

intención de alcanzar una meta, objetivo o resultado. RAE, (2001).



11

Login Autentificación al ingresar a un servicio o sistema. Alegsa, (2017).

Manifiesto Escrito en que se hace público la declaración de doctrinas. RAE,

(2001).

Mantenibilidad Capacidad de un elemento, bajo determinadas condiciones de uso,

para conservar, o ser restaurado a un estado en el que pueda realizar

la función requerida, cuando el mantenimiento se realiza bajo

determinadas condiciones y usando procedimientos y recursos

establecidos. ISO, (2017).

Marketing Conjunto de principios y prácticas que buscan el aumento del

comercio, especialmente de la demanda. RAE, (2001).

Marketing relacional Forma de crear relaciones cercanas y duraderas con los clientes,

permitiendo que tanto la empresa como el cliente mismo puedan

derivar mejores beneficios de la relación. Kotler, (2012).

Método Es una palabra que proviene del término griego methodos

(“camino” o “vía”) y que se refiere al medio utilizado para llegar a

un fin. Su significado original señala el camino que conduce a un

lugar. Francois, (2004).

Metodología Es un vocablo generado a partir de tres palabras de origen griego:

metà (“más allá”), odòs (“camino”) y logos (“estudio”). El

concepto hace referencia al plan de investigación que permite

cumplir ciertos objetivos en el marco de una ciencia. Francois,

(2004).

Métrica Medida cuantitativa o cualitativa del grado en que un sistema,

componente o proceso posee un atributo determinado. IEEE,

(1993).

Modelo Es una representación de un objeto real que en el plano abstracto el

hombre concibe para caracterizarlo y poder, sobre esa base, darle

solución al problema planteado, es decir, satisfacer una necesidad.

François, (2004).

Optimización Buscar la mejor manera de realizar una actividad. RAE, (2001).

Outsourcing Acuerdo en el que una empresa contrata una parte de su actividad



12

interna existente a otra empresa. Oxford, (2005).

Plan de desarrollo Es una herramienta de gestión que promueve el desarrollo en un

determinado objetivo. Pérez, (2013).

Portabilidad Se define como la característica que posee un software para

ejecutarse en diferentes plataformas, el código fuente del software

es capaz de reutilizarse en vez de crearse un nuevo código cuando

el software pasa de una plataforma a otra. A mayor portabilidad

menor es la dependencia del software con respecto a la plataforma.

ISO, (2017).

Procedimiento Consiste en seguir ciertos pasos predefinidos para desarrollar una

labor de manera eficaz. Su objetivo debería ser único y de fácil

identificación, aunque es posible que existan diversos

procedimientos que persigan el mismo fin, cada uno con estructuras

y etapas diferentes, y que ofrezcan más o menos eficiencia.

François, (2004).

Proceso Su origen es latino del vocablo “processus”, de procedere, que

viene de “pro” (para adelante) y “cere” (caer, caminar), lo cual

significa progreso, avance, marchar, ir adelante, ir hacia un fin

determinado. Por ende, es definido como la sucesión de actos o

acciones realizados con cierto orden, que se dirigen a un punto o

finalidad, así como también al conjunto de fenómenos activos y

organizados en el tiempo. François, (2004).

Product Owner Representante de todas las personas interesadas en los resultados

del proyecto (internas o externas a la organización, o usuarios

finales del producto) y actuar como interlocutor único ante el

equipo. Schwaber, (2013).

Rol Es un término que proviene del inglés “role”, que a su vez deriva

del francés “rôle”. El concepto está vinculado a la función o papel

que cumple alguien o algo. François, (2004).

SCRUM master Facilitador de proyectos, es la figura que lidera los equipos en la

gestión ágil de proyectos. Su misión es que los equipos de trabajo

alcancen sus objetivos hasta llegar al Sprint final, eliminando

cualquier dificultad que puedan encontrar en el camino. Schwaber,

(2013).

SCRUM team Grupo de personas que de manera conjunta desarrollan el producto



13

del proyecto. Tienen un objetivo común, comparten la

responsabilidad del trabajo que realizan en cada iteración y en el

proyecto. Schwaber, (2013).

Software Conjunto de programas, instrucciones y reglas informáticas para

ejecutar ciertas tareas en una computadora. RAE, (2001).

Sprint División del proyecto en bloques de temporadas cortas y fijas que

proporcionan un resultado completo, como un incremento de

producto que sea potencialmente entregable. Schwaber, (2013).

Stakeholders Significa interesado o parte interesada, que se refiere a todas

aquellas personas u organizaciones afectadas por las actividades y

las decisiones de una empresa. Schwaber, (2013).

Tarea La palabra tarea reconoce un origen árabe. Proviene del vocablo

“tariha” y significa trabajo u obra. Consiste en un hacer que

demanda esfuerzo y que generalmente tiene un tiempo límite para

su realización. François, (2004).

Time to market Se define como la capacidad de reacción que tienen las

organizaciones para crear o mantener ventajas competitivas ante los

retos que presenta el mercado y sus competidores. Kenneth, (2004).

Técnica Es un procedimiento o un conjunto de procedimientos prácticos, en

vistas al logro de uno o varios resultados, valiéndose de

herramientas o instrumentos, y utilizando el método inductivo y/o

analógico, en cualquier campo del saber o del accionar humano. No

constituye ciencia pues sus contenidos son para casos particulares,

sin pretensión de universalidad, pudiendo aplicarse para la solución

de un problema o la realización de una tarea u obra, diferentes

técnicas a elección del interesado, según la que más se adapte a sus

aptitudes y gustos. François, (2004).

Tecnologías Conjunto de teorías y de técnicas que permiten el aprovechamiento

práctico del conocimiento científico. RAE, (2001).

Testing Las pruebas de software, son las investigaciones empíricas y

técnicas cuyo objetivo es proporcionar información objetiva e

independiente sobre la calidad del producto a la parte interesada.

Kenneth, (2004).



14

Unificación La palabra unificación posee un origen etimológico del latín “unus”

que tiene por significado “uno”, como su nombre lo indica unificar

significa reducir varios compartimientos o grupos a una sola

unidad, se refiere a unir, mezclar diferentes grupos con el fin de

fomentar conexión. François, (2004).

Usabilidad Es la medida de la calidad de la experiencia que tiene un usuario

cuando interactúa con un producto o sistema. (ISO, 2017).



15

Glosario de acrónimos

ASD Adaptative Software Development, Desarrollo Adaptativo de Software

B2B Business to business, Negocio entre Empresas

BI

Business Intelligence, Inteligencia de Negocios

CRM

Customer Relationship Management, Gestión de las Relaciones con los

Clientes

INEGI

Instituto Nacional de Estadística y Geografía

ISO International Organization for Standardization, Organización Internacional

de Normalización

MDSD Model Driven Software Development, Método de Desarrollo de Sistemas

Dinámicos

OLAP On-Line Analytical Processing, Procesamiento Analítico en Línea

PDCA

Plan - Do - Check - Act, Planear – Hacer – Chequear - Actuar

PM

Project Management, Gestión de Proyectos

PMI

Project Management Institute, Instituto de Gestión de Proyectos

ROI

Return Of Investment, Retorno de la Inversión

RSI

Relative Strength Index, Índice de Fuerza Relativa

RUP

Rational Unified Process, Proceso Unificado de Racional

SEI Software Engineering Institute, Instituto de Ingeniería de Software

SLA

Service Level Agreement, Acuerdo de Nivel de Servicio

TELCO Telecomunicaciones

TI

Tecnologías de la Información

UML

Unified Modeling Language, Lenguaje Unificado de Modelado

XP eXtreme Programming, Programación Extrema



16

Capítulo 1

Introducción



17

Capítulo 1. Introducción

1.1. Antecedentes

Las Tecnologías de la Información (TI) se han convertido en la última década en

parte esencial para los negocios, es por eso que se han desarrollado herramientas que

ayudan a empresas y organizaciones a gestionar las diversas actividades de la misma; por lo

tanto, las metodologías han ido de la mano de las TI para hacer más eficiente el desarrollo

de proyectos y/o software.

Recientemente, desarrolladores y empresas consultoras de TI están comenzando a tomar

parte en la economía como outsourcing y a utilizar metodologías, que emplean enfoques

iterativos para el desarrollo de proyectos, donde los miembros de un equipo se reúnen con

cada unidad de negocio para analizar sus necesidades antes de empezar a diseñar o

construir una solución al problema. Una vez que se han identificado los requisitos, el

equipo se trasladará a diseñar, construir e implementar el sistema, dando lugar al empleo de

las metodologías ágiles.

En cuanto al lado del cliente, CRM (Customer Relationship Management) es una estrategia

de negocio que se utiliza para la gestión y prácticas de negocio en empresas, es un término

que realmente no es nuevo; lo que es reciente son las TI que apoyan su implantación,

permitiendo al dueño de un negocio, saber necesidades, gustos e intereses de sus clientes.

En este tipo de estrategias es necesario utilizar las buenas prácticas y que mejor, que

basarse en una metodología que se adapte a las necesidades del proyecto, como son las

metodologías ágiles; las cuales, son una serie de técnicas para la gestión de proyectos que

han surgido como contraposición a los métodos clásicos de gestión. Aunque surgieron en el

ámbito del desarrollo de software, también han sido exportadas a otro tipo de proyectos,

sugerido por Racheva (2010).

Por otra parte, el sector Consultoría en TI como outsourcing (también conocida como

tercerización laboral), es un campo que ha crecido en los últimos años. Este sector se ha

dedicado a prestar servicios de especialización a empresas u organizaciones que necesitan

actividades específicas a un proceso o proyecto en especial. Así mismo, la comunicación

con la empresa u organización a la que se le prestó el servicio es vital en este proceso.

Razón por la cual, se ha elegido este sector como caso de estudio y aplicación, del modelo

que se propone como parte de esta investigación.

1.2. Planteamiento del problema

A partir del análisis de los resultados obtenidos sobre el uso de metodologías y

modelos en empresas de desarrollo de software en México, se tiene a SCRUM como la



18

metodología ágil más utilizada hasta el momento, Corona (2016), el resto de porcentajes se

muestran en la Figura 1. De manera que también se debe brindar mejor atención a las

relaciones interpersonales, especialmente con el cliente, puesto que la comunicación es el

principal objetivo de SCRUM.

Figura 1. Porcentajes de metodologías y/o modelos para el desarrollo de software usado por

empresas mexicanas. Corona (2016).

Tomando como base la ausencia de uso de mejora en los procesos y metodologías, se

corrobora que no existe un modelo definido que se encargue de las relaciones con el cliente

y que se adapte a las necesidades en particular del sector, en cuanto a la agilidad del

desarrollo de software y facilidad de seguimiento, para así optimizar procesos y la calidad

de los productos de software.

1.3. Objetivos de la tesis

Objetivo general:

Diseñar un modelo de mejora de procesos basado en la implementación de la

estrategia CRM y de la metodología ágil SCRUM enfocado hacia el Sector de

Desarrollo y Consultoría de TI como outsourcing.

Objetivos específicos:

Identificar factores en los procesos de desarrollo de software que influyen en las

relaciones con el cliente en las consultoras de TI.

Definición clara de roles dentro de la organización, debido a que serán parte clave

en la aplicación de procesos del desarrollo de software.



19

Diseñar el modelo, estableciendo actividades y tareas, tomando como base la

metodología SCRUM y la estrategia CRM y usando como ayuda herramientas, que

apoyen la fundamentación del modelo propuesto.

Formular un modelo que apoye a la mejora de procesos durante y después del

desarrollo del servicio y/o producto.

Implementar el modelo propuesto en al menos una empresa del Sector Consultoría

de TI, considerando el proceso de manejo de clientes de CRM.

1.4. Justificación

La tendencia actual es el marketing relacional y la inclusión de TI dentro de las

empresas para mejorar su productividad y presencia en el mercado. Por consiguiente, el

desarrollo de herramientas CRM permite disponer de información actualizada de los

clientes e información del prestador de servicios (proveedor), conociendo rápidamente los

diferentes puntos de contactos para interactuar. Si se agrega un modelo que apoye al Sector

Consultoría en TI a implantar la estrategia CRM y además, asistido de las herramientas de

software que la respalden, se obtiene una mejor interacción con personas, procesos y

productos, colaboración con el cliente, respuesta al cambio, valor agregado al cliente cada

lapso de tiempo, entre otros.

La resolución del problema es importante porque le da la relevancia requerida a la

planificación y gestión de procesos y desafortunadamente, muchas empresas no le prestan

atención a pesar de ser la base para los negocios de cualquier rubro. En cuanto al

outsourcing dentro del Sector Consultorías de TI en conjunto con CRM y una metodología

ágil SCRUM, esta problemática se enfoca a la satisfacción del cliente. Por lo cual, se va a

aportar un modelo que guie las estrategias para mantener la relación con el cliente,

conjuntando la administración de proyectos que se tienen con el cliente, resaltando

mediante métricas el nivel de satisfacción requerido y otorgando iterativamente valor de los

servicios prestados.

Por otra parte, datos del Instituto Nacional de Estadística y Geografía (INEGI), señalan que

el personal no dependiente de la razón social en la que trabajan (outsourcing) se ha

incrementado un 48% en 10 años. Como puede observarse en la Figura 2, el 16.6% de las

29, 642,421 personas con alguna ocupación, está en el esquema de outsourcing.



20

Figura 2. Gráfica con el incremento del outsourcing en los últimos años. INEGI (2015).

1.5. Beneficios esperados

Las TI han traído consigo elementos valiosos, aplicados para la toma de decisiones y

a la automatización de procesos, que obtienen, organizan y visualizan información a través

de grandes volúmenes de datos, aunque están en constante cambio y avance. CRM es una

estrategia importante para las empresas hoy en día, ya que través de ella se obtiene

información valiosa de procesos y/o clientes que ayuda a la comunicación entre los

mismos. Es por eso que, empresas y organizaciones en el Sector Consultoría de TI, esperan

que se aporte una guía para la planificación, organización y gestión de procesos e

información dentro de la empresa, empleando una metodología ágil para el rápido

desarrollo de proyectos.

Por lo tanto, la finalidad de esta investigación es aportar un modelo CRM basado en

metodologías, fusionando la estrategia de negocio con una metodología ágil (SCRUM)

dentro del Sector Consultoría de TI como outsourcing, que permita una mejor visibilidad

del estado del proyecto y mejore las relaciones con el cliente al mismo tiempo. Trayendo

consigo beneficios como, mejor relación con el cliente, trato adecuado a cada cliente,

clientes potenciales, gestión de proyectos, base de datos unificada, reducción de tiempos,

reducción de costos, entre otros.

1.6. Alcances y limitaciones

El modelo planteado se basa en el sector consultoría de TI, especialmente,

enfocándose al área del outsourcing; ya que esta área en particular, se puede considerar

como una forma de trabajo potencial para las empresas mexicanas actuales. El modelo será

probado en proyectos de empresas mexicanas, enfocadas en el desarrollo de software.



21

En relación a la estrategia CRM empleando la metodología SCRUM, proporcionará

información sobre el estado del proyecto, métricas, documentación, estrategias, entre otros

y en cuanto a la relación con el cliente, contactos y reglas de negocio. En cada etapa del

ciclo de vida de desarrollo del proyecto, solo se definirán actividades y tareas para cada uno

de los participantes del proyecto, especificadas a detalle donde se obtienen los

requerimientos cambiantes.

El presente trabajo de tesis se enfatiza en el modelo para el desarrollo de software, razón

por la cual, no se ha creado un producto de software como tal que lo automatice; este

trabajo, se basa en el análisis y exploración de diversas prácticas consideradas como buenas

dentro de la Ingeniería de Software, para fundamentar y elaborar un modelo que se adapte

al sector de consultoría como outsourcing. Por consiguiente, ha sido necesario inspeccionar

y conocer modelos, metodologías, métodos, procedimientos, técnicas y procesos que han

surgido, para ser empleadas por las empresas para el desarrollo de software, fundamentando

así la formulación de roles, etapas, actividades y tareas para el modelo propuesto en esta

investigación.

Todo desarrollo de software, requiere en primer lugar conocer adecuadamente los procesos

y estrategias que se van a automatizar, tal es el caso por ejemplo de la estrategia CRM, de

la cual, ya existen muchos desarrollos de software.

Es así, como investigación se centra únicamente en el análisis de prácticas y procesos

dentro de la organización, para que permitan conocer mejor al personal y clientes. Una vez

depurado el modelo, en un futuro será posible su implementación.

1.7. Organización de la tesis

Los capítulos en este documento de tesis, se estructuran de la siguiente manera:

Capítulo 1.

En este capítulo se presenta una breve introducción sobre el tema, se plantea el problema,

objetivos a lograr, justificación, beneficios esperados, alcances y limitaciones.

Capítulo 2.

Se muestran conceptos básicos para la comprensión de un CRM y metodologías destacadas,

así como también el estado del arte de esta investigación.

Capítulo 3.

En el tercer capítulo se diseña el modelo propuesto, por consiguiente, se definen

requerimientos, se presenta el modelo empleando UML, que se adapte a los procesos de

negocio planteados y definidos y orientados al cliente.



22

Capítulo 4.

El cuarto capítulo presenta la implantación del modelo para la realización de pruebas y

resultados que lo validen en cuanto a funcionalidad.

Capítulo 5.

Se muestran las conclusiones, beneficios alcanzados (o aportes) y los trabajos a futuro.



23

Capítulo 2

Marco teórico y Estado del Arte



24

Capítulo 2. Marco teórico y estado del arte.

En el presente capítulo, se abordarán algunos de los procesos que conlleva el ciclo de

vida del desarrollo de proyectos en SCRUM orientados a las estrategias CRM. Se describen

también, las herramientas de las que se apoyará el presente trabajo para su diseño.

En el estado del arte, se mencionan herramientas de software que se encuentran en el

mercado, con la intención de extraer aspectos importantes y características que puedan

servir de base a la presente investigación.

2.1. Customer Relationship Management (CRM)

CRM es una estrategia de negocio que optimiza los ingresos y la rentabilidad, además

de promocionar la satisfacción y lealtad de los clientes. Las tecnologías CRM habilitan

estrategia, identificación y gestión de las relaciones con los clientes, en persona o

virtualmente. El software CRM proporciona funcionalidad para las empresas en cuatro

segmentos: ventas, marketing, servicio al cliente y comercio digital, (Collins K., Thompson

E., 2016).

Sarika Sharma y D.P. Goyal (2011), señalan que “para sobrevivir en el entorno competitivo

actual, una organización necesita estar centrada en el cliente, ya que es el cliente el que

hace o rompe el éxito de la organización. CRM es un entorno muy fragmentado y ha

llegado a significar diferentes cosas para diferentes personas”. De acuerdo con la definición

de Bradshaw D. (2001), CRM es un enfoque de gestión que permite a la organización

identificar, atraer y aumentar la retención de clientes rentables mediante la gestión de las

relaciones con ellos.

A través de este tipo de herramientas, una organización tiene una mayor veracidad sobre la

información que se extrajo del cliente, que da como resultado una mejor comunicación.

Estas herramientas también ayudan al intercambio de información valiosa, ya que ayuda a

mejorar los procesos, generar relaciones a largo plazo y aumentar la satisfacción del cliente.

A esto se le denomina marketing relacional, que argumenta Gummesson (2002), es la

“interacción representada en redes de las relaciones”.

La gestión de una organización se entiende como una determinada multitud de agentes

colectivos en el mercado que crean y reciben valor a través de sus relaciones, por lo que

tienen que ser incluidos en el proceso de planificación de la organización, donde el valor

del producto final va a depender de ellos en gran medida.

La creación de una estrategia de relaciones con los clientes es el primer paso de un proyecto

de CRM. Por lo que se requieren los siguientes pasos:



25

1) Conocimiento: Identificación de clientes más rentables.

2) Escuchar: El énfasis está en la lealtad del cliente, por lo que es imperativo para

averiguar los valores y las necesidades clave para cada clase de cliente.

3) Crecimiento: A través de la comunicación y la producción de valor de la manera

más adecuada para cada clase de cliente, la empresa es capaz de desarrollar una

relación con ellos.

4) La evaluación de los resultados.

Para hacer frente a estas etapas adecuadamente, la empresa tiene que revisar e integrar sus

infraestructuras y procesos de negocio, prestando especial atención a dos factores cruciales:

la comunicación y el intercambio de conocimientos, Rajola F. (2013).

2.1.1. Ecosistema CRM

El ecosistema de CRM consta de tres componentes fundamentales:

CRM analítico,

CRM operacional,

CRM colaborativo.

Los tres componentes señalados anteriormente son los "campos de acción" de CRM, que

están estrechamente vinculados entre sí, debido a la falta o insuficiencia de cualquiera de

las dimensiones pone en peligro el funcionamiento de todo el sistema (Ptacek, 2000a).

2.1.2. CRM analítico

Se analizan los datos e información sobre los clientes que tiene la organización. Aquí

es donde la tecnología CRM utiliza una plataforma que permite una buena interacción con

los datos, alimentada por las bases de datos de los sistemas operativos, Rajola F. (2013).

Los puntos más importantes son el componente de análisis, almacenamiento de datos y los

mercados de datos. El uso de herramientas de inteligencia de negocio en el análisis de

datos, por ejemplo, son capaces de dividir a los clientes en grupos homogéneos, la

construcción de perfiles y la creación de modelos de comportamiento a través de la

evaluación de una serie de parámetros, como la lealtad, rentabilidad, solvencia y por

último, pero no menos importante, sensibilidad a determinadas acciones de marketing, que

por lo tanto se pueden planificar y supervisar con eficacia (Lee 2000; Kotler 1999; Groth

1998; 2000b Brown).

El CRM Analítico contiene como elementos destacados el data warehouse, datamarts,

otras aplicaciones verticales (data mining, OLAP), automatización de marketing y gerente

de campaña de los sistemas.



26

2.1.3. CRM operacional

Rajola F. (2013) menciona que la toma de decisiones de negocios realizadas en el

contexto analítico son adoptadas en el operacional. Estas tecnologías incluyen aplicaciones

de interacción con el cliente. Ofrecen una serie de utilidades como registros del cliente,

actitudes, preferencias, información sobre las operaciones por canal, la gestión operativa de

marketing de campañas y la de un perfil actualizado para cada cliente.

El CRM operacional también es compatible con actividades administrativas (gestión de

pedidos, cadena de suministro y operaciones con el sistema de información), actividades de

front office (automatización de servicios, automatización de marketing, automatización de

la fuerza de ventas) y actividades de oficina móvil en relación con el personal de las

sucursales, promotores financieros y todos los demás servicios de apoyo a las ventas.

2.1.4. CRM colaborativo

En este componente, se encarga de facilitar la interacción del cliente y la

organización e incorpora los nuevos medios, donde provee los patrones de comportamiento

del cliente. Los canales que permiten a los clientes tener acceso en línea a la información en

cualquier momento (Internet, intranet, portales auto-servicio y conexiones de socios).

Si el sitio web es difícil de navegar o el portal no provee la información que los clientes

necesitan, el sistema no opera durante el horario laboral del cliente y entonces, el canal no

sirve. Un cliente frustrado mirará a la competencia.

La implementación de servicios colaborativos (correo electrónico, chat, etc.) sirven para

facilitar las interacciones con el cliente, organización e stakeholders, por lo tanto, debe

orientarse a mejorar la comunicación para promover la disminución de costos del cliente e

incrementar su retención.

2.1.5. CRM estándar

CRM hoy en día se han convertido en una herramienta indispensable en las

organizaciones y empresas, por lo cual han surgido software estándares y a la medida, con

el fin de cubrir las necesidades de cada organización.

En el mercado existe software estándar para diferentes organizaciones, ya que no son

iguales las necesidades. Muchos de estos, son basados en la demanda, confiabilidad,

experiencia y relación con el negocio. Según un estudio realizado por Harris D. (2014).

Entre los 10 CRM más populares se pueden mencionar Salesforce, Microsoft Dynamics



27

CRM, HubSpot, Insightly, Infusionsoft, Zoho CRM, Oracle CRM On Demand, SAP,

SugarCRM y Pardot.

Para realizar este estudio, se tomaron en cuenta tres aspectos: índice de adopción, usuarios

que usan el producto; búsquedas en línea, el número de veces en que aparece el nombre de

la marca en el buscador Google por mes y seguidores sociales.

2.2. Metodologías ágiles

Una definición útil de la agilidad viene dada por Qumer y Henderson-Sellers (2008),

que la define como un comportamiento persistente o capacidad de una entidad que exhibe

flexibilidad para adaptarse a cambios esperados o inesperados rápidamente. Sigue el lapso

de tiempo más corto, usos económicos, instrumentos sencillos y calidad en un entorno

dinámico.

Las metodologías ágiles son métodos de desarrollo de software que proveen soluciones a

organizaciones sobre la colaboración de los equipos participantes, hacen énfasis en el

desarrollo evolutivo (iterativo), flexibilidad y comunicación.

Dichas metodologías de desarrollo de software, han recibido mucha atención en las últimos

dos décadas. Los métodos iterativos han tomado gradualmente una gran parte de la

comunidad de desarrollo de software, en 2009, un 35% de las organizaciones ya tenía los

métodos ágiles maduros y otra tercera parte de su aplicación, según Forrester (2009).

2.2.1. Manifiesto ágil

Se están descubriendo mejores formas de desarrollar software, haciéndolo y ayudar a

que otros lo hagan. Como citan los 17 críticos de los modelos de mejora del desarrollo de

software basados en procesos, convocados por Beck (2016), se están descubriendo formas

mejores de desarrollar software. A través de este trabajo se valoran los siguientes puntos:

“Individuos e interacciones sobre procesos y herramientas,

Software funcionando sobre documentación extensiva,

Colaboración con el cliente sobre negociación contractual,

Respuesta ante el cambio sobre seguir un plan.”

Es decir, mientras que hay valor en los elementos de la derecha, se valoran más los

elementos de la izquierda, M.M. Lankhorst (2012).

Siguiendo estos principios, según Beck (2016):

1. Prioridad es satisfacer al cliente mediante la entrega temprana y continua de

software con valor.



28

2. Aceptar que los requisitos cambien, incluso en etapas tardías del desarrollo. Los

procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al

cliente.

3. Entregar software funcional frecuentemente, entre dos semanas y dos meses, con

preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajan juntos de forma

cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados.

6. Conversación cara a cara para comunicar información a todos los miembros del

proyecto.

7. El software funcionando es la medida principal de progreso.

8. Los procesos ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de

forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-

organizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a

continuación ajustar y perfeccionar su comportamiento en consecuencia.

2.2.2. Beneficios de usar metodologías ágiles

La mayoría de las veces, las metodologías ágiles son la mejor opción por los

beneficios a corto plazo. Lo difícil es saber el punto medio y más recomendable para cada

proyecto e incluso, se puede buscar el punto intermedio entre ágil y tradicional. Por ello, es

importante saber que hay una metodología concreta para cada proyecto, como lo dicen

especialistas del manifiesto ágil, convocados por Kent y firmantes del manifiesto ágil

(2001).

No todos los tamaños de empresas emplean metodologías ágiles, dado que depende de lo

que se desea desarrollar. Hay empresas grandes que deciden adoptar como mejor

alternativa metodologías hibridas, que combinan algunas prácticas de distintas

metodologías, sean tradicionales y/o ágiles, por ejemplo RUP (Rational Unified Process),

SCRUM y XP (Extreme Programming).

Entre las ventajas de utilizar este tipo de metodologías, se pueden mencionar los ejemplos

mostrados en la Tabla 1.



29

Tabla 1. Beneficios de aplicar metodologías ágiles en el desarrollo de software. (Pastrana, 2014).

Beneficio Descripción

RSI superior Cuando se enfrentan proyectos múltiples y no se aplican metodologías

ágiles, se espera a que se complete un proceso antes de arrancar con el

segundo. Para poder lidiar con este tipo de operaciones se busca cómo

finalizar entregas lo más pronto posible, lo cual significa un inmenso riesgo

de recorte de funcionalidades o calidad.

El desarrollo con metodología ágil refuerza las entregas múltiples con

funcionalidades del acuerdo de entrega e implica un enfoque, que consiste

en desarrollar la funcionalidad a prioridad para el proyecto desde el inicio.

Aumento de productividad La producción de software que trabaja alrededor de las necesidades de

negocio implica ingresar conocimiento multidisciplinario en etapas

simultáneas. La metodología ágil sirve para enfocar la atención de los

partidos por disciplina en el espacio que se les necesita e inmediatamente,

liberar el talento para que puedan moverse entre zonas de trabajo.

Simplifica el manejo de la

sobrecarga de procesos

Los equipos que trabajan sobre normas y regulaciones han de validar su

trabajo, lo cual representa un doble trabajo. Las metodologías por iteración

simplifican el proceso de entrega versus validación lo cual además permite

adoptar cambios sobre la marcha del alcance del proyecto.

Mejor perfil de productividad Los equipos ágiles son más productivos que aquellos que utilizan métodos

tradicionales a lo largo de todo el ciclo de desarrollo. Si no se aplica un

sistema ágil se presenta un patrón de desarrollo engorroso donde la mayoría

del trabajo sucede en las primeras etapas. La realidad, es que casi nunca

suele suceder que las piezas en equipo terminan trabajando juntos de

manera coherente.

Los equipos ágiles que mantienen un nivel de revisión por unidades

discretas de entrega de trabajo con cada iteración permiten realizar pruebas

de rendimiento y sistemas desde el principio. De este modo, la calidad

general del producto es mayor y el equipo funciona de manera más

productiva durante todo el ciclo de desarrollo.

Una mejor gestión del riesgo No siempre se logra cumplir con las metas de lanzamiento cuando se trabaja

con software, mientras más lejanas sean las entregas al cliente o equipo, más

se maximiza el riesgo de potencial desviación de la entrega contra la

definición del proyecto inicial. Las metodologías ágiles permiten repasar en

ciclos continuos progreso de entregables y productos semi-cerrados.

Cuando fallan las entregas la metodología ágil permite ajustar el ciclo de

trabajo para enfocar el talento en zonas de mayor o menor riesgo, a

justificación de defender un proyecto en su totalidad.

Sin embargo, no todas las empresas han acogido las metodologías ágiles con el mismo

entusiasmo. Por lo cual se han encontrado en ellas serios inconvenientes para la

consecución de sus objetivos.



30

2.2.3. Comparativa de metodologías ágiles

Todas las metodologías ágiles deben cumplir con el manifiesto ágil, en el cual, se le

da más importancia a los individuos, funcionamiento del software, al cliente y cambios

sobre documentación, procesos y negociaciones. Y como menciona M.M. Lankhorst

(2012), entre las metodologías ágiles más conocidas pueden destacarse las que se listan en

la Tabla 2.

Tabla 2. Características de algunas metodologías ágiles. (Elaboración propia).

CARACTERÍSTICAS ETAPAS

PROGRAMACIÓN

EXTREMA

(EXTREME

PROGRAMMING

- XP)

Metodología basada en prueba y error.

Fundamentada en Valores y Prácticas.

Está orientada hacia quien produce y usa

el software.

Reduce el costo del cambio en todas las

etapas del ciclo de vida del sistema.

Combina las que han demostrado ser las

mejores prácticas para desarrollar

software y las lleva al extremo.

Se tienen 12 principios que se agrupan

en 4 categorías distintas:

Retroalimentación.

Proceso continuo en lugar de por

bloques.

Propiedad intelectual compartida.

Entendimiento compartido.

DESARROLLO

ADAPTATIVO DE

SOFTWARE

(ADAPTATIVE

SOFTWARE

DEVELOPMENT -

ASD)

Proporciona un marco para el desarrollo

iterativo de sistemas grandes y

complejos.

Resalta que las aproximaciones

secuenciales en cascada que solo

funcionan en entornos bien conocidos.

Guiado por los riesgos.

La revisión de los componentes sirve

para aprender de los errores y volver a

iniciar el ciclo de desarrollo.

Fase de especulación.

Fase de colaboración.

El aprendizaje.

MÉTODO DE

DESARROLLO

DE SISTEMAS

DINÁMICOS

(MDSD)

Se centra en proyectos de sistemas de

información con presupuestos y agendas

apretadas.

Utiliza un mecanismo para medir

tiempos.

Promueve el uso del RAD (Rapid

Application Development, Desarrollo

Rápido de Aplicaciones).

Desarrollo iterativo.

Pre-proyecto.

Estudio de la viabilidad.

Estudio del negocio.

Iteración de Modelo Funcional.

Iteración de Diseño y Desarrollo.

Aplicación.

Post-proyecto.

CRISTAL

(CRYSTAL

CLEAR - CC)

Se caracteriza por seguir proyectos

según 2 dimensiones, tamaño y

complejidad.

CC consiste en valores, técnicas y

procesos.

El factor más significativo es

“comunicación”.

Maneja iteraciones.

Clear, para equipos de hasta 8

personas o menos.

Amarillo, de entre 10 y 20

personas.

Naranja, para equipos entre 20 y

50 personas.

Roja, entre 50 y 100 personas.

Entre otros.

SIX SIGMA Metodología para la mejora de procesos.

Se basa en realizar análisis estadísticos

Definir.

Medir.



31

con el fin de poder reducir o solucionar

un problema.

Instrumento de medición de calidad.

Analizar.

Mejorar.

Controlar.

SCRUM Entrega mensual de resultados.

Gestión regular de las expectativas del

cliente y basada en resultados tangibles.

Resultados anticipados (time to market).

Flexibilidad y adaptación respecto a las

necesidades del cliente, cambios en el

mercado, etc.

Gestión sistemática del Retorno de

Inversión (ROI).

Mitigación sistemática de los riesgos del

proyecto.

Productividad y calidad.

Alineamiento entre el cliente y el equipo

de desarrollo.

Equipo motivado.

Las iteraciones (Sprints), se manejan

de la siguiente forma:

Planificación de la iteración.

Ejecución de la iteración.

Inspección y adaptación.

El objetivo de las metodologías ágiles, como se menciona en el manifiesto ágil, es el

enfoque a las personas sobre las técnicas y es por eso que se eligió este tipo de metodología

para implementarse junto con una estrategia que se centra en las relaciones con las personas

también. Muchas disciplinas se acogieron a las metodologías ágiles para la puesta en

marcha de sus proyectos, especialmente los que tenían que ver con el sector del software,

pero SCRUM fue la más empleada gracias a que cuenta con beneficios significativos para

el cliente, permitiendo obtener resultados directos en intervalos predefinidos de tiempo

cortos. SCRUM es una metodología flexible ya que se adapta a cambios en todas las etapas

del desarrollo del proyecto e incorpora mejoras para los procesos.

Otros aspectos no tan positivos de este tipo de metodologías, son la fuerte dependencia de

expertos y líderes, la poca documentación y las soluciones erróneas en etapas largas del

desarrollo.

La Tabla 3, compara las distintas aproximaciones ágiles con base en tres parámetros: vista

del sistema como algo cambiante, tener en cuenta la colaboración entre todos los miembros

del equipo y características más específicas de la propia metodología como son

simplicidad, excelencia técnica, resultados, adaptabilidad, etc. Todas las metodologías

ágiles mencionadas anteriormente tienen una significativa diferencia del índice de agilidad,

entre ellas destacan ASD, Crystal, DSDM, SCRUM y XP como las más ágiles, según el

SEI (Software Engineering Institute), (2010). También existen otras metodologías ágiles

pero están enfocadas al sector manufactura y dado que este trabajo se basa en el desarrollo

de productos de software, no se consideran.



32

Tabla 3. Ranking de “agilidad” (Los valores más altos representan una mayor agilidad). SEI

(2010).

ASD Crystal DSDM SCRUM XP

Sistema como algo

cambiante

5 4 3 5 5

Colaboración 5 5 4 5 5

Características

metodología (CM):

Resultados 5 5 4 5 5

Simplicidad 4 4 3 5 5

Adaptabilidad 5 5 3 4 3

Excelencia técnica 3 3 4 3 4

Prácticas de

colaboración

5 5 4 4 5

Medida CM 4.4 4.4 3.6 4.2 4.4

Medida Total 4.8 4.5 3.6 4.7 4.8

2.2.4. SCRUM

M.M. Lankhorst (2012) menciona que, la metodología ágil más popular hoy en día es

SCRUM (Schwaber y Beedle 2002). El nombre SCRUM deriva del rugby y también se

utiliza para las reuniones diarias con todos los miembros del equipo, una de las prácticas

importantes del método.

2.2.4.1. Roles

SCRUM es un marco relativamente ligero que identifica sólo tres roles:

1) SCRUM Master, mantiene los procesos y elimina impedimentos.

2) Product Owner, que representa a todos los interesados y decide sobre las

características y prioridades.

3) SCRUM Team, un grupo de funciones cruzadas, de auto-organización que hacen el

análisis real, diseño, implementación, prueba y despliegue.

Fundamentalmente, SCRUM no tiene un jefe de proyecto que maneje la autoridad de

control y mando sobre el equipo. El SCRUM Master es un facilitador, pero el equipo es

responsable de la forma en que organizan su trabajo; la planificación es un esfuerzo de



33

colaboración entre el SCRUM Team y el Product Owner, en base a las prioridades

establecidas por este último y el esfuerzo necesarios según lo estimado por el primero.

2.2.4.2. Proceso

En SCRUM se realizan entregas parciales y regulares del producto final, priorizadas

por el beneficio que aportan al receptor del proyecto. Por ello, está especialmente indicado

para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde

los requisitos son cambiantes o poco definidos, donde la innovación, competitividad,

flexibilidad y productividad son fundamentales. También se utiliza para resolver

situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se

alargan demasiado, los costos se disparan o la calidad no es aceptable, cuando se necesita

capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la

rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o

cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.

En SCRUM un proyecto se ejecuta en bloques temporales cortos y fijos llamados Sprint

(iteraciones de un mes y/o dos semanas). En cada Sprint se tiene que proporcionar un

resultado significativo para el cliente cuando lo solicite.

El proceso parte de los requerimientos, donde el cliente prioriza los objetivos dependiendo

al aporte con respecto a costos, repartidos en iteraciones y entregas. Se programan

reuniones, al principio de cada bloque o Sprint, para planear entregas del desarrollo de un

bloque de requerimientos, véase en la Figura 3.

Ya establecidos los Sprint, se realizan pequeñas reuniones diarias que se basan en apoyar

dudas que surgen durante el desarrollo, con la comunicación directa entre el Product Owner

y SCRUM Team. Al culminar el Sprint se hace la entrega y el Product Owner valida la

entrega de valor, después se realizan reuniones para hacer la retrospectiva del Sprint.



34

Figura 3. Proceso SCRUM. Gestión de Proyectos. (2012).

Las principales actividades que se llevan a cabo son las siguientes:

Planificación del Sprint

El primer día del Sprint se hace la reunión de planificación. Tiene dos partes:

1. Selección de requisitos (4 horas máximo). El Product Owner presenta al SCRUM

Team la lista de requisitos priorizada del proyecto.2. Planificación del Sprint (4

horas máximo). El SCRUM Team elabora la lista de tareas de la iteración necesarias

para desarrollar los requisitos.

Ejecución del Sprint

Cada día el SCRUM Team realiza una reunión de 15 minutos (máximo). Cada miembro del

equipo inspecciona el trabajo que el resto está realizando para poder hacer las adaptaciones

necesarias que permitan cumplir con el compromiso.

Durante el Sprint, el SCRUM Master se encarga de que el equipo pueda cumplir con su

compromiso y de que no se merme su productividad. Además, el Product Owner junto con

el SCRUM Team refinan la lista de requisitos y si es necesario, re-planifican los objetivos

del proyecto para maximizar la utilidad de lo que se desarrolla y el retorno de inversión.

Inspección y adaptación

El último día del Sprint se realiza la reunión de revisión. Tiene dos partes:



35

1. Demostración (4 horas máximo). El SCRUM Team presenta al Product Owner los

requisitos completados en el Sprint, en forma de incremento de producto preparado

para ser entregado con el mínimo esfuerzo. Si es necesario, el Product Owner

realiza las adaptaciones necesarias de manera objetiva.

2. Retrospectiva (4 horas máximo). El SCRUM Team analiza su manera de trabajar y

los problemas que podrían impedirle progresar, mejorando de manera continua su

productividad.

Artefactos de SCRUM

Los artefactos de SCRUM representan trabajo o valor en diversas formas que son útiles

para proporcionar transparencia y oportunidades para la inspección y adaptación. Los

artefactos definidos por SCRUM están diseñados específicamente para maximizar la

transparencia de la información clave, que es necesaria para asegurar que todos tengan el

mismo entendimiento del artefacto.

1. Lista de Producto: es una lista ordenada de todo lo que podría ser necesario en el

producto, y es la única fuente de requisitos para cualquier cambio a realizarse en el

producto. . El Product Owner es el responsable de esta lista, incluyendo su

contenido, disponibilidad y ordenación. Una lista de producto nunca está completa.

El desarrollo más temprano de la misma solo refleja los requisitos conocidos y

mejor entendidos al principio. La lista de producto evoluciona a medida de que el

producto y el entorno en el que se usará también lo hacen.

2. Lista de pendientes del Sprint: es el conjunto de elementos de la lista de producto

seleccionados para el Sprint, más un plan para entregar el Incremento de producto y

conseguir el objetivo del Sprint. La Lista de Pendientes del Sprint es una predicción

hecha por el Equipo de Desarrollo acerca de qué funcionalidad formará parte del

próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un

Incremento “Terminado”.

2.3. Estado del Arte

Actualmente existe un gran número de investigaciones con casos de estudio con

enfoques ágiles apoyados en el cliente, así como también, trabajos fundamentados en

metodologías híbridas, que combinan los mejores elementos o componentes de las

metodologías ágiles y tradicionales. No obstante, la comunicación que se emplea en el

agilismo, muchas veces no se contempla para toda la organización sino en proyectos

individuales. En este trabajo de tesis se abordan estos conceptos y se orientan en la

comunicación para todas las áreas de la organización.

Se tomaron elementos y componentes, considerados relevantes de algunos trabajos

recientes, destacando las siguientes:



36

2.3.1 Agile Methodologies for BI Projects (AMBIP)

Según comenta Nogués, (2017), las metodologías ágiles para proyectos de BI (Business

Intelligence) con el paso del tiempo pueden causar pérdidas de tiempo y esfuerzo de

desarrollo sin tener resultado, creando riesgos en el enfoque tradicional de la gestión del

proyecto. Esto pasa debido a que utilizan modelos complejos para el manejo de diferentes

fuentes de datos. Examinando y explicando también, el cómo usar lo mejor del agilismo

para la aplicación de proyectos BI y así evitar estos riesgos.

El artículo propone un mix entre SCRUM y Kanban, de las que considera el panel físico y

las reuniones diarias, lo más significativo de estas dos metodologías, que dan paso a

priorizar la evolución individual y la interacción sobre las herramientas utilizadas. Este mix

apoya mejor al desarrollo de proyectos BI. En cuanto a SCRUM, al que se le llama Sprint

0, realiza un análisis inicial más extenso a través de una herramienta de BI. También

efectúa una segmentación del proyecto, que considera diferentes involucrados de otros

departamentos para complementar conocimientos.

2.3.2 Integrating User-Centred Design in Agile Development (IUCDA)

La investigación realizada por Cockton, (2016), menciona que trabaja con UCD (User

Centred Development) en metodologías de desarrollo de software. Donde las metodologías

UCD proveían métodos integrados de manera clara, pero ha cambiado gracias a las

metodologías ágiles con el desarrollo estructurado. Es por eso que la integración del diseño

centrado en usuarios para el desarrollo ágil combina dos enfoques complementarios para el

desarrollo del software. Aplicado a pequeñas y medianas empresas.

A pesar de ser un desafío en anteriores décadas, por el uso de procesos de metodologías

tradicionales, se ha otorgado efectividad, eficiencia, satisfacción, bienestar laboral, lealtad,

retención de empleados y competitividad. UCD comparte características con las

metodologías ágiles; requerimientos iterativos, desarrollo incremental, entrega de software

en funcionamiento e introducción de colaboración personalizada con el cliente.

Por medio de los casos de estudio presentados brevemente, se analiza la integración de

actividades UCD dentro del agilismo. Los temas más abordados esta la cultura, equipos de

trabajo, tareas e indagación.

UCD y el agilismo presentan los siguientes valores:

Equipos autónomos independientes de individuos que interactúan

Software en funcionamiento que satisface a los clientes por el valor que entrega

Colaboración con el cliente, con la aceptación de los requisitos cambiantes

Prácticas flexibles para una reacción rápida a los comentarios de los clientes



37

Velocidad evidenciada en la entrega anticipada de las versiones de trabajo iniciales,

la velocidad de comercialización y la velocidad de comunicación dentro de un

proyecto con entrega a tiempo.

Visibilidad, conciencia y responsabilidad.

Productividad: capacidad de concentración sin interrupción.

Sentido de logro en relación con los roles claros y los objetivos a corto plazo.

Facilidad de desarrollo con bajo desperdicio, preferencia para métodos de peso

ligero.

Estar de moda.

2.3.3 Scaling for agility: A reference model for hybrid traditional-agile software

development methodologies (SA)

Qumer, (2016), propone un modelo de referencia para metodologías híbridas de desarrollo

de software. Este documento aborda un importante desafío y desarrolla un modelo de

arquitectura de referencia de metodología híbrida utilizando un método empírico

constructivo cualitativo del enfoque de investigación. De esta forma, se han descubierto los

elementos o componentes de agilidad, abstracción, valor comercial, política empresarial,

reglas, legales, contexto e instalaciones que no han sido explícitamente modelados o

discutidos en Estándares Internacionales (IS) como el modelo de la ISO/IEC 24744.

El modelo se realizó mediante la aplicación de un enfoque iterativo de investigación

empírica constructiva cualitativa, que permite el desarrollo y evaluación de artefactos en

iteraciones cortas. Está compuesto por 6 pasos; que básicamente se orientan en la

iniciación, desarrollo y evaluación.

2.3.4 Distributed Agile Development: A Case Study of Customer Communication

Challenges (DAD)

El caso de estudio sobre desarrollo distribuido ágil que propone Abrahamsson, (2009), el

cual enfatiza la importancia de la comunicación debido a los entornos distribuidos por

distancias temporales, geográficas y culturales. Por lo que el estudio muestra por medio de

los resultados, sugerencias sobre la eficiencia de la comunicación con el cliente

independientemente de la relación actual con los clientes y las políticas organizacionales.

Determina que la comunicación eficiente es un factor esencial en el desarrollo, el cual,

combina metodologías híbridas, que ayudan a analizar el uso de los diferentes canales de

comunicación con el cliente, detectando falta de interacción con el mismo debido a que no

existe confianza ni se comparte la información, teniendo como resultado un déficit en los

medios de comunicación utilizados.



38

2.3.5 Combining Agile and Traditional: Customer Communication in Distributed

Environment (CAT)

La investigación realizada por Korkala, (2010), señala que actualmente las empresas usan

metodologías que combinan lo tradicional y ágil en sus desarrollos de software. Ya que el

agilismo acentúa la comunicación con el cliente. Por lo que este caso de estudio revela la

clave de porqué es difícil establecer comunicación, siendo que se utilizan múltiples medios

diferentes. El artículo propone una guía que provee la información necesaria a través de las

siguientes preguntas:

¿Qué tipo de información se necesita de la otra parte?; esta información puede ser,

por ejemplo, requisitos de software, acceso al código implementado por otras

organizaciones, etc.

¿Quién proporcionará esta información?; esto se refiere a los clientes y otras partes

interesadas, relevantes que brindan la información importante para la finalización

exitosa del trabajo. Estos deben ser identificados.

¿Es posible obtener esta información cuando es necesaria?; el desarrollo ágil es

cíclico, lo que significa que parte de la información, por ejemplo, atención al cliente

durante la planificación de Sprint, se requiere a intervalos acordados. Por otro lado,

el cliente debe proporcionar información crítica para el desarrollo tan pronto como

sea posible después de haber sido solicitada. Como ejemplo, los requisitos

discutidos y acordados podrían incluir elementos ambiguos que deberían aclararse

lo antes posible. Esta pregunta tiene como objetivo aclarar si la información

necesaria se puede obtener de manera oportuna y si los clientes pueden

proporcionarla cuando sea necesario.

¿Las fuentes de información están comprometidas a proporcionar la información

cuando se acuerda?; además de la información en sí misma, la fuente de la

información es igualmente importante. Como se explicó anteriormente, el rol del

cliente ágil es más exigente que en el desarrollo tradicional. Es esencial que las

partes interesadas que proporcionan la información estén dispuestas y puedan

hacerlo.

¿Hay algo que impida obtener esta información?; como se describen las

características de la organización pueden impedir el acceso a la información de otras

partes interesadas. Deben identificarse los posibles obstáculos y soluciones para

mitigar los problemas desarrollados.

2.3.6 Project Management and Agile Methodologies: A Survey (PMA)

Dall’Agnol, (2004), a través de este trabajo examinó las analogías y diferencias derivadas

sobre el uso de metodologías ágiles en empresas desde el punto de vista de las técnicas de

gestión de proyectos. Este análisis se basó en cuestionarios hacia gerentes que utilizaban

agilismo sobre sus empleados y procesos. Esta adopción de metodologías ágiles apoya a la

mejora del desarrollo de software y la satisfacción del cliente.



39

La correlación entre la adopción de metodologías ágiles y la preferencia por el trabajo en

equipo entre los desarrolladores es otra buena estrategia basada en las personas. El trabajo

en equipo es útil para mejorar la transferencia de conocimiento, la comunicación y la

coordinación dentro de una organización. El intercambio de conocimiento dentro de un

grupo facilita su transferencia y el desarrollo de nuevas ideas.

En la Tabla 4 se muestran las características de las investigaciones mencionadas en

las secciones 2.31 a la 2.3.6. Estas investigaciones abordan desafíos de modelos de

desarrollo de software sobre la importancia de la comunicación eficiente.

Tabla 4. Comparación de trabajos de investigación con enfoque ágil basados en la comunicación

con el cliente. (Elaboración propia).

Características AMBIP* IUCDA* SA* DAD* CAT* PMA*

Metodologías ágiles

Metodologías

tradicionales

× × × ×

Orientación al cliente

Estrategias para la

comunicación

Satisfacción del cliente

Reuniones diarias × × Manejo de artefactos

Análisis inicial × × × Complejidad en

modelado de datos × × × ×

Reglas estrictas en las

metodologías × × × × ×

Calidad en uso × × × × × Usabilidad del software × × × ×

Dirección de

experiencias de usuario

× ×

Transferencia de roles × ×

Uso de medios de

comunicación

Gestión de proyectos * Las siglas se definen en los trabajos de investigación descritos en las secciones anteriores.



40

2.4. Resumen

En este capítulo menciona conceptos básicos sobre el modelo a desarrollar y la guía

para su implementación. Las herramientas referidas son las más populares en el mercado

hoy en día, de las cuales se tomaron los puntos más importantes a destacar.

Con las metodologías ágiles, el cliente se entusiasma y se compromete con el proyecto

dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento

realinear el software con los objetivos de negocio de su empresa, ya que puede introducir

cambios funcionales o de prioridad en el inicio de cada nueva iteración sin ningún

problema.

El uso de tecnologías de este tipo permite visualizar mejoras en los procesos como la

optimización de tiempos. Muchas veces este tipo de herramientas son muy costosas, tanto

la licencia como asesorías y capacitaciones, es por eso que va acompañada de una

metodología que permite una adopción más rápida que una convencional. Como otro punto

importante, se tiene la estrategia CRM antes de la adopción de la herramienta como

software, ya que primero se debe proyectar y dirigir las operaciones en la empresa y

analizar las oportunidades.

Este método de trabajo promueve la innovación, motivación y compromiso del equipo que

forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para

desarrollar sus capacidades.



41

Capítulo 3

Descripción de MOPICS

(MOdelo de mejora de procesos basado

en la Implementación de la estrategia

CRM y la metodología SCRUM)



42

Capítulo 3. Descripción MOPICS

3.1. Introducción

Este capítulo describe detalladamente el modelo propuesto en este trabajo de tesis,

MOPICS (MOdelo de mejora de Procesos basado en la Implementación de la

estrategia CRM y la metodología SCRUM) es un modelo de desarrollo de software

incremental, el cual se fundamenta en buenas prácticas de Ingeniería de Software. Como

primer lugar se tiene la estrategia CRM (Customer Relationship Management, Gestión de

las Relaciones con los Clientes), que como lo describen sus siglas, se cimienta en las

relaciones con los clientes creando un vínculo que apoya la comunicación en el desarrollo

del producto de software en un proyecto y en toda la organización. En segundo lugar se

ubica SCRUM, siendo la metodología ágil más usada hoy en día, debido a que incorpora

prácticas que ayudan a todos los integrantes del proyecto a estar comunicados en el

desarrollo de un producto. Como tercera práctica se considera el ciclo de Deming que es

una estrategia de mejora continua que hace hincapié en la calidad. Y por último, se integra

la gestión de proyectos, según lo describe el PMI A través de la guía PMBOK (2013),

como la planificación y orientación de procesos de un proyecto,

3.2. Diseño de MOPICS (MOdelo de mejora de Procesos basado en la

Implementación de la estrategia CRM y la metodología SCRUM)

MOPICS, además de integrar procesos de la estrategia CRM y de la metodología ágil

SCRUM, también adiciona algunos procesos de la gestión de proyectos (Project

Management) y el ciclo de Deming (PDCA) en el desarrollo de un proyecto, tal y como se

muestra en la Figura 4. Los procesos integrados en MOPICS, forman una estructura de TI

que se basa en las necesidades del cliente y a su vez lo apoyan, en conjunto con los

involucrados en el proyecto para el desarrollo de software requerido.

Figura 4. Procesos integrados en MOPICS. (Elaboración propia).



43

MOPICS combina una filosofía y un conjunto de directrices de desarrollo. La filosofía

busca la satisfacción del cliente y la entrega temprana de software incremental, equipos

pequeños con alta motivación, métodos informales y una simplicidad general del

desarrollo. Los procesos de desarrollo rápido de software están diseñados para producir

software útil de forma rápida. Generalmente, son procesos interactivos en los que se

entrelazan la especificación, el diseño, el desarrollo y las pruebas.

3.3. Características del modelo

El modelo diseñado para la integración de procesos dentro del desarrollo de proyectos

de software se considera un modelo de desarrollo incremental, el cual tiene como

características principales los siguientes puntos:

Desarrollo de software en proyectos empleando outsourcing por medio de empresas

de consultoría de TI.

Proyectos de tamaño pequeño a mediano para desarrollo de software, duración de

dos a seis meses aproximadamente (basado en la metodología SCRUM).

Equipos de desarrollo pequeños, de 6 a 10 miembros máximo.

Seguimiento a mantenimiento y soporte del software terminado.

Integración de todos los involucrados en el proyecto.

Redefinición de procesos. Puede ser modificado y adaptado de acuerdo a las

necesidades del software en desarrollo.

Incremento de confiabilidad y calidad del software.

Poca documentación.

El desarrollo de software trata más acerca de personas, sus interacciones y

adaptaciones a un ambiente amplio de trabajo y no sobre procesos de ingeniería.

Formación de cultura organizacional.

Atención adecuada al cliente (B2B).

Proporción de un ambiente de confianza y colaboración entre las partes

involucradas.

Los elementos frecuentes como limites a dirigirse son:

Mal información o desconocimiento de objetivos y metas.

Escases de comunicación y confianza.

Problemas interpersonales entre miembros del proyecto.

Resoluciones difusas por parte de líderes y/o directivos.

Rotación del personal.



44

3.4. Roles

Los roles son los papeles específicos que cumplen las distintas personas involucradas

en un proceso. El modelo plantea los mostrados y descritos en la Tabla 5.

Tabla 5. Roles en el modelo propuesto. (Elaboración propia).

Rol Descripción

Propietario del producto Persona que representa a la empresa cliente y a las personas

involucradas en el proyecto. Se considera la voz del cliente.

Muestra la visión del proyecto al equipo por medio de información

recopilada que ayude a formalizar los requerimientos y entregas de

valor.

Se enfoca en el negocio y es el responsable del ROI (Return On

Investment, Retorno de Inversión).

Experto Gestor de actividades del grupo de desarrolladores. Se encarga de

liderar al equipo guiándolo en los procesos de la metodología, en

camino a cumplir los objetivos establecidos en el desarrollo.

Brinda un ambiente estable de trabajo.

Trabaja en conjunto con el Propietario del producto, para

incrementar el ROI.

Gestiona el rendimiento por medio de una bitácora que reduce;

impedimentos, riesgos, amenazas, fallas, errores y defectos durante

el desarrollo.

Equipo de desarrollo Grupo de personas expertas, auto-organizado y multifuncional en el

área de conocimiento técnico para el desarrollo del proyecto.

Desarrollan los requerimientos de manera conjunta. Lo conforman

desarrolladores, probadores, analistas, ingenieros, diseñadores.

Cliente Persona, empresa u organización que financia un proyecto con el fin

de obtener un producto o servicio.

Involucrados Se consideran aquellas personas involucradas en los procesos. Son

los departamentos implicados; dirección, finanzas, recursos

humanos, pruebas, ventas, marketing, soporte, mantenimiento.

Usuario final Persona que manipulará el software final, es para quien está

realizando el diseño.

Como se puede observar en la Tabla 5, los roles son retomados de SCRUM. Se toma

especial importancia a los implicados desde el inicio del proyecto, en especial al cliente,

para proporcionar un trato personalizado y lograr una buena comunicación desde el inicio a

través de reuniones que permiten el identificar cambios estratégicos y detección de factores

clave para brindar mejores resultados, aportando beneficios a la organización en las

distintas áreas funcionales (ventas, marketing, soporte) y valor al cliente.

La Figura 5 muestra el flujo de los roles que entran en juego en el proceso. Se recomienda

que una persona desempeñe un solo rol y que esté asignada a un solo proyecto (a excepción

del cliente), ya que si se tienen más proyectos conferidos no se prestaría la debida



45

importancia al propio, por lo que se puede descuidar trabajo, crear traslape de información,

retrasos, entre otros.

Figura 5. Flujo de comunicación entre roles. (Elaboración propia).

Los roles definidos se obtuvieron a través de un análisis sobre investigación empírica, por

lo que no se realizó un análisis estadístico. Y con base en la segmentación de clientes y la

metodología que utilizaban los equipos de trabajo, se consiguieron los roles anteriormente

mencionados, dado que tiene una orientación al personal de la empresa. Se enfoca en los

empleados que son los encargados de dar la calidad al producto, puesto que ellos son los

que están directamente comunicados con el cliente (recuérdese que está enfocado al

outsourcing, donde el equipo de trabajo esta físicamente en el mismo lugar que el cliente) y

tienen tratos personalizados con el cliente en cuanto a dudas y/o aclaraciones de las

actividades y tareas del proyecto en curso. Los papeles que desempeñan cada persona en el

proyecto tiene un propósito y función, aunque los equipos sean interdisciplinarios, tienen

un rol importante.

También como factor importante a focalizar es la motivación del personal, visto que si los

empleados no tienen estímulos y ánimo para hacer el trabajo, no se brinda la calidad

deseada. La carencia de motivación en equipos de trabajo conduce a las constantes

rotaciones del personal, creando pérdidas de tiempo y costos sobre el proyecto.

3.5. Descripción de las etapas para la implementación de MOPICS

MOPICS como ciclo de vida del desarrollo de software, ofrece un marco de trabajo

para controlar y simplificar el proceso de desarrollo y para ayudar a la empresa en la



46

implementación del modelo, se siguen paso a paso las etapas del modelo; consta de cinco

etapas como se muestra en la a Figura 6, en las cuales se analiza desde cero a la

organización para después gestionar el ciclo de vida del desarrollo del producto de

software, a través de los análisis pertinentes. MOPICS toma puntos de SCRUM y por ello,

abarca la planeación, implementación, reuniones, entregas de valor y cambios durante el

desarrollo. También se incluyen procesos de la estrategia CRM, en el inicio del proyecto,

para centrarse en las interacciones de las personas implicadas en el proyecto y la evaluación

de calidad del producto. MOPICS como modelo de desarrollo incremental y basado en un

paradigma ágil, se considera un vínculo entre las áreas funcionales y el desarrollo de

software que ocasiona la mejora de procesos y relaciones interpersonales.

Figura 6. Etapas en MOPICS. (Elaboración propia).

Cada etapa cuenta con una serie de actividades y tareas que están enfocados en objetivos

organizacionales y del proyecto al que pertenecen. Las tareas se deben de cumplir en un

tiempo determinado, pero si no se llegasen a completar, ya sea por complicaciones en el

desarrollo y/o que la dificultad suba, es necesario plantear nuevamente el objetivo de la

tarea con el cliente y los líderes, para realizar los cambios pertinentes, estas aclaraciones se

pueden obtener gracias a reuniones.

3.5.1. Etapa cero (Diagnóstico organizacional)

Esta etapa se enfoca primeramente en las relaciones iniciales con el cliente y los

miembros de la organización, así como al modelo de negocio en cuanto al cómo se va a

aportar valor al cliente. Los departamentos de marketing y ventas en conjunto con el

propietario del producto asignado en el proyecto, crean las bases para la comunicación con

el cliente y así, desarrollar un producto de software a la medida según las características

que se especifiquen. La Figura 7, indica las actividades y tareas que se llevan a cabo en esta

primera etapa de MOPICS. Hay actividades y tareas que se realizan en conjunto con otros

roles y que ayudan a crear vínculos y optimizan el proceso.



47

Es necesario definir una visión y objetivos globales del proyecto, dando un mejor enfoque

en los objetivos y hacer un buen seguimiento de los mismos, a partir de un análisis inicial

poder conocer puntos fuertes y débiles de la organización, siendo crítico este análisis para

el desarrollo del proyecto y su posterior mantenimiento.

Figura 7. Etapa cero (Diagnóstico organizacional). (Elaboración propia).

En la Tabla 6, se describen las actividades mostradas en la Figura 7 y también, tareas que se

ejecutan durante la etapa cero al inicio de MOPICS. Es importante mencionar que en cada

tarea pueden tenerse varios roles participantes o también, un rol puede desarrollar una sola

actividad y/o tarea. También se crean los planes de liberaciones, que es donde acuerdan las

fechas de entrega de valor por cada Sprint, un Sprint es un periodo de tiempo establecido

para el desarrollo de determinadas actividades y tareas.

Tabla 6. Actividades y tareas de la etapa cero. (Elaboración propia).

Actividad Descripción Tareas Roles involucrados

Recopilación y

gestión de datos

Se recaban y/o actualizan

datos acerca del cliente para

la gestión de los mismos.

Estructuración del almacén

de datos del cliente

Solicitud de información

Depto. Ventas

Propietario del

producto



48

Segmentación de

clientes

Se basa en la teoría de

elección del consumidor,

donde a través de la

recopilación y actualización

de los datos del cliente, se

analiza el comportamiento del

mismo y permite saber sobre

la rentabilidad y gustos.

Análisis del cliente

División por niveles y

perfiles de cliente

Depto. Ventas

Depto.

Marketing

Generación de

estrategias

Se generan estrategias a través

del conocimiento de la

competencia. Utiliza las redes

sociales como herramienta

para promociones, entre otros.

Estrategia interna / Análisis

FODA (Fortalezas,

Oportunidades,

Debilidades, Amenazas)

Estrategia externa /

Análisis del mercado

Depto.

Marketing

Propietario del

producto

Depto. Ventas

Caso de negocio Describe la definición del

problema, visión, objetivos y

análisis del proyecto.

Enfoque panorámico del

problema y necesidades del

negocio

Visión del proyecto

(restricciones)

Alineación del proyecto

con objetivos específicos

Creación de caso de

negocio / Análisis Costo-

Beneficio (ACB)

Soluciones y aprobaciones

Propietario del

producto

Identificación de

roles

Elección de equipo de

desarrolladores. Evaluación de habilidades

y selección de roles

Capacitaciones

Propietario del

producto

Definición de

requerimientos

generales

Se obtiene información sobre

las funcionalidades del

software a grandes rasgos,

ayudando a destacar posibles

anomalías en el software a

desarrollar.

Desarrollo de

requerimientos generales

Identificación de riesgos y

valor del negocio

Creación de listado de

características y

funcionalidades del

proyecto

Establecimiento de

requisitos de evaluación de

calidad

Propietario del

producto

Cliente

Usuario Final

Creación de plan

de liberaciones

Se establecen planes para la

entrega de valor, que muestra

al cliente los avances por

Sprint.

Periodos de tiempo de

entrega por Sprint

Conjuntos de

funcionalidades por Sprint

Tiempos para cambios de

funcionalidades al final de

cada Sprint

Propietario del

producto

Cliente

Para el manejo de datos, análisis y gestión del proyecto, se tiene un criterio abierto en

cuanto a las herramientas que se quiera utilizar siempre y cuando se cumplan con los

tiempos establecidos y con los formatos que se requieran.



49

3.5.2. Etapa uno (Plan de desarrollo)

La elaboración de un plan es la parte más importante en todo proyecto, ya que es

cuando la empresa fija las metas y los procesos a utilizar, apoyándose de la toma de

decisiones. Es por eso que esta etapa del modelo se centra en planificar las metas a

desarrollar durante cada Sprint hasta llegar a la entrega de valor. En la Figura 8, se observa

la etapa de plan de desarrollo, la cual incluye a solo tres actores, dejando de lado a los

departamentos involucrados, centrándose en el cliente, propietario del producto y el experto

que en conjunto establecerán una planeación y estimación adecuada de las actividades y

tareas a desarrollar. Esta etapa está más enfocada al uso de la metodología SCRUM,

además de que estén más involucrados sus roles principales, maneja el termino de Sprint

que consiste en las iteraciones sobre el estado del desarrollo de software, este proceso se

repite hasta que se tiene el software terminado. Es por eso que se considera la utilización de

estas etapas como guía para la implementación de MOPICS, además de que se adapta a

cambios en cualquier momento del proceso.

Figura 8. Etapa uno (Planeación del desarrollo). (Elaboración propia).



50

Para la planificación se debe especificar con detalle los requerimientos, para que no haya

anomalías durante el desarrollo, ayudando a mitigar riesgos, pérdidas de tiempo y costos,

confusiones entre miembros del proyecto, entre otros. En la Tabla 7, se especifica cada una

de las actividades que tienen lugar en el plan de desarrollo, basándose en la priorización y

estimación de las actividades seleccionadas para cada Sprint y especificando las tareas

relacionadas con cada una.

Tabla 7. Actividades y tareas de la etapa uno. (Elaboración propia).


Definición de

requerimientos

específicos

Se expresan los

requerimientos sobre

funcionalidades específicas

del software.

Requerimientos que

expresen funcionalidad

Descripción de criterios de

aceptación

Especificación de

evaluación de calidad

Propietario del

producto

Experto

Cliente

Priorización y

estimación de

requerimientos

específicos

Es la selección de

preferencias sobre los

requerimientos, estableciendo

una valoración.

Aplicación de técnicas de

estimación a

requerimientos específicos

Tamaños y esfuerzos por

requerimiento

Priorizaciones antes del

Sprint

Propietario del

producto

Experto

Cliente

Planeación de

tiempos por

Sprint

Se especifican las

características principales a

asignar en cada iteración.

Número y duración de cada

Sprint

Asignación de

requerimientos para cada

Sprint

Planeación de reuniones

Cronograma de actividades

para la evaluación de

calidad

Propietario del

producto

Experto

Definición de

actividades y

tareas por Sprint

Se reparten actividades con

sus respectivas tareas para

cada iteración y se explica, en

que consiste cada una.

Descripción de actividades

Evaluación de tiempos de

actividades

Descripción de tareas por

actividad

Evaluación de tiempos de

tareas

Propietario del

producto

Experto

Priorización y

estimación de

actividades y

tareas

Se aplican técnicas de

estimación a las diferentes

actividades para asignarlas a

una iteración dependiendo de

su complejidad e importancia.

Aplicación de técnicas de

estimación a actividades

Selección de actividades a

desarrollar en cada Sprint

Asignación de tareas al

equipo de trabajo

Propietario del

producto

Experto

Uso de

herramientas

Son las herramientas de

software de las cuales se

apoyan los miembros del

proyecto para desarrollar y

gestionar parte del proyecto.

Preparación de ambientes

Documentación

estandarizada

Propietario del

producto

Experto



51

3.5.3. Etapa dos (Implementación)

La etapa de implementación se encarga de todo el desarrollo del código que da lugar

a las funcionalidades del software, abarcando varios puntos que permitirán validar y

verificar el resultado obtenido. La Figura 9 ilustra las actividades que se efectúan en un

tiempo determinado, donde se involucran líderes, desarrolladores y el cliente dando lugar a

una buena comunicación, que sostenga los posibles cambios de funcionalidades (si es el

caso) y de paso a la mejora continua del proceso.

Figura 9. Etapa Dos (Implementación). (Elaboración propia).

Las actividades que se realizan durante esta etapa de MOPICS se centran en el código,

donde se está evaluando constantemente el estado de las funcionalidades que sean las

adecuadas y que no haya defectos durante el desarrollo.

En la Tabla 8 se describen las actividades en conjunto con las tareas específicas para cada

una, que darán lugar al desarrollo del software.

Tabla 8. Actividades y tareas de la etapa dos. (Elaboración propia).

Actividad Descripción Tareas Roles involucrados Desarrollo de

entregables Se encarga del desarrollo del

software por funcionalidades,

realización del código fuente

por los desarrolladores, guiado

por el Product Owner y el

SCRUM Master.

Desarrollo de tareas

Experto

Equipo de

desarrollo

Aseguramiento de

ambiente de trabajo Experto

Reuniones de

aclaración de

especificaciones

Diseño de la evaluación

de calidad

Propietario del

producto

Experto

Equipo de

desarrollo



52

Creación de bitácora de

limitaciones y riesgos

Experto

Documentación Experto

Equipo de

desarrollo

Refinación de

prioridades Si existen cambios en el

desarrollo, se replantean las

prioridades sobre las

actividades y/o tareas si es

necesario, ya sea que los

requiera el cliente o por

dificultades en la elaboración.

Incorporación de

cambios

Detección de nuevos

riesgos

Actualización de

información

Experto

Equipo de

desarrollo

Revisión de

entregables Se compromete a la revisión

de las entregas de valor al

cliente al final del desarrollo

por Sprint, ayuda al

aseguramiento de la calidad

del software.

Revisión de estándares

de calidad

Propietario del

producto

Cliente

Validación y

verificación de

requerimientos

específicos de los

entregables

Toma de medidas para

métricas de evaluación

de la calidad

Propietario del

producto

Experto

Cliente

Pruebas (Testing)

Reunión de

retrospectiva del Sprint

Propietario del

producto

Experto

Equipo de

desarrollo

Rechazo de entregables Identificación de

mejoras potenciales a

procesos

Propietario del

producto

Experto

3.5.4. Etapa tres (Entrega de valor y liberaciones)

Para la liberación de entregables como etapa de entrega de valor al cliente, se

tuvieron que acondicionar requerimientos, mejoras, recomendaciones, refinamientos,

críticas, que ayudan a enriquecer el proceso y el desarrollo del software en el proyecto.

Como se puede observar en la Figura 10, el cliente es el responsable de aceptar o rechazar

las funcionalidades realizadas al término de la iteración o en la culminación del software,

siendo antes probadas y validadas. MOPICS considera la entrega de valor como una de las

partes más importantes, a partir de esta se obtiene la medición de la satisfacción y calidad

del software terminado cuando ya está en producción, la opinión del cliente debe ser

prioridad para cualquier empresa.



53

Figura 10. Etapa tres (Entrega de valor). (Elaboración propia).

La Tabla 9 ilustra las actividades y tareas relacionadas con cada una, de la entrega de valor

junto sus correspondientes tareas. El cliente, el propietario del producto y el experto son los

encargados del desarrollo de esta etapa, el propietario del producto se encarga de mediar

adecuaciones al final de las iteraciones.

Tabla 9. Actividades y tareas de la etapa tres. (Elaboración propia).


Liberación de

entregables por

Sprint

Se adaptan los cambios

necesarios y se programan

actividades pendientes para el

próximo Sprint.

Adecuación de

requerimientos para el

siguiente Sprint

Liberación de entregable

Pruebas

Propietario del

producto

Experto

Cliente

Liberación de

entregable final

Al concluir los Sprints y

teniendo el software

funcionando por completo, se

hace la entrega final al cliente,

listo para ser usado por el

usuario final.

Entrega final al cliente

Reunión para la

identificación de mejoras a

futuros proyectos y mejores

practicas

Pruebas

Propietario del

producto

Cliente

Mejora continua Se analizan los procesos

realizados y se determina si es

posible optimizarlos.

Análisis recomendaciones

Propietario del

producto

Cliente



54

Refinamiento y

optimización de procesos

Ejecución de la evaluación

de calidad

Propietario del

producto

Experto

3.5.5. Etapa cuatro (Satisfacción del cliente)

El cliente es la razón de ser de cualquier empresa, por eso que la empresa debe de

crear estrategias que logren mantener clientes y atraer nuevos, además de incluir la calidad

en sus productos y servicios. La Figura 11 señala los criterios de calidad que se cumplieron

después de la entrega final del software. A través del mantenimiento y soporte, se obtienen

métricas que muestran el rendimiento del sistema, ya sea por medio de comparaciones con

otros sistemas (también llamado Benchmark) y con la gestión de incidencias. La

documentación siempre es un factor importante en cualquier proyecto, gracias a ella se

tiene el respaldo sobre funcionalidades de manera que se pueda entender por cualquier

miembro del proyecto.

Figura 11. Etapa cuatro (Satisfacción del cliente). (Elaboración propia).

Teniendo en cuenta la prestación de servicios dentro del sector de las TI, hoy en día existen

empresas con los mismos mercados y cuentan con mejor calidad, de tal forma que los

clientes se retienen al generar una buena satisfacción. La Tabla 10 indica las actividades

que guiarán a la empresa a crear las soluciones que el cliente busca.

Tabla 10. Actividades y tareas de la etapa cuatro. (Elaboración propia).


Análisis de

métricas de

calidad

Se basa en la evaluación

resultante de calidad del

producto de software.

Enfocándose en los procesos,

cumplimiento de

Revisión y comparación

de las medidas de los

criterios de aceptación

Valoración de

resultados

Propietario del

producto

Experto

Cliente



55

requerimientos y el software

funcionando. Mejora continua

Mantenimiento Se provee servicio para

conservar el producto

terminado en cuanto respectan

fallas, errores, bugs, entre

otros, que se presenten durante

su uso y actualizaciones que

se requieran.

Mantenibilidad

Gestión de

incidencias

Experto

Equipo de

desarrollo

Rendimiento del

sistema (Benchmark) Propietario del

producto

Experto

Como cualquier otro producto, el software también está sujeto a la evaluación de calidad,

de tal manera que los clientes y/o usuarios establezcan el grado de satisfacción que cumpla

sus necesidades.

Según el portal ISO 25000 (2017), menciona que “la calidad del producto, junto con la

calidad del proceso, es uno de los aspectos más importantes actualmente en el desarrollo de

software. Relacionada con la calidad del producto, recientemente ha aparecido la familia de

normas ISO/IEC 25000, que proporciona una guía para el uso de la nueva serie de

estándares internacionales llamada Requisitos y Evaluación de Calidad de Productos de

Software (SQuaRE - System and Software Quality Requirements and Evaluation). ISO/IEC

25000 constituye una serie de normas basadas en ISO/IEC 9126 y en ISO/IEC 14598 cuyo

objetivo principal es guiar el desarrollo de los productos de software mediante la

especificación de requisitos y evaluación de características de calidad.”

La calidad del producto de software se obtiene de la medición de sus componentes y el

software funcionando. La medición se consigue a través de entrevistas, cuestionarios y

respuesta del producto de software. Cabe mencionar que no se considera este tipo de

mediciones como certificación sobre una norma ISO, ya que estas se realizan por medio de

auditores expertos y verificados, pero si se requiere de una aplicación más formal de la

norma se puede contratar dicha auditoria. Estas mediciones son de uso interno sobre la

mejora de utilización de recursos en la organización.

En el apéndice 2 se encuentran detalladas las características de las normas ISO en las que se

basó la evaluación del producto de software, así como también se toman varios puntos

como referencia de una herramienta para la evaluación del modelo de calidad, León N.

(Agosto 2011).

3.6. Resumen

MOPICS como un modelo que engloba una estrategia CRM y una metodología ágil

como lo es SCRUM, contempla también la gestión de proyectos gracias a administración de

interacciones generadas, que ayudan a crear una sólida comunicación en general. Las etapas

incluyen desde análisis de la empresa hasta gestión de calidad, permitiendo una guía



56

completa para el desarrollo de un proyecto. En cuanto al sector al que va dirigido, al

utilizarse etapas, actividades y tareas, mantiene facilidad de adaptación, así que no necesita

de capacitación si se conoce la forma de trabajo de las metodologías ágiles.

Toda gestión de proyectos exige una rigurosa documentación, es por eso que MOPICS,

como el manifiesto ágil lo menciona, no necesita de documentación exhaustiva. Las

personas, interacciones, funcionamiento de software y respuestas al cambio, van por

delante de los procesos, documentación y planes lineales.



57

Capítulo 4

Caso práctico: Aplicación de

MOPICS en una empresa del

Sector Consultoría de TI.



58

Capítulo 4. Caso Práctico

4.1. Introducción

MOPICS se basa la aplicación de mejora de procesos en el desarrollo de software de

proyectos en el Sector Consultoría de TI, dirigiéndose en específico al área del outsourcing.

El Sector Consultoría en TI se enfoca a aquellas empresas con proyectos pequeños y

medianos, que prestan servicios de TI en rubros como consultoría, aplicaciones,

infraestructura, ingeniería de sistemas, gestión del cambio, business intelligence, estrategia

de cliente, innovación, cadenas de suministro, ventas y marketing, entre otros. Y por el otro

lado, CRM brinda apoyo a las distintas áreas de la empresa, con la mejora de procesos y

gestión de las relaciones con el cliente.

A continuación se mencionará un ejemplo de la aplicación de la guía de MOPICS en una

empresa de consultoría donde se detallan los pasos seguidos en un proyecto de desarrollo.

4.2. Descripción de empresas participantes

4.2.1. Empresa de consultoría y desarrollo de software (proveedor)

Se denomina “Consultora X” a una empresa basada en asesoramientos tecnológicos

y empresariales, especializados en el desarrollo, implantación e integración de TI, ligados a

los sectores de banca, seguros, TELCO, industria y administraciones públicas. Emplea

personal de diferentes rubros en el área de las TI; programadores, analistas, administradores

de proyectos, ingenieros, entre otros. También cuenta con una amplia cartera de clientes,

que se les explota personal externo por proyecto. Cada empresa cliente cuenta con un

portafolio de proyectos, los cuales se manejan tiempos definidos y cortos; que además

cuenta con personal externo a través de distintas empresas (outsourcing). En el proceso de

acordar los servicios que brinda la empresa consultora, acuerdan la forma de trabajar para

el proyecto y siempre recomienda emplear el tipo de metodología ágil SCRUM, porque se

obtiene valor a medida que se va desarrollando el proyecto, además de que se adapta a los

tiempos y procesos definidos por el cliente.

4.2.2. Descripción de la Empresa cliente

El “Banco Y” es una institución financiera prestadora de servicios de cambio,

transferencias de fondos, pagos y cobranzas, créditos y otros de similar naturaleza. Esta

institución consta con una sede donde se operan varias áreas como lo son finanzas,

sistemas, administrativos, soporte, aclaraciones, entre otras. Así mismo esta institución

financiera maneja una banca en línea, donde sus clientes (usuario final) manipulan sus

cuentas bancarias a través del sitio web, donde la seguridad en el sistema es primordial y



59

por eso se requieren autenticaciones para realizar cualquier tipo de operación. A este sitio

web, cada periodo de tiempo se le realizan actualizaciones o se agregan nuevas

funcionalidades, por lo que se requiere el desarrollo de proyectos en periodos de tiempo

bien definidos y cortos. En el desarrollo de estos agregados a la banca en línea, se contrata

personal externo por proyecto.

4.3. Actividades y tareas de MOPICS

Para comenzar, se necesita que todo el personal en el proyecto tenga buena

disposición a colaborar con todas las partes involucradas, estar abierto a nuevas formas de

trabajo y a emplear valores organizacionales. Requiere cambios en cultura, procesos y

sistemas de toda la organización. Con base en las etapas de MOPICS descritas en el

Capítulo 3 de este documento de tesis, se describen las actividades y tareas a seguir.

El proyecto que se tiene con la institución bancaria se centra en una campaña de publicidad

en la banca en línea con la cual ya se cuenta, donde se ofertan servicios extra, como lo son

apertura de cuentas, tarjetas adicionales, créditos e hipotecas, seguros, entre otros. Este

proyecto adiciona una ventana portal web.

La guía es supervisada y aplicada por el propietario del producto, el cual además de ser la

voz del cliente, realiza entrevistas y cuestionarios con preguntas clave cada semana a todos

los integrantes del proyecto.

Las herramientas con las que se apoyan para la gestión del proyecto son:

Jira, software para la gestión de proyectos (agilismo),

Kanban, tablero físico con post-its.

4.3.1 Diagnóstico organizacional

E0. Etapa Cero

A0.1. Recopilación y gestión de datos

T0.1.1. Estructuración del almacén de datos del cliente.

El comercial asignado al proyecto en conjunto con el área de administración

de proyectos de la consultora, generan en un archivo de Excel en Google

Drive compartido como base de datos.

T0.1.2. Solicitud de información.

El Propietario del producto asignado al proyecto en conjunto con el área

administrativa y ventas, se encargan de actualizar y gestionar información

general del “Banco Y” por medio de formatos proporcionados por la



60

“Consultora X”, el “Banco Y” ya ha solicitado anteriormente los servicios

con la “Consultora X”. Los datos a actualizar son los de la persona

encargada del seguimiento al proyecto y del proyecto en sí; duración del

proyecto, fecha de inicio y fin del proyecto, herramientas a usar, procesos

clave, rubros a solicitar, etcétera.

A0.2. Segmentación.

T0.2.1. Análisis del cliente

El departamento de ventas y marketing, subrayan las peticiones del “Banco

Y” para apoyar a la incorporación de necesidades que satisfagan el

desarrollo del proyecto y que además, ayude a la comunicación entre

departamentos dentro la “Consultora X”. Lo que más le interesa al “Banco

Y” es el mantener al margen a los involucrados por medio de reportes claros,

documentación estandarizada, comunicación constante entre el equipo de

trabajo y los gestores, cumplimiento de tiempos, experiencia en el equipo de

desarrolladores sobre el lenguaje de programación a utilizar y personal

responsable. También se analiza al encargado del seguimiento del proyecto

de parte del cliente donde se toman en cuenta aspectos personales; el

encargado es una persona seria, puntual, quiere tener las cosas claras,

indeciso, fácil de contactar, de difícil convencimiento.

T0.2.2. División por niveles y perfiles de cliente

Los departamentos de ventas y marketing, a través de los datos obtenidos,

asignan un perfil de pirámide para clientes de servicio/ventas y se clasifica

como cliente habitual, en el nivel 2 gracias a que ha trabajado anteriormente

en dos proyectos y se le tiene un trato especial.

A0.3. Generación de las estrategias

T0.3.1. Estrategia interna / Análisis FODA (Fortalezas, Oportunidades, Debilidades

y Amenazas)

El propietario del producto realiza un análisis sobre el proyecto en puerta.

Donde se obtiene un documento sencillo como diagnóstico inicial.

Destacando la siguiente información:

Fortalezas; buen ambiente laboral, conocimiento del mercado, buena calidad

del producto final, experiencia de los recursos humanos, procesos técnicos y

administrativos regulares.

Debilidades; salarios bajos, equipo viejo, falta de capacitación, problemas

con la calidad, reactividad en la gestión, mala situación financiera,

incapacidad para ver errores, capital de trabajo mal utilizado, falta de



61

motivación de los recursos humanos, producto o servicio sin características

diferenciadoras.

Oportunidades; competencia débil, mercado mal atendido, necesidad del

producto, tendencias favorables en el mercado.

Amenazas; cambios en la legislación, competencia muy agresiva, aumento

de precio de insumos, segmento del mercado contraído, tendencias

desfavorables en el mercado, competencia consolidada en el mercado,

inexistencia de competencia.

Percibiendo un amplio énfasis en la motivación al personal para así lograr un

servicio y/o producto de calidad.

T0.3.2. Estrategia externa / Análisis de mercado

Se ha detectado que el cliente se enfoca al trabajo en equipo y la

comunicación es primordial en su equipo de trabajo, por lo que la

capacitación a nivel organizacional es fundamental.

A0.4. Caso de Negocio

T0.4.1. Enfoque panorámico del problema y necesidades del negocio

Se va a desarrollar una pestaña al portal web para la gestión de préstamos

personales, como dominio del problema se tienen el conjunto de conceptos

relacionados, como lo son el usuario, acceso en línea, contrato, préstamo

personal, póliza, cuenta bancaria, numero de cliente, etcétera. El problema es

que no existe un sitio específico en el portal web donde gestionar datos sobre

el préstamo que se adquirió y los usuarios finales, encuentran desesperante

cuando solicitan información vía telefónica o directamente en la sucursal.

Los procesos de negocio que se consideran prioritarios son el login del

usuario con su número de contrato, consulta de saldos y estados de cuenta,

registro de operaciones, cambios en datos personales, créditos, ofertas, entre

otras. En la Figura 12, se muestran los componentes principales del modelo

de caso de negocio a tomar en cuenta.



62

Figura 12. Elementos del modelo de negocio. (Elaboración propia).

T0.4.2. Visión del proyecto

Se describe la información sobre el proyecto, su ejecución y propósito.

Regido por los objetivos, métricas e indicadores de éxito. Las premisas y

restricciones para el logro de objetivos y recursos en el proyecto.

T0.4.3. Alineación del proyecto con objetivos específicos

Mediante una reunión con el cliente y sus interesados, se recopilan las

peticiones más relevantes como tipo requerimientos generales dirigidos

como expectativas sobre el personal. Hace referencia al plan estratégico de

la organización.

T0.4.4. Creación de caso de negocio / Análisis Costo-Beneficio (ACB)

El Propietario del producto hace un análisis especificando los costos y

beneficios del proyecto donde son clave la toma de decisiones sobre el caso

de negocio.

T0.4.5. Soluciones y aprobaciones

Se describen posibles alternativas sobre el proyecto y explica por qué no se

seleccionaron las demás. Para el final se aceptan las soluciones por algún

directivo o el Propietario del producto.



63

A0.5. Identificación de roles

T0.5.1. Evaluación de habilidades y selección de roles

El propietario del producto, después de la información obtenida del

proyecto, evalúa al personal sin proyecto asignado para ser parte del equipo

de desarrollo y/o experto, si es necesario contacta al departamento de

recursos humanos para contratar alguien que cumpla con el perfil.

T0.5.2. Capacitaciones

Se recomienda que los miembros que formarán parte del equipo de

desarrollo y el experto tengan conocimiento sobre paradigmas ágiles y si es

necesario, introducir al usuario final y el encargado del proyecto de parte del

“Banco Y” a las capacitaciones.

A0.6. Definición de requerimientos generales

T0.6.1. Desarrollo de requerimientos generales

En esta tarea el usuario final y el “Banco Y” en conjunto con el propietario

del producto se reúnen para especificar las peticiones generales del

desarrollo, se consideran importantes y frecuentes para el producto a

desarrollar.

T0.6.2. Identificación de riesgos y valor del negocio

Mediante los requerimientos previamente obtenidos, se realiza una lista de

riesgos para la identificación de vulnerabilidades y amenazas en el

desarrollo.

T0.6.3. Creación de listado de características y funcionalidades del proyecto

Se enlistan las características y funcionalidades más importantes para el

desarrollo del proyecto. Entre las que se pueden recalcar las peticiones del

usuario final como prioridad.

A0.7. Definición de calidad del producto de software

T0.7.1. Gestión de calidad (ISO/IEC 25001)

Como planeación y gestión de la calidad del software, se gestiona la

evaluación y especificación de los requerimientos del producto a desarrollar.

T0.7.2. Calidad en uso (ISO/IEC 25010)

En cuanto a modelos de calidad en el software, determina las características

y sub-características de la calidad para evaluar el software.



64

T0.7.3. Medición de la calidad (ISO/IEC 25021)

Específica y los elementos de medidas de calidad para las métricas usadas

para todo el ciclo de vida del desarrollo del software.

A0.8. Creación de plan de liberaciones (entregas de valor)

T0.8.1. Periodos de tiempo de entrega por Sprint

El propietario del producto se encarga de calcular los tiempos a partir de los

requerimientos en lista y se acuerda con el “Banco Y”, los bloques de tiempo

para el desarrollo de componentes a entregar funcionando en cada Sprint. En

este proyecto se tomaron en cuenta cuatro Sprints porque se considera un

pequeño desarrollo.

T0.8.2. Conjuntos de funcionalidades por Sprint

Y una vez establecidos los bloques de tiempos, se seleccionan y determinan

los requerimientos a cubrir por cada Sprint. El usuario final y el

representante del “Banco Y”, se encargan de elegir las funcionalidades por

Sprint dependiendo de su valor. Por lo general las funcionalidades básicas se

toman en el primer Sprint para facilitar el trabajo de las demás.

T0.8.3. Tiempos para cambios de funcionalidades al final de cada Sprint

Es importante el tomar en cuenta los cambios durante todo el proyecto, el

modelo se basa en un paradigma ágil que tiene como objetivo es estar sujeto

al cambio.

4.3.2 Plan de desarrollo

E1. Etapa Uno

A1.1. Definición de requerimientos específicos

T1.1.1. Requerimientos que expresen funcionalidad

A partir de los requerimientos generales se generan especificaciones de cada

uno de estos requerimientos. Una funcionalidad muy general se convierte en

una o varias actividades.

T1.1.2. Descripción de criterios de aceptación (objetividad)

El propietario del producto y el cliente acuerdan las características que se

deben cumplir en las actividades al término del desarrollo del primer Sprint.

Los probadores son los encargados de validar y verificar dichos criterios de

aceptación.



65

A1.2. Priorización y estimación de requerimientos específicos

T1.2.1. Aplicación de técnicas de estimación a requerimientos específicos.

El equipo de desarrollo en conjunto con el experto se valoran los

requerimientos específicos, con ayuda de técnicas de estimación de tiempos

y horas que les tomara el desarrollo. Se eligió la técnica paramétrica porque

se cuenta con información del proyecto anterior.

T1.2.2. Tamaños y esfuerzos por requerimiento

Una vez con la técnica de estimación paramétrica, se procede a identificar

todos y cada uno de los elementos necesarios para el progreso de la petición.

Se toman en cuenta la voz del desarrollador, ya que de ellos depende el

incremento del valor y se de retroalimentación con una motivación diaria a

través del énfasis en el trabajo bien hecho y con incentivos.

T1.2.3. Priorizaciones antes del Sprint

El cliente aprueba las estimaciones y las ordena de manera que se tengan las

más relevantes como principio del desarrollo.

A1.3. Planeación de tiempos por Sprint

T1.3.1. Número y duración de cada Sprint

Se calcula el tiempo estimado para la primera entrega de valor, se toman en

cuenta los tiempos sobre los requerimientos y actividades a desarrollar en las

diferentes instancias.

T1.3.2. Asignación de requerimientos para cada Sprint

Para cada Sprint se asignan los requerimientos con el mayor número de

estimación y que están como prioridad para el cliente. Estos requerimientos

se dividen a su vez en actividades y tareas que el equipo de desarrollo se

reparte para su ejecución, el equipo de trabajo es multidisciplinario, por lo

que no debe de haber problema en el desarrollo de la tarea.

T1.3.3. Planeación de reuniones

Se tienen planeadas tres tipos de reuniones. La primera es al principio del

Sprint, se especifica lo que se tiene planeado para cada Sprint. La segunda es

la reunión diaria, que sirve como revisión de dudas y comentarios para

informarse del estado de las tareas y no debe tomar más de 15 minutos. Y la

tercera reunión es la reunión de retrospectiva al término del Sprint, donde se

revisa los resultados del Sprint y se recalcan puntos a mejorar.

A1.4. Definición de actividades y tareas por Sprint



66

T1.4.1. Descripción de actividades

Se especifican las actividades en las cuales se basaran las funcionalidades

del producto.

T1.4.2. Evaluación de tiempos de actividades

Una vez definidas las actividades, se estiman las horas hombre que se

necesitaran por actividad.

T1.4.3. Descripción de tareas por actividad

Con las actividades estimadas de tiempos, se dividen a su vez en tareas que

especifican el desarrollo de los componentes que darán lugar a las

funcionalidades.

T1.4.4. Evaluación de tiempos de tareas

Cuando se han especificado las tareas se procede a tener una estimación de

tiempos en intervalos más cortos para cada tarea.

A1.5. Priorización y estimación de actividades y tareas

T1.5.1. Aplicación de técnicas de estimación a actividades

Las técnicas de estimación la mayoría del tiempo son dadas por el cliente, ya

que él es el que asigna la importancia de las funcionalidades.

T1.5.2. Selección de actividades a desarrollar en cada Sprint

Con base en la priorización anterior, se eligen las actividades a desarrollar en

un Sprint dependiendo del porcentaje de prioridad que se les asigno y de

cubrir el tiempo determinado del Sprint sin que se tenga exceso de trabajo y

tiempos muertos.

T1.5.3. Asignación de tareas al equipo de trabajo

El equipo de desarrollo se encarga de valorar la importancia de las tareas por

actividad para después asignarse a cada uno de los miembros del equipo de

desarrollo. Esto ayuda a que los equipos trabajen más en conjunto y a ser

multidisciplinarios.

A1.6. Uso de herramientas

T1.6.1. Preparación de ambientes (instalación de software)

Se acondicionan las herramientas que se utilizaran durante el proyecto en los

equipos de los miembros del equipo, también se incluye al Propietario del

producto y el cliente para aquel software que servirá de gestión de proyectos.

Muchas veces resulta más sencillo para la gestión del proyecto el manejar la

paquetería estándar de forma compartida.



67

T1.6.2. Documentación estandarizada

La documentación no es primacía pero se toma la necesaria para efectos del

proyecto dependiendo del cliente.

4.3.3 Implementación

E2. Etapa Dos

A2.1. Desarrollo de entregables (software)

T2.1.1. Desarrollo de tareas

El equipo de desarrollo trabaja en el desarrollo de las tareas. Las tareas

pueden ser desde documentación hasta la elaboración del código.

T2.1.2. Aseguramiento de ambiente de trabajo

El experto guía al equipo de desarrollo en el progreso de las tareas en cuanto

a teoría, prácticas y reglas. El experto es el responsable de las interacciones

con los involucrados en el proyecto.

T2.1.3. Reuniones para aclaración de especificaciones

Se realizan reuniones diarias entre el cliente, propietario del producto,

equipo de desarrollo y experto, donde se revisan temas puntuales sobre las

tareas que se están llevando a cabo en el momento.

T2.1.4. Creación de bitácora de limitaciones y riesgos

La bitácora de limitaciones y riesgos la elabora el experto, en la cual se

precisan los impedimentos y posibles peligros que se presentan durante el

desarrollo de las tareas en el momento.

A2.2. Refinación de prioridades

T2.2.1. Incorporación de cambios

Para integrar cambios que el cliente requiera durante las actividades en

proceso, el propietario del producto se compromete a adicionarlos en los

requerimientos específicos para así ponerlos en práctica, solo preocupándose

por los detalles necesarios. Estos requerimientos específicos se tienen

alojados en una lista que se encarga de acomodarlos de formar priorizada.

T2.2.2. Detección de nuevos riesgos



68

A la hora de tener en cuenta cambios se deben tener en cuenta también los

riesgos que implicarían. Estos riesgos se resuelven en la gestión de riesgos.

T2.2.3. Actualización de información

El seguimiento de la información se realiza con apoyo de herramientas.

A2.3. Revisión de entregables

T2.3.1. Revisión de estándares de calidad

Antes de realizar pruebas de las funcionalidades por entregar, se tienen que

chequear los estándares que permiten demostrar la calidad al cliente de

forma cualitativa que se tengan el respaldo oficial del desarrollo.

T2.3.2. Pruebas

Después de realizar las revisiones correspondientes a los estándares

definidos con el cliente, se realizan pruebas sobre los componentes

funcionando para la comprobación del uso según los requerimientos, estas

pruebas se realizan antes de ser aprobadas por el cliente y el usuario final.

T2.3.3. Validación y verificación de requerimientos específicos de los entregables

Estas ratificaciones las realiza el propietario del producto en apoyo con el

equipo de desarrollo y experto para revisar si se cumplió lo acordado.

T2.3.4. Rechazo de entregables

Si no se efectuaron al pie de la letra algunas actividades o requerimientos en

específico, se procede a rechazar el entregable por parte del propietario del

producto para efectos de medición de satisfacción con el cliente. El

propietario del producto es la voz del cliente y es el primer filtro antes de la

manipulación del software con el cliente y usuario final.

T2.3.5. Reunión de retrospectiva de la Sprint

Una vez finalizada la revisión con el propietario del producto, se convoca a

una junta con todos los involucrados para repasar el Sprint, para la solución

de problemas, identificación de mejoras, cumplimiento de requerimientos,

colaboración de todos los equipos, etcétera. Si no se cumplieron los

requerimientos que se habían acordado desde el inicio, ya sea por constantes

cambios, incidentes, problemas, errores o fallas, se retoman para el siguiente

Sprint y se ajustan los tiempos.

T2.3.6. Identificación de mejoras potenciales a procesos

Las mejoras de procesos se obtienen después de haber tenido la reunión de

revisión del Sprint, estas mejoras se toman en cuenta para el siguiente Sprint

y para el equipo en general.



69

Figura 13. Proceso de vinculación de las partes involucradas. (Elaboración propia).

4.3.4 Entregas de valor

E3. Etapa Tres

A3.1. Liberación de entregables por Sprint

T3.1.1. Liberación de entregable por Sprint

Se hace la entrega con el cliente del producto de software al terminar el

Sprint, donde el usuario final y el cliente manipulan el software para efectos

de aprobación de los requerimientos.

T3.1.2. Adecuación de requerimientos para la siguiente Sprint

Cuando ha culminado el Sprint y se hace la entrega al cliente, si no se

cubrieron los requerimientos y/o actividades estimadas, se incorporan al

siguiente y se ajustan los tiempos.

A3.2. Liberación de entregable final

T3.2.1. Entrega final al cliente

Ya culminados todos los Sprints del proyecto, se prepara el software para ser

entregado de manera formal al cliente, junto con la documentación obtenida

durante el ciclo de vida del software.

T3.2.2. Identificación de mejoras a futuros proyectos y mejores prácticas

Para finalizar, se reúnen todos los aspectos buenos y malos que apoyarán la

mejora de futuros proyectos con base en la experiencia adquirida durante el

ciclo de vida del software.



70

A3.3. Mejora continua

T3.3.1. Análisis recomendaciones

De la identificación anterior, se recopilan las recomendaciones más

relevantes, tanto internas como externas de la organización, para mejorar la

calidad del servicio en cuanto al desarrollo del software.

T3.3.2. Refinamiento de procesos

Los procesos se tratan de optimizar para garantizar la eficiencia en las

actividades de la empresa, llegando a su cliente satisfaciendo sus

necesidades de una forma competitiva, eficiente y con rentabilidad.

4.3.5 Satisfacción del cliente

E4. Etapa Cuatro

A4.1. Análisis de métricas

T4.1.1. Análisis de métricas de procesos

Hace una distinción de la medición y monitoreo obtenidos del desempeño de

los procesos. Esta distinción se representa con graficas que son el soporte del

análisis para la obtención de la satisfacción medible.

T4.1.2. Análisis de métricas del producto /servicio

Las métricas del producto se sustentan en las preguntas clave que se le hacen

al cliente al término de los servicios prestados. Se toman todas las críticas y

se trata de tener un criterio neutral que refuerce las relaciones entre las

empresas cliente.

T4.1.3. Revisión de criterios de autenticación de la calidad por medio del análisis de

procesos

Los criterios de autenticación son factores clave en la calidad de un software

para la medición y el monitoreo de la calidad. Con anterioridad, se toman en

cuenta aspectos de la calidad en el diagnóstico organizacional y

considerando estos criterios para futuros proyectos o para el mantenimiento

del producto terminado.

T4.1.4. Aplicación de mejora continúa

Cuando se aplican los pasos anteriores se considera una mejora continua que

defiende los ideales de la empresa consultora para brindar un mejor servicio

a las empresas clientes que lo soliciten y conseguir, mayor rentabilidad en



71

los servicios proporcionados gracias al trato con las personas involucradas

en el proyecto. Si es necesario se omite o adiciona documentación.

A4.2. Acuerdos de niveles de servicio (SLA – Service Level Agreement)

T4.2.1. Gestión de incidencias

Con respecto a los SLA que se consideran dentro del mantenimiento del

software, se acuerda el nivel de la calidad del servicio de empresa consultora

a empresa cliente. Las incidencias responden a aspectos tales como tiempo

de respuesta, disponibilidad horaria, documentación disponible, personal

asignado al servicio, etc.

T4.2.2. Rendimiento del sistema (Benchmark)

El Benchmark se tiene en cuenta como un factor del SLA, que es la

medición del rendimiento del software en funcionamiento como comparativa

con software similar.

T4.2.3. Documentación

La documentación y el mantenimiento van de la mano, porque enseñan a al

usuario final a usar el software y a los programadores a mantenerlo

funcionando de manera óptima. También se documentan problemas, fallas,

errores y defectos constantes durante el mantenimiento del software.

4.4 Evaluación de MOPICS

Se utilizaron algunas técnicas para la evaluación de MOPICS que definen la forma

de valorar la calidad de los productos de software y el modelo de calidad, donde se

determinaron las características de las normas ISO/IEC 9126, ISO/IEC 14598 y la sucesora

de las dos normas anteriores, ISO/IEC 25000. A través de los resultados obtenidos de las

características, subcaracterísticas, métricas y parámetros recolectados de dichas normas, se

muestra la calidad lograda.

La evaluación consideró la calidad como objetivo principal, a través de la comunicación

como resultado del trabajo en equipo y el software funcionando con base en las

expectativas del cliente y/o usuario final. Como particularidades se contempla la calidad

interna, calidad externa, calidad en uso y el modelo de calidad.

Las mediciones conseguidas de la aplicación de MOPICS fueron realizadas por el

propietario del producto, ya que él es el miembro del proyecto que tiene un mayor flujo de

comunicación con todos los involucrados. A través de estas valoraciones, el propietario del

producto genera la evaluación final que permite, además de aclarar que funciona el modelo,

saber cuál es el porcentaje de calidad logrado. Quienes responden a las evaluaciones son

principalmente el cliente y el usuario final, siendo los que determinan si es funcional o no



72

el producto, además se analiza el rendimiento del equipo de trabajo por medio de los

desarrolladores y expertos sobre el cumplimiento de objetivos para el proyecto y la

organización.

Las mediciones se realizan a partir de formularios en un archivo Excel compartido vía

Google Drive, que a su vez está dividido en tres módulos que gestionan, definen y valoran

las características del software. Estas evaluaciones se realizaron por medio de las reuniones

y revisiones con el cliente, para tener una consecución más precisa del producto que

soporten el rendimiento, pérdidas, déficits y ganancias. La tabla 11 muestra la

normalización de las medidas que se utilizaron en la evaluación del producto de software.

Tabla 11. Normalización de las métricas para la evaluación del software.

0 1 2 3 4 5

No

aplica

(NA)

Nunca Pocas veces Algunas veces Casi

siempre

Siempre

Muy mal Mal Normal Bueno Muy bueno

Nada Alguno Media Alto Mucho

No definido Básico Promedio Casi todo

definido

Todo

Muy baja Baja Medianamente

definido

Casi

completo

Muy alto

No Poco

definido

Habitual Aproximado Si

Con la tabla anterior se calcularon los promedios de las subcaracterísticas por cada

característica de la calidad del producto, las tablas 12 y 13 muestran respectivamente los

resultados de las métricas obtenidas por media y porcentaje de la calidad externa e interna,

así como también la calidad en uso y el modelo de calidad, en los anexos se especifica los

términos que se evaluaron de las normas ISO.

Tabla 12. Calidad externa e interna.

Característica Subcaracterística Resultados de la

evaluación

Media Porcentaje

Funcionalidad Adecuación 4.6 92 %

Exactitud 5 100 %

Interoperabilidad 4 80 %

Seguridad de acceso 4.1 82 %

Cumplimiento de la

funcionalidad

4 80 %

Confiabilidad Madurez 5 100 %

Tolerancia a fallos 4.8 96 %

Recuperación 4.2 84 %



73

Cumplimiento de la

confiabilidad

4.5 90 %

Usabilidad Facilidad de comprensión 4.7 94 %

Facilidad para aprender 4.4 88 %

Facilidad para operar 4.5 90 %

Atracción 5 100 %

Eficiencia Comportamiento del tiempo 5 100 %

Manejo de recursos 5 100 %

Cumplimiento de la

eficiencia

5 100 %

Mantenibilidad Facilidad de análisis 5 100 %

Facilidad de cambio 4.8 96 %

Cumplimiento de la

mantenibilidad

5 100 %

Portabilidad Facilidad de instalación

4.3 86 %

Como se puede observar, la Tabla 12 indica la medición alcanzada, donde se registra la

calidad interna y externa durante el ciclo de vida del desarrollo del modelo, donde se están

probando constantemente los componentes terminados por Sprint y es posible, que el

cliente los apruebe o que los rechace y hacer cambios.

En cuanto a la calidad de uso, la Tabla 13 ilustra los resultados del modelo más completo

en cuanto a la demostración de la calidad. La calidad en uso es la forma en que el usuario

final manipula a MOPICS como producto terminado.

Tabla 13. Calidad de uso.


evaluación

Media Porcentaje

Efectividad Efectividad 5 100 %

Productividad Productividad 5 100 %

Seguridad Mitigación de riesgos 5 100 %

Satisfacción Cumplimiento del propósito 5 100 %

Confianza 5 100 %

Placer 5 100 %

Confort 5 100 %

Promediando las dos tablas anteriores, en la tabla 14 se obtiene la calidad del producto.



74

Tabla 14. Calidad del producto de software.

Modelo de calidad Resultados de la

evaluación

Media Porcentaje

Externa e interna 4.6 92 %

En uso 5 100 %

Total 4.8 96 %

En la tabla anterior, se muestra un 96 % en la calidad resultante del producto utilizando la

guía de MOPICS, el cual es superior a los métodos tradicionales que son procedentes del

desarrollo en cascada o lineal y, es similar a los ágiles.

En relación a MOPICS como modelo, la tabla 15 resume el sistema y modelo de calidad de

software como un producto terminado después de haber aplicado MOPICS en un desarrollo

de un proyecto. Cabe mencionar que la mantenibilidad es considerada la característica más

importante de la calidad del software, es por eso que las ISO/IEC 9126 e ISO/IEC 25000,

analizan además como subcaracterística, la mantenibilidad.

Tabla 15. Modelo de calidad.


evaluación

Media Porcentaje

Adecuación

funcional

Completitud funcional 5 100 %

Corrección funcional 5 100 %

Adecuación funcional 5 100 %

Eficiencia en el

desempeño

Comportamiento del tiempo 5 100 %

Manejo de recursos 5 100 %

Capacidad 4.8 96 %

Compatibilidad Coexistencia 4.8 96 %

Interoperabilidad 5 100 %

Usabilidad Facilidad de comprensión 5 100 %

Facilidad de aprender 4.8 96 %

Facilidad para operar 5 100 %

Protección contra errores de

usuarios

4.8 96 %

Estética de la interfaz con el

usuario

5 100 %

Accesibilidad 5 100 %

Confiabilidad Madurez 5 100 %

Tolerancia a fallos 4.8 96 %



75

Recuperación 4.2 84 %

Disponibilidad 4.5 90 %

Seguridad Confidencialidad 5 100 %

Integridad 5 100 %

Trazabilidad 5 100 %

Autenticidad 5 100 %

Mantenibilidad Facilidad de análisis 5 100 %

Facilidad de cambio 4.8 96 %

Facilidad para pruebas 5 100 %

Cumplimiento de la

mantenibilidad

5 100 %

Reusabilidad 4.8 96 %

Portabilidad Adaptabilidad 4.8 96 %

Facilidad de instalación 4.3 86 %

Facilidad de reemplazo 4 80 %

Como modelo de valoración de MOPICS, se basó en la norma ISO/IEC 25000, la cual

describe el modelo que consiste en características y subcaracterísticas para la calidad del

producto de software y la calidad en uso, se puede observar en la tabla 16.

Tabla 16. Calidad del modelo.

Se retomaron algunas subcaracterísticas de las norma ISO/IEC 9126 e ISO/IEC 14598, de

las cuales se toman desde la perspectiva de aplicación del modelo y no como producto de

software terminado.

4.5 Resumen

La aplicación de MOPICS en la empresa consultora ayudó de mucho a crecer

organizacionalmente, ya que no existía una motivación, lo que ocasionaba que no tuvieran

interés por tener una buena relación con las demás personas en el proyecto y causando un

mal servicio. Esto se debe a la cultura organizacional, muchas empresas no prestan atención

a estos aspectos porque solo se interesan por obtener beneficios monetarios y en tiempos

reducidos, sin antes pensar en enfocarse en debilidades y fortalezas de la empresa.

Por otra parte, al conseguir la evaluación de la calidad del software al producto resultante

tras emplear MOPICS puede garantizarse que el modelo funciona y cumple con las

expectativas para las que fue desarrollado. Las expectativas principales son la unificación y



76

optimización de procesos de las metodologías y estrategias destinadas al cliente, puesto que

permitan el brindar un mejor servicio y dar una mejor calidad al software en producción.

Con base en los fundamentos de calidad de otros modelos de desarrollo y los resultados

obtenidos de la evaluación, se denota el funcionamiento del modelo para este tipo de

proyectos. El primer objetivo de MOPICS, como un marco de trabajo, maneja la

comunicación de tal forma que se vuelva indispensable para el trabajo en equipo.



77

Capítulo 5

Conclusiones y trabajos a futuro



78

Capítulo 5. Conclusiones y trabajos a futuro

5.1. Cumplimiento de objetivos

El presente trabajo cumple con el objetivo general que es “diseñar un modelo de

mejora de procesos basado en la implementación de la estrategia CRM y de la

metodología ágil SCRUM enfocado hacia el Sector de Desarrollo y Consultoría de TI

como outsourcing”, porque evalúa y gestiona las interacciones de modo directo con los

involucrados y el uso del agilismo durante el ciclo de vida del desarrollo del software.

De igual manera, pueden validarse los objetivos específicos, que apoyan al objetivo

general:

1. “Identificar factores en los procesos de desarrollo de software que influyen en las

relaciones con el cliente en las consultoras de TI.”

Entre los principales factores identificados en la adopción de una estrategia ligada al

cliente, se destacan:

Carencia de comunicación; lo que causa el desconocimiento de metas y

objetivos en el proyecto.

No compartir experiencias; ayudan a mejorar técnicas.

Reglas pesadas para el desarrollo o herramientas de control inútiles.

Conflictos interpersonales; impide el trabajo en equipo.

Rotación del personal; lo ocasiona la falta de motivación e incentivos

laborales.

Se lograron distinguir dichos factores empíricamente, ya que al no tener un enlace

personalizado con el cliente, el personal asume cosas erróneamente.

2. “Definición clara de roles dentro de la organización, debido a que serán parte

clave en la aplicación de procesos del desarrollo de software.”

La definición de los roles para la implementación de MOPICS, se consideraron a

partir de SCRUM. Esta metodología tiene certificaciones oficiales que aprueban

habilidades y capacidades de los individuos para laborar sobre un marco de trabajo

establecido. Los roles mencionados son descritos de manera que están sujetos a

adaptaciones, facilitan el ajuste con actividades y con anteriores modelos de

desarrollo de software.

El propietario del producto es el rol que se asemeja a las actividades que maneja un

jefe de proyectos, considerándose el papel más importante y compuesto de los



79

demás. Para seguir las metodologías ágiles, debe centrarse en los miembros de su

equipo y su conocimiento en lugar del proceso definido para desarrollar.

3. “Diseñar el modelo, estableciendo actividades y tareas, tomando como base la

metodología SCRUM y la estrategia CRM y usando como apoyo otras buenas

prácticas, que apoyen la fundamentación del modelo propuesto.”

Para el diseño de MOPICS, se crearon etapas que están conformadas por actividades

y tareas. Se divide en cinco etapas: diagnóstico organizacional, plan de desarrollo,

implementación, entrega de valor y satisfacción del cliente. Se diseñó de tal forma

que se fundamenta en el ciclo de vida del desarrollo del desarrollo de software. Las

actividades y tareas incluyen procesos de SCRUM que asocian al cliente como

principal objetivo.

La estructura de las actividades se adapta a la estrategia con los clientes, les asiste

en todo el proceso durante el proyecto, permitiendo asegurar un alto grado de

madurez en la cultura de su organización.

4. “Formular un modelo que apoye a la mejora de procesos durante y después del

desarrollo del servicio y/o producto, mediante el mantenimiento del mismo.”

Se verificó esta formulación en el capítulo 4 de este documento, gracias a las

retrospectivas por cada entregable y las reuniones constantes durante el desarrollo,

que permiten ver el progreso del proyecto y favorece la optimización de los

procesos. Debe recordarse que el agilismo es también optimización. Detrás del

agilismo es posible encontrar la intención de optimizar recursos para maximizar el

valor percibido para los clientes; pueden ser internos o externos. Lo que se intenta,

es reducir o evitar directamente todas aquellas tareas que no agregan valor al

cliente.

Con el software terminado, el mantenimiento se evalúa por medio de la

disponibilidad del software durante su uso. Se incluyen características de las normas

ISO de calidad de software durante y al término del desarrollo.

5. “Implementar el modelo propuesto en al menos una empresa del Sector Consultoría

de TI, considerando el proceso de manejo de clientes de CRM.”

El trabajo favoreció al proyecto en el que se puso en práctica, donde fue demostrado

MOPICS, implementándolo en una empresa de consultoría; considerando el manejo

de clientes a partir de estrategias, se seleccionó una empresa dedicada al

outsourcing y que hubiesen usado o tenido conocimientos de SCRUM y/o agilismo.

La implementación consideró una empresa con los siguientes aspectos:



80

Empresa proveedora de servicios de TI.

Externalización de TI.

Administración de servicios orientados al negocio y servicio.

Concentración en la calidad del producto y/o servicio.

Mayor interés por el cliente que por la tecnología.

Este trabajo de investigación, se enfocó en el análisis de las estrategias y los procesos

contenidos en una organización para el desarrollo de un proyecto y no en la creación del

software que automatice los procesos de MOPICS, una vez realizadas más pruebas en el

modelo. MOPICS es básicamente cimentado en el valor, que es la satisfacción del cliente

por medio de la calidad, en la comunicación de sus miembros, y en la adaptación a los

cambios.

5.2. Beneficios logrados

Tomando como base el planteamiento del problema descrito en el capítulo 1, se

menciona que las empresas que emplean outsourcing, no cuentan con un modelo

consolidado a seguir, para imitar en cuanto al trabajo en equipo con todas las áreas

implicadas y no exclusivamente, con el área externa. Por otra parte, en el capítulo 3, se

diseñó a MOPICS, como un modelo híbrido de desarrollo evolutivo e incremental, centrado

en las personas y resultados, en el cual incorpora cambios durante el desarrollo del

producto de software y su implementación. Con base en el paradigma de desarrollo ágil,

MOPICS hace uso de técnicas que logran en el proyecto implementado de la obtención de

los factores que influyen en las empresas consultoras de TI en la adopción de estrategias de

comunicación con el cliente mediante CRM.

La comunicación se fortaleció en el proyecto donde se implementó, debido a que MOPICS

pone énfasis en las relaciones interpersonales y a los resultados en plazos cortos. De esta

forma, demostró que al colaborar todo el tiempo directamente con el cliente, se logra

establecer una comunicación sólida y de complacencia, aunque no solamente es con el

cliente sino también con todos los involucrados en el proyecto y en la organización. La

mejora de la comunicación se promueve con la ayuda de las reuniones constantes, donde se

concentran las partes interesadas para adicionar cambios considerados importantes y

actualizaciones al momento y así no dispersar la información. La correlación entre la

adopción de metodologías ágiles y la preferencia por el trabajo en equipo entre los

desarrolladores, es otra buena estrategia basada en las personas. El trabajo en equipo es útil

para mejorar la transferencia de conocimiento, la comunicación y la coordinación dentro de

una organización. El intercambio de conocimiento dentro de un grupo facilita su

transferencia y el desarrollo de nuevas ideas.



81

Las reuniones diarias se consideran sustanciales tanto para el cliente como para el equipo

de desarrollo, ya que si existe alguna dubitación por parte de algún miembro, no se pierde

tiempo y se consulta con el principal. Cabe aclarar que tanto el cliente como el equipo de

desarrollo, se encuentran en la misma ubicación física, es decir, trabajan en el mismo

edificio en el que se encuentra el cliente, dado que se especifica en el contrato. Como se

está utilizando agilismo en el desarrollo, se tienen que solucionar dudas lo antes posible.

Por lo general, el cliente tiene más de un proyecto asignado pero no más de tres al mismo

tiempo, ya que sería mucha carga de trabajo y se descuidarían aspectos importantes, en

cambio, el propietario del producto, experto y equipo de desarrollo solo tienen asignados un

solo proyecto, teniendo en cuenta que los proyectos no sobrepasan los 6 meses para su

evolución.

MOPICS se fundamenta con base en diferentes prácticas de Ingeniería de Software, así,

abarca en la parte de gestión del proyecto y estrategia CRM, el área de conocimiento que se

responsabiliza en la gestión del portafolio y gestión de programas, que identifican y

seleccionan las inversiones potenciales y se genera la sinergia entre proyectos con objetivos

en común que, permiten hacer visibles los beneficios de ambas partes (cliente/proveedor).

Además de medir el nivel de satisfacción del cliente a través del rendimiento percibido

menos las expectativas. Es por eso que MOPICS ofrece una ventaja frente a los modelos

tradicionales de desarrollo como el lineal, cascada y espiral, ya que une procesos de la

organización con los propios del modelo que permite la flexibilidad a cambios e

interacciones durante el ciclo de vida del desarrollo del software.

Como resultado final y aportación de la investigación, se logra establecer un modelo

completo que permite juntar elementos del desarrollo de un proyecto, como lo es la gestión,

desarrollo, calidad y relaciones interpersonales, que a su vez dan un resultado de cultura

organizacional y satisfacción del cliente. La clave es hacer las cosas conforme un orden y

en equipo, como dijo Stephen Covey, Olaz (2014), “la fuerza reside en las diferencias, no

en las similitudes”.

5.3. Evaluación de la calidad

MOPICS se probó en un proyecto real, logrando una mejora en la calidad del

desarrollo del producto, el cual beneficia al mantenimiento que se brinda después del

término del proyecto. En comparación con las técnicas que usaba la empresa para el manejo

de su portafolio de proyectos, este modelo apoyó la comunicación dentro de los equipos de

trabajo, creando la unificación de procesos que se llevaban por separado sin tener el diálogo

y el intercambio de información. Por lo que se puede decir que MOPICS verificó y

comprobó los resultados planeados, corroborando las expectativas del presente trabajo, lo

cual significa que MOPICS cumple con los factores que influyen en la comunicación

dentro del ciclo de vida del software. Se tomaron puntos clave de los procesos de las

normas de calidad ISO/IEC 14598, ISO/IEC 9126 e ISO/IEC 25000, que describen

parámetros de calidad del producto de software, enfocándose en la evaluación de calidad



82

del software, estas normas se evaluaron durante y al final del ciclo de vida de desarrollo del

software para calificar de manera más completa a MOPICS.

Las métricas aplicadas para la evaluación de MOPICS, se realizaron por parte del

propietario del producto, el cual realizó preguntas al equipo de trabajo, según los estándares

de calidad, sobre la calidad del producto en desarrollo y producción, así como también se

llevaron a cabo con el cliente y usuario final sobre el cumplimiento de funcionalidades.

5.4. Aportaciones

En términos generales, las aportaciones más importantes a destacar en el modelo

MOPICS:

Diseño de cinco etapas del modelo de desarrollo de software.

Origen de un mejorado modelo de ciclo de vida de desarrollo que combina

agilismo y relaciones interpersonales.

Análisis inicial completo que reúne las áreas de ventas, dirección, marketing,

cliente y propietario del producto.

Creación de carpeta del proyecto visible a todas las partes involucradas;

permite informar sobre el estado del proyecto a otras áreas funcionales de la

empresa proveedor.

Diseño de formatos y tablas para el control y gestión del proyecto.

Asignación de roles y características para los distintos miembros del

proyecto.

Propuesta del uso de todos los elementos ágiles en el desarrollo y

mantenimiento del producto de software.

Hacer uso de notas para agilizar la comunicación de los integrantes del

equipo de desarrollo; herramientas Kanban.

Adecuación de características y subcaracterísticas de normas ISO para la

evaluación del software.

Optimización de recursos, tiempos y procesos.

MOPICS como modelo de desarrollo de software es una propuesta interesante para las

empresas consultoras de TI, porque a comparación de trabajos actuales y modelos

tradicionales, presta peculiar atención al factor humano como lo menciona el manifiesto

ágil. El objetivo principal de muchas empresas es generar capital para hacerse de un

nombre en el mercado de las TI, siendo el error más común para el éxito de la organización.

Recordemos que lo que hace a la empresa son sus empleados, que son los que brindan el

servicio directo a los clientes y usuarios. Empresas como estas deben de enfocarse primero

en el factor humano y después en la creación de estrategias para crear una organización más

sólida que permita un buen desempeño en los roles de cada empleado.



83

Como se mencionó en el estado del arte, a partir de trabajos similares de

investigación, se observa en la Tabla 17, las características con los que cuenta MOPICS y

tienen en común con otros trabajos de investigación.

Tabla 17. Comparación de MOPICS con trabajos de investigación similares.

Características AMBIP* IUCDA* SA* DAD* CAT* PMA* MOPICS

Metodologías ágiles

Metodologías

tradicionales

× × × × ×

Orientación al cliente

Estrategias para la

comunicación

Satisfacción del

cliente

Reuniones diarias × × Manejo de artefactos

Análisis inicial × × × Manejo de

complejidad en

modelado de datos

× × × × ×

Uso de reglas estrictas

en las metodologías × × × × × ×

Calidad en uso × × × × × Usabilidad del

software

× × × ×

Dirección de

experiencias de

usuario

× ×

Transferencia de roles × × ×

Uso de medios de

comunicación

Gestión de proyectos * Las siglas se definen en los trabajos de investigación descritos en el estado del arte en las secciones 3.51 a la

3.5.6.

El trabajo de investigación “SA” (Scaling for agility: A referencce model for hybrid

traditional-agile software development methodologies), adopta mayor número de

características en cuanto a ambos aspectos. Hay aspectos positivos que benefician la

optimización de los procesos que están implicados en el desarrollo de software, pero a su

vez, también hay aspectos que perjudican elementos importantes como la complejidad en el

manejo de reglas para la adopción de procesos, entre otros.



84

Como se observó en la tabla anterior, MOPICS evita el uso de modelos tradicionales, los

cuales impiden la detección temprana de fallas en el desarrollo y la incorporación de

cambios. Los cambios ayudan a que el cliente tenga una mejor visión del software que

desea.

Gracias a la aplicación de MOPICS en un proyecto, se enfatizaron estas características.

Como aportaciones, se destaca la evaluación de la calidad. La calidad del modelo evalúa la

calidad en uso y la calidad interna y externa del software. Dichas evaluación se realizan con

las bases de las normas ISO.

5.5. Divulgación de la investigación

De este trabajo se realizó un artículo de divulgación, el cual de forma sintetizada

redacta los resultados obtenidos en la investigación. Este artículo tuvo participación en el

XII Congreso Internacional de Gestión, Calidad, Derecho y Competitividad Empresarial en

Morelia, Michoacán. El congreso propone y apoya trabajos e ideas de distintos niveles de

investigación que ayuden a empresas que hoy en día necesitan sustentar sus

procedimientos, tecnologías, métodos, estrategias, técnicas, entre otros, en el desarrollo de

productos y/o servicios de calidad y con base en normas oficiales.

5.6. Estancia de investigación

La estancia de investigación que se efectuó, tuvo lugar en la Universidad Politécnica

de Valencia, España, donde se trabajó en conjunto con el Departamento de Sistemas de

Información y Computación (DSIC) en el área de Ingeniería de Software con el Dr. Patricio

Letelier Torres, experto en metodologías ágiles en el desarrollo de software. Al haber

colaborado con un experto en el tema, se reforzaron aspectos en los procesos de SCRUM

que están contenidos en la guía propuesta en MOPICS. Se enfatizaron varias propiedades

en la parte del agilismo y que a su vez van de la mano con la estrategia CRM, los cuales

apoyan al desarrollo de la comunicación en el proyecto y proveen calidad en el software.

5.7. Trabajos futuros

Para continuar con la investigación, se propone la aplicación de MOPICS en más

proyectos de desarrollo y mantenimiento de software en varios estados de la República

Mexicana, que permitan identificar otros indicadores y adicionar procesos clave que ayuden

a mejorar el modelo.

Por otra parte, sería interesante después de haber refinado el modelo, implantarlo en otros

países con los mismos intereses que en México, para crear una guía universal de desarrollo

de software en proyectos con metodologías ágiles, brindando software de calidad, con un



85

presupuesto adecuado, sin retrasos de tiempos y ofrecer una excelente satisfacción al

cliente en cuanto al cumplimiento de sus expectativas.

También se proyecta creación de una herramienta de software en línea que asista a los

procesos utilizados en MOPICS, facilitando el uso del modelo y su adopción, a cualquier

empresa que desee emplearlo.



86

Referencias

A. Khedr and J. N. Kok. (2008). Adopting Knowledge Discovery in Databases for

Customer Relationship Management in Egyptian Public Banks. Leiden, The

Netherlands: Leiden University, Leiden Institute of Advanced Computer Science.

Abdoulaye A., (2003). Conceptualización y difusión de "buenas prácticas" en

educación: ensayo de un enfoque internacional a partir de las lecciones aprendidas de

un proyecto. Sitio web

http://portal.unesco.org/education/en/file_download.php/f1685fde2633dd9b3b20fd828d

6bfa92abdoulaye.pdf

Abraham Silberschatz, Henry F. Korth and S. Sudarshan. (2002). Fundamentos de

Bases de Datos. España: McGraw Hill.

Abrahamsson P., Marchesi M., Maurer F... (2009). Distributed Agile Development: A

Case Study of Customer Communication Challenges. Springer-Verlag Berlin

Heidelberg, 2009, 7.

Alegsa L. (1998 - 2017). Diccionario de Informática y Tecnología. Sitio web

http://www.alegsa.com.ar

Alles M. (2011). Diccionario de Términos de Recursos Humanos de Martha Alles.

Página 120.

Armand Khoury. (2015). Agile/Scrum applied to Dynamics CRM projects. Diciembre,

2015, de agile Sitio web: https://www.linkedin.com/pulse/agilescrum-applied-dynamics-

crm-projects-armand-khoury

Ble C. (2010 - 2013). Diseño ágil con TDD, Agilismo. LIBROS WEB

http://librosweb.es/libro/tdd/capitulo_1/en_que_consiste_el_agilismo_un_enfoque_prac

tico

Bourque P., Fairley R... (2014). SWEBOK: Guide to the Software Engineering Body of

Knowledge. Los Alamitos, CA. IEEE Computer Society.

Bradshaw, D., Brash, C. (2001) Managing customer relationships in e-business world:

how to personalize the computer relationships for increased profitability. International

Journal of Retail.

Cockton G., Lárusdóttir M., Gregory P., Cajander A... (2016). Integrating User-Centred

Design in Agile Development. Springer International Publishing Switzerland, 2016, 46.

Collins K., Thompson E., Desisto R., Alvarez G., MaozGartner M. (2016). Customer

Relationship Management and Customer Experience Primer for 2016.

Corona B., Muñoz M., Miramontes J., Calvo-Manzan J., San Feliu T. (Abril 2016).

Estado de arte sobre métodos de evaluación de metodologías ágiles en las pymes.

ReCIBE, Revista electrónica de computación, informática, biomédica y electrónica,

Vol. 1, 18.

Dall’Agnol M., Sillitti A., Succi G... (2004). Project Management and Agile

Methodologies: A Survey. Springer-Verlag Berlin Heidelberg, 2004, 4.

DICIEA, Diccionario Inglés-Español-Aleman (1993). Editorial Cultural, Madrid. ISBN

84-86732-25-5

E. Hernández, J. Hernández, C. Lizandra, (2001). C++ Estándar, ITP Paraninfo.



87

Espinosa N., Gómez J. (1996). Dirección de la Calidad. Editorial ISPJAE.

Francois C. (2004). International Encyclopedia of Systems and Cybernetics. Alemania:

K.G. Saur.

G. Booch, J. Rumbaugh y I. Jacobson, (1999). El Lenguaje Unificado de Modelado,

Addison Wesley.

Gartner. (2016). Sitio web: http://www.gartner.com/search/all/CRM

Greenberg P. (2004). CRM at the speed of light: essential customer strategies for the

21st century. McGraw-Hill, Osborne.

Gummesson, E. (2002): Total Relationship Marketing. Oxford (UK): Butterworth-

Heinemann.

Harris D. (2014). The 10 Most Popular CRM Products. Sitio Web

http://www.softwareadvice.com/resources/the-10-most-popular-crm-products/

Hussain Z., Slany W., and Holzinger A. (2009). Investigating Agile User-Centered

Design in Practice: A Grounded Theory Perspective. Austria.

I. Jacobson, G. Booch, J. Rumbaugh, (2000). El Proceso Unificado de Desarrollo,

Addision Wesley.

IEEE, Standard Glossary of Software Engineering Terminology. (1990).

Ihme T. (2012). Scrum adoption and architectural extensions in developing new service

applications of large financial IT systems. Oulu, Finland.

Instituto Nacional de Estadística y Geografía (INEGI). (2015). Información relacionada

con los recursos humanos y financieros destinados a las actividades de investigación y

desarrollo tecnológico e innovación en el sector productivo. 2016, de INEGI Sitio web:

http://www.beta.inegi.org.mx/temas/ciencia/

International Organization for Standardization. (2017). ISO 25000 Calidad del producto

de software. 2017, de International Organization for Standardization Sitio web:

http://iso25000.com/

Jiménez E... (2012). Medición de calidad de META. En META (Metodología

tradicional y ágil) (76). México: CIC IPN.

JoeCRM. (February 11, 2013). Microsoft Dynamics CRM and Agile Development

Methodology. Diciembre, 2015, de CRM Sitio web:

http://www.powerobjects.com/2013/02/11/microsoft-dynamics-crm-and-agile-

development/

K. Schwaber y J. Sutherland, (2016). La guía de Scrum, la guía definitiva de Scrum: las

reglas del juego. Julio, 2016. http://www.scrumguides.org/docs/scrumguide/v2016/2016-

Scrum-Guide-Spanish.pdf

Kenneth B. (2004). The PDMA Handbook of New Product Development, Second

Edition, John Wiley & Sons, 2004. Chapter 12 (pp. 173-187), "Accelerated Product

Development: Techniques and Traps”.

Kent Beck y firmantes del Manifiesto Ágil, (2001). Manifiesto Ágil. Sitio web:

http://agilemanifesto.org/iso/es/manifesto

Keramati, S. Nazari-Shirkouhi, H. Moshki, M. Afshari-Mofrad, E. Maleki-Berneti.

(2012, November 15). A novel methodology for evaluating the risk of CRM projects in

fuzzy environment. Springer, 1, 25.



88

Koenes A., Soriano C... (1996). Gestión de la calidad total. Madrid, España: Días de

Santos.

Korkala M., Pikkarainen M., Conboy K... (2010). Combining Agile and Traditional:

Customer Communication in Distributed Environment. Springer-Verlag Berlin

Heidelberg, 2010, 16.

Kotler P., Keller K. (2012). Dirección de Marketing (14ª edición). Pearson Educación

de México, 2012 p. 20.

León N, Pinto N., Gómez L... (Agosto 2011). Herramienta computacional para la

evaluación de calidad de productos software enmarcados en actividades de

investigación. Scientia Et Technica, XVI, 48.

M. Bass J. (2014). How product owner teams scale agile methods to large distributed

enterprises. New York, USA.

MG (2000 - 2017). Manage Consulting International. Sitio web:

http://www.manageconsulting.it

M.M. Lankhorst, M.M. Zoet, W.P.M. Janssen, and W.A. Molnar. (2008). Chapter 2.

Agility.

M.M. Lankhorst, M.M. Zoet, W.P.M. Janssen, and W.A. Molnar. (2012). Agile Service

Development. Berlin, Germany.

Nogués A., Valladares J... (2017). Agile Methodologies for BI Projects. En Business

Intelligence Tools for Small Companies (29 - 56). España: Apress.

Olaz A. J. (2014). Cómo trabajar en equipo a través de competencias. España: Narcea

Ediciones.

Oxford Dictionary (2005). Oxford English Dictionary (3rd ed.). Outsource. Oxford

University Press. September 2005.

Pastrana O. (2014). 5 beneficios de aplicar metodologías ágiles en el desarrollo de

software. Sitio web http://www.i2btech.com/blog-i2b/tech-deployment/5-beneficios-de-

aplicar-metodologias-agiles-en-el-desarrollo-de-software/

Pérez J., Merino M. (2009 – 2013). Definición de plan de desarrollo. Sitio web

https://definicion.de/plan-de-desarrollo/

Project Management Institute. (2004). A guide to the project management body of

knowledge (PMBOK guide). Newtown Square, Pa: Project Management Institute.

Ptacek, M. J. (2000). Search for perfect CRM solution remains elusive. American

Banker, 165(173).

Quero, M. (2006). Relationship Marketing and Services Marketing: two convergent

perspectives for value creation in the cultural sector. Empirical evidence on performing

arts consumers in Spain. España.

Qumer A., Henderson-Sellers B., Niazi M... (2016). Scaling for agility: A reference

model for hybrid traditional-agile software development methodologies. Springer

Science+Business Media New York, 2016, 27.

RAE, Real Academia Española. (2001). Diccionario de la lengua española (22.a ed.).

Consultado en http://www.rae.es/rae.html

Rajola F. (2013). Customer Relationship Management in the Financial Industry. Berlin,

Alemania.



89

Roanboc, Gestión de Proyectos. (2012). Implementando Scrum con Team Foundation

2012. Sitio Web https://roanboc.wordpress.com/2013/12/23/implementando-scrum-

con-team-foundation-2012/

Sanaa Askool, Keiichi Nakata. (2010). A conceptual model for acceptance of social

CRM systems based on a scoping study. Springer, 6, 16.

Sarika Sharma, D.P. Goyal. (2011). Critical Success Factors for CRM Implementation:

A Study on Indian Banks. India.

Scott Kostojohn, Mathew Jhonson and Brian Paulen. (2011). CRM Fundamentals. New

York: Apress.

SIN, Sinergia e Inteligencia de Negocio (2007 - 2016). Sinnexus, Business Intelligence

e Informática estratégica. Sitio web: http://www.sinnexus.com

Software Engineering Institute (SEI), (2010). Metodologías ágiles para el desarrollo de

software. 2006, de SEI Sitio web: www.sei.cmu.edu/cmm/cmm

Schwaber K., Sutherland J. (2013). La Guía Definitiva de Scrum: Las Reglas del Juego.

2014, de Scrum.Org and ScrumInc Sitio web: http://www.scrumguides.org

WR, WordReference (2017). Sitio web: http://www.wordreference.com

Z. Racheva, M. Daneva, K. Sikkel, and L. Buglione. (2010). Business Value Is Not

Only Dollars – Results from Case Study Research on Agile Software Projects. Roma,

Italy.



90

Apéndices y

anexos



91

Apéndices

1. Carpeta del proyecto



92



93



94



95



96



97

2. Normas de calidad

Las normas de las que se tomaron puntos de referencia en cuanto a la evaluación de

la calidad del producto de software son:

ISO/IEC 9126

ISO/IEC 14598

ISO/IEC 25000

De las cuales se emplearon características para la evaluación de la calidad interna, externa,

de uso y del modelo. También se hizo referencia en la forma de medición de la calidad, a

un trabajo de tesis que propone una metodología hibrida, de la cual también se evalúa la

calidad a través de las normas anteriormente mencionadas, Jiménez (2012).

Tabla 18. Métricas de la calidad interna y externa del producto de software.

Característica Subcaracterística Métrica Propósito de la métrica Resultado de

la evaluación

de la guía

Funcionalidad Adecuación Adecuación funcional ¿Qué tan adecuadas son las

funciones revisadas?

4

Alcance de la

implementación

funcional

¿Qué tan correcta es la

implementación funcional?

5

Exactitud Expectativa de la

exactitud

¿Hay diferencias aceptables

entre los resultados actuales y

los razonables esperados?

5

Exactitud en el

calculo

¿Qué tan a menudo los

usuarios hallan resultados

exactos?

4

Precisión ¿Qué tan a menudo los

usuarios hallan resultados con

precisión adecuada?

5

Interoperabilidad Facilidad en el

intercambio de datos

¿Qué tan correcto se realiza el

intercambio para transferir

datos específicos que se

implementan?

4

Seguridad de

acceso

Acceso auditable ¿Qué tan completo es el rastro

auditable con respecto a los

datos?

5

Cumplimiento de la

funcionalidad

Conformidad de

funcionalidad

¿Qué tan cumplida es la

funcionalidad del producto a

las regulaciones, normas y

convenios aplicables?

5

Confiabilidad Madurez Eliminación de fallas ¿Qué tan a menudo es posible

corregir las fallas?

5



98

Madurez de la prueba ¿Se prueba correctamente el

producto?

5

Tolerancia a fallos Prevención de

interrupciones

¿Qué tan a menudo es posible

prevenir que el producto

origine una interrupción total

del ambiente de producción?

5

Prevención de fallas ¿Qué tan a menudo es posible

controlar los patrones de fallas

para evitar fallas serias y

críticas?

5

Prevención de

operación incorrecta


implementar funciones con la

capacidad de evitar

operaciones incorrectas?

4

Recuperación Facilidad de

restablecimiento

¿Qué tan capaz es el producto

para restablecerse a sí mismo

después de un evento

anormal?

4

Efectividad de

restauración

¿Qué tan efectiva es la

capacidad de restauración?

4

Cumplimiento de la

confiabilidad

Conformidad de

confiabilidad

¿Qué tan conforme es la

confiabilidad del producto a

regulaciones aplicables,

normas y convenios?

5

Usabilidad Facilidad de

comprensión

Integridad de la

descripción


comprender las funciones

después de leer la descripción

del producto?

5

Actividades

comprensibles

¿Los usuarios comprenden

que se requiere por el

producto como entrada y que

proporciona este como salida?

4

Facilidad para

aprender

Facilidad de aprender

a desempeñar una

tarea en uso

¿Qué tan a menudo el usuario

después de aprender como

desempeñar una tarea

específica puede ponerla en

práctica eficientemente?

4

Efectividad de la

documentación del

usuario y/o ayuda del

producto

¿Qué tan a menudo las tareas

pueden completarse

correctamente después de usar

documentación y/o ayuda del

producto?

4

Facilidad para

operar

Consistencia

operacional en uso

¿Qué tan consistentes son los

componentes del producto?

4

Corrección del error

en uso


puede fácilmente recuperarse

de un error o reintentar tareas?

5



99

Recuperación en uso

de un error

operacional


puede recuperarse fácilmente

de una mala situación?

5

Facilidad de

adaptación


puede fácilmente adaptar los

procedimientos de operación

para su conveniencia?

5

Reducción del

procedimiento de

operación


fácilmente puede reducir los

procedimientos de operación a

su conveniencia?

4

Atracción Interacción atractiva ¿Qué tan atractiva es la

presentación del producto para

el usuario?

5

Eficiencia Comportamiento

del tiempo

Rendimiento ¿Qué tan a menudo se pueden

desempeñar las tareas

satisfactoriamente sobre un

periodo de tiempo dado?

5

Utilización de los

recursos

Utilización de los

recursos materiales

¿Qué tan a menudo se puede

hacer uso de los recursos

materiales sin provocar

ineficiencias?

5

Conformidad de

eficiencia

Conformidad de

eficiencia


eficiencia del producto a


normas y convenios?

5

Mantenibilidad Facilidad de

análisis

Capacidad de

seguimiento de

auditoria


puede identificar la operación

especifica que origina la falla?

5

Facilidad para

introducir cambios

Eficiencia del ciclo de

cambio

¿Qué tan a menudo se puede

resolver fácilmente el

problema del usuario a su

satisfacción dentro de una

escala aceptable de tiempo?

5

Complejidad de

modificación

¿El responsable del uso del

producto puede realizar

fácilmente las adecuaciones

necesarias o solucionar un

problema?

5

Conformidad de

mantenibilidad

Conformidad de

mantenibilidad


mantenibilidad del producto a


normas y convenios?

4

Portabilidad Facilidad de

instalación

Fácil de instalar ¿El responsable del uso del

producto puede fácilmente

instalarlo al ambiente de

operación?

4



100

Tabla 19. Métricas de la calidad en uso del producto de software.

Característica Métrica Propósito de la métrica Resultado de

la evaluación

de la guía

Efectividad Efectividad de la

tarea

¿Qué porcentaje de objetivos

y tareas se logran

correctamente?

5

Conclusión de la tarea ¿Qué porcentaje de las tareas

se completa?

5

Productividad Eficiencia de la tarea ¿Qué tan eficientes son los

usuarios?

5

Seguridad Seguridad de las

personas afectadas

por el uso del

producto

¿Qué tan correcto es el

producto para no provocar

afectaciones en las personas

por el uso?

5

Daño económico ¿Qué tan correcto es el

producto para no provocar

afectaciones económicas por

su uso?

5

Satisfacción Escala de satisfacción ¿Qué tan satisfecho está el

usuario?

5



101

3. Herramienta para la evaluación del modelo de calidad de productos

de software

“Existen estándares como el ISO 14598 y el ISO 9126, los cuales en la actualidad hacen

parte del estándar ISO 25000, que definen la forma como se debe evaluar la calidad de los

productos software y el modelo de calidad que se debe seguir. En cuanto a la forma de

realizar la evaluación de los productos software, estos estándares establecen que primero se

deben especificar los requisitos de la evaluación. Para ello se define el propósito de la

evaluación que, aunque tiene siempre como fin último asegurar el cumplimiento del

producto con las necesidades implícitas y explícitas del usuario, se puede utilizar entre otras

cosas para decidir si se acepta o no el producto, definir cuándo lanzarlo al mercado,

compararlo con otros de funcionalidad similar o decidir cuándo mejorar o reemplazar el

producto. Una vez se define el propósito de la evaluación, se seleccionan los productos a

evaluar. Estos productos pueden ser resultado intermedios (modelos de datos, prototipos,

módulos, manuales, etc.) o productos finales del proyecto de desarrollo (instaladores,

código fuente, ejecutables, etc.).” comenta León N. (Agosto 2011).

El procedimiento siguiente es definir el modelo de calidad a usar. Un modelo de calidad es

un conjunto de características y las relaciones entre ellas, los cuales proporcionan la base

para especificar los requerimientos de calidad y evaluar la calidad. Los modelos de calidad

de productos software como el que plantea la norma ISO 9126. Los aspectos a evaluar de la

calidad de un software se agrupan en características, dentro de las cuales se pueden crear

subgrupos llamados subcaracterísticas, las cuales a su vez están conformadas por métricas

que son métodos y escalas para realizar las mediciones y que son el resultado de relaciones

matemáticas entre parámetros o atributos puntuales de las mediciones.

Elementos de un modelo de calidad de evaluación de software. León N. (2011).

Definidos los requisitos de evaluación, se procede a especificar la evaluación. En primera

instancia se seleccionan las métricas a medir en el modelo de calidad especificado. Es



102

importante elegir mediciones sencillas de obtener y fáciles de utilizar. Como segundo paso

de la especificación de la evaluación, se establecen niveles para las métricas, definiendo

rangos en los cuales se pueden declarar diferentes niveles de satisfacción de cumplimiento

de la métrica. El último paso en la especificación de la evaluación lo constituye el

establecimiento de los criterios de valoración, lo cual implica definir qué características

tendrán más o menos peso al generar un resultado final.

Especificada la evaluación, se procede a diseñar la evaluación generando el plan de

evaluación, consistente en un cronograma de actividades con los respectivos responsables.

La última etapa la constituye la ejecución de la evaluación. Primero se toman las medidas

de las métricas seleccionadas en la especificación de la evaluación. Estas medidas se

comparan con los criterios definidos anteriormente y por último se valoran los resultados.

Modelo de calidad de la evaluación de productos de software. León N. (2011).



103

4. Gestión de proyectos

Según el PMBOK (2004), la gestión de proyectos es la aplicación de conocimiento,

habilidades, herramientas y técnicas a las actividades para alcanzar los objetivos del

proyecto. Todo proyecto de desarrollo de software debe contar con una apropiada gestión

de proyectos, por esto debe de operar con personal calificado, herramientas adecuadas,

procesos que se adecuen a las necesidades del proyecto y una buena planificación, para

llegar al producto deseado en tiempo y forma. La gestión de proyectos guía a un proyecto

desde el inicio hasta un final satisfactorio, con ayuda de procesos, métodos, modelos y

técnicas que dirigen al personal a realizar un buen desempeño en el desarrollo; se encarga

de localizar, inspeccionar y valorar las posibles soluciones de un desarrollo de software,

cumpliendo con estándares de calidad.

Según Pressman (2002), la gestión de proyectos de software consta de principios básicos

tales como una eficaz gestión de las cuatro “P” (Personas, Productos, Procesos y Proyecto).

También están las métricas de software del proyecto y del proceso, que resulta la base para

una toma de decisiones de gestión efectiva, así como para ayudar en la estimación, el

control de calidad, la evaluación de productividad y el control de proyectos.

Personas: factor humano para la construcción de un software.

Productos: construcción de un software.

Procesos: marco de trabajo para la construcción del software.

Proyecto: dirección del desarrollo de un software.

La gestión de proyectos de software es el primer nivel del proceso de Ingeniería de

software, que permite hacer frente a problemas como mal levantamiento de requerimientos,

planificaciones mal organizadas, dificultad para estimar y falta de detección de riesgos.



104

5. Ciclo de Deming

También llamado PDCA (Plan-Do-Check-Act), mejor conocido como modelo para la

mejora continua de procesos, enseña a las organizaciones a planear una acción, hacerla,

verificarla conforme al plan y guiarla hacia lo aprendido. Este ciclo está conformado por

cuatro pasos:

Ciclo de Deming (PDCA).

Planear (Plan): Identifica y analiza el problema.

Hacer (Do): Desarrolla soluciones e implementa la solución.

Verificar (Check): Evalúa los resultados y revisa si se cumplió el objetivo deseado.

Actuar (Act): Estandariza la solución.

Este ciclo se emplea en MOPICS, ya que se toma en cuenta la mejora continua de los

procesos y calidad del producto de software.



105

6. Satisfacción del cliente

Los deseos, necesidades y expectativas del cliente son primordiales para tener una

buena satisfacción. Es por eso que, es un requisito hoy en día ganarse la confianza del

cliente, siendo el marketing un departamento indispensable para las demás áreas

funcionales de la empresa.

Se consideran tres beneficios para una importancia significativa en la satisfacción del

cliente, según Kotler:

Un cliente satisfecho vuelve a comprar. Se obtiene lealtad y oportunidad de

venderle el mismo u otros productos y servicios.

Un cliente satisfecho comunica experiencias positivas a colegas sobre los productos

o servicios utilizados. La empresa gana difusión.

Un cliente satisfecho no presta atención a la competencia. La empresa gana una

posición en el mercado.

La satisfacción también está conformada por tres elementos:

Valor percibido

Resultado que el cliente percibe de la entrega de valor. Se determina desde el punto de vista

del cliente, y no de la empresa, basándose en los resultados obtenidos del producto o

servicio. Está basado en las percepciones del cliente y no en la realidad, como también

sufre el impacto de opiniones de terceros.

Expectativas

Se consideran las esperanzas del cliente en cuanto a conseguir un producto o servicio. Esto

se produce gracias a promesas sobre beneficios ofrecidos, experiencia de compras

anteriores y, opiniones. En este factor es importante la disminución de índices de

satisfacción del cliente, no significan disminución de calidad. En todo caso, es importante

monitorear las expectativas de los clientes para determinar si están dentro de lo que la

empresa puede proporcionarles, si están a la par, por debajo o encima de las expectativas

que genera la competencia y, si coinciden con lo que el cliente promedio espera para

animarse a comprar.

Niveles de satisfacción

Después de realizar la compra, el cliente contempla tres niveles de satisfacción:

insatisfacción, satisfacción y complacencia. La insatisfacción se produce cuando no se

cubren las expectativas del cliente. Como satisfacción se tiene el desempeño coincidiendo

con las expectativas del cliente. Y por último la complacencia, que es cuando el desempeño



106

excede las expectativas. Dependiendo el nivel de satisfacción del cliente, se puede conocer

el grado de lealtad hacia la empresa.

Para la obtención del nivel de satisfacción con el cliente se utiliza la siguiente formula:

𝑉𝑎𝑙𝑜𝑟 𝑃𝑒𝑟𝑐𝑖𝑏𝑖𝑑𝑜 − 𝐸𝑥𝑝𝑒𝑐𝑡𝑎𝑡𝑖𝑣𝑎𝑠 = 𝑁𝑖𝑣𝑒𝑙 𝑑𝑒 𝑆𝑎𝑡𝑖𝑠𝑓𝑎𝑐𝑐𝑖ó𝑛

Estos datos se obtienen de una investigación de mercado previamente realizada por el

equipo de marketing, a través del análisis y recopilación de la información, donde se

asignan valores a los resultados obtenidos por medio de parámetros.

Una vez obtenido el nivel de satisfacción, se debe de tomar en cuenta la rentabilidad, donde

se cuestiona ¿hasta qué punto una empresa debe invertir para lograr la satisfacción de sus

clientes? Es por eso que el reto del marketing es el generar esa satisfacción en sus clientes

de manera rentable, encontrando el equilibrio entre generar valor sin efectuar gastos

extraordinarios con motivo de asegurar clientes.

Es por eso que se considera la estrategia CRM desde el inicio de la implementación en el

modelo propuesto, con la ayuda del ciclo de Deming se obtienen datos que ayudan a la

gestión de proyectos a tener mejor relación con el cliente.



107

Anexos

1. Artículo derivado de la investigación



108



109



110



111



112



113



114



115

instituto politÉcnico nacional · 2019. 1. 25. · modelo de planificación de procesos...

Documents