Metodología Scrum

Metodología Scrum

Dulce Mendoza

Bryan Rivero

En el año de 1986 Takeuchi y Nonaka publicaron el artículo “ The New Product Developroent Game” el cual dará a conocer una nueva forma de gestionar proyectos en la que la agilidad, flexibilidad, y la incertidumbre son los elementos principales.

Nonaka y Takeuchi se fijaron en empresas tecnológicas que, estando en el mismo entorno en el que se encontrabas otras empresas, realizaban productos en menos tiempo, de buena calidad y menos costes.

Observando a empresas como Honda, HP, Canon…etc, Se dieron cuenta de que el producto o seguía unas pases en las que había un equipo especializado en cada una de ellas, si no que se partía de unos requisitos muy generales y el producto lo realizaba un equipo multisciplinar que trabajaba desde el comienzo del proyecto hasta el final.

Se comparó esta forma de trabajo en equipo, con la colaboración que se hacen los jugadores de rugby y la utilización de una formación denominada SCRUM.

Scrum aparece como una práctica destinada a los productos tecnológicos y será en 1993 cuando realmente Jeff Sutherland aplique un modelo de desarrollo de Software en Ease/Corporation.

En 1996, Jeff Surtherland y Ken Schwaber presentaron las prácticas que se usaban como proceso formal para el desarrollo de software y que pasarían a incluirse en la lista de Agile Alliance.

Scrum es adecuado para aquellas empresas en las que el desarrollo de los productos se realiza entornos que se caracterizan por tener:

Incertidumbre: Sobre esta variable se plantea el objetivo que se quiere alcanzar sin proporcionar un plan detallado del producto.

Esto genera un reto y da la autonomía que sirve para generar un “tensión” adecuada para la motivación de los equipos.

Auto-organización: Los equipos son capaces de organizarse por si solos, no necesitan roles para la gestión pero tienen que reunir las siguientes características:

-Autonomía: Son los encargados de encontrar la solución usando la estrategia que encuentren adecuada.

-Autosuperación: Las soluciones iniciales sufrirán mejoras.

-Auto-enriquecimiento: Al ser equipos multidisciplinares se ven enriquecidos de forma mutua, aportando soluciones que pueden complementarse.

Control moderado: Se establecera un control suficiente para evitar descontroles. Se basa en crear un escenario de “autocontrol entre iguales” para no impedir la creatividad y espontaneidad de los miembros del equipo.

Transmisión del conocimiento: Todo el mundo aprende de todo el mundo. Las personas pasan de unos proyectos a otros así comparten sus conocimientos a lo largo de la organización.

Scrum al ser una metodología de desarrollo ágil tiene como base la idea de creación de ciclos breves para el desarrollo, que comúnmente se llama iteraciones y que en Scrum se llamaran “Sprints”, Su ciclo tiene 5 fases que definen el ciclo:

-Concepto: Se define de forma general las características del producto y se asigna el equipo que se encargara de su desarrollo.

-Especulación: En esta fase se hacen disposiciones con la información obtenida y se establecen los límites que marcaran el desarrollo del producto, yales como costes y agendas.

-Exploración: Se incrementa el producto en el que se añaden las funcionalidades de la pase de especulación.

-Revisión: El equipo revisa todo lo que se ha construido y se contrasta con el objetivo deseado.

-Cierre: Se entregara en la fecha acordada un versión del producto deseado. Al tratarse de una versión, el cierro no indica que se ha finalizado el proyecto sino que seguirá habiendo cambios, denominados “mantenimientos”, que hará que el producto final se acerque al producto final deseado.

Scrum gestiona estas iteraciones a través de reuniones diarias, uno de los elementos fundamentales de esta metodología

Componentes de Scrum.

Para entender todo lo que el proceso de desarrollo del Scrum, se describirá de forma general las fases y roles. Estas fases y roles se detallaran de forma más concisa mas adelante.

Scrum se puede dividir de forma general en 3 fases, que podemos entender como reuniones. Las reuniones forman parte de los artefactos de esta metodología junto con los roles y elementos que lo forman.

Las Reuniones.

Planificación del Backlog: Se definirá un documento en el que se reflejaran los requisitos del sistema por prioridades.

En esta fase se definirá también la planificación del Sprint 0, en la que se decidirá cuáles van a ser los objetivos y el trabajo que hay que realizar para esa iteración.

Se obtendrá además en esta reunión un Sprint Backlog, que es la lista de tareas y que es el objetivo más importante del Sprint.

Seguimiento del Sprint: En esta fase se hacen las reuniones diarias en las que las 3 preguntas principales para evaluar el avance de las tareas serán:

-¿Qué trabajo se realizó desde la reunión anterior?

-¿Qué trabajo se hará hasta la nueva reunión?

-Inconvenientes que han surgido y que hay que solucionar para poder continuar.

Revisión del Sprint: Cuando se finaliza el Sprint se realizara una revisión del incremento que se ha generado. Se presentara los resultados finales y una demo i versión, esto ayudara a mejorar el feedback con el cliente.

Los Roles.

Los roles se dividen en 2 grupos: Cerdos y Gallinas, esto surge en el chiste sobre un cerdo y una gallina y su intención de poner un restaurante.

Los Cerdos:

Son las personas que están comprometidas con el proyecto y el proceso de Scrum.

-Producto Owner: Es la persona que toma las decisiones, y es la que realmente conoce el negocio del cliente y su visión del producto. Se encarga de escribir las ideas del cliente, las ordena por prioridad y las coloca en el Product Blaclog.

-ScrumMaster: Es el encargado de comprobar que el modelo y la metodología funciona. Eliminará todos los inconvenientes que hagan que el producto no fluya e interactuara con el cliente y con los gestores

-Equipo De Desarrollo: Suele ser un equipo pequeño de unas 5-9 personas y tienen autoridad para organizar y tomar decisiones para conseguir su objetivo. Está involucrado en la estimación del esfuerzo de las tareas del blacklog.

Las Gallinas:

Aunque no son partes del proceso Scrum, es necesario que parte de la retroalimentación de la salida del proceso y así poner revisar y planear cada Sprint.

-Usuarios: Es el destinatario final del producto.

-Stakeholders: Las personas al as que el proyecto les producirá un beneficio. Participan durante las revisiones del Sprint.

-Managers: Toma decisiones finales participando en la selección de los objetivos y de los requisitos.

Elementos de Scrum.

Los elementos que forman Scrum son:

-Product Blacklog: Lista de necesidades del cliente.

-Sprint Backlog: Lista de tareas que se realizan en un Sprint.

-Incremento: Parte añadida o desarrollada en un Sprint, es una parte terminada y totalmente operativa.

Product Blacklog.

Es el inventario en el que se almacenan todas las funcionalidades o requisitos en forma de lista priorizada. Estos requisitos serán los que tendrán el producto o los que ira adquiriendo en sucesivas iteraciones.

La lista será gestionada y creada por el cliente con ayuda del Scrum Master, quien indicara el coste estimado para completar un requisito, y además contendrá todo lo que aporte un valor final al producto.

Es necesario que antes de empezar el Sprint se definan cuales van a ser los objetivos del producto y tener una lista de requisitos ya definida. No es necesario que sea muy detallada, simplemente deberá contener los requisitos principales para que el equipo pueda trabajar.

 Una vez definidos los requisitos se tendrá que acordar cuando se tiene que entender un objetivo como terminado o completado.

Como complemento a la definición  de completado, se deberá asociar una condición de aceptación o no aceptación a cada objetivo en el mismo momento en el que se crea la lista.

Finalmente el Product Blacklog ira evolucionando mientras el producto exista en el mercado. Esta es la forma para evolucionar y tener un valor del producto para el cliente suficiente para ser competitivo.

Las Historias de Usuario.

Son las descripciones de las funcionalidades que va a tener el software.

Estas Historias de usuarios, serán el resultado de la colaboración entre el cliente y el equipo, e iran evolucionando durante toda la vida del proyecto.

Las historias de usuario se componen de tres fases denominadas “Las 3 C”:

-Card: Sera una breve descripción escrita que servirá como recordatorio.

-Conversation: Es una conversación que servirá para asegurar de que se ha entendido bien todo, y concretar el objetivo.

-Confirmation: Tests funcionales para finar detalles que sean relevantes e indicar cuál va a ser el límite.

Formato de la Pila Del Producto (Product Blacklog).

En Scrum, la preferencia por tener documentación en todo momento es menos estricta. Se encuentra mas necesario el matener una comunicación directa con el equipo, por eso se usa como herramienta el Backlog.

Aunque no hay ningún producto especial al a hora de confeccionar la lista, es conveniente que incluya información relativa a:

-Identificador para la funcionalidad.

-Descripción de la funcionalidad.

-Sistema de priorización u orden.

-Estimación.

Sprint Backlog.

En esta lista de tareas que elabora el equipo durante la planificación de un Sprint. Se asignan las tareas a cada persona y el tiempo que queda para terminarlas.

De esta manera el proyecto se descompone en unidades más pequeñas y se puede determinar o ver en que tarea no se está avanzando e intentar eliminar el problema.

Cómo funciona la lista:

Es una lista ordenada por prioridades para el cliente.

Puede haber dependencias entre tareas y ora, por lo tanto se tendrán que diferenciar de alguna manera.

Todas las tareas tienen que tener un coste semejante que será entre 4-16 horas.

Formato de la lista:

-Hay 3 opciones:

-Hojas de cálculo.

-Pizarras.

-Herramientas colaborativas.

Incremento.

Representa los requisitos que se han completado en una iteración y que son perfectamente operativos.

Según los resultados que se obtengan, el cliente puede ir haciendo los cambios necesarios y replanteando el proyecto.

     

Metodologia de James Senn

Wilmar Angulo

Ender Goyo

 Faces de la metodologia de James Senn

 Metodología Senn 

 Caracteristicas

 Existen 3 entrategias según James Senn

• el método clásico del ciclo de vida de desarrollo de sistemas

• el método de desarrollo por análisis estructurado

• el método de construcción de prototipos de sistemas

 origenes

Metodologia

     Basado en lo dicho por  James Senn en su libro titulado "Análisis y diseño de sistemas de información" un sistema  "es considerar como un todo unitario y organizado de procesos, procedimientos, tareas, métodos y recursos materiales, tecnológicos y humanos interdependientes, de que se vale una organización para alcanzar un objetivo, y es fácilmente identificable por los límites de su medio ambiente".

•         

    Esto quiere decir que un sistema de información es un ente que sigue una estructura bien organizada y claramente planteada con el fin de emitir y generar información histórica, actual y proyecciones futuras inclusive, todo esto con la espina vertebral de las operaciones llevadas a cabo por la organización.

Fases de desarrollo para Senn:

      1  Investigación preliminar: se inicia a través de la solicitud del sistema; se aclarara la solicitud del horario, es decir se especificaran los pasos a tomar; se realizara un estudio de factibilidad, tomando en cuenta 3 factores en este caso:

A   Económico: El valor económico en función al personal, equipos, etc…

B  Técnica: Que será la verificación del software y hardware así como el personal técnico y

C  Operacional: Ver si están en la capacidad de operar con el nuevo sistema; finalmente se aprobara la solicitud, si cumple con las características estipuladas.

2 Determinación de los requerimientos del sistema: Se  hace un estudio del sistema actual, y se determinan los nuevos requerimientos del sistema (a través de formularios, encuestas, etc…), así como las entradas y salidas del sistema actual.

3) Diseño del sistema: Se describe como se transformaran los datos en información; este diseño se realizara en dos bases, una lógica: donde se harán modelos e-r, bases de datos, diagramas de flujo de datos, etc…, y una física: es decir todo lo tangible (papeles, gráficos, etc…)

4) Desarrollo del software: se dará la construcción y programación de este sistema.

5) Prueba del sistema: Aquí se pretende detectar las posibles fallas de aplicación del sistema (fallas de programación, de análisis, de diseño (este es el mas critico)), en este proceso se simulan entradas de datos, se ponen a usuarios externos a interactuar con el sistema, se hace la aprobación escrita de todos los aspectos del sistema, cabe destacar que esto debe hacerse de forma gradual.

6) Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla, esta implantación se puede hacer por 3 enfoques,

a) Piloto: Se elegirá solo un sector de la empresa para usar el sistema,

b) Paralelo: Se utilizara el sistema viejo y el nuevo al mismo tiempo, para comparar,

c) Por sustitución: Sencillamente se sustituye todo el sistema); la evaluación se lleva a cabo para identificar puntos débiles y fuertes, como la operacionalidad , la administración, el desempeño de desarrollo (, el desempeño como tal y el desempeño.

                                       Características

Se  define el sistema como un medio organizado de proporcionar información pasada, presente y hasta futura (proyecciones) relacionada con las operaciones internas y el conocimiento externo de la organización". 

Se establece que el sistema sigue una estructura bien organizada y claramente planteada con el fin de emitir y generar información histórica, actual y proyecciones futuras inclusive, todo esto con la espina vertebral de las operaciones llevadas a cabo por la organización.

El sistema se considera  como un todo unitario y organizado de procesos, procedimientos, tareas, métodos y recursos materiales, tecnológicos y humanos interdependientes, de que se vale una organización para alcanzar un objetivo, y es fácilmente identificable por los límites de su medio ambiente".

Según James Senn, existen tres estrategias para el desarrollo de sistemas

 El método clásico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por análisis estructurado y el método de construcción de prototipos de sistemas. Cada una de estas estrategias tiene un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada.

                                          Origen

James A. Senn es Profesor   y Gerente del Centro para el Liderazgo Global Business se especializa en consultoría destinada a la dirección ejecutiva, las estrategias empresariales de éxito, la innovación empresarial, el comercio electrónico, y en el desarrollo, implementación y gestión de las tecnologías de la información. A partir de  su experiencia laboral James A Senn vio la necesidad de desarrollar una metodología la cual permitiera desarrollar la excelencia empresarial y un alto rendimiento administrativo, además de esto su metodología debía permitir el uso de la tecnología informática en los sistemas empresariales  en vista de esto Publica su libro “Análisis y Diseño de sistemas de Información” en el cual se plantean una serie de preceptos y estrategias los que permiten un amplio entendimientos de las formas y mecanismos para desarrollas sistemas.

Fases del Ciclo de desarrollo de un sistema según James-Senn:

1) Investigación preliminar: se inicia a través de la solicitud del sistema (ya sea por medio verbal, fax, e-mail, etc.); se aclarara la solicitud del horario, es decir se especificaran los pasos a tomar; se realizara un estudio de factibilidad, es decir con que recursos cuento, se tomaran en cuenta 3 factores en este caso:

a) económico: el valor económico en función al personal, equipos, etc.

b) técnica: que será la verificación del software y hardware así como el personal técnico.

c) operacional: ver si están en la capacidad de operar con el nuevo sistema; finalmente se aprobara la solicitud, es decir saber si cumple con las características estipuladas.

2) Determinación de los requerimientos del sistema: es decir que tan grande es, examinar los procesos; se hace un estudio del sistema actual, y se determinan los nuevos requerimientos del sistema (a través de formularios, encuestas, etc), así como las entradas y salidas del sistema actual.

3) Diseño del sistema: va a ser como se va a desarrollar el sistema, la forma en como esos requerimientos los voy a automatizar, se definen las formas de cálculo, y se describe como se transformaran los datos en información; este diseño se realizara en dos bases, una lógica: donde se harán modelos e-r, bases de datos, diagramas de flujo de datos, etc, y una física: es decir todo lo tangible (papeles, gráficos, etc.).

4) Desarrollo del software: se dará la construcción y programación de este sistema, se recomienda en algunos casos usar diseñadores y analistas de la compañía y programadores de otra compañía, o viceversa, aunque esto puede tener sus ventajas: los costos pueden ser menores, es rentable usar un terreno por los costos, y también sus desventajas: no existiría comunicación fiel entre programadores y diseñadores, etc.

5) Prueba del sistema: aquí se pretende detectar las posibles fallas de aplicación del sistema (fallas de programación, de análisis, de diseño (este es el más critico)), en este proceso se simulan entradas de datos, se ponen a usuarios externos a interactuar con el sistema, se hace la aprobación escrita de todos los aspectos del sistema, cabe destacar que esto debe hacerse de forma gradual.

6) Implantación y evaluación: la implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla, esta implantación se puede hacer por 3 enfoques,

a) piloto: se elegirá solo un sector de la empresa para usar el sistema,

b) paralelo: se utilizara el sistema viejo y el nuevo al mismo tiempo, para comparar,

c) por sustitución: sencillamente se sustituye todo el sistema (es el más riesgoso); la evaluación se lleva a cabo para identificar puntos débiles y fuertes, como la operacionalidad (cómo funciona el sistema), la administración, el desempeño de desarrollo (sería una relación de tiempo versus beneficio), el desempeño como tal y el desempeño organizacional (relación costo versus beneficio).

MÉTODO DEL PROTOTIPO DE SISTEMAS

La construcción de prototipos representa una estrategia de desarrollo, cuando no es posible determinar todos los requerimientos del usuario. Es por ello que incluye el desarrollo interactivo o en continua evolución, donde el usuario participa de forma directa en el proceso.

Este método contiene condiciones únicas de aplicación, en donde los encargados del desarrollo tienen poca experiencia o información, o donde los costos y riesgos de que se cometa un error pueden ser altos.

Así mismo este método resulta útil para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación. El método del prototipo de sistemas consta de 5 etapas:

1). Identificación de requerimientos conocidos: La determinación de los requerimientos de una aplicación es tan importante para el m‚todo de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o análisis estructurado. Por consiguiente, antes de crear un prototipo, los analistas y usuario deben de trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacer.

2). Desarrollo de un modelo de trabajo: Es fácil comenzar los procesos de construcción del prototipo con el desarrollo de un plan general que permita a los usuarios conocer lo que se espera de ellas y del proceso de desarrollo. Un cronograma para el inicio y el fin de la primera interacción es de gran ayuda. En el desarrollo del prototipo se preparan los siguientes componentes:

a). El lenguaje para el dialogo o conversación entre el usuario y el sistema.

b). Pantallas y formatos para la entrada de datos.

c). Módulos esenciales de procesamiento.

d). Salida del sistema

3). Utilización del prototipo: Es responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. La experiencia del sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, así como las características inadecuadas

4). Revisión del prototipo: Durante la evaluación los analistas de sistemas desean capturar información sobre los que les gusta y lo que les desagrada a los usuarios.

Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo, sin embargo es el analista responsable de tales modificaciones.

5). Repetición del proceso las veces que sea necesarias: El proceso antes descrito se repite varias veces, el proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.

}

MÉTODO DE DESARROLLO POR ANÁLISIS ESTRUCTURADO

Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de:

1). La división del sistema en componentes

2). La construcción de un modelo del sistema.

El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento, etc.). Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.

El análisis estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Éste análisis permite al analista conocer un sistema o proceso en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente.

Componentes

Símbolos gráficos: Iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.

Diccionario de datos: descripción de todos los datos usados en el sistema. Puede ser manual o automatizado.

Descripciones de procesos y procedimientos: declaraciones formales que usan técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.

Reglas: estándares para describir y documentar el sistema en forma correcta y completa.

Diseño Estructurado.

El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software.

El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional.

La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo).

Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.

Análisis de flujo de datos.

Estudia el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas usa los diagrama de flujos de datos y los diccionarios de datos.

Herramientas

Las herramientas muestran todas las características esenciales del sistema y la forma en que se ajustan entre si, como es muy difícil entender todo un proceso de la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, junto con sus acciones.

Diagrama de flujo de datos

Es el modelo del sistema. Es la herramienta más importante y la base sobre la cual se desarrollan otros componentes.

El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos cada vez más detallados. Repitiéndose esta secuencia hasta que se obtienen suficientes detalles para que el analista comprenda la parte del sistema que se encuentra bajo investigación.

El diagrama físico de datos da un panorama del sistema en uso, dependiente de la implantación, mostrando cuales tareas se hacen y como son hechas. Incluyen nombres de personas, nombres o números de formato y documento, nombres de departamentos, archivos maestro y de transacciones, equipo y dispositivos utilizados, ubicaciones, nombres de procedimientos.

El diagrama lógico de datos da un panorama del sistema, pero a diferencia del físico es independiente de la implantación, que se centra en el flujo de datos entre los procesos, sin considerar los

                         Definiciones “las 3 metologias”

1.-Método del ciclo de vida y desarrollo del sistema: incluye las actividades de investigación preliminar, determinación de requerimientos, diseño del sistema, desarrollo del software, prueba del sistema e implantación. Los requerimientos del sistema de información predecible, manejables como proyecto, requiere que los datos se encuentren en archivos y bases de datos, gran volumen de transacciones y procesamiento. Muchas de estas actividades pueden realizarse de manera concurrente y ello hace posible que las diferentes partes del sistema se encuentren al mismo tiempo en distintos grados de avance. El tiempo de desarrollo de este método es largo e incluye el desarrollo por equipos de proyecto.

2. Método Análisis Estructurado: Se enfoca en el que sistema o aplicación realiza sin importar la forma en que se llevan a cabo las funciones, abordando los aspectos lógicos y no los físicos. En este método se emplean símbolos gráficos para representar el procesamiento de datos. Los componentes importantes incluyen los diagramas de flujo de datos, que señalan el flujo de datos en el sistema y entre los procesos y dispositivos de almacenamiento de datos, y el diccionario de datos, que incluye todas las definiciones datos, procesos y demás información pertinente. Este método incluye la formulación las especificaciones, de forma funcional, para cada uno de los módulos del software. Este método es adecuado para todo tipo de aplicaciones y tiene mayor utilidad como complemento de otros métodos de desarrollo.

3. Método del prototipo de sistemas: La construcción de prototipos representa una estrategia de desarrollo, cuando no es posible determinar todos los requerimientos del usuario. Es por ello que incluye el desarrollo interactivo o en continua evolución, donde el usuario participa de forma directa en el proceso. Este método posee 5 etapas: Identificación de requerimientos, desarrollo de un modelo de trabajo, utilización del prototipo, revisión del prototipo y repetición del proceso. 

Hoy en día, con el auge de las computadoras y su influencia en nuestro mundo, las empresas, con la ayuda de los analistas de sistemas, que ejercen un gran peso en las decisiones que se toman en la misma, ya que cuentan con varias herramientas para análisis, diseño y desarrollo que les permiten cumplir con sus responsabilidades. Cuando estas herramientas se utilizan de manera apropiada, contribuyen sustancialmente a la utilidad del sistema, y deciden, de forma parcial, qué hacer con los sistemas actuales, si reemplazarlos o no. Cada uno de ellos, de acuerdo a la empresa, se rigen por una metodología bien sea de un autor u otro, en este caso les mostramos, como se desarrollaría un proyecto según el autor James Senn.

Modelo Incremental

El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos.

En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento.

Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo.

De esta forma el tiempo de entrega se reduce considerablemente.

Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.

El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

Pipeline

La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior.

Esta arquitectura es muy común en el desarrollo de programas para el intérprete de comandos, ya que se pueden concatenar comandos fácilmente con tuberías (pipe).

También es una arquitectura muy natural en el paradigma de programación funcional, ya que equivale a la composición de funciones matemáticas.

Características

- Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.

- El usuario se involucre más.

- Difícil de evaluar el costo total.

- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.

- Requiere gestores experimentados.

- Los errores en los requisitos se detectan tarde.

- El resultado puede ser muy positivo.

Ventajas:

- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.

- También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.

- El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.

- Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.

- Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.

- Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.

- Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.

- Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.

- Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos

Desventajas:

- El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.

- Requiere de mucha planeación, tanto administrativa como técnica.

- Requiere de metas claras para conocer el estado del proyecto.

- Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).

- Cada incremento debe aumentar la funcionalidad.

- Es difícil establecer las correspondencias de los requisitos contra los incrementos.

- Es difícil detectar las unidades o servicios genéricos para todo el sistema

Eduardo Hernández

Geto Jean Michel