MODELO ES.:

MODELO ESPIRAL:
Es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

Para cada ciclo habrá cuatro actividades:

1. Determinar Objetivos.
2. Análisis del riesgo.
3. Desarrollar y probar.
4. 'Planificación.'

DETERMINAR OBJETIVOS:

• Fijar también los productos definidos a obtener: requisitos, 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.

DESARROLLAR, VERIFICAR y VALIDAR(PROBAR):

• 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. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.

ANÁLISIS DE RIESGO:

• Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas puedan producir. Se evalúan alternativas. Se debe tener un prototipo antes de comenzar a desarrollar y probar.

MODELO E.:

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.    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 re alimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

    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.

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

CONCEPTO M.B.R:

• MODELO BASADO EN 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 testados y utilizados en otro momento previo al comienzo del proyecto
• 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 últimos, puede pasar que no haya componentes que se adapten a las nuevas modificaciones.

EN LA VIDA TIENES QUE SABER PERDER......¡PERO NO TIENES QUE SER UN PERDEDOR Y DEBES SEGUIR EN ADELANTE!

CONCEPTO M.I:

MODELO INCREMENTAL:

Es un proceso de desarrollo de software creado en respuesta a las debilidades del modelo tradicional de cascada.

Básicamente este modelo de desarrollo, que no es más que un conjunto de tareas agrupadas en pequeñas etapas repetitivas (iteraciones),¹ es uno de los más utilizados en los últimos tiempos ya que, como se relaciona con novedosas estrategias de desarrollo de software y una programación extrema, es empleado en metodologías diversas.

El proceso se divide en 4 partes:

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

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.

CONCEPTO M.C:

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.

CONCEPTO S.I:

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 y organización de la información.