miércoles, 11 de noviembre de 2015

CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN

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.

MODELO BASADO A REUTILIZACION

El diseño basado en reutilizacion 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 puro

Modelo real

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 reutilizan 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.

Ventajas / Desventajas

Ventajas	Desventajas
Reutilizan del software. Simplifica las pruebas; pues estas se le hacen a los componentes antes de probar el conjunto completo de componentes ensamblados. Simplifica el mantenimiento del sistema. Mayor calidad.	Genera mucho tiempo en el desarrollo del sistema. Modelo costoso . Requiere experiencia en la identificación de riesgos. Genera mucho trabajo adicional.

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.

Requiere una considerable habilidad para la evaluación del riesgo, y cuenta con esta habilidad para el éxito. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas. Finalmente, el modelo no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. Todavía tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.

MODELO INCREMENTAL

El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollo como 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.

El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la entrega de un producto completamente operacional. Este modelo 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.

De este modo podemos terminar una aplicación ejecutable (primera versión) que podrá ser entregada al cliente para que éste pueda trabajar en ella y el programador pueda considerar las recomendaciones que el cliente efectúe para hacer mejoras en el producto. Estas nuevas mejoras deberán esperar a ser integradas en la siguiente versión junto con los demás requerimientos que no fueron tomados en cuenta en la versión anterior.El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino únicamente corrección de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo.Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las funcionalidades que proporcionará el sistema. Se confecciona un bosquejo de requisitos funcionales y será el cliente quien se encarga de priorizar que funcionalidades son mas importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que el sistema entregará. La asignación de funcionalidades a los incrementos depende de la prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el primer incremento.

Características:

Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.
El usuario se involucra mas.
Dificil de evaluar el costo total.
Dificil 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 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.
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.

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.¹

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

Análisis de requisitos.
Diseño del Sistema.
Diseño del Programa.
Codificación.
Pruebas.
Implantación.
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.