Sistemas de información.

Un sistema de información es un conjunto de datos que interactúan entre sí con un fin común.

En informática, los sistemas de información ayudan a administrar, recolectar, recuperar, procesar, almacenar y distribuir información relevante para los procesos fundamentales y las particularidades de cada organización.

La importancia de un sistema de información radica en la eficiencia en la correlación de una gran cantidad de datos ingresados a través de procesos diseñados para cada área con el objetivo de producir información válida para la posterior toma de decisiones.

PARCIAL 1.- Fundamento de sistemas.

Características de un sistema de información.

Un sistema de información se caracteriza principalmente por la eficiencia que procesa los datos en relación al área de acción. Los sistemas de información se alimentan de los procesos y herramientas de estadística, probabilidad, inteligencia de negocio, producción, marketing, entre otros para llegar a la mejor solución.

Un sistema de información se destaca por su diseño, facilidad de uso, flexibilidad, mantenimiento automático de los registros, apoyo en toma de decisiones críticas y mantener el anonimato en informaciones no relevantes.

Metodologías del desarrollo de software.

¿Qué es un Método?

Un Método se compone de diversos aspectos que nos permitirán conseguir una meta o lograr un objetivo. Se define más claramente como un conjunto de herramientas, las cuales utilizadas mediante las técnicas correctas, permiten la ejecución de procesos que nos llevarán a cumplir los objetivos que buscamos. En pocas palabras y aunque esto lo puedes encontrar como tal en internet, es un conjunto de herramientas, técnicas y procesos que facilitan la obtención de un objetivo.

¿Qué es una Metodología?

En el desarrollo de software, una metodología hace cierto énfasis al entorno en el cuál se plantea y estructura el desarrollo de un sistema. Como lo mencioné al principio, existen una gran cantidad de metodologías de la programación que se han utilizado desde los tiempos atrás y que con el paso del tiempo han ido evolucionando. Esto se debe principalmente a que no todos los sistemas de la información, son compatibles con todas las metodologías, pues el ciclo de vida del software puede ser variable. Por esta razón, es importante que dependiendo del tipo de software que se vaya a desarrollar, se identifique la metodología para el diseño de software idónea.

¿En qué consisten las Metodologías de Desarrollo de Software?

Una Metodología de desarrollo de software, consiste principalmente en hacer uso de diversas herramientas, técnicas, métodos y modelos para el desarrollo. Regularmente este tipo de metodología, tienen la necesidad de venir documentadas, para que los programadores que estarán dentro de la planeación del proyecto, comprendan perfectamente la metodología y en algunos casos el ciclo de vida del software que se pretende seguir.

Aunque actualmente existen mucha variedad en metodologías de programación. La realidad es que todas están basadas en ciertos enfoques generalistas que se crearon hace muchos años, algunos tipos de metodologías de desarrollo de software que se utilizaron e inventaron al principio de nuestra era tecnológica y son las que veremos a continuación.

¿Cuáles son modelos del Ciclo de vida del Software tradicionales?

Como les mencioné hace un momento, regularmente, cada metodología de desarrollo de software, tiene un enfoque bien marcado, estos enfoques no son para nada nuevos y se siguen utilizando para la planeación y desarrollo de software aún en nuestros tiempos, así que vamos a ver cuáles son cada uno de ellos y aprenderemos como funcionan.

Metodología en cascada: Framework lineal.

El modelo de desarrollo de Software en cascada, es una metodología de la programación muy antigua. Si bien su creador nunca lo menciona como metodología en cascada, el funcionamiento y lineamiento de los procesos de la planeación, son exactamente iguales. Básicamente, el estilo del modelo en cascada, es que no podrás avanzar a la siguiente fase, si la anterior no se encuentra totalmente terminada, pues no tiene por qué haber vuelta atrás. Vamos a ver cuáles son las fases de desarrollo de software del modelo en cascada, para que te puedas dar una idea.

1. Análisis de Requisitos. El primer nivel del modelo cascada, es el análisis de requisitos. Básicamente lo que se documenta aquí, son los objetivos de lo que el software debe hacer al terminar el desarrollo, sin entrar en detalles de la parte interna, los cuales se verán durante el proceso. Sin embargo es importante señalar que una ves avanzado el paso de análisis, no puede haber vuelta atrás, pues la metodología para el diseño de software con la cual se trabaja no lo permitirá.

2. Diseño del Sistema. Todo lo que conlleva el armado de un diseño para el sistema que vayas a utilizar, es lo que continua después del análisis de requisitos. Aquí se elaborará lo que es la estructura del sistema y se determinarán las especificaciones para cada una de las partes del sistema que se planea desarrollar. Siendo del mismo modo, una fase a la cuál ya no se podrá volver después de haber bajado al nivel 3.

3. Diseño del Programa. En este punto, aún no ingresamos a lo que es la escritura de código, sin embargo ya se realizan los algoritmos que se van a utilizar en la programación. Si bien recuerdas, un algoritmo no necesariamente es código, simplemente tomas una hoja de papel y escribes el algoritmo que vas a utilizar. Esto es precisamente lo que se realiza en el paso número 3.

4. Codificación. Seguramente como programador, esta es la parte que estabas esperando, pues ahora es momento de empezar a escribir todo el código que será necesario para el desarrollo del software. Para este punto, la velocidad y el tiempo que se requiera, dependerá mucho del lenguaje de programación que vayas a utilizar. Pues algunos lenguajes de programación permiten utilizar componente, bibliotecas e incluso algunas funciones para reutilizar código, las cuales podrán acelerar el proceso de codificación en gran manera.

5. Ejecución de Pruebas. La codificación ha terminado y ahora es momento de verificar que nuestro sistema es realmente funciona, antes de que el cliente empiece a utilizarlo. Este es precisamente el objetivo de la fase 5 de pruebas. Aquí es recomendable que intentes mover lo más que se pueda tu software, con el objetivo de dañarlo intencionalmente, de este modo, si supera las pruebas de daño realizadas por tí, entonces estará listo para el usuario final.

6. Verificación. Después de haber realizado una gran cantidad de pruebas en la Fase 5, debemos migrar a la verificación. Esta fase consiste en la ejecución del Software por parte del usuario final. Si la fase cinco se realizó correcta y profundamente, el software no tendrá ningún tipo de problema y el usuario final quedará satisfecho con el resultado.

7. Mantenimiento. Seguramente te has dado cuenta, de que las aplicaciones o el software actual, constantemente se está actualizando. Esto se debe principalmente a que se le da mantenimiento al software, se solucionan errores, se quitan algunos bugs, se añaden funcionalidades, todo después de que el usuario final ya lo ha probado y utilizado en su fase final. Esta es posiblemente una de las fases más tediosas del modelo de desarrollo de software, pues debes estar atento a los comentarios de los usuarios, para ver que cosas son las que no funcionan correctamente y a las cuales hay que darles mantenimiento

¿Cuáles son los Principios básicos del modelo de cascada?

Como puedes ver, el proceso de desarrollo de software con el modelo de cascada es bastante complejo. Sin embargo uno de sus principios es que cada una de las fases elaboradas, se encuentre documentada perfectamente, de este modo, si el desarrollo queda suspendido en alguna fase, cualquier usuario que quiera continuar con el proyecto lo podrá hacer leyendo la documentación.

Así también, es muy común encontrar metodologías para el desarrollo de software en cascada con fechas de objetivos, tiempos o presupuestos para determinadas fases. Aprovechando el hecho de que una ves que avanzaste de fase, es muy poco recomendable el volver atrás, aunque regularmente se tiene un cierto nivel de tolerancia, pero lo correcto en la utilización del modelo de cascada, es que no puedas ir atrás a realizar modificaciones de ningún tipo.

Método de Prototipos.

Esta metodología de la programación todavía sigue siendo la favorita de muchos. Consiste básicamente en que en base a los requerimientos y necesidades que tiene el cliente, se realiza de forma rápida un prototipo, este no vendrá completo ni mucho menos terminado, pero si permitirá contar con las bases necesarias para que cualquier programador pueda seguir trabajando en el hasta llegar al código final.

Por si no lo sabes aún, un prototipo es una versión no terminada del producto que se le entregará al cliente o usuario final. Esto nos genera cierta ventaja en el desarrollo de productos similares con funciones distintas, por ejemplo. Supongamos que vas a desarrollar un proyecto para 3 clientes distintos, ambos con una estructura idéntica pero con funcionalidades muy distintas, entonces lo que hacemos es crear un prototipo base y entorno a el mostrarlo a nuestros clientes para que de ahí se empiecen a desarrollar las demás funciones.

Mejor vamos a ver cuales son las etapas de desarrollo de software por las cuales tendrás que pasar, en caso de utilizar la metodología de prototipos.

1. Planeación. A diferencia de otras metodologías, la planeación debe ser muy rápida, en esta fase no puedes demorarte mucho, pues recuerda que solamente será un prototipo por el momento.

2. Modelado. Nuevamente, una fase que deberá ser suficientemente rápida como para que nos quite nada de tiempo. Hacer el modelado será simple y te sigo recordando que solamente es un prototipo, al menos por ahora.

3. Elaboración del Prototipo. Ya que contamos con la planeación de lo que vamos a realizar y el modelado rápido, entonces es momento de elaborar el prototipo. Para esta instancia, ya no te diré que lo debes hacer rápido, puesto que te tomará el tiempo que tenga sea necesario elaborarlo, recuerda que este ya se muestra al cliente, así que ya es una fase importante.

4. Desarrollo. Posterior a contar con el prototipo elaborado y mostrado al cliente, es momento de comenzar el desarrollo. Este te tomará una gran cantidad de tiempo, dependiendo del tamaño del proyecto y el lenguaje de programación que se vaya a utilizar.

5. Entrega y Retroalimentación. Una de las cosas con las que cuenta el modelo de prototipos, es que una ves entregado el proyecto, debemos darle al cliente cierta retroalimentación sobre como utilizarlo y ciertamente es una fase que se encuentra dentro de las etapas de desarrollo de software esta metodología.

6. Comunicación con el Cliente. Es importante que una ves entregado el proyecto, tengamos cierta comunicación con el cliente, básicamente para que nos indique si el proyecto es correcto o si desea agregarle ciertas funciones, nuestra metodología lo permite. Si fuera en modo cascada, entonces seria algo realmente imposible de hacer.

7. Entrega del Producto Final. Por último, solamente quedará entregar el sistema elaborado mediante esta metodología. Aquí tendrás la ventaja de que el código es reutilizable, para que así con el prototipo ya puedas simplemente empezar de nuevo y con una buena base de código que te acelerará el proceso.

¿Cuáles son los Principios Básicos del método de prototipos?

Por supuesto, te habrás dado cuenta de que el modelo de prototipos puede llegar a ser un poco más tedioso, aunque todo dependerá del ámbito en que lo utilices. Sin embargo uno de sus principios básicos que seguramente habrás notado, es que con el método de prototipos el proyecto se va dividiendo en partes cada ves mas pequeñas, para evitar el peligro ante los riesgos frente a los que estamos expuestos.

Además, otros de sus principios básicos fundamentales, es que con la metodología de prototipos, el cliente final se involucra mucho más en el proyecto que con otras metodologías, haciendo de esta forma que el producto final llegue rápidamente aunque con un poco más de presión en el proceso. La ventaja es que conforme se van haciendo prototipos pequeños, poco a poco se va llegando al producto final. Incluso en algún determinado momento podrás llegar a crear un prototipo que con solo ajustar ciertos detalles, se podría convertir en el producto que el usuario quiere.

Modelo Incremental o Iterativo y Creciente.

El modelo Incremental, es una metodología de la programación muy utilizada hoy en día, pues su comodidad de desarrollo permite que te obtenga un producto final mucho más completo y exitoso. Se trata especialmente de la combinación de los modelos lineal e iterativo o bien, modelo de cascada y prototipos. Básicamente consiste en completar varias iteraciones de lo que es el modelo de cascada, pero sin completar ninguna, haciendo iteraciones lo que se hace es crear una evolución en el producto, permitiendo que se agreguen nuevas especificaciones, funcionalidades, opciones, funciones y lo que el usuario requiera después de cada iteración.

En pocas palabras, el Modelo Incremental repite el modelo de cascada una y otra ves, pero con pequeñas modificaciones o actualizaciones que se le puedan ir agregando al sistema. De este modo el usuario final se ve sumamente sumergido en el desarrollo y puedes proporcionarle un resultado óptimo.

Fases del Modelo Incremental.

El modelo iterativo o incremental, cuenta con algunas fases de desarrollo de software que realmente no tienen mucha complejidad, vamos a verlas:

1. Inicialización. como en todo modelo de desarrollo, debe haber una inicialización, aquí se puede hablar de dar una idea, de tener algunos requisitos que se buscan en el proyecto y ciertas especificaciones que se pueden manejar. No es necesario que se haga una lista total de requerimientos pues recordemos que el proyecto se basa en iteraciones, así que el proyecto puede ir evolucionando poco a poco.

2. Periodos de Iteración. Durante el desarrollo del proyecto, es cuando damos inicio a las iteraciones. La primera iteración se realiza con las características iniciales, básicamente al final de la primer iteración, queda un pequeño prototipo de lo que será el proyecto, pero se puede volver a inicializar la iteración y realizar modificaciones en los procesos, como el análisis y las especificaciones o funciones que el usuario final requiere para su sistema. El número de iteraciones que se realicen son ilimitadas y dependerá tanto del desarrollador como del usuario final. Si nuestro objetivo es que el cliente o la persona que necesita el trabajo quede completamente satisfecha, entonces nos veremos en la necesidad de hacer la cantidad de iteraciones que se requieran al final del día.

3. Lista de Control. Es importante que conforme se vaya realizando cada iteración, se vaya llevando un control del mismo en una lista. Como si fuera un programa que recibe actualizaciones constantemente. Cada una de las actualizaciones o iteraciones deberá ser documentada y de ser posible, guardada en sus respectivas versiones, para que sea sencillo volver atrás, en caso de que una iteración no sea exitosa o el usuario ya no la requiera.

¿Cuáles son los principios básicos del Modelo Incremental?

Es importante definir los siguientes principios fundamentales, pues nos permiten saber con claridad por donde va la idea de la metodología.

La idea de un modelo incremental, es utilizar una serie de mini modelos de desarrollo de software en cascada, segmentando requerimientos y permitiendo que el usuario vaya de la mano con el proyecto durante la realización.

Básicamente las fases de cada iteración, son las mismas que se manejan en el modelo de cascada, aunque también se pueden agregar algunas, pero su objetivo es completar cada fase de la iteración, para que esta se vaya complementando poco a poco y no se genere un desarrollo tedioso y cansado que puede alargar la duración del proyecto en demasía.

Debes saber, que cada iteración te generará un prototipo cada ves mas evolucionado, estos deberás guardarlos por si en determinado momento deseas volver atrás, pues a diferencia del modelo de cascada, podemos retroceder cuando se requiera y los prototipos se pueden volver a utilizar una y otra ves, pues el código fuente es reutilizable.

Modelo en Espiral.

El modelo en espiral, fue utilizado y diseñado por primera ves por Barry Boehm en 1986. Se trata nuevamente de una combinación entre el modelo lineal o de cascada y el modelo iterativo o basado en prototipos, sin embargo a este sistema lo que debemos añadirle es la gestión de riesgos, algo que en los modelos anteriores ni siquiera se menciona.

Este modelo, consiste en ciertas fases que se van realizando en modo de espiral, utilizando procesos de la misma forma en que se utilizan en el modelo de cascada, sin embargo aquí estos no son obligatorios y no llevan precisamente el orden establecido. Básicamente se trata de un modelo evolutivo, que conforme avancen los ciclos, irá incrementando el nivel de código fuente desarrollada, un incremento en la gestión de riesgos y por supuesto un incremento en los tiempos de ejecución y planificación del sistema, esto es lo que tiene el modelo en espiral.

Para que tengas una idea más clara, el modelo en espiral es principalmente utilizado para el desarrollo de grandes proyectos como la creación de un sistema operativo. Sin embargo necesitas de ciertos requisitos, como el hecho de contar con personal completamente capacitado para las funciones que se requieran. Mejor veamos cuales son las las fases o tareas dentro del modelo de espiral.

1. Determinar Objetivo. Es importante que siempre consideres una planeación inicial, esta solo se realizará una vez. Sin embargo el proceso de determinar objetivos se hará constantemente durante cada iteración que se vaya realizando con el modelo espiral. Esto se debe a que poco a poco se irá incrementando más el tamaño del manual de usuario, los requisitos, las especificaciones e incluso las restricciones. Todo esto entra en lo que es la tarea de objetivos y con cada vuelta en el espiral entraremos a esta tarea, la cual como todas las demás, es fundamental.

2. Análisis de Riesgo. Una etapa donde incluso una lluvia de ideas podría ayudar, el análisis de riesgos. Aquí deberás tener en cuenta todo aquello que pueda dañar a tu proyecto, ya sea que se trate de ciertas amenazas o de posibles daños que se puedan ocasionar, teniendo además un Plan B por así decirlo, para que en caso de que ocurra algo inesperado, tener a la mano la solución para continuar con el proyecto. En esta fase del modelo espiral, podemos agregar lo que son la creación de prototipos, pues siempre es bueno tener un respaldo de nuestro código, se esta forma en caso de que algo malo suceda, volvemos a la versión anterior. Así que cada vez que vayamos a ingresar a la fase de pruebas e implementación, será necesario contar con un prototipo que nos respalde.

3. Desarrollar, Validar y Probar. Básicamente en esta fase, la forma en que se estará desarrollando el proyecto, dependerá del análisis de riesgos, pues siempre se va a ir desarrollando el proyecto enfocándose en los riesgos que podemos evitar en nuestro software, es decir, si la situación de riesgo más obvia se encuentra en la interfaz del usuario, entonces hay que trabajar con prototipos para este enfoque, creando evoluciones proporcionales, para ir evitando ese tipo de riesgos. Esto no significa que ignoremos el resto del proyecto o del desarrollo, sin embargo el modelo en espiral si acomoda un poco más las prioridades al momento, independientemente de todo lo demás. Por lo que siempre en cada vuelta o iteración que se le de al modelo de espiral, tu avance siempre dependerá del análisis de riesgo, hasta que este sea mínimo y el desarrollo pueda continuar de forma normal.

4. Planificación. Antes de proceder a realizar otra iteración o vuelta al espiral, debemos prestar atención a lo que sucedió en la vuelta anterior. Debemos analizar detalladamente si los riesgos encontrados ya tuvieron solución, lo cual debe ser lo ideal, puesto que ahora habría que analizar más especificaciones y más requisitos del sistema para continuar con el desarrollo. Básicamente la fase de planificación, nos servirá para determinar el avance de nuestro proyecto y indicar hacia donde vamos a dirigirnos en la próxima iteración.

¿Cuáles son los Principios básicos del modelo en Espiral?

Está claro que el modelo en espiral, es sumamente distinto a los demás. Encontramos por fuera cuatro fases bien organizadas, las cuáles siempre deben llevar ese orden que se estipula desde el principio. Una determinación de objetivos, un análisis de riesgos, el desarrollo y las pruebas, junto con la planificación, la cual dependerá de los resultados de la iteración para saber cómo se actuará en la siguiente vuelta al espiral.

Básicamente, en el modelo de espiral, toda la atención está enfocada hacia el análisis de riesgos, pues el objetivo primario será reducir los riesgos que se vayan generando, de otra forma el sistema no llegará a ser seguro jamás.

Algo muy importante que debes ver en el modelo de espiral, es que los interesados deben estar involucrados prácticamente en cada vuelta que se dé al espiral, para crear lo que son los requisitos antes de realizar una vuelta más y al final en la fase de planificación, se determinan los logros obtenidos, el avance y lo que se esperará de una siguiente vuelta.

RAD: Desarrollo Rápido de Aplicaciones (Rapid Application Development)

A diferencia de otras metodologías para el desarrollo de software, la metodología RAD o desarrollo rápido de aplicaciones, no cuenta con una serie de fases ordenadas por así decirlo. Aunque si está basada en lo que es el modelo de cascada y la creación de prototipos, sin embargo el proceso es muy independiente a contar con ciertas fases estipuladas como los modelos que hemos visto anteriormente. Así que vamos a ver los principios del modelo RAD.

¿Cuáles son los principios básicos del Modelo RAD?

De los mismos modos que modelos anteriores, el Modelo RAD, está basado en el uso de las iteraciones y principalmente en el manejo de prototipos. Sin embargo a diferencia del resto, la metodología RADhace uso de las Herramientas CASE, las cuales permitirán acelerar el proceso considerablemente.

Del mismo modo que el modelos espiral y el de prototipos, RAD se subdivide en pequeñas secciones, las cuales se irán optimizando y de esta forma se irá avanzando mucho más rápido que con grandes segmentos que pueden volverse difíciles dentro de un proceso acelerado como lo este este modelo.

Una de las ventajas del RAD, es que el enfoque y las prioridades van hacia la fase de desarrollo, a diferencia de modelos como el espiral, que se enfoca en que los riesgos al momento sean mucho menores. Acá con el RAD, se hace lo contrario, si hay riesgos reducimos los requerimientos para reducir los riesgos, no como en el espiral, que entre más riesgos, más requisitos aportamos para que se incremente. Acá la idea es reducir tiempos y no riesgos, o si, talves también, pero la reducción de riesgos es totalmente inversa al modelo espiral.

Por supuesto, como en todos los modelos, vas a requerir de ciertos factores documentados, de preferencia todo lo que se pueda, para que en caso de que alguien más venga a continuar con este proyecto, tenga a la mano toda la información que necesita y con unas cuentas lecturas pueda empezar a desarrollar lo que se había quedado pendiente en un determinado momento.

¿Cuál es tu metodología tradicional preferida?

Si bien hemos visto métodos muy diversos, información muy variada y ciclos de desarrollo de software con distintos enfoques. La realidad es que al final tu siempre decidirás como trabajar y con que tipo de metodología te sentirías más a gusto. Obviamente depende de muchos factores, principalmente del tamaño del proyecto, pues modelos como el espiral, son especialmente para proyectos grandes y modelos como el RAD, son enfocados en proyectos pequeños, sin tanto requisito pero manejando siempre cierto nivel de calidad, el cual siempre debes considerar.

A continuación, analizaremos lo que son las metodologías ágiles de desarrollo de software más importantes, las cuáles a diferencia de las metodologías tradicionales, funcionan más como una combinación de estas para lograr un objetivo. Su finalidad siempre será el crear software de una forma más rápida de lo que se venía logrando con las metodologías de antaño. Así que vamos a ver un poco de información referente a lo que son las metodologías ágiles, como funcionan y que se necesita para implementarlas.

Metodologías Ágiles.

Con el paso del tiempo, estaba claro que las metodologías tradicionales, simplemente no se iban a acoplar con las nuevas tecnologías, los nuevos lenguajes y sobretodo los programadores modernos. Es por eso que desde principios del Siglo, se han desarrollado lo que son las metodologías ágiles. Una metodología ágil, consiste principalmente en trabajar con menos documentación de la que, como vimos, las metodologías tradicionales utilizan en todo momento.

Existen una gran cantidad de metodologías ágiles de desarrollo de software y todas las vamos a ver a continuación. Sin embargo antes hay que comprender en que consiste detenidamente la metodología ágil, para lo cual contamos con el manifiesto ágil. Un documento en el cuál se resume la filosofía de este enfoque de desarrollo, así seguramente después de leer esos puntos, nos quedará aún mas clara la idea de hacia donde se pretende llegar y principalmente Cómo se pretende llegar a los objetivos.

Manifiesto Ágil.

• Al Individuo y las Interacciones del Equipo. Una de las cosas que sabemos muy bien, es que las personas son quienes consiguen los éxitos dentro de un proyecto de software. Sin embargo también está claro que si el equipo de trabajo falla, entonces todo se viene abajo y el enfoque que había de éxito se convierte en incertidumbre. A diferencia de si el equipo funciona perfectamente, se tienen más cerca los objetivos, aún cuando no exista una lista de procesos establecida como se hacía con las metodologías de antaño.

Con este primer valor del desarrollo ágil, se pretender hacer ver, que en realidad no importa que el equipo de trabajo no sean las personas más brillantes del sector. Con que sean personas que saben hacer bien el trabajo que se les asignará es más que suficiente. En este caso, las herramientas aunque son importantes para incrementar el rendimiento, también es cierto que si hay herramientas de más y que no sirven de nada en un principio, lo mejor es dejarlas de lado o estas nos quitarán valioso tiempo que no tendremos.

Básicamente el enfoque, es que no se intente crear un entorno de trabajo desde un principio, tratando de que los desarrolladores se adapten a ese entorno que nosotros deseamos, pues este tipo de proyectos suelen tardar mucho tiempo en desarrollarse, algunos incluso jamás terminan y se quedan estancados. El enfoque del desarrollo ágil nos dice, que es mejor formar primero un buen equipo de trabajo y posteriormente entre ellos vayan creando su propio entorno. Este proceso ayudará mucho más a la metodología ágil y por supuesto, la adaptación será un proceso fugaz.

• Software funcional en lugar de demasiada documentación. Crear documentación, es una de las actividades que con las metodologías tradicionales, absorbían una gran cantidad de tiempo. Si nos acercamos a analizaras las metodologías de antaño, descubriremos que en cada una de ellas, realizar la documentación era una parte vital. Sin embargo en las metodologías ágiles, esto ha cambiado, pues existe una regla que dice de la siguientes forma: "No producir documentación, al menos que sean sumamente necesarios al momento para tomar una decisión". Por lo que además se extienda hacia el enfoque de que la documentación debe ser corta y breve, nada sumamente extenso que requiera de una gran cantidad de tiempo de lectura.

Te preguntarás y entonces, cuando un nuevo programador o desarrollador sea colocado en un puesto dentro del proyecto, como sabrá hacia donde ir y el enfoque que se está llevando a cabo. Para lo cual el manifiesto ágil nos dice que, existen dos elementos fundamentales para que un nuevo miembro del equipo se ponga al día. El primero es el código fuente, pues suponiendo que es una persona conocedora, sabrá hacia donde va el curso del proyecto con tan solo leer el código. La segunda es que la interacción con el equipo de trabajo, será el complemento ideal para que se acople al proyecto. De este modo nos olvidamos de la extensa documentación para un software que al final del día debe estar totalmente funcional.

• Colaboración con el Cliente en lugar de hacer Contrato. Una de las cosas importantes dentro de las metodologías ágiles. Es que cambia el modo en que se trabajaba con el cliente anteriormente. Y es que en las metodologías de antaño, el trabajo consistía en tener una reunión previa con el cliente para analizar los requerimientos del sistema, aquí se analizaban las limitaciones del proyecto y se establecían los costos. Lo que generaba cierta barrera de bloqueo entre las posibilidades de desarrollar algo funcional para otras cosas o solo para el objetivo establecido en la reunión. Esto al final podía ser desastroso y dificultar la llegada al éxito por parte del proyecto.

Sin embargo, ahora en el manifiesto ágil, se propone que exista una interacción constante entre el cliente y el equipo de desarrolladores. La idea es que el cliente vaya viendo como va el sistema y analice nuevas funcionalidades o objetivos, ya que estos no tienen porque plantearse desde el principio, si el desarrollo nos puede llevar a una infinidad de posibilidades. De esta forma el cliente al final queda totalmente satisfecho con el producto final y habremos llegado al éxito trabajando todos en equipo de forma simultanea.

• Posibilidad de Hacer cambios de planes a medio proyecto. Suena mas o menos a lo que vimos en el punto anterior, pues básicamente la idea es evitar lo que es la planeación extensa y empezar a crear código que permita expansión. Recordemos que con las metodologías tradicionales, se acostumbraba a enlistar los requisitos del sistema y el desarrollo iba enfocado solamente a eso, lo cual ya no permitía que a medio desarrollo hubiera cambios, pues era un código poco moldeable y si se requerían nuevas cosas, en algunas metodologías lo idea era volver a empezar.

La idea en las metodologías ágiles, es que durante el desarrollo del software, si el cliente tiene la idea de incrementar sus objetivos, especificaciones o requerimientos, lo pueda hacer sin ningún problema. Pues básicamente el sistema debe ser flexible para todo lo que pueda surgir en el proceso. De este forma, no solamente llegaremos al éxito, si no que el cliente quedará totalmente satisfecho con el trabajo desarrollado, pues no tuvo que conformarse con lo primero que se le vino a la mente, si no que se actualizó con las ideas que en la marcha fueron surgiendo.

¿Cuáles son las Principales Metodologías Ágiles?

Algo que debes saber antes de dar paso a la descripción de cada una de las metodologías de la programación ágiles, es que aunque entre sus creadores crearon lo que fue el manifiesto ágil, la realidad es que cada una de las metodologías cuenta con su propia personalidad y características únicas, que la diferencian de las demás. Por eso a continuación, veremos cada una de las metodologías ágiles más populares, para que tengas un conocimiento más sólido de lo que son y hacia dónde van cada una de ellas.

Metodología Scrum.

Para que tengas una idea rápida, para que un proyecto ingrese al marco de lo que es el modelo Scrum, debe contar con las siguientes características:

• Desarrollo Incremental. Una metodología ágil sin desarrollo incremental, no puede ser considerada Scrum. Con incremental hago énfasis a olvidarnos de la planeación y de la ejecución de las líneas sin salirnos de lo pre establecido, pues con una metodología Scrum, el desarrollo se irá incrementando poco a poco, sin importar el orden en el cual se lleven a cabo los procesos.

• Calidad de las personas. Básicamente la calidad de un producto, no será analizada en base a la calidad de cada uno de los procesos llevados a cabo. Al contrario, la calidad dependerá de las personas, la auto organización y el conocimiento de los equipos de trabajo.

• Adiós al Secuencial y Cascada. Aquí en el modelo Scrum, hay algo a lo que se le denomina, solapamiento. Esto consiste en que no importa en qué proceso te encuentres, si un proceso necesita ser trabajado, vuelves a el para realizar lo que tienes que hacer, a diferencia de las metodologías cascada o secuencial, donde no había vuelta atrás. Acá afortunadamente no hay ningún problema con eso y la ventaja es que se ahorran tiempos.

• La comunicación es Fundamental. Una de las cosas que se realizan, son los equipos de trabajo, sin embargo acá la ventaja que tendrás es que podrás estar en constante comunicación con los otros equipos de trabajo, nadie está envuelto en su propia burbuja y toda la información que se maneje o lleve a cabo, será comunicada sin problema.

¿Cómo funcionan los Procesos Scrum?

La metodología Scrum, es bastante amigable y fomenta lo que es el trabajo en equipo en todo momento, con la finalidad de conseguir los objetivos de una forma rápida. Veamos ahora cuales son los procesos con los cuales funciona la metodología, empezando por el Product Backlog, el cual nos permitirá llegar a los Sprints, a continuación te explicaré de que te estoy hablando.

• Product Backlog. El Product Backlog no es más que una lista de las funcionalidades del producto a desarrollar. Este debe ser elaborado por el Product Owner, puesto que más adelante les explicaré. Sin embargo no se trata de una lista cualquiera hecha con escritos y nada más. El Product Backlog debe estar ordenado de acuerdo a las prioridades del sistema de más a menos, con la idea de que las cosas con mayor prioridad sean las que se realicen antes de cualquier cosa. De forma concreta, digamos que el objetivo base del Product Owner, es que nos de respuesta a la pregunta "¿Qué hay que hacer?".

• Sprint Backlog. Una vez que ya contamos con el Product Backlog terminado, entonces aparecerá el primer Sprint Backlog. Pero ¿Qué es el Sprint Backlog? Consiste básicamente en seleccionar algunos de los puntos escritos en el Product Backlog, los cuales procederán a ser realizados. Sin embargo en este punto el Sprint Backlog tiene como requisito marcar el tiempo en que se llevará a cabo el Sprint.

• Sprint Planning Meeting. Antes de iniciar un Sprint, el cual es la fase de desarrollo, se realiza lo que es un Sprint Planning Meeting. En este proceso del Scrum, es una reunión que se realiza para definir plazos y procesos a efectuarse para el proyecto establecido en el Product Backlog. Algo importante que debes saber, es que cada Sprint, se compone de diversos features, que no son otra cosa más que procesos o subprocesos que se deben realizar, puede ser la creación de un logo, la gestión de contenido, el diseño visual, etc. Todo dependerá del proceso que se desee llevar a cabo.

• Daily Scrum o Stand-up Meeting. Cuando un Sprint está en proceso, después de haber hecho la planeación del proyecto mediante plazos y procesos, entonces entramos a lo que son los Daily Scrum o Stand-up Meeting. Aquí básicamente lo que se hace son reuniones diarias mientras se está llevando a cabo un Sprint, para responder las siguientes preguntas: ¿Que hice ayer?, ¿Qué voy a hacer hoy, ¿Qué ayuda necesito?. Aquí entra en función el Scrum Master, un puesto que igual más adelante les explicaré. Pero el será el encargado de determinar la solución de los problemas y cada complicación que suceda.

• Sprint Review. El Sprint Review, es básicamente una reseña de lo que fue el Sprint. Consiste específicamente en la revisión del Sprint terminado y para este punto ya tendría que haber algo que mostrarle al cliente, algo realmente visual o tangible para que se pueda analizar un cierto avance.

• Sprint Retrospective. Para concluir, el Sprint Retrospective, permite al equipo analizar los objetivos cumplidos, si se cometieron errores, visualizarlos y tratar de no cometerlos nuevamente más adelante. Básicamente también sirve este proceso para lo que son la implementación de mejoras.

Equipos que Componen los Procesos Scrum.

Durante el punto anterior, te describí los procesos que se llevan a cabo en la Scrum Metodología, y en varios puntos mencioné ciertos equipos que son encargados de algunos aspectos importantes. Por eso a continuación veremos cuales son los equipos que conforman la metodología Scrum y con los cuales se trabajará arduamente, obvio, cada quien con sus respectivas responsabilidades.

• Product Owner. Si se trata de tener un líder de proyecto, entonces el Product Owner lo será. Básicamente son los ojos del cliente, será la persona encargada del proyecto y de visorear que se lleve a cabo de tal forma que cumpla las expectativas de lo que se espera.

• Scrum Master. Ahora bien, para cada reunión realizada, siempre debe estar un líder, en este caso el Scrum Master será el lider de cada una de las reuniones y ayudará en los problemas que hayan surgido. Será básicamente como un "facilitador" el cual minimizará obstáculos, sin embargo no los omitirá. En realidad el Scrum Master debe ser una persona empapada de conocimientos sobre el lenguaje o lenguajes bajo los cuales se llevará a cabo el proyecto, de lo contrario no tendría como ayudar a solucionar problemas.

• Scrum Team. Básicamente es el núcleo de la metodología Scrum, pues es el equipo de desarrollo, encargado de lo que es la codificación del software y de cumplir los objetivos o metas propuestas por el Product Owner.

• Cliente. Aunque no lo creas, el cliente también forma parte del equipo, hablamos de eso hace un rato, cuando comenté que no es como en las metodologías tradicionales donde al cliente se le pedían requerimientos y se le daba un costo total. En la metodología Scrum, el cliente tiene la capacidad para influir en el proceso, debido a que siempre estará empapado de el, ya sea que proponga nuevas ideas o bien haciendo algún tipo de comentario.

Metodología Kanban.

Siguiendo con las metodologías ágiles, nos encontramos con Kanban. Se trata de una metodología Japonesa, la cual consiste en ir etiquetando con tarjetas cada uno de los procesos que se deben llevar a cabo, también se le ha denominado como "Un sistema de producción de alta efectividad y productividad". De hecho, empresas como la marca de autos Toyota, fueron una de las primeras en implementarla para acelerar los procesos de producción.

La palabra Kanban, en Japonés significa "tarjetas visuales" y es precisamente lo que se maneja en ella. Algunos la trabajan con lo que son tarjetas virtuales o bien simulando que se pueden ver las tarjetas, sin embargo una forma correcta de hacerlo es con tarjetas físicas, que el equipo pueda ver y sentir para tener mayor efectividad.

Una de las principales ventajas de Kanban, es que además de ser una metodología Ágil, también es muy fácil de usar e implementar, sobretodo porque el equipo de trabajo se unirá y empezarán a trabajar a la par en diferentes aspectos del desarrollo. Veamos ahora, cuales son los principios básicos de la metodología Kanban.

Principios Básicos de Kanban.

• Garantía de Calidad. Algo por lo que destaca Kanban, es que el ser una metodología ágil, no es sinónimo de trabajar a las carreras o de hacer todo de golpe. Kanban promueve la calidad antes que la velocidad, es decir, un producto bien hecho desde la primera vez que se elaboro es más rápido, que un producto mal hecho al cual se le tienen que volver a meter las manos para arreglarlo. Entendiendo esto, concluimos con que todo debe salir bien desde el inicio y no debe haber margen de error.

• Desperdicios. Basado en lo que es el principio YAGNI, la metodología kanban trabaja de una forma en la cual, solamente se debe hacer lo necesario y requerido para que el sistema o el desarrollo quede bien. Evitando todo aquello que es considerado como extra, superficial o innecesario. De este modo no solamente se ofrece una mayor calidad en el producto, si no que además se optimizan tiempos y costos.

• Mejora Continua. Algo interesante de la metodología Kanban, es que no solamente de trata de un sistema diseñado para el proceso de desarrollo de Software, se puede implementar en el desarrollo de cualquier tipo de producto, tal y como lo hizo Toyota. Además es un sistema que nos da la oportunidad de ir mejorando constantemente en los procesos, dependiendo claro de cual sea el objetivo o la meta final.

• Es Flexible. Aquí es donde volvemos a hacer comparaciones con las metodologías de antaño, donde la flexibilidad no existía, como si fueran metodologías del abuelo estricto, acá eso no existe. La flexibilidad es uno de los principios de Kanban y ¿qué obtenemos con ello?. Gracias a que es flexible, podemos adelantarnos a un proceso que queramos hacer o que tenga cierto nivel de prioridad, no necesitamos seguir una linea de trabajo, lo cual hace de kanban una metodología más dinámica y además permite resolver problemas que surjan de imprevisto, algo que con otras metodologías simplemente ni se considera.

¿Cómo configurar una estrategia Kanban?

Realmente una de las cosas que diferencian a Kanban del resto, es que acá vas a necesitar un tablero de verdad. No es nada extraño ni loco, con el avance de los días de trabajo notarás que fue una magnífica idea comprar ese tablero y los post-it para escribir objetivos. Así que vamos a ver los pasos para realizar bien la configuración de una metodología Kanban.

1. Definir el Flujo de Trabajo. Una vez que ya tienes el tablero que es requisito para esta metodología, es entonces cuando podrás empezar a seccionarlo dependiendo del número de tareas, fases o proyectos que tengas en puerta. Considera que el tablero debe estar a la vista de todo el equipo de trabajo, pues será necesario estar al pendiente de los procesos y de ir actualizándolos conforme se vaya avanzando en el. Ahora si que como te comentaba, un tablero puede ser destinado para un solo proyecto o bien para muchos proyectos, todo dependerá de si deseas mantener el flujo de trabajo constante o medianamente pausado.

2. Fases del Ciclo de Producción. Es importante que te des cuenta, de como debes seccionar el tablero para ir marcando el flujo de producción. En este caso es realmente necesario que los procesos sean divididos en pequeños segmentos, para que se pueda agilizar y no se quede estancado en uno con demasiada duración. Es por eso que en los post-it que vayas colocando con cada proceso, deberá ser colocado el número de horas requeridas para completarlo, al finalizar las horas se determinará el porque no se ha terminado o bien ya se habrá avanzado a otra fase.

3. Stop Starting, start finishing. La filosofía de Kanban, trabaja de esta forma, no te voy a envolver en términos que te puedan confundir pues la idea es obvia: "No se empieza una nueva tarea, hasta terminar la otra". Esto se debe principalmente a que la idea es tener un alto porcentaje de tareas completadas y no como ciertos equipos de desarrollo que tienen una gran cantidad de proyectos en puerta y muchas tareas por hacer, la mayoría empezadas, pero ninguna terminada. Esta es la situación principal que se trata de evitar con Kanban y es que aunque parezca muy obvia, la realidad es que muchos la pasan de largo, aun cuando es fundamental.

4. Tener un Control. Algo con lo que trabaja Kanban, es con el control del flujo de trabajo. Si bien la idea es que los trabajadores tengan actividad realmente constante y no se detengan aun cuando terminen sus tareas. Kanban permite llevar un control de todo gracias a las notas que se van colocando. De esta forma además permite que se ejecuten varios proyectos se forma simultánea, una parte del equipo pudo haber terminado sus tareas del proyecto anterior y avanzar al siguiente, mientras los demás siguen todavía trabajando en ello. La idea es no provocar interrupciones a cada momento, además de que si necesitas un control, puedes ir almacenando las tarjetas y listo.

Metodología XP.

Si hablamos de metodologías de la programación sin mencionar a la Metodología XP, es como no hablar de nada en absoluto. Esta metodología es posiblemente la más destacada de las metodologías ágiles y esto se debe a su gran capacidad de adaptación ante cualquier tipo de imprevisto que surja. Pues la idea no es mantener ciertos requisitos desde que se está elaborando el proyecto, sino que durante el proceso, estos vayan cambiando o vayan evolucionando gradualmente sin complicaciones. Básicamente los creadores de esta metodología XP, consideran que es mejor adaptarte en el proceso a los requisitos que vayan apareciendo, que iniciar con requisitos y desarrollar un proyecto en base a eso.

Si queremos ver la metodología con otra perspectiva, se podría decir que la metodología XP o metodología de programación extrema, como también se le conoce. Es la combinación de las demás metodologías, solamente que se van utilizando de acuerdo a como sea necesario, por eso es considerada como la más destacada de las metodologías ágiles. Así que es momento de entrar en detalles y vamos a ver cuáles son los valores que conforman a la metodología de programación XP.

Valores de la Metodología XP.

Como toda metodología, la programación extrema cuenta con algunos valores que son fundamentales para que se lleve a cabo como debe ser. En algunas otras metodologías estos puntos los conocíamos como principios básicos, es realmente lo mismo solo que acá los mencionan como valores, veamos cuales son.

• Comunicación. Del mismo modo que otras metodologías como la Scrum, el cliente tiene una gran intervención, pero obviamente la comunicación dependerá de más factores. Por ejemplo. El código fuente de los programadores debe transmitir esa comunicación a todo el equipo, por eso las variables amigables. De igual forma, se deben documentar las cosas más relevantes, independientemente de que sean comentadas en el código, pero es importante tener un documento extra para explicaciones extensas, de lo contrario el código se verá infestado de escrito. En cuando a la comunicación entre personas, los programadores se comunican constantemente ya que trabajan en parejas, la comunicación que se tiene con el cliente debe ser constante, pues recordemos que incluso el forma parte del equipo de trabajo y es responsabilidad del cliente, comunicarnos algunas actualizaciones que requiera en el proceso, nuevas ideas, soluciones a problemas o sencillamente algún problema que el vea. Todo debe ser comunicado, esta parte es realmente fundamental para el desarrollo de un producto exitoso.

• Simplicidad. El primero de los valores de la metodología de programación XP, es la simplicidad. Ya te haz de imaginar en que consiste, puesto que la idea es que el desarrollo sea veloz, por lo cual todas las cuestiones de diseño se simplifican al máximo, lo mismo sucede con las líneas de código, si se pueden simplificar, se hacen, además de que regularmente el mismo código es donde va la documentación comentada, de esta forma nos evitamos el estar haciendo documentación extra. Por esta razón, además es importante que en el ciclo de desarrollo de software mediante la metodología XP, las variables, métodos y clases, tengan nombres amigables y relacionados, de este modo no solamente se ayuda el equipo de trabajo, el cual de por sí ya se debe conformar de dos personas por equipo, sino que además, cuando una persona nueva ingrese al proyecto, será muy rápida su adaptación.

• Retroalimentación. El hecho de que el cliente se encuentre involucrado en el proyecto, ayudará inicialmente con la retroalimentación. Pues conforme pasan los días y se va analizando el código por pequeñas etapas, el cliente puede ir corrigiendo, agregando, quitando o excluyendo algunas cosas, esa es la ventaja de la programación por periodos cortos de tiempo, es decir, imagina que llevas varios meses desarrollando el proyecto y cuando vas con el cliente, el proyecto no le gusta y desea hacer tantos cambios que te llevará una eternidad. Precisamente eso es lo que se trata de evitar con la metodología XP, que se tiren varios meses de trabajo a la basura y mejor se vaya optimizando en pequeños lapsos de tiempo. Otra de las formas de retroalimentación con la cual contamos, es nuestro código fuente. Pues gracias a que podemos realizar diversas pruebas unitarias, podremos ver la salud de nuestro código, una gran ventaja, pues si hay problemas o errores, siempre estaremos a tiempo de realizar modificaciones y soluciones. A diferencia de un proyecto sumamente extenso, donde seguramente la cantidad de errores será tan impresionante que volver a empezar podrá ser una opción.

• Valentía. Hay elementos donde el coraje o la valentía de los programadores serán fundamentales. Por ejemplo el dar solución a los problemas frente a los cuales se enfrente. El pasar por la eliminación de código fuente en el programa desarrollado, aun cuando todo ese código haya tomado una gran cantidad de tiempo en hacerse o que tal el hecho de diseñar para hoy y no para mañana. Muchos lo hacen con esa idea en ocasiones, pero con un poco de valentía y coraje que forman parte de los valores de la metodología, seguramente el éxito llegará de manera anticipada.

• Respeto. Originalmente, este quinto valor no se encontraba en la metodología XP, sin embargo es importante mencionarlo pues hoy en día ya lo conforma. El respeto es importante para que haya una buena comunión entre los programadores del equipo. Nunca hay que denigrar a nadie ni agregar o ofender, pues un autoestima alta en el equipo garantizará un trabajo mucho más eficiente. Por esta razón, cosas como el código fuente, las modificaciones, los fallos obtenidos, los problemas o la solución de problemas, son procesos que se deben respetar para que el ambiente de trabajo también sea óptimo.

Características que componen la metodología XP.

Ya vimos los valores o principios básicos, dejémoslo en valores pues así es como lo denomina la metodología, sin embargo ahora vamos a ver sus características, de esta forma te podrás dar una mejor idea de cómo funciona una metodología XP.

• Tipo de Desarrollo Iterativo e incremental. Como hemos visto en lo que llevamos hablando de la metodología XP, el método está basado en lo que son las mejoras continuas, a base de iteraciones y por supuesto un desarrollo incremental al estilo espiral.

• Pruebas Unitarias. Una de las características además son las pruebas unitarias. Se utiliza software de codificación eso sí, dependiendo del lenguaje que estemos usando es la herramienta que nos corresponde, pero de este modo se analiza el código y solucionan errores, antes de validarlo y darlo por bueno.

• Trabajo en Equipo. Más específico todavía, es el trabajo en parejas, el objetivo es que el enfoque en parejas sea mayor, las distracciones son menores y el aprendizaje del uno con el otro permite que el avance del proyecto sea mucho más eficiente que cuando una persona es la encargada.

• Alguien del equipo trabaja con el cliente. Es fundamental que el cliente intervenga en el desarrollo, pero obviamente el no estará en la sala de desarrollo, se debe asignar a una persona que sea le encargada de tener las reuniones con el cliente de forma constante. El será quien comunique al equipo los cambios o el seguimiento del proyecto.

• Corrección de Errores. Algo importante, el hecho de que la metodología XP sea realmente rápida para el desarrollo, no significa que se pasen por alto los errores, de hecho primero se le tiene que dar corrección a los errores antes de seguir avanzando en el proyecto.

• Reetructuración del Código. La idea es clara una refacturación del código siempre se debe realizar. Con esto lo que haremos es simplificar el código pero no las funciones. Pues regularmente cuando desarrollamos, agregamos algunas cosas que pueden ser innecesarias y que no afectan en el funcionamiento del sistema, estas son precisamente las que hay que refacturar.

• El Código es de todos. Realmente aunque se trabaje en equipos, al final todos tendrán la posibilidad de ver el código, proponer cambios o incluso hacerlos. La idea es que si uno no detecta un error, otro lo podrá hacer, por eso el código fuente es compartido entre todos.

• Código simple es la clave. Algo importante con la metodología extrema, es que la simplicidad siempre llevará la ventaja. Principalmente porque cuando se requiera hacer un cambio, si el código fuente es muy complejo, posiblemente lleve muchas horas realizar los cambios e incluso una alternativa seria ya no hacer ningún cambio para no perder tiempo. Esta es precisamente la razón por la cual el código simple, es fundamental en la metodología.

Básicamente, lo que es la simplicidad y la comunicación van de la mano. Puesto que a mayor simplicidad, la comunicación necesaria será menor. Haciendo que la eficiencia se incremente y la pérdida de tiempo en comunicación sea menor. Por eso es importante seguir al pie de la letra estas dos ideales de la metodología.

Equipo de Trabajo dentro de una Metodología XP.

Ya para concluir con esta metodología, recordemos que es una de las mejores que podrían existir y que realmente vale la pena implementar. Veamos cuales son los roles que componen el equipo de trabajo en un proyecto que se elaborará mediante la metodología XP, para que tengas una idea de la formación que se debe efectuar.

• Programador. Realmente no creo que sea necesario que te diga lo que hace el programador. Bueno, es el encargado del código del sistema y además de hacer las pruebas unitarias que se solicitan.

• Tester. Básicamente es el encargado de las pruebas del desarrollo. Lo que se vaya implementando, el teste lo prueba y le dice al cliente o mejor dicho, le comunica al cliente las pruebas funcionales, para posteriormente comunicarle al equipo los resultados.

• Tracker. El seguimiento será lo suyo. Será el encargado de realizar las comparaciones entre los tiempos estimados antes de empezar un desarrollo y los tiempos reales que se obtuvieron. Tratando siempre de mantener al tanto al equipo para que traten de mejorar los tiempos.

• Entrenador. Este elemento es realmente importante, puesto que es el responsable del proyecto básicamente y precisamente hace las funciones de un entrenador. Se encarga de guiar al equipo por el camino que deben seguir.

• Consultor. Regularmente el consultor no formaba parte del equipo, bueno de hecho no lo integra. El consultor sigue siendo un externo, pero que cuenta con conocimientos específicos y que será capaz de ayudar en la solución de problemas.

• Gestor. Posiblemente el líder más alto. Si se trata de unir a los clientes con los programadores, el gestor es el intermedio, es decir. Es el encargado de vincular e interrelacionar al cliente con los programadores.

Archivo adjunto de metodología del desarrollo de software.

Actividad 1.- Se sugiere un mapa conceptual.

Metodología estructurada, RAD Y agiles.

Metodología Estructurada.

Existen muchas definiciones sobre lo que es una metodología, todas ellas coinciden en que debería tener al menos las siguientes características:

•Define como se divide un proyecto en fases y las tareas a realizar en cada una.

•Para cada una de las fases está especificado cuales son las entradas que reciben y las salidas que producen.

•Tienen alguna forma de gestionar el proyecto.

Una metodología es un conjunto integrado de técnicas y métodos que permite abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Una definición estándar de metodología puede ser el conjunto de métodos que se utilizan en una determinada actividad con el fin de formalizarla y optimizarla. Determina los pasos a seguir y cómo realizarlos para finalizar una tarea.

RAD.

La metodología de desarrollo conocida como diseño rápido de aplicaciones RAD (rapid application development) ha tomado gran auge debido a la necesidad que tienen las instituciones de crear aplicaciones funcionales en un plazo de tiempo corto. RAD es un ciclo de desarrollo diseñado para crear aplicaciones de computadoras de alta calidad. El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas son Visual Studio, Lazarus, Gambas, Delphi, Foxpro, Anjuta, Game Maker, Velneo o Clarion. En el área de la autoría multimedia, software como Neosoft Neoboo y MediaChance Multimedia Builder proveen plataformas de desarrollo rápido de aplicaciones, dentro de ciertos límites.

Fases del RAD.

• 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 procesó?
• Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
• Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
• Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. 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 (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
• Pruebas de entrega: Como el proceso DRA enfatiza 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.

Características de RAD:

Equipos Híbridos:

• Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema así como aquellas personas involucradas con los requisitos.
• Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y programadores en uno.

Herramientas Especializadas:

• Desarrollo "visual"
• Creación de prototipos falsos (simulación pura)
• Creación de prototipos funcionales.
• Múltiples lenguajes.
• Calendario grupal.
• Herramientas colaborativas y de trabajo en equipo.
• Componentes reusables.
• Interfaces estándares (API)

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.

METODOLOGIAS AGILES.

INTRODUCCION En las dos últimas décadas las notaciones de modelado y posteriormente las herramientas pretendieron ser la clave para el éxito en el desarrollo de software, no obstante, las expectativas no fueron satisfechas del todo. Esto se debe en gran parte a que otro importante elemento, la metodología de desarrollo, había sido postergado. De nada sirven buenas notaciones y herramientas si no se proveen directivas eficientes para su aplicación.

La metodología necesariamente ha de ser ágil, debe tener un ciclo corto de desarrollo y debe incrementar las funcionalidades en cada iteración del mismo preservando las existentes, ayudando al negocio en lugar de darle la espalda. Es para este entorno para el que han nacido las metodologías ágiles y como consecuencia se creó el Manifiesto Ágil.

El Manifiesto Ágil describe, básicamente, cuales son los principios sobre los que se basan los métodos reconocidos como ágiles.

Éste manifiesto sugiere un enfoque orientado a la participación de los usuarios y clientes, más que hacia los procesos y herramientas, trabajando más en el software y menos en la documentación, colaborando más con los clientes en vez de estar negociando y respondiendo a los cambios sacrificando el plan de trabajo si es necesario.

En el "Manifiesto ágil" se definen los cuatro valores principales por las que se deberían guiar las metodologías ágiles.

1. Al individuo y sus interacciones más que al proceso y las herramientas.

2. Desarrollar software que funciona más que obtener una documentación exhaustiva.

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

4. Responder a los cambios más que seguir una planificación.

El significado de cada uno de estos valores son los siguientes:

• Al individuo y sus interacciones más que al proceso y las herramientas.

Sin duda, la herramienta fundamental de la ingeniería del software y del desarrollo de aplicaciones es el cerebro humano y nuestra capacidad para desarrollar y desenvolvernos con nuestro entorno. Una persona sola no realiza un proyecto, necesita de un entorno en el que desarrollar su trabajo y de un equipo con el que colaborar. Estas interacciones deben también cuidarse. Un factor clave para el éxito es construir un buen equipo, que se lleven bien entre ellos, y que además sepan cómo construir su propio entorno de desarrollo. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte a él. Esto nos resta eficiencia, es mejor que el equipo se configure sobre la base de sus necesidades y sus características personales. Además, las interacciones que haga el equipo con el usuario final deberían ser igual de fluidas siendo este usuario un miembro más del equipo, con un objetivo común, que es conseguir que el proyecto funcione y sea útil para él. Si todo esto funciona bien, la elección de las herramientas y el proceso mismo de desarrollo pasan a estar en un plano totalmente secundario en la ecuación del éxito del proyecto.

• Desarrollar software que funciona más que obtener una documentación exhaustiva.

Uno de los objetivos de una buena documentación es poder ir a consultarla cuando haya que modificar algo del sistema o surja alguna incertidumbre. Sin duda es un arma de doble filo, una buena documentación actualizada en cada modificación y bien mantenida al día permite saber el estado de la aplicación y cómo realizar las modificaciones pertinentes, pero son pocos los que con las presiones externas de tiempo y dinero acaban actualizando la documentación. Generalmente, cuando se tiene que arreglar un programa porque algo falla o surge un cambio de alcance, nos concentramos en que funcione ya que es muy posible que haya usuarios parados y que la empresa o la organización esté perdiendo dinero, en estos casos, ni nos paramos a mirar detenidamente la documentación ni, cuando se acaba de arreglar, nos ponemos a actualizarla. En la filosofía ágil, lo primordial es evitar estos fallos, centrar nuestro tiempo en asegurar que el software funciona y que se ha testeado exhaustivamente, e intentar reducir la creación de documentos poco útiles, de éstos que acaban no manteniéndose y ni siquiera consultándose. La regla no escrita es no producir documentos superfluos, y sólo producir aquellos que sean necesarios de forma inmediata para tomar una decisión importante durante el proceso de desarrollo. Estos documentos deben ser cortos y centrarse en lo fundamental, olvidándonos de las ambigüedades que no aportan nada a la comprensión del problema. No obstante, los documentos son soporte de documentación, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan.

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

La consultoría informática de los últimos años se ha convertido en una lucha a muerte entre el proveedor del servicio y el cliente que lo contrata. Por una parte, el cliente intenta que se hagan el mayor número de funcionalidades con el mismo dinero, por otra parte, el consultor intenta que por ese dinero sólo se realicen las funcionalidades contratadas inicialmente. En las reuniones de seguimiento de los proyectos es fácil oír frases del tipo "esta modificación no entra en el contrato" respondida generalmente por la tan típica "pues yo ya no tengo más presupuesto y así no podemos trabajar". Al final, este tipo de proyectos hacen que el consultor informático sea un híbrido entre analista y abogado, que desarrolla habilidades legales para salvaguardarse en caso de conflicto jurídico. Sin embargo, para que un proyecto tenga éxito es fundamental la complicidad y el contacto continuo entre el cliente y el equipo de desarrollo. El cliente debe ser y sentirse parte del equipo. De esta manera, ambos entenderán las dificultades del otro y trabajarán de forma conjunta para solucionarlo.

4. Responder a los cambios más que seguir una planificación. Una organización cambia constantemente, se adapta a las necesidades del mercado y reorganiza sus flujos de trabajo para ser más eficiente. Es difícil, pues, que en el desarrollo de un proyecto, éste no sufra ningún cambio, ya que es seguro que las necesidades de información de la empresa habrán cambiado. Y no sólo esto, sino que las posibilidades económicas de la misma pueden influir sobre nuestro proyecto, bien sea agrandándolo o reduciéndolo. Son muchos los factores que alterarán nuestra planificación inicial del proyecto.

Si no la adaptamos a estos cambios, corremos el riesgo de que, cuando acabemos, nuestro sistema no cumpla con las necesidades pre-establecidas y el cliente se haya gastado el dinero en vano. La habilidad de responder a los cambios de requisitos, de tecnología, presupuestarios o de estrategia, marcan sin duda el camino del éxito del proyecto. Como consecuencia de estos cuatro valores, el Manifiesto ágil también enuncia los doce principios que caracterizan un proceso ágil diferenciándolo de otro tradicional donde este enfoque no se había aplicado lo suficiente, siempre se había dejado implícito pero sin hacer hincapié en ellos.

a) La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.

b) Dar la bienvenida a los cambios incluso al final del desarrollo. Los cambios le darán una ventaja competitiva a nuestro cliente.

c) Hacer entregas frecuentes de software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

d) Las personas del negocio y los desarrolladores deben trabajar juntos diariamente a lo largo de todo el proyecto.

e) Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos.

f) El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.

g) El software que funciona es la principal medida del progreso.

h) Los procesos ágiles promueven un desarrollo sostenido. Los promotores, usuarios y desarrolladores deben poder mantener un ritmo de trabajo constante de forma indefinida.

i) La atención continua a la calidad técnica y al buen diseño mejoran la agilidad.

j) La simplicidad es esencial. Se ha de saber maximizar el trabajo que no se debe realizar.

k) Las mejores arquitecturas, requisitos y diseños surgen de los equipos que se han organizado ellos mismos.

l) En intervalos regulares, el equipo debe reflexionar con respecto a cómo llegar a ser más efectivo, y ajustar su comportamiento para conseguirlo.

Llegados a este punto, podemos intuir que las formas de hacer las cosas en la ingeniería del software están cambiando, adaptándose más a las personas y a las organizaciones en las que han de funcionar las aplicaciones. Las metodologías ágiles no son la gran solución a todos los problemas del desarrollo de aplicaciones, ni tan siquiera se pueden aplicar en todos los casos, pero sí que nos aportan otro punto de vista de cómo se pueden llegar a hacer las cosas, de forma más rápida, más adaptable y sin tener que perder la rigurosidad de las metodologías clásicas.

BENEFICIOS.

Durante la década pasada, las metodologías ágiles demostraron ser muy beneficiosas ayudando a los equipos de desarrollo de software a la hora de entregar en fecha software de alta calidad que compensara las necesidades de los clientes. Los equipos de software quieren trabajar con metodologías ágiles porque necesitan un proceso que pueda responder de manera eficiente a los cambios en los productos en desarrollo. Las metodologías ágiles permiten una mayor flexibilidad que las metodologías tradicionales de desarrollo, ya que éstas se bloquean y ralentizan en los detalles del proyecto y son menos capaces de ajustarse a las cambiantes necesidades de los clientes, del mercado y de los desafíos imprevistos que plantea la tecnología y el medio ambiente. Algunos de los beneficios son los siguientes:

• Simplificación de la sobrecarga de procesos Los equipos que trabajan para crear productos regulados por estándares de la industria, deben demostrar el cumplimiento de esas normas. Estos equipos suelen adoptar importantes sobrecargas de trabajo para asegurarse de que cumplen con los estrictos mandatos de código. Las metodologías ágiles pueden ayudarles a cumplir los estándares de la industria con menos sobrecarga utilizando iteraciones más cortas y empaquetadas. El beneficio neto es un proceso que:
• Puede adaptarse a los cambios que, inevitablemente,
• Requiere menos sobrecarga en el proceso end-to-end
• Implica menos trabajo a medida que se acerca la fecha final 2.

2.- Calidad mejorada.

Las prácticas de desarrollo ágil proporcionan la funcionalidad suficiente como para satisfacer las expectativas de los clientes con una alta calidad. Eso es, proporcionar la mínima funcionalidad con la máxima calidad. La mínima funcionalidad no implica necesariamente una pobre funcionalidad, sino que implica lo suficiente como para conseguir que el trabajo se realice. Los clientes suelen pensar que saben lo que quieren cuando especifican altos niveles de requerimientos para un producto de software. Sin embargo, la mayoría de las veces, cuando ven el producto final, éste no resuelve el problema. Simplemente, no se han imaginado de forma precisa el mismo, o el problema ha cambiado o, incluso, la tecnología no era tan buena como parecía. También puede ser que el producto no funcione realmente del modo en que las partes interesadas tenían intención, incluso aunque pensaran que habían descrito los requerimientos de manera clara. Desarrollar iteraciones en poco tiempo y demostrar a los clientes los productos pronto y con frecuencia, permite tanto a los clientes como a los equipos de desarrollo ponerse de acuerdo y coincidir en que el producto cumple con cada una de sus necesidades.

3.- Mejorar la previsibilidad a través de una mejor gestión del riesgo.

Cuando los equipos de desarrollo no cumplen con sus fechas de lanzamiento, a menudo se debe a muchas razones completamente justificables. Puede ser que el equipo no hubiera entendido bien lo complejo que sería utilizar la nueva tecnología, los requerimientos podían no estar del todo claros o los clientes cambiaron de opinión cuando el trabajo estaba prácticamente finalizado. En cualquier caso, los negocios demandan productos que cumplan con las fechas de entrega, de modo que los planes de negocio directamente relacionados con ellos puedan cumplirse. Hay muchas formas en las que las metodologías ágiles pueden ayudar a que los proyectos cumplan con las fechas de lanzamiento previstas. Dar prioridad a los riegos. Las prácticas ágiles priorizan los aspectos de desarrollo de alto riesgo permitiendo así una reducción de los riesgos iniciales. Evaluación de riesgos en paralelo. Para áreas de riesgo donde debería haber múltiples soluciones y el equipo no se pone de acuerdo a la hora de tomar el camino más adecuado, se debe tener en cuenta la posibilidad de optar por el desarrollo multi-set. Esto requiere que diferentes equipos trabajen en paralelo resolviendo el mismo problema con diferentes soluciones. La mayoría de los equipos no considerarán ni tan siquiera esta forma de trabajar, porque están convencidos de que el tiempo y el coste requeridos para hacer una evaluación paralela son demasiado grandes. De hecho, el desarrollo paralelo de alternativas es probable que traiga consigo las decisiones clave a seguir.

• Mejor perfil de productividad Los equipos ágiles son más productivos que aquellos que utilizan métodos tradicionales a lo largo de todo el ciclo de desarrollo. El desarrollo tradicional comienza con un ciclo de diseño de abajo arriba, moviéndose hasta una fase de prototipo para pasar luego a un ciclo de desarrollo largo, seguido por otro ciclo totalmente impredecible en el que se integran las piezas para pasar, por último, a la fase de prueba final. A medida que el proyecto progresa, los equipos tienen que trabajar juntos de manera más coherente, confiando en que todas las piezas trabajen juntas tal y como esperan. Pero lo cierto es que esto raramente ocurre, de modo que la interacción entre los equipos aumenta a medida que lo hacen los problemas de integración. Por último, la fase de pruebas lleva todo esto al límite. Trabajando juntos como un único equipo en fases verticales del producto desde el principio del ciclo de producción, se evita el ciclo de productividad tradicional. Los equipos ágiles tienden a ser muy productivos desde la primera iteración hasta su lanzamiento y su ritmo tiene que ser gestionado de modo que no se produzca agotamiento. Los equipos ágiles que mantienen este código de trabajo con cada iteración, permiten realizar pruebas de rendimiento y sistemas desde el principio, pudiendo empezar en las primeras iteraciones. De este modo, defectos críticos como problemas de integración se descubren antes, la calidad general del producto es mayor y el equipo funciona de manera más productiva durante todo el ciclo de desarrollo.
• Capacidad para aprovechar las inversiones realizadas.

Adoptar las técnicas ágiles de manera satisfactoria impone un importante soporte de herramientas. La mayoría de los equipos invierten fuertemente en buenas herramientas de software y necesitan elevar esa inversión y reducir la cantidad de cambios cuando empiezan a adoptar las metodologías ágiles. La inversión más crítica es una buena planificación y una herramienta de gestión del trabajo que proporcione una cartera de pedidos del equipo visible y que asocie el trabajo con cada elemento de trabajo en cartera. Idealmente, esa herramienta de planificación se integra con otras herramientas de desarrollo, lo que permite a los equipos mantener la trazabilidad de la cartera de pedidos en otros aspectos, incluyendo:

• Los requerimientos que la impulsan.
• La arquitectura bajo desarrollo.
• El software de la solución.
• Las pruebas que validan la solución.

Algunas de las herramientas más conocidas para la gestión y administración de proyectos ágiles son:

• Team Foundation Server (Microsoft)
• Rational (IBM)
• HP Quality Center (Hewlett Packard)
• Realimentación continua con el cliente.

De forma temprana el cliente recibe entregables de valor, lo que permite ver los constantes avances, logrando así, aportar en lo necesario para que el equipo vaya construyendo en la dirección correcta lo anterior, inmediatamente reduce de forma drástica los errores y la posibilidad de costosas correcciones, respondiendo a los cambios en requisitos de forma rápida y eficaz. El cliente es una parte más del equipo.

• Equipo motivado.

Cuando se realiza un proyecto aplicando alguna de las metodologías agiles, las personas involucradas en el mismo están más motivadas ya que pueden usar su creatividad para resolver problemas y cuando pueden decidir organizar su trabajo. Esto hace que las personas se sienten más satisfechas cuando pueden mostrar los logros que consiguen tomando sus propias decisiones.

Se adjunta toda la información de la metodología estructurada, RAD y Agiles.

Actividad 2 .- Se sugiere la siguiente actividad investigación.

Actividad 3 .- Se sugiere un cuadro comparativo sobre las metodologías de desarrollo de software.

           DESARROLLO DE SISTEMAS.

Para lograr la realización de un proyecto es muy importante que se lleven a cabo una serie de pasos y procedimientos de investigación, los cuales permitirán abrir aún más las perspectivas que tenemos de dicho proyecto. La ejecución clara y objetiva de estos procedimientos de investigación son las que nos permitirán obtener un enfoque claro de lo que deseamos obtener y como lo habremos de lograr.

El desarrollo de proyectos es una parte fundamental para toda empresa u organización que desea obtener éxito en las áreas que involucran un proyecto. Para llevar a cabo el desarrollo de un proyecto nos planteamos algunas preguntas: ¿existe un problema?, ¿Cuál es el problema?, ¿Cómo se realizan los procesos actuales?, etc. La aclaración de estos aspectos permitirá obtener una visión mas clara de los problemas que serán resueltos con la realización del proyecto.

Dados los antecedentes, al iniciar un proyecto es claro que se debe de conocer a fondo los pasos y procedimientos de investigación que requiere un proyecto.

El Desarrollo de Proyectos es una herramienta de una gran utilidad y es por esto que he decidido llevar a cabo una recopilación de los pasos que conlleva la realización de un proyecto.

Métodos y etapas del Desarrollo de Proyectos.

Pressman nos comenta que Meiler Page-Jones, en el prólogo de su libro sobre gestión del proyecto de software, hace una declaración a la que se sumarían muchos especialistas de la ingeniería de software:

He visitado docenas de empresas, buenas y malas, y he observado a numerosos gestores de proceso de datos, tanto buenos como malos. Muy frecuentemente, he visto con horros cómo estos gestores se peleaban inútilmente con proyectos terribles, intentaban cumplir plazos imposibles o entregaban sistemas que decepcionaban a sus usuarios y acababan dedicando gran cantidad de tiempo al mantenimiento.

Lo que describe Page-Jones son los síntomas que aparecen como resultado de una serie de problemas técnicos y de gestión. Sin embargo, si se emitiera un veredicto sobre cada proyecto, es muy probable que se encontrara un rasgo común: la gestión del proyecto fue débil.

Por la experiencia que he desarrollado en la implementación de sistemas de información esta aseveración de Pressman se debe de tomar muy en cuenta en cualquier tipo de implementación ya que si la gestión del proyecto es débil tendremos muchas probabilidades de no cumplir con las expectativas del proyecto.

Para realizar una gestión efectiva Pressman sugiere las siguientes etapas:

Métricas del Software.

Involucra la generación de mediciones y métricas para el proyecto para entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso se mide para intentar mejorarlo e intentar aumentar su calidad.

Estimación.

Una de las actividades cruciales del proceso de gestión de proyectos de software en donde se tienen que obtener estimaciones de esfuerzo humano requerido (normalmente en personas-mes), de la duración cronológica del proyecto (en fechas) y del costo (monetario).

Análisis de Riesgos.

El análisis de riesgos es algo vital para una buena gestión del proyecto, y sin embargo, a pesar de todo, se emprenden muchos proyectos sin que se hayan considerado los riesgos concretos.

El análisis de riesgos consiste realmente en una serie de pasos de control de los riesgos que nos permiten "combatirlos": identificación de riesgos, estrategias de control de riesgos, resolución de riesgos y supervisión de riesgos. Estos pasos se aplican a lo largo del proceso de ingeniería del software.

Planificación.

La planificación de un proyecto de software no difiere de la planificación de cualquier proyecto de ingeniería. Se identifica una serie de tareas del proyecto. Se establecen interdependencias entre las tareas. Se estima el esfuerzo asociado con cada tarea. Se hace la asignación de personal y de otros recursos. Se crea una "red de tareas". Se desarrolla una agenda de fechas.

Seguimiento y Control.

Una vez que se ha establecido la agenda de desarrollo, comienza la actividad de seguimiento y control. El gestor del proyecto sigue la pista a cada tarea establecida en la agenda. Si una tarea se sale de la agenda, el gestor puede utilizar una herramienta de planificación automática sobre el proyecto para determinar el impacto del error de planificación sobre los hitos intermedios y sobre la fecha final de entrega. En ese caso se pueden reasignar recursos, reordenar las tareas o (como último recurso) modificar los compromisos de entrega para resolver el problema no detectado. De este modo, se puede controlar mejor el desarrollo del software.

Etapas del Desarrollo de Proyectos.

Existen muchas metodologías de implementación de sistemas, para Avison y Fizgerald cualquier metodología debe de cubrir las siguientes etapas:

Detección de Necesidades.

Consiste en determinar que algún elemento (procesos, equipos, personas, etc.) no cumplen ya con los objetivos o metas, o bien, se requiere de uno no existente de acuerdo al nivel de importancia que manifieste la necesidad.

Definición del Problema.

Consiste en delimitar las fronteras y el alcance de las necesidades que se desean atender y sobre la cuales existen posibilidades de definir un proyecto.

Definición de Factibilidad.

Consiste en definir el nivel de factibilidad (posibilidades de éxito) para conseguir la solución de las necesidades. Se manejaran 4 niveles de factibilidad que servirán para determinar si un proyecto puede ser exitoso o no, estos niveles son:

• Operacional.
• Técnico.
• Económico.
• Calendarización.                                                                                                       Planeación del Proyecto.

Consiste en explicar como será la delimitación del problema, justificando el planteamiento de los objetivos desarrollados inicialmente. En esta etapa se definen los niveles o etapas del desarrollo del proyecto, además de las técnicas y el control que se llevará a cabo.

 Elaboración del Proyecto.

Consiste en definir el diseño, la elaboración de módulos y la integración de todos los elementos. Se deben de dar a conocer en esta etapa todos los distintos tipos de pruebas y técnicas de análisis de resultados para determinar una posible evaluación al final del proyecto. En el Capítulo III explicaré una metodología detallada para la implementación de proyectos de Planeación Financiera.

 Documentación.

Consiste en explicar como están compuestos los manuales técnicos y de usuario del proyecto.

Detección de Necesidades.

Elementos para identificar posibles proyectos.

Definición de Proyecto.

Es la integración de una serie de procedimientos y actividades haciendo uso de una metodología definida que permita lograr los objetivos y metas de la manera más eficiente y efectiva.

Motivos de un Proyecto.

Dentro de los motivos que generan el inicio de un proceso para el desarrollo de proyectos se encuentran principalmente elementos y factores que pueden ser externos e internos. Algunos de estos factores son los que se mencionan a continuación:

• Micromercados. Se refiere a la necesidad de atender a segmentos de usuarios muy específicos y donde se requieren de productos y servicios adecuados.
• Volatilidad Corporativa. Es la necesidad de llegar a acuerdos, uniones, alianzas o adquisiciones que modifican el estado de una empresa.
• Control de Costos. Se refiere a la presión por contener y reducir gastos.
• Consumismo. es la necesidad de reaccionar a la demanda y seleccionar a sus consumidores.
• Calidad. Se refiere al mejoramiento del producto final.
• Globalización. Se refiere a la necesidad de tener mayor cobertura.
• Regularizaciones. Se refiere a cambios dentro del ambiente provocados por acciones gubernamentales. Por ej. Las leyes y los impuestos.

Existen elementos muy claros para identificar posibles Proyectos, entre los principales podemos nombrar:

• Problemas con algún elemento actual. Errores, ineficiencias, retardos, deseos de algún incremento, reducción de gastos, etc.
• Deseos de explotar nuevas necesidades. Nuevos mercados, nueva producción, mas formas de obtener venta competitiva, uso de sistemas de información.
• Incremento de la competencia. Nuevas características en los competidores, mejorar un servicio o un producto.
• Hacer mas efectivo el uso de la información. Nueva información, mejor aprovechamiento, rapidez, mejores decisiones.
• Crecimiento organizacional. Crecimiento en las empresas, mas necesidades.
• Unión o adquisición corporativa. Consolidación de sistemas y procesos, requerimientos, reducir actividades redundantes.
• Cambios en el ambiente o en el mercado. Clientes, proveedores, leyes y regulaciones, clima.

Definición del Problema.

Creatividad e Innovación.

Una vez que se han detectado los posibles problemas existentes en una empresa u organización, debemos de definir las áreas sobre las cuales será planteada la solución para los requerimientos; esta solución debe de estar delimitada de acuerdo a los parámetros que proporcionen los problemas y no abarcar mas allá de los que indica una posible solución.

Esta etapa contempla 7 pasos que permitirán definir adecuadamente los alcances y fronteras de un proyecto, en estos pasos se permite establecer una guía de operación en el desarrollo del proyecto.

Los pasos son los siguientes:

• Determinar el alcance y los objetivos.
• Crear una visión.
• Adoptar una metodología en la planeación.
• Organizar y definir los recursos necesarios.
• Definir el equipo de trabajo.
• Preparar un plan de trabajo.
• Obtener o confirmar los requerimientos de acuerdo al plan desarrollado.

El desarrollo de proyectos no solo implica la solución de problemas, sino también consiste en definir la mejor solución posible tomando como base aspectos que sean considerados como únicos o específicos para la solución. Para estos procesos se considera importante la aplicación de la creatividad e innovación en la solución de los problemas.

Estudio de Factibilidad.

Determinación de la Factibilidad.

Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas señalados, la factibilidad se apoya en 3 aspectos básicos:

• Operativo.
• Técnico.
• Económico.

El éxito de un proyecto esta determinado por el grado de factibilidad que se presente en cada una de los tres aspectos anteriores.

Para esto se realiza un estudio de factibilidad que sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisión, si procede su estudio, desarrollo o implementación.

El objetivo de un estudio de factibilidad es auxiliar a una organización a lograr sus objetivos y cubrir la metas con los recursos actuales en las siguientes áreas.

• Factibilidad Técnica.
• Mejora del sistema actual.
• Disponibilidad de tecnología que satisfaga las necesidades.
• Factibilidad Económica.
• Tiempo del analista.
• Costo de estudio.
• Costo del tiempo del personal.
• Costo del tiempo.
• Costo del desarrollo / adquisición.
• Factibilidad Operativa.
• Operación garantizada.
• Uso garantizado.

La investigación de factibilidad es un proyecto que consiste en descubrir cuales son los objetivos de la organización, luego determinar si el proyecto es útil para que la empresa logre sus objetivos. La búsqueda de estos objetivos debe contemplar los recursos disponibles o aquellos que la empresa puede proporcionar, nunca deben definirse con recursos que la empresa no es capaz de dar.

En las empresas se cuenta con una serie de objetivos que determinan la posibilidad de factibilidad de un proyecto sin ser limitativos.

Presentación de un estudio de Factibilidad.

Un estudio de factibilidad requiere ser presentado con todas la posibles ventajas para la empresa u organización, pero sin descuidar ninguno de los elementos necesarios para que el proyecto funcione. Para esto dentro de los estudios de factibilidad se complementan dos pasos en la presentación del estudio:

• Requisitos Óptimos.
• Requisitos Mínimos.

El primer paso se refiere a presentar un estudio con los requisitos óptimos que el proyecto requiera, estos elementos deberán ser los necesarios para que las actividades y resultados del proyecto sean obtenidos con la máxima eficacia.

El segundo paso consiste en un estudio de requisitos mínimos, el cual cubre los requisitos mínimos necesarios que el proyecto debe ocupar para obtener las metas y objetivos, este paso trata de hacer uso de los recursos disponibles de la empresa para minimizar cualquier gasto o adquisición adicional.

Un estudio de factibilidad debe representar gráficamente los gastos y los beneficios que acarreará la puesta en marcha del sistema, para tal efecto se hace uso de la curva costo-beneficio.

Planeación del Proyecto.

Delimitación del problema.

La delimitación del problema se refiere a identificar todos aquellos aspectos que son importantes para el desempeño de una actividad y aislar todos aquellos que no interfieren en el mismo.

En la delimitación del problema se deben de escribir cada uno de los recursos y procesos que intervienen dentro del área del proyecto, para analizar cada uno de ellos y seleccionar aquellos que realmente intervengan dentro del problema identificado.

El objetivo de delimitar el problema es disminuir el grado de complejidad del proyecto para atender solo aquellos aspectos que son requeridos.

Se deben de proporcionar todos los elementos posibles que ayuden a soportar con bases firmes y concretas todos los elementos (recursos, personal e ideas) que son necesitados por el proyecto para su operación optima.

Elaboración del proyecto.

En el capítulo III se detallará una metodología creada para implementar sistemas de planeación financiera, existen diferentes metodologías y en general pienso que todas funcionan siempre y cuando sean llevadas con un orden y control, además de manejar una metodología es importante tener siempre en mente 3 conceptos durante todo el proyecto: Definición de etapas de Desarrollo.

La definición de etapas de desarrollo de un proyecto consiste en la identificación y organización de todas las actividades y procesos importantes que intervienen en la búsqueda de una meta u objetivo, estas etapas deben ser definidas en función de sus características e importancia que presenten.

Las actividades resultantes deben ser descritas y desarrolladas para conocer sus características, posteriormente debe de asignarse un nivel de importancia a cada una de ellas considerando aquellas actividades estrictamente necesarias para alcanzar el objetivo deseado. esta prioridad a nivel de importancia debe de ser considerada mas importante dentro de un modo eficaz (llegar al objetivo).

Ahora debe de asignarse un rango o nivel aprobatorio para cada actividad que permitirá eliminar directamente aquellas que no cumplan con el criterio asignado. Este nivel mínimo será asignado considerando los niveles mas bajos que hayan sido puestos a las actividades para minimizar su impacto en el resultado final.

Planeación y Control de Procesos.

Este proceso se refiere a todas aquellas actividades necesarias para organizar y ordenar adecuadamente un proyecto, implica que cada una de las tareas o actividades que componen un proyecto deben estar muy bien definidas con el fin de identificar y conocer todos los aspectos y elementos importantes, y a su vez poder aplicar buenos métodos de control que permitan llevar a cabo el proyecto de la mejor manera. Los pasos que contempla esta etapa son:

• Desglosar actividades generales.
• Analizar y profundizar cada actividad en sub-actividades (mas importantes).
• Conocer el detalle de cada sub-actividad.
• Aplicar elementos de control para cada actividad y sub-actividad.
• Identificar formas de evaluarlas.
• Consolidar y fortalecer cada actividad (justificar).

Arquitectura de Tecnología.

Se refiere a todos aquellos elementos tecnológicos que son necesarios para soportar o complementar a las aplicaciones de una empresa. Su objetivo es definir un camino estándar para el uso de tecnología en las empresas, y que les permita definir las opciones de crecimiento a mediano y largo plazo. Se siguen los siguientes pasos:

• Identificar plataformas y principios de tecnología.
• Definir tecnología distribución de los datos y aplicaciones.
• Relacionar tecnología distribución de los datos y aplicaciones.

Documentación del Proyecto.

Manual Técnico y del Usuario.

La documentación de proyectos es importante para identificar más fácilmente los aspectos y características que forman parte de un proyecto. Una adecuada documentación le proporciona identidad y "personalidad" a un proyecto, de manera que los usuarios podrán reconocer mas fácilmente las ventajas y desventajas, características, funcionalidades y ventajas, así como costos y beneficios que impliquen el desarrollo del proyecto.

La documentación de un proyecto debe contar con las siguientes características:

• Lenguaje claro y de acuerdo al nivel aplicado:
• Gerencial.
• Técnico.
• Usuario.
• Contemplar todos los aspectos del proyecto.
• Contar con objetivos fácil de detectar.
• Servir como soporte en todo el desarrollo del proyecto.
• Identificar ventajas y desventajas (resaltar ventajas).
• Contar con adecuada estructura.

Los documentos que componen una adecuada documentación de un proyecto deben ser los siguientes:

Carpeta general o profesional.

Consiste en un documento que detalla todos los aspectos relacionados con el proyecto, identifica todas las bases y orígenes sobre las que nace el proyecto, además que especifica los pasos necesarios, los recursos y aplicaciones que un proyecto necesita.

El objetivo de la carpeta profesional es servir de modelo para la implementación del proyecto a desarrollar, de manera que las personas involucradas obtengan información fácilmente en cualquier etapa del proyecto.

Los aspectos principales que debe de contemplar la carpeta profesional son:

• Definición del problema a resolver (delimitar).
• Definición clara de objetivo y metas.
• Áreas que involucra.
• Conocimiento de la organización.
• Planteamiento claro (pasos).
• Investigación.
• Propuestas claras.
• Plan de trabajo.
• Recursos.
• Calendarización.

Este documento va dirigido hacia personas que van a estar relacionadas directamente con la implementación del proyecto, por lo que su nivel se orienta hacia el uso y aplicaciones utilizadas para el definir el proyecto.

Carpeta gerencial o resumen ejecutivo.

Este documento va dirigido hacia las personas de más alto nivel de la empresa o hacia aquellas de las que depende la decisión de implementar o no el proyecto. Generalmente se utiliza un lenguaje claro sin tecnicismo, en términos ejecutivos. Su extensión no debe ser mucha, y debe de recalcar los aspectos más importantes del proyecto.

Generalmente debe contener elementos gráficos y resúmenes que ayuden a identificar mas fácilmente las ideas propuestas.

Carpeta técnica.

Este documento contiene toda la información sobre los recursos utilizados por el proyecto, llevan una descripción muy bien detallada sobre las características físicas y técnicas de cada elemento. Por ejemplo: características de procesadores, velocidad, dimensiones del equipo, garantías, soporte, proveedores y equipo adicional.

Su extensión depende de la cantidad de recursos y equipo utilizado y generalmente se presenta en forma de fichas técnicas en donde se describe en cada una las características de cada recurso.

Plan económico (factibilidad).

Este documento contiene información relacionada con el aspecto económico y de factibilidad del proyecto, su objetivo principal es describir todos aquellos costos relacionados con el desarrollo e implantación del proyecto, ayuda a la empresa a establecer marcos de referencia y evaluar mas fácilmente los alcances y disponibilidad para llevar a cabo el proyecto.

Consta de 2 secciones, una de ellas es el plan económico del desarrollo del proyecto y la otra es el plan económico para implementar el proyecto (la mas importante). Generalmente en esta carpeta se incorpora el estudio de factibilidad que permitirá a la empresa a evaluar la posibilidad de poner en marcha la realización del proyecto.

Se adjunta la información para recabar la información para el desarrollo del sistemas.

Actividad 4 .- Se sugiere realizar una entrevista para recabar la información para el desarrollo del sistema.