Ir al contenido principal

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 diseño 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 diseñados 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, diseñar 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 productos que se generan son
vision general de proyecto
modelo de casos de uso
modelo de analisis de PU
modelo de diseño
modelo de 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

Comentarios

Entradas populares de este blog

DISEÑO AL NIVEL DE COMPONENTES

El diseño a nivel de componentes se presenta a menudo despues que se ha terminado la primera iteracion del diseño arquitectonico. y  el objetivo de esta fase es traducir el diseño en software operaciona. El diseño a nivel de componentes define las estructuras de datos, los algoritmos, las caracteristicas de la interfaz  y los mecanismos de comunicacion asignados a cada componente de software. esta fase permite revisar si los detalles de diseño son correctos y consistentes con las representaciones iniciales de diseño ¿QUE ES UN COMPONENTE? Es un bloque de construccion modular par el software de computo. una parte modular desplegable y reemplazable de un sistema que encapsula implementacion y expone un conjunto de interfaces. desde el punto de vista orientado a objetos un componente es un conjunto de clases ques se interrelacionan entre si. en el contexto convencional de ingenieria de software  un componente es un elemento funcional que incorpora  la logica del procesamiento y

ESTRATEGIAS DE PRUEBAS DE SOFTWARE

La estrategia de pruebas de software proporciona un mapa que describe los pasos que se daran como parte de la prueba indica cuando se planea y cuando se daran dichos pasos ademas cuanto tiempo, esfuerzo y recursos consumiran. un software se prueba para descubrir los errores cometidos, si se realiza sin ningun plan seguramente se desperdiciara tiempo, se dedicara un esfuerzo innecesario y lo que es peor puede que no se detecten los errores. Las pruebas se deben planificar con anticipacion y realizarlas de manera sistematica por lo que es importante tener una plantilla existen diferentes y en general tienen los siguientes pasos. 1. Revisiones tecnicas formales y efectivas 2. Se inicia a nivel de componentes y se trabaja hacia afuera hacia la integracion del sistema 3. Diferentes tecnicas en diferentes momentos 4. las pruebas las dirige el desarrollador 5. la prueba y la depuracion son actividades diferentes, pero la segunda debe incluirse en cualquier estrategia de pruebas. l

AGE OF EMPIRES ERROR INICIALIZAR DIRECT 3D

Instale age of empires 3 pero no me corria me salia un mensaje de error al inicializar posibles causas direct 3d y otras que no me acuerdo la solucion luego de buscar: abrir el archivo mis documentos\my games\Age of empires 3\users\NewProfile.xml en block de notas setting name="optiongrfxres">etting Name="optiongrfxres">1280 x 720 colocar los parametros en la configuarcion que tiene el ordenador en mi caso es wide screen 1280 X 720 Setting Name="optionrefreshrate">75 esta configuracion se mira en inicio > panel de control > apariencia y temas >pantalla lengeta configuarcion > boton opciones avanzadas lengueta adaptador > boton listar modos alli colocas el modo que queres y lo pones en el archivo newProfile.xml