MODELOS PRESCRIPTIVOS DEL PROCESO Los modelos prescriptivos de software fueron ideados originalmente para ordenar el caos del

desarrollo de software, y la historia nos muestro que el uso de estos han tradio tanto un camino a seguir en el desarrollo de software asi como estructuras utiles. aun que el trabajo de ingenieria de software y el producto resultante siguen estando en un punto entre el orden y el caos lo cual indica que no se esta en la estructura completa y que puede haber cierta dosis de creatividad en el desarrollo de software y no se esta en la desorganizacion total de manera que puede seguirse un camino predecible para el proyecto. Los modelos prescriptivos de software nos definen un conjunto de tareas actividades, productos de trabajo que se requieren para desarrollar productos de calidad que son importantes para llevar control, estabilidad y organizacion a una actividad que tiende a ser caotica, el modelo prescriptivo llena el marco de trabajo con conjuntos de tareas explicitas para las acciones de la ingenieria de software. Se debe considerar que aun que un proceso sea prescriptivo esto no se debe asumir como estatico, estos se deben adaptar al personal, al proyecto y al problema. Los modelos son llamados prescriptivos ya que prescriven una serie de elementos de proceso asi como su flujo de trabajo, cada uno de modelos se ajustan al marco de trabjo estandar pero cada uno aplica diferencias a cada una de las actividades y a su flujo de trabajo. EL MODELO CASCADA O CICLO CLASICO

Existen ocaciones en las cual es los requisitos de un sistemas se identifican de manera razonable y estos fluyen de la comunicacion al despliegue de manera casi lineal. Esto se da cuando se debe hacer adaptaciones o mejorias a un sistema existente por ejemplo al agruegar nuevas regulaciones gubernamentales a un programa existente, puede utilizarse tambien en proyectos nuevos pero unicamente cuando los requisitos estan bien definidos y son estables en forma razonable. Las actividades seguidas por este son las siguientes

El modelo cascada es el paradigma mas antiguo en la ingenieria de software pero al utilizar este paradigma se han observado lo siguiente. 1. Es muy raro que los problemas reales sigan el flujo lineal secuencial propuesto. 2. Es muy dificil para el cliente establecer todos los requisitos de manera explicita el modelo cascada lo requiere y enfrenta problemas al proponer cambios. 3. El cliente debe tener paciencia.

En general hoy en dia al ser un mundo acelerado y cambiante enfrentamos muchos problemas al utilizar este paradigma ya que puede probocar estados de bloqueos en los que no se pueden terminar algunas tareas hasta que otras se hayan concluido, pero de igual forma pueden presentarse proyectos en los cuales este definido todo de manera clara y no se tengan cambios pra los cuales este modelo puede ser el ideal. MODELOS DE PROCESOS INCREMENTALES

En muchas ocaciones encontramos proyectos con requisitos bien definidos razonables pero la propia naturaleza del proyecto nos impide usar un enfoque puramente lineal, por ejemplo se necesita tener un conjunto limitado de funcionalidad para luego refinarla y expandirla y esto nos conduce a modelo incremental el cual combina elementos del modelo en cascada en forma iterativa. El modelo incremental entrega una serie de lanzamientos llamados incrementos que proporcionan en forma progresiva mas funcionalidad para los clientes a medida que se entrega cada uno de los incrementos. Al utilizar el modelo incremental la primer entrega es un producto esencial que incluye los requisitos basicos, los detalles tanto

conocidos como no conocidos pueden incluirse en lanzamientos posteriores, esta primera entrega puede ser evaluado por el cliente para incluir nueva funcionalidad. Este proceso debe ser repetitivo hasta no tener un producto final. El modelo incremental al igual que el modelo de prototipos es por naturaleza iterativo la gran diferencia entre ambos es que se debe hacer una entrega funcional en el caso del modelo incremental. Si el cliente propone una fecha de entrega imposible es conveniente sugerir la entrega de uno o mas incrementos para dicha fecha de modo que se pueda tener un producto parcial basico a las necesidades del cliente para ese momento y entregar el resto de incrementos adicionales luego.

Aunque las primeras versiones son incompletas tienen un alto grado de funcionalidad la cual servira al cliente para evaluacion y revision de sus necesidades. El modelo incremental es util por ejemplo cuando no se tienen el personal suficiente disponible, puede desarrollarse el primer incremento utilizando parte del equipo y contratar o esperar a terminar un proyecto anterior para tener disponible personal, puede tambien planearse a manera de riesgos tecnicos por ejemple puede crearse un primer incremento que no utilize algun hardware especifico mientras este es adquirido. MODELO DRA (DESARROLLO RAPIDO DE APLICACIONES) es un modelo incremental que hace enfasis en un ciclo de vida corto. y

puede verse como una version a alta velocidad del modelo en cascada en el cual se logra un desarrollo rapido mediante un efoque basado en componentes. En el cual deberiamos tener un sistema completamente funcional en un periodo de 60 a 90 dias. DRA cumple con las actividades vistas en el marco de trabajo estandar, aqui la comunicacion trabaja para entender el problema del negocio y las caracteristicas de informacion que debe incluir el software. la planeacion es una fase esencial ya que varios equipos deben trabajar en paralelo en diferentes funciones del sistema. el modelado incluye tres fases modelado de proceso, modelado de negocio y modelado de datos. la construccion hace enfasis en la utilizacion de componentes de software existentes y la generacion de codigo automatico. el Despliegue establece una base para las proximas iteraciones. las condiciones de entender bien los requisitos y limitar el ambito del proyecto necesarios para aplicar DRA no se pueden garantizar por ningun medio y si los requisitos son pobres es mejor aplicar modelos de prototipo o evolutivos.

DRA

tiene

los

siguientes

incomvenientes

1. para proyectos grandes pero escalables DRA necesita sufiente recurso humano para crear el numero correcto de equipos. 2. si tanto cliente como programador no se compromenten en las actividades rapidas necesarias para completar el sistema en un marco

breve

de

tiempo

los

proyectos

DRA

fracasaran.

3.Si un sistema no se puede modular en forma apropiada para la construccion de componentes separados sera un gran problema. 4. Si el alto rendimiento es un aspecto importante y se alcanzara al convertir interfaces en componentes. 5. Inaprpiado con riesgos tecnicos altos.

MODELOS

EVOLUTIVOS

Los modelos evolutivos producen una version completa en forma incremental en cada iteracion. y permiten crear versiones mas completas del software en cada iteracion. y son utilies cuando se tienen requisitos basicos establecidos pero se deben definir detalles sobre la extencion del producto o sitema. CONSTRUCCION DE PROTOTIPOS

El cliente describe un conjunto de de objetivos generales del software pero no identifica los requisitos detallados de entrada, salida o procesamiento y el desarrollador esta inseguro de la efectividad del software. si el cliente tiene un necesidad real del software pero no sepa definir los detalles o el mismo no sepa bien que es lo que quiere es importante como primer paso desarrollar un prototipo. y puede mezclarse con cualquier otro metodo.

El paradigma de construccion de prototipos se inicia con la comunicacion el ingeniero de software y el cliente encuentran y definen los requisitos basicos y conocidos, entonces se plantea con rapidez una iteracion de construccion de prototipos y se presenta un diseo rapido y este se centra en aspectos visibles al cliente y al usuario final, se construye el prototio y este se somete a una evaluacion por parte del cliente/usuario para y con la retroalimentacion producida se reajustan los requisitos del software que se desarrollara. De tal forma que el prototipo sirve como un mecanismo para identificar los requisitos del software. Es recomendable idealmente desechar un prototipo y debe resistirse la presion de entregarlo como un producto ya que la calidad se vera diezmanda y por lo tanto debe de definirse las reglas del juego con el cliente indicandosele que el protitipo sirve para tomar requisitos y ajustarlos y luego debe desecharsele al menos en parte para luego desarrollar un software de alta calidad. EL MODELO ESPIRAL

El modelo espiral es un proceso de software evolutivo que conjuga la naturaleza iterativa de la construccion de prototipos con los aspectos controlados y sistematicos del modelo cascada, el modelo cascada se puede adaptar y aplicar a traves del ciclo de vida completo de una aplicacion desde el desarrollo del concepto hasta el mantenimiento. Cuando se aplica el modelo espiral se desarrolla una serie de entregas

evolutivas iniciando desde posiblemente documentacion y prototipos, hasta llegar versiones cada ves mejores del sistema.

el desarrollo espiral es un enfoque realista para el de sarrollo de sistemas a gran escala. como el software evoluciona el desarrollador y el cliente adquieren mayor experiencia y reaccionan mejor ante riesgos en cada etapa. si se aplica en forma apropiada el se deben reducir riesgos antes que estos sean un problema. entre los problemas de este modelo podemos ver que es dificil convencer al cliente que el enfoque evolutivo es controlable, si un riesgo importante no se descubre y administra surgiran problemas. MODELO DE DESARRROLLO CONCURRENTE

El modelo de procesos concurrentes define una serie de eventos que se disparan transiciones de estado a estado para cada una de las actividades, acciones, o tareas de ingenieria de software. Se aplica a todos los tipos de desarrollo de software y proporciona una vision exacta del estado del proyecto es apropiado cuando se encuentran involucrados varios equipos de ingenieria. un ejemplo de una actividad concurrente es el siguiente

El software de computadora modero es cambiante y los tiempos de entrega reducidos y es importante si se pierde tiempo el mismo software puede perder significado y los procesos evolutivos pueden ayudarnos, los problemas de estos puedens ser que no sabemos cuantas iteraciones necesitamos para construir un producto y las tecnicas de estimacion se basan en metodos lineales los cuales no se ajustan, no se establece la velocidad maxima de evolucion DESARROLLO BASADO EN COMPONENTES

Incorpora muchas de las caracteristicas del modelo espiral es evolutivo por naturaleza. el modelo configura aplicaciones a partir de software empaquetado en forma previa. el modelado y construccion inician por identificar los componentes candidatos estos pueden ser diseados como modulos de software convencionales o como clases o paquetes de clases orientados a objetos. MODELO DE METODOS FORMALES

Comprende un conjunto de actividades que conducen a la especificacion matematica del software de computadora y

proporcionan un mecanismo para eliminar problemas dificiles a traves de un analisis matematico. el problema principal es el tiempo y los recursos que consume son grandes, no hay gente suficiente capacitada para aplicar estos metodos y es muy dificil comunicarse con el cliente por medio de las notaciones especificas. DESARROLLO DE SOFTWARE ORIENTADO A ASPECTOS

Es un paradigma de ingenieria de software que proporciona un proceso y enfoque metodologico para definir, especificar, disear y construir aspectos. mecanismos mas alla de subrutinas y legados para localizar la expresion del interes general es posible que el proceso adopte caracteristicas del proceso espiral y concurrente .

EL

PROCESO

UNIFICADO

El proceso unificado es el intentod e reunir las mejores caracteristicas de los distintosp paradigmas de ingenieria de software y se complementa muchos de los mejores principios del desarrollo agil, hace enfasis en la arquitectura y ayuda a los arquitectos a enfocarse en las metas correctas PU abarca la comunicacion y actividades de planeacion, se identifican los requisitos del software y se propone una arquitectura aproximada del sistema y se desarrolla un plan para la naturaleza iteretiva incremental que sigue. los requisitos fundamentales se describen a traves de un conjunto fundamental de casos de uso que describen caracteristicas y funciones son importantes para cada clase importante de usuarios

la planeacion identifica recursos, evalua riesgos importantes, define itinerario y establece una base para las siguientes fases. la fase de elaboracion establece las actividades de comunicacion y modelado del modelo generico, la fase de construccion es igual la actividad de transision abarca la ultima parte de construccion del modelo generico y la actividad de despliegue, la fase de produccion conicide con la actividad de despliegue. los vision modelo modelo modelo modelo productos general de de de que se de casos analisis de generan son proyecto de uso de PU diseo implementacion

los modelos incrementales nos ayudan a tener control sobre el

proyecto de softwae y hacer una actividad caotica en algo controlable, por supuesto debemos saber que metodo utilizar en cada caso

MODELOS PRESCRIPTIVOS DE PROCESO Que es ? los modelos prescriptivos de proceso definen un conjunto distinto de actividades, acciones, tareas fundamentos y productos de trabajo que es requieren para desarrollar software de alta calidad.

Quin lo hace? Los ingenieros de software y sus gerentes adaptan un modelo prescripto de proceso a sus necesidades y despus lo siguen. ademas, la gente que ha solicitado el software tiene un papel por desempear se ejecuta el modelo de software.

Por qu es importante ? porque proporciona estabilidad.control y organizacion a una actividad que si no se controla puede volverse catica. Cules son los pasos? El proceso conduce a un equipo de software a travs de un conjunto de actividades del marco de trabajo que se organizan en un flujo de proceso.

Cul es un obtenido? Desde punto de vista de un ingeniero de software,losproductos de trabajo son los programas,documentos y datos que se producen como consecuencia de las actividades y tareas que define el proceso.

TIPOS DE MODELOS

1.Modelo prescriptivos Modelo en Cascada: algunas veces llamado el ciclo de vida clsico,sugiere un enfoque sistemtico,secuencial hacia el desarrollo del software, que se inicia con la especificacin de requerimiento del cliente y que continua con la planeacin, el modelo, la construccin,y el despliegue para culminar en el soporte del software.

2. Modelo de proceso incremental

Modelo incremental: Combina elementos del modelo en cascada aplicado en forma iterativa.el modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario.cada secuencia linael produce incrementos.

Modelo DRA (desrrolo rpido de aplicaciones): Es un modelo de proceso del software incremental que resulta un ciclo de desarollo corto.el desarrollo corto.el modelo DRA es una adaptacin a alta velocidad del modelo en cascada en el que se logra el desarrollo rpido mediante un enfoque de construccin basado en componentes.

3.Modelos de procesos evolutivos Modelo en espiral: Es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construccin de prototipos con los aspectos controlados y sistematics del modelo en cascada. Modelo de desarrollo concurrente: Llamado algunas veces ingenieria concurrente relacionado,se representa en forma esquemtica como una serie de actividades del marco de trabajo,acciones y tarea de la ingenieria de software y sus estados asociados.

4.Modelos especializados de proceso

Modelo de metodos formales: modelo de mtodos formales comprende un conjunto actividades que conducen a la especificacin matemtica del software de computadora.los metodos formales permiten que los ingeniero de software especifique,desarrolle y verifique un sistema basado en computadora al aplicar una notacin matemtica

rigurosa.

Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 16 de 18 flujo de trabajo identifica las tareas necesarias para completar una accin importante deingeniera del software y los productos de trabajoqueseproducencomoconsecuenciadelarealizacinexitosadetareas.Sedebedestacarqueno todas las tareas identificadas para unflujo de trabajo del PU se realizan para cualquier proyecto de software. El equipo debe adaptarel proceso (acciones, tareas, subtareas y productos de trabajo) parasatisfacersusnecesidades. Productos de trabajo del proceso unificado. En la siguiente figura se ilustran los productos de trabajo clave que se produjeron comoconsecuencia de las cuatro fases tcnicas del PU. Durante la fase de inicio, el propsito esestablecer una "visin" generalpara el proyecto, identificar unconjunto de requisitos denegocios, formar un caso denegocios para el software ydefinir los riesgos del proyecto ydel negocio que pudieranrepresentar un obstculo para elxito. Desde el punto de vista delingeniero de software, elproducto de trabajo ms impor-tante generado durante la etapade inicio es el modelo de caso de uso: una coleccin de casos deuso que describen la forma enque actores externos ("usuarios" humanos y no humanos del software) interactan con elsistema y

obtienen valor a partir de ste. En esencia, el modelo de casos de uso es unacoleccin de escenarios de uso con plantillas estandarizadas que implican caractersticasy funciones del software mediante la descripcin de una serie de condiciones previas, unflujo de eventos o un escenario, y un conjunto de condiciones exteriores para lainteraccin representada. En un inicio, los casos de uso describen requisitos al nivel deldominio de negocios (por ejemplo, el grado de abstraccin es alto). Sin embargo, elmodelo de casos de uso se refina y elabora conforme cada fase del PU se ejecuta y sirvecomo una entrada importante para la creacin de productos de trabajo subsecuentes.Durante la fase de inicio slo se completa entre el 10 y 20 por ciento de los casos de uso.Despus de la elaboracin, se ha creado entre un 80 y 90 por ciento del modelo.La fase de elaboracin produce un conjunto de productos de trabajo que elaborarequisitos (incluso requisitos no funcionales), as como una descripcin arquitectnica y undiseo preliminar. Cuando el ingeniero de software inicia con el anlisis orientado aobjetos, el objetivo primordial es definir un conjunto de clases de anlisis que describan enforma adecuada el comportamiento del sistema. El modelo de anlisis del PU es unproducto de trabajo que se desarrolla como consecuencia de esta actividad. Los paquetesde clases y anlisis (colecciones de clases) definidos como una parte del modelo deanlisis se refinan despus en un modelo de diseo, el cual identifica clases de diseo,subsistemas y las interfases entre los subsistemas. Los modelos de anlisis y diseoexpanden y refinan una representacin evolutiva de la arquitectura del software. Adems,

Modelos de desarrollo de softwareMC Genaro Alberto Gmez Chi Pgina 17 de 18 en la fase de elaboracin se revisan los riesgos y el plan de proyecto para asegurar quecada uno de ellos conserve su validez.La fase de construccin produce un modelo de implementacin que traduce lasclases de diseo en componentes de software que se construirn para ejecutar el sistema,y un modelo de despliegue convierte los componentes en el ambiente fsico decomputacin. Por ltimo, un modelo de prueba describe las pruebas empleadas paraasegurar que los casos de uso se reflejen de manera apropiada en el software que se haconstruido.La fase de transicin entrega el incremento del software y evala los productos detrabajo elaborados durante la etapa en que los usuarios finales trabajan con el software.En esta etapa se produce la retroalimentacin proveniente de las pruebas beta y losrequerimientos cualitativos de cambio. Resumen.

Los modelos prescriptivos del proceso de software se han aplicado durante muchosaos en un esfuerzo encaminado a ordenar y estructurar el desarrollo del software. Cadauno de estos modelos convencionales sugiere un flujo de proceso que de alguna forma esdiferente, pero todos realizan el mismo conjunto de actividades genricas del marco detrabajo: comunicacin, planeacin, modelado, construccin y despliegue.El modelo en cascada sugiere una progresin lineal de actividades del marco detrabajo que a menudo resulta inconsistente con la realidad moderna en el mundo delsoftware (por ejemplo, con el cambio continuo, los sistemas en evolucin, las fechas deentrega restringidas). Sin embargo, este modelo se puede aplicar en situaciones en lascuales los requisitos estn bien definidos y son estables.Los modelos incremntales del proceso de software producen software como unaserie de entregas de incrementos. El modelo DRA est diseado para proyectos grandes que se deben entregar en marcos de tiempo muy reducidos.Los modelos de proceso evolutivos reconocen la naturaleza evolutiva de la mayorade los proyectos de ingeniera del software y estn diseados para ajustarse al cambio.Los modelos evolutivos, como el de construccin de prototipos y el modelo en espiral,generan productos de trabajo incremntales (o versiones del software en funcionamiento)con rapidez. Estos modelos se pueden adaptar para aplicarlos a travs de todas lasactividades de la ingeniera del software: desde el desarrollo de conceptos hasta elmantenimiento del sistema a largo plazo.El modelo basado en componentes destaca la reutilizacin y ensambladura decomponentes. Los modelos de mtodos formales conducen a la utilizacin de unenfoque basado en las matemticas para el desarrollo y la verificacin del software.El modelo orientado a aspectos incluye los intereses generales que cubren la arqui-tectura total del sistema.

Modelos de desarrollo softwareMC Genaro Alberto Gmez Chi Pgina 18 de

http://es.scribd.com/doc/19162245/Unidad-5-Modelo-Desarrollo-Software

de