UNIVERSIDAD POLITÉCNICA DE SINALOA

PROGRAMA ACADÉMICO DE INGENIERÍA

EN INFORMÁTICA

Tesina

“Metodologías hibridas en el desarrollo de

aplicaciones móviles”

Para obtener la acreditación de las estadías

profesionales y contar con los créditos para

el grado de Ingeniero en Informática.

Autor: Jaramillo Osuna Jorge Armando

Asesor: MCC. Alejandro Pérez Pasten Borja

Asesor OR: MCC. Rosa Angélica Rosales Camacho

Mazatlán, Sinaloa 13 de diciembre del 2019

2

CARTA DE ACEPTACIÓN

3

CARTA DE TERMINACIÓN

4

CARTA DE NOMBRE TESINA

5

CARTA DE ACEPTACION TESINA

6

AGRADECIMIENTOS

Agradezco enormemente a mi familia por todo su apoyo en todo momento, por estar

conmigo brindándome ánimos para nunca rendirme, por su gran sacrificio para

facilitarme el apoyo económico, gracias a todo lo que han hecho por mí, me han

permitido obtener cada uno de mis logros que a su vez compartiré con ellos.

A mi asesora MCC. Rosa Angélica Rosales Camacho por su continua y

proactiva ayuda durante todo el proceso, siempre con la intención de mejorar.

7

ÍNDICE TEMÁTICO

Índice de imágenes .................................................................................................................. 8

RESUMEN ................................................................................................................................ 9

ABSTRACT ................................................................................................................................ 9

INTRODUCCIÓN ....................................................................................................................... 9

CAPÍTULO I ............................................................................................................................. 10

1.1. Antecedentes .............................................................................................................. 11

1.1.1. Localización. ............................................................................................................. 12

1.1.2. Objetivos y prioridades de la empresa ...................................................................... 13

1.1.3. Organigrama de la empresa ...................................................................................... 13

1.1.4. Visión ........................................................................................................................ 14

1.1.5. Misión....................................................................................................................... 14

1.2. Planteamiento del problema ....................................................................................... 14

1.2.1. Propuesta de investigación ....................................................................................... 15

1.2.2. Objetivos .................................................................................................................. 15

1.2.2.1 Objetivo general ......................................................................................................... 15

1.2.2.2. Objetivos específicos ................................................................................................. 16

1.2.3. Preguntas de investigación ........................................................................................... 16

1.2.4. Hipótesis ..................................................................................................................... 17

Hipótesis general o principal .................................................................................................. 17

1.2.5 Limitaciones y supuestos ............................................................................................... 17

1.2.6 Relevancia ..................................................................................................................... 17

CAPÍTULO II ............................................................................................................................ 18

2.1 Metodologías de desarrollo de software .......................................................................... 19

2.1.1 Desarrollo de software o Ingeniería del Software .......................................................... 20

2.2 Metodologías Ágiles y Tradicionales. ................................................................................ 21

2.2.1 Metodologías Ágiles ...................................................................................................... 22

2.2.1.1 El Manifiesto Ágil. ...................................................................................................... 23

2.2.2 Metodologías Tradicionales .......................................................................................... 29

CAPÍTULO III ........................................................................................................................... 35

3.1 Planteamiento ................................................................................................................. 37

3.2. Desarrollo ....................................................................................................................... 42

Conclusiones .......................................................................................................................... 48

Bibliografías ........................................................................................................................... 49

8

Índice de imágenes Imagen 1. Ubicación universidad. [19] .......................................................................................................... 12 Imagen 2. Organigrama de la institución educativa UPSIN. [1] ...................................................................... 13 Imagen 3. Logo Agile Alliance [3]................................................................................................................... 22 Imagen 4. Filosofía XP [3] .............................................................................................................................. 27 Imagen 5. Metodología SCRUM. [3] .............................................................................................................. 28 Imagen 6.Características Crystal Clear. [3] .................................................................................................... 28 Imagen 7. Funcionamiento MSF [5] ............................................................................................................... 30 Imagen 8. Funcionamiento Win-Win Spiral Model [4] ................................................................................... 31 Imagen 9. Logo de ICONIX. [6] ...................................................................................................................... 32 Imagen 10. Tablero KANBAN. [7]................................................................................................................... 33 Imagen 11. Comparación entre metodologías á..giles y tradicionales. [8]..................................................... 36 Imagen 12. Metodologías más utilizadas en el desarrollo de aplicaciones. [9] ............................................... 40

9

RESUMEN

El presente documento ha sido realizado con la finalidad de acreditar la carrera de

Ingeniería en Informática en la Universidad Politécnica de Sinaloa. El contenido del

presenta trabajo señala la importancia del uso correcto de las metodologías de

desarrollo de software, que tienen como finalidad generar la documentación para el

entendimiento de un proyecto a nuevos colaboradores.

ABSTRACT

This document has been written in order to earn the science computer degree at

Universidad Politécnica de Sinaloa. The content in the current work points out the

importance of the correct use of the developing software methodologies, which has as

purpose the creation of documentation for further understanding to new collaborators in

a given proyect.

INTRODUCCIÓN

Con el crecimiento exponencial de las nuevas tecnologías y el acelerado cambio de

las actuales. El desarrollo de aplicaciones móviles ha tenido que evolucionar de

manera acelerada también, esto ha causado estragos en numerosos proyectos

exitosos, debido a que, en la mayoría de los casos, los desarrolladores llevan un

ritmo tan agitado y dinámico de trabajo no se dan el tiempo de llevar un registro de

todos cambios que se realizan en el proyecto en curso.

10

CAPÍTULO I

Antecedentes y planteamiento del problema

11

A continuación, se presenta un breve resumen de la institución donde se realizaron

las estadías, se describe apropiadamente la misión, visión, datos geográficos. Pero

sobre todo se explicará el planteamiento del problema para así de esta manera el

lector pueda imaginar de qué va tratar la investigación.

1.1. Antecedentes

La Universidad Politécnica de Sinaloa (UPSIN) surge a partir de una

correspondencia de los dos niveles de gobierno, Federal y Estatal, compartiendo la

misma preocupación de diversificar la oferta educativa en aquellas regiones que

carezcan de opciones viables de operar. Además, surge como parte de la propuesta

contenida en el Programa Nacional de Educación 2000-2006, que pretende

impulsar el desarrollo con equidad de un sistema de educación superior de buena

calidad que responda con oportunidad a las demandas sociales y económicas del

país y obtenga mejores niveles de certidumbre, confianza y satisfacción de sus

resultados. [1]

La necesidad de fortalecer la educación superior en el sur de nuestra entidad

federativa motivó al Ejecutivo Estatal a crear una institución de educación superior

de alta calidad que fuera capaz de formar ciudadanos ejemplares, con dominio de

la tecnología de punta y con aptitud para integrarse cabalmente a su entorno.

Después de varios estudios de orden de económico y de oferta y demanda

educativa, se decidió instalar la UPSIN en la ciudad y puerto de Mazatlán, a su vez

que se contaba con las condiciones propicias, tanto en infraestructura educativa

como industrial y de prestación de los servicios. [1]

Dichos estudios arrojaron la necesidad de crear las carreras de ingeniería en

Biotecnología, en Mecatrónica y en Informática. Así, el 30 de agosto de 2004 se

crea la UPSIN como un organismo público descentralizado del Estado de Sinaloa,

según aparece en el decreto para su creación, publicado en el diario oficial de la

fecha anteriormente indicada. El precedente histórico de la UPSIN es la creación

del subsistema de Universidades Politécnicas (UUPP) de la Subsecretaría de

Educación Superior (SES) en el 2001. [1]

En febrero de 2005 se lanzó la primera convocatoria para aspirantes a ingresar a la

UPSIN y este proceso concluyó con el registro oficial de 138 alumnos, distribuidos

12

en las tres carreras, dando inicio a las actividades académicas el día 2 de mayo del

mismo año. Al mismo tiempo se lanzó la segunda convocatoria para ingresar a la

UPSIN en septiembre de ese mismo año. A partir de entonces, la UPSIN lanza una

convocatoria anual con el propósito de iniciar actividades académicas, para cada

generación, en el mes de septiembre. [1]

1.1.1. Localización.

La Universidad Politécnica de Sinaloa se encuentra ubicada por la carretera

municipal libre de Mazatlán, Higueras, en la colonia Genaro Estrada, Mazatlán

Sinaloa.

Imagen 1. Ubicación universidad. [19]

13

1.1.2. Objetivos y prioridades de la empresa

En la Universidad Politécnica de Sinaloa, están comprometidos con la formación de

profesionistas capaces de desarrollar, aplicar e innovar conocimiento científico y

tecnológico, con sólidas bases humanistas a través de procesos y servicios

sustentables orientados hacia la mejora continua, y de estándares internacionales

que satisfagan las necesidades del sector productivo y social de la región, del país

y del mundo considerando siempre los principios de igualdad laboral y no

discriminación descritos en el anexo que se encuentra integrado al registro REC-

RG-01. [1]

1.1.3. Organigrama de la empresa

La Universidad Politécnica de Sinaloa cuenta con gran variedad de sectores en los

cuales se desempeñan diferentes labores, donde se destacan dos grandes áreas,

la académica y la administrativa; UPSIN cuenta con una administración jerárquica,

lo cual indica la existencia de encargados responsables del correcto funcionamiento

de las actividades que les han sido delegadas según el área de enfoque. [1]

Imagen 2. Organigrama de la institución educativa UPSIN. [1]

14

1.1.4. Visión

La Universidad Politécnica de Sinaloa es reconocida nacionalmente, como una

institución pública de educación superior que ofrece programas educativos de

excelencia, vinculada a organismos nacionales e internacionales, desarrollando y

aplicando líneas de investigación que impulsan la asimilación, transferencia y

mejora de la tecnología e incrementando la especialización de la fuerza laboral del

país a través de la educación continua y vinculación con el sector productivo. [1]

1.1.5. Misión

Formar profesionistas con alta capacidad tecnológica, espíritu emprendedor y

sólidas bases humanistas; generar, aplicar y difundir conocimiento, mediante

servicios de calidad, sustentados en programas académicos pertinentes, en un

modelo educativo basado en competencias y en estándares internacionales,

contribuyendo al desarrollo regional y del país. [1]

1.2. Planteamiento del problema

Cuando se tiene la idea de un proyecto innovador, no importa el ámbito de estudio,

parece sencillo organizar y ejecutar todos los pasos que tienen como objetivo la

culminación de la idea, evidentemente el resultado final será la materialización de

la idea en forma del producto esperado.

Si bien lo anterior mencionado es cierto, aun cuando el proyecto cumple las

expectativas iniciales eso apenas es el inicio del camino. Hablando del ámbito de la

tecnología, específicamente, el desarrollo de aplicaciones móviles es necesario

tener en cuenta el alcance de lo que se está realizando, cuando una idea pasa de

la mente de cualquier individuo a desarrollo y se obtiene la aceptación del mercado

objetivo, si bien esto es una excelente señal de un caso de éxito, es apenas el

principio.

Pero qué sucedería si a la persona que se le encomendó una tarea crucial

durante el desarrollo de la aplicación a un analista, desarrollador o incluso el Project

Manager de pronto falleciera o fuera despedida abruptamente sin dejar registro de

15

escrito de las labores realizadas, obviamente el código no se va ir con este

hipotético individuo, pero como todas las cosas en la vida, todo está sujeto a

interpretación lo que para una persona puede parecer casi obvio para la otra puede

terminar siendo un acertijo que demore horas.

Para este tipo de situaciones existe la documentación, para algunos puede

parecer la parte más aburrida durante el proyecto porque son horas de análisis y

entendimiento de todos los aspectos que constituyen la idea, sin embargo, esta es

una de las partes cruciales en el nacimiento de una aplicación, porque sienta las

bases del desarrollo de la idea en etapas posteriores.

1.2.1. Propuesta de investigación

En consecuencia, de la problemática ya mencionada, se llevó a cabo la presente

investigación de cómo se debe documentar apropiadamente un proyecto, cabe

aclarar que existen numerosas sugerencias acerca de cómo documentar un

proyecto, pero cada equipo de trabajo y sobre todo las ideas siempre son diferentes,

por eso mismo no es recomendable arraigarse mucho a una metodología que a otra

persona le funcionó de maravilla.

Se propone una manera de documentar que recopile los elementos de mayor

utilidad de otros casos de éxito, durante el desarrollo de cualquier proyecto

orientado a aplicaciones móviles.

El presente escrito no trata de desacreditar las sugerencias de los expertos

de la materia, sino que trata de explicar que existe más de una manera de hacer las

cosas.

1.2.2. Objetivos

Como resultado del planteamiento del problema y la propuesta de investigación se

definen los siguientes objetivos.

1.2.2.1 Objetivo general

16

Conocer los diferentes tipos de metodologías que existen en el desarrollo de

proyectos de cualquier índole, posteriormente hacer un filtrado sobre cuales se

utilizan con mayor frecuencia en el área informática, ya recopilada esta información

se realizó otra reducción de resultados, cuáles son las metodologías más utilizadas

en el desarrollo de proyectos informáticos y cuales ofrecían mayor flexibilidad

respecto al inesperado cambio de requerimientos.

La razón de ser de estas condiciones es encontrar la metodología que puede

adaptarse a cambios inesperados durante el desarrollo del proyecto.

1.2.2.2. Objetivos específicos

Los siguientes puntos hacen mención a las actividades específicas a realizar para

lograr la meta que plantea el objetivo general.

● Estudiar las diferentes metodologías existentes para encontrar las

diferencias entre cada una.

● Adquirir conocimientos sobre cómo se debe llevar a cabo el correcto

desarrollo de aplicaciones móviles.

● Adaptar las metodologías ya existentes para el desarrollo de una

aplicación móvil.

● Iniciar el desarrollo de una metodología híbrida que recopile la

información de mayor utilidad de los dos enfoques.

1.2.3. Preguntas de investigación

Antes y durante el desarrollo de la metodología híbrida se han formulado las

siguientes preguntas:

● ¿Por qué se recomienda el uso de metodologías ágiles durante el

desarrollo de aplicaciones móviles?

● ¿Cuáles son las principales ventajas y desventajas de las metodologías

ágiles y tradicionales?

● ¿Cuál es la principal razón por la que ya no se emplean metodologías

tradicionales para la realización de nuevo proyecto orientado a

aplicaciones móviles?

17

● ¿Cuáles son las metodologías híbridas más empleadas recientemente y

cuáles son sus principales ventajas y desventajas?

1.2.4. Hipótesis

En base a la problemática establecida, la propuesta de investigación y las incógnitas

ya mencionadas, se establece la siguiente hipótesis:

Hipótesis general o principal

El desarrollo de una metodología híbrida servirá para futuros proyectos de

aplicaciones móviles, se espera optimizar la parte de la documentación en mayor

medida y realizar un análisis de los requerimientos de la aplicación con un enfoque

dinámico.

1.2.5 Limitaciones y supuestos

Los métodos empleados en el desarrollo de aplicaciones móviles se actualizan cada

vez más rápido y con mayor frecuencia, sin embargo, se quiere hacer en su mayor

medida posible que esta metodología sea dinámica en todos los aspectos posibles,

por lo que se podrá implantar nuevas técnicas a la misma para retrasar su desgaste.

Como supuesto se espera que la investigación en curso sirva de apoyo a cualquier

persona que decida emprender el desarrollo de una aplicación móvil y no conozca

qué metodología utilizar.

1.2.6 Relevancia

La necesidad de vincular los dos tipos de metodologías de desarrollo añade una

nueva perspectiva al momento de emprender un nuevo proyecto informático, lo

atractivo de este instrumento de desarrollo es que se recopila lo esencial y

solamente lo esencial para desarrollar aplicaciones móviles en estos tiempos

cambiantes, reduciendo procesos que probablemente ya no sean factibles de seguir

o simplemente se han vuelto obsoletos.

18

CAPÍTULO II

Estado del arte

19

A continuación, en este capítulo se listan y definirán los conceptos e información

clave para el desarrollo y comprensión de una metodología híbrida.

2.1 Metodologías de desarrollo de software

Las metodologías que se utilizan para desarrollar software se refieren al framework

donde se estructura, planifica y controla los procesos durante el desarrollo de un

sistema de información. Una gran variedad de frameworks ha evolucionado con el

paso del tiempo, cada uno de ellos posee fortalezas y debilidades. Esto quiere decir

que no necesariamente una sola metodología será la ideal para el desarrollo de

cualquier proyecto, sin embargo, al existir un paraguas extenso de metodologías

alguna de ellas se puede adecuar al proyecto cualquiera que fuese, es

responsabilidad del equipo de trabajo adaptar la metodología de acuerdo a las

técnicas y organización que tenga el proyecto en cuestión. [2]

Existen numerosas metodologías de software, pero para empezar simple y con

claridad, se dejarán en claro dos conceptos importantes:

● Método/Metodología

● Desarrollo de Software/Ingeniería de software

Existe una relación entre método, ciencia e investigación. Beauregard González

relaciona el método con la ciencia y la investigación al definir método:

Método se define como un proceso o conjunto de procedimientos que sirven

de instrumento para alcanzar los fines de la investigación siendo un

procedimiento general basado en principios lógicos que pueden ser comunes

a varias ciencias. [2]

20

De esta manera:

El método científico es el procedimiento planeado que sigue en la

investigación para descubrir las formas de existencia de los procesos

objetivos, para desentrañar sus conexiones internas y externas, para

generalizar y profundizar los conocimientos así adquiridos, para llegar a

demostrarlos con rigor nacional y para comprobar en el experimento y con

las técnicas de aplicación. [2]

Habiendo esclarecido lo anterior metodología se define como el conjunto de

procedimientos racionales utilizados para alcanzar el objetivo o la gama de objetivos

que rige una investigación científica, una exposición doctrinal o tareas que requieran

habilidades, conocimientos o cuidados específicos. [2] La principal labor de la

metodología es hacer un análisis de los métodos que se presentan para

posteriormente determinar cuál es el apropiado a aplicar para una investigación o

proyecto.

2.1.1 Desarrollo de software o Ingeniería del Software

El Desarrollo de Software significa empezar a construirlo, si es necesario desde

cero, por esta razón es considerado una ingeniería, las definiciones a continuación

son las que el autor considera que tiene mayor similitud con el trabajo en curso.

Ingeniería del Software que se define entonces como:

● La aplicación de un enfoque sistemático, disciplinado y cuantificable al

desarrollo, operación y mantenimiento de software, y el estudio de estos

enfoques. [2] [3].

● La ingeniería de software trata del establecimiento de los principios y

métodos de la ingeniería a fin de obtener software de modo rentable, que sea

fiable y trabaje en máquinas reales. [2] [3].

● Ingeniería de software es el estudio de los principios y metodologías para el

desarrollo y mantenimiento de sistemas software. [2] [3].

21

Software

El software de computadora es el producto que construyen los programadores

profesionales y al que después le dan mantenimiento durante un largo tiempo.

Incluye programas que se ejecutan en una computadora de cualquier tamaño y

arquitectura, contenido que se presenta a medida que se ejecutan los programas

de cómputo e información descriptiva tanto en una copia dura como en formatos

virtuales que engloban virtualmente a cualesquiera medios electrónicos. La

ingeniería de software está formada por un proceso, un conjunto de métodos

(prácticas) y un arreglo de herramientas que permite a los profesionales elaborar

software de cómputo de alta calidad. [4]

Dentro de la ingeniería del software existen cantidades abrumadoras de

conceptos, modelos, enfoques y técnicas. En el desarrollo de software se pueden

emplear diversas metodologías para construir software, pero al final del día existen

dos enfoques al momento de emprender un proyecto, las Metodologías Ágiles y

Tradicionales.

2.2 Metodologías Ágiles y Tradicionales.

Agilidad. Dentro del contexto del trabajo de la ingeniería de software Ivar Jacobson

realiza un análisis bastante útil:

“La agilidad se ha convertido en la palabra mágica de hoy para describir un

proceso del software moderno. Todos son ágiles. Un equipo ágil es diestro y

capaz de responder de manera apropiada a los cambios. El cambio es de lo

que trata el software en gran medida. Hay cambios en el software que se

construye, en los miembros del equipo, debidos a las nuevas tecnologías, de

todas clases y que tienen un efecto en el producto que se elabora o en el

proyecto que lo crea. Deben introducirse apoyos para el cambio en todo lo

que se haga en el software; en ocasiones se hace porque es el alma y

corazón de éste. Un equipo ágil reconoce que el software es desarrollado por

22

individuos que trabajan en equipo, y que su capacidad, su habilidad para

colaborar, es el fundamento para el éxito del proyecto.” [4]

2.2.1 Metodologías Ágiles

En una reunión celebrada en febrero de 2001 en Utah-EEUU, nace el término

“ágil” aplicado al desarrollo de software. En esta reunión participan un grupo

de 17 expertos de la industria del software, incluyendo algunos de los

creadores o impulsores de metodologías de software. Su objetivo fue esbozar

los valores y principios que deberían permitir a los equipos desarrollar

software rápidamente y respondiendo a los cambios que puedan surgir a lo

largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de

desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos

por la documentación que se genera en cada una de las actividades

desarrolladas. Varias de las denominadas metodologías ágiles ya estaban

siendo utilizadas con éxito en proyectos reales, pero les faltaba una mayor

difusión y reconocimiento. [5]

Tras esta reunión se creó The Agile Alliance, una organización, sin ánimo de

lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil

de software y ayudar a las organizaciones para que adopten dichos

conceptos. El punto de partida fue el Manifiesto Ágil, un documento que

resume la filosofía “ágil”. [5]

Imagen 3. Logo Agile Alliance [3]

23

2.2.1.1 El Manifiesto Ágil.

El Manifiesto comienza enumerando los principales valores del desarrollo ágil. Se

valora:

● Al individuo y las interacciones del equipo de desarrollo sobre el

proceso y las herramientas. La gente es el principal factor de éxito de un

proyecto software. Si se sigue un buen proceso de desarrollo, pero el equipo

falla, el éxito no está asegurado; sin embargo, si el equipo funciona, es más

fácil conseguir el objetivo final, aunque no se tenga un proceso bien definido.

No se necesitan desarrolladores brillantes, sino desarrolladores que se

adapten bien al trabajo en equipo. Así mismo, las herramientas

(compiladores, depuradores, control de versiones, etc.) son importantes para

mejorar el rendimiento del equipo, pero el disponer más recursos que los

estrictamente necesarios también puede afectar negativamente. En

resumen, es más importante construir un buen equipo que construir el

entorno. Muchas veces se comete el error de construir primero el entorno y

esperar que el equipo se adapte automáticamente. Es mejor crear el equipo

y que éste configure su propio entorno de desarrollo en base a sus

necesidades. [5]

● Desarrollar software que funciona más que conseguir una buena

documentación. Aunque se parte de la base de que el software sin

documentación es un desastre, la regla a seguir es “no producir documentos

a menos que sean necesarios de forma inmediata para tomar una decisión

importante”. Estos documentos deben ser cortos y centrarse en lo

fundamental. Si una vez iniciado el proyecto, un nuevo miembro se incorpora

al equipo de desarrollo, se considera que los dos elementos que más le van

a servir para ponerse al día son: el propio código y la interacción con el

equipo. [5]

24

● La colaboración con el cliente más que la negociación de un contrato.

La característica particular del desarrollo de software hace que muchos

proyectos han fracasado por intentar cumplir unos plazos y unos costos

preestablecidos al inicio del mismo, según los requisitos que el cliente

manifestaba en ese momento. Por ello, se propone que exista una interacción

constante entre el cliente y el equipo de desarrollo. Esta colaboración entre

ambos será la que marque la marcha del proyecto y asegure su éxito. [5]

● Responder a los cambios más que seguir estrictamente un plan. La

habilidad de responder a los cambios que puedan surgir a lo largo del

proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.)

determina también el éxito o fracaso del mismo. Por lo tanto, la planificación

no debe ser estricta puesto que hay muchas variables en juego, debe ser

flexible para poder adaptarse a los cambios que puedan surgir. Una buena

estrategia es hacer planificaciones detalladas para unas pocas semanas y

planificaciones mucho más abiertas para unos pocos meses. [5]

Los valores anteriores inspiran los doce principios del manifiesto. Estos principios

son las características que diferencian un proceso ágil de uno tradicional. Los dos

primeros son generales y resumen gran parte del espíritu ágil. Son:

I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de

software que le aporte un valor. Un proceso es ágil si a las pocas semanas de

empezar ya entrega software que funcione, aunque sea rudimentario. El cliente

decide si pone en marcha dicho software con la funcionalidad que ahora le

proporciona o simplemente lo revisa e informa de posibles cambios a realizar.

[5]

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente

tenga una ventaja competitiva. Este principio es una actitud que deben adoptar

los miembros del equipo de desarrollo. Los cambios en los requisitos deben

verse como algo positivo. Les va a permitir aprender más, a la vez que logran

25

una mayor satisfacción del cliente. Este principio implica además que la

estructura del software debe ser flexible para poder incorporar los cambios sin

demasiado coste añadido. El paradigma orientado a objetos puede ayudar a

conseguir esta flexibilidad. Luego existen una serie de principios que tienen que

ver directamente con el proceso de desarrollo de software a seguir. [5]

III. Entregar frecuentemente software que funcione desde un par de semanas a un

par de meses, con el menor intervalo de tiempo posible entre entregas. La

entrega al cliente se insiste en que sean software, no planificaciones, ni

documentación de análisis o de diseño. [5]

IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del

proyecto. El proceso de desarrollo necesita ser guiado por el cliente, por lo que

la interacción con el equipo es muy frecuente. [5]

V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el

apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. La

gente es el principal factor de éxito, todo los demás (proceso, entorno, gestión,

etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo

sobre los individuos debe ser cambiado. [5]

VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar

información dentro de un equipo de desarrollo. Los miembros de equipo deben

hablar entre ellos, éste es el principal modo de comunicación. Se pueden crear

documentos, pero no todo estará en ellos, no es lo que el equipo espera. [5]

VII. El software que funciona es la medida principal de progreso. El estado de un

proyecto no viene dado por la documentación generada o la fase en la que se

encuentre, sino por el código generado y en funcionamiento. Por ejemplo, un

proyecto se encuentra al 50% si el 50% de los requisitos ya están en

funcionamiento. [5]

VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener una paz

constante. No se trata de desarrollar lo más rápido posible, sino de mantener el

ritmo de desarrollo durante toda la duración del proyecto, asegurando en todo

momento que la calidad de lo producido es máxima. Finalmente, los últimos

principios están más directamente relacionados con el equipo de desarrollo, en

cuanto metas a seguir y organización del mismo. [5]

26

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

Producir código claro y robusto es la clave para avanzar más rápidamente en el

proyecto. [5]

X. La simplicidad es esencial. Tomar los caminos más simples que sean

consistentes con los objetivos perseguidos. Si el código producido es simple y

de alta calidad será más sencillo adaptarlo a los cambios que puedan surgir. [5]

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos

organizados por sí mismos. Todo el equipo es informado de las

responsabilidades y éstas recaen sobre todos sus miembros. Es el propio equipo

el que decide la mejor forma de organizarse, de acuerdo a los objetivos que se

persigan. [5]

XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más

efectivo, y según esto ajusta su comportamiento. Puesto que el entorno está

cambiando continuamente, el equipo también debe ajustarse al nuevo escenario

de forma continua. Puede cambiar su organización, sus reglas, sus

convenciones, sus relaciones, etc., para seguir siendo ágil. [5]

Entre las metodologías ágiles más destacadas hasta el momento se pueden

nombrar:

• XP (Extreme Programming)

• Scrum

• Crystal Clear

XP

Es una metodología ágil centrada en potenciar las relaciones interpersonales como

clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo,

preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen

clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo

de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las

soluciones implementadas y coraje para enfrentar los cambios. XP se define como

especialmente adecuada para proyectos con requisitos imprecisos y muy

cambiantes, y donde existe un alto riesgo técnico. Los principios y prácticas son de

27

sentido común pero llevadas al extremo, de ahí proviene su nombre. Kent Beck, el

padre de XP, describe la filosofía de XP sin cubrir los detalles técnicos y de

implantación de las prácticas. Posteriormente, otras publicaciones de experiencias

se han encargado de dicha tarea. [5]

Imagen 4. Filosofía XP [3]

SCRUM

Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco

para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10

años. Está especialmente indicada para proyectos con un rápido cambio de

requisitos. Sus principales características se pueden resumir en dos. El desarrollo

de software se realiza mediante iteraciones, denominadas sprints, con una duración

de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra

al cliente. La segunda característica importante son las reuniones a lo largo

proyecto. Éstas son las verdaderas protagonistas, especialmente la reunión diaria

de 15 minutos del equipo de desarrollo para coordinación e integración. [5]

28

Imagen 5. Metodología SCRUM. [3]

Crystal Methodologies

Se trata de un conjunto de metodologías para el desarrollo de software

caracterizadas por estar centradas en las personas que componen el equipo (de

ellas depende el éxito del proyecto) y la reducción al máximo del número de

artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo

de software se considera un juego cooperativo de invención y comunicación,

limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo

que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como

tener políticas de trabajo en equipo definidas. Estas políticas dependerán del

tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo,

Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros). [5]

Imagen 6.Características Crystal Clear. [3]

29

2.2.2 Metodologías Tradicionales

Imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con

el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la

planificación total de todo el trabajo a realizar y una vez que está todo detallado,

comienza el ciclo de desarrollo del producto software. Se centran especialmente en

el control del proceso, mediante una rigurosa definición de roles, actividades,

artefactos, herramientas y notaciones para el modelado y documentación detallada.

Además, las metodologías tradicionales no se adaptan adecuadamente a los

cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno,

donde los requisitos no pueden predecirse o bien pueden variar.

Entre las metodologías tradicionales o pesadas se puede citar:

• RUP (Rational Unified Procces)

• MSF (Microsoft Solution Framework)

• Win-Win Spiral Model

• Iconix

RUP

Rational Unified Process (RUP) es una metodología de desarrollo de software

orientado a objeto que establece las bases, plantillas, y ejemplos para todos los

aspectos y fases de desarrollo del software. RUP es herramientas de la ingeniería

de software que combinan los aspectos del proceso de desarrollo (como fases

definidas, técnicas, y prácticas) con otros componentes de desarrollo (como

documentos, modelos, manuales, código fuente, etc.) dentro de un framework

unificado [6]

30

Imagen 2.5. Flujos en la metodología RUP. [4]

MSF

Microsoft Solution Framework es una metodología para el desarrollo de software

para la planificación, desarrollo y gestión de proyectos tecnológico. Se centra en el

modelo de procesos y de equipo dejando los demás aspectos en segundo plano. [7]

Imagen 7. Funcionamiento MSF [5]

31

Win-WIin Spiral Model

El modelo Win-Win es una adaptación del modelo espiral que se enfatiza en la

participación del cliente en el proceso de desarrollo de un producto de software. En

un caso ideal, el desarrollador simplemente pregunta al cliente lo que se requiere y

el cliente proporciona suficiente información y detalles para proceder. Sin embargo,

esto no suele ocurrir en la mayoría de los casos y es necesario que se establezcan

negociaciones significativas entre ambas partes para equilibrar la funcionalidad y

rendimiento con los costos y tiempo de salida al mercado del producto.

El modelo Win-Win deriva su nombre del objetivo de estas negociaciones, es

decir, "ganar-ganar". El cliente recibe el producto que satisface la mayoría de sus

necesidades, y el desarrollador trabaja para alcanzar presupuestos y fechas de

entrega. Para lograr este objetivo, se realizan varias actividades de negociación al

principio de cada paso alrededor de la espiral. [7]

Imagen 8. Funcionamiento Win-Win Spiral Model [4]

ICONIX

Es una metodología pesada-ligera de Desarrollo del Software que se encuentre a

medio camino entre RUP (Rational Unified Process) y XP (eXtreme Programming),

es una metodología simplificada en comparación a otras más tradicionales, la cual

unifica un conjunto de métodos de orientación a objetos con el objetivo de tener un

control estricto sobre todo el ciclo de vida del producto a realizar, cuenta con una

secuencia de pasos que se deben seguir y determina claramente las actividades a

desarrollar en cada etapa del ciclo de vida del proyecto que la utilice.

32

Imagen 9. Logo de ICONIX. [6]

KANBAN

En general, Kanban es un sistema de programación para lean y otros procesos JIT.

En un proceso Kanban, existen "tarjetas" físicas o virtuales (generalmente post-its)

llamadas Kanban que se mueven a través del proceso de principio a fin. El objetivo

es mantener un flujo constante de Kanban.

Cuando se utiliza para el desarrollo de software, Kanban utiliza las etapas del

ciclo de vida del desarrollo de software (SDLC) para representar las diferentes

etapas del proceso. El objetivo es controlar y gestionar el flujo de características

(representadas por tarjetas Kanban) para que el número de características que

entran en el proceso coincida con las que se están completando.

A diferencia de, por ejemplo Scrum, Kanban es una metodología ágil que no

es necesariamente iterativa. Procesos como Scrum tienen iteraciones cortas que

imitan el ciclo de vida de un proyecto a pequeña escala, teniendo un comienzo y un

final distintos para cada iteración. Kanban permite que el software se desarrolle en

un solo ciclo de desarrollo. A pesar de esto, Kanban es un ejemplo de una

metodología ágil porque cumple con los doce principios detrás del manifiesto ágil,

porque, aunque no es iterativo, es incremental.

El principio detrás del Kanban, que permite que sea incremental y ágil, es

que tiene un rendimiento limitado. Sin iteraciones, un proyecto Kanban no tiene

puntos de inicio o final definidos para work items individuales; cada uno puede

empezar y terminar independientemente del otro, y los work items no tienen una

33

duración predeterminada. En cambio, se reconoce que cada fase del ciclo de vida

tiene una capacidad limitada de trabajo en un momento dado. Se crea un pequeño

elemento de trabajo a partir de la lista de requisitos priorizados y no iniciados y luego

se inicia el proceso de desarrollo, generalmente con la elaboración de algunos

requisitos. No se permite que un work item pase a la siguiente fase hasta que se

abra una cierta capacidad. Al controlar el número de tareas activas en un momento

dado, los desarrolladores todavía se acercan al proyecto global de forma

incremental, lo que les da la oportunidad de aplicar principios ágiles.

Imagen 10. Tablero KANBAN. [7]

Los proyectos Kanban tienen límites llamados Work In Progress (WIP), que

son las medidas de la capacidad que mantiene al equipo de desarrollo enfocado en

una pequeña cantidad de trabajo a la vez. Sólo a medida que se completan las

tareas, las nuevas se incorporan al ciclo. Los límites del WIP deben ser ajustados

en base a comparaciones del esfuerzo esperado versus el esfuerzo real para las

tareas que se completan.

Kanban no impone ninguna definición de rol, como, por ejemplo, Scrum, y

junto con la ausencia de iteraciones formales, la flexibilidad de roles hace que

Kanban sea atractivo para aquellos que han estado usando modelos de desarrollo

de estilo waterfall-style y que quieren cambiar, pero que temen la conmoción inicial

34

que algo como Scrum puede causar mientras son adoptados por un equipo de

desarrollo.

Framework: es un entorno de trabajo o marco de trabajo. Es un conjunto

estandarizado de conceptos, prácticas y criterios para enfocar un tipo de

problemática particular que sirve como referencia, para enfrentar y resolver nuevos

problemas de índole similar. [4]

35

CAPÍTULO III

Planteamiento y desarrollo

36

Después de haber dado una breve introducción a las metodologías más conocidas,

es evidente que el desarrollo de software no es algo que deba llevarse a la ligera o

de improviso, requiere de una eficiente comunicación y organización en el equipo

de trabajo. No importa el enfoque de la metodología, la constante que puede

apreciarse a simple vista es que un solo individuo no es capaz de desarrollar

software funcional, siempre va ser necesario de un equipo de trabajo. En la siguiente

tabla se muestra las diferencias que existen entre las metodologías ágiles y

tradicionales, en ella se puede ver que los equipos difieren en cantidad y

organización de integrantes.

Imagen 11. Comparación entre metodologías á..giles y tradicionales. [8]

Una vez conocidos los conceptos necesarios, es momento de explicar cómo

fue que surgió la necesidad de una metodología que uniera las técnicas más útiles

para el desarrollo de una aplicación móvil, es decir cómo fue que se decidió emplear

una metodología híbrida.

37

3.1 Planteamiento

Las ideas naturalmente nacen de las necesidades, cualquier necesidad que haya

surgido fue resuelta con una idea que se materializó en una solución. El anterior

enunciado aplica para cualquier área profesional y el desarrollo de software no es

la excepción, de la idea nace el software. Sin embargo, como ya se mencionó en

repetidas ocasiones en este documento el software requiere de ingenio y una

excelente organización, si se desea un producto de calidad por supuesto.

Por ello, es importante seleccionar cual va ser la metodología que se

pretende implementar, cual se adecua a las necesidades del equipo de desarrollo.

Actualmente todos los fabricantes de aplicaciones móviles o web se inclinan por las

metodologías ágiles, como SCRUM, KANBAN o XP, estas formas de trabajar son

eficientes cuando los requerimientos son cambiantes, por otro lado, si se conoce

con exactitud el producto final con requerimientos estrictamente rígidos en la opinión

del autor es recomendable utilizar una metodología tradicional como RUP o MSF.

Aunque existen estos dos enfoques ¿Qué sucedería si el proyecto que se

esté realizando, el equipo encargado tiene la falsa idea de que se conocen los

requerimientos, subsecuente a ello después de realizar el apropiado análisis estos

pasan a desarrollarse?

En consecuencia, a la situación anterior, es importante aclarar que es de

suma importancia seleccionar de manera consciente que metodología se va

emplear para desarrollar un proyecto que tiene como resultado la entrega de

software, evaluar adecuadamente todos los beneficios y contras que ofrece

determinada forma de trabajar, a partir de ello el equipo debe utilizar su criterio, si

una metodología de las evaluadas tiene más beneficios que contras entonces esta

es la indicada. Aunque esto no significa que se deba casar con una metodología en

particular, pero si la ya mencionada tiene demasiados beneficios es bastante

evidente que esa debe elegirse, ahora que si sucede el escenario en el que existe

una igualdad de beneficios y contras ¿Qué se debe hacer?

38

Para empezar, se va describir primero que es lo que NO se debe hacer, se

utilizara como motivo de ejemplo de dos situaciones, donde en ambas tienen los

requerimientos inciertos, la factibilidad de la implementación inicial de la idea era

remota o casi nula y el equipo de trabajo cuenta con nula experiencia en la

administración de proyectos, en este caso no se realizó una evaluación para

seleccionar la metodología a implementar. Con todos estos factores conocidos se

decidió (inconscientemente) utilizar una metodología en su mayoría tradicional. Por

motivos de practicidad este caso será llamado Caso A.

Caso A.

El equipo de desarrollo cuenta con los integrantes necesarios para empezar a

construir lo que en la mente de cada integrante será el próximo gran hit en el mundo

de las aplicaciones móviles, esta idea cambiará por completo la manera de hacer

las cosas ¿Bastante impresionante no?

Al decidir utilizar técnicas derivadas de una metodología tradicional, el grupo

de trabajo sigue la pauta que dicta esta forma de trabajar se levantan los

requerimientos de las fuentes disponibles, si bien se conoce que estas fuentes

causan más de una duda debido a que son inciertas, se decide continuar,

posteriormente se realiza un análisis de los requerimientos obtenidos, nuevamente

surgen inquietudes respecto a la veracidad de las fuentes y sobre todo la viabilidad

del proyecto. A raíz de ello se propone tomarse un momento para reflexionar si esa

es la manera ideal de hacer las cosas, a final de cuentas se decide seguir con el

desarrollo, tomando como la razón más importante la cantidad de tiempo invertido

en el proyecto.

Subsiguientemente se realiza la documentación y el esquema de la base de

datos, hasta ahora se puede decir que el proyecto que va por buen camino, ahora

es necesario hacer una pausa para analizar lo anterior. La capacidad de los

integrantes inexpertos del grupo de trabajo no presenta una complicación alguna a

la hora de desempeñar las tareas requeridas durante las etapas propuestas por la

metodología tradicional que han elegido. De igual manera el criterio analítico del

equipo no representa un problema, porque a pesar de hacer caso omiso de la fuente

39

de los requerimientos, se identificó la desconfianza al momento de redactarlos, esto

sucede de igual manera con la viabilidad del proyecto, se reconoce que no tenga la

aceptación esperada, aun así, se decide continuar. Al transcurrir un periodo no muy

prolongado el equipo decide finalmente reestructurar todo el proyecto apoyándose

de un enfoque ágil con el propósito de ajustarse mejor a los cambios y volver sentar

las bases de la nueva organización del proyecto.

En el Caso A, tras haber leído lo anterior, a primera vista se puede decir que

el enfoque tradicional no se adapta apropiadamente al cambio, la manera de

trabajar con las metodologías tradicionales en la mayoría de las ocasiones se

muestra rígida al aplicar cambios en etapas avanzadas del proyecto.

Ahora que se expuso la situación del Caso A es momento de abrir paso para

el Caso B, en este caso la situación relatada es similar al caso A solamente que el

equipo de desarrollo decide emplear una metodología ágil.

Caso B

El equipo de desarrollo cuenta con los integrantes necesarios para empezar a

construir lo que en la mente de cada integrante será el próximo gran hit en el mundo

de las aplicaciones móviles, esta idea cambiará por completo la manera de hacer

las cosas ¿Bastante impresionante no?

Este equipo tiene noción de las metodologías de software existentes, sabe

que hay tradicionales y ágiles, así también, es consciente que en el mundo actual

de las aplicaciones móviles las tecnologías de desarrollo se actualizan con una

frecuencia mayor a la deseada. Es de su conocimiento que deben encontrar una

manera de trabajar que se adecue al cambio apropiadamente, y por cambio se

refiere a las tecnologías, algún cambio en las historias de usuarios propuestas por

los integrantes o cualquier otra anomalía detectada en las iteraciones del proyecto

en cualquier etapa. Ciertamente este equipo de trabajo, se encuentra en una mejor

posición al iniciar el desarrollo.

Ahora, el equipo pone manos a la obra, se compromete con las reuniones

diarias de integración de 15 minutos, se planifica y se asignan las tareas a los

40

miembros del equipo se especifican fechas de entrega, se generan los primeros

maquetados de lo que podrían ser las pantallas finales, implementan sprints

semanales para ver el estado actual en que se encuentran, surgen cambios en las

historias de usuarios, pero estos son bien administrados debido a la flexibilidad de

esta metodología.

Todo va de acuerdo a lo planeado, pero de pronto, sucede que el ritmo que

en un principio aparentemente se mostraba sustentable, deja de serlo, la adaptación

a los cambios cada vez más abruptos termina por ser abrumadora, dicho lo anterior

se plantea una justa y necesaria reestructuración al proyecto, el equipo se dio

cuenta que si bien los cambios que el proyecto podría o no sufrir durante el

desarrollo son soportados a causa de la naturaleza de la metodología empleada, la

incidencia de los cambios cada vez más frecuente terminó por transformar casi por

completo la esencia de la aplicación que se tenía en mente, obligando a si, a

reevaluar todo lo anterior mencionado.

Entonces ¿Qué significa lo anterior? ¿Sera acaso que ninguna metodología

sirve? Por supuesto que no, las metodologías sin importar el enfoque tienen en su

favor abundantes casos de éxito a su favor. Como se muestra en la siguiente

imagen.

Imagen 12. Metodologías más utilizadas en el desarrollo de aplicaciones. [9]

41

Por lo tanto, si la metodología tiene casos de éxito con un índice demasiado

alto y no tiene éxito en el proyecto en el que se está implementando, esto solo puede

significar una sola cosa. Probablemente se está aplicando de manera errónea,

aunque esta afirmación puede ser cierta en la mayoría de las ocasiones, en el

desarrollo de software, lo que para un grupo de trabajo funcionó con éxito no quiere

decir que va funcionar para todos exactamente igual, esto es propiciado a que cada

equipo de desarrollo cuenta con diferentes aptitudes, respuesta a la organización,

curva de aprendizaje diferente, entre otras variables. A dónde se quiere llegar con

esto es, que hay diferentes maneras de hacer las cosas, cuando se están haciendo

de la manera indicada y aun así no se obtienen los resultados esperados es ahí,

cuando el ingenio sale a relucir.

En dado caso que la metodología seleccionada se esté aplicando

apropiadamente y simplemente no se estén cumpliendo los objetivos esperados,

justo en el momento en que el equipo reconozca esta situación, se debe reflexionar

y volver a evaluar el filtrado de las metodologías existentes, pros y contras, si se

encuentran la misma cantidad de ventajas y desventajas al implementarla (aquí no

importa si el enfoque es ágil o tradicional) en estas circunstancias es válido tomar

lo que le parezca útil al equipo de desarrollo, ya sea técnicas, formatos, esquemas,

tableros; y añadirlos a lo que terminará siendo la metodología que fungirá como guía

en el desarrollo del proyecto.

Aquí es cuando surge una metodología híbrida, que no es otra cosa que la

unión de técnicas de desarrollo, puede ser Ágil-Tradicional, Tradicional-Tradicional,

Ágil-Ágil, mientras sea de utilidad en el proyecto y el equipo considere que no

entorpezca la organización resulta válido realizarlo.

Aunque ya se mencionó cómo pueden surgir metodologías híbridas, si bien

no se asegura que esta manera de trabajar garantizará el éxito del proyecto, algo

que se puede decir con certeza es que a veces un cambio de perspectiva en el

desarrollo de aplicaciones móviles puede facilitar enormemente su realización

42

3.2. Desarrollo

Hasta esta parte se han expuesto dos situaciones que son comunes a la hora de

construir software desde cero, anteriormente se hizo mención de lo que es una

metodología híbrida, que simplemente es cuando convergen dos metodologías de

cualquier enfoque, el autor a continuación se dispondrá a explicar y mencionar

buenas prácticas y recomendaciones para trabajar con una metodología híbrida.

En primer lugar, para empezar con el pie derecho, hay que tener claro que

no es necesario forzar la implementación de una metodología híbrida, incluso hay

expertos en software que no están convencidos totalmente de su factibilidad.

¿Cómo identificar si una metodología híbrida es factible? Si en los casos

anteriormente expuestos el lector y su equipo de trabajo se sienten identificados con

una o ambas situaciones, es un indicador útil de qué valdría la pena implementar

una metodología de esta naturaleza. De esta manera se puede proseguir

Sin importar el enfoque al momento de iniciar a desarrollar software se

necesitan de dos partes: desarrollador y cliente/mercado. Es una constante cuando

se construye una aplicación, por lo general no se acostumbra a crear software sin

tener pensado hacia quien va dirigido, realmente no tendría sentido la realización

del mismo, siendo así se puede establecer otra constante: el cliente y el

desarrollador no hablan el mismo idioma, no haciendo referencia a que uno habla

inglés y otro español o viceversa, sino que el cliente cuando acude con un equipo

de desarrollo en busca de satisfacer una necesidad, en la mayoría de los casos el

relato que la parte interesada explica al desarrollador no es del todo claro, para el

cliente el problema es bastante claro y la solución informática también, cualquiera

pensaría que es bastante fácil de entender, solo apuntar todas las solicitudes que

el comprador vaya exponiendo, y de hecho es todo lo que el cliente tiene que hacer,

sin embargo, aquí es cuando comienza la ingeniería en software, porque el cliente

como ya se dijo solo debe explicar su necesidad, por otro lado el programador debe

encargarse de traducir el relato en algo que en ingeniería de software se conoce

como requerimientos.

43

Este término se define como:

En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de

requisitos o Ingeniería de requerimientos comprende todas las tareas relacionadas

con la determinación de las necesidades o de las condiciones a satisfacer para un

software nuevo o modificado, tomando en cuenta los diversos requisitos de las

partes interesadas, que pueden entrar en conflicto entre ellos. Sin embargo, la

Ingeniería de requerimientos también es contemplada en otras disciplinas, estando

fuertemente vinculada con la administración de proyectos. [9]

Estos requerimientos tienen fases que deben cumplirse, son tres.

● Obtención de requerimientos: búsqueda y obtención de los requerimientos

desde los grupos de interés. [10]

● Análisis: comprobación de la consistencia y completitud de los

requerimientos. [10]

● Verificación: constatación de que los requerimientos especificados son

correctos. [10]

Estos requerimientos son fundamentales, son la base del proyecto, es de suma

importancia dedicarles el tiempo necesario para su entendimiento. A partir de ellos

se desprenden todas las tareas posteriores, la persona encargada de esta actividad

debe contar con las siguientes habilidades:

● Ser un buen oyente

● Comprensión

● Pensamiento crítico para detectar las dudas que surjan

● Una excelente facilidad de palabra para estructurar las preguntas al cliente

● Noción de tecnicismos informáticos

Lo anterior servirá para despejar todas las dudas que vayan apareciendo. No es

fácil que una persona que reúna las cualidades anteriores, resultaría maravillosa

contar con un integrante con todas las aptitudes ya mencionadas, a pesar de ello

no siempre es así, pero no hay necesidad de alarmarse, en ocasiones estas

44

características se reúnen, pero no se concentran en una sola persona, pueden ser

dos o incluso tres.

En las metodologías tradicionales, así como las ágiles al terminar el

levantamiento de requerimientos, se realiza un análisis de los mismos para

identificar los módulos que fungen como base de aplicación, el único detalle resulta

ser que en las tradicionales el siguiente paso es el diseño, hasta llegar a etapas

finales como la entrega del software al cliente. En cambio, en las metodologías

ágiles sucede que se hace un análisis de igual manera, pero si de pronto el cliente

omite algo al programar reuniones frecuentes con el cliente un cambio repentino en

los requerimientos no afectaría o entorpecer el proceso de desarrollo.

Volviendo al tema de los requerimientos es necesario hacer énfasis en el

análisis, esta fase es esencial, en ella todos los miembros del grupo de trabajo se

familiarizan con el software a construir, es crucial que todos los principales

participantes estén presentes y sobre todo atentos. Dicho lo anterior cuando se

realiza el análisis de los requerimientos por costumbre el desarrollador tiende a

pensar en todas las posibilidades que se desprenden de los mismos. Por ejemplo,

hay quienes al momento de desglosar el análisis se apoyan con ejemplos gráficos,

con bosquejos de lo que podrían llegar a ser pantallas de usuario finales, si bien

esto no es malo del todo, en esta etapa resulta limitante y puede retrasar la

abstracción de las ideas, en resumen, al realizar el análisis se recomienda

encarecidamente no preocuparse por el diseño, solamente proponer todas las

funcionalidades posibles de los requerimientos en cuestión.

Cabe señalar que es importante mantener todo el proceso de análisis de forma

dinámica, el equipo de trabajo debe encontrar la manera de mantener un ritmo

productivo y sobre todo con motivación, se debe evitar a toda costa que solamente

un par de miembros tenga iniciativa, lo ideal sería ver esto como una lluvia de ideas.

45

Esto es porque, al final los requerimientos recopilados están sujetos a una

validación, aquí se muestran los parámetros a evaluar para su apropiada

aprobación:

● Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo.

[9]

● Cohesión: el requerimiento debe dirigirse a solo una única cosa. [9]

● Completo: el requerimiento debe estar completamente declarado en un único

lugar, sin información faltante. [9]

● Consistente: el requerimiento no debe contradecir ningún otro requerimiento

y debe ser completamente consistente con toda la documentación. [9]

● Correcto/necesario: el requerimiento debe cumplir con la necesidad

declarada por los interesados en el sistema/software. [9]

● Factible/viable: el requerimiento debe poder ser implementado. [9]

● No ambiguo: el requerimiento debe estar concisamente declarado. Debe

expresar hechos objetivos, no opiniones subjetivas. Debe ser interpretado de

una única manera. [9]

● Obligatorio: el requerimiento debe representar una característica definida por

el grupo interesado en el desarrollo del sistema/software, su ausencia no

puede ser reemplazada. [9]

● Observable externamente: el requerimiento debe especificar una

característica observable externa o experimentable por el usuario del

producto. [9]

● Verificable/demostrable: La implementación del requerimiento debe ser

resuelta en alguno de estos cuatro métodos: inspección, análisis,

demostración o prueba. [9]

Las validaciones mostradas son una herramienta de gran utilidad durante un

proyecto de esta índole, un buen planteamiento de requerimientos tiene una

estrecha relación con el índice de éxito de un proyecto.

Suponiendo que se concluye la fase del levantamiento de requerimientos con

éxito, en un enfoque tradicional lo siguiente sería continuar con el diseño como se

46

mencionó anteriormente, no obstante, al aplicar un enfoque mixto se puede optar

por corroborar lo discutido nuevamente con el cliente para descartar dudas y

resolver redundancias en caso de existir alguna. En el supuesto escenario en el

que la etapa anterior culmina con éxito, el programador inexperto podría pensar que

es momento de desempolvar el teclado y empezar a programar como nunca, pero

aun no es necesario.

La organización en el desarrollo de software lo es todo, una buena

organización ayuda a prevenir errores, que se traduce en optimizar tiempos y

obviamente nadie quiere perder tiempo, siendo así, al tener los requerimientos

terminados, es preciso continuar con la planeación de las tareas que van a

desempeñar, para ello existe una metodología llamada KANBAN, esta propone la

incorporación de un tablero para ser capaz de conocer exactamente en qué estado

se encuentra el proyecto, en que se está trabajando y quien se está encargando de

ello. Como se muestra en la imagen. Tablero KANBAN. [7].

Es ideal para tener una perspectiva simplificada del proyecto, KANBAN

propone que los miembros del equipo de desarrollo no deben asumir roles

establecidos, sin embargo, cada miembro tiene capacidades diferentes que pueden

explotarse en beneficio del proyecto, por otro lado, como podría saberse que un

integrante del equipo tiene un talento natural para cierta tarea, pero no lo sabe

porque nunca lo ha intentado, un dilema. Debido a ello, KANBAN tiene razón en no

asumir roles, porque estos podrían limitar el potencial de algún integrante, entonces

se propone que en un principio no existan roles al planificar las tareas, es decir que

no se asignen actividades de acuerdo a las aptitudes previas que se conocen de la

persona en cuestión. A pesar de ello esta práctica puede retrasar el proyecto, lo

ideal sería aplicar este ejercicio un periodo prudente de acuerdo a la duración del

proyecto, una vez identificadas las habilidades de los integrantes, es ahí cuando se

pueden asumir roles basados en el desempeño obtenido con el ejercicio.

Los resultados del ejercicio propuesto, antes de la implementación pueden

parecer desalentadores, en un proyecto de desarrollo de software es fundamental

que exista un Project Manager y cuando no se cuenta con uno, debería considerarse

47

la opción anterior para encontrar el rol de PM o cualquier otro que podría estar en

los integrantes del equipo.

Este rol al ser el más importante, al no estar presente en un equipo puede

resultar frustrante cuando se quiere avanzar o incluso resulta imposible avanzar a

un ritmo saludable.

48

Conclusiones

El desarrollador promedio piensa que el crear nuevo software es simplemente tener

la idea y proceder a programar sin mirar a los lados, pero detrás de esto existe una

infinidad de procedimientos que lo mantienen funcional. Y no quiere decir que

construir aplicaciones sea una tarea abrumante, sino que es necesario conocer todo

lo que conlleva este cometido, si se conoce lo suficiente de un tema cualquiera que

sea esto puede llevar a ideas que se traducen en nuevos aportes.

En el desarrollo de software los aportes serían las nuevas aplicaciones, pero

muchas veces hay apps que nunca llegan a los usuarios para los que fueron

pensadas por no tener una apropiada metodología de desarrollo que encaje al

proyecto. En ocasiones parece ridículo pero el informático promedio le gusta

complicarse la vida, es ávido fanático de las soluciones complicadas, la manera

simple de ver las cosas está infravalorada en este ámbito, las decisiones y

respuestas lógicas basadas en el sentido común a problemas lógicos resulta difícil

de concebir.

La relación del párrafo anterior con las metodologías es que, si se requiere

juntar técnicas de enfoques diferentes con el fin de producir software, simplemente

se deben juntar y trabajar con ellas, si no se ven resultados positivos o los

esperados, intercalar entre las técnicas hasta encontrar la efectividad buscada.

Ya se mencionó en una ocasión, lo que para un equipo de desarrollo funciona

a la perfección, no lo hace funcional para todos.

49

Bibliografías

[1] UPSIN, «UPSIN,» UPSIN, 12 11 2015. [En línea]. Available:

http://www.upsin.edu.mx/identidad_institucional. [Último acceso: 12 12 2019].

[2] ACM, Computing Degrees & Careers, ACM, 1997.

[3] activecollab, «activecollab,» activecollab, 08 11 15. [En línea]. Available: https://activecollab.com/blog/project-management/crystal-methods. [Último acceso: 12 12 2019].

[4] Wikipedia, «Wikipedia,» Wikipedia, 22 03 2014. [En línea]. Available: https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational#/media/Archivo:Rup_espanol.gif. [Último acceso: 12 12 2019].

[5] justindeveloper, «justindeveloper,» justindeveloper, 28 01 2016. [En línea]. Available: https://justindeveloper.files.wordpress.com/2010/09/msf25b225d.gif. [Último acceso: 12 12 2019].

[6] ecured, «ecured,» ecured, 15 11 2015. [En línea]. Available: https://www.ecured.cu/images/c/c3/Iconix.jp. [Último acceso: 12 12 2019].

[7] KANBAN, «KANBAN,» KANBAN, 18 04 2017. [En línea]. Available: https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcRxcS_15jG9uWDiUsMBtfoZxRSHEvpPg9wiEYYNHgIJ_AVC7kyp. [Último acceso: 12 12 2019].

[8] roa, «roa,» roa, 26 02 2019. [En línea]. Available: http://roa.ult.edu.cu/bitstream/123456789/477/1/masyxp.pdf. [Último acceso: 12 12 2019].

[9] medium, «medium,» medium, 19 09 2017. [En línea]. Available: https://medium.com/agility-path/5 -programming-isnt-popular-83790418b901. [Último acceso: 12 12 2019].

[10] J. C. RUEDA CHACÓN, «http://biblioteca.usac.edu.gt,» USAC, [En línea]. Available: http://biblioteca.usac.edu.gt. [Último acceso: 27 11 2019].

[11] R. S. M. J. E. M. O. V. C. &. R. E. P. Pressman, Ingeniería del software: un enfoque práctico (7ª ed.)., CDMX: McGrawHill, 2006.

[12] U. T. d. Pereira, «Universidad Tecnológica de Pereira,» Universidad Tecnológica de Pereira, 2006 05 21. [En línea]. Available: https://revistas.utp.edu.co/index.php/revistaciencia. [Último acceso: 28 11 2019].

[13] J. Olivares, «dsc.itmorelia.edu.mx,» dsc.itmorelia.edu.mx, 12 08 2010. [En línea]. Available: http://dsc.itmorelia.edu.mx/~jcolivares/documents/msf.pdf. [Último acceso: 27 11 2019].

[14] P. Letelier, «roa.ult.edu.cu,» Universidad Politécnica de Valencia, 30 08 2010. [En línea]. Available: http://roa.ult.edu.cu/bitstream/123456789/477/1/masyxp.pdf. [Último acceso: 27 11 2019].

[15] investigacionit.com.ar, «investigacionit.com.ar,» investigacionit.com.ar, 16 03 2013. [En línea]. Available: http://investigacionit.com.ar/requisitos-o-requerimientos/. [Último acceso: 2019 11 28].

[16] &. I. S. B. Institute of Electrical and Electronics Engineers, IEEE Standard Glossary of Software Engineering Terminology., IEEE, 1990.

[17] CMS, «CMS,» GOB, 2007 02 24. [En línea]. Available: https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf. [Último acceso: 27 11 2019].

[18] L. Alegsa, «alegsa.com.ar,» alegsa.com.ar, 2016 06 29. [En línea]. Available: http://www.alegsa.com.ar/Dic/requerimientos.php. [Último acceso: 11 28 2019].

[19] Google, «Google Maps, » Google Maps, 11 07 2017. [En línea]. Available: https://www.google.com.mx/maps/preview. [Último acceso: 12 12 2019].