MODELO EN ESPIRAL
martes, 17 de agosto de 2010
EL MODELO EN ESPIRAL
Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.
El modelo en espiral fue desarrollado por Boehm, quien lo describe así:
El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.
Se caracteriza principalmente por:
Ø Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
Ø Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.
El modelo espiral captura algunos principios básicos:
· Decidir qué problema se quiere resolver antes de viajar a resolverlo.
· Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
· Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
· No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
· Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.
En cada vuelta tomamos en cuenta:Ø Los Objetivos: Que necesidad debe envolver el programa.
Ø Alternativas: Los varios métodos de alcanzar los objetivos de manera exitosa, a través de diferentes puntos como son:
1.Características: experiencia del personal, exigencias a efectuar.
2.Formas de gestión del programa.
3.Riesgo tomado con cada alternativa.
Ø Desarrollar y Verificar: Programar y probar el programa .
Ø Se planificaran los siguientes pasos y se volverá a empezar la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones la radial y la angular:
1.Angular=Avance del proyecto Software, dentro de un ciclo.
2.Radial=Aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.
Este sistema es muy utilizado en proyectos largos como pueden ser la creación de un Sistema Operativo. Y que necesitan constantes cambios.
Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea capaz de detectar y catalogar correctamente dicho riesgo.
El modelo en espiral WINWIN
El modelo en espiral WINWIN de Boehm, define un conjunto de acciones de negociación al principio de casa paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades:
Identificación del sistema o subsistemas clave de los directivos.
Determinación de las condiciones de victoria de los directivos.
Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).
El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de decisión antes de continuar el proyecto de software.
Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.
El modelo en espiral fue desarrollado por Boehm, quien lo describe así:
El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.
Se caracteriza principalmente por:
Ø Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
Ø Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.
El modelo espiral captura algunos principios básicos:
· Decidir qué problema se quiere resolver antes de viajar a resolverlo.
· Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
· Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
· No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
· Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.
En cada vuelta tomamos en cuenta:Ø Los Objetivos: Que necesidad debe envolver el programa.
Ø Alternativas: Los varios métodos de alcanzar los objetivos de manera exitosa, a través de diferentes puntos como son:
1.Características: experiencia del personal, exigencias a efectuar.
2.Formas de gestión del programa.
3.Riesgo tomado con cada alternativa.
Ø Desarrollar y Verificar: Programar y probar el programa .
Ø Se planificaran los siguientes pasos y se volverá a empezar la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones la radial y la angular:
1.Angular=Avance del proyecto Software, dentro de un ciclo.
2.Radial=Aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.
Este sistema es muy utilizado en proyectos largos como pueden ser la creación de un Sistema Operativo. Y que necesitan constantes cambios.
Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea capaz de detectar y catalogar correctamente dicho riesgo.
El modelo en espiral WINWIN
El modelo en espiral WINWIN de Boehm, define un conjunto de acciones de negociación al principio de casa paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades:
Identificación del sistema o subsistemas clave de los directivos.
Determinación de las condiciones de victoria de los directivos.
Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).
El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de decisión antes de continuar el proyecto de software.
modelos hibridos
Frente a esta alternativa, GFI Software defiende un modelo híbrido de soluciones. Dentro de este modelo híbrido, las aplicaciones informáticas podrán combinar lo mejor del Cloud Computing con lo mejor de los aplicativos en local, optimizando y protegiendo las inversiones que realizan las pymes en tecnologías de la información.
Un proveedor de soluciones, que brinde este enfoque híbrido, ofrece a las pequeñas y medianas empresas un amplio conjunto de soluciones para que ellas mismas elijan la que mejor se les adapte en función de sus actuales y futuros requerimientos de infraestructura informática.
La empresa, además, no necesitará buscar un proveedor de soluciones alternativo en caso de querer cambiar de un modelo a otro, pudiendo beneficiarse de su relación con su actual proveedor. No existen, por tanto, ni nuevas condiciones a negociar, ni contratos a largo plazo, ni problemas de migración, ni costes ligados a la puesta en funcionamiento del sistema, etc.
PROTOTIPO DE SOFTWARE
lunes, 16 de agosto de 2010
El desarrollo orientado a prototipos
Si bien algunos autores consideran que esto es parte del ciclo de vida clásico (Boehm, 1988), es también posible verlo como un método independiente.
Una definición de un prototipo en software podría ser:
"...es un modelo del comportamiento del sistema que puede ser usado para entenderlo completamente o ciertos aspectos de él y así clarificar los requerimientos... Un prototipo es una representación de un sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas"
Las fases que comprende el método de desarrollo orientado a prototipos serían:
Investigación preliminar. Las metas principales de esta fase son: determinar el problema y su ámbito, la importancia y sus efectos potenciales sobre la organización por una parte y, por otro lado, identificar una idea general de la solución para realizar un estudio de factibilidad que determine la factibilidad de una solución software.
Definición de los requerimientos del sistema. El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relación al proyecto bajo desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es aquí donde el desarrollador determina los requisitos mediante la construcción, demostración y retroalimentaciones del prototipo. Por lo mismo esta etapa será revisada con más detalle luego de esta descripción.
Diseño técnico. Durante la construcción del prototipo, el desarrollador ha obviado el diseño detallado. El sistema debe ser entonces rediseñado y documentado según los estándares de la organización y para ayudar a las mantenciones futuras. Esta fase de diseño técnico tiene dos etapas: por un lado, la producción de una documentación de diseño que especifica y describe la estructura del software, el control de flujo, las interfaces de usuario y las funciones y, como segunda etapa, la producción de todo lo requerido para promover cualquier mantención futura del software.
4
Programación y prueba. Es donde los cambios identificados en el diseño técnico son implementados y probados para asegurar la corrección y completitud de los mismos con respecto a los requerimientos.
Operación y mantención. La instalación del sistema en ambiente de explotación, en este caso, resulta de menor complejidad, ya que se supone que los usuarios han trabajado con el sistema al hacer las pruebas de prototipos. Además, la mantención también debería ser una fase menos importante, ya que se supone que el refinamiento del prototipo permitiría una mejor claridad en los requerimientos, por lo cual las mantenciones perfectivas se reducirían. Si eventualmente se requiriese una mantención entonces el proceso de prototipado es repetido y se definirá un nuevo conjunto de requerimientos.
La fase más importante corresponde a la definición de requerimientos, la cual correspondería a un proceso que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. La definición de requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo:
Análisis grueso y especificación. El propósito de esta subfase es desarrollar un diseño básico para el prototipo inicial.
Diseño y construcción. El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un sistema con la máxima funcionalidad, poniendo énfasis en la interface del usuario.
Evaluación. Esta etapa tiene dos propósitos: extraer a los usuarios la especificación de los requerimientos adicionales del sistema y verificar que el prototipo desarrollado lo haya sido en concordancia con la definición de requerimientos del sistema. Si los usuarios identifican fallas en el prototipo, entonces el desarrollador simplemente corrige el prototipo antes de la siguiente evaluación. El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proceso de evaluación puede ser dividido en cuatro pasos separados: preparación, demostración, uso del prototipo y discusión de comentarios. En esta fase se decide si el prototipo es aceptado o modificado.
5
Modificación. Esto ocurre cuando la definición de requerimientos del sistema es alterada en la sub-fase de evaluación. El desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios.
Término. Una vez que se ha desarrollado un prototipo estable y completo, es necesario ponerse de acuerdo en relación a aspectos de calidad y de representación del sistema.
En la siguiente figura se puede ver un esquema en que estas etapas se realizan, note que la especificación de requerimientos está claramente diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya que permite entregar al usuario lo que sería una visión la solución final en etapas tempranas del desarrollo, reduciendo tempranamente los costos de especificaciones erróneas.
Si bien algunos autores consideran que esto es parte del ciclo de vida clásico (Boehm, 1988), es también posible verlo como un método independiente.
Una definición de un prototipo en software podría ser:
"...es un modelo del comportamiento del sistema que puede ser usado para entenderlo completamente o ciertos aspectos de él y así clarificar los requerimientos... Un prototipo es una representación de un sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas"
Las fases que comprende el método de desarrollo orientado a prototipos serían:
Investigación preliminar. Las metas principales de esta fase son: determinar el problema y su ámbito, la importancia y sus efectos potenciales sobre la organización por una parte y, por otro lado, identificar una idea general de la solución para realizar un estudio de factibilidad que determine la factibilidad de una solución software.
Definición de los requerimientos del sistema. El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relación al proyecto bajo desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es aquí donde el desarrollador determina los requisitos mediante la construcción, demostración y retroalimentaciones del prototipo. Por lo mismo esta etapa será revisada con más detalle luego de esta descripción.
Diseño técnico. Durante la construcción del prototipo, el desarrollador ha obviado el diseño detallado. El sistema debe ser entonces rediseñado y documentado según los estándares de la organización y para ayudar a las mantenciones futuras. Esta fase de diseño técnico tiene dos etapas: por un lado, la producción de una documentación de diseño que especifica y describe la estructura del software, el control de flujo, las interfaces de usuario y las funciones y, como segunda etapa, la producción de todo lo requerido para promover cualquier mantención futura del software.
4
Programación y prueba. Es donde los cambios identificados en el diseño técnico son implementados y probados para asegurar la corrección y completitud de los mismos con respecto a los requerimientos.
Operación y mantención. La instalación del sistema en ambiente de explotación, en este caso, resulta de menor complejidad, ya que se supone que los usuarios han trabajado con el sistema al hacer las pruebas de prototipos. Además, la mantención también debería ser una fase menos importante, ya que se supone que el refinamiento del prototipo permitiría una mejor claridad en los requerimientos, por lo cual las mantenciones perfectivas se reducirían. Si eventualmente se requiriese una mantención entonces el proceso de prototipado es repetido y se definirá un nuevo conjunto de requerimientos.
La fase más importante corresponde a la definición de requerimientos, la cual correspondería a un proceso que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. La definición de requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo:
Análisis grueso y especificación. El propósito de esta subfase es desarrollar un diseño básico para el prototipo inicial.
Diseño y construcción. El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un sistema con la máxima funcionalidad, poniendo énfasis en la interface del usuario.
Evaluación. Esta etapa tiene dos propósitos: extraer a los usuarios la especificación de los requerimientos adicionales del sistema y verificar que el prototipo desarrollado lo haya sido en concordancia con la definición de requerimientos del sistema. Si los usuarios identifican fallas en el prototipo, entonces el desarrollador simplemente corrige el prototipo antes de la siguiente evaluación. El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proceso de evaluación puede ser dividido en cuatro pasos separados: preparación, demostración, uso del prototipo y discusión de comentarios. En esta fase se decide si el prototipo es aceptado o modificado.
5
Modificación. Esto ocurre cuando la definición de requerimientos del sistema es alterada en la sub-fase de evaluación. El desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios.
Término. Una vez que se ha desarrollado un prototipo estable y completo, es necesario ponerse de acuerdo en relación a aspectos de calidad y de representación del sistema.
En la siguiente figura se puede ver un esquema en que estas etapas se realizan, note que la especificación de requerimientos está claramente diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya que permite entregar al usuario lo que sería una visión la solución final en etapas tempranas del desarrollo, reduciendo tempranamente los costos de especificaciones erróneas.
MODELO EVOLUTIVO
Ciclo de Vida del Software
Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.
El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 años atrás, el modelo cascada ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, o más incrementalmente o de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos.
Definición de un Modelo de Ciclo de Vida
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Un modelo de ciclo de vida del software:
•Describe las fases principales de desarrollo de software.
•Define las fases primarias esperadas de ser ejecutadas durante esas fases.
•Ayuda a administrar el progreso del desarrollo, y
•Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.
Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.
Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.
El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 años atrás, el modelo cascada ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, o más incrementalmente o de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos.
Definición de un Modelo de Ciclo de Vida
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Un modelo de ciclo de vida del software:
•Describe las fases principales de desarrollo de software.
•Define las fases primarias esperadas de ser ejecutadas durante esas fases.
•Ayuda a administrar el progreso del desarrollo, y
•Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.
Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.
MODELOS CASCADA
Modelo de la cascada
modelo de la cascada es a secuencial modelo del desarrollo del software (un proceso para la creación del software) en que el desarrollo se considera como fluyendo constantemente hacia abajo (como a cascada) con las fases de análisis de requisitos, diseño, puesta en práctica, prueba(validación), integración, y mantenimiento. El origen del término “cascada” se cita a menudo para ser un artículo publicado adentro 1970 por Winston W. Royce (1929-1995),[1] aunque Royce no utilizó el término “cascada” en este artículo. Irónico, Royce presentaba este modelo como ejemplo de un modelo dañado, non-working (Royce 1970).
Historia del modelo de la cascada
En Royce 1970 propuesto qué se refiere actualmente como el modelo de la cascada como concepto inicial, un modelo que él discutió era dañado (Royce 1970). Su papel exploró cómo el modelo inicial se podría desarrollar en un modelo iterativo, con la regeneración a partir de cada fase que influenciaba fases subsecuentes. Es solamente el modelo inicial que recibió el aviso; su propia crítica de este modelo inicial se ha no hecho caso en gran parte. La frase “modelo de la cascada” vino rápidamente referirse no a Royce final, diseño iterativo, sino algo a su modelo puramente secuencialmente pedido. Este artículo utiliza el significado popular de la frase “modelo de la cascada”. Para un similar modelo iterativo a la visión final de Royce, vea modelo espiral.
A pesar de las intenciones de Royce para que el modelo de la cascada sea modificado en un modelo iterativo, el uso del modelo de la cascada como proceso puramente secuencial sigue siendo popular, y, para alguno, la frase “modelo de la cascada” tiene puesto que venido referir a cualesquiera acerqúese a la creación del software que se considera como inflexible y non-iterative. Los que utilizan la frase “modelo de la cascada” pejoratively ven generalmente el modelo de la cascada como ingenuo e inadecuado para un proceso iterativo.
Discusiones para el modelo de la cascada
Tiempo pasado a principios de en la producción del software puede conducir a mayor economía más tarde en el ciclo de vida del software; es decir, se ha demostrado muchas veces que un insecto encontrado en los primeros tiempos del ciclo de vida de la producción (tales como especificación o diseño de requisitos) es más barato, en términos de dinero, esfuerzo y tiempo, de fijar que el mismo insecto encontrado más tarde en el proceso. ([McConnell 1996], P. 72, estima que “los requisitos desertan que se deja desapercibido hasta la construcción o el mantenimiento costará 50 a 200 veces tanto al arreglo pues habría costado al arreglo en el tiempo de los requisitos. ”) Tomar un ejemplo extremo, si un diseño del programa resulta ser imposible poner en ejecución, es más fácil fijar el diseño en la etapa del diseño que realizar meses más adelante, cuando se están integrando los componentes del programa, que todo el trabajo hecho hasta ahora tiene que ser desechado debido a un diseño quebrado.
Ésta es la idea central detrás Diseño grande encima del frente (BDUF) y el modelo de la cascada - el tiempo pasó a principios de cerciorarse de que los requisitos y el diseño son voluntad absolutamente correcta excepto usted mucha hora y esfuerzo más adelante. Así, el pensamiento en los que sigan el proceso de la cascada va, uno debe cerciorarse de que cada fase sea el 100% completo y absolutamente correcto antes de proceder a la fase próxima de la creación del programa. Los requisitos del programa se deben fijar en piedra antes de que se comience el diseño (si no se pierde el trabajo puso en un diseño basado en requisitos incorrectos); el diseño del programa debe ser perfecto antes de que la gente comience el trabajo sobre poner el diseño en ejecución (si no ella está poniendo el diseño en ejecución incorrecto y se pierde su trabajo), etc.
Otra discusión para el modelo de la cascada es que pone énfasis en la documentación (tal como documentos de los requisitos y documentos del diseño) así como código de fuente. En metodologías menos diseñadas y documentadas, los miembros del equipo se van, mucho conocimiento se pierde y puede ser difícil para que un proyecto se recupere de. Si completamente el documento del diseño de funcionamiento ser actuales (al igual que el intento del diseño grande encima del frente y del modelo de la cascada) nuevos miembros del equipo o aún enteramente nuevos equipos debe poder familiarizarse leyendo los documentos.
Así como el antedicho, algunos prefieren el modelo de la cascada para su acercamiento simple y discutible disciplinado. Más bien que qué el adherente de la cascada ve como caos, el modelo de la cascada proporciona un acercamiento estructurado; el modelo sí mismo progresa linear en fases discretas, fácilmente comprensibles y explicables y es así fácil de entender; también proporciona fácilmente jalones markable en el proceso del desarrollo. Está quizás por esta razón que el modelo de la cascada está utilizado como ejemplo que comienza de un modelo del desarrollo en muchos textos y cursos de la tecnología de dotación lógica.
Se discute que el modelo de la cascada y el diseño grande encima del frente en general se pueden satisfacer a los proyectos del software que son estables (especialmente esos proyectos con requisitos unchanging, por ejemplo con software del abrigo del encogimiento) y a donde está posible y probable que los diseñadores puedan predecir completamente las áreas problemáticas del sistema y producir a correcto el diseño antes de la puesta en práctica se comienza. El modelo de la cascada también requiere que los ejecutores sigan el pozo hecho, diseño completo exactamente, asegurándose de que proceda la integración del sistema suavemente.
Suscribirse a:
Entradas (Atom)