ISW-S02-El Proceso

INGENIERÍA DEL SOFTWARE SESIÓN NÚMERO 02 EL PROCESO Conocer el significado del proceso dentro de la Ingeniería.

CAPÍTULO 1: GESTIÓN DE PROYECTOS DE SOFTWARE ISTP-KHIPU

WILBERT DALGUERRE ORDÓÑEZ 2013 - I

El Proceso

Contenido EL PROCESO ................................................................................................ 3 INGENIERÍA DEL SOFTWARE: UNA TECNOLOGÍA ESTRATIFICADA ....................................... 3 PROCESO, MÉTODOS Y HERRAMIENTAS .............................................................................. 4 UNA VISIÓN GENERAL DE LA INGENIERÍA DEL SOFTWARE .................................................. 5 La fase de definición se centra sobre el qué. ....................................................................... 5 La fase de desarrollo se centra en el cómo. ......................................................................... 6 La fase de mantenimiento .................................................................................................... 6 EL PROCESO DEL SOFTWARE ................................................................................................ 7 Nivel 1:.................................................................................................................................. 8 Nivel 2:.................................................................................................................................. 8 Nivel 3:.................................................................................................................................. 8 Nivel 4:.................................................................................................................................. 8 Nivel 5:.................................................................................................................................. 9 MODELOS DEL PROCESO DE SOFTWARE............................................................................ 10 1. EL MODELO LINEAL SECUENCIAL.................................................................................... 11 2. EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS ......................................................... 13 3. EL MODELO DRA ............................................................................................................. 15 MODELOS EVOLUTIVOS DE PROCESO DEL SOFTWARE ...................................................... 17 1. El modelo lineal secuencial se diseña para el desarrollo en línea recta. ....................... 18 2. El modelo incremental ................................................................................................... 18 3. El modelo espiral ............................................................................................................ 19 4. El modelo espiral WINWIN ............................................................................................. 22 5. El modelo de desarrollo concurrente ............................................................................. 23

1

El Proceso DEASARROLLO BASADO EN COMPONENTES ..................................................................... 25 EL MODELO DE MÉTODOS FORMALES ............................................................................... 27 TÉCNICAS DE CUARTA GENERACIÓN .................................................................................. 28 TÉCNOLOGÍAS DE PROCESO ............................................................................................... 31 PRODUCTO Y PROCESO ...................................................................................................... 31 BIBLIOGRAFÍA ................................................................................................................ 34

2

El Proceso

EL PROCESO Pero,

¿qué

es exactamente el proceso del software desde un punto de vista técnico?, definimos un proceso de software como un marco de trabajo de las tareas que se requieren para construir software de alta calidad. ¿Es «proceso» sinónimo de ingeniería del software? La respuesta es «sí» y «no». Un proceso de software define el enfoque que se toma cuando el software es tratado por la ingeniería. Pero la ingeniería del software también comprende las tecnologías que tiene el proceso (métodos técnicos y herramientas automatizadas). Aún más importante es que la ingeniería del software la realizan personas creativas, con conocimiento, que deberían trabajar dentro de un proceso del software definido y avanzado que es apropiado para los productos que construyen y para las demandas de su mercado.

INGENIERÍA DEL SOFTWARE: UNA TECNOLOGÍA ESTRATIFICADA Aunque cientos de autores han desarrollado definiciones personales de la ingeniería del software, una definición propuesta por Fritz Bauer en una conferencia de gran influencia sobre estos temas va a servir como base de estudio: La ingeniería del software es el establecimiento y uso de principios robustos de la ingeniería a fin de obtener económicamente software que sea fiable y que funcione eficientemente sobre máquinas reales.

Casi todos tendrán la tentación de seguir esta definición. No dice mucho sobre los aspectos técnicos de la calidad del software; no se enfrenta directamente con la necesidad de la satisfacción del cliente o de la entrega oportuna del producto; omite la mención de la importancia de mediciones y métricas; tampoco expresa la importancia de un proceso avanzado. Y sin embargo, la definición de Bauer nos proporciona una línea base. ¿Cuáles son los «principios

3

El Proceso robustos de la ingeniería» aplicables al desarrollo de software de computadora? ¿Cómo construimos el software «económicamente» para que sea «fiable»? ¿Qué se necesita para crear programas de computadora que funcionen «eficientemente» no en una máquina si no en diferentes «máquinas reales»? Éstas son cuestiones que siguen siendo un reto para los ingenieros del software.

Existe una definición más completa: Ingeniería del software: La aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software.

PROCESO, MÉTODOS Y HERRAMIENTAS La Ingeniería del software es una tecnología multicapa, cualquier enfoque de ingeniería (incluida ingeniería del software) debe apoyarse sobre un compromiso de organización de calidad. El fundamento de la ingeniería del software es la capa de proceso. El proceso de la ingeniería del software es la unión que mantiene juntas las capas de tecnología y que permite un desarrollo racional y oportuno de la ingeniería del software. El proceso define un marco de trabajo para un conjunto de Áreas clave de proceso (ACPs) que se deben establecer para la entrega efectiva de la tecnología de la ingeniería del software.

Las áreas claves del proceso forman la base del control de gestión de proyectos del software y establecen el contexto en el que se aplican los métodos técnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.

Los métodos de la ingeniería del software indican «cómo» construir técnicamente el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Los métodos de la ingeniería del software dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas Las herramientas de la Ingeniería del software proporcionan un enfoque automático o semiautomático para el proceso y para los métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el

4

El Proceso desarrollo del software llamado ingeniería del software asistida por computadora (CASE).

UNA VISIÓN GENERAL DE LA INGENIERÍA DEL SOFTWARE La ingeniería es el análisis, diseño, construcción, verificación y gestión de entidades técnicas (o sociales). Con independencia de la entidad a la que se va a aplicar ingeniería, se deben cuestionar y responder las siguientes preguntas: ¿Cuál es el problema a resolver? ¿Cuáles son las características de la entidad que se utiliza para resolver el problema? ¿Cómo se realizará la entidad (y la solución)? ¿Cómo se construirá la entidad? ¿Qué enfoque se va a utilizar para no contemplar los errores que se cometieron en el diseño y en la construcción de la entidad? ¿Cómo se apoyará la entidad cuando usuarios soliciten correcciones, adaptaciones y mejoras de la entidad?

Nos vamos a centrar en una sola entidad (el software de computadora). Para construir la ingeniería del software adecuadamente, se debe definir un proceso de desarrollo de software. En esta sección se consideran las características genéricas del proceso de software. Más adelante, se tratarán modelos específicos de procesos. El trabajo que se asocia a la ingeniería del software se puede dividir en tres fases genéricas, con independencia del área de aplicación, tamaño o complejidad del proyecto. Cada fase se encuentra con una o varias cuestiones de las destacadas anteriormente.

La fase de definición se centra sobre el qué.

Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño existen, y qué criterios de validación se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software. Aunque los métodos aplicados durante la fase de definición variarán dependiendo del paradigma de ingeniería del

5

El Proceso software (o combinación de paradigmas) que se aplique, de alguna manera tendrán lugar tres tareas principales: ingeniería de sistemas o de información, planificación del proyecto del software y análisis de los requisitos.

La fase de desarrollo se centra en el cómo.

Es decir, durante el desarrollo un ingeniero del software intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función dentro de una arquitectura de software, cómo han de implementarse los detalles procedimentales, cómo han de caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba. Los métodos aplicados durante la fase de desarrollo variarán, aunque las tres tareas específicas técnicas deberían ocurrir siempre: diseño del software, generación de código y prueba del software.

La fase de mantenimiento Se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente.

Durante la fase de mantenimiento se encuentran cuatro tipos de cambios: Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra los defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos.

Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (por ejemplo: CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el que se desarrolló el software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo.

6

El Proceso Mejora. Conforme se utilice el software, el cliente/ usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.

Prevención. El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el mantenimiento preventivo hace cambios en programas de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

EL PROCESO DEL SOFTWARE Un proceso de software establece un marco común del proceso definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos del software, con independencia de su tamaño o complejidad. Un número de conjuntos de tareas (cada uno es una colección de tareas de trabajo de ingeniería del software, hitos de proyectos, productos de trabajo, y puntos de garantía de calidad) que permiten que las actividades del marco de trabajo se adapten a las características del proyecto del software y a los requisitos del equipo del proyecto. Finalmente, las actividades de protección (tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo de procesos). Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso. En los Últimos años, se ha hecho mucho énfasis en la «madurez del proceso>>. El Software Enginierin Institute (SEI) ha desarrollado un modelo completo que se basa en un conjunto de funciones de ingeniería del software que deberían estar presentes conforme organizaciones alcanzan diferentes niveles de madurez del proceso. Para determinar el estado actual de madurez del proceso de una organización, el SEI utiliza un cuestionario de evaluación y un esquema de cinco grados. El esquema de grados determina la conformidad con un modelo de capacidad de madurez que define las actividades clave que se requieren en los diferentes niveles de madurez del proceso.

7

El Proceso El enfoque del SEI proporciona una medida de la efectividad global de las prácticas de ingeniería del software de una compañía y establece cinco niveles de madurez del proceso, que se definen de la forma siguiente:

Nivel 1: Inicial. El proceso del software se caracteriza según el caso, y ocasionalmente incluso de forma caótica. Se definen pocos procesos, y el éxito depende del esfuerzo individual.

Nivel 2: Repetible. Se establecen los procesos de gestión del proyecto para hacer seguimiento del coste, de la planificación y de la funcionalidad.

Para repetir éxitos anteriores en proyectos con aplicaciones similares se aplica la disciplina necesaria para el proceso.

Nivel 3: Definido. El proceso del software de las actividades de gestión y de ingeniería se documenta, se estandariza y se integra dentro de un proceso de software de toda una organización. Todos los proyectos utilizan una versión documentada y aprobada del proceso de la organización para el desarrollo y mantenimiento del software. En este nivel se incluyen todas las características definidas para el nivel 2.

Nivel 4: Gestionado. Se recopilan medidas detalladas del proceso del software y de la calidad del producto. Mediante la utilización de medidas detalladas, se comprenden y se controlan cuantitativamente tanto los productos como el proceso del software. En este nivel se incluyen todas las características definidas para el nivel 3.

8

El Proceso Nivel 5: Optimización. Mediante una retroalimentación cuantitativa del proceso, ideas y tecnologías innovadoras se posibilita una mejora del proceso. En este nivel se incluyen todas las características definidas para el nivel 4.

Merece la pena destacar que cada nivel superior es la suma de los niveles anteriores, por ejemplo, un desarrollador de software en el nivel 3 tiene que haber alcanzado el estado nivel 2 para poder disponer de sus procesos en el nivel 3. El nivel 1 representa una situación sin ningún esfuerzo en la garantía de calidad y gestión del proyecto, donde cada equipo del proyecto puede desarrollar software de cualquier forma eligiendo los métodos, estándares y procedimientos a utilizar que podrán variar desde lo mejor hasta lo peor. El nivel 2 representa el hecho de que un desarrollador de software ha definido ciertas actividades tales como el informe del esfuerzo y del tiempo empleado, y el Una métrica es una informe de las tareas realizadas. El nivel 3 representa cantidad el hecho de que un desarrollador de software ha insignificante que definido tanto procesos técnicos como de gestión, por puede extraerse de ejemplo un estándar para la programación ha sido algún documento o detallado y se hace cumplir por medio de código dentro de procedimientos tales como auditorías. Este nivel es un proyecto de aquel en el que la mayoría de los desarrolladores de software. software, pretenden conseguir con estándares como el ISO 9001, y existen pocos casos de desarrolladores de software que superan este nivel. El nivel 4 comprende el concepto de medición y el uso de métricas. Sin embargo, cabe destacar el concepto de métrica para comprender la importancia que tiene que el desarrollador del software alcance el nivel 4 o el nivel 5.

Un ejemplo de métrica es el número de ramas condicionales en una sección de código de un programa. Esta métrica es significativa en el sentido de que proporciona alguna indicación del esfuerzo necesario para probar el código: está directamente relacionado con el número de caminos de prueba dentro del código.

9

El Proceso Una organización del nivel 4 maneja numerosas métricas. Estas métricas se utilizan entonces para supervisar y controlar un proyecto de software, por ejemplo: Una métrica de prueba puede usarse para determinar cuándo finalizar la prueba de un elemento del código. Una métrica de legibilidad puede usarse para juzgar la legibilidad de algún documento en lenguaje natural. Una métrica de comprensión del programa puede utilizarse para proporcionar algún umbral numérico que los programadores no pueden cruzar. Para que estas métricas alcancen este nivel es necesario que todos los componentes del nivel 3 CMM, en castellano MCM (Modelo de Capacidad de Madurez), estén conseguidos, por ejemplo notaciones bien definidas para actividades como la especificación del diseño de requisitos, por lo que estas métricas pueden ser fácilmente extraídas de modo automático.

El nivel 5 es el nivel más alto a alcanzar. Hasta ahora, muy pocos desarrolladores de software han alcanzado esta fase. Representa la analogía del software con los mecanismos de control de calidad que existen en otras industrias de mayor madurez. Por ejemplo el fabricante de un producto industrial como un cojinete de bolas (rodamiento) puede supervisar y controlar la calidad de los rodamientos producidos y puede predecir esta calidad basándose en los procesos y máquinas utilizados para desarrollar los rodamientos.

Del mismo modo que el desarrollador del software en el nivel 5 puede predecir resultados como el número de errores latentes en un producto basado en la medición tomada durante la ejecución de un proyecto. Además, dicho desarrollador puede cuantificar el efecto que un proceso nuevo o herramienta de manufacturación ha tenido en un proyecto examinando métricas para ese proyecto y comparándolas con proyectos anteriores que no utilizaron ese proceso o herramienta En este orden debe destacarse que para que un desarrollador de software alcance el nivel 5 tiene que tener cada proceso definido rigurosamente y seguirlo al pie de la letra; esto es una consecuencia de estar en el nivel 3. Si el desarrollador del software no tiene definidos rigurosamente los procesos pueden ocurrir una gran cantidad de cambios en el proceso de desarrollo y no se podrán utilizar las estadísticas para estas actividades.

MODELOS DEL PROCESO DE SOFTWARE

10

El Proceso Para resolver los problemas reales de una industria, un ingeniero del software o un equipo de ingenieros deben incorporar una estrategia de desarrollo que acompañe al proceso, métodos y capas de herramientas y las fases genéricas discutidas en una Sección anterior. Esta estrategia a menudo se llama modelo de proceso o paradigma de ingeniería del software. Se selecciona un modelo de proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, y los controles y entregas que se requieren.

En un documento intrigante sobre la naturaleza del proceso del software, L.B.S. Raccoon utiliza fractales como base de estudio de la verdadera naturaleza del proceso del software.

1. EL MODELO LINEAL SECUENCIAL

Un fractal es un objeto geométrico cuya estructura básica, fragmentada o irregular, se repite a diferentes escalas.

Llamado algunas veces «ciclo de vida básico» o modelo en cascada», el modelo lineal secuencial sugiere un enfoque5 sistemático, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento. La Figura muestra el modelo lineal secuencial para la ingeniería del software. Modelado según el ciclo de ingeniería convencional, el modelo lineal secuencial comprende las siguientes actividades: Ingeniería y modelado de Sistemas/Información. Como el software siempre forma parte de un sistema más grande (o empresa), el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algún subgrupo de estos requisitos.

Esta visión del sistema es esencial cuando el software se debe interconectar con otros elementos como hardware, personas y bases de datos. La ingeniería y el análisis de sistemas comprenden los requisitos que se recogen en el nivel del sistema con una pequeña parte de análisis y de diseño. La ingeniería de información abarca los requisitos que se recogen en el nivel de empresa estratégico y en el nivel del área de negocio.

11

El Proceso

FIGURA. El modelo lineal secuencial.

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 («analista ») 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.

12

El Proceso 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. ¿Por qué falla algunas veces el modelo lineal?

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

2. EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS El modelo lineal 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.

13

El Proceso 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. Pero ¿qué hacemos con el prototipo una vez que ha servido para el propósito descrito anteriormente? Brooks proporciona una respuesta: 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:

14

El Proceso  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 unos 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.  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.

Aunque pueden surgir problemas, 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.

3. EL MODELO DRA 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

15

El Proceso 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?

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. 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 pueden ser afrontadas por un equipo DRA separado y ser integradas en un solo conjunto.

16

El Proceso 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 inter-operatividad con programas de computadora ya existentes.

MODELOS EVOLUTIVOS DE PROCESO DEL SOFTWARE Se reconoce que el software, al igual que todos los sistemas complejos, evoluciona con el tiempo. Los requisitos de gestión y de productos a menudo cambian conforme a que el desarrollo proceda haciendo que el camino que lleva al producto final no sea real; las estrictas fechas tope del mercado hacen que sea imposible finalizar un producto completo, por lo que se debe introducir una versión limitada para cumplir la presión competitiva y de gestión; se comprende perfectamente el conjunto de requisitos de productos centrales o del sistema, pero todavía se tienen que definir los detalles de extensiones del producto o sistema. En estas y en otras situaciones similares, los ingenieros del software necesitan un modelo de proceso que se ha diseñado explícitamente para acomodarse a un producto que evolucione con el tiempo.

17

El Proceso 1. El modelo lineal secuencial se diseña para el desarrollo en línea recta.

En esencia, este enfoque en cascada asume que se va entregar un sistema completo una vez que la secuencia lineal se haya finalizado.

El modelo de construcción de prototipos se diseña para ayudar al cliente (o al que desarrolla) a comprender los requisitos. En general, no se diseña para entregar un sistema de producción. En ninguno de los paradigmas de ingeniería del software se tiene en cuenta la naturaleza evolutiva del software.

Los modelos evolutivos son iterativos. Se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez más completas del software.

2. El modelo incremental El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofía interactiva de construcción de prototipos. Como muestra la figura en la parte inferior, el modelo incremental aplica secuencias lineales de forma escalonada mientras Programación basada en prototipos progresa el tiempo en el calendario. Cada es un estilo de programación secuencia lineal produce un «incremento» orientada a objetos en el cual, las del software. Por ejemplo, el software de "clases" no están presentes, y la retratamiento de textos desarrollado con el utilización de procesos (conocida paradigma incremental podría extraer como herencia en lenguajes funciones de gestión de archivos básicos y basados en clases) se obtiene a de producción de documentos en el primer través de la clonación de objetos ya existentes, que sirven de incremento; funciones de edición más prototipos, extendiendo sus sofisticadas y de producción de funcionalidades. 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

18

El Proceso básicos, pero muchas funciones 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.

3. El modelo espiral El modelo en espiral, propuesto originalmente por Boehm, 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

19

El Proceso el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteracciones, 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.

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. La Figura anterior representa un modelo en espiral que contiene seis regiones de tareas:  comunicación con el cliente- las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.  planificación- las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto.  análisis de riesgos- las tareas requeridas para evaluar riesgos técnicos y de gestión.  ingeniería- las tareas requeridas para construir una o más representaciones de la aplicación.  construcción y acción- las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentación y práctica)  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.

Cada una de las regiones están compuestas por un conjunto de tareas del trabajo, llamado conjunto de tareas, que se adaptan a las características del proyecto que va a emprenderse. Para proyectos pequeños, el número de tareas de trabajo y su formalidad es bajo.

20

El Proceso Para proyectos mayores y más críticos cada región de tareas contiene tareas de trabajo que se definen para lograr un nivel más alto de formalidad. En todos los casos, se aplican las actividades de protección (por ejemplo: gestión de configuración del software y garantía de calidad del software). Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral puede producir el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software. Cada paso por la región de planificación produce ajustes en el plan del proyecto. El coste y la planificación se ajustan con la realimentación ante la evaluación del cliente. Además, el gestor del proyecto ajusta el número planificado de iteraciones requeridas para completar el software.

A diferencia del modelo de proceso clásico que termina cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Una visión alternativa del modelo en espiral puede ser considerada examinando el eje de punto de entrada en el proyecto también reflejado en la Figura anterior. Cada uno de los cubos situados a lo largo del eje pueden usarse para representar el punto de arranque para diferentes tipos de proyectos. Un «proyecto de desarrollo de conceptos» comienza en el centro de la espiral y continuará (aparecen múltiples iteraciones a lo largo de la espiral que limita la región sombreada central) hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso continúa a través del cubo siguiente (punto de entrada del proyecto de desarrollo del producto nuevo) y se inicia un «nuevo proyecto de desarrollo”. El producto nuevo evolucionará a través de iteraciones alrededor de la espiral siguiendo el camino que limita la región algo más brillante que el centro. En esencia, la espiral, cuando se caracteriza de esta forma, permanece operativa hasta que el software se retira. Hay veces en que el proceso está inactivo, pero siempre que se inicie un cambio, el proceso arranca en el punto de entrada adecuado (por ejemplo: mejora del producto). El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software a gran escala. 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 utiliza la construcción de prototipos como mecanismo de

21

El Proceso reducción de riesgos, pero, lo que es más importante, permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida clásico, pero lo incorpora al marco de trabajo iterativo que refleja de forma más realista el mundo real.

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 problemáticos.

4. El modelo espiral WINWIN 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 sopesar 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 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:   

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

22

El Proceso Conseguidos completamente estos pasos iniciales se logra un resultado «victoria-victoria», que será el criterio clave para continuar con la definición del sistema y del software. Además del énfasis realizado en la negociación inicial, 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 de la espiral y proporcionan hitos de decisión antes de continuar el 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.

5. El modelo de desarrollo concurrente Davis y Sitaram han descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la forma siguiente: 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 tienen idea del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente complejos de actividades mediante modelos demasiado simples.

Tenga en cuenta que aunque un proyecto grande esté en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo

23

El Proceso simultáneamente. Por ejemplo, El personal está escribiendo requisitos, diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de procesos de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren durante cualquier fase. El trabajo más reciente de Kellner utiliza diagramas de estado [una notación que representa los estados de un proceso] para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento específico (por ejemplo: un cambio de requisitos durante el último desarrollo), pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades de desarrollo y de gestión del software en un proyecto. La mayoría de los modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso de desarrollo. Un modelo de proceso concurrente está dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.

El modelo de proceso 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. Todas las actividades existen concurrentemente, pero residen en estados diferentes. Por ejemplo, al principio del proyecto la actividad de comunicación con el cliente (no mostrada en la figura) 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.

24

El Proceso El modelo de proceso 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.

DEASARROLLO BASADO EN COMPONENTES Las tecnologías de objetos proporcionan el marco de trabajo técnico para un modelo de proceso basado en componentes para la ingeniería del software. El paradigma orientado a objetos enfatiza la creación de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se diseñan y se implementan adecuadamente, las clases orientadas a objetos son

25

El Proceso reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadora.

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.

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 anteriores, se almacenan en una biblioteca de clases o diccionario de datos (repository). 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

26

El Proceso Associates, Inc. Informa que el ensamblaje de componentes lleva a una reducción del 70 por 100 de tiempo de ciclo de desarrollo, un 84 por 100 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.

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

27

El Proceso 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.

TÉCNICAS DE CUARTA 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,

28

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

29

El Proceso 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.

Hay algún mérito en lo que se refiere a indicaciones de ambos lados y es posible resumir el estado actual de los enfoques de T4G: 1. El uso de T4G es un enfoque viable para muchas de las diferentes áreas de aplicación. Junto con las herramientas de ingeniería de software asistida por computadora (CASE) y los generadores de código, T4G ofrece una solución fiable a muchos problemas del software.

2. Los datos recogidos en compañías que usan T4G parecen indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas y de tamaño medio, y que la cantidad de análisis y diseño para las aplicaciones pequeñas también se reduce.

3. 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 (actividades de ingeniería del software), para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la eliminación de la codificación.

Resumiendo, las técnicas de cuarta generación ya se han convertido en una parte importante del desarrollo de software. Cuando se combinan con enfoques de ensamblaje de componentes.

El paradigma T4G (Técnicas de Cuarta Generación) se puede convertir en el enfoque dominante

30

El Proceso TÉCNOLOGÍAS DE PROCESO Los modelos de procesos tratados en las secciones anteriores se deben adaptar para utilizarse por el equipo del proyecto del software.

Para conseguirlo, se han desarrollado herramientas de tecnología de procesos para ayudar a organizaciones de software a analizar los procesos actuales, organizar tareas de trabajo, controlar y supervisar el progreso y gestionar la calidad técnica. Las herramientas de tecnología de procesos La herramienta de permiten que una organización de software tecnología de proceso construya un modelo automatizado del marco también se puede utilizar de trabajo común de proceso, conjuntos de para coordinar el uso de otras herramientas de tareas y actividades de protección. El modelo, ingeniería del software presentado normalmente como una red, se asistida por computadora puede analizar para determinar el flujo de adecuada para una tarea trabajo típico y para examinar estructuras de trabajo en particular iterativas de procesos que pudieran llevar a un hacia el desarrollo del tiempo o coste de desarrollo reducidos. Una software. vez que se ha creado un proceso aceptable, se pueden utilizar otras herramientas de tecnología de procesos para asignar, supervisar e incluso controlar todas las tareas de ingeniería del software definidas como parte del modelo de proceso.

Cada uno de los miembros de un equipo de proyecto de software puede utilizar tales herramientas para desarrollar una lista de control de tareas de trabajo a realizarse, productos de trabajo a producirse, y actividades de garantía de calidad a conducirse.

PRODUCTO Y PROCESO Si el proceso es débil, el producto final va a sufrir indudablemente.

Aunque una dependencia obsesiva en el proceso también es peligrosa. En un breve ensayo, Margaret Davis comenta la dualidad producto y proceso: Cada diez años o cinco aproximadamente, la comunidad del software vuelve a definir «el problema» cambiando el foco de los aspectos de producto a los aspectos de proceso. Por consiguiente, se han abarcado lenguajes de programación estructurados (producto)

31

El Proceso seguidos por métodos de análisis estructurados (proceso) seguidos a su vez por encapsulación de datos (producto) y después por el énfasis actual en el Modelo Madurez de Capacidad de Desarrollo del software del Instituto de ingeniería de software (proceso).

Mientras que la tendencia natural de un péndulo es parar en medio de dos extremos, el enfoque de la comunidad del software cambia constantemente porque se aplica una fuerza nueva cuando halla el último movimiento. Estos movimientos son perjudiciales por sí mismos y en sí mismos porque confunden al desarrollador del software medio cambiando radicalmente lo que significa realizar el trabajo, que por sí mismo lo realiza bien. Los cambios tampoco resuelven «el problema», porque están condenados al fracaso siempre que el producto y el proceso se traten como si formasen una dicotomía en lugar de una dualidad.

En la comunidad científica hay un precedente que se adelanta a las nociones de dualidad cuando contradicciones en observaciones no se pueden explicar completamente con una teoría competitiva u otra.

La naturaleza dual de la luz, que parece ser una partícula y una onda al mismo tiempo, se ha aceptado desde los años veinte cuando Louis de Broglie lo propuso. Creo que las observaciones que se hacen sobre los mecanismos del software y su desarrollo demuestran una dualidad fundamental entre producto y proceso. Nunca se puede comprender el mecanismo completo, su contexto, uso, significado y valor si se observa sólo como un proceso o sólo como un producto.

Toda actividad humana puede ser un proceso, pero cada uno de nosotros obtiene el sentido de autoestima ante esas actividades que producen una representación o ejemplo que más de una persona puede utilizar o apreciar, una u otra vez, o en algún otro contexto no tenido en cuenta. Es decir, los sentimientos de satisfacción se obtienen por volver a utilizar nuestros productos por nosotros mismos o por otros.

Así pues, mientras que la asimilación rápida de los objetivos de reutilización en el desarrollo del software aumenta potencialmente la satisfacción que los desarrolladores obtienen de su trabajo, esto incrementa la urgencia de aceptar la dualidad producto y proceso.

Pensar en un mecanismo reutilizable como el único producto o el único proceso, bien oscurece el contexto y la forma de utilizarlo, o

32

El Proceso bien el hecho de que cada utilización elabora el producto que a su vez se utilizará como entrada en alguna otra actividad de desarrollo del software. Elegir un método sobre otro reduce enormemente las oportunidades de reutilización y de aquí que se pierda la oportunidad de aumentar la satisfacción ante el trabajo.

Las personas obtienen tanta satisfacción (o más) del proceso creativo que del producto final. Un artista disfruta con las pinceladas de la misma forma que disfruta del resultado enmarcado. Un escritor disfruta con la búsqueda de la metáfora adecuada al igual que con el libro final. Un profesional creativo del software debería también obtener tanta satisfacción de la programación como del producto final.

El trabajo de los profesionales del software cambiará en los próximos años. La dualidad de producto y proceso es un elemento importante para mantener ocupada a la gente creativa hasta que se finalice la transición de la programación a la ingeniería del software.

33

El Proceso BIBLIOGRAFÍA

 Ingeniería del software – un enfoque práctico. Roger S. Pressman

 http://www.google.com.pe/search?num=10&hl=es&site=imghp&tb m=isch&source=hp&biw=1366&bih=677&q=EL+PRODUCTO&oq= EL+PRODUCTO&gs_l=img.3..0l10.1430.3454.0.4143.11.9.0.2.2.0 .186.986.4j5.9.0...0.0...1ac.1.Fl7oAV4lIQw#hl=es&tbo=d&site=img hp&tbm=isch&sa=1&q=software+de+inteligencia+artificial&oq=soft ware+de+inteligencia+artificial&gs_l=img.3..0j0i24l5.134002.1409 50.6.141169.26.11.0.15.15.1.196.1908.0j11.11.0...0.0...1c.1.9iim2 AMAFfQ&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&fp=ba1326681ff2cb 8&bpcl=38897761&biw=1366&bih=634  http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software  http://www.ctic.uni.edu.pe/files/insoft01.pdf

Todos son links o enlaces a diferentes páginas web que se consultaron para el desarrollo de esta sesión de clases.

34