ciclo de vida de un sistema informatico

fases del ciclo de vida de un sistema informatico

Es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario.

 

 

FASES

Cualquier sistema de información va pasando por una serie de fases a lo largo de su vida. Su

ciclo de vida comprende una serie de etapas entre las que se encuentran las siguientes:

- Planificación
- Análisis
- Diseño
- Implementación
- Pruebas
- Instalación o despliegue
- Uso y mantenimiento

Estas etapas son un reflejo del proceso que se sigue a la hora de resolver cualquier tipo de

problema.

- Comprender el problema (análisis)

- Plantear una posible solución, considerando soluciones alternativas (diseño)
- Llevar a cabo la solución planteada (implementación)
- Comprobar que el resultado obtenido es correcto (pruebas)

 

Planificación:

Comienza con un pedido escrito llamado “system request”, que identifica el sistema de información y los cambios deseados. Pueden ser cambios mayores (un nuevo sistema) o cambios menores (un reporte). El propósito de la fase de planificación es identificar claramente la naturaleza y el alcance del problema. Se requiere una investigación preliminar y el resultado se llama Informe de Investigación Preliminar. La investigación preliminar también es conocida como Estudio de Viabilidad.

 

analisis

en esta fase se recopilan y analizan los datos acerca del sistema y su funsionamiento aplicando cuestiones , entrevistas, encuestas, en general las tecnicas de recopilasion de datos

Especifica que es lo que el sistema debe hacer.

 

 

 

Desarrollo

El propósito de esta fase es desarrollar un diseño (cómo va a quedar) del sistema de información que satisfaga todos los requisitos documentados. Se determina qué va a hacer el sistema. Se identifican las entradas , salidas , archivos, programas, procedimientos y controles del sistema. El documento creado se llama Especificaciones del Diseño del Sistema y debe ser aprobado por la gerencia y los usuarios.

- Pruebas

Luego de que la compañía esté utilizando el sistema, a veces es necesario realizar cambios al sistema para hacer mantenimiento o mejoras. Los cambios de mantenimiento son para corregir errores o adaptar el sistema a requisitos del gobierno u otras entidades. Las mejoras son modificaciones para aumentar la capacidad del sistema, como nuevos reportes.

 - implemetacion

Los programas son escritos, probados y documentados. El propósito de esta fase es entregar un sistema de información completo y documentado, que haya sido revisado y aprobado por la gerencia y usuarios.  Los preparativos finales incluyen la conversión de datos, adiestramientos y la transición del sistema viejo al nuevo. En esta fase se debe realizar una evaluación del sistema luego de implantado para verificar costo-beneficio. El resultado final de la fase de implantación es un sistema listo para usarse.

 

instalacion

en este proseso ye lleva a cavo dichas configurasiones atraves de CD con la informasion.

 

Se trata de tener un sistema instalado con un conjunto de aplicaciones software para diferentes usos. El proyecto básico significa instalar en un PC Windows y Linux con las siguientes características:

• Uso de Servicios Internet: cliente POP/IMAP de correo que soporte multicuentas y navegador Web. Además deben estar en español y hay que personalizar la presentación (Temas o Skins)
• Uso de Aplicación ofimática que permita realizar documentos de texto con formato, hojas de cálculo y presentaciones de diapositivas.
• Uso de Aplicación de Mensajería Instantánea que soporte los protocolos/cuentas de MSN messenger, Yahoo Messenger y Jabber
• Edición Avanzada de archivos de texto
• Reproducción Multimedia de Audio y de Video

El sistema se deberá instalar en un hardware que debe funcionar y que hay que revisar. Además de esta propuesta básica, para algunos alumnos se admiten diferentes  propuestas. Ha de ser un proyecto de menos de 60 horas.

 

 

 

 

 

uso / Mantenimiento

“Una vez que un sistema pasa a formar parte de la vida diaria de la empresa, cada programa, cada procedimiento y cada estructura de datos se convierte en una pieza del negocio que, como tal, deberá funcionar en forma constante, exacta y confiable. L a operación del negocio ahora dependerá del funcionamiento del sistema, por lo que las tareas de mantenimiento cobran vital importancia.

Durante la fase de mantenimiento, se ponen en práctica todas las políticas y los procedimientos destinados a garantizar la operación continúan de los de los sistemas y a asegurar su uso efectivo, con el fin, de que éstos se constituyan en una verdadera herramienta de apoyo al logro de los objetivos estratégicos de la empresa

Modelo Incremental

El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollocomo una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:

• Método de las comparaciones limitadas sucesivas.
• Ciencia de salir del paso.
• Método de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.

En una visión genérica, el proceso se divide en 4 partes:

• Análisis
• Diseño
• Código
• Prueba

Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.

Ventajas:

• Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.
• También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software.
• El modelo proporciona todas las ventajas del modelo en Cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
• Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

Desventajas:

• El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de alto índice de riesgos.
• Requiere de mucha planeación, tanto administrativa como técnica.
• Requiere de metas claras para conocer el estado del proyecto.

Modelo basado en Reutilización

 Editar 2 129…

MODELO BASADO EN REUTILIZACIÓN

Introducción al modelo

El diseño basado en reutilización puro busca construir un producto software integrando componentes pre-existentes.
Los beneficios principales que otorga este modelo son:
-Tiempos de desarrollos cortos
-Disminucion de errores
-Disminucion de costos y riegos ya que se reduce los componentes a desarrollar
-Existe un aumento de la confiabilidad ya que los componentes a utilizar ya fueron testeados y utilizados en otro momento previo al comienzo del proyecto

A modo de desventaja podemos mencionar el hecho de que al no poseer algún componente que cubra con un requisito dado por el usuario, este debe ser modificado para adaptarlo a los componentes almacenados en el repositorio de componentes.
Esto se da en el modelo puro. En cambio en el modelo real si no se puede adaptar un requisito de usuario, se conseguirá o se desarrollara ese modulo para que cumpla con lo pedido por el usuario.
Otra desventaja de este modelo es que una vez finalizada la etapa de modificación de requisitos, y ante la eventual necesidad de cambios en estos ultimos, puede pasar que no haya componentes que se adapten a las nuevas moficicaciones.

modelo de cascada

modelo de cascada
En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.¹

Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos.
2. Diseño del Sistema.
3. Diseño del Programa.
4. Codificación.
5. Pruebas.
6. Implantación.
7. Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.

Análisis de requisitos

En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.

Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.

Diseño del Sistema

Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.

Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la organización del código para comenzar la implementación.

Diseño del Programa

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

Codificación

Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así como de pruebas y ensayos para corregir errores.

Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

Pruebas

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.

  Verificación                      

Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle.

En la creacion de desarrollo de cascada se implementa los codigos de investigacion y puebas del mismo

Mantenimiento

Una de las etapas mas criticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

imagen

modelo espiral evolutivo

 MODELO ESPIRAL EVOLUTIVO
 El modelo espiral en el desarrollo del software es un modelo meta del ciclo de vida del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un esfuerzo del desarrollo por ahí mismo comienza otro; además en cada ejecución del desarrollo se sigue cuatro pasos principales: 1. Determinar o fijar los objetivos. En este paso se definen los objetivos específicos para posteriormente identifica las limitaciones del proceso y del sistema de software, además se diseña una planificación detallada de gestión y se identifican los riesgos. 2. Análisis del riesgo. En este paso se efectúa un análisis detallado para cada uno de los riesgos identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y luego del análisis de estos riesgos se planean estrategias alternativas. 3. Desarrollar, verificar y validar. En este tercer paso, después del análisis de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo desarrolla. 4. Planificar. En este último paso es donde el proyecto se revisa y se toma la decisión si se debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto. Ver fig1 anexos Con cada iteración alrededor de la espiral, se crean sucesivas versiones del software, cada vez más completas y, al final, el sistema de software ya queda totalmente funcional. La diferencia principal entre el modelo espiral y los modelos anteriores (ej.: cascada, evolutivo, incremental, etc.) es la evaluación del riesgo. El riesgo es todo lo que pueda salir mal en un proyecto de desarrollo de software. Por ejemplo, si queremos utilizar un lenguaje de programación para desarrollar un sistema operativo, un riesgo posible es que los compiladores utilizables no produzcan un código objeto eficiente. Los riesgos originan problemas en el proyecto, como el exceso de los costos. Es así que, la disminución de los riesgos es una actividad muy importante. Un modelo espiral comienza con la determinación de los objetivos tanto funcionales como de rendimiento. Después se enumeran algunas formas posibles de alcanzar estos objetivos identificando las fuentes de riesgos posibles. Luego continuamos con el siguiente paso que es resolver estos riesgos y llevar a cabo las actividades de desarrollo, para finalizar con la planificación del siguiente ciclo de la espiral. Ver fig2 anexos 
CARACTERÍSTICAS DEL MODELO EN ESPIRAL PARA EL DESARROLLO DE SOFTWARE Es considerado como un modelo evolutivo ya que combina el modelo clásico con el diseño de prototipos. Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente. Este modelo es el indicado para desarrollar software con diferentes versiones actualizadas como se hace con los programas modernos de PC´s. La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos. Ver fig. 3 anexos Este es el enfoque más realista actualmente. El modelo en espiral esta compartida en varias actividades estructurales, también llamadas regiones de tareas. Existen seis regiones de tareas que son: Comunicación con el cliente: esta es una tarea requerida para establecer comunicación entre el desarrollador y el cliente. Planificación: esta tarea es necesaria aplicarla para pode definir los recursos, el tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los requerimientos. Análisis de riesgos: esta es una de las tareas principales por lo que se aplica el modelo en espiral, es requerida para evaluar los riesgos técnicos y otras informaciones relacionadas con el proyecto. Ingeniería: esta es una tarea necesaria ya que se requiere construir una o más representaciones de la aplicación. Construcción y adaptación: esta tarea es requerida en el modelo espiral porque se necesita construir, probar, instalar y proporcionar soporte al usuario. Evaluación el cliente: esta también es una tarea principal, necesaria para adquirir la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería y la de implementación creada durante la etapa de instalación. VENTAJAS DEL MODELO ESPIRAL No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad. En la terminación de un producto desde el final de la primera iteración es muy factible aprobar los requisitos. Sufrir retrasos corre un riesgo menor, por que se comprueban los conflictos presentados tempranamente y existe la forma de poder corregirlos a tiempo. 
DESVENTAJAS DEL MODELO ESPIRAL Existe complicación cuando se evalúa los riesgos. Se requiere la participación continua por parte del cliente. Se pierde tiempo al volver producir inicialmente una especificación completa de los requerimientos cuando se modifica o mejora el software. 
ACOPLAMIENTOS DEL MODELO ESPIRAL Los nuevos requerimientos del sistema se definen en todo los detalles posibles, esto implica generalmente el entrevistarse con un número determinado de usuarios que representarán a todos los usuarios tanto externos como internos y otros aspectos del sistema existente. Un prototipo preliminar se crea para el desarrollo del nuevo software partiendo de un diseño hecho del sistema que se construyó del prototipo inicial. Esto es generalmente un sistema scaled-down, y representa una aproximación de las características del producto final. Un segundo diseño de software es desarrollado por un procedimiento cuádruple: Evaluación del primer prototipo en términos de sus fuerzas, debilidades, y riesgos; Definir los requisitos del segundo prototipo; Planeando y desarrollando el segundo prototipo; Construyendo y probando el segundo prototipo. En la opción del cliente, el proyecto completado puede ser abortado si el riesgo se juzga demasiado grande. Los factores de riesgo pudieron implicar los excesos de coste del desarrollo, cálculo erróneo del fusionar los costes, o cualquier otro factor que podría, en el juicio del cliente, dar lugar a un producto final menos que satisfactorio. El diseño existente se evalúa de manera semejante al igual que el diseño anterior, y, en caso de necesidad, otro prototipo se desarrolla de él según el procedimiento cuádruple expuesto anteriormente. Se iteran los pasos precedentes hasta que el cliente está satisfecho sabiendo que el diseño mejorado representa el producto final deseado. Además, se construye el sistema final, basado en el diseño mejorado. El sistema final se evalúa y se prueba con todas las de ley. El mantenimiento general se realiza sobre una base continua para prevenir fallas en grande y para reducir al mínimo el tiempo perdido. 
CONCLUCIÓN El prototipo del modelo en espiral para la ingeniería de software es en la actualidad el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel del modelo en espiral. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos. 
BIBLIOGRAFÍA http://es.wikipedia.org/wiki/Desarrollo_en_espiral http://www.compute-rs.com/es/consejos-362625.htm http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf http://es.wikipedia.org/wiki/Software#Proceso_de_creaci.C3.B3n_del_software http://148.202.148.5/cursos/cc321/fundamentos/unidad1/espiral.htm

MODELO EN ESPIRAL

MODELO EN ESPIRAL

MODELO EN ESPIRAL

Este modelo fue propuesto por Boehm en 1988. Básicamente consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada ciclo de la espiral se sigue un Modelo Cascada, pero no necesariamente debe ser así.

En cada vuelta o iteración hay que tener en cuenta

Los Objetivos: Que necesidad debe cubrir el producto.

Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:

Características: experiencia del personal, requisitos a cumplir, etc.

Formas de gestión del sistema.

Riesgo asumido con cada alternativa.

Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades

Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:

Angular: Indica el avance del proyecto software dentro de un ciclo.

Radial: Indica el 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 grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo.

Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.

Tareas

Para cada ciclo habrá cuatro actividades:

Determinar o fijar objetivos

·         Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.

·         Fijar las restricciones.

·         Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.

·         Hay una cosa que solo se hace una vez: planificación inicial o previa.

Análisis del riesgo:

Desarrollar, verificar y validar

·         Tareas de la actividad propia y de prueba.

·         Análisis de alternativas e identificación resolución de riesgos.

·         Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc.

Planificar

Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.

Ventajas

El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.

Reduce riesgos del proyecto

Incorpora objetivos de calidad

Integra el desarrollo con el mantenimiento, etc.

Desventajas

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificación de riesgos.

APRECIA LO QUE TIENES EN LA VIDA POR QUE NO SABES CUANDO SE LO PUEDE PERDER