UNIVERSIDAD POLITÉCNICA DE SINALOA PROGRAMA...
Transcript of UNIVERSIDAD POLITÉCNICA DE SINALOA PROGRAMA...
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].