Sommerville define modelo de desarrollo de software como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.”
Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software.
Modelo Lineal Secuencial:
El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería. Éste toma las actividades fundamentales del proceso de especificación, Análisis, Diseño, generación de código y pruebas.
El modelo en lineal secuencial consta de las siguientes fases:
Análisis de los requisitos del software. El proceso de reunión de requisitos se intensifica y se centra especialmente en el software. Para comprender la naturaleza del (los) programa(s) a construirse, el ingeniero («arialista») del software debe comprender el dominio de información del software, así como la función requerida, comportamiento, rendimiento e interconexión.
Diseño. El diseño del software es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental (algoritmo). El proceso del diseño traduce requisitos en una representación del software donde se pueda evaluar su calidad antes de que comience la codificación.
Generación de código. El diseño se debe traducir en una forma legible por la máquina. El paso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una forma detallada, la generación de código se realiza mecánicamente.
Pruebas. Una vez que se ha generado el código, comienzan las pruebas del programa. El proceso de pruebas se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales; es decir, realizar las pruebas para la detección de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos.
Mantenimiento. El software indudablemente sufrirá cambios después de ser entregado al cliente (una excepción posible es el software empotrado). Se producirán cambios porque se han encontrado errores, porque el software debe adaptarse para acoplarse a los cambios de su entorno externo (por ejemplo: se requiere un cambio debido a un sistema operativo o dispositivo periférico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. El soporte y mantenimiento del software vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo. El modelo lineal secuencial es el paradigma más antiguo y más extensamente utilizado en la ingeniería del software. Sin embargo, la crítica del paradigma ha puesto en duda su eficacia. Entre los problemas que se encuentran algunas veces en el modelo lineal secuencial se incluyen:
1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo. Aunque el modelo lineal puede acoplar interacción, lo hace indirectamente.
Como resultado, los cambios pueden causar confusión cuando el equipo del proyecto comienza.
2. A menudo es difícil que el cliente exponga explícitamente todos los requisitos. El modelo lineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbre natural al comienzo de muchos proyectos.
3. El cliente debe tener paciencia. Una versión de trabajo del (los) programa(s) no estará disponible hasta que el proyecto esté muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se revisa el programa.
Modelo de Construcción de prototipos
Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombre -máquina.
En estas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque.
El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un «diseño rápido». El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente (por ejemplo: enfoques de entrada y formatos de salida). El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.
Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de los fragmentos del programa ya existentes o aplica herramientas (por ejemplo: generadores de informes, gestores de ventanas, etc.) que permiten generar rápidamente programas de trabajo.
Escuchar Construir/revisar al cliente El cliente prueba En la mayoría de los proyectos, el primer sistema construido apenas se puede utilizar. Puede ser demasiado lento, demasiado grande o torpe en su uso, o las tres a la vez. No hay otra alternativa que comenzar de nuevo, aunque nos duela pero es más inteligente, y construir una versión rediseñada en la que se resuelvan estos problemas... Cuando se utiliza un concepto nuevo de sistema o una tecnología nueva, se tiene que construir un sistema que no sirva y se tenga que tirar, porque incluso la mejor planificación no es omnisciente como para que esté perfecta la primera vez. Por lo tanto la pregunta de la gestión no es si construir un sistema piloto y tirarlo. Tendremos que hacerlo. La Única pregunta es si planificar de antemano construir un desechable, o prometer entregárselo a los clientes.. .
El prototipo puede servir como «primer sistema».
El que Brooks recomienda tirar. Aunque esta puede ser una visión idealizada. Es verdad que a los clientes y a los que desarrollan les gusta el paradigma de construcción de prototipos. A los usuarios les gusta el sistema real y a los que desarrollan les gusta construir algo inmediatamente. Sin embargo, la construcción de prototipos también puede ser problemática por las siguientes razones:
1. El cliente ve lo que parece ser una versión de trabajo del software, sin tener conocimiento de que el prototipo también está junto con «el chicle y el cable de embalar», sin saber que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo. Cuando se informa de que el producto se debe construir otra vez para que se puedan mantener los niveles altos de calidad, el cliente no lo entiende y pide que se apliquen anos pequeños ajustes>> para que se pueda hacer del prototipo un producto final.
De forma demasiado frecuente la gestión de desarrollo del software es muy lenta.
2. El desarrollador, a menudo, hace compromisos de implementación para hacer que el prototipo funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje de programación inadecuado simplemente porque está disponible y porque es conocido; un algoritmo eficiente se puede implementar simplemente para demostrar la capacidad. Después de algún tiempo, el desarrollador debe familiarizarse con estas selecciones, y olvidarse de las razones por las que son inadecuadas. La selección menos ideal ahora es una parte integral del sistema.
la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego al comienzo; es decir, el cliente y el desarrollador se deben poner de acuerdo en que el prototipo se construya para servir como un mecanismo de definición de requisitos.
Modelo de Desarrollo Rápido de Aplicaciones
El Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto.
El modelo DRA es una adaptación a «alta velocidad» del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando una construcción basada en componentes.
Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un «sistema completamente funcional» dentro de períodos cortos de tiempo (por ejemplo: de 60 a 90 días) . Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases :
Modelado de Gestión. El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la procesa? El modelado de gestión se describe con más detalle en el Capítulo 10.
Modelado de datos. El flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos.
Generación de aplicaciones. El DRA asume la utilización de técnicas de cuarta generación
En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas para facilitar la construcción del software.
Pruebas y entrega. Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.
El DRA hace un fuerte uso de componentes reutilizables.
Obviamente, las limitaciones de tiempo impuestas en un proyecto DRA demandan «ámbito en escalas»
Si una aplicación de gestión puede modularse de forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones puede ser afrontada por un equipo DRA separado y ser integradas en un solo conjunto.
Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:
· Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA.
· DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado.
· Si no hay compromiso por ninguna de las partes constituyentes, los proyectos DRA fracasarán.
· No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modularizar adecuadamente, la construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistemas, el enfoque DRA puede que no funcione.
· DRA no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el software nuevo requiere un alto grado de interoperabilidad con programas de computadora ya existentes.
Modelo Incremental
Mills sugirió el modelo incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema.
Reduce el trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de Lineal secuencial o desarrollo concurrente, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por lineal secuencial, si es dudoso, desarrollo concurrente.
El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofía interactiva de construcción de prototipos. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un «incremento» del software. Por ejemplo, el software de tratamiento de textos desarrollado con el paradigma incremental podría extraer funciones de gestión de archivos básicos y de producción de documentos en el primer incremento; funciones de edición más sofisticadas y de producción de documentos en el segundo incremento; corrección ortográfica y gramatical en el tercero; y una función avanzada de esquema de página en el cuarto. Se debería tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos.
Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos básicos, pero muchas funciones
Diseño suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisión detallada). Como un resultado de utilización y/o de evaluación, se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y características adicionales.
Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. El modelo de proceso incremental, como la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones «incompletas» del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación.
El desarrollo incremental es particularmente útil cuando la dotación de personal no está disponible para una implementación completa en la fecha límite que se haya establecido para el proyecto. Los primeros incrementos se pueden implementar con menos personas.
Modelo Espiral
El modelo en espiral es actualmente uno de los más conocidos y fue propuesto por Boehm. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado.
Cada ciclo de desarrollo se divide en cuatro fases:
1. Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos.
2. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.
3. Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase.
4. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.
Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto.
El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.
El modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas.
1. Comunicación con el cliente- las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
2. Planificación- las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto.
3. Análisis de riesgos- las tareas requeridas para evalúa riesgos técnicos y de gestión.
4. Ingeniería- las tareas requeridas para construir una o más representaciones de la aplicación.
5. Construcción y acción- las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentación y práctica)
6. Evaluación del cliente- las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.
El modelo espiral WINWIN (Victoria & Victoria)
El modelo en espiral sugiere una actividad del marco de trabajo que aborda la comunicación con el cliente. El objetivo de esta actividad es mostrar los requisitos del cliente. En un contexto ideal, el desarrollador simplemente pregunta al cliente lo que se necesita y el cliente proporciona detalles suficientes para continuar. Desgraciadamente, esto raramente ocurre. En realidad el cliente y el desarrollador entran en un proceso de negociación, donde el cliente puede ser preguntado para medir la funcionalidad, rendimiento, y otros productos o características del sistema frente al coste y al tiempo de comercialización.
Las mejores negociaciones se esfuerzan en obtener'
«victoria-victoria». Esto es, el cliente gana obteniendo el producto o sistema que satisface la mayor parte de sus necesidades y el desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de entrega realista.
El modelo en espiral WINWIN de Boehm [BOE98] define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente, se definen las siguientes actividades:
1. Identificación del sistema o subsistemas clave de los «directivos»
2. Determinación de las «condiciones de victoria» de los directivos.
3. Negociación de las condiciones de «victoria» de los directivos para reunirlas en un conjunto de condiciones «victoria-victoria» para todos los afectados (incluyendo el equipo del proyecto de software).
En esencia, los puntos de fijación representan tres visiones diferentes del progreso mientras que el proyecto recorre la espiral. El primer punto de fijación, llamado objetivos del ciclo de vida (OCV), define un conjunto de objetivos para cada actividad principal de ingeniería del software. Como ejemplo, de una parte de OCV, un conjunto de objetivos asociados a la definición de los requisitos del producto/sistema del nivel más alto. El segundo punto de fijación, llamado arquitectura del ciclo de vida (ACV), establece los objetivos que se deben conocer mientras que se define la arquitectura del software y el sistema. Como ejemplo, de una parte de la ACV, el equipo del proyecto de software debe demostrar que ha evaluado la funcionalidad de los componentes del software reutilizables y que ha considerado su impacto en las decisiones de arquitectura. La capacidad operativa inicial (COI) es el tercer punto de fijación y representa un conjunto de objetivos asociados a la preparación del software para la instalación/distribución, preparación del lugar previamente a la instalación, y la asistencia precisada de todas las partes que utilizará o mantendrá el software.
Modelo de Desarrollo Concurrente
El modelo de desarrollo concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas. Por ejemplo, la actividad de ingeniería definida para el modelo en espiral se lleva a cabo invocando las tareas siguientes: modelado de construcción de prototipos y/o análisis, especificación de requisitos y diseño'.
La actividad -análisis- se puede encontrar en uno de los estados'" destacados anteriormente en cualquier momento dado. De forma similar, otras actividades (por ejemplo: diseño o comunicación con el cliente) se puede representar de una forma análoga. Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por ejemplo, al principio del proyecto la actividad de comunicación con el cliente ha finalizado su primera iteración y está en el estado de cambios, en espera. La actividad de análisis (que estaba en el estado ninguno mientras que se iniciaba la comunicación inicial con el cliente) ahora hace una transición al estado bajo desarrollo.
Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad análisis cambia del estado bajo desarrollo al estado cambios en espera.
El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera.
El modelo de desarrollo concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor" Un sistema cliente/servidor se compone de un conjunto de componentes funcionales.
Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una dimensión de sistemas y una dimensión de componentes. Los aspectos del nivel de sistemas se afrontan mediante tres actividades: diseño, ensamblaje y uso.
La dimensión de componentes se afronta con dos actividades: diseño y realización. La concurrencia se logra de dos formas: (1) las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente; (2) una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente. En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto.
Modelo de Desarrollo Basado en Componentes
El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo en espiral. Es evolutivo por naturaleza, y exige un enfoque iterativo para la creación del software.
Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software llamados «clases». La actividad de la ingeniería comienza con la identificación de clases candidatas. Esto se lleva a cabo examinando los datos que se van a manejar por parte de la aplicación y el algoritmo que se va a aplicar para conseguir el tratamiento. Los datos y los algoritmos correspondientes se empaquetan en una clase. Las clases creadas en los proyectos de ingeniería del software anterior, se almacenan en una biblioteca de clases o diccionario de datos.
Una vez identificadas las clases candidatas, la biblioteca de clases se examina para determinar si estas clases ya existen. En caso de que así fuera, se extraen de la biblioteca y se vuelven a utilizar. Si una clase candidata no reside en la biblioteca, se aplican los métodos orientados a Objetos. Se compone así la primera iteración de la aplicación a construirse, mediante las clases extraídas de la biblioteca y las clases nuevas construidas para cumplir las necesidades Únicas de la aplicación. El flujo del proceso vuelve a la espiral y volverá a introducir por último la iteración ensambladora de componentes a través de la actividad de ingeniería. El modelo de desarrollo basado en componentes conduce a la reutilización del software, y la reutilización proporciona beneficios a los ingenieros de software. Según estudios de reutilización, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reducción del 70 % de tiempo de ciclo de desarrollo, un 84 % del coste del proyecto y un índice de productividad del 26.2, comparado con la norma de industria del
16.9. Aunque estos resultados están en función de la robustez de la biblioteca de componentes, no hay duda de que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros de software.
El proceso unificado de desarrollo de software representa un número de modelos de desarrollo basados en componentes que han sido propuestos en la industria. Utilizando el Lenguaje de Modelado Unificado (UML), el proceso unificado define los componentes que se utilizarán para construir el sistema y las interfaces que conectarán los componentes. Utilizando una combinación del desarrollo incremental e iterativo, el proceso unificado define la función del sistema aplicando un enfoque basado en escenarios (desde el punto de vista de1 usuario). Entonces acopla la función con un marco de trabajo arquitectónico que identifica la forma que tomará el software.
Modelo de Métodos Formales
El modelo de métodos formales comprende un conjunto de actividades que conducen a la especificación matemática del software de computadora. Los métodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática. Algunas organizaciones de desarrollo del software actualmente aplican una variación de este enfoque, llamado ingeniería del software de sala limpia. Cuando se utilizan métodos formales durante el desarrollo, proporcionan un mecanismo para eliminar muchos de los problemas que son difíciles de superar con paradigmas de la ingeniería del software. La ambigüedad, lo incompleto y la inconsistencia se descubren y se corrigen más fácilmente no mediante una revisión a propósito para el caso, sino mediante la aplicación del análisis matemático. Cuando se utilizan métodos formales durante el diseño, sirven como base para la verificación de programas y por consiguiente permiten que el ingeniero del software descubra y corrija errores que no se pudieron detectar de otra manera. Aunque todavía no hay un enfoque establecido, los modelos de métodos formales ofrecen la promesa de un software libre de defectos. Sin embargo, se ha hablado de una gran preocupación sobre su aplicabilidad en un entorno de gestión:
1. El desarrollo de modelos formales actualmente es bastante caro y lleva mucho tiempo.
2. Se requiere un estudio detallado porque pocos responsables del desarrollo de software tienen los antecedentes necesarios para aplicar métodos formales.
3. Es difícil utilizar los modelos como un mecanismo de comunicación con clientes que no tienen muchos conocimientos técnicos.
No obstante es posible que el enfoque a través de métodos formales tenga más partidarios entre los desarrolladores del software que deben construir software de mucha seguridad (por ejemplo: los desarrolladores de aviónica y dispositivos médicos), y entre los desarrolladores que pasan grandes penurias económicas al aparecer errores de software.
Modelo de Técnicas de 4ta Generación
El término técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software que tienen algo en común: todas facilitan al ingeniero del software la especificación de algunas características del software a alto nivel. Luego, la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Cada vez parece más evidente que cuanto mayor sea el nivel en el que se especifique el software, más rápido se podrá construir el programa. El paradigma T4G para la ingeniería del software se orienta hacia la posibilidad de especificar el software usando formas de lenguaje especializado o notaciones gráficas que describa el problema que hay que resolver en términos que los entienda el cliente. Actualmente, un entorno para el desarrollo de software que soporte el paradigma T4G puede incluir todas o algunas de las siguientes herramientas: lenguajes no procedimentales de consulta a bases de datos, generación de informes, manejo de datos, interacción y definición de pantallas, generación de códigos, capacidades gráficas de alto nivel y capacidades de hoja de cálculo, y generación automatizada de HTML y lenguajes similares utilizados para la creación de sitios web usando herramientas de software avanzado. Inicialmente, muchas de estas herramientas estaban disponibles, pero sólo para ámbitos de aplicación muy específicos, pero actualmente los entornos T4G se han extendido a todas las categorías de aplicaciones del software.
Al igual que otros paradigmas, T4G comienza con el paso de reunión de requisitos. Idealmente, el cliente describe los requisitos, que son, a continuación, traducidos directamente a un prototipo operativo. Sin embargo, en la práctica no se puede hacer eso. El cliente puede que no esté seguro de lo que necesita; puede ser ambiguo en la especificación de hechos que le son conocidos, y puede que no sea capaz o no esté dispuesto a especificar la información en la forma en que puede aceptar una herramienta T4G. Por esta razón, el diálogo cliente-desarrollador descrito por los otros paradigmas sigue siendo una parte esencial del enfoque T4G. Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección de requisitos al paso de implementación, usando un lenguaje de cuarta generación no procedimental (L4G) o un modelo comprimido de red de iconos gráficos. Sin embargo, es necesario un mayor esfuerzo para desarrollar una estrategia de diseño para el sistema, incluso si se utiliza un L4G. El uso de T4G sin diseño (para grandes proyectos) causará las mismas dificultades (poca calidad, mantenimiento pobre, mala aceptación por el cliente) que se encuentran cuando se desarrolla software mediante los enfoques convencionales.
La implementación mediante L4G permite, al que desarrolla el software, centrarse en la representación de los resultados deseados, que es lo que se traduce automáticamente en un código fuente que produce dichos resultados. Obviamente, debe existir una estructura de datos con información relevante y a la que el L4G pueda acceder rápidamente.
Para transformar una implementación T4G en un producto, el que lo desarrolla debe dirigir una prueba completa, desarrollar con sentido una documentación y ejecutar el resto de las actividades de integración que son también requeridas por otros paradigmas de ingeniería del software. Además, el software desarrollado con T4G debe ser construido de forma que facilite la realización del mantenimiento de forma expeditiva.
Al igual que todos los paradigmas del software, el modelo T4G tiene ventajas e inconvenientes. Los defensores aducen reducciones drásticas en el tiempo de desarrollo del software y una mejora significativa en la productividad de la gente que construye el software.
Los detractores aducen que las herramientas actuales de T4G no son más fáciles de utilizar que los lenguajes de programación, que el código fuente producido por tales herramientas es «ineficiente» y que el mantenimiento de grandes sistemas de software desarrollados mediante T4G es cuestionable.
No hay comentarios:
Publicar un comentario