EL MODELO BASADO EN 

REUTILIZACIÓN

El modelo basado en reutilización se basa en la existencia de un número significante de componentes reutilizables, cuales se integran en el sistema, más que desarrollarlos desde cero. Aunque en la mayoría de los proyectos software existe algo de reutilización de software, habitualmente esta es una reutilización informal, “empírico”.

Las personas que trabajan en el proyecto buscan diseños o códigos similares para modificarlos a lo requerido e incorporarlos en el sistema. El enfoque orientado a reutilización se compone de un gran número de componentes de software reutilizable, así como de marcos de trabajos para estos:

·         Definición de requerimientos

·         Análisis de componentes

·         Modificación de requerimientos

·         Diseño de sistemas con reutilización

·         Desarrollo e integración

·         Validación del sistema

La primera y la última etapa del proceso son similares pero las etapas intermedias son distintas:

Análisis de componentes: se buscan componentes para implementar la especificación de requerimientos.

Modificación de requerimientos: los requerimientos se modifican para reflejar los componentes disponibles; si eso no es posible, se buscan soluciones alternativas

Diseño de sistemas con reutilización: se diseña o se reutiliza un marco de trabajo para el sistema, tomando en cuenta los componentes disponibles; si no hay componentes adecuados, se diseñan otros nuevos.

Desarrollo e integración: los componentes disponibles se compran, los componentes no-disponibles se desarrollan y todos los componentes y los sistemas se integran

El desarrollo basado en reutilización.

Ventajas

·     El modelo orientado a reutilización reduce la cantidad de software a desarrollarse, los costos y los riesgos

·    El proceso es más rápido

Desventajas  

·         Los compromisos en los requerimientos son inevitables.

·         Existiendo el peligro de obtener un sistema que no cumple las necesidades reales de los usuarios

Linkografia: http://es.slideshare.net/rolmary/1-presentacion1ingenieriadesoftware1

EL MODELO INCREMENTAL

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

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

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. 
• Este es el enfoque más realista actualmente.

MODELO EVOLUTIVO

MODELO EVOLUTIVO

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de operación. Los modelos “Iterativo Incremental” y “Espiral” (entre otros) son dos de los más conocidos y utilizados del tipo evolutivo.
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado.Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

Existen dos tipos de desarrollo evolutivo:

·Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.

·Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.

VENTAJAS

· La especificación puede desarrollarse de forma creciente.

· Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.

·Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.


DESVENTAJAS

· Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.

·Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.

·Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.


Linkografia:http://jorgetrejos.blogspot.com/2010/08/modelo-evolutivo.html

MODELO EN CASCADA

Este es el más básico de todos los modelos y ha servido como bloque de construcción para los demás paradigmas de ciclo de vida. Está basado en el ciclo convencional de una ingeniería y su visión es muy simple: el desarrollo de software se debe realizar siguiendo una secuencia de fases. Cada etapa tiene un conjunto de metas bien definidas y las actividades dentro de cada una contribuyen a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la misma. El arquetipo del ciclo de vida abarca las siguientes actividades:

1. Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.
2. Análisis de los requisitos del software: el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software debe comprender el ámbito de la información del software así como la función, el rendimiento y las interfaces requeridas.
3. Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa; la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación.
4. Codificación: el diseño debe traducirse en una forma legible para la maquina. Si el diseño se realiza de una manera detallada, la codificación puede realizarse mecánicamente.
5. Prueba: una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.
6. Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debidos a que se haya encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos) o a que el cliente requiera ampliaciones funcionales o del rendimiento.

En el modelo vemos una ventaja evidente y radica en su sencillez, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software. Pero el modelo se aplica en un contexto, así que debemos atender también a él y saber que:

• Los proyectos reales raramente siguen el flujo secuencial que propone el modelo. Siempre hay iteraciones y se crean problemas en la aplicación del paradigma.
• Normalmente, al principio, es difícil para el cliente establecer todos los requisitos explícitamente. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos.
• El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto no estará disponible una versión operativa del programa. Un error importante que no pueda ser detectado hasta que el programa esté funcionando, puede ser desastroso.

Linkografia: http://librosweb.es/libro/tdd/capitulo_1/modelo_en_cascada.html

CICLO DE VIDA DE UN SISTEMA 

DE INFORMACIÓN

Un sistema de información es un sistema, automatizado o manual, que engloba a personas, máquinas y/o métodos organizados para recopilar, procesar, transmitir datos que representan información. Un sistema de información engloba la infraestructura, la organización, el personal y todos los componentes necesarios para la recopilación, procesamiento, almacenamiento, transmisión, visualización, denominación y organización de la información.

Linkografia: http://flanagan.ugr.es/docencia/2005-2006/2/apuntes/ciclovida.pdf