Modelos Del Proceso De Software: 2013

miércoles, 15 de mayo de 2013

Técnicas De Cuarta Generación

Las técnicas de cuarta generación son un conjunto muy diverso de métodos y herramientas que tienen por objeto el de facilitar el desarrollo del software, facilitan al que desarrolla el software la propiedad de especificar algunas características del mismo a alto nivel, mas tarde, la herramienta genera automáticamente el código fuente a partir de esta especificación.

Los tipos más comunes de generadores de código cubren uno o varios de los siguientes aspectos:

1.-Acceso a base de datos: utilizando lenguajes de consulta de alto nivel, generadores de códigos a partir de una especificación de los requisitos se genera automáticamente toda la aplicación.

2.-Generación de pantallas: permitiendo diseñar la pantalla dibujándola directamente, incluyendo además el control del cursor y la gestión de los errores de los datos de entrada.

3.-Gestión de entornos gráficos: permitiendo manejar distintas herramientas para la realización de un proyecto de forma gráfica.

4.-Generación de informes:Como otros paradigmas, T4G comienza con el paso de recolección de requerimientos. En el mejor de los casos el cliente debería describir los requerimientos y éstos traducirse directamente a un prototipo operacional pero en general esto no es así. El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificación de hechos que son conocidos y puede ser incapaz o no desear especificar la información en la forma que una herramienta T4G puede construirla, además las herramientas actuales T4G no son lo suficientemente sofisticadas para acomodar realmente lenguaje natural y no lo serán por algún tiempo.

RUP (Rational Unified Process) Proceso Unificado de Modelado

Surge a mediados de los 90s junto con UML
Así como el CDM es ampliamente documental
Se basa en UML y es iterativo e incremental
El punto de partida es la elicitación de requisitos del software

CDM (Custom Development Method) Método de desarrollo adaptable

Creado por ORACLE Corporation
Permite hacer un seguimiento intensivo de las diferentes fases del desarrollo (Definición, Análisis, Diseño, Construcción, Transición y Producción). Para ello, realizan un conjunto de tareas que se agrupan en procesos. Cada proceso hace parte de cada una de las fases del desarrollo y se reporta mediante un documento denominado “entregable”.
Genera mucha documentación

FDD (Feature Driven Development)

FDD con sus siglas en inglés Feature Driven Development es un enfoque ágil para el desarrollo de sistemas. Fue desarrollado por Jeff De Luca y el viejo gurú de la Orientacióna Objetos Peter Coad. Como las otras metodologías adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible. Dicho enfoque no hace énfasis en la obtención de los requerimientos sino en como se realizan las fases de diseño y construcción. Sin embargo, fue diseñado para trabajar con otras actividades de desarrollo de software y no requiere la utilización de ningún modelo de proceso específico. Además, hace énfasis en aspectos de calidad durante todo el proceso e incluye un monitoreo permanente del avance del proyecto. Al contrario de otras metodologías, FDD afirma ser conveniente para el desarrollo de sistemas críticos.

XP (Extreme Programming)

La programación extrema o Extreme Programming (XP) es un enfoque de la Ingenieria de Software formulado por Kent Benk, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos agiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Modelo De Metodos Formales

La denominación métodos formales se usa para referirse a cualquier actividad relacionada con representaciones matemáticas del software, incluyendo la especificación formal de sistemas, análisis y demostración de la especificación, el desarrollo transformacional y la verificación de programas. Todas estas actividades dependen de una especificación formal del software.

Una especificación formal del software es una especificación expresada en un lenguaje cuyo vocabulario, sintaxis y semántica están formalmente definidos. Esta necesidad de una definición formal significa que los lenguajes de especificación deben basarse en conceptos matemáticos cuyas propiedades se comprendan bien. La rama de las matemáticas usada es lade matemática discreta, y los conceptos matemáticos provienen de la teoría de conjuntos, la lógica y el álgebra.

Ventajas

Se comprende mejor el sistema.
La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario.
El sistema se describe de manera más precisa.
El sistema se asegura matemáticamente que es correcto según las especificaciones.
Mayor calidad software respecto al cumplimiento de las especificaciones.
Mayor productividad

Desventajas

El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los programas resultantes son incómodos para los usuarios.
Los investigadores por lo general no conocen la realidad industrial.
Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado dogmático.
Se considera que la aplicación de métodos formales encarece los productos y ralentiza su desarrollo.

Modelos Evolutivos Del Proceso De Software

Modelos flexibles que permiten la modificación del sistema durante su proceso de desarrollo.
Procesos iterativos que permiten a los desarrolladores construir versiones del software cada vez más completas.
Ejemplos:

Modelo Incremental.
Modelo Espiral.
Modelo Espiral WINWIN.
Modelo de Desarrollo Concurrente.

Modelo Incremental

Consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.

Ventajas
Los clientes no tienen que esperar hasta que el sistema se entregue

completamente para comenzar a hacer uso de él.

Los clientes pueden usar los incrementos iniciales como prototipo para precisar los requerimientos posteriores del sistema.
Minimización del riesgo de falla en el proyecto porque los errores se van corrigiendo progresivamente.

Desventajas

Adaptación de los requisitos del cliente para lograr incrementos pequeños

que añadan funcionalidad al sistema.

Modelo Espiral

Es un modelo de desarrollo evolutivo propuesto por Barry Boehm, que utiliza prototipos como apoyo. La forma de espiral representa una iteración (repetición) de procesos que, a medida que se van entregando prototipos y éstos son revisados por los clientes o usuarios finales, el tiempo empleado para desarrollar la próxima versión es cada vez mayor. Cada división recibe el nombre de región de tareas.

Ventajas

El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.

Desventajas

Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
Genera mucho tiempo en el desarrollo de sistemas.

Modelo Espiral WinWin (victoria & victoria)

Una variante interesante del Modelo Espiral es el Modelo espiral Win-Win. El Modelo Espiral previo (clásico) sugiere la comunicación con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él proporciona la información para continuar, sin embargo, esta es una situación que rara vez ocurre. Normalmente el cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.

Modelo De Desarrollo Concurrente

Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.

Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la siguiente forma:

Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente.

Modelo de Desarrollo Rápido de Aplicaciones (DRA)

Este modelo se basa en el Modelo Lineal Secuencial llevado a cabo por varios equipos de trabajo que siguen las etapas del proceso, es aplicable a la construcción de sistemas de información fácilmente modularizables, este modelo necesita de clientes y desarrolladores que estén en constante contacto con el proceso ya que no es un método muy eficaz a la hora de utilizar nuevas tecnologías ya que se puede afectar el aprendizaje.

Modelado de gestión o Negocios:

El flujo de información entre las funciones de las empresas se define respondiendo a preguntas como qué información del motor del proceso de negocio,lo que se genera,que la genera,donde va la información,que lo proceso y así sucesivamente.

Modelado de datos

La información recogida a partir del modelo de negocio se refina en un conjunto de objetos de datos que se necesitan para apoyar el negocio.

Modelado de procesos

El objeto de datos definidos en la fase de modelado de datos se transforman para logra relflujo de información necesario para implementar una función de negocio. descripciones de procesamiento se crean para añadir,modificar,eliminar o recuperar un objeto de datos.

Generación de aplicaciones

Las herramientas automatizadas que se utilizan para facilita la construcción del software,e incluso que utilizan las técnicas GL cuarto.

Pruebas de entrega

Muchos de los componentes de programación ya han sido sometidos a pruebas de reutilización énfasis RAD. Esto reduce el tiempo global de los ensayos. Pero los nuevos componentes debe ser probado y todas las interfaces debe ejercerse plenamente.

Modelo De Construcción De Prototipos

Es también denominado "Modelo De Desarrollo Evolutivo", los modelos evolutivos se caracterizan por la forma en que permiten que los ingenieros de software desarrollen versiones cada vez más completas del software.El diseño rápido se basa en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. El prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Etapas

Plan rápido.
Modelado, diseño rápido.
Construcción del Prototipo.
Desarrollo, entrega y retroalimentación.
Comunicación.

Ejemplo De Modelo De Prototipos

Modelo Lineal Secuencial o Cascada

Este es le primer modelo empleado también conocido como modelo clásico, modelo tradicional o modelo lineal secuencial, si sufre algún cambio durante la ejecución en alguna etapa en el modelo en cascada puro implicaría empezar desde 0 todo el ciclo de nuevo, lo cual implica altos costos de tiempo y desarrollo.

El modelo consta de las siguientes etapas:

Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios para los que va destinado el sistema. Se busca hacer esta definición lo más detallado posible.

Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican, se describen las abstracciones y relaciones de los componentes del sistema.

Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.

Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.

Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.⁴

En lugar de usar el modelo en cascada puro, se produce alguna realimentación entre etapas, que no es completamente predecible ni rígida, así no afectando si hay cambios o evoluciones durante el ciclo de vida.

El ejemplo gráfico de este Modelo lo podemos observar en la siguiente imagen:

LIMITACIONES

•No es estrictamente secuencial (se saltan etapas)

•Los requisitos se exponen a medida de que avanzan las etapas mas no en el inicio como generalmente es.

•La primera versión del software llega al final del proceso, a veces el afán del cliente hace que la aplicación final no cumpla con los requerimientos

DEFICNICIÓN

En este espacio hablaremos de el significado de los modelos del proceso de software, es una estrategia también llamada modelo de proceso o paradigma de Ingeniería de Software.

se selecciona el modelo según la naturaleza del proyecto y de la aplicación los métodos herramientas, controles y entregas que se requieren.

Esto es una metodología para el desarrollo de software que incluye las fases del ciclo de vida y se define de manera general para todas las aplicaciones de la organización donde se definen tareas especificas.

PROCESOS DEL SOFTWARE

BUCLE DE RESOLUCIÓN DE PROBLEMA

Todo el desarrollo de software se puede caracterizar como bucle de resolución de problemas. Raccoon [RAC95] sugiere un Modelo del Caos que describe el desarrollo del software como una extensión desde el usuario hasta el desarrollador y la tecnología.