Universidad: UNIDEG Juventino rosas

Carrera: ingeniería en sistemas

Materia: Ing. de software

Cuatrimestre: séptimo

Profesora: maya Gacela Villagómez Torres

Actividad de aprendizaje: Presentación “Modelos para el desarrollo de Software”.

Equipo: Luz María Gpe. Navarrete Ochoa

Citlali de Cruz García Mendoza

Dalia Griselda Sandiego Ortega.

Fecha de entrega: 25/09/2014.

Introducción

Sin duda la ingeniería de software es fundamental para lograr entender el objetivo y la organización, la ingeniería de software se ha

convertido en un desarrollo rápido de aplicaciones, que tiene un proceso muy importante a desarrollar con el software tiene un

propósito de producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. La importancia del

software es una asignatura muy básica en muchas licenciaturas y posgrados debido en el ámbito laboral como lo es durante en el

desempeño laboral tal como lo es en el profesional la aplicación del conocimiento de software.

Modelos de proceso de desarrollo de software o paradigmas

Para resolver los problemas reales de una empresa o industria, un ingeniero de software o de ingenieros debe incorporar una

estrategia de desarrollo que acompañe el proceso, los métodos, capas de herramientas y fases genéricas.

Esta estrategia se llama modelo de procesos o paradigma de ingeniería del software consiste en seleccionar un modelo de

proceso para el desarrollo de la ingeniería del software.

Es un proceso de análisis que involucra la selección de una estrategia de desarrollo que depende de:

1. La naturaleza del proyecto , el nivel de experiencia informática del usuario los recursos disponibles ($) , la duración

estimada del proyecto , el nivel de presión en las estimaciones , los métodos a emplear ,, las herramientas de desarrollo a

utilizar , los controles ,las entregas de productos que se requieran metodologías de desarrollo: las metodologías de

desarrollo más difundidas en la ingeniería de software son:

Metodologías estructuradas, aplicaciones rápidas, orientadas a objetos.

La ingeniería de software tiene varios modelos tal como: paradigmas y filosofías de desarrollo en los cuales se puede apoyar

para realización de software los cuales podemos destacar estos por ser los más utilizados y los más completos modelo en

cascada o clásico (modelo tradicional) ejemplo de unas metodología desarrollo en cascada es: análisis de requisitos, diseño del

sistema, diseño del programa, codificación, pruebas, implantación, mantenimiento. Ciclo de vida en cascada dentro de la

categoría de metodologías estructuradas encontramos el ciclo de vida tradicional / clásico sdlc y sus variantes de desarrollo

iterativo. El sldc tiene una clara secuencia lineal (cascada) en donde una etapa no se inicia hasta que la anterior estuviese

completamente terminada es el más común y antiguo de los ciclos de vida.

Modelo en espiral (modelo evolutivo) es un modelo del ciclo de vida del software fue definido por primera vez por Barry boehm en

1988 utilizado generalmente en la ingeniería de software

Modelo desarrollo por etapas: es similar al modelo de prototipos ya que se muestra al cliente real software en diferentes

sestados sucesivos de desarrollo pueden distinguirse por las siguientes fases: especiación conceptual, análisis de requerimientos

diseño inicial, diseño detallado, codificación, depuración y liberación.

Modelo iterativo y creciente o iterativo el incremental

RAD (rapid aplicación develepment)

Desarrollo concurrente

RUP modelo racional

Proceso unificado

Modelos o paradigmas de desarrollos más usados:

• Lineal, secuencial o cascada

• Prototipos

• Espiral

• Cuarta generación

• Desarrollo rápido

Estos son algunos de los modelos

Modelo cascada Modelo espiral

Busca definir los objetivos globales del sistema para luego refinar en conjunto con el cliente los requisitos específicos

modelo propotipo

Definición de Paradigma: Para la Ingeniería de Software el paradigma es una agrupación de métodos, herramientas y procedimientos con el fin de describir u modelo.

Un "paradigma" es un modelo para comprender la realidad, que nos permite relacionarnos con el mundo circundante y tener un

sentido de identidad dentro de lo que percibimos que es "el mundo real".

Fase general Descripción

De definición.

Parte fundamental del desarrollo de software.

 Identifica los requisitos clave del sistema.

 Producto final: el ERS, documento base para el control del cumplimiento de requerimientos de usuario.

De desarrollo.

Referida a cómo han de diseñarse los componentes del software.

 Comprende etapas como diseño de estructuras, modelo de requisitos, diseño de interfaz, estructura de la base de datos, codificación y prueba por parte del programador y del cliente.

De mantenimientoFase post implantación.

 Aplica las etapas de las fases de definición y desarrollo sobre el software final.

Los paradigmas de la ingeniería de software conservan estas fases generales, variando los métodos, las herramientas y procedimientos para aplicarlos. El paradigma de cascada puro presenta las siguientes ventajas y desventajas.

Ventajas Desventajas

Permite un mejor control de cada actividad, en cuanto a fechas de entrega, costos, revisiones y productos desarrollados.

Minimiza los gastos de la planificación del proyecto.

Los proyectos de software rar vez siguen un flujo secuencial.

 No involucra al usuario en el desarrollo del producto.

Requiere mucho tiempo para el desarrollo del proyecto.

Si el usuario olvida especificar un requerimiento se incurre un elevado costo.

Metodologías de desarrollo: las metodologías de desarrollo más difundidas en la ingeniería de software son:

• Metodologías estructuradas• Aplicaciones rápidas• Orientadas a objetos

MODELOS O PARADIGMAS DE DESARROLLOS MAS USADOS:

• lineal, secuencial o cascada• Prototipos• Espiral• Cuarta generación• Desarrollo rápido

Modelos en Función de Prototipos

Cuando en la etapa de análisis se necesitan de técnicas amigables para la elaboración del ERS, es recomendable el empleo de herramientas de levantamiento de información como son los prototipos o modelos previos. Los modelos previos pueden ser en papel o computadora para mostrar la interacción hombre-máquina; un modelo que muestra algunas funciones del software; o, algún software anterior (parte o todo) parecido al que se desea, que luego será modificado y adaptado según los requerimientos del usuario.

El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un << diseño rápido >>.

El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente (p. Ej.: enfoques de entrada y formatos de salida). El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y lo utiliza para refinar los requisitos del software a desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que se necesita hacer.

Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de los fragmentos del programa ya existentes o aplica herramientas (p. Ej.: generadores de informes, gestores de ventanas, etc.) que permiten generar rápidamente programas de trabajo.

El paradigma de la elaboración por prototipos resulta una alternativa para el desarrollo rápido de aplicaciones de software; pues el analista acorta en tiempo entre la determinación de los requerimientos de información y la entrega de un sistema funcional, además que el usuario podrá modificar y depurar sus requerimientos conforme avance el desarrollo del proyecto.

El paradigma de desarrollo por prototipos presenta las siguientes ventajas y desventajas.

 

Ventajas Desventajas

Permite la retroalimentación por parte del usuario.

Desarrollo rápido.

 El usuario se siente parte del grupo.

El desarrollador debe dar forma prematuramente a un sistema, incluso antes de comprender de manera básica el problema y su funcionamiento.

 El usuario puede creer que un prototipo es un software final.

El paradigma de prototipos es aplicable a proyectos de análisis acelerado, donde sólo se cuente con requisitos generales; a proyectos con clientes impacientes de ver algo funcionando; a proyectos con clientes dispuestos a reaccionar abiertamente con el prototipo. No es recomendable aplicarlo a proyectos con clientes exigentes de calidad, pues los prototipos son susceptibles a muchos fallos, y el cliente se puede formar una idea equivocada de la seriedad del desarrollador.

Tecnología de Procesos

Las herramientas de tecnología de procesos permiten que una organización de software construya un modelo automatizado de la estructura común del proceso, conjunto de tareas, y actividades de protección.

El modelo, presentado normalmente como una red, se puede analizar para determinar el flujo de trabajo típico y para examinar estructuras alternativas de procesos que pudieran llevar a un tiempo o costo de desarrollo reducidos. Una vez que se ha creado un proceso aceptable, se pueden utilizar otras herramientas de tecnología de procesos para asignar, supervisar, e incluso controlar todas las tareas de ingeniería del software definidas como parte del modelo de proceso. Cada uno de los miembros de un equipo de proyecto de software pueden utilizar tales herramientas para desarrollar una lista de control de tareas de trabajo a realizarse productos de trabajo a producirse, y actividades de garantía de calidad a conducirse.

Criterios Generales para Seleccionar un Paradigma:

El ingeniero de sistemas debe estar en capacidad de seleccionar de manera correcta la utilización de alguno de los paradigmas anteriormente mencionados o una combinación de ellos, evaluando las principales características del problema al cual se enfrentará.

Estas características se deben captar en la fase de análisis general del sistema y deberán reforzarse en la etapa de análisis detallado del sistema. Como puntos de evaluación para la selección del paradigma adecuado tenemos:

La naturaleza del proyecto, donde se agrupan criterios como la complejidad del producto final, el conocimiento de la aplicación por parte del grupo, la utilización final del software, etc.

El control del proyecto y la importancia de los avances, directamente relacionado con las características del cliente, sus perspectivas y deseos respecto al software, la importancia de su inclusión en el grupo de desarrollo del producto, etc.

Los métodos y las herramientas disponibles para el desarrollo de cada una de las fases a realizar

Cuadro comparativo modelos para el desarrollo de software

Nombre del modelo

definición Descripción o característica

ventajas desventajas Lugares de aplicación

Modelo en cascada i lineal secuencial

Llamado ciclo de vida básico o modelo de cascada, es un enfoque sistemático secuencial comienza en un nivel de sistemas y progresa con el análisis, codificación, pruebas y mantenimiento.

El modelo también puede denominado en un ciclo de vida clásico y modelos lineales secuenciales.Consiste en la ejecución secuencial de una serie de fases que se suceden, lo que da nombre a los modelos.Cada fase no comienza hasta que la anterior ha terminado.Se disponga de unos requisitos completos y consistentes al principio del desarrollo.Sea un proyecto pequeño en el que el periodo de congelación de los requisitos es corto, o

Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor que ninguno.Facilita la gestión del desarrollo.

En general establecer todos los requisitos al principio del proceso de desarrollo es un mito inalcanzable, los usuarios no pueden imaginarse lo que hasta que no ven un sistema funcionado.Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado cambio, todo cambia.El usuario debe esperar mucho tiempo hasta ver los resultadosLos errores de análisis y diseño son costosos de eliminar, y se propagan a las fases siguientes con un efecto conocido como bola de nieve.Se genera mucho mantenimiento inicial debido al periodo de congelación de requisitos y este recae, en su mayor parte.

Este modelo es ampliamente utilizado en los sistemas gubernamentales de gran tamaño, en especial en el departamento de defensa de los estados unidos (DOD).Esta utilizado en la NASA

un proyecto con unos requisitos bastantes estables.

Modelo en cascada

también llamado modelo en cascada (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), 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

En esta etapa, se establece los requerimientos del productivo que se desea desarrollar. Estos consisten usualmente en los servicios que deben proveer, limitaciones y metas del software.Esta etapa incluye también un estudio de la factibilidad y viabilidad del proyecto con el fin de determinar la convivencia de la puesta en marcha del proceso de la apuesta en marcha del proceso de desarrollo. Puede ser tomada como la concepción de un producto de software y ser vista como el comienzo del ciclo de vida.

La panificación es sencillaLa calidad del producto resultante es alta Permite trabajar con personal poco calificado

Lo peor es la necesidad de tener todos los requisitos a los principios. Lo normal es que el cliente no tenga perfectamente definidas las especificaciones del sistema o puede ser que surjan necesidades imprevistasSi se han cometido errores en una fase difícil volver a trasNo se tiene el producto hasta esto quiere decir que:Si se comete un error en la fase de análisis no lo descubrimos hasta la entrega, con el consiguientes gasto inútil de recursos.El cliente no vera resultados hasta el final con lo que puede impacientarse.Es competitivamente más lento que los demás y el coste es mayor también.

Es para aquellos que se dispone de todas especificaciones desde el principio, por ejemplo, los de reingenieríaSe está desarrollando un tipo de producto que no es novedosoProyectos complejos que se entienden bien desde el principio.

Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida

Modelo en espiral

Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a través de las fases de análisis de las

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 aplica a cualquier proyecto sin importar el tamaño.Permite evaluar si el ciclo que se va a hacer, aporta algo o no (reducción de riesgos).

No es una técnica deaprendices

Es una técnica muy demorada

Para obtener un producto final.Debe existir un control para el

númerode ciclos necesariospara obtener el producto final

Modelo en espiral sirve como la mejor opción para las empresas con los objetivos empresariales volátiles, pero donde hay una necesidad de que el prototipo para manejar las complejidades de los

necesidades, el diseño, implantación, pruebas (validación), la integración, y mantenimiento.

se producen versiones cada vez más completas del sistema diseñado.

Se mejora lacalidad con el tiempo (mientrasmásTiempo pase mejor).

procedimientos de negocio. Esto fue sobre las ventajas y desventajas del modelo en espiral y los pasos en espiral modelo de desarrollo. Espero que este artículo te ha ayudado con los pros y los contras del modelo en espiral.

Modelo incremental

Este modelo incrementa y combina los modelos Este modelo incrementa se conoce también bajo las siguientes denominaciones:Métodos de las comparaciones limitadas sucesivas.Ciencia de salir del paso Método de atacar el

Se evitan largos y se entrega algo de valor a los usuarios con cierta frecuencia.El usuario se involucra masDifícil de evaluar el costo totalDifícil aplicar a los sistemas transacciones que tienden a ser integrados y a operar como un todo.Requiere gestores experimentados Los errores en los requisitos se detectan

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

El modelo incrementa no es recomendable para casos de sistemas de tiempo real, de alto nivel se 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.

El modelo permite una implementación con refinamientos sucesivos (ampliación y/o mejoras).Con cada incremento se agrega nuevas funcionalidad o se nuevos requisitos o bien se mejora la versión previamente implementada del producto software.

problema por ramas.En una visión genética el proceso se divide en 4 partes:análisis DiseñoCódigoprueba

tardeEl resultado puede ser positivo

proporcional todas las ventajas del modelo en cascada realimentando, reduciendo sus desventajas solo al ámbito de cada incremento.Resulta más sencillo acomodar cambios al acortar el tamaño de los incrementos.

Modelo de prototipos

de prototipos permite que todo el sistema, o algunos de sus partes se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los

Una maqueta o prototipo de pantallas muestra la interfaz de la aplicación, su cara externa, pero dicha interfaz está fija, estática, no procesa datos. El prototipo no tiene desarrollada una lógica interna, sólo muestra las pantallas por las que irá

No modifica el flujo del ciclo de vidaReduceEl riesgo de construir productos que no satisfagan las necesidades de los usuariosReduce costos y aumenta la

Requiere de experiencia.Requiere un control para el desarrollo planificado.Necesita de usuarios comprometidos.

A manera de ejemplo, pensemos en un equipo de sonido con cada una de sus piezas o componentes; es probable que por separado puedan ser funcionales, pero para que verdaderamente desempeñen la

que se aseguren que el desarrollador el usuario el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollador, este modelo se encarga del desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance

pasando la futura aplicación

probabilidad de éxito.Exige disponer de las herramientas adecuada.No presenta calidad ni robustez.Una vez identificados todos los requisitos mediante prototipos, se construye el producto de ingeniería.Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

función que deberían, tienen que estar unidas formando un todo.

del producto, pero no se asegura su uso real.

También ofrece un mejor enfoque cuando el responsable del desarrollo del software esta inseguro de eficacia de un algoritmo de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-maquina

Modelo evolutivo

refinando de acuerdo aEl desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se valos comentarios o nuevos requerimientos por parte d

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

Reutilización del software.

Simplifica las pruebas; pues estas se le hacen a los componentes antes de probar el conjunto completo de componentes ensamblados.

Genera mucho tiempo en el desarrollo del sistema.Requiere experiencia en la identificación de riesgos.Genera mucho trabajo adicional.

A manera de ejemplo, pensemos en un equipo de sonido con cada una de sus piezas o componentes; es probable que por separado puedan ser funcionales, pero para que verdaderamente desempeñen la función que deberían,

el cliente odel usuarioFinal. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.

Simplifica el mantenimiento del sistema.

Mayor calidad.

tienen que estar unidas formando un todo.