MODELOS DE PROCECOS DEL SOFTWARE
MODELOS DE PROCECOS DEL SOFTWARE
|
Ingeniería en Tecnología Informática
I Cuatrimestre
Introducción a la Tecnología de la Información
Ing: Erick Fernando Chan
Morales.
MODELOS DE PRECESO DEL SOFTWARE
POR:
Claudio
Bernabe Beb Chen.
10 de Marzo
de 2013
INDICE
Modelo Lineal secuencial
Modelo Lineal secuencial
Se tiene un modelo que lleva un desarrollo incremental, esto nos dice que
se desarrolla el software en etapas y que después del término de una etapa no
es posible regresar a ella, este modelo tiene cuatro etapas que son:
- Planificación: se determinan los objetivos, metas, requerimientos y
Restricciones en el proyecto.
- Análisis de riesgos: identificación de situaciones inconvenientes para
evitarlas y solucionarlas.
- Ingeniera: desarrollo del producto con respecto al diseño y otras
consideraciones planteadas.
- Evaluación del cliente: valorización de los resultados del
proyecto(producto obtenido).
y se tiene implícita la realización de estas actividades:
-Análisis de requerimientos: en esta etapa se procede a recopilar todos los
requisitos que debe cumplir el software a desarrollar, el cliente aquí tiene un
papel fundamental, ya que analiza junto con los desarrolladores del software
los requisitos que debe cumplir el software a desarrollar.
- Diseño: esta etapa está enfocada hacia el desarrollo de un esbozo de la
arquitectura, la interfaz y el manejo de datos del software.
- Generación de código: es cuando se implementa el diseño del
software en algún lenguaje de programación definido en el mismo diseño.
- Pruebas: se hace una revisión de los procesos que realiza el
software, para determinar que esté haciendo lo planteado para cumplir con los
requerimientos.
- Mantenimiento: se verifica el correcto funcionamiento del software en su
entorno de uso, y si existen errores o defectos, proceden a corregirlos
MODELO DE
PROTOTIPOS
Este modelo
también denominado modelo de desarrollo evolutivo. Para comprender este modelo,
comenzaremos con la
definición de los objetivos globales para el software, después identificaremos
los requerimientos que conocemos y los sitios del diseño en donde es necesaria
más definición. Entonces planteamos con rapidez una iteración de construcción
de prototipos y se presenta el modelado (en forma de un diseño rápido).
Los modelos evolutivos son
iterativos; los caracteriza 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 (por ejemplo, la configuración de la interfaz con el
usuario y el formato de los despliegues de salida). 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á. La iteración ocurre cuando 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.
CONSTRUCCION DE PROTOTIPOS
A menudo un cliente define un conjunto de objetivos
generales para el software, pero no identifica los requisitos detallados de
entrada, procesamiento o salida. El responsable del desarrollo del software
está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema
operativo o de la forma que debería tomar la interacción humana – máquina,
entonces en este caso cuando utilizamos la construcción de prototipos.
Ø
No modifica
el flujo del ciclo de vida.
Ø
Reduce el
riesgo de construir productos que no satisfagan las necesidades de los
usuarios.
Ø
Reduce
costos y aumenta la probabilidad de éxito.
Ø
Exige
disponer de las herramientas adecuadas.
Ø
No presenta
calidad ni robustez.
Ø
Una vez
identificados todos los requisitos mediante el prototipo, se construye el
producto de ingeniería.
DESVENTAJAS
A los usuarios les gusta el sistema
real y a los desarrolladores les gusta construir algo de inmediato. Sin
embargo, la construcción de prototipos se torna problemática por las siguientes
razones:
v
El cliente
ve funcionando lo que para él es la primera versión del prototipo que ha sido
construido con “chicle y cable para embalaje”, y puede decepcionarse al
indicarle que el sistema aún no ha sido construido.
v
El
desarrollador puede caer en la tentación de aumentar el prototipo para construir
el sistema final sin tener en cuenta los obligaciones de calidad y de
mantenimiento que tiene con el cliente.
MODELO DRA
El desarrollo rapido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto.
Es una adaptación de "alta velocidad" del modelo de cascada. El proceso de DRA permite que un equipo de desarrollo cree un sistema completamente funcional dentro de un periodo muy corto de 60 a 90 días.
VENTAJAS
- Es muy
rápido.
- Permite
trabajar en él a varias personas a la vez
DESVENTAJAS
- El
enfoque DRA tiene inconvenientes para proyectos grandes, necesita
suficientes recursos humanos para crear el numero correcto de equipos.
- Si los
desarrolladores y clientes no se comprenden con las actividades necesarias
para completar el sistema, los proyectos fallarán.
- El DRA
sería inapropiado cuando los riesgos técnicos son altos.
MODELO DE DESARROLLO CONCURRENTE
Llamado algunas veces "Ingeniería
Concurrente" , se representa en forma esquematica con una serie de
actividades del marco de trabajo.
Por ejemplo las actividades de
modelado, definida para el modelo en espiral, se lleva a cabo en las siguientes
acciones:
- Construction
de prototipos.
- Especificación
de análisis.
Todas las actividades existen en
forma concurrente pero se encuentran en diferentes estados.
El modelo de proceso concurrente
define una serie de eventos que disparan transiciones de estado a estado para
cada una de las actividades, acciones o tareas de la ingeniería del software.
Esto genera el evento de Corrección del Análisis del Modelo.
PROCESO UNIFICADO DE SOFTWARE
El Proceso Unificado "es un
proceso de desarrollo de software configurable que se adapta a través de
los proyectos variados en tamaños y complejidad. Se basa en muchos años de
experiencia en el uso de la tecnología orientada a objetos en el desarrollo de
software de misión crítica en una variedad de industrias por la compañía
Rational", donde confluyen 'los tres amigos' como se llaman a sí mismos o
los tres grandes OO: Grady Booch, James Rumbaugh e Ivar Jacobson
El Proceso Unificado guía a los
equipos de proyecto en cómo administrar el desarrollo iterativo de un modo
controlado mientras se balancean los requerimientos del negocio, el tiempo al
mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados
en la captura de los requerimientos y en el establecimiento de una guía
arquitectónica lo más pronto, para diseñar y probar el sistema hecho de acuerdo
a los requerimientos y a la arquitectura. El proceso describe qué entregables
producir, cómo desarrollarlos y también provee patrones. El proceso unificado
es soportado por herramientas que automatizan entre otras cosas, el modelado
visual, la administración de cambios y las pruebas.
DESARROLLO DEL SOFTWARE ORIENTADO A ASPECTOS
La Programación Orientada a Aspectos (POA) es un
paradigma de programación relativamente reciente cuya intención es permitir
una adecuada modularización de las aplicaciones y posibilitar una mejor
separación de conceptos. Gracias a la POA se pueden capturar los diferentes
conceptos que componen una aplicación en entidades bien definidas, de manera
apropiada en cada uno de los casos y eliminando las dependencias inherentes
entre cada uno de los módulos. De esta forma se consigue razonar mejor sobre
los conceptos, se elimina la dispersión del código y las implementaciones
resultan más comprensibles, adaptables y reusables. Varias tecnologías con
nombres diferentes se encaminan a la consecución de los mismos objetivos.
MODELO INCREMENTAL
Modelo incremental evolutivo:
MODELO INCREMENTAL EVOLUTIVO
En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estén diseñados para acomodarse a una evolución temporal o progresiva, donde los requisitos centrales son conocidos de antemano, aunque no estén bien definidos a nivel detalle.
En el modelo Cascada y Cascada
Realimentado no se tiene en cuenta la naturaleza evolutiva del software, se
plantea como estático con requisitos bien conocidos y definidos desde el
inicio.
Los evolutivos son modelos iterativos,
permiten desarrollar versiones cada vez más completas y complejas, hasta llegar
al objetivo final deseado; incluso evolucionar más allá, durante la fase de
operación.
Los modelos “Iterativo Incremental” y
“Espiral” (entre otros) son dos de los más conocidos y utilizados del tipo
evolutivo
MODELO ESPIRAL
Esta clase trato sobre el modelo espiral, el cual es a
base de una serie de ciclos los cuales se repiten en forma de espiral, cada vez
que se avanza un ciclo se va alcanzando un nivel superior hasta concluir el
proyecto.
Este modelo utiliza prototipos para un mejor
desarrollo del producto.
Lo característico de este modelo es que incluye un
“análisis de riesgo” es decir que podemos analizar si el proyecto puede
continuar o mejor lo suspendemos.
Este modelo se basa en que antes de hacer algo debemos
analizarlo, también debemos buscar varias opciones de resolución de problemas
para de allí escoger la opción más conveniente,
y además analizar los riesgos que se pueda tener. Este modelo necesita
de otro para poder desarrollarse. Se debe escoger el modelo cascada cuando se
pierda el control del presupuesto o por
el calendario; y el de prototipo cuando tengamos problemas con la interfaz.
El modelo espiral consta de 4 cuadrantes que son sus
fases y se dividen de la siguiente forma:
1.- Planificación
2.- Análisis de Riesgos
3.- Ingeniería
4.- Evaluación
Entre sus ventajas están que al pasar a otro nivel se
debe preguntar si se sigue, se repite o se anula el proyecto con esto nos
evitamos errores y despilfarro de tiempo y dinero. Otra ventaja es que antes de
que ocurra un problema nosotros podemos actuar y controlarlo.
Este modelo también tiene debilidades por ejemplo no
se lo puede aplicar en desarrollo bajo contrato además que solo Boehm podía
utilizar este modelo y alcanzar éxito en el desarrollo del software en el que
estaba trabajando.
MODELO ESPIRAL CON GANANCIA
Este modelo tiene como objetivo la ganancia de todos
los participantes, es decir que todos salgan satisfechos.
Tiene 3 puntos de fijación que son:
OVC (objetivo del ciclo de vida) Aquí se establece los
objetivos a cumplirse en cada etapa.
ACV (arquitectura del ciclo de vida) Se define la
arquitectura del SW.
COI (capacidad operativa inicial) Aquí el SW comienza a funcionar.
Sus ventajas son que todos los participantes ganan, y
tiene un ambiente más humano.
MODELO WINWIN
El
modelo en espiral WINWIN de Boehm, define un conjunto de actividades de
negociación al principio de casa paso alrededor de la espiral. Más que una
simple actividad de comunicación con el cliente se definen las siguientes
actividades:
- Identificación del
sistema o subsistemas clave de los directivos.
- Determinación de las
condiciones de victoria de los directivos.
- Negociación de las
condiciones de victoria de los directivos para reunirlas en un conjunto de
condiciones para todos los afectados (incluyendo el equipo del proyecto de
software).
El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de decisión antes de continuar el proyecto de software.
DESARROLLO
DE SOFTWARE BASADO EN COMPONENTES
Actualmente el desarrollo de
software basado en componentes se ha transformado en el componente más seguro
tanto para la construcción de grandiosos sistemas como para aplicaciones de software.
Entonces analizaremos principalmente
aquellas propiedades de calidad referentes a los componentes software y a las
aplicaciones que con ellos se construyen.
El Desarrollo de Software Basado en Componentes (DSBC)
trata de apoyar las bases para el diseño y desarrollo de aplicaciones
distribuidas basadas en componentes software reutilizables. Esta norma cuenta
en la actualidad con una utilidad, tanto desde el panorama académico como desde
el industrial, en donde su demanda de temas es cada día mayor.
La finalidad primordial de (DSBC) es
entender los diferentes modelos de desarrollo de software y la importancia de
sus componentes y servicios. También evaluar las diferencias entre este modelo
y los estudiados anteriormente en el transcurso de desarrollar este tipo de
software.
Además deberíamos conocer los
fundamentos sobre los que se sienta el modelo y todas las tendencias al momento
de armar el software, es decir en su arquitectura.
¿Y por qué el empleo de este modelo de desarrollo en
el mundo del software?
Se dice que la progresiva necesidad
de efectuar sistemas complejos en poco de tiempo, y con menor esfuerzo tanto
del desarrollador como de la parte económica, está beneficiando el avance de lo
que se conoce como Desarrollo de Software Basado en Componentes (DSBC).
Este nuevo método se sustenta en
componentes software ya desarrollado, que son combinados apropiadamente para
satisfacer las exigencias del sistema.
Los primordiales esfuerzos de la
gente desarrolladora de software en estos temas se han basado hasta ahora en
los aspectos prácticos de los componentes, es decir, en la funcionalidad que
brindan. Sin embargo, por lo general se han venido previniendo muchos de los
aspectos de calidad que intervienen a la hora de seleccionar componentes y
ensamblarlos para construir aplicaciones que satisfagan los requisitos del
cliente.
Estos aspectos “extra-funcionales”,
cada vez absorbe la curiosidad de los arquitectos e ingenieros del software.
Por un lado, los requisitos extra-funcionales pueden afectar a varias partes
del sistema, y por ello tendrán prioridad si entran en conflicto con los
requisitos funcionales. Asimismo, el cuidadoso análisis de las propiedades de
calidad puede mejorar el proceso de diferencia de los componentes candidatos
que cumplan el núcleo de requisitos funcionales. Por ejemplo, si dos
componentes efectúan la misma funcionalidad, sus atributos extra-funcionales
pueden ser el criterio definitivo en el proceso de selección.
COTS
La segunda tarea para este modelo de
desarrollo se centraliza en los procesos y herramientas para la evaluación y
selección de componentes COTS. Aparte de tener en cuenta las obligaciones
funcionales de la aplicación, es necesario meditar otros factores que también
se mezclan a la hora de seleccionar componentes. El problema es que este tipo
de requisitos, denominados “extra-funcionales” son difíciles de apreciar,
aunque todos somos conscientes de la importancia que representan.
Estos factores priman muchas veces incluso más que
los funcionales, pues un diseñador hasta es capaz de adaptar la arquitectura de
un sistema para poder incluir un componente que se desea que esté, o bien para
evitar la presencia de un componente de un fabricante en el cual no se confía.
A pesar de estos problemas, los
beneficios que proporciona el DSBC están ampliando su uso en ambientes
industriales de desarrollo de software, sobre todo en cuanto a reducción de
esfuerzos y costes de desarrollo y mantenimiento, y a la mejora de la calidad
final de los productos y sistemas construidos. Esta extensión de su uso está
favoreciendo la aparición de numerosas metodologías y herramientas de
desarrollo para realizar un efectivo DSBC. Sin embargo, esta disciplina dista
aún de ser una verdadera “ingeniería”, pues aún no se dispone ni de métricas
adecuadas, ni de procesos precisos, ni de normativa internacional que la
regule.
En este sentido, la definición de
métricas de calidad para componentes y aplicaciones
Software, especialmente las
desarrolladas en base a componentes COTS, aparece como una necesidad imperiosa.
METODOS FORMALES
La denominación métodos
formalesse 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 la de
matemática discreta, y los conceptos matemáticos provienen de la teoría de
conjuntos, la lógica y el álgebra.
En la década de los 80, muchos investigadores de
ingeniería del software propusieron que el uso de métodos formales de
desarrollo era la mejor forma de mejorar la calidad del software. Argumentaban
que el rigor y el análisis detallado, que son una parte esencial de los métodos
formales, podrían dar lugar a programas con menos errores y más adecuados a las
necesidades de los usuarios. Predijeron que, en el siglo XXI, una gran
proporción del software estaría desarrollado usando métodos formales.
Claramente, esta predicción no se ha hecho realidad.
Existen cuatro razones principales para esto:
1. Una
ingeniería del software exitosa. El uso de otros métodos de ingeniería del software como los métodos estructurados, gestión
de configuraciones y ocultación de la información en el diseño del
software y procesos de desarrollo ha conducido a mejoras en la calidad del
software. La gente que sugirió que la única forma de mejorar la calidad del software era usando métodos formales estaba
claramente equivocada.
2. Cambios
en el mercado. En la década
de los 80, la calidad del software fue vista como un problema clave de la ingeniería del software. Sin embargo, desde
entonces, la cuestión crítica para muchas clases de desarrollo del software
no es la calidad, sino la oportunidad de mercado. El software debe
desarrollarse rápidamente, y los clientes están dispuestos a aceptar software con algunos defectos si se les entrega
rápidamente. Las técnicas para el desarrollo rápido del software no funcionan
de forma efectiva con las especificaciones formales. Por supuesto, la calidad
todavía es un factor importante, pero debe lograrse en el contexto de
entrega rápida.
3. Ámbito
limitado de los métodos formales. Los métodos formales no son muy apropiados
para la especificación de interfaces de usuario e interacciones del usuario. El
componente de interfaz de usuario se ha
convertido en una parte cada vez mayor de la mayoría de los sistemas, de manera
que realmente s6lo pueden usarse métodos formales cuando se desarrollan las
otras partes del sistema.
4. Escalabilidad
limitada de los métodos formales. Los métodos formales todavía no son
muy escalables. La mayoría de los proyectos con éxito que han usado estas
técnicas han estado relacionados con núcleos de sistemas críticos relativamente
pequeños. A medida que los sistemas incrementan su tamaño, el tiempo y esfuerzo
requerido para desarrollar una especificación formal crece de forma
desproporcionada.
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.
El uso de métodos formales está creciendo en el área
del desarrollo de sistemas críticos, en donde las propiedades emergentes del
sistema tales como seguridad, fiabilidad y protección son muy importantes. El
alto coste de los fallos de funcionamiento en estos sistemas implica que las
compañías están dispuestas a aceptar los costes elevados iniciales de los
métodos formales para asegurar que su software es tan confiable como sea
posible.
Los sistemas críticos en los que los métodos formales
se han aplicado con éxito incluyen un sistema de información de control de
tráfico aéreo, sistemas de señalización de redes ferroviarias, sistemas de
naves espaciales y sistemas de control médico.
Clasificación
La clasificación más común se realiza en base al
modelo matemático subyacente en cada método, de esta manera podrían
clasificarse en:
- Especificaciones basadas en lógica de primer
orden y teoría de conjuntos: permiten especificar el sistema mediante un
concepto formal de estados y operaciones sobre estados. Los datos y
relaciones/funciones se describen en detalle y sus propiedades se expresan
en lógica de primer orden. La semántica de los lenguajes está basada en la
teoría de conjuntos. Los métodos de este tipo más conocidos son: Z, VDM y
B.
- Especificaciones algebraicas:
proponen una descripción de estructuras de datos estableciendo tipos y
operaciones sobre esos tipos. Para cada tipo se define un conjunto de
valores y operaciones sobre dichos valores. Las operaciones de un tipo se
definen a través de un conjunto de axiomas o ecuaciones que especifican
las restricciones que deben satisfacer las operaciones. Métodos más
conocidos: Larch, OBJ, TADs.
Especificación de comportamiento:
- Métodos basados en álgebra de procesos:
modelan la interacción entre procesos concurrentes. Esto ha potenciado su
difusión en la especificación de sistemas de comunicación (protocolos y
servicios de telecomunicaciones) y de sistemas distribuidos y
concurrentes. Los más conocidos son: CCS,CSP y LOTOS.
- Métodos basados en Redes de Petri: una
red de petri es un formalismo basado en autómatas, es decir, un modelo
formal basado en flujos de información. Permiten expresar eventos
concurrentes. Los formalismos basados en redes de petri establecen la
noción de estado de un sistema mediante lugares que pueden contener
marcas. Un conjunto de transiciones (con pre y post condiciones) describe
la evolución del sistema entendida como la producción y consumo de marcas
en varios puntos de la red.
- Métodos basados en lógica temporal: se
usan para especificar sistemas concurrentes y reactivos. Los sistemas
reactivos son aquellos que mantienen una continua interacción con su
entorno respondiendo a los estímulos externos y produciendo salidas en
respuestas a los mismos, por lo tanto el orden de los eventos en el
sistema no es predecible y su ejecución no tiene por qué terminar.
TECNICAS DE CUARTA GENERACION
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.
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.
Para
aplicaciones pequeñas puede ser posible ir directamente desde el paso de
establecimiento de requerimientos a la implementación, sin embargo es necesaria una estrategia del
diseño para el sistema. El uso de T4G sin diseño para grandes proyectos causará
las mismas dificultades (poca calidad, pobre mantenimiento, mala aceptación por
el cliente) que se encuentran cuando se desarrolla software usando los métodos
convencionales.
El
último paso de la figura anterior contiene la palabra producto para transformar
una implementación T4G en un producto, el que lo desarrollo debe dirigir una
prueba completa, desarrollar una documentación con sentido y ejecutar todas las
otras actividades de transición requeridas en los otros paradigmas de la
ingeniería de software.
Los
defensores aducen reducciones dramáticas en el tiempo de desarrollo en el
software y una mejora significativa en la productividad de la gente que
construye el software. Los detractores de este paradigma aducen que los
lenguajes de programación, que el código fuente producido por tales
herramientas es ineficiente y que el mantenimiento de grandes sistema de software
desarrollado usando T4g está abierta a discusión.
Hay
algunos méritos en las razones de cada parte. Aunque es algo difícil separar
los hechos de las suposiciones es posible resumir el estado actual de los
métodos T4G:
Con
muy pocas excepciones el dominio de aplicación actual de las T4G está limitada
a las aplicaciones de sistema de información comerciales, específicamente del
análisis de información comercial, específicamente del análisis de información
y de la obtención de informes en las grandes bases de datos. Hasta la fecha T4G
se han usado muy poco en productos de ingeniería y áreas de aplicación de
sistemas.
La
recolección de datos preliminares que acompañan al uso de T4G parece indicar
que el tiempo requerido para producir software se reduce mucho para
aplicaciones pequeñas de trabajo medio así como también la cantidad de análisis
y diseño.
Sin
embargo el uso de T4G para grandes trabajos de desarrollo de software exige el
mismo o más tiempo de análisis, diseño y prueba perdiéndose así un tiempo sustancial
que se ahorra mediante la eliminación de la codificación.
En
conclusión podemos definir que las técnicas de cuarta generación pueden reducir
drásticamente el esfuerzo y tiempo de desarrollo en aplicaciones de pequeño y
mediano nivel, sin embargo debido a su imperfecto estado actual el desarrollo
de grandes aplicaciones con estas esta aun muy lejos de convertirse en una
realidad.
No hay comentarios:
Publicar un comentario