Ciclo de vida de los sistemas de información
Procesos por el cual los analistas de sistemas, los ingenieros de software, los programadores y los usuarios elaboran sistemas de información y aplicaciones informáticas.
El ciclo de vida de un sistema de información 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. existen tres estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por análisis estructurado y el método de construcción de prototipos de sistemas. Cada una de estas estrategias tienen un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada.
En el siguiente vídeo nos da una introducción mas clara sobre que es el ciclo de vida de los sistemas de información
Modelos de Desarrollo de Software
Los modelos de desarrollo de software son una representación abstracta de una manera en particular. Realmente no representa cómo se debe desarrollar el software, sino de un enfoque común. Puede ser modificado y adaptado de acuerdo a las necesidades del software en proceso de desarrollo. Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debería escoger el más apropiado para sus necesidades. En ocasiones puede que una combinación de varios modelos sea apropiado.
En el siguiente vídeo se muestran otros modelos de desarrollo de software don explica características, ventajas, desventajas y como utilizar cada uno de los modelos.Modelo de cascada
El modelo de cascada define las siguientes etapas que deben cumplirse de forma sucesiva:
- Especificación de requisitos
- Diseño del software
- Construcción o Implementación del software
- Integración
- Pruebas (o validación)
- Despliegue (o instalación)
- Mantenimiento
Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo desaconseja revisita y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles.
Modelo Estructurado
Las siguientes etapas deben cumplirse de forma sucesiva ya que son faces con mayor especificación cada una de ellas complementa a la otra, ya que las encuestas en este modelo son importantes para saber con mayor criterio las necesidades del usuario y el análisis se lleve mas a fondo y tenga un control de calidad eficiente para los procedimientos de cada una de las etapas de este modelo y la instalación se lleve a cabo con mas seguridad y satisfaciendo necesidades.
- Encuestas.
- Análisis.
- Diseño.
- Implementacion.
- Pruebas.
- Control de calidad.
- Procedimientos.
- Conversión B.D.
- Instalación.
Modelo Espiral
El modelo de espiral define las siguientes etapas que deben cumplirse de forma sucesiva:
- Especificación de requisitos
- Análisis de riesgo
- Prototipo 1,2.
- Requerimientos de software.
- Validación de requerimientos.
- Prototipo 3.
- Diseño de software.
- validación de diseño.
- integración y prueba.
La principal características del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala.
La espiral se visualiza como un proceso que pasa a través de algunas interacciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:
Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las opciones y limitaciones para facilitar la re utilización de software, la calidad del software puede ayudar como una meta propia en la integración en el desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:
La primera fase es la búsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para así buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso análisis, y si fuera necesario incluyendo la fabricación de un prototipo.
La espiral se visualiza como un proceso que pasa a través de algunas interacciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:
- crear planes con el propósito de identificar los objetivos del software, seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software;
- Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar como identificar y eliminar el riesgo;
- la implantación del proyecto: implantación del desarrollo del software y su pertinente verificación;
Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las opciones y limitaciones para facilitar la re utilización de software, la calidad del software puede ayudar como una meta propia en la integración en el desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:
- El énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de clientes que acepten este análisis y actúen en consecuencia.
- Para ello es necesaria confianza en los desarrolladores así como la predisposición a gastar más para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala.
- Si la implantación del riesgo de análisis afectará de forma esencial los beneficios del proyecto, no debería utilizarse este modelo.
- Los desarrolladores de software han de buscar de forma explícita riesgos y analizarlos de forma exhaustiva para que este modelo funcione.
La primera fase es la búsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para así buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso análisis, y si fuera necesario incluyendo la fabricación de un prototipo.
Modelo prototipo
las siguientes etapas de este modelo se son a un mas estrictas ya que solo cuenta con pocas etapas pero son eficientes y con un mayor énfasis en satisfacer al usuario para facilitar y reutilizarlo para un mayor desarrollo de los requerimientos básicos del usuario.
- Requerimientos básicos
- Desarrollo de prototipos
- Uso de prototipos
- Usuario satisfecho
El ciclo de vida según bibliográfia
FABREGAS
- Requerimientos
- Análisis/Diseño
- Construcción
- Pruebas
- Producción/Mantenimiento
SENN
- investigación pre-eliminar
- determinación de requerimientos
- diseño de sistemas
- desarrollo de software
- prueba del sistema
- implementacion y evaluación
PRESSMAN
- Análisis
- Diseño
- Codificación
- Prueba
- Mantenimiento
EN GENERAL USAREMOS
- Análisis
- Diseño
- Implementacion
- Mantenimiento
