MODELOS DE PROCESOS DE SOFTWARE
DEFINICIÓN DE MODELOS DE PROCESOS DE SOFTWARE[1]
Para poder entender con
mayor facilidad, desglosamos el tema en partes importantes. El Proceso es un
conjunto de actividades, acciones y tareas que se ejecutan cuando va a crearse
algún producto del trabajo. Por otro lado, la Ingeniería de Software es una rama
de la computación, que estudia la creación de Software confiable y de calidad,
con el cual podremos desarrollar las actividades del mismo. Las acciones son un
conjunto de tareas que producen un producto importante. Y por último, las
tareas se centran en objetivos pequeños, pero bien definidos que producen
resultados notables.
Por lo que un proceso
de Software es un enfoque adaptable que permite que las personas que hacen el
trabajo (el equipo de software) busquen y elijan el conjunto apropiado de acciones
y tareas para el trabajo. En consecuencia, es la encargada de controlar la
administración de proyectos de Software, y establece el contexto en el que se
aplican métodos técnicos, se generan productos del trabajo (modelos,
documentos, datos, reportes, formatos, etc.), se establecen puntos de
referencia, se asegura la calidad y se administra el cambio de manera
apropiada.
Por lo tanto cada modelo de proceso de Software tiene una estructura de actividades, acciones y tareas que define su relación tanto con el proceso como entre sí y esto con el fin de entregar un software en forma oportuna y con calidad suficiente para satisfacer a quienes patrocinaron su creación y a aquellos que lo usarán.
1.
DESCRIBIR AL MENOS 3
MODELOS DEL TIPO SECUENCIAL
1.1.
Modelo Lineal Secuencial[2]
Llamado también “ciclo de vida básico” o “modelo en cascada” sugiere un enfoque sistemático, Secuencial, para el desarrollo de software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.
Características
● Está compuesto por una
serie de fases que se ejecutan secuencialmente.
● Obtención de documentos
como criterio de finalización de fase
● Problemas de progresión
secuencial
● Desconocimiento de las
necesidades por parte del cliente
● Inestabilidad de los requisitos.
Nos de ven resultados hasta muy avanzado el proyecto. Efecto bing bang próximo
a la entrega.
1.2.
Modelo Iterativo Basado
En Prototipos[3]
Es un modelo
experimental de un sistema o de un componente de un sistema que tiene los
suficientes elementos que permiten su uso.
Objetivos
● Son un medio eficaz
para aclarar los requisitos de los usuarios e identificar las características
de un sistema que deben cambiarse o añadirse.
● Mediante el prototipo
de se puede verificar la viabilidad del diseño de un sistema.
Características
● Es una aplicación que
funciona.
● Su finalidad es probar
varia suposiciones con respecto a las características requeridas por el
sistema.
● Se crean con rapidez.
● Evolucionan a través de
un proceso iterativo.
● Tiene un costo bajo de
desarrollo.
1.3.
Modelo de Desarrollo
Rápido de Aplicaciones (DRA)[4]
Es un proceso
desarrollado por James Martin en 1980, el cual enfatiza un ciclo de desarrollo
extremadamente corto. Es una adaptación a “Alta velocidad” en el que se logra
el desarrollo rápido utilizando un enfoque de construcción basado en
componentes. Si se comprenden bien los requisitos y se limita el ámbito del
proyecto, el proceso permite al equipo de desarrollo crear un “sistema
completamente funcional” dentro de períodos cortos de tiempo. Cuando se utiliza
principalmente para aplicaciones de sistemas de información, comprende las
siguientes fases:
● Modelado de gestión: El flujo de información entre las funciones
de gestión se modela de forma que responda a las siguientes preguntas:
○ ¿Qué información
conduce el proceso de gestión?
○ ¿Qué información se genera?
○ ¿Quién la genera?
○ ¿A dónde va la
información?
○ ¿Quién la proceso?
● Modelado de datos
Es una manera de
estructurar y organizar los datos para que se puedan utilizar fácilmente por
las bases de datos. Se definen los atributos de cada uno de los objetos y las
relaciones entre estos objetos.
● Modelado de proceso
Es la comunicación
entre los objetos, los datos estructurados en la fase anterior quedan
transformados para lograr el flujo de información necesario para implementar
una función de gestión. Se describen y crean los procesos para añadir,
modificar, suprimir, o recuperar un objeto de datos.
● Generación de aplicaciones
En lugar de crear
software con lenguajes de programación de tercera generación, el proceso DRA
trabaja para volver a utilizar componentes de programas ya existentes, si es
posible o a crear componentes reutilizables. En todos los casos se utilizan
herramientas automáticas para facilitar la construcción del software.
● Pruebas de entrega
Debido a la
reutilización, ya se han comprobado muchos de los componentes de los programas.
Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los
componentes nuevos y se deben ejercitar todas las interfaces a fondo.
Algunos inconvenientes
Para proyectos grandes
requiere recursos humanos suficientes como para crear el número correcto de
equipos DRA.
DRA requiere clientes y
desarrolladores comprometidos en las rápidas actividades necesarias para
completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por
ninguna de las partes constituyentes, los proyectos DRA fracasarán.
No todos los tipos de
aplicaciones son apropiados para DRA. Si un sistema no se puede modelar
adecuadamente, la construcción de los componentes será problemático. Si está en
juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo
interfaces en componentes de sistema, el enfoque DRA puede que no funcione. DRA
no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una
nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software
requiere un alto grado de interoperabilidad con programas de computadora ya
existentes.
DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje.
Ventajas
● Comprar puede ahorrar
dinero en comparación con construir.
● Los entregables pueden
ser fácilmente trasladados a otra plataforma.
● El desarrollo se
realiza a un nivel de abstracción mayor.
● Visibilidad temprana.
● Mayor flexibilidad.
● Menor codificación
manual.
● Mayor involucramiento
de los usuarios.
● Posiblemente menos
fallas.
● Posiblemente menor
costo.
● Ciclos de desarrollo
más pequeños.
● Interfaz gráfica
estándar.
Desventajas
● Comprar puede ser más
caro que construir.
● Costo de herramientas
integradas y equipo necesario.
● Progreso más difícil de
medir.
● Menos eficiente.
● Menor precisión
científica.
● Riesgo de revertirse a
las prácticas sin control de antaño.
● Más fallas (por
síndrome de “codificar a lo bestia”).
● Prototipos pueden no
escalar, un problema mayúsculo.
● Funciones reducidas
(por “timeboxing”).
● Dependencia en
componentes de terceros: funcionalidad de más o de menos, problemas legales.
2.
DESCRIBIR AL MENOS 3
MODELOS DEL TIPO EVOLUTIVO
2.1.
Modelo evolutivo
“incremental”[5]
Tiene como objetivo un crecimiento progresivo de la
funcionalidad. Es decir, el producto va evolucionando con cada una de las
entregas previstas hasta que se amolda a lo requerido por el cliente o
destinatario, el producto debe mostrar una evolución con respecto a la fecha
anterior ya que nunca puede ser igual. A
diferencia de otros modelos es que este divide las tareas en iteraciones para
así conseguir objetivos específicos, el modelo incremental exige un encadenamiento
progresivo de cada tarea.
Este no es modelo rígido así que va adaptándose a las
características del tipo de proyecto, por lo tanto tiene 7 fases para tomar en
cuenta:
●
los requerimientos: que son
los objetivos del proyecto.
●
Definición de las tareas y
las iteraciones: sabiendo lo que se busca, el siguiente paso es hacer una lista
de tareas y agruparlas en las iteraciones que tendrá el proyecto.
● Diseño de los incrementos: cada iteración debe superar a la que le ha precedido. Esto es lo que se denomina incremento.
● Desarrollo del incremento se realizan las tareas previstas establecidos en la etapa anterior
●
Validación de incrementos:
al término de cada iteración, los responsables de gestión del proyecto deben
aprobar el incremento.
●
Integración de incrementos:
una vez son validados, los incrementos dan forma a lo que se denomina línea
incremental o evolución del proyecto en su conjunto.
● Entrega del producto: cuando el producto final ha sido validado se procede a su entrega.
2.2.
Modelo Evolutivo Espiral[6]
En el modelo espiral, el software se desarrolla en una
serie de versiones incrementales. Durante las primeras iteraciones la versión
incremental podría ser un modelo en papel o un prototipo, durante las últimas
iteraciones se producen versiones cada vez más completas del sistema diseñado.
EL modelo en espiral se divide en un número de actividades
de marco de trabajo, también llamadas REGIONES DE TAREAS, Cada una de las
regiones están compuestas por un conjunto de tareas del trabajo llamado
CONJUNTO DE TAREAS que se adaptan a las características del proyecto que va a
emprenderse en todos los casos se aplican actividades de protección.
Ventajas
El análisis del riesgo se hace de forma explícita y clara.
Une los mejores elementos de los restantes modelos.
●
Reduce riesgos del
proyecto.
●
Incorpora objetivos de
calidad.
●
Integra el desarrollo con
el mantenimiento, etc.
●
Además es posible tener en
cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que
este ciclo de vida no es rígido ni estático.
Desventajas
●
Genera mucho tiempo en el
desarrollo del sistema
●
Modelo costoso
●
Requiere experiencia en la
identificación de riesgos.
Se desarrolla un software completo desde el inicio y de
acuerdo a cada versión nueva que se desarrolla se aumentan subsistemas que
cambian las funcionalidades, estos cambios se realizan en cada iteración.
Cada iteración tiene un mini modelo de cascada, y los
objetivos de cada iteración se establecen de acuerdo a lo realizado en una
iteración anterior.
La manera de evaluar las iteraciones es estableciendo al
menos dos etapas: la revisión inicial que se realiza al principio de la
iteración y fija los objetivos a realizarse en esta iteración, y la revisión de
evaluación que confirma si se ha conseguido los resultados deseados.
Este modelo se usa cuando no se tiene seguridad de lo que
se quiere desarrollar, debido a que en cada iteración y en cada evaluación se
determina si hay que aumentar algo mas o si el proyecto está acabado.
3.
DESCRIBIR AL MENOS 3
MODELOS DEL TIPO ÁGIL
3.1.
Modelos De Tipo Ágil
La
metodología ágil se basa en un desarrollo incremental e iterativo (es decir, el
proceso de planificación es evolutivo y se va detallando a medida que avanza el
proyecto). Fue diseñada para dotar de más autonomía a los miembros del equipo
de trabajo frente a las limitaciones que presentan los métodos tradicionales en
este sentido. En un proyecto ágil, el equipo está facultado para tomar
decisiones, mientras que en los proyectos tradicionales se ejerce un mayor
control de arriba hacia abajo.
3.1.1.
Modelo Crystal clear
Historia
Las metodologías
Crystal fueron creadas por el “antropólogo de proyectos” Alistair Cockburn, el
autor que ha escrito los que tal vez sean los textos más utilizados,
influyentes y recomendables sobre casos de uso, Writing effective Use Cases
[Coc01] [Lar03].
La familia Crystal
dispone un código de color para marcar la complejidad de una metodología:
cuanto más oscuro un color, más “pesado” es el método. Cuanto más crítico es un
sistema, más rigor se requiere. El código cromático se aplica a una forma
tabular elaborada por Cockburn que se usa en muchos más para situar el rango de
complejidad al cual se aplica una metodología. En la figura se muestra una
evaluación de las pérdidas que puede ocasionar la falla de un sistema y el
método requerido según este criterio. Los parámetros son Comodidad (C), Dinero
Discrecional (D), Dinero Esencial (E) y Vidas (L). En otras palabras, la caída
de un sistema que ocasiona incomodidades indica que su nivel de criticalidad es
C, mientras que si causa pérdidas de vidas su nivel es L. Los números del
cuadro indican el número de personas afectadas a un proyecto, ±20%. Los métodos
se llaman Crystal evocando las facetas de una gema: cada faceta es otra versión
del proceso, y todas se sitúan en torno a un núcleo idéntico. Hay cuatro
variantes de metodologías: Crystal Clear (“Claro como el cristal”) para equipos
de 8 o menos integrantes; Amarillo, para 8 a 20; Naranja, para 20 a 50; Rojo,
para 50 a 100. Se promete seguir con Marrón, Azul y Violeta. La más
exhaustivamente documentada es Crystal Clear (CC), y es la que se ha de
describir a continuación. CC puede ser usado en proyectos pequeños de categoría
D6, aunque con alguna extensión se aplica también a niveles E8 a D10. El otro
método elaborado en profundidad es el Naranja, apto para proyectos de duración
estimada en 2 años, descripto en Surviving Object-Oriented Projects [Coc97b].
Los otros dos aún se están desarrollando. Como casi todos los otros métodos, CC
consiste en valores, técnicas y procesos.
¿Qué es Crystal Clear?
Es una metodología de
desarrollo de Software ágil, que en realidad está considerada como una «familia
de metodologías» debido a que se subdivide en varios tipos de metodologías en
función a la cantidad de personas que vayan a conformar el proyecto. Crystal
Clear es una familia de metodologías con un “código genético” común.
El nombre Crystal
deriva de la caracterización de los proyectos según 2 dimensiones, tamaño y
complejidad. Por ejemplo:
● Clear es para equipos
de hasta 8 personas o menos.
● Amarillo para equipos
entre 9 a 20 personas.
● Naranja para equipos
entre 21 a 50 personas.
● Roja para equipos entre 51 a 100 personas.
● Azul para proyectos
especiales.
Crystal Clear puede ser
usado en proyectos pequeños y como casi todos los otros métodos, Crystal Clear
consiste en valores, técnicas y procesos.
Actividades
Se define un proceso de
software como un conjunto de actividades y resultados asociados que producen un
producto de software. Estas actividades son llevadas a cabo por los ingenieros
de software. Se definen como cuatro actividades fundamentales que son comunes
para todos los procesos de software:
● Especificación de
software: donde los clientes e ingenieros definen el software a producir y las
restricciones sobre su operación.
● Desarrollo de software:
donde el software se diseña y programa.
● Validación del
software: donde el software se valida para asegurar que es lo que el cliente
requiere.
● Evolución del software:
donde el software se modifica para adaptarlo a los cambios requeridos por el
cliente y el mercado.
Fases
● Puesta en escena.
Consiste en la planificación del siguiente incremento, el equipo selecciona los
requerimientos que serán implementados en el incremento y planifican lo que
harán.
● Revisiones. Cada
incremento tiene varias iteraciones y cada iteración incluye las actividades de
construcción, demostración y resumen de objetivos del incremento.
● Monitoreo. Los
progresos son monitoreados a partir de las diferentes entregas. El proceso se
mide con los hitos clave y la estabilidad de las fases.
● Paralelismo y flujo.
Cuando el monitoreo nos brinda un estado suficientemente estable es hora de
pasar a la próxima etapa.
● Estrategia de
diversidad holística. Se utiliza para dividir grandes equipos funcionales en
equipos multifuncionales.
● Técnica de puesta a
punto de la metodología. Se basa en entrevistas y talleres para elaborar una
metodología específica para el proyecto. Sirve para modificar o fijar el
proceso de desarrollo.
● Puntos de vista de
usuario. Dependiendo del color de la metodología Crystal que se elija se recomienda
la opinión de dos usuarios por cada versión del producto (CC); también tres
revisiones por parte del cliente en cada iteración (CO).
Roles
● Patrocinador: Produce la Declaración de Misión con
Prioridades de Compromiso (Tradeoff).
Consigue los recursos y define la totalidad del proyecto.
● Usuario Experto: Junto con el Experto en Negocios produce la
Lista de Actores / Objetivos y el archivo de casos de uso y requerimientos.
Debe familiarizarse con el uso del sistema, sugerir modos de operación,
información a visualizar simultáneamente, navegación, etc.
● Diseñador Principal: Produce la Descripción Arquitectónica.
Se supone que debe ser al menos un
profesional de Nivel 3. En Metodologías Ágiles se definen tres niveles de
experiencia:
Nivel 1 es capaz de
“seguir los procedimientos”.
Nivel 2 es capaz de
“apartarse de los procedimientos específicos” y encontrar otros distintos.
Nivel 3 es capaz de
manejar con fluidez, mezclar e inventar procedimientos.
● Programador: Produce, junto con el Diseñador Principal, los
Borradores de Pantallas, el Modelo Común de Dominio, las Notas y Diagramas de
Diseño, el Código Fuente, el Código de
Migración, las Pruebas y el Sistema Empaquetado. Un programa en CC es
“diseño y programa”; sus programadores son diseñadores/ programadores.
● Experto en Negocios: Junto con el Usuario Experto produce la
Lista de Actores / Objetivos y el archivo de casos de uso y
requerimientos.Debe conocer las reglas y políticas del negocio.
● Coordinador: Con la ayuda del equipo, produce el Mapa de
Proyecto, el Plan de Entrega, el Estado del proyecto, la lista de Riesgos, etc.
● Verificador: Produce el Reporte de Bugs. Puede ser un
programador en tiempo parcial, o un equipo
de varias personas.
● Escritor Produce el Manual de Usuario del sistema.
3.2.
Modelo Programación
Extrema (XP)[8]
Historia
Nace oficialmente en
aproximados de marzo de 1996 en un proyecto desarrollado por Kent Beck en
DaimlerChrysler, después de haber trabajado varios años con Ward Cunningham en
busca de una nueva aproximación al problema del desarrollo de software que
hiciera las cosas más simples de lo que nos tenían acostumbrados los métodos
existentes. Para muchos, XP no es más que sentido común. Kent definió cuatro
grandes tareas a realizar en el desarrollo de todo proyecto: planificación,
diseño, desarrollo y pruebas; teniendo siempre presente las cuatro
características básicas que debe reunir un programador XP: simplicidad en el
desarrollo, comunicación entre las partes implicadas, realimentación para poder
reutilizar y coraje.
La Programación Extrema
es una metodología de desarrollo de software que se basa en la simplicidad, la
comunicación y la retroalimentación o reutilización del código desarrollado
(reciclado de código). Cuenta con tan solo 6 años de vida, pero con un gran
respaldo por parte de grandes empresas cómo la Ford, DaimlerChrysler, First
Union National Bank -USA-, etc., que lo que buscan en definitiva es la
reducción de costes.
¿Qué es la programación extrema XP?
La Programación Extrema
XP, mejor conocida por su nombre en inglés Extreme Programming (PX), es una de
las llamadas Metodologías Ágiles de desarrollo de software más exitosas de los
tiempos recientes, nace como nueva disciplina de desarrollo de software hace
aproximadamente unos seis años, y ha causado un gran revuelo entre el colectivo
de programadores del mundo. Kent Beck, su autor, es un programador que ha
trabajado en múltiples empresas y que actualmente lo hace como Programador en
la conocida empresa automovilística DaimlerChrysler.
Con sus teorías ha
conseguido el respaldo de gran parte de la industria del software y el rechazo
de otra parte. La programación extrema se basa en la simplicidad, la
comunicación y el reciclado continuo de código, para algunos no es más que
aplicar una pura lógica.
Objetivos
● Establecer las mejores
prácticas de Ingeniería de Software en los desarrollos de proyectos.
● Mejorar la
productividad de los proyectos.
● Garantizar la Calidad
del Software desarrollando, haciendo que este supere las expectativas del
cliente.
Características
● 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 y NUnit para la
plataforma.NET. Estas dos últimas inspiradas en JUnit.
● Programación en
parejas: Se recomienda que las
tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se
supone que 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
compartido: 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: La programación extrema apuesta que es
más sencillo hacer algo si funcionan. Cuando todo funcione se podrá añadir
funcionalidad si es 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 éste, lo que lleva a una
comunicación más completa, especialmente si se puede reducir el equipo de
programadores.
Funcionamiento
Ahora que tenemos
nuestros cuatro valores estamos preparados para construir una Disciplina de
un buen funcionamiento de Desarrollo de software.
● Codificar: Es la única actividad de la
que no podremos prescindir. Sin código fuente no hay programa, aunque hay gente
que cuenta que existe software en producción del que se perdió el código
fuente. Por tanto necesitamos codificar y plasmar nuestras ideas a través del
código. En una programación en PX en pareja el código expresa tu interpretación
del problema, así podemos utilizarlo para comunicar, para hacer mías tus ideas,
y por tanto para aprender y mejorar.
●
Hacer
pruebas: Las características del software que no pueden ser demostradas
mediante pruebas simplemente no existen. Las pruebas me dan la oportunidad de
saber si lo que implementé es lo que en realidad yo pensaba que había
implementado. Las pruebas nos indican que nuestro trabajo funciona, cuando no
podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro
sistema entonces has acabado por completo.
No
debemos de escribir tan solo una prueba para ver qué funciona y salir
corriendo, debemos de pensar en todas las posibles pruebas para nuestro código,
con el tiempo llegarás a conclusiones sobre las pruebas y podrás pensar que si
dos de tus pruebas ya funcionan la tercera prueba no será necesaria escribirla,
sin caer en demasiada confianza. Programar y probar es más rápido que sólo
programar. Puedes ganar media hora de productividad sin hacer pruebas, pero
perderás mucho tiempo en la Depuración.
Tendrás
menos errores, tendrás que volver menos veces sobre el código, te costará menos
localizar los errores, perderás menos tiempo escuchado como tus clientes te
dicen que no funciona. Las pruebas deben ser sensatas y valientes. No podemos
hacer pruebillas que no testen a fondo el sistema, esos agujeros que vamos
dejando nos esperan para cuando pasemos de nuevo por allí y volveremos a caer
dentro.
● Planeación: Durante la planeación, se llevan a cabo la actividad de “escuchar”
las historias del cliente, las cuales son una especie de casos de uso
redactados que muestran que es lo que el cliente desea que el programa lleve a
cabo, además, el cliente le da una prioridad a cada una de esas historias, al
escuchar, se le asignan las semanas de desarrollo, y si el valor es muy grande,
se le pide al cliente que los divida en historias más pequeñas. A medida que avanza el proyecto, el cliente
puede agregar, cambiar el valor, descomponer o eliminar una historia, por lo
que el equipo de desarrollo cambia sus planes en consecuencia.
● Diseñar: El
Diseño
crea una estructura que organiza la lógica del sistema, un buen diseño permite
que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser
sencillos, si alguna parte del sistema es de desarrollo complejo, dividirla en
varias. Si hay fallos en el diseño o malos diseños, estos deben de ser
corregidos cuanto antes.
Tenemos que codificar porque sin código no hay
programas, tenemos que hacer pruebas porque sin pruebas no sabemos si hemos
acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos
que codificar ni probar, y tenemos que diseñar para poder Codificar, probar y
escuchar indefinidamente.
Figuras y roles
Los equipos de un proyecto de esta tipología y
magnitud tienen normalmente las siguientes figuras y roles:
● Clientes: Establecen las prioridades y marca el
proyecto. Suelen ser los usuarios finales del producto y quiénes marcan las
necesidades.
● Programadores: Serán los que se encargarán de desarrollar el
Extreme Programming.
● Testers: se encargan de ayudar al cliente sobre los
requisitos del producto.
● Coach: Asesoran al resto de componentes del equipo y marcan el
rumbo del proyecto.
● Manager: Ofrece recursos, es el responsable de la
comunicación externa y quien coordina las actividades.
3.3.
Modelo Scrum
La metodología Scrum es
un marco de trabajo o framework que se utiliza dentro de equipos que manejan
proyectos complejos. Es decir, se trata de una metodología de trabajo ágil que
tiene como finalidad la entrega de valor en períodos cortos de tiempo y para
ello se basa en tres pilares: la transparencia, inspección y adaptación. Esto
permite al cliente, junto con su equipo comercial, insertar el producto en el
mercado pronto, rápido y empezar a obtener ventas.
Historia
Este modelo fue
identificado y definido por Ikujiro Nonaka y Takeuchi a principios de los 80,
al analizar cómo desarrollaban los nuevos productos las principales empresas de
manufactura tecnológica: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M y
Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game,
1986). En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en
equipo, con el avance en formación de melé (scrum en inglés) de los jugadores
de Rugby, a raíz de lo cual quedó acuñado el término “scrum” para referirse a
ella. Aunque esta forma de trabajo
surgió en empresas de productos tecnológicos, es apropiada para cualquier tipo
de proyecto con requisitos inestables y para los que requieren rapidez y
flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas
de software.
En 1995, Ken Schwaber
presentó “Scrum Development Process” en OOPSLA 95 (Object-Oriented Programming
Systems & Applications conference)(SCRUM Development Process), un marco de
reglas para desarrollo de software, basado en los principios de Scrum, y que él
había empleado en el desarrollo de Delphi, y Jeff Sutherland en su empresa
Easel Corporation (compañía que en los macrojuegos de compras y fusiones, se
integraría en VMARK, y luego en Informix y finalmente en Ascential Software
Corporation)
Actividades
● Planificación de la
iteración (Sprint Planning)·
● Ejecución de la
iteración (Sprint
● Reunión diaria de
sincronización del equipo (Scrum Daily Meeting
● Demostración de los
requisitos completados (Sprint Review)
● Retrospectiva (Sprint
Retrospective)
●
Refinamiento de la lista de requisitos
y cambios en el proyecto.
Fases
Scrum es un framework
que permite trabajar en una serie de interacciones en equipo. Las fases que
definen y en las que se divide un proceso de SCRUM son las siguientes:
I. El quién y el que:
identifica los roles de cada uno de los miembros del equipo y define su
responsabilidad en el proyecto.
II. El dónde y el
cuándo: que representan el Sprint.
III. El por qué y el
cómo: representan las herramientas que utilizan los miembros de Scrum.
Roles
I. Roles en scrum: quién y qué El equipo de Scrum
consiste en tres diferentes roles:
1. El Producto Owner/Dueño del producto: Es la “voz del cliente”
y el responsable de desarrollar, mantener y priorizar las tareas en el backlog.
2. El Scrum Master.- Es responsable de asegurarse que el trabajo
del equipo vaya bien siguiendo las bases de Scrum. Además, se encarga de
remover cualquier obstáculo que pueda encontrar el equipo de desarrollo.
3. Los Development Team
Members/Miembros del Equipo de desarrollo.- Son los encargados de escribir
y probar el código
II. El sprint: dónde y cuándo El Sprint es la unidad
básica de trabajo para un equipo Scrum. Esta es la característica principal que
marca la diferencia entre Scrum y otros modelos para el desarrollo ágil. Es una
simple iteración llevada a cabo por los miembros del equipo. Un equipo puede
completar varios sprints durante el desarrollo del proyecto. Un Sprint inicia con un equipo que se compromete a realizar el
trabajo y finaliza con la demostración de un entregable. El tiempo mínimo para
un Sprint es de una semana y el máximo es de 4 semanas. Dentro del desarrollo
de un Sprint se llevan a cabo ciertos eventos, estos reciben el nombre de Scrum
Events o Eventos Scrum. Estos son:
1. Planeación del Sprint/Sprint Planning Todos los involucrados
en el equipo se reúnen para planificar el Sprint. Durante este evento se decide
qué requerimientos o tareas se le asignará a cada uno de los elementos del
equipo. Cada integrante deberá asignar el tiempo que crea prudente para llevar
a cabo sus requerimientos. De esta manera se define el tiempo de duración del
Sprint.
2. Reunión de Equipo de Scrum/Scrum team meeting A estas reuniones se
les deberían dedicar máximo 15 minutos diarios, y deberían ser siempre en el
mismo horario y lugar. En ellas, cada miembro del equipo deberá responder tres
simples preguntas:
● ¿Qué hiciste ayer?
● ¿Qué tienes planeado
hacer hoy?
● ¿Qué obstáculos
encontraste en el camino?
Estas reuniones sirven
para que todos los miembros del equipo se apoyan entre ellos. Si alguno de
ellos tiene algún inconveniente que obligue a extender el encuentro, este debe
tratarse más a fondo en una reunión enfocada en buscar la mejor solución para ello.
iii. Refinamiento del Backlog/Backlog Refinement
El Product Owner revisa
cada uno de los elementos dentro del Product Backlog con el fin de esclarecer
cualquier duda que pueda surgir por parte del equipo de desarrolladores.
También sirve para volver a estimar el tiempo y esfuerzo dedicado a cada uno de
los requerimientos.
iv. Revisión del Sprint/Sprint Review Los miembros del equipo
y los clientes se reúnen para mostrar el trabajo de desarrollo de software que
se ha completado. Se hace una demostración de todos los requerimientos
finalizados dentro del Sprint. En este punto no es necesario que todos los
miembros del equipo hablen, pueden simplemente estar presentes, pero la
presentación está a cargo del Scrum Master y el Product Owner.
v. Retrospectiva del Sprint/Retrospective
En este evento el
Product Owner se reúne con todo su equipo de trabajo y su Scrum Master para
hablar sobre lo ocurrido durante el Sprint. Los puntos principales a tratar en
esta reunión son:·
Qué se hizo mal: durante el Sprint para poder mejorar el
próximo.
Qué se hizo bien: para seguir en la misma senda del éxito.
Qué inconvenientes se encontraron y no permitieron
avanzar, como se tenía planificado.
III. Herramientas scrum:
por qué y cómo: Para poder definir las respuestas a estas preguntas nos
valemos de ciertas herramientas que Scrum nos provee. Estas son:
● Backlog de Producto/Product Backlog Esto puede referirse a
todo elemento que sea parte del proyecto: puede ser un bug, una referencia o
parte de un requerimiento. Brindan información muy general del proyecto y
muchas veces no son tomados como requerimientos oficiales.
● Historias de Usuario/User Stories Es un elemento especial
del producto Backlog. Se llaman historias porque en ellas se proporciona
información sobre cómo debe ser el comportamiento del requerimiento que se está
trabajando. Su función es proporcionar información directa del cliente en caso
de existir algún cambio. Generalmente estos sí son tomados como requerimientos
oficiales.
● Backlog del Sprint/Sprint Backlog Es el conjunto de
elementos tomados del Product Backlog que fueron priorizados, medidos y
aceptados en las reuniones de Sprint Planning. Estos, en conjunto con sus
respectivos User Stories, forman oficialmente los requerimientos a elaborar en
cada uno de los Sprints que tendrá el proyecto.
● El panel de Tareas/The Task board Este panel muestra las
tareas que tienen asignadas los miembros del equipo. Esta tabla se divide en
tres columnas que representan el estado de la actividad:
A. Por hacer
B. Haciendo
C. Terminado
Al inicio del Sprint
todas están en la primera columna. Cuando una tarea pasa a la segunda columna,
el Scrum Master y el Product Owner son notificados respecto a qué está haciendo
cada miembro del equipo y cuánto tiempo lleva trabajando en dicha tarea. Al
finalizar, esta debe cambiarse a la última columna. Esto quiere decir que está
listo para que QA haga las pruebas necesarias.
● Definición de “Listo”/Definition of Done Todo equipo eficaz y
ágil tiene ciertos acuerdos que deben cumplirse antes de dar por finalizado un
proyecto. Estos son:
○ Todas las tareas están
completas.
○ Revisión de Código /
Code Reviewed.·
○ Pruebas realizadas a
cada elemento desarrollado.
○ Revisión por parte de
los clientes (que cumpla sus necesidades).
○ La revisión de las
condiciones de aceptación por parte del Product Owner.
Estas herramientas son útiles, no sólo durante un Sprint, sino también a lo largo del proyecto, pues ayudan al equipo a entender el porqué de cada actividad. Además, son visibles para el equipo y para los externos. En resumen, Scrum es una metodología aplicable a cualquier tipo de proyecto y, aunque su ejecución requiere de un cambio de cultura laboral por parte de los miembros del equipo, los buenos resultados, el recorte de tiempo y de costos que se genera hacen que todo el sacrificio valga la pena.
BIBLIOGRAFÍA
● Modelos de gestión de proyectos: Método Ágil vs Cascada. (2016, November 30). The Work Smarter Guide - Redbooth. https://redbooth.com/hub/es/modelos-gestion-proyectos-metodo-agil-vs-cascada/
● Barreto, G. (n.d.). Crystal Clear - Ingenieria de Soporte Logico.
https://sites.google.com/site/ingsoportelogico/home/crystal-clear
● Sommerville, I. (2005). Ingeniería del software. Pearson educación.
● Molina, S. G. R. (2013). Metodologías ágiles enfocadas al
modelado de requerimientos. Informes
Científicos Técnicos-UNPA, 5(1),
1-29.
●
S. (2015, September 13). Historia –. Programación eXtrema.
https://iswugaps2extremeprogramming.wordpress.com/category/historia/#:%7E:text=Podr%C3%ADamos%20decir%20que%20XP%20nace,simples%20de%20lo%20que%20nos
● Izquierdo, J. (2017,
August 3). ¿Qué es el XP Programming?
Thinking for Innovation. https://www.iebschool.com/blog/que-es-el-xp-programming-agile-scrum/#:%7E:text=El%20Extreme%20(o%20XP)%20Programming,con%20eficacia%2C%20flexibilidad%20y%20control
●
Ayala, A. P. C. DESARROLLO
DE SOFTWARE DE NOMINA DE EMPLEADOS UTILIZANDO LA METODOLOGIA CRYSTAL.
● Calero, W., &
Perfil, V. T. M. (2010, October 8). Modelo de Desarrollo Concurrente. Blogger.
http://ingenieraupoliana.blogspot.com/2010/10/modelo-de-desarrollo-concurrente.html#:%7E:text=El%20modelo%20concurrente%20tiene%20la,en%20el%20proceso%20de%20desarrollo.
● Baudin,
C. (2011, June). HTTP Request denied. Https://Scielo.Org/Es/. https://scielo.conicyt.cl/scielo.php?script=sci_arttext&pid=S0718-33052011000100014
●
Aroca
Aparicio, D. (2021, January 28). Ingeniería Concurrente: Definición y
aplicación al desarrollo de productos. Lean Manufacturing 10.
https://leanmanufacturing10.com/ingenieria-concurrente
● Pressman, Roger S. (2002). Ingenieria
del Software - Un Enfoque Practico 5b: Edicion (Spanish Edition) [E-book].
McGraw-Hill Companies.
http://www.javier8a.com/itc/bd1/ld-Ingenieria.de.software.enfoque.practico.7ed.Pressman.PDF
Me guta :3
ResponderEliminar