modelos
En el modelo clásico, cada proyecto atraviesa por algún tipo de análisis, diseño e implantación.
La fase de exploración y análisis pudieran unirse en una sola.
Puede no haber fase de estudio de hardware si se cree que cualquier sistema nuevo pudiera instalarse con los ordenadores existentes sin causar mayor problema operacional.
La fase de diseño preliminar y el diseño de detalles pudieran unirse en una sola llamada simplemente de diseño.
Diversas fases de pruebas pueden unirse en una sola; de hecho, podrían incluirse con la codificación.
Puede no haber fase de estudio de hardware si se cree que cualquier sistema nuevo pudiera instalarse con los ordenadores existentes sin causar mayor problema operacional.
La fase de diseño preliminar y el diseño de detalles pudieran unirse en una sola llamada simplemente de diseño.
Diversas fases de pruebas pueden unirse en una sola; de hecho, podrían incluirse con la codificación.
El uso de la implantación ascendente es una de las grandes debilidades del ciclo de vida de los proyectos clásicos.
Se espera que los programadores lleven a cabo primero sus pruebas modulares, luego las pruebas del subsistema, y finalmente las pruebas del sistema mismo. Este enfoque también se conoce como el ciclo de vida de cascada.
Muchas organizaciones que desarrollan sistemas únicos, el enfoque ascendente presenta un gran número de dificultades serias:
Se espera que los programadores lleven a cabo primero sus pruebas modulares, luego las pruebas del subsistema, y finalmente las pruebas del sistema mismo. Este enfoque también se conoce como el ciclo de vida de cascada.
Muchas organizaciones que desarrollan sistemas únicos, el enfoque ascendente presenta un gran número de dificultades serias:
Nada esta hecho hasta que todo esté terminado.
Los fallos más triviales se encuentran al comienzo del período de prueba y las más graves al final.
La eliminación de fallos suele ser extremadamente difícil durante las últimas etapas de prueba del sistema.
La necesidad de prueba aumenta exponencialmente durante las etapas finales de prueba
La segunda debilidad más importante del ciclo de vida de un proyecto clásico es su insistencia en que las fases se sucedan secuencialmente.
Esto es una tendencia natural humana: deseamos decir que hemos terminado la fase de análisis del sistema y que nunca tendremos que volver a preocuparnos por ella.
El único problema del progreso ordenado es que no es nada realista. Por ejemplo, durante el período que transcurre para desarrollar el sistema pueden cambiar ciertos aspectos del ambiente del usuario (la economía, la competencia, los reglamentos gubernamentales que afectan a las actividades del usuario).
Los fallos más triviales se encuentran al comienzo del período de prueba y las más graves al final.
La eliminación de fallos suele ser extremadamente difícil durante las últimas etapas de prueba del sistema.
La necesidad de prueba aumenta exponencialmente durante las etapas finales de prueba
La segunda debilidad más importante del ciclo de vida de un proyecto clásico es su insistencia en que las fases se sucedan secuencialmente.
Esto es una tendencia natural humana: deseamos decir que hemos terminado la fase de análisis del sistema y que nunca tendremos que volver a preocuparnos por ella.
El único problema del progreso ordenado es que no es nada realista. Por ejemplo, durante el período que transcurre para desarrollar el sistema pueden cambiar ciertos aspectos del ambiente del usuario (la economía, la competencia, los reglamentos gubernamentales que afectan a las actividades del usuario).
Modelo Semiestructurado
La
secuencia ascendente de codificación, la prueba de módulos y prueba del
sistema se reemplaza por una implementación de arriba hacia abajo, que
es un enfoque en el cual los módulos de alto nivel se codifican y
prueban primero, seguidos por los más detallados de bajo nivel.
Dentro del modelo semiestructurado encontramos otros detalles tales como, la implementación descendente que significa que se pondrán en ejecución paralelamente parte de la codificación y de las pruebas.
Dándose con lo anterior una retroalimentación entre la codificación, la prueba y la eliminación de las fallas.
Otro punto acerca del modelo semiestructurado, es que una gran parte del trabajo que se realiza bajo el nombre de "diseño estructurado" es en realidad un esfuerzo manual para enmendar especificaciones erróneas.
Otra función de los diseñadores, es traducir un documento narrativo, ambiguo, monolítico y redundante a un modelo útil, que sirva de base para derivar la jerarquía de módulos que cumplan con los requisitos del usuario.
En general con este enfoque de desarrollo de sistemas los diseñadores tenían poco contacto con el analista que escribía la especificación y definitivamente "no tenía contacto con el usuario".
Dentro del modelo semiestructurado encontramos otros detalles tales como, la implementación descendente que significa que se pondrán en ejecución paralelamente parte de la codificación y de las pruebas.
Dándose con lo anterior una retroalimentación entre la codificación, la prueba y la eliminación de las fallas.
Otro punto acerca del modelo semiestructurado, es que una gran parte del trabajo que se realiza bajo el nombre de "diseño estructurado" es en realidad un esfuerzo manual para enmendar especificaciones erróneas.
Otra función de los diseñadores, es traducir un documento narrativo, ambiguo, monolítico y redundante a un modelo útil, que sirva de base para derivar la jerarquía de módulos que cumplan con los requisitos del usuario.
En general con este enfoque de desarrollo de sistemas los diseñadores tenían poco contacto con el analista que escribía la especificación y definitivamente "no tenía contacto con el usuario".
Modelo Estructurado.
En el modelo estructurado se examinan brevemente las nueve actividades y los tres terminadores que lo componen.
Los terminadores son los usuarios, los administradores, y el personal de operaciones. Los cuales se tratan de individuos o grupos que proporcionan la entrada al equipo del proyecto, y son los beneficiados finales del sistema.
Los terminadores son los usuarios, los administradores, y el personal de operaciones. Los cuales se tratan de individuos o grupos que proporcionan la entrada al equipo del proyecto, y son los beneficiados finales del sistema.
Actividad 1: La encuesta
Esta
actividad también se conoce como el estudio de factibilidad o como el
estudio inicial de negocios. Empieza cuando el usuario solicita que una o
más partes de su sistema se automaticen.
Objetivos de la encuesta son:
Objetivos de la encuesta son:
- Identificar a los usuarios responsables y crear ""un campo de actividad" inicial del sistema.
- Identificar las deficiencias actuales en el ambiente del usuario.
- Establecer metas y objetivos para un sistema nuevo.
- Determinar si es factible automatizar el sistema y de ser así, sugerir escenarios aceptables.
- Preparar el esquema que se usarápara guiar el resto del proyecto.
En
general, la encuesta ocupa sólo del 5 al 10 por ciento del tiempo y los
recursos de todo el proyecto, y para los proyectos pequeños y sencillos
pudiera ni siquiera ser una actividad formal.
A pesar de todo lo anterior, es una actividad importante debido a que la administración pudiera decidir cancelar el proyecto si no parece atractivo desde el punto de vista de costo-beneficio
A pesar de todo lo anterior, es una actividad importante debido a que la administración pudiera decidir cancelar el proyecto si no parece atractivo desde el punto de vista de costo-beneficio
Actividad 2: El análisis de sistemas
El
propósito principal de la actividad de análisis es transformar sus dos
entradas principales, las políticas del usuario y el esquema del
proyecto, en una especificación estructurada.
Esto implica modelar el ambiente del usuario con diagramas de flujo de datos, diagramas de entidad-relación, diagramas de transición de estado, etc.
Esto implica modelar el ambiente del usuario con diagramas de flujo de datos, diagramas de entidad-relación, diagramas de transición de estado, etc.
Actividad 3: El diseño
La
actividad de diseño se dedica a asignar porciones de la especificación
(modelo esencial) a procesadores adecuados (máquinas o humanos) y a
labores apropiadas (o tareas, particiones, etc.) dentro de cada
procesador.
Dentro
de cada labor, la actividad de diseño se dedica a la creación de una
jerarquía apropiada de módulos de programas y de interfases entre ellos
para implantar la especificación creada en la actividad 2.
Además, se ocupa de la transformación de modelos de datos de entidad-relación en un diseño de base de datos.
Además, se ocupa de la transformación de modelos de datos de entidad-relación en un diseño de base de datos.
Actividad 4: Implantación
Esta
actividad incluye la codificación y la integración de módulos en un
esqueleto progresivamente más complejo del sistema final.
Por eso, la actividad 4 incluye tanto programación estructurada como implantación descendente.
Por eso, la actividad 4 incluye tanto programación estructurada como implantación descendente.
Actividad 5: Generación de pruebas de aceptación
La
especificación estructurada debe contener toda la información necesaria
para definir un sistema que sea aceptable desde el punto de vista del
usuario.
Por eso, una vez generada la especificación, puede comenzar la actividad de producir un conjunto de casos de prueba de aceptación desde la especificación estructurada
Por eso, una vez generada la especificación, puede comenzar la actividad de producir un conjunto de casos de prueba de aceptación desde la especificación estructurada
Actividad 6: Garantía de calidad
La garantía de calidad también se conoce como la prueba final o la prueba de aceptación.
Esta actividad requiere como entradas los datos de la prueba de aceptación generada en la actividad 5 y el sistema integrado producido en la actividad 4.
Esta actividad requiere como entradas los datos de la prueba de aceptación generada en la actividad 5 y el sistema integrado producido en la actividad 4.
Actividad 7: Descripción del procedimiento
Esta
actividad implica la generación de una descripción formal de las partes
del sistema que se harán en forma manual, lo mismo que la descripción
de como interactuarán los usuarios con la parte automatizada del nuevo
sistema.
El resultado de la actividad 7 es un manual para el usuario.
El resultado de la actividad 7 es un manual para el usuario.
Actividad 8: Conversión de bases de datos
En
algunos proyectos, la conversión de bases de datos involucraba más
trabajo que el desarrollo de programas para el nuevo sistema.
En el caso general, esta actividad requiere como entrada las base de datos actual del usuario, al igual que la especificación del diseño producida por medio de la actividad 3.
En el caso general, esta actividad requiere como entrada las base de datos actual del usuario, al igual que la especificación del diseño producida por medio de la actividad 3.
Actividad 9: Instalación
En
esta actividad sus entradas son el manual del usuario producido en la
actividad 7, la base de datos convertida que se creó con la actividad 8 y
el sistema aceptado producido por la actividad 6.
En algunos casos la instalación pudiera significar simplemente un cambio de la noche a la mañana al nuevo sistema; en otros casos, la instalación pudiera ser un proceso gradual, en el que un grupo tras otro de usuario van recibiendo manuales y entrenamiento y comenzado a usar el nuevo sistema.
En algunos casos la instalación pudiera significar simplemente un cambio de la noche a la mañana al nuevo sistema; en otros casos, la instalación pudiera ser un proceso gradual, en el que un grupo tras otro de usuario van recibiendo manuales y entrenamiento y comenzado a usar el nuevo sistema.
Otros modelos de ciclos de de vida:
En cascada
En cascada
El
ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado
para el software a partir de ciclos de vida de otras ramas de la
ingeniería. Es el primero de los propuestos y el más ampliamente seguido
por las organizaciones (se estima que el 90% de los sistemas han sido
desarrollados así).
Este
modelo admite la posibilidad de hacer iteraciones, es decir, durante
las modificaciones que se hacen en el mantenimiento se puede ver por
ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que
se harán los cambios necesarios en la codificación y se tendrán que
realizar de nuevo las pruebas, es decir, si se tiene que volver a una de
las etapas anteriores al mantenimiento hay que recorrer de nuevo el
resto de las etapas.
Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.
Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento específico.
Cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases. Los documentos son:
Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.
Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento específico.
Cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases. Los documentos son:
Análisis:
Toma como entrada una descripción en lenguaje natural de lo que quiere
el cliente. Produce el S.R.D. (Software RequirementsDocument).
Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software DesignDocument)
Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen también pruebas de unidad.
Pruebas: A partir de los módulos probados se realiza la integración y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar.
Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software DesignDocument)
Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen también pruebas de unidad.
Pruebas: A partir de los módulos probados se realiza la integración y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar.
Ciclos de vida en cascada Ventajas
La planificación es sencilla.
La calidad del producto resultante es alta.
Permite trabajar con personal poco cualificado
Ciclos de vida en cascada Inconvenientes
Lo
peor es la necesidad de tener todos los requisitos al principio. Lo
normal es que el cliente no tenga perfectamente definidas las
especificaciones del sistema, o puede ser que surjan necesidades
imprevistas.
Si se han cometido errores en una fase es difícil volver atrás.
No se tiene el producto hasta el final, esto quiere decir que:
Si se han cometido errores en una fase es difícil volver atrás.
No se tiene el producto hasta el final, esto quiere decir que:
- Si se comete un error en la fase de análisis no lo descubrimos hasta la entrega, con el consiguiente gasto inútil de recursos.
- El cliente no verá resultados hasta el final, con lo que puede impacientarse .
- El cliente no verá resultados hasta el final, con lo que puede impacientarse .
No se tienen indicadores fiables del progreso del trabajo (síndrome del 90%).
Es comparativamente más lento que los demás y el coste es mayor también.
Ciclos de vida en cascada: Tipos de proyectos para los que es adecuado
Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniería.
Se está desarrollando un tipo de producto que no es novedoso.
Proyectos complejos que se entienden bien desde el principio
Se está desarrollando un tipo de producto que no es novedoso.
Proyectos complejos que se entienden bien desde el principio
En cascada con subproyectos
Si
una vez que se ha llegado al diseño arquitectónico, se comprueba que el
sistema se divide en varios subsistemas independientes entre sí, sería
razonable suponer que a partir de ese punto cada uno se puede
desarrollar por separado y en consecuencia en paralelo con los demás.
Cada uno tendrá seguramente fechas de terminación distintas.
Una vez que han terminado todos se integran y se prueba el sistema en su conjunto. La ventaja es que se puede tener a más gente trabajando en paralelo de forma eficiente. El riesgo es que existan interdependencias entre los subproyectos.
Cada uno tendrá seguramente fechas de terminación distintas.
Una vez que han terminado todos se integran y se prueba el sistema en su conjunto. La ventaja es que se puede tener a más gente trabajando en paralelo de forma eficiente. El riesgo es que existan interdependencias entre los subproyectos.
En cascada incremental
En
este caso se va creando el sistema añadiendo pequeñas funcionalidades.
Cada uno de los pequeños incrementos es parecido a lo que ocurre dentro
de la fase de mantenimiento.
La ventaja de este método es que no es necesario tener todos los requisitos en un principio. El inconveniente es que los errores en la detección de requisitos se encuentran tarde.
Hay dos partes en el ciclo de vida, similares al anterior. Por un lado estáel análisis y el diseño global. Por otra parte están los pequeños incrementos, con las fases de diseño detallado, codificación y mantenimiento.
La ventaja de este método es que no es necesario tener todos los requisitos en un principio. El inconveniente es que los errores en la detección de requisitos se encuentran tarde.
Hay dos partes en el ciclo de vida, similares al anterior. Por un lado estáel análisis y el diseño global. Por otra parte están los pequeños incrementos, con las fases de diseño detallado, codificación y mantenimiento.
En V
Propuesto por Alan Davis, tiene las mismas fases que el anterior pero se considera el nivel de abstracción de cada una.
Una fase además de utilizarse como entrada para la siguiente, sirve para validar o verificar otras fases posteriores.
Una fase además de utilizarse como entrada para la siguiente, sirve para validar o verificar otras fases posteriores.
Tipo sashimi
Según el modelo en cascada puro una fase solo puede empezar cuando ha terminado la anterior.
En este caso sin embargo, se permite un solapamiento entre fases.
Por ejemplo, sin tener terminado del todo el diseño se comienza a implementar. El nombre ``sashimi'' deriva del modo del estilo de presentación de rodajas de pescado crudo en Japón.
Una ventaja de este modelo es que no necesita generar tanta documentación como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases.
Los problemas planteados son:
En este caso sin embargo, se permite un solapamiento entre fases.
Por ejemplo, sin tener terminado del todo el diseño se comienza a implementar. El nombre ``sashimi'' deriva del modo del estilo de presentación de rodajas de pescado crudo en Japón.
Una ventaja de este modelo es que no necesita generar tanta documentación como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases.
Los problemas planteados son:
Es aún más difícil controlar el progreso del proyecto debido a que los finales de fase ya no son un punto de referencia claro.
Al hacer cosas en paralelo si hay problemas de comunicación pueden surgir inconsistencias.
La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios, tipo de tecnología y el tipo de ciclo de vida.
El diseño arquitectónico es el de alto nivel, el detallado el de bajo nivel.
La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios, tipo de tecnología y el tipo de ciclo de vida.
El diseño arquitectónico es el de alto nivel, el detallado el de bajo nivel.
Propuesto inicialmente por Boehmen 1988.
Consiste en una serie de ciclos que se repiten.
Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior.
En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo.
Un riesgo puede ser muchas cosas:
requisitos no comprendidos, mal diseño, errores en la implementación, etc.
Consiste en una serie de ciclos que se repiten.
Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior.
En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo.
Un riesgo puede ser muchas cosas:
requisitos no comprendidos, mal diseño, errores en la implementación, etc.
En cada iteración Boehmrecomienda recopilar la siguiente lista de informaciones:
Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc.
Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista
–Características del producto.
–Formas de gestionar el proyecto.
–Formas de gestionar el proyecto.
Restricciones:
–Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc.
–Desde el punto de vista organizativo: Coste, tiempo, personal, etc.
–Desde el punto de vista organizativo: Coste, tiempo, personal, etc.
Riesgos: Lista de riesgos identificados.
Resolución de riesgos: La técnica más usada es la construcción de prototipos.
Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.
Planes: Lo que se va a hacer en la siguiente fase.
Compromiso: Decisiones de gestión sobre como continuar.
Resolución de riesgos: La técnica más usada es la construcción de prototipos.
Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.
Planes: Lo que se va a hacer en la siguiente fase.
Compromiso: Decisiones de gestión sobre como continuar.
Al
terminar una iteración se comprueba que lo que se ha hecho
efectivamente cumple con los requisitos establecidos, también se
verifica que funciona correctamente.
El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento.
Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo
El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento.
Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo
Modelo de ciclo de vida en espiral Ventajas:
No necesita una definición completa de los requisitos para empezar a funcionar.
Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.
El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteración (las anteriores iteraciones están bien).
El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.
Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.
El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteración (las anteriores iteraciones están bien).
El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.
Modelo de ciclo de vida en espiral Inconvenientes
Es difícil evaluar los riesgos.
Necesita de la participación continua por parte del cliente.
Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.
Necesita de la participación continua por parte del cliente.
Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.
Modelo de ciclo de vida en espiral Dónde es adecuado
Proyectos donde sea importante el factor riesgo.
Cuando no sea posible definir al principio todos los requisitos.
No hay comentarios:
Publicar un comentario