Apuntes para INGENIERIA DE SOFTWARE I PRINCIPIOS DE INGENIERIA DE SOFTWARE

R. Contreras A. - M. A. Pinningho J. Ingenier a Civil Inform atica Segundo Semestre 2013

A continuaci on se discutir a algunos principios centrales relacionados al desarrollo exitoso de software. Estos principios tienen que ver tanto con el proceso de ingenier a de software, como con el producto nal. El proceso correcto ayudar a a obtener el producto correcto, pero este producto tambi en afectar a la elecci on del proceso a usar. Un problema tradicional en ingenier a de software ha sido el enfasis ya sea en el proceso o en el producto, con la exclusi on del otro. Ambos son importantes. Los principios que desarrollamos tienen un caracter lo sucientemente general como para ser aplicables al proceso de construcci on y administraci on. Sin embargo, estos principios no son sucientes para guiar el proceso de desarrollo de software. En realidad se trata de armaciones abstractas que describen propiedades deseables de los procesos y productos software. Pero, para aplicar principios, el ingeniero de software deber a estar equipado con m etodos y t ecnicas espec cas que ayuden a incorporar las propiedades deseadas en los procesos y productos. En principio, deber amos distinguir entre m etodos y t ecnicas. Los m etodos son gu as generales que gobiernan la ejecuci on de alguna actividad; son aproximaciones rigurosas, sistem aticas y disciplinadas. Las t ecnicas son algo m as mec anicas que los m etodos; a menudo tienen una aplicabilidad m as restringida. Sin embargo, en general, la diferencia entre las dos no es muy n tida, y por tal raz on es de uso com un intercambiar ambos t erminos.

Figura 1: Relaci on entre principios, t ecnicas, metodolog as y herramientas A veces, los m etodos y t ecnicas son encapsulados en conjunto para dar vida a una metodolog a. El prop osito de una metodolog a es promover una cierta aproximaci on en la soluci on de problemas, preseleccionando los m etodos y t ecnicas a usar. Las herramientas, a su vez, son desarrolladas para apoyar la aplicaci on de t ecnicas, m etodos y metodolog as. La Figura 1, graca los conceptos reci en tratados. Cada nivel en la Figura 1, est a basado en el (los) nivel (es) anterior (es), y est a m as sujeto a cambios debido al paso del tiempo. Es necesario insistir que nuestra preocupaci on con el software no apunta a aquellos desarrollos que son apenas experimentos a ejecutar unas pocas veces, normalmente por su propio desarrollador. Nos referimos a software cuyos usuarios saben poco o nada de computadores y software. O tal vez estamos interesados en software de apoyo a aplicaciones cr ticas, donde los efectos de los errores pueden ser hasta desastrosos. Por estas y otras razones, estamos preocupados con aplicaciones que deben ser conables. Tambi en podemos suponer que la aplicaci on es lo sucientemente grande y compleja de manera que se requiere un esfuerzo para descomponerla en partes manejables. Esto es particularmente cr tico cuando hablamos de aplicaciones a ser desarrolladas por un equipo, pero es tambi en verdad en el caso

de un solo ingeniero de software haciendo el trabajo. En todas estas circunstancias, que representan situaciones t picas en el desarrollo de software, conabilidad y evoluci on juegan un rol especial. Claro est a que si el software no es conable y no cumple las condiciones para evolucionar, la necesidad de ingenieros de software, principios y t ecnicas disminuye bastante. De aqu es que se puede armar que la elecci on de principios y t ecnicas est a determinada por las metas de calidad del software.

1.

Rigor y Formalidad

El desarrollo de software es una actividad creativa. Hay una tendencia inherente a toda actividad creativa de no ser exactos ni precisos, sino que, a seguir la inspiraci on del momento de una forma no estructurada. Por otra parte el Rigor es un complemento necesario a la creatividad en toda actividad de ingenier a: es s olo a trav es de la aproximaci on rigurosa que podremos producir productos m as conables, controlar sus costos, y aumentar nuestras aspiraciones respecto de su conabilidad. El Rigor no necesita restringir la creatividad. En lugar de eso, mejora la creatividad mejorando la conanza del ingeniero en los resultados creativos, una vez que ellos son cr ticamente analizados a la luz de una planicaci on rigurosa. Paradojalmente, el rigor es una cualidad intuitiva que no puede denirse rigurosamente. Tambi en es verdad que diversos grados de rigurosidad pueden ser alcanzados. El grado m as alto es lo que llamamos formalidad. As , la formalidad es un requerimiento m as restrictivo que el rigor, requiere que el proceso de software sea dirigido y evaluado por intermedio de leyes matem aticas. Por supuesto, la formalidad implica rigor, pero lo opuesto no es verdad: uno puede ser riguroso a un en una base informal. En todo campo de la ingenier a, el proceso de dise no transcurre como una secuencia de pasos bien denidos, precisamente establecidos y basados en argumentaciones s olidas. En cada paso, el ingeniero sigue alg un m etodo o aplica alguna t ecnica. Los m etodos y t ecnicas aplicados pueden estar basados en alguna combinaci on de resultados te oricos derivados por alg un modelamiento formal de la realidad, por ajustes emp ricos que toman en cuenta alg un fen omeno no considerado por el modelo, y reglas heur sticas que dependen de la experiencia fundamentalmente. La mezcla de estos factores resulta en una aproximaci on rigurosa y sistem atica la metodolog a

que puede ser f acilmente explicada y aplicada una y otra vez. No es necesario ser siempre formal durante el dise no, pero el ingeniero debe saber c omo y cu ando ser formal, si as se requiere. Por ejemplo, un ingeniero puede conar en la experiencia pasada y en heur sticas para dise nar un puente corto, destinado a ser usado temporalmente para conectar los dos lados de un riachuelo. Por otra parte, se podr a usar un modelo matem atico para vericar si el dise no es seguro, en caso que el puente sea un poco m as largo y se pretenda usar permanentemente. Incluso podr a ser necesario usar sosticados modelos matem aticos si el puente fuera considerablemente largo, o si fuera construido en un a rea s smica. En este u ltimo caso, el modelo considerar a, sin duda, factores que pueden perfectamente ser ignorados en los casos previos. Lo anterior muestra que el ingeniero debe ser capaz de entender el nivel de rigurosidad y formalidad que debe alcanzarse, dependiendo de la dicultad conceptual de la tarea y de su criticidad. Incluso estos niveles pueden variar entre partes de un mismo sistema. Por ejemplo, las partes cr ticas pueden requerir una descripci on formal de sus funciones y una aproximaci on formal a los supuestos hechos, mientras que aquellas partes estandarizadas y bien entendidas pueden requerir aproximaciones m as simples. La descripci on de lo que un programa hace, se puede hacer en lenguaje natural; y puede tambi en expresarse suministrando una descripci on formal, basada en un lenguaje l ogico. La ventaja de la formalidad sobre el rigor es que la formalidad puede llegar a ser la base para la mecanizaci on del proceso. Por ejemplo, uno puede esperar usar la descripci on del programa (v a asertivas por ejemplo) para crear el programa (en un lenguaje de programaci on), si el programa a un no existe, o para demostrar que el programa corresponde a la descripci on, si tanto el programa como la descripci on existen. Tradicionalmente, ha existido una sola fase en el desarrollo de software donde se usa una aproximaci on formal: en programaci on. De hecho, los programas son objetos formales: est an escritos en un lenguaje cuya sintaxis y sem antica se encuentran completamente denidas. Los programas son descripciones formales que pueden ser autom aticamente manipuladas por los compiladores: se verica su correcci on formal, se transforman en una forma equivalente en otro lenguaje (ensamblador o de m aquina), se editan, mejorando su apariencia; entre otras. Estas operaciones mec anicas, que son posibles por el hecho de usarse la formalidad en la programaci on, pueden 4

mejorar efectivamente la conabilidad y vericabilidad de productos software. El rigor y la formalidad tambi en tienen efectos ben ecos en la mantenibilidad, reusabilidad, portabilidad, comprensi on e interoperabilidad del software. Por ejemplo, una documentaci on rigurosa, o a un formal, puede mejorar todos los factores mencionados, en relaci on a una documentaci on informal, que es a menudo ambigua, inconsistente e incompleta. El rigor y la formalidad tambi en pueden aplicarse a procesos de software. La documentaci on rigurosa de un proceso software ayuda a reusar el proceso en otros proyectos similares. Bas andose en esta documentaci on, administradores pueden predecir los pasos a trav es de los cuales el nuevo proyecto evolucionar a, asignado los recursos apropiados a medida que se vayan necesitando, por ejemplo. De forma similar, la documentaci on rigurosa del proceso software puede ayudar a mantener un producto existente. Si los diferentes pasos (etapas) a trav es de los cuales evoluciona el proyecto est an documentados, uno puede modicar un producto existente partiendo desde el nivel intermedio apropiado, no necesariamente desde el nivel del c odigo nal. Finalmente debemos decir que, si el proceso software es especicado rigurosamente, los administradores pueden monitorearlo en forma precisa, para garantizar el cumplimiento de los puntos de control y mejorar la productividad.

2.

Separaci on de Intereses

La separaci on de intereses, nos permite involucrarnos con diferentes aspectos individuales de un problema, de forma que podamos concentrarnos en ellos separadamente. Es una pr actica de sentido com un que seguimos diariamente para manejar las dicultades que vamos encontrando. Por lo anterior, esta pr actica tambi en puede (debe) ser aplicada al caso del desarrollo de software, de forma de poder administrar su complejidad. La u nica manera de administrar la complejidad de un proyecto es separar los diferentes aspectos. Lo primero que se debe hacer es aislar los factores que est an relacionados de una manera m as d ebil. Adem as, cuando los diversos factores son tomados en consideraci on de forma separada, no se debe

considerar en detalle los factores relacionados con el aspecto bajo an alisis sino s olo en la medida en que lo impactan. Hay varias formas de separar los intereses. Primero, uno puede hacer la separaci on teniendo en consideraci on el tiempo. Una separaci on basada en el tiempo, permite una planicaci on precisa de actividades eliminando el overhead que tendr a lugar al ir saltando de una actividad a otra de una forma no restringida (esta es la motivaci on base para el ciclo de vida del software). Otro tipo de separaci on es el que se da en t erminos de calidades que deber an ser tratadas separadamente. Por ejemplo, en el caso del software, podr amos querer manejar separadamente la eciencia y la correcci on de un programa. Podr amos decidir dise nar software de una manera cuidadosa y estructurada tal que su correcci on (se espera) est e garantizada a priori, y luego reestructurar parcialmente el programa para mejorar su eciencia. Otro tipo de separaci on tiene que ver con las vistas (views) del software, a ser analizadas separadamente. Por ejemplo, al analizar los requerimientos de una aplicaci on, puede ser u til concentrarse separadamente en los datos que uyen de una actividad a otra, y en el ujo del control que gobierna la manera en que actividades diferentes son sincronizadas. La separaci on as vista, entonces, puede implicar una separaci on de responsabilidades para tratar aspectos separados. Este principio es la base para la divisi on del trabajo en un problema complejo en asignaciones espec cas de trabajo, posiblemente para personas diferentes con diferentes habilidades. Una u ltima separaci on nos permite tratar con partes de un mismo sistema separadamente; aqu la separaci on se da en t erminos de tama no. Este es un concepto fundamental que es necesario conocer para dominar la complejidad de la producci on de software. Es, de hecho, tan importante, que bien merece un la dedicaci on de un apartado especial, que se tocar a bajo el t tulo de Modularidad.

3.

Modularidad

Un sistema complejo puede ser dividido en partes m as simples, llamadas m odulos. Un sistema que est a compuesto por m odulos se llama modular. El principal benecio de la modularidad, es que permite que la separaci on de contextos se pueda aplicar en dos fases: cuando se relaciona con los detalles de cada m odulo aisladamente (e ignorando detalles de otros m odulos), y cuando se relaciona con las caracter sticas globales de todos los m odulos y sus relaciones con la nalidad de integrarlos en un sistema coherente. Si las dos fases son ejecutada en el orden mencionado, decimos que el dise no se llama bottom-up; el caso inverso caracteriza al dise no top-down. La modularidad es una caracter stica importante de la mayor a de los procesos y productos de la ingenier a. Por ejemplo, en la industria automotriz, la construcci on de autos de hace ensamblando bloques que han sido construidos separadamente. A un m as, algunas partes son reusadas de un modelo a otro, tal vez despu es de cambios menores. La mayor a de los procesos industriales son esencialmente modulares, compuestos de paquetes que se combinan de maneras simples (secuencialmente o en paralelo) para alcanzar el resultado deseado. La modularidad no s olo es un principio deseable de dise no, sino que abarca la totalidad del proceso de producci on de software. En particular, hay tres objetivos que la modularidad trata de alcanzar en la pr actica: capacidad de descomposici on de un sistema complejo; composici on de un sistema a partir de componentes existentes y; comprensi on del sistema, mir andolo en partes. La descomponibilidad de un sistema se basa en la divisi on del problema original top down en subproblemas, y luego en aplicar la descomposici on a cada subproblema recursivamente. Esto reeja la bien conocida frase divide et impera (dividir y conquistar), que describe la antigua losof a seguida por los romanos para conquistar otras naciones: dividirlas, aislarlas y luego conquistarlas individualmente. La componibilidad de un sistema se basa en partir desde los componentes elementales hasta llegar al sistema terminado. Por ejemplo, sistemas de software tales como sistemas operativos. Los autos son otro ejemplo obvio de un sistema construido por ensamble de partes. Cuando uno de los componentes no funciona, simplemente se puede reemplazar por uno en buen estado de operaci on. 7

Idealmente, en la producci on de software, deber amos ser capaces de ensamblar nuevas aplicaciones tomando m odulos desde una biblioteca y combin andolos para formar el producto solicitado. Tales m odulos deber an ser creados teniendo en mente que van a ser m odulos reutilizables. Usando m odulos reutilizables, se pueden acelerar tanto el proceso inicial de construcci on del sistema como su sintonizaci on na; por ejemplo, deber a ser posible reemplazar un componente por otro que realice la misma funci on pero que tenga diferentes requerimientos de recursos computacionales. La capacidad de entender cada parte del sistema separadamente, ayuda a su modicaci on. Cuando surge la necesidad de hacer reparaciones, una modularizaci on adecuada ayuda a connar la b usqueda por la fuente de mal funcionamiento a un solo componente. Para alcanzar descomponibilidad, componibilidad, y capacidad de comprensi on del sistema, los m odulos deben tener dos caracter sticas importantes: alta cohesi on y bajo acoplamiento. Un m odulo tiene alta cohesi on si todos sus elementos est an fuertemente relacionados. Los elementos en un m odulo deben agruparse por alguna raz on l ogica, no por pura casualidad, as cooperan a alcanzar un objetivo com un, la funci on del m odulo. La cohesi on de un m odulo es una propiedad interna. El acoplamiento caracteriza la relaci on de un m odulo con otros m odulos. El acoplamiento mide la interdependencia de dos m odulos. Si dos m odulos dependen fuertemente uno del otro, se habla de un alto acoplamiento. Idealmente interesa que los m odulos en un sistema tengan un bajo acoplamiento, ya que los m odulos fuertemente acoplados son dif ciles de analizar, entender, modicar, testear o reusar separadamente. La Figura 2 muestra una visi on gr aca de la cohesi on y el acoplamiento. Un buen ejemplo de un sistema con alta cohesi on y bajo acoplamiento es el subsistema el ectrico de una casa. Esto porque est a constituido de un conjunto de aplicaciones con funciones claramente denidas e interconectadas por simples alambres, el sistema tiene bajo acoplamiento. Ya que cada componente interno de una aplicaci on est a ah para proveer exactamente un servicio (lo que se supone la aplicaci on realiza), el sistema tiene una alta cohesi on. 8

Figura 2: Descripci on gr aca de cohesi on y acoplamiento. a) Estructura fuertemente acoplada. b) Estructura con alta cohesi on y bajo acoplamiento

Las estructuras modulares con alta cohesi on y bajo acoplamiento nos permiten ver los m odulos como cajas negras cuando debemos describir la estructura total, y luego, cuando es analizada o descrita la funcionalidad de cada m odulo, tratarlos separadamente.

4.

Abstracci on

Abstracci on es un proceso mediante el cual identicamos los aspectos importantes de un fen omeno e ignoramos sus detalles. Lo que debemos considerar importante o detalle depende del prop osito de la abstracci on. Por ejemplo, consideremos un reloj de cuarzo. Una abstracci on u til para su due no es una descripci on del efecto de presionar sus diferentes botones. Una abstracci on u til para una persona encargada de realizar la mantenci on de este tipo de relojes, es la descripci on y operaci on de la tapa que se puede remover para cambiar la bater a. As , puede haber muchas abstracciones diferentes para una misma realidad, cada una suministrando una visi on de la realidad y sirviendo a un prop osito espec co. La abstracci on es una herramienta poderosa utilizada por ingenieros de todas las disciplinas para manejar la complejidad. Por ejemplo, la representaci on de un circuito el ectrico en t erminos de resistencias, condensadores, etc., cada uno caracterizado por un modelo en t erminos de ecuaciones, es una abstracci on idealizada de un dispositivo. Por una parte, las ecuaciones son un modelo simplicado que aproxima el comportamiento de los compo-

nentes reales; por otra parte, el modelo que construimos a menudo ignora detalles tales como el hecho de que no hay conectores puros entre componentes y que estos componentes tambi en podr an ser modelados en t erminos de resistencias, condensadores, bobinas, etc. Ambos hechos pueden ser ignorados por el dise nador ya que los efectos que ellos describen son despreciables en t erminos de los resultados que se desea observar. Este ejemplo ilustra una idea general importante: los modelos que construimos de los fen omenos tales como las ecuaciones para describir dispositivos son una abstracci on de la realidad, ignorando ciertos hechos y concentr andonos en otros que son verdaderamente relevantes. Lo mismo es v alido para modelos analizados y construidos por ingenieros de software. Por ejemplo, cuando se debe analizar y especicar los requerimientos de una nueva aplicaci on, los ingenieros de software construyen un modelo de la aplicaci on propuesta. Este modelo puede ser expresado de diferentes maneras dependiendo del grado de rigor y formalidad. No importa el lenguaje que usemos para expresar los requerimientos, puede ser lenguaje natural o lenguaje formal de f ormulas matem aticas, lo que tendremos es un modelo que hace abstracci on de un cierto n umero de detalles que decidimos ignorar, sin afectar la correcci on del modelo. Los lenguajes de programaci on, por ejemplo, son abstracciones construidas sobre el hardware: nos suministran una forma u til y poderosa de construcciones tales que podemos escribir programas (la mayor a) sin que tengamos que preocuparnos de detalles tales como el n umero de bits usados para representar n umeros o los mecanismos de direccionamiento. Esto nos ayuda a concentrarnos en el problema a resolver en vez de preocuparnos con la manera en que debemos instruir a la m aquina sobre c omo resolverlo. Los programas que escribimos son tambi en abstracciones. Por ejemplo, una planilla de pagos, computarizada, es una abstracci on sobre el procedimiento manual que la primera reemplaza: suministra la esencia del procedimiento manual, no sus detalles exactos. La abstracci on es un principio importante que se aplica tanto a productos software como a procesos. Por ejemplo, los comentarios que aparecen en el encabezado de un procedimiento son una abstracci on que describe el efecto del procedimiento. Cuando la documentaci on del programa es analizada, se supone que tales comentarios suministran toda la informaci on que es necesaria para entender las otras partes del programa que usan ese pro10

cedimiento. Como ejemplo del uso de abstracciones en procesos software, consideremos el caso de estimaci on de costos para una nueva aplicaci on. Una manera posible de estimar costos consiste en identicar algunos factores clave del nuevo sistema y hacer una extrapolaci on desde los perles de costo de sistemas similares previos. Los factores claves usados para realizar el an alisis son abstracciones del sistema.

5.

Anticipaci on al cambio

El software cambia constantemente. Los cambios se deben tanto a la necesidad de reparar el software eliminando errores que no fueron detectados antes como a la necesidad de apoyar la evoluci on de la aplicaci on a medida que aparecen requerimientos nuevos o cambian los requerimientos antiguos. Esta es una de las razones por las que se identica la mantenibilidad como una de las mayores cualidades de un software. La capacidad de evoluci on del software no es gratuita, ya que se requiere un esfuerzo especial para predecir c omo y cu ando ocurrir an los cambios. Cuando los cambios son identicados, se debe tener especial cuidado para proceder de manera que nuevos cambios futuros sean f aciles (o al menos no tan dif ciles) de aplicar. La anticipaci on al cambio es algo que distingue al software de la mayor a de los otros tipos de productos industriales. En muchos casos, se desarrolla una aplicaci on de software mientras sus requerimientos est an todav a por entenderse. Luego, despu es de haber sido puesto en marcha, con base en la realimentaci on obtenida del usuario, la aplicaci on debe evolucionar. Adem as, las aplicaciones a menudo est an embutidas en un ambiente, tal como una estructura organizacional; y esto genera nuevos requerimientos, posiblemente, que antes ni se sospechaban. La reusabilidad es otra cualidad del software fuertemente afectada por la anticipaci on al cambio. Un componente es reusable si se puede emplear directamente para generar un nuevo producto. O, en forma m as realista, si s olo requiere peque nos cambios para ser reutilizado. As , la reusabilidad puede verse como una capacidad de evoluci on de bajo nivel, i.e., capacidad de evolucionar a nivel de componente. Si podemos anticipar los cambios de

11

contexto en que el componente software puede estar considerado, podemos dise nar el componente de modo que los cambios puedan realizarse con cierta facilidad. La anticipaci on al cambio requiere que est en disponibles las herramientas para administrar las diferentes versiones y revisiones del software de una manera controlada. Debe ser posible almacenar y recuperar documentaci on, m odulos fuente, m odulos objeto, etc., desde una base de datos que act ue como una bodega central de componentes reusables. La anticipaci on al cambio tambi en afecta al proceso de administraci on de software. Por ejemplo, los administradores deber an ser capaces de anticipar el efecto de rotaci on de personal. Tambi en es importante, cuando se dise na el ciclo de vida de una aplicaci on, tener en cuenta el mantenimiento. Dependiendo de los cambios anticipados, los administradores deben estimar los costos y dise nar la estructura organizacional que apoye la evoluci on del software. Adem as, los administradores deber an ser capaces de decidir cuando es recomendable invertir tiempo y esfuerzo en la producci on de elementos reusables, ya sea como un producto dentro de un desarrollo de software particular, o como un esfuerzo de desarrollo paralelo.

6.

Generalidad
El principio de generalidad puede ser establecido de la siguiente manera:

Cada vez que se le pide a uno resolver un problema, se debe tratar de enfocar en el descubrimiento de un problema m as general que puede estar oculto detr as del problema propuesto. Puede suceder que el problema generalizado no sea m as complejo (incluso puede ser m as simple) que el problema original. De forma m as general, la soluci on a un problema generalizado tiene m as potencial para poder ser reutilizada. Incluso puede ocurrir que ya est e dada por una especie de paquete preconstruido. Tambi en puede ocurrir que a trav es de la generalizaci on de un problema uno termine dise nando un m odulo que es llamado en m as de un punto en la aplicaci on, en vez de tener varias soluciones especializadas. Por otra parte, una soluci on generalizada puede ser m as costosa, en t erminos de velocidad de ejecuci on, requerimientos de memoria o tiempo de desarrollo. As , es necesario evaluar las contrapartes de la generalidad

12

con respecto a costo y eciencia, para decidir si es mejor resolver el problema generalizado o el problema particular. Por ejemplo, sup ongase que se solicita mezclar dos archivos secuenciales en un archivo secuencial. Basado en los requerimientos, se sabe que los dos archivos originales no contienen registros con claves id enticas. Claramente, si se generaliza la soluci on para aceptar archivos de entrada que puedan contener diferentes elementos con la misma clave, se obtiene un programa que tiene un mayor potencial de reusabilidad. Como otro ejemplo, supongamos que se nos pide dise nar una aplicaci on para manejar un peque no libro de recetas. Supongamos que las recetas tienen un encabezado, que contiene informaci on tal como el nombre, una lista de ingredientes e informaci on de cocci on, y una parte textual que describe como aplicar las recetas. Adem as de almacenar las recetas en una biblioteca, debe ser posible hacer una b usqueda sosticada de recetas basada en ingredientes disponibles, m aximo de calor as, etc. En vez de dise nar un nuevo conjunto de opciones, estas b usquedas deben ser vistas como un caso especial de un conjunto m as general de facilidades de procesamiento de textos. Antes de comenzar con el dise no del conjunto especializado de rutinas, el dise nador deber a considerar si la adopci on de una herramienta generalizada de procesamiento de textos pudiera ser m as apropiada. Sin duda, la herramienta generalizada es m as conable que los programas especializados a ser dise nados, y probablemente se podr a acomodar cambios en los requerimientos o incluso nuevos requerimientos. En el lado negativo, sin embargo, puede haber un costo de adquisici on, y posiblemente overhead en el uso de la herramienta generalizada. La generalidad es un principio fundamental si lo que se desea es desarrollar herramientas o paquetes software para uso amplio por parte del mercado. El exito de herramientas como planillas electr onicas, bases de datos y procesadores de texto, se basa en que son lo sucientemente generales como para cubrir las necesidades pr acticas de la mayor a de las personas. As , en vez de adecuar soluciones espec cas para cada persona, es m as econ omico elegir de entre aquellos productos ya disponibles en el mercado. Los productos de prop osito general representan una tendencia bastante generalizada en software. Para un area espec ca de aplicaci on, los paquetes generales que proveen soluciones estandarizadas a problemas comunes, est an aumentando en t erminos de disponibilidad. Si el problema puntual puede ser reformulado como una instancia de un problema resuelto por un 13

paquete general, puede ser conveniente adoptar el paquete en vez de implementar una soluci on especializada. Esta tendencia general es id entica a la ocurrida en otras ramas industriales. Por ejemplo, en los primeros d as de la tecnolog a del autom ovil, era posible construir autos de acuerdo a requerimientos espec cos de un cliente. A medida que el campo se industrializ o, los clientes pudieron comenzar a escoger s olo desde un reducido n umero de modelos (desde un cat alogo normalmente), que corresponden a soluciones pre-empaquetadas, provistas por el fabricante. Hoy, no es posible solicitar un dise no particular de autom ovil para un cliente, a menos que este est e dispuesto a pagar grandes cantidades de dinero.

7.

Incrementalidad

La incrementalidad caracteriza a un proceso que ocurre paso-a-paso, en incrementos. La meta buscada es alcanzada por aproximaciones sucesivas a ella, cada aproximaci on es alcanzada por un incremento en la aproximaci on anterior. La incrementalidad se aplica a muchas actividades de la ingenier a. Si se aplica al software, signica que la aplicaci on es producida como resultado de un proceso evolutivo. Una forma de aplicar el principio de incrementalidad, consiste en identicar subconjuntos primarios u tiles de una aplicaci on que puede ser desarrollada y entregada a eventuales clientes de forma de recibir una realimentaci on temprana. Esto permite que la aplicaci on pueda evolucionar en forma controlada en aquellos casos en que los requerimientos iniciales no est an estabilizados o no est an completamente comprendidos. La motivaci on para la incrementalidad es que en la mayor a de los casos pr acticos no hay forma de tener todos los requerimientos corregidos antes del desarrollo de la aplicaci on. Muchas veces los requerimientos emergen a medida que la aplicaci on o partes de ella est a disponible para experimentaci on pr actica. En consecuencia, mientras m as temprano podamos recibir la rea-limentaci on del cliente respecto a la utilidad de la aplicaci on, m as f acil ser a incorporar los cambios requeridos en el producto.

14

Cuando una aplicaci on es desarrollada incrementalmente, las etapas intermedias pueden constituir prototipos del producto nal; o sea, son una aproximaci on de este. La idea de prototipado r apido es a menudo entendida como una manera de desarrollo progresivo de una aplicaci on, mano a mano con el entendimiento de los requerimientos. Obviamente un ciclo de vida de software basado en prototipado, es bastante diferente del descrito de forma t pica por el modelo de cascada, donde primero se completa el an alisis de requerimientos y la especicaci on, y entonces se comienza a desarrollar la aplicaci on. La forma incremental permite utilizar un modelo de desarrollo iterativo m as exible. Esta diferencia tiene efecto no s olo en los aspectos t ecnicos de los proyectos, sino tambi en sobre aspectos administrativos y organizacionales. Como es de esperar, el desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulaci on de documentos, programas, datos de test, etc., que se desarrolla para diferentes versiones del software. Cada paso incremental signicativo (habr a muchos que luego se desprecian) debe ser registrado; la documentaci on debe ser recuperada con facilidad; los cambios deben ser efectuados de una manera controlada, y as sucesivamente. Si esto no es hecho cuidadosamente, cualquier intento de desarrollar software con este estilo evolutivo se puede transformar r apidamente en una forma ca otica de desarrollar software, y todas las ventajas potenciales del desarrollo evolutivo simplemente se perder an.

Referencias
[1] Ghezzi, C., Jazayeri, M., Mandrioli, D. Fundamentals of Software Engineering. Prentice Hall, 2nd Edition, 2003. [2] Booch, G. Software Engineering with Ada. The Benjamin/Cummings Publishing Co., 1987.

15