República Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación Universitaria
Universidad Centroccidental “Lisandro Alvarado”
Decanato de Ciencias y Tecnología
Investigación Desarrollo de Software
Daniel Alfredo Rodríguez Piña
V- 17017361
Profesor: Johán Rosendo
Sección: 1
Procesos de desarrollo de software
En este artículo queremos hablar de los procesos de desarrollo de programas informáticos. Debe
quedar claro que estas serán unas notas generales sobre los procesos de desarrollo que existen,
pero que no vamos a profundizar en ninguno, ya que para hacerlo necesitaríamos manuales o
libros enteros. Por tanto, lo puedes considerar como algo de cultura general que te vendrá bien
para tener una ligera idea de cómo se desarrollan aplicaciones grandes y complejas o pequeñas y
sencillas.
Qué es el proceso de desarrollo de software
El proceso de desarrollo de software es el método que usamos para crear aplicaciones
informáticas de cualquier tipo, que indica qué etapas tendrá que hacer el equipo de desarrollo,
qué disciplinas del desarrollo se realizarán en cada etapa y cómo se organizará el mantenimiento,
una vez se haya desarrollado el software.
A la vista de las aplicaciones existentes hoy en día... puedes pensar en juegos, procesadores de
texto, programas de diseño... entenderás que los procesos de desarrollo pueden ser algo amplio y
complejo, ya que incluye todo el flujo y actividades necesarias para crear el software, gestionar a
los equipos de desarrolladores y las numerosas disciplinas que deben realizarse. Claro que todas
las aplicaciones que se realizan no tienen la misma complejidad, pero lo cierto es que incluso en
proyectos pequeños o medianos es importante el beneficio que se puede obtener al aplicar un
proceso de desarrollo, ya que nos ayudará a aumentar sus posibilidades de éxito.
Existen diversos procesos de desarrollo que se usan en la actualidad y otros procesos de desarrollo
que se utilizaron en su época y que ya están un poco en desuso. Dentro de los procesos de
desarrollo actuales encontramos RUP y el Desarrollo Ágil, siendo éste último usado
mayoritariamente en la industria del software. Ambos procesos son iterativos y pensados para
aplicaciones de tamaño mediano o grande. Pero existen otros procesos como "La Cascada", más
usado hace décadas, pero que puede ser útil todavía en la actualidad para aplicaciones pequeñas.
Metodologías tradicionales
Las metodologías tradicionales, como su nombre nos indica, son las que se han usado toda la vida.
Buscan imponer disciplina al proceso de desarrollo de software y de esa forma volverlo predecible
y por ello eficiente.
De hecho, estas metodologías tienen un enfoque predictivo, donde se sigue un proceso secuencial
en una sola dirección y sin marcha atrás. La estimación/captura de requisitos se realiza una única
vez (exacto, una vez solo) al principio del proyecto y es precisamente por eso que nuestra
estimación tendrá mucha importancia ya que de ella dependen todos los recursos que
emplearemos en el proyecto. Si queremos adoptar una metodología tradicional, el desarrollo de
un proyecto debe empezar siempre con un riguroso proceso de captura de requisitos, análisis y
diseño. Recuerda: los requisitos son acordados de una vez y, para todo el proyecto, no se esperan
cambios en ellos.
Un consejo: adopta este tipo de metodología cuando ya tienes mucha experiencia con un
determinado tipo de producto y sabes estimarlo perfectamente. Además, es la opción ideal para
proyectos donde los requisitos no cambian y las condiciones del entorno son conocidas y estables.
¿Y qué pasa si tienes que desarrollar un proyecto/producto nuevo? ¿Estás 100% seguro de que
todo saldrá exactamente según la estimación y lo previsto?
Un consejo: en este caso, considera aplicar una metodología ágil.
Las metodologías ágiles surgen como alternativa a las tradicionales porque nos ayudan a reducir la
probabilidad de fracaso por sub-estimación de costos, tiempos y funcionalidades en entornos
cambiantes.
Metodologías ágiles
Los marcos de trabajo (frameworks) y metodologías ágiles se caracterizan por ser adaptativas y
flexibles, esto significa que no son reticentes a los cambios, al revés, los imprevistos son eventos
esperados que aprenderás a acoger con gran normalidad. Hoy en día, el marco de trabajo ágil más
utilizado y conocido es Scrum pero recuerda que existen también Kanban, Lean y otros.
Muy en resumen, podríamos decir que las características principales de la metodologías ágil son:
comunicación, cohesión, funcionalidad y conocimientos.
Comunicación:
Si queremos adoptar una metodología ágil, será importante, sino fundamental, que nuestro
cliente forme parte integrante del proyecto ya que, como hemos visto, cuando se trata de un
desarrollo totalmente nuevo es probable e incluso, normal, que los requisitos y las funcionalidades
puedan necesitar cambios y ajustes. Una curiosidad: cuando hablamos del cliente como
componente fundamental adentro del proyecto, recuerda que, según por ejemplo el framework
Scrum, «el cliente final» o, más bien, su prototipo, puede ser incluso un miembro del propio
equipo que, haciendo las veces del cliente, nos ayudará a gestionar y mejorar el proyecto desde
una perspectiva intencionadamente externa.
Cohesión:
Otro punto extremadamente importante. El secreto para aplicar bien la metodología ágil es contar
con un equipo muy cohesionado. Un consejo: es muy recomendable que el grupo sea pequeño
(máximo 10 personas) y, sobre todo, siempre motivado. Debe tratarse de un trabajo de equipo en
el que los miembros se complementen los unos a los otros.
Funcionalidad:
En proyectos ágiles, el trabajo se fragmenta en partes que se priorizan y se desarrollan durante un
periodo de tiempo corto (entre 1 y 4 semanas), denominados «sprints«. Una de las máximas en las
metodologías ágiles es la de anteponer el valor aportado al producto sobre otras tareas
(documentación extensa, burocracia en procesos, etc). El objetivo es obtener un producto
funcional lo antes posible. De este modo ya en las primeras instancias del proyecto tendremos un
producto con valor que se va mejorando con cada «sprint» y – un detalle que no debe
subestimarse – un cliente que «empieza a ver algo» de su producto desde muy pronto, será un
cliente más motivado y satisfecho.
Conocimientos:
Como podemos ver, sin duda las metodologías ágiles pueden optimizar muchísimo la gestión de
un proyecto pero recuerda que no pueden prescindir de un determinado contexto ni de valores y
conocimientos para funcionar correctamente. Si deseas emplear una metodología ágil, primero
tendrás que interiorizar sus valores y seguir siempre sus reglas de buen uso. Una última
recomendación: que la documentación y el «papeleo» no sean una prioridad de la metodología
ágil, no significa en absoluto que se deje de lado. En cambio, necesitarás sí una documentación
corta y concisa que sea sin muchas florituras pero perfectamente exhaustiva
Scrum
La metodología Scrum permite abordar proyectos bastante complejos que están desarrollados en
entonos cambiantes de una manera fácil y flexible.
Se trata de una metodología que ayuda a los equipos a aprender y organizarse en base a las
experiencias a la vez que aborda problemas e invita a reflexionar sobre los éxitos y fracasos. Todo
ello bajo una serie de herramientas y recursos que permite a los equipos organizarse con mayor
agilidad.
Características.
Equipos autónomos: los equipos Scrum están pensados para operar sobre la marcha, con un
orden y dinámica únicos que carecen de jerarquía. Estos equipos se consideran autoorganizados,
exhiben autonomía, crecimiento continuo y colaboración.
Fases de desarrollo solapadas: las personas de un equipo Scrum deben trabajar para sincronizar
sus ritmos para cumplir con los plazos de entrega. En algún momento del desarrollo, el ritmo de
cada individuo comienza a solaparse y sincronizarse con el de los demás y, finalmente, se forma un
ritmo colectivo dentro del equipo.
Aprendizaje múltiple: Scrum es un marco que se basa en gran medida en prueba y error. Los
miembros del equipo Scrum también tienen como objetivo mantenerse al día con las condiciones
cambiantes del mercado. Es por eso que el aprendizaje es fluído y rota entre los diferentes
miembros de la organización.
Seguimiento sin control: como mencionamos, los equipos Scrum se autoorganizan y operan como
una pequeña startup, pero eso no significa que no exista ninguna estructura. Al crear puntos de
control a lo largo del proyecto para analizar las interacciones y el progreso del equipo, los equipos
Scrum mantienen el control sin obstaculizar la creatividad.
Etapas de Scrum
1.Planificación
Es la fase en la que se establecen las tareas prioritarias y donde se obtiene información breve y
detallada sobre el proyecto que se va a desarrollar.
Con el método Scrum no es necesario definir todos los objetivos al comienzo del proyecto. El
Product Owner, de forma conjunta con el equipo de trabajo comienzan a listar lo más importante
para el Product Backlog.
2.Ejecución o Sprint
Podemos definir el Sprint como un mini proyecto en donde el equipo de trabajo se focaliza en el
desarrollo de tareas para alcanzar el objetivo que se ha definido previamente en el Sprint
planning.
3.Control
Es la fase en la que se mide el progreso de un determinado proyecto Scrum. En ella, el Scrum
Master será el encargado de actualizar los gráficos cuando se finalice cada uno de los Sprint.
A modo de resumen, la metodología Scrum se centra principalmente en el trabajo en equipo,
siguiendo una serie de criterios establecidos para obtener los mejores resultados en un proyecto.
Kanban
Actualmente, el término Kanban ha pasado a formar parte de las llamadas metodologías ágiles,
cuyo objetivo es gestionar de manera general cómo se van completando las tareas. Kanban es una
palabra japonesa que significa “tarjetas visuales”, donde Kan es “visual”, y Ban corresponde a
“tarjeta”.
Las principales ventajas de esta metodología es que es muy fácil de utilizar, actualizar y asumir por
parte del equipo. Además, destaca por ser una técnica de gestión de las tareas muy visual, que
permite ver a golpe de vista el estado de los proyectos, así como también pautar el desarrollo del
trabajo de manera efectiva.
Los principios de la metodología Kanban
La metodología Kanban se basa en una serie de principios que la diferencian del resto de
metodologías conocidas como ágiles:
Calidad garantizada. Todo lo que se hace debe salir bien a la primera, no hay margen de error. De
aquí a que en Kanban no se premie la rapidez, sino la calidad final de las tareas realizadas. Esto se
basa en el hecho que muchas veces cuesta más arreglarlo después que hacerlo bien a la primera.
Reducción del desperdicio. Kanban se basa en hacer solamente lo justo y necesario, pero hacerlo
bien. Esto supone la reducción de todo aquello que es superficial o secundario (principio YAGNI).
Mejora continua. Kanban no es simplemente un método de gestión, sino también un sistema de
mejora en el desarrollo de proyectos, según los objetivos a alcanzar.
Flexibilidad. Lo siguiente a realizar se decide del backlog (o tareas pendientes acumuladas),
pudiéndose priorizar aquellas tareas entrantes según las necesidades del momento (capacidad de
dar respuesta a tareas imprevistas).
Pasos para configurar tu estrategia de Kanban
La aplicación del método Kanban implica la generación de un tablero de tareas que permitirá
mejorar el flujo de trabajo y alcanzar un ritmo sostenible. Para implantar esta metodología,
deberemos tener claro los siguientes aspectos:
1# DEFINIR EL FLUJO DE TRABAJO DE LOS PROYECTOS
Para ello, simplemente deberemos crear nuestro propio tablero, que deberá ser visible y accesible
por parte de todos los miembros del equipo. Cada una de las columnas corresponderá a un estado
concreto del flujo de tareas, que nos servirá para saber en qué situación se encuentra cada
proyecto. El tablero debe tener tantas columnas como estados por los que pasa una tarea, desde
que se inicia hasta que finaliza (p.e: diagnóstico, definición, programación, ejecución, testing, etc.).
A diferencia de SCRUM, una de las peculiaridades del tablero es que este es continuo. Esto
significa que no se compone de tarjetas que se van desplazando hasta que la actividad queda
realizada por completo. En este caso, a medida que se avanza, las nuevas tareas (mejoras,
incidencias o nuevas funcionalidades) se acumulan en la sección inicial, de manera que en las
reuniones periódicas con el cliente se priorizan y se colocan dentro de la sección que se estima
oportuna.
Dicho tablero puede ser específico para un proyecto en concreto o bien genérico. No hay unas
fases del ciclo de producción establecidas, sino que se definirán según el caso en cuestión, o se
establecerá un modelo aplicable genéricamente para cualquier proyecto de la organización.
2# VISUALIZAR LAS FASES DEL CICLO DE PRODUCCIÓN
Al igual que Scrum, Kanban se basa en el principio de desarrollo incremental, dividiendo el trabajo
en distintas partes. Esto significa que no hablamos de la tarea en sí, sino que lo dividimos en
distintos pasos para agilizar el proceso de producción.
Normalmente cada una de esas partes se escribe en un post-it y se pega en el tablero, en la fase
que corresponda. Dichos post-its contienen la información básica para que el equipo sepa
rápidamente la carga total de trabajo que supone: normalmente descripción de la tarea con la
estimación de horas. Además, se pueden emplear fotos para asignar responsables así como
también usar tarjetas con distintas formas para poner observaciones o indicar bloqueos (cuando
una tarea no puede hacerse porqué depende de otra).
Al final, el objetivo de la visualización es clarificar al máximo el trabajo a realizar, las tareas
asignadas a cada equipo de trabajo (o departamento), así como también las prioridades y la meta
asignada.
3# STOP STARTING, START FINISHING
Este es el lema principal de la metodología Kanban. De esta manera, se prioriza el trabajo que está
en curso en vez de empezar nuevas tareas. Precisamente, una de las principales aportaciones del
Kanban es que el trabajo en curso debe estar limitado y, por tanto, existe un número máximo de
tareas a realizar en cada fase.
En realidad, se trata de definir el máximo número de tareas que podemos tener en cada una de las
fases (p.e: 3 tareas en la fase de planificación; 2, en la fase de desarrollo; una, en la fase de
pruebas, etc.) y, por tanto, restringir el trabajo en curso. A esto, se le añade otra idea que, por muy
obvia que pueda parecer, la práctica nos demuestra que no es así: no se puede abrir una nueva
tarea sin finalizar otra.
De esta manera, se pretende dar respuesta al problema habitual de muchas empresas de tener
muchas tareas abiertas pero con un ratio de finalización muy bajo. Aquí lo importante es que las
tareas que se abran se cierren antes de empezar con la siguiente.
4# CONTROL DEL FLUJO
A diferencia de SCRUM, la metodología Kanban no se aplica a un único proyecto, sino que mezcla
tareas y proyectos. Se trata de mantener a los trabajadores con un flujo de trabajo constante, las
tareas más importantes en cola para ser desarrolladas y un seguimiento pasivo para no tener que
interrumpir al trabajador en cada momento.
Programación extrema
La programación extrema o eXtreme Programming (en adelante, XP) es una metodología de
desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la
materia, Extreme Programming Explained: Embrace Change (1999).
Al igual que estos, la programación extrema se diferencia de las metodologías tradicionales
principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los
defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de
adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una
aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del
proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.
Se puede considerar la programación extrema como la adopción de las mejores metodologías de
desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera
dinámica durante el ciclo de vida del software.
Valores
Los valores originales de la programación extrema son: simplicidad, comunicación,
retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición
de Extreme Programming Explained. Los cinco valores se detallan a continuación:
Simplicidad
La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el
desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas
modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente
exponencialmente.
Para mantener la simplicidad es necesaria la refactorización del código, esta es la manera de
mantener el código simple a medida que crece.
También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse
en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben
elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no
decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de
autocompletado y refactorización que existen actualmente.
Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se
asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el
sistema completo.
Comunicación
La comunicación se realiza de diferentes formas. Para los programadores el código comunica
mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo legible. El
código autodocumentado es más fiable que los comentarios ya que estos últimos pronto quedan
desfasados con el código a medida que es modificado. Debe comentarse solo aquello que no va a
variar, por ejemplo el objetivo de una clase o la funcionalidad de un método.
Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y
los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores
se comunican constantemente gracias a la programación por parejas. La comunicación con el
cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide qué
características tienen prioridad y siempre debe estar disponible para solucionar dudas.
Retroalimentación (feedback)
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en
tiempo real.
Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que
rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo
que es más importante.
Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden
tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del
equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las
herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud
del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a
cambios recientes en el código.
Coraje o valentía
Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y
no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado
tiempo y trabajo para implementar el resto del proyecto. La valentía le permite a los
desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto
significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementarán
más fácilmente. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar
código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código.
Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un
problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, solo si es
persistente.
Respeto
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros,
porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen
o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre
están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para
la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo
del resto no haciendo menos a otros, una mejor autoestima en el equipo eleva su ritmo de
producción.
Características fundamentales
Las características fundamentales del método son:
Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de
regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo,
las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la
plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se
inspiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de
programación Smalltalk.
Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos
personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es
revisado y discutido mientras se escribe- es más importante que la posible pérdida de
productividad inmediata.
Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un
representante del cliente trabaje junto al equipo de desarrollo.
Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su
legibilidad y mantenibilidad, pero sin modificar su comportamiento. Las pruebas han de garantizar
que en la refactorización no se ha introducido ningún fallo.
Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada
módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda
corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan
que los posibles errores serán detectados.
Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se
podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo
hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo
complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más
comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple
es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más
completa, especialmente si se puede reducir el equipo de programadores.
