Sin título

Página 1

MODELO DEL PROCESO DE SOFTWARE

Un modelo de proceso de software define cómo resolver la problemática del desarrollo de sistemas de software. Para desarrollar software se requiere resolver ciertas fases de un proceso que se conocen en su conjunto como el ciclo de vida del desarrollo de software. Un modelo de proceso debe considerar una variedad de aspectos, como el conjunto de personas, estructuras organizacionales, reglas, políticas, actividades, componentes de software, metodologías y herramientas utilizadas.

MODELO DE CASCADA

Consiste en una serie de etapas que deben ser subsecuentes las cuales primero es necesario terminar una de ellas para continuar con la siguiente hasta terminar con todas las etapas.

El modelo original planteaba que cada actividad debía completarse antes de poder continuar con la siguiente actividad. Sin embargo, en una revisión posterior se extendió el modelo, permitiendo regresar a actividades anteriores. El modelo de cascada fue inicialmente bien recibido, dado que las actividades de las etapas eran razonables y lógicas. Lamentablemente, el modelo no explicaba cómo modificar un resultado, en especial considerando lo difícil que es definir todos los requisitos de un sistema desde el inicio y que éstos se mantengan estables y sin cambios durante el desarrollo. Además, toma demasiado tiempo en obtener resultados, retrasando la detección de errores hasta el final.

Debido al paso de una fase en cascada a otra, este modelo se conoce como “modelo en cascada” o ciclo de vida del software.

Las principales etapas del modelo en cascada reflejan directamente las actividades fundamentales del desarrollo:

1. Análisis y definición de requerimientos. Los servicios, las restricciones y las metas del sistema se establecen mediante consulta a los usuarios del sistema. Luego, se definen con detalle y sirven como una especificación del sistema.

2. Diseño del sistema y del software. El proceso de diseño de sistemas asigna los requerimientos, para sistemas de hardware o de software, al establecer una arquitectura de sistema global. El diseño del software implica identificar y describir las abstracciones fundamentales del sistema de software y sus relaciones.

3. Implementación y prueba de unidad. Durante esta etapa, el diseño de software se realiza como un conjunto de programas o unidades del programa. La prueba de unidad consiste en verificar que cada unidad cumpla con su especificación.

4. Integración y prueba de sistema. Las unidades del programa o los programas individuales se integran y prueban como un sistema completo para asegurarse de que se cumplan los requerimientos de software. Después de probarlo, se libera el sistema de software al cliente.

5. Operación y mantenimiento. Por lo general (aunque no necesariamente), ésta es la fase más larga del ciclo de vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye corregir los errores que no se detectaron en etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema e incrementar los servicios del sistema conforme se descubren nuevos requerimientos.

En principio, el resultado de cada fase consiste en uno o más documentos que se autorizaron (“firmaron”). La siguiente fase no debe comenzar sino hasta que termine la fase previa. En la práctica, dichas etapas se traslapan y se nutren mutuamente de información. Durante el diseño se identifican los problemas con los requerimientos. En la codificación se descubren problemas de diseño, y así sucesivamente. El proceso de software no es un simple modelo lineal, sino que implica retroalimentación de una fase a otra. Entonces, es posible que los documentos generados en cada fase deban modificarse para reflejar los cambios que se realizan.

COMENTARIO

El modelo de cascada que como su nombre lo indica consiste en una serie de etapas que siguen una secuencia, hasta que terminemos con una podemos proseguir con la siguiente, aunque actualmente en la práctica las etapas se nutren mutuamente. Hay que tener en cuenta que el modelo en cascada sólo debe usarse cuando los requerimientos se entiendan bien. El modelo es un ejemplo de un proceso dirigido por un plan; en principio, debemos planear y programar todas las actividades del proceso, antes de comenzar a trabajar con ellas.

MODELO EN ESPIRAL DE BOEHM

En el modelo espiral, no hay fases como tales que deban de ser completadas en cierto orden, más bien hay una progresión de actividades que se van repitiendo de manera cíclica.

Es una extensión del modelo de cascada. A diferencia del modelo de cascada, que es dirigido por documentos, el modelo espiral se basa en una estrategia para reducir el riesgo del proyecto en áreas de incertidumbre, como tener requerimientos iniciales incompletos e inestables. El modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo. Cada ciclo comienza con la identificación de los objetivos, soluciones alternas y restricciones asociadas con cada alternativa, y finalmente se procede a su evaluación. Cuando se encuentra que existe cierta incertidumbre, se utilizan diversas técnicas para reducir el riesgo de las distintas alternativas. Cada ciclo del modelo espiral termina con una revisión que discute los logros actuales y los planes para el siguiente ciclo.

Las creencias del modelo de espiral son que una actividad comienza cuando se entienden los objetivos y riesgos involucrados, se usan las herramientas que mejor reduzcan los riesgos basándose en la evaluación de soluciones alternas, todo el personal relacionado debe involucrarse en una revisión que determine cada actividad (planeando y comprometiéndose con las siguientes actividades) y el desarrollo se incrementa en cada etapa, permitiendo prototipos sucesivos del producto. Con algunas variantes, éste es el modelo de proceso más importante en la actualidad.

Cada ciclo en la espiral se divide en cuatro sectores:

1. Establecimiento de objetivos. Se definen objetivos específicos para dicha fase del proyecto. Se identifican restricciones en el proceso y el producto, y se traza un plan de gestión detallado. Se identifican los riesgos del proyecto. Pueden planearse estrategias alternativas, según sean los riesgos.

2. Valoración y reducción del riesgo. En cada uno de los riesgos identificados del proyecto, se realiza un análisis minucioso. Se dan acciones para reducir el riesgo.

3. Desarrollo y validación. Después de una evaluación del riesgo, se elige un modelo de desarrollo para el sistema. Por ejemplo, la creación de prototipos desechables sería el mejor enfoque de desarrollo, si predominan los riesgos en la interfaz del usuario. Si la principal consideración son los riesgos de seguridad, el desarrollo con base en transformaciones formales sería el proceso más adecuado, entre otros. Si el principal riesgo identificado es la integración de subsistemas, el modelo en cascada sería el mejor modelo de desarrollo a utilizar.

4. Planeación. El proyecto se revisa y se toma una decisión sobre si hay que continuar con otro ciclo de la espiral. Si se opta por continuar, se trazan los planes para la siguiente fase del proyecto.

COMENTARIO

En este modelo como tal no hay una secuencia en la realización de las etapas, si no que en esta las etapas se repiten de manera cíclica. Este modelo se basa la aplicación de estrategias para reducir el riesgo del proyecto en áreas de incertidumbre. Este modelo hace énfasis en los ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo. Las creencias del modelo de espiral son que una actividad comienza cuando se entienden los objetivos y riesgos involucrados, se usan las herramientas que mejor reduzcan los riesgos basándose en la evaluación de soluciones alternas.

FUENTES TEOICAS DE INFOMACION:

https://www.cgn.gub.uy/innovaportal/file/83018/1/material_concurso_r14_cgn_2017.pdf

https://weitzenfeld.robolat.org/wpcontent/uploads/2015/01/WeitzenfeldGuardatiComputacion2008.pdf

MODELO DEL PROCESO DE SOFTWARE

Un modelo de proceso de software define cómo resolver la problemática del desarrollo de sistemas de software. Para desarrollar software se requiere resolver ciertas fases de un proceso que se conocen en su conjunto como el ciclo de vida del desarrollo de software. Un modelo de proceso debe considerar una variedad de aspectos, como el conjunto de personas, estructuras organizacionales, reglas, políticas, actividades, componentes de software, metodologías y herramientas utilizadas.

MODELO DE CASCADA

Consiste en una serie de etapas que deben ser subsecuentes las cuales primero es necesario terminar una de ellas para continuar con la siguiente hasta terminar con todas las etapas.

El modelo original planteaba que cada actividad debía completarse antes de poder continuar con la siguiente actividad. Sin embargo, en una revisión posterior se extendió el modelo, permitiendo regresar a actividades anteriores. El modelo de cascada fue inicialmente bien recibido, dado que las actividades de las etapas eran razonables y lógicas. Lamentablemente, el modelo no explicaba cómo modificar un resultado, en especial considerando lo difícil que es definir todos los requisitos de un sistema desde el inicio y que éstos se mantengan estables y sin cambios durante el desarrollo. Además, toma demasiado tiempo en obtener resultados, retrasando la detección de errores hasta el final.

Debido al paso de una fase en cascada a otra, este modelo se conoce como “modelo en cascada” o ciclo de vida del software.

Las principales etapas del modelo en cascada reflejan directamente las actividades fundamentales del desarrollo:

1. Análisis y definición de requerimientos. Los servicios, las restricciones y las metas del sistema se establecen mediante consulta a los usuarios del sistema. Luego, se definen con detalle y sirven como una especificación del sistema.

2. Diseño del sistema y del software. El proceso de diseño de sistemas asigna los requerimientos, para sistemas de hardware o de software, al establecer una arquitectura de sistema global. El diseño del software implica identificar y describir las abstracciones fundamentales del sistema de software y sus relaciones.

3. Implementación y prueba de unidad. Durante esta etapa, el diseño de software se realiza como un conjunto de programas o unidades del programa. La prueba de unidad consiste en verificar que cada unidad cumpla con su especificación.

4. Integración y prueba de sistema. Las unidades del programa o los programas individuales se integran y prueban como un sistema completo para asegurarse de que se cumplan los requerimientos de software. Después de probarlo, se libera el sistema de software al cliente.

5. Operación y mantenimiento. Por lo general (aunque no necesariamente), ésta es la fase más larga del ciclo de vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye corregir los errores que no se detectaron en etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema e incrementar los servicios del sistema conforme se descubren nuevos requerimientos.

En principio, el resultado de cada fase consiste en uno o más documentos que se autorizaron (“firmaron”). La siguiente fase no debe comenzar sino hasta que termine la fase previa. En la práctica, dichas etapas se traslapan y se nutren mutuamente de información. Durante el diseño se identifican los problemas con los requerimientos. En la codificación se descubren problemas de diseño, y así sucesivamente. El proceso de software no es un simple modelo lineal, sino que implica retroalimentación de una fase a otra. Entonces, es posible que los documentos generados en cada fase deban modificarse para reflejar los cambios que se realizan.

COMENTARIO

El modelo de cascada que como su nombre lo indica consiste en una serie de etapas que siguen una secuencia, hasta que terminemos con una podemos proseguir con la siguiente, aunque actualmente en la práctica las etapas se nutren mutuamente. Hay que tener en cuenta que el modelo en cascada sólo debe usarse cuando los requerimientos se entiendan bien. El modelo es un ejemplo de un proceso dirigido por un plan; en principio, debemos planear y programar todas las actividades del proceso, antes de comenzar a trabajar con ellas.

MODELO EN ESPIRAL DE BOEHM

En el modelo espiral, no hay fases como tales que deban de ser completadas en cierto orden, más bien hay una progresión de actividades que se van repitiendo de manera cíclica.

Es una extensión del modelo de cascada. A diferencia del modelo de cascada, que es dirigido por documentos, el modelo espiral se basa en una estrategia para reducir el riesgo del proyecto en áreas de incertidumbre, como tener requerimientos iniciales incompletos e inestables. El modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo. Cada ciclo comienza con la identificación de los objetivos, soluciones alternas y restricciones asociadas con cada alternativa, y finalmente se procede a su evaluación. Cuando se encuentra que existe cierta incertidumbre, se utilizan diversas técnicas para reducir el riesgo de las distintas alternativas. Cada ciclo del modelo espiral termina con una revisión que discute los logros actuales y los planes para el siguiente ciclo.

Las creencias del modelo de espiral son que una actividad comienza cuando se entienden los objetivos y riesgos involucrados, se usan las herramientas que mejor reduzcan los riesgos basándose en la evaluación de soluciones alternas, todo el personal relacionado debe involucrarse en una revisión que determine cada actividad (planeando y comprometiéndose con las siguientes actividades) y el desarrollo se incrementa en cada etapa, permitiendo prototipos sucesivos del producto. Con algunas variantes, éste es el modelo de proceso más importante en la actualidad.

Cada ciclo en la espiral se divide en cuatro sectores:

1. Establecimiento de objetivos. Se definen objetivos específicos para dicha fase del proyecto. Se identifican restricciones en el proceso y el producto, y se traza un plan de gestión detallado. Se identifican los riesgos del proyecto. Pueden planearse estrategias alternativas, según sean los riesgos.

2. Valoración y reducción del riesgo. En cada uno de los riesgos identificados del proyecto, se realiza un análisis minucioso. Se dan acciones para reducir el riesgo.

3. Desarrollo y validación. Después de una evaluación del riesgo, se elige un modelo de desarrollo para el sistema. Por ejemplo, la creación de prototipos desechables sería el mejor enfoque de desarrollo, si predominan los riesgos en la interfaz del usuario. Si la principal consideración son los riesgos de seguridad, el desarrollo con base en transformaciones formales sería el proceso más adecuado, entre otros. Si el principal riesgo identificado es la integración de subsistemas, el modelo en cascada sería el mejor modelo de desarrollo a utilizar.

4. Planeación. El proyecto se revisa y se toma una decisión sobre si hay que continuar con otro ciclo de la espiral. Si se opta por continuar, se trazan los planes para la siguiente fase del proyecto.

COMENTARIO

En este modelo como tal no hay una secuencia en la realización de las etapas, si no que en esta las etapas se repiten de manera cíclica. Este modelo se basa la aplicación de estrategias para reducir el riesgo del proyecto en áreas de incertidumbre. Este modelo hace énfasis en los ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo. Las creencias del modelo de espiral son que una actividad comienza cuando se entienden los objetivos y riesgos involucrados, se usan las herramientas que mejor reduzcan los riesgos basándose en la evaluación de soluciones alternas.

FUENTES TEOICAS DE INFOMACION:

https://www.cgn.gub.uy/innovaportal/file/83018/1/material_concurso_r14_cgn_2017.pdf

https://weitzenfeld.robolat.org/wpcontent/uploads/2015/01/WeitzenfeldGuardatiComputacion2008.pdf