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