viernes, 13 de noviembre de 2015

CICLO DE VIDA DE UN SISTEMA DE INFORMACION

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.
Según James Senn, 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.


jueves, 12 de noviembre de 2015

MODELO  IMCREMENTAL

El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos. En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. 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 elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.
El Modelo Incremental se puede ver aquí en forma grafica:
Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.
El usuario se involucra más.
- Difícil de evaluar el coste total.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
Pipeline
La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior.Esta arquitectura es muy común en el desarrollo de programas para el intérprete de comandos, ya que se pueden concatenar comandos fácilmente con tuberías (pipe).También es una arquitectura muy natural en el paradigma de programación funcional, ya que equivale a la composición de funciones matemáticas.
Interprete de comandos
Parte fundamental de un sistema operativo que ordena la ejecución de mandatos obtenidos del usuario por medio de una interfaz alfanumérica.
Características
- Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.
- El usuario se involucre más.
- Difícil de evaluar el costo total.
- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se detectan tarde.
- El resultado puede ser muy positivo.
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.
- Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
- Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.
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 DE REUTILIZACION
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
-Disminución de errores
-Disminución 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 modificaciones.


Modelo_puro..png
Modelo puro
Modelo_real..png
MODELO  ESPIRAL  EVOLUTIVO

 El modelo en espiral, propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado.

El modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.


-Comunicación con el cliente: Las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
-Planificación: Las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto.
-Análisis de riesgos: Las tareas requeridas para evaluar riesgos técnicos y de gestión.
-Ingeniería: Las tareas requeridas para construir una o más representaciones de la aplicación.
-Construcción y acción: Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentación y práctica).
-Evaluación del cliente: Las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.
Cada una de las regiones está compuesta por un conjunto de tareas del trabajo, llamado conjunto de tareas, que se adaptan a las características del proyecto que va a emprenderse. Para proyectos pequeños, el número de tareas de trabajo y su formalidad es bajo. Para proyectos mayores y más críticos cada región de tareas contiene tareas de trabajo que se definen para lograr un nivel más alto de formalidad. En todos los casos, se aplican las actividades de protección (por ejemplo: gestión de configuración del software y garantía de calidad del software).
Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral puede producir el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software. Cada paso por la región de planificación produce ajustes en el plan del proyecto.
El coste y la planificación se ajustan con la realimentación ante la evaluación del cliente. Además, el gestor del proyecto ajusta el número planificado de iteraciones requeridas para completar el software.
El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software a gran escala. Como el software evoluciona, a medida que progresa el proceso el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto, y, si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemáticos. Pero al igual que otros paradigmas, el modelo en espiral no es la panacea. Puede resultar difícil convencer a grandes clientes (particularmente en situaciones bajo contrato) de que el enfoque evolutivo es controlable.

 MODELO EVOLUTIVO
Un componente es una pieza de código pre-elaborado que encapsula alguna funcionalidad expuesta a través de interfaces estándar.

Etapas del modelo evolutivo Basado en Componentes

PLANEACION: En esta etapa evalúa la función y el rendimiento que se asignaron al Software durante la Ingeniería del Sistema de Computadora para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible.

ANÁLISIS DE RIESGOS: en esta etapa l analista se encarga de analizar los riesgos que el software a crear estará expuesto y así encontrar la manera de corregirlos.

CONSTRUCCIÓN Y ADAPTACIÓN DE LA INGENIERÍA: en esta etapa se construye el software, se prueba si no tiene algún problema o para detectar errores, se instala , y luego se le brinda soporte al cliente.

VALUACIÓN DEL CLIENTE: el cliente tiene la tarea de evaluar el software para verificar si este cumple con los requisitos que este proporciono y esta en todo la tarea de aprobar o rechazar el software.
Características
Es evolutivo
Posee un enfoque evolutivo para la creación de software
Comienza con la identificación de las clases más importantes
Examina los datos que se van a manejar
Permite la reutilización del software
El ensamblaje de los componentes reduce el 70 del 100% del tiempo del ciclo del desarrollo del software y un 84 del 100% del costo del proyecto.

martes, 10 de noviembre de 2015

MODELO EN 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.1
>>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 diseñ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 amplia mente 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 complementació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 re utilizables 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 creación de desarrollo de cascada se implementa los códigos de investigación y pruebas 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.

LA VIDA NO SE HA HECHO PARA COMPRENDERLA SI NO PARA VIVIRLA