Análisis y Diseño de Sistemas

Agradecimientos

Estas dedicatoria va para todas las personas que dedicaron su tiempo para pode realizar este libro electrónico basada en su información investigada durante todos estos años y poder encontrar todo tipo de conceptos, teorías y ejemplos acerca este tema que hoy en día toma mucho revuelo ya que todo la tecnología esta interviniendo en la vida diaria del ser humano.

Metodología Cascada 1

El modelo de cascada es un método de gestión de proyectos, en el que el proyecto se divide en distintas fases secuenciales, donde el equipo puede pasar a la siguiente fase sólo cuando se haya completado la anterior.

La primera descripción formal de la metodología de cascada fue elaborada en el artículo de Winston W. Royce en 1970 sobre la gestión de desarrollo de software. Aun así se considera que el método de cascada se originó en la fabricación y la construcción. De ahí viene que de acuerdo con este modelo no se puede volver a la fase anterior. Es decir, una vez que alguna pieza de producto sale de la máquina, no lo puedes resetear. Y también, que cada fase tiene que completarse en una secuencia predeterminada. No se puede hacer el techo de una casa, si aún no tiene cimientos.

Hoy en día, el modelo cascada no solo se utiliza en los proyectos de construcción o en la fabricación. Por ejemplo, se aplica con bastante frecuencia en el ciclo de vida de desarrollo de sistemas (SDLC) para proyectos de ingeniería de software y TI. En este artículo lo vamos a ver principalmente desde esta perspectiva, pero tenga en cuenta que el concepto básico se adapta a cualquier tipo de proyecto.

El punto clave de la metodología de cascada es que no hay posibilidad de cambios o errores, por lo que la planificación aquí es una etapa fundamental. La calidad de trabajo inicial define en mayor medida el resultado final.

La responsabilidad del gerente en esto es elaborar bien todos los requisitos y prever todas las preguntas pertinentes. Los requisitos deben ser lo más completos posible porque el equipo trabaja con la investigación y el diseño en las etapas iniciales.

Requisitos

Diseño e implementación

Pruebas

Implantación

Mantenimiento

Metodología Desarollo Iterativo

En un desarrollo iterativo e incremental el proyecto se planifica en diversos bloques temporales (en el caso de Scrum de un mes natural o hasta de dos semanas, si así se necesita) llamados iteraciones.

Las iteraciones se pueden entender como mini proyectos: en todas las iteraciones se repite un proceso de trabajo similar (de ahí el nombre “iterativo”) para proporcionar un resultado completo sobre producto final, de manera que el cliente pueda obtener los beneficios del proyecto de forma incremental. Para ello, cada requisito se debe completar en una única iteración: el equipo debe realizar todas las tareas necesarias para completarlo (incluyendo pruebas y documentación) y que esté preparado para ser entregado al cliente con el mínimo esfuerzo necesario. De esta manera no se deja para el final del proyecto ninguna actividad arriesgada relacionada con la entrega de requisitos.

En cada iteración el equipo evoluciona el producto (hace una entrega incremental) a partir de los resultados completados en las iteraciones anteriores, añadiendo nuevos objetivos/requisitos o mejorando los que ya fueron completados. Un aspecto fundamental para guiar el desarrollo iterativo e incremental es la priorización de los objetivos/requisitos en función del valor que aportan al cliente.

Evaluación

Requerimientos

Cada iteración produce un producto ejecutable

Implementación

Análisis y desarrollo

Metodología Desarrollo Iterativo 2

Beneficios

Se puede gestionar las expectativas del cliente (requisitos desarrollados, velocidad de desarrollo, calidad) de manera regular, puede tomar decisiones en cada iteración. Esto es especialmente interesante cuando:

El cliente no sabe exactamente qué es lo que necesita, lo va sabiendo conforme va viendo cuales son los resultados del proyecto.

El cliente necesita hacer cambios a corto plazo (nuevos requisitos o a cambios en los ya realizados) por:

Cambios en las condiciones del mercado (por un cambio de necesidades, por un nuevo producto que ha lanzado la competencia, urgencias).

La reacción y aceptación del mercado respecto al uso de los primeros resultados del proyecto.

Cualquier cambio en el entorno (recursos, etc.), que pueda incluso finalizar el proyecto manteniendo como mínimo los resultados alcanzados hasta ese momento.

El equipo necesita saber si lo que ha entendido es lo que el cliente espera.

El cliente puede comenzar el proyecto con requisitos de alto nivel, quizás no del todo completos, de manera que se vayan refinando en sucesivas iteraciones. Sólo es necesario conocer con más detalle los requisitos de las primeras iteraciones, los que más valor aportan.

No es necesario realizar una recolección completa y detallada de todos los requisitos antes de empezar el desarrollo del proyecto.

El cliente puede obtener resultados importantes y usables ya desde las primeras iteraciones. Se puede gestionar de manera natural los cambios que van apareciendo durante el proyecto. La finalización de cada iteración es el lugar natural donde el cliente puede proporcionar su feedback tras examinar el resultado obtenido (ver control empírico y demostración). Con esta información ya es posible planificar los cambios necesarios para alinearse con las expectativas del cliente desde las primeras iteraciones, de manera que al finalizar el proyecto el cliente obtenga los objetivos esperados.

El cliente como máximo puede perder los recursos dedicados a una iteración, no los de todo el proyecto.

La finalización de cada iteración es el lugar natural donde el equipo puede decidir cómo mejorar su proceso de trabajo, en función de la experiencia obtenida. Con esta información ya es posible planificar los cambios necesarios para aumentar la productividad y calidad desde las primeras iteraciones. Ver Retrospectiva.

Permite conocer el progreso real del proyecto desde las primeras iteraciones y extrapolar si su finalización es viable en la fecha prevista. El cliente puede decidir repriorizar los requisitos del proyecto, añadir nuevos equipos, cancelarlo, etc.

Permite mitigar desde el inicio los riesgos del proyecto. Desde la primera iteración el equipo tiene que gestionar los problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigación de manera anticipada.

Permite gestionar la complejidad del proyecto.

En una iteración sólo se trabaja en los requisitos que aportan más valor en ese momento.

Se puede dividir la complejidad para que cada parte sea resuelta en diferentes iteraciones.

Dado que cada iteración debe dar como resultado requisitos terminados, se minimiza el número de errores que se producen en el desarrollo y se aumentar la calidad.

Metodología Desarrollo Iterativo 2

Restricciones

La disponibilidad del cliente debe ser alta durante todo el proyecto dado que participa de manera continua:

El inicio de una iteración, el cliente ha de detallar (o haber detallado previamente) los requisitos que se van a desarrollar.

En la finalización de cada iteración, el cliente ha de revisar los requisitos desarrollados.

La relación con el cliente ha de estar basada en los principios de colaboración y ganar/ganar más que tratarse de una relación contractual en la cual cada parte únicamente defiende su beneficio a corto plazo.

Cada iteración debe dar como resultado requisitos terminados, de manera que el resultado sea realmente útil para el cliente y no deje tareas pendientes para futuras iteraciones o para la finalización del proyecto.

Cada iteración ha de aportar un valor al cliente, entregar unos resultados cerrados que sean susceptibles de ser utilizados por él.

Es necesario disponer de técnicas y herramientas que permitan hacer cambios fácilmente en el producto, de manera que pueda crecer en cada iteración de manera incremental sin hacer un gran esfuerzo adicional, manteniendo su complejidad minimizada y su calidad.

Recomendaciones

Utilizar iteraciones cortas de 2 a 4 semanas incrementa la productividad del proyecto, dado que el equipo trabaja de forma más eficiente cuando tiene objetivos a corto plazo. Asímismo, con iteraciones cortas la precisión de las estimaciones aumenta. El tamaño depende de:

Los condicionantes del proyecto.

La necesidad de tener feedback más o menos rápido.

Que no se degrade la relación trabajo útil / gestión operativa (por ejemplo reuniones, actividades necesarias que no producen valor directo, etc.).

Utilizar iteraciones regulares, de manera que todas sean un timebox de la misma duración.

El equipo aprende a calcular la velocidad de desarrollo, la cantidad de trabajo que puede hacer en una iteración (sin tener que hacer extrapolaciones si las iteraciones no fuesen regulares).

El cliente puede proyectar cuantas iteraciones se necesitan para tener cada entrega, en función de la velocidad de desarrollo del equipo (el trabajo que pudo completar en iteraciones anteriores del mismo tamaño), y tomar decisiones al respecto.

Permite gestionar y sincronizar de manera sencilla las necesidades del proyecto con respecto a las de otros proyectos (integración con el trabajo realizado por otros equipos, compartición de personas que son difíciles de asignar a un único equipo).

Las iteraciones coincidiendo con meses naturales permiten sincronizar el trabajo del equipo con el de otros departamentos y con el resto de la organización (por ejemplo, la organización puede tener medidas de resultados y objetivos a nivel trimestral o cuatrimestral).

Metodología RUP 3

Fases del Método RUP

• Objetivos y alcance del proyecto

• Arquitectura y sistema

Construcción Transición

• Depurar y entregar al usuario

Culminar la funcionalida d del sistema

RUP significa Rational Unified Process . Este término es un proceso creado por la empresa de ingeniería de software, Rational Software Corporation, para guiar el desarrollo de un programa. El RUP es una metodología con prácticas Lean, así como Scrum y Extreme Programming (XP). Estos métodos tienen en común el uso de buenas prácticas que ayudan a obtener técnicas rutinarias y productivas.

¿Qué es la metodología RUP?

Las prácticas utilizadas en RUP se basan en varios métodos, pero además, presenta algunos principios similares al de los métodos Lean .

Uno de estos métodos es Scrum , y no es posible clasificar uno como mejor que el otro, sino evaluar cuáles son los objetivos que cada metodología proporciona para tu organización o proyecto.

El Scrum Framework se basa en prácticas según el manifiesto Lean. Los proyectos que se desarrollan en este sistema tienen características como actividades y funcionan de forma iterativa e incremental.

Importancia

La metodología Rup es una metodología de desarrollo de software muy importante. Ha ayudado a muchos desarrolladores a mejorar sus habilidades y a producir software de alta calidad. Si te dedicas a esto, entonces debes aprender esta metodología. Te ayudará a mejorar tu trabajo y a producir herramientas de mejor calidad. Rup también te ayudará a entender mejor el ciclo de vida del software y a planificar mejor tu trabajo. Así que aprende esta metodología y mejora tu trabajo. Rup te ayudará a convertirte en un mejor profesional.

4 Fases del RUP

Como se indicó en el tema anterior, las fases del RUP están involucradas dentro de la perspectiva del desarrollo dinámico.

Es en este momento que se le da planificación al proyecto, relevamiento de recursos, implementación, pruebas, entre otros. A continuación, comprendamos un poco más sobre cada paso, por separado.

2 Elaboración

Es en este momento que se elabora la planificación del proyecto con los stakeholders, son ellos quienes han descrito los requisitos para el sistema a desarrollar.

La etapa se realiza en un corto período de tiempo. Guía al equipo para analizar la viabilidad del proyecto y cómo empezar a definir los primeros pasos. Usando este concepto tenemos una metodología llamada Lean Inception.

Ahí es cuando se termina la construcción del proyecto, por eso tiene ese nombre. El principal objetivo es la elaboración del producto. Dado que el método se basa en el desarrollo de software, estamos hablando de crear códigos.

Además, es en esta etapa que se realizan las primeras pruebas para que se prepare la base inicial para la etapa de transición.

En la fase de elaboración, o elaboración, busca relevar casos, documentación, estudios base, es decir, modelos para orientar el proyecto. Esto es para orientar cuál será la mejor manera de acuerdo con las premisas de los interesados.

Tras todo este conocimiento, se elabora un plan de proyecto, con todas las características y especificidades, de la forma más detallada posible.

1 Comienzo 4 Transición 3 Construcción

La transición se expresa como transición, es decir, la fase que pasa el proyecto desde el punto de prueba hasta la implementación.

Después de todas las pruebas realizadas y con el objeto listo, llega el momento de ponerlo a disposición del usuario final, es decir, la entrega del proyecto.

Además de la entrega, esta fase incluye la realización de capacitaciones y asegurar que el objeto final resuelva todos los problemas de las partes interesadas.

Dadas todas las fases que componen un proyecto utilizando la metodología RUP, es importante destacar que en el desarrollo de estas actividades todo el equipo necesita estar orientado a algunas prácticas y realizar los artefactos de forma alineada.

Metodología XP 4

La programación extrema es una metodología ágil de gestión de proyectos que se centra en la velocidad y la simplicidad con ciclos de desarrollo cortos y con menos documentación. La estructura del proceso está determinada por 5 valores fundamentales, 5 reglas y 12 prácticas de XP (que detallaremos más adelante en este artículo).

Al igual que otras metodologías ágiles, la programación extrema es una método de desarrollo de software dividido en sprints de trabajo. Los marcos ágiles siguen un proceso iterativo, en el que se completa y revisa el marco al final de cada sprint, refinándolo para adaptarlo a los requisitos cambiantes y alcanzar la eficiencia máxima. Al igual que otros métodos ágiles, el diseño de la programación extrema permite a los desarrolladores responder a las solicitudes de los clientes, adaptarse y realizar cambios en tiempo real. Sin embargo, la programación extrema es mucho más disciplinada; realiza revisiones de código frecuentes y pruebas unitarias para realizar cambios rápidamente. Además es muy creativa y colaborativa, ya que promueve el trabajo en equipo durante todas las etapas de desarrollo.

Los orígenes de XP se remontan a fines de la década de 1990, cuando Kent Beck la creó para gestionar el desarrollo de un sistema de software de nómina para Chrysler llamado Proyecto C3. El objetivo al implementar la programación extrema era (y sigue siendo) eliminar la resistencia a cambiar el código en un proyecto de desarrollo. En los métodos de desarrollo de software más tradicionales, es muy común que el código no se cambie una vez que está escrito (excepto para la depuración). Con la programación extrema, en cambio, el código se examina con tanto detalle que los desarrolladores pueden decidir modificarlo por completo luego de una sola iteración.

• Si estás constantemente en contacto con tus clientes. La programación extrema incorpora los requisitos de los clientes a lo largo del proceso de desarrollo y también se basa en ellos para las pruebas y aprobaciones.

• Si trabajas con un equipo flexible que pueda aceptar el cambio (sin resentimientos). Dada su propia naturaleza, la programación extrema a menudo requerirá que todo el equipo deseche todo su arduo trabajo. Algunas reglas también permiten que algunos miembros del equipo realicen cambios en cualquier momento, lo que supondría un problema si los demás compañeros del equipo se lo toman como algo personal.

Como la programación extrema se centra en el desarrollo de software, suele ser implementada solamente por los equipos de ingeniería. Incluso los equipos de software, suelen usarla únicamente para determinadas configuraciones. Para obtener el máximo beneficio de la programación extrema, recomendamos usarla en los siguientes casos:

• Para gestionar un equipo más pequeño. Debido a su naturaleza altamente colaborativa, la programación extrema funciona mejor en equipos pequeños de menos de diez personas.

• Si dominas los aspectos técnicos de la codificación. La programación extrema no es para principiantes ya que necesitas poder trabajar e implementar cambios rápidamente.

Metodología Watch 5

Es un método de desarrollo de software elaborado para ser empleado durante el desarrollo de sistemas de información empresarial (SIE).

Montilva (2008) define el método Watch como: un marco metodológico que describe los procesos técnicos, gerenciales y de suporte que deben emplear los equipos y grupos que tendrán a su cargo el desarrollo de las aplicaciones informáticas de un SIE. Un marco metodológico es un patrón que debe ser instanciado, es decir adaptado cada vez que se use. Cada equipo de desarrollo de aplicaciones de un SIE deberá usar el método como un patrón o plantilla metodológica, a partir de la cual ellos deben elaborar el proceso específico de desarrollo de la aplicación que dicho de equipo deba producir.

Características

• Sólida fundamentación: posee una base conceptual y metodología muy bien sustentada. El método descansa en conceptos bien establecidos que se derivan de la Ingeniería de Software, los Sistemas de Información Geográfica (SIG), los sistemas de información empresarial (SIE).

• Es estructurado y modular:: posee una clara estructura que faculta su compresión y utilización. Esta estructura sepáralos tres elementos primordiales de un método, el producto se quiere elaborar, los actores que los elaboran y el proceso que siguen los actores para elaborar el producto.

• Es de propósito especifico: el método esta dirigidos al desarrollo de aplicaciones geográficas en entornos empresariales, es decir, al desarrollo de sistemas de información de carácter corporativo que estén orientados.

• es flexible y adaptable: si bien el método esta dirigido al desarrollo de aplicaciones especializadas (aplicaciones geográficas en entornos empresariales) sus tres componentes pueden ser adaptados, con relativa facilidad, a otros tipos de productos de software.

La metodología Watch esta comprendida por tres modelos que lo componen los cuales son:

• Modelado de product6o: define el modelo de producto como el primer componente del método watch, este modelo describe las características generales que tienen las aplicaciones de un SIE e identifica los productos intermedios y finales que se deben producir durante el desarrollo de una aplicación SIE.

• Modelado de actores: Montilva (2008) define el modelo de actores como, el segundo de los tres componentes que integran el método watch para el desarrollo de una aplicación empresarial. Su función es discutir con los actores, equipos de trabajo y demás interesados vinculados al desarrollo de las aplicaciones de una aplicación empresarial.

• Modelado de procesos: es un conjunto de actividades que tienen un mismo fin, el modelo de procesos es el ultimo componente del método watch y corresponde a los procesos que definen la trayectoria del proyecto y como se admiran los recursos del equipo, sean estos materiales o humanos.

Referencias Bibliográficas

• Wikipedia (2023). Sistemas informáticos. Recuperado el 15 de Junio de 2023 en: https://es.wikipedia.org/wiki/Sistema_inform%C3%A1tico

• Crehara (2022). Domina el modelo cascada y potencia al máximo tus proyectos de software. Recuperado el 15 de Junio de 2023 en:

https://www.crehana.com/blog/transformacion-digital/modelo-en-cascada /

• Nimble (2023). Desarrollo iterativo e incremental. Recuperado el 15 de Junio de 2023 en:

https://www.nimblework.com/es/agile/desarrollo-iterativo-e-incremental/

• Blogspot (2012). Metodología RUP. Recuperado el 15 de junio de 2023 en: http://rupmetodologia.blogspot.com/

• Sinnaps (2023). Metodología XP o Programación extrema. Recuperado el 15 de junio de 2023 en: https:// www.sinnaps.com/blog-gestion-proyectos/metodologia-xp

• J. A. Silva (2004). Desarrollo de aplicaciones empresariales – El método watch. Recuperado el 15 de junio de 2023 en: https:// luiscastellanos.files.wordpress.com/2014/02/mc3a9todo-watch-gray-watc h-jonas-montilva-2004.pdf