Introduccin a la Ingeniera de Software

Curso 2002

Principios de la Ingeniera de Software

Introducccin
En este documento se presentan algunos principios generales de importancia, que son centrales para desarrollar software en forma exitosa, y que tratan tanto del proceso de ingeniera de software como del producto final. El proceso adecuado ayudar a desarrollar el producto deseado, pero tam!i"n el producto deseado afectar la eleccin del proceso a utili#ar. $n pro!lema tradicional de la ingeniera de software es poner el "nfasis en el proceso o en el producto excluyendo al otro, sin em!argo, am!os son importantes. Estos principios son suficientemente generales para ser aplicados a lo largo del proceso de construccin y gestin del software, sin em!argo no son suficientes para guiar el desarrollo ya que descri!en propiedades desea!les de los procesos y productos de software% para aplicarlos es necesario contar con m"todos apropiados y t"cnicas especficas. &os m"todos son guas generales que go!iernan la e'ecucin de alguna acti(idad, presentan enfoques rigurosos, sistem ticos y disciplinados, por otro lado, las t"cnicas son m s mec nicas y se refieren a aspectos m s )t"cnicos* que los m"todos y tienen aplicacin restringida. $na metodologa es un con'unto de m"todos y t"cnicas cuyo propsito es promo(er cierto enfoque para la resolucin de un pro!lema mediante ese con'unto seleccionado. &as +erramientas son desarrolladas para apoyar la aplicacin de t"cnicas, m"todos y metodologas. &os principios son la !ase de todos los m"todos, t"cnicas, metodologas y +erramientas.

Rigor y formalidad:
En cualquier proceso creati(o existe la tendencia a seguir la inspiracin del momento de forma no estructurada, sin ser precisos% el desarrollo de software es de por s una acti(idad creati(a. ,or otro lado, el rigor es un complemento necesario de la creati(idad en todas las acti(idades de la ingeniera% -nicamente a tra("s de un enfoque riguroso podr n producirse productos m s confia!les, controlando sus costos e incrementando el grado de confian#a en los mismos. El rigor no tiene por qu" restringir la creati(idad, por el contrario, puede potenciar la creati(idad aumentando la confian#a del ingeniero en los resultados de la misma, una (e# que estos son anali#ados a la lu# de e(aluaciones rigurosas. ,arad'icamente el rigor es una cualidad intuiti(a que no puede ser definida en forma rigurosa, pero s pueden alcan#arse (arios ni(eles de rigurosidad siendo el m s alto la formalidad. &a formalidad es un requerimiento m s fuerte que el rigor. requiere que el proceso de software sea guiado y e(aluado por leyes matem ticas. /!(iamente formalidad implica rigor pero no a la in(ersa. se puede ser riguroso incluso informalmente. En todos los campos de la ingeniera el proceso de dise0o sigue una secuencia de pasos !ien definidos, esta!lecidos en forma precisa y posi!lemente pro!ados, siguiendo en cada paso alg-n m"todo o aplicando alguna t"cnica. Estos m"todos y t"cnicas estar n !asados en alguna com!inacin de resultados tericos deri(ados de un modelado formal de la realidad, a'ustes empricos que tienen en cuenta fenmenos no presentes en el modelo, y m"todos pr cticos de e(aluacin que dependen de la experiencia pasada 1)rules of t+um!*2. $n ingeniero de!e sa!er cmo y cu ndo ser formal si es requerido, entendiendo el ni(el de rigor y formalidad que de!e ser alcan#ado dependiendo de la dificultad conceptual de la tarea y su criticidad, lo que puede (ariar para diferentes partes del mismo sistema. ,or e'emplo, partes crticas pueden requerir una descripcin formal de las funciones esperadas y un enfoque formal para su e(aluacin mientras que partes est ndares o !ien entendidas requerir n enfoques m s simples. Esto aplica tam!i"n en el caso de la ingeniera de software, por e'emplo en el caso de la especificacin del software la cual puede esta!lecerse de forma rigurosa utili#ando lengua'e natural o tam!i"n puede darse formalmente mediante una descripcin formal en un lengua'e de sentencias lgicas. &a (enta'a de la formalidad so!re el rigor es que puede ser la !ase para la mecani#acin del proceso, por e'emplo si se quiere utili#ar la descripcin formal para crear el programa si "ste no existe, o para mostrar que el programa se corresponde con las especificaciones esta!lecidas si tanto el programa como las especificaciones existen.

Instituto de Computacin 3 4acultad de Ingeniera 3 $ni(ersidad de la 5ep-!lica

, gina 6 de 6

Introduccin a la Ingeniera de Software

Curso 2002

7radicionalmente es en la fase de codificacin donde se utili#a un enfoque formal ya que los programas son o!'etos formales. son escritos en un lengua'e cuya sintaxis y sem ntica est n completamente definidas. &os programas son descripciones formales que son manipuladas autom ticamente por los compiladores que c+equean su correctitud y las transforman en una forma equi(alente en otro lengua'e 1assem!ler o lengua'e de m quina2, todo lo cual es posi!le gracias a la utili#acin de la formalidad en la programacin. &a aplicacin del principio de rigor y formalidad tiene influencia !eneficiosa en la o!tencin de cualidades del software como la confia!ilidad, (erifica!ilidad, manteni!ilidad, reusa!ilidad, porta!ilidad, comprensi!ilidad e interopera!ilidad. ,or e'emplo, una documentacin del software rigurosa o incluso formal puede me'orar todas estas cualidades so!re una documentacin informal que puede ser am!igua, inconsistente e incompleta. El principio de rigor y formalidad tam!i"n se aplica al proceso de software% la documentacin rigurosa del proceso ayuda a que "ste sea reutili#ado en proyectos similares y tam!i"n ayuda a mantener un producto existente permitiendo que las modificaciones se realicen partiendo del ni(el intermedio apropiado, en lugar de +acerlo solamente so!re el cdigo final. Si el proceso de software est especificado en forma rigurosa, los gerentes podr n controlar su adecuacin y e(aluar su oportunidad para me'orar la producti(idad.

Separacin de intereses:
Este principio permite enfrentarse a los distintos aspectos indi(iduales de un pro!lema de forma de concentrarse en cada uno por separado. En el desarrollo de un producto de software de!en tomarse muc+as decisiones como las funciones que ser n ofrecidas, la confia!ilidad esperada, eficiencia de tiempo y espacio, relaciones con el am!iente como recursos de software o +ardware especial, interfaces de usuario, entre otras. /tras decisiones tienen que (er con el proceso de desarrollo como el am!iente de desarrollo, la organi#acin y estructura del equipo, la agenda, los procedimientos de control, las estrategias de dise0o, los mecanismos de recuperacin frente a errores, entre otras. 8 otras m s que tienen que (er con temas econmicos y financieros. 9uc+as de estas decisiones pueden no estar relacionadas entre s por lo que o!(iamente podr n ser tratadas en forma separada, pero muc+as otras estar n fuertemente relacionadas y ser pr cticamente imposi!le tener en cuenta todos los temas al mismo tiempo o por parte de las mismas personas. &a -nica forma de enfrentar la comple'idad de un proyecto es separar los distintos intereses. &a primer forma en la que se pueden separar los distintos intereses es seg-n el tiempo, lo que permite planificar las distintas acti(idades y eliminar el tra!a'o extra que implica cam!iar de una a otra en forma no restringida. Esta separacin seg-n el tiempo es la moti(acin que +ay tras el ciclo de (ida del software% un modelo racional de la secuencia de acti(idades que de!eran seguirse en la produccin de software. /tra forma de separacin de intereses es en t"rminos de las cualidades que de!eran tratarse por separado, por e'emplo podran enfrentarse separadamente la eficiencia y correctitud de un programa, primero dise0 ndolo cuidadosa y estructuradamente para garanti#ar su correctitud a priori y luego reestructurarlo para me'orar su eficiencia. /tro tipo importante de separacin de intereses permite que distintas (isiones del software sean anali#adas en forma separada, por e'emplo al anali#ar los requerimientos de una aplicacin podra ser de ayuda concentrarse por un lado en los datos que fluyen de una acti(idad a otra y por otro lado en el flu'o de control que go!ierna la sincroni#acin de dic+as acti(idades. :m!as ayudan a entender el sistema y ninguna de las dos pro(ee una (isin completa del mismo. /tra forma m s de aplicacin de este principio es enfrentar partes del mismo sistema en forma separada, esto es en t"rminos de tama0o. Este es un concepto fundamental que de!e dominarse para enfrentar la comple'idad de la produccin de software, y es tan importante que se trata como un punto aparte !a'o el principio de modularidad. Si !ien podran perderse algunas optimi#aciones potenciales al no tener en cuenta el pro!lema en su con'unto, la comple'idad glo!al puede resol(erse muc+o me'or concentr ndose en los distintos aspectos por separado, incluso si no fuera posi!le descomponer el pro!lema en los distintos aspectos en forma

Instituto de Computacin 3 4acultad de Ingeniera 3 $ni(ersidad de la 5ep-!lica

, gina 2 de 6

Introduccin a la Ingeniera de Software

Curso 2002

inmediata, es posi!le tomar inicialmente algunas decisiones de dise0o generales y luego aplicar el principio de separacin de intereses en forma efecti(a. Como o!ser(acin final, la separacin de intereses podra resultar en la separacin de responsa!ilidades al enfrentarse a los distintos aspectos a tener en cuenta, por lo tanto es la !ase para di(idir el tra!a'o en un pro!lema comple'o en asignaciones de tra!a'o especficas posi!lemente a personas distintas con distintas +a!ilidades.

Modularidad:
$n sistema comple'o puede di(idirse en pie#as m s simples llamadas mdulos, un sistema compuesto de mdulos es llamado modular. El principal !eneficio de la modularidad es que permite la aplicacin del principio de separacin de intereses en dos fases. al enfrentar los detalles de cada mdulo por separado ignorando detalles de los otros mdulos, y al enfrentar las caractersticas glo!ales de todos los mdulos y sus relaciones para integrarlos en un -nico sistema co+erente. Si estas fases son e'ecutadas en ese orden se dice que el sistema es dise0ado de a!a'o +acia arri!a 1!ottom up2, en el orden in(erso se dice que el sistema es dise0ado de arri!a +acia a!a'o 1top down2. El principio de modularidad tiene tres 1;2 o!'eti(os principales. capacidad de descomponer un sistema comple'o, capacidad de componerlo a partir de mdulos existentes y comprensin del sistema en pie#as 1o peda#os2. &a posi!ilidad de descomponer un sistema se !asa en di(idir en su!pro!lemas de forma top down el pro!lema original y luego aplicar el principio a cada su!pro!lema en forma recursi(a. Este procedimiento refle'a el !ien conocido principio de <i(ide y =encer s 1<i(ide > Conquer2. &a posi!ilidad de componer un sistema est !asada en o!tener el sistema final de forma !ottom up a partir de componentes elementales. Idealmente en la produccin de software se quisiera poder ensam!lar nue(as aplicaciones tomando mdulos de una !i!lioteca y com!in ndolos para formar el producto requerido% estos mdulos de!eran ser dise0ados con el o!'eti(o expreso de ser reusa!les. &a capacidad de comprender cada parte de un sistema en forma separada ayuda a la modifica!ilidad del sistema. <e!ido a la naturale#a e(oluti(a del software muc+as (eces se de!e (ol(er +acia atr s al tra!a'o pre(io y modificarlo. Si el sistema solo puede ser comprendido como un todo las modificaciones ser n difciles de aplicar y el resultado ser poco confia!le. Cuando se +ace necesario reparar el sistema, la modulari#acin apropiada ayuda a restringir la !-squeda de la fuente de error a componentes separados. ,ara alcan#ar estos o!'eti(os los mdulos en los que se di(ida el sistema de!en tener alta co+esin y !a'o acoplamiento. $n mdulo tiene alta co+esin si todos sus elementos est n fuertemente relacionados y son agrupados por una ra#n lgica, esto es todos cooperan para alcan#ar un o!'eti(o com-n que es la funcin del mdulo. &a co+esin es una propiedad interna de cada mdulo, por el contrario el acoplamiento caracteri#a las relaciones de un mdulo con otros. El acoplamiento mide la interdependencia de dos mdulos, por e'emplo si el mdulo : +ace una llamada a una rutina pro(ista por el mdulo ? o accede a una (aria!le declarada por el mdulo ?. Si dos mdulos dependen fuertemente uno del otro tienen un alto acoplamiento lo que los (uel(e difciles de anali#ar, comprender, modificar, testear o reusar en forma separada. Idealmente se quiere que los mdulos de un sistema tengan !a'o acoplamiento. $na estructura modular con alta co+esin y !a'o acoplamiento permite (er los mdulos como ca'as negras cuando se descri!e la estructura glo!al del sistema y luego encarar cada mdulo por separado cuando se anali#a o descri!e la funcionalidad del mdulo.

Abstraccin:
&a a!straccin es un proceso mediante el cual se identifican los aspectos rele(antes de un pro!lema ignorando los detalles% es un caso especial del principio de separacin de intereses en el cual se separan los aspectos importantes de los detalles de menor importancia. &o que se a!strae y lo que se considera

Instituto de Computacin 3 4acultad de Ingeniera 3 $ni(ersidad de la 5ep-!lica

, gina ; de 6

Introduccin a la Ingeniera de Software

Curso 2002

depender del propsito de la a!straccin, por lo que podr n +acerse distintas a!stracciones de la misma realidad cada una de las cuales pro(eer una (isin de la realidad que sir(e para un propsito especfico. ,or e'emplo, cuando los requerimientos de una nue(a aplicacin son anali#ados y especificados se construye un modelo de la aplicacin propuesta, el cual podr ser expresado en (arias formas dependiendo del grado requerido de rigor y formalidad. Sin importar cual sea el lengua'e elegido para expresar los requerimientos, lo que se pro(ee es un modelo que a!strae los detalles que se decidi que podan ser ignorados en forma segura. &os lengua'es de programacin tam!i"n son a!stracciones construidas so!re el +ardware que pro(een constructores -tiles y poderosos para escri!ir programas ignorando detalles como el n-mero de !its que se utili#an para representar n-meros o los mecanismos de direccionamiento, lo que permite concentrarse en el pro!lema a resol(er en lugar de la forma de instruir a la m quina para +acerlo. El principio de a!straccin es un principio importante que se aplica tanto a los productos de software como a los procesos. En este -ltimo caso, por e'emplo, al reali#ar la estimacin de costos para una nue(a aplicacin una forma posi!le es identificar algunos factores cla(es del nue(o sistema y extrapolar los (alores a partir de perfiles de costo de sistemas pre(ios similares. &os factores cla(es utili#ados para reali#ar el an lisis son a!stracciones del sistema.

Anticipacin al cambio:
El software sufre cam!ios constantemente, como se (io al tratar la manteni!ilidad del software estos cam!ios pueden surgir por la necesidad de eliminar errores que no fueron detectados antes de li!erar la aplicacin, o por la necesidad de apoyar la e(olucin de la aplicacin de!ido a nue(os requerimientos o cam!ios en los requerimientos existentes. &a +a!ilidad del software para e(olucionar no (iene sola sino que requiere esfuer#o especial para anticipar cmo y cu ndo pueden ocurrir estos cam!ios. Cuando se identifican posi!les cam!ios futuros, se de!e tener cuidado de proceder de forma que estos sean f ciles de aplicar, es importante aislar los posi!les cam!ios en porciones especficas del software de tal forma que est"n restringidos a esas partes. &a anticipacin al cam!io es posi!lemente el principio que m s distingue al software de otros tipos de produccin industrial. 9uc+as (eces una aplicacin de software es desarrollada mientras sus requerimientos a-n no est n completamente comprendidos, al ser li!erado y o!tener retroalimentacin del usuario de!e e(olucionar con nue(os requerimientos o cam!ios a los requerimientos ya existentes los cuales pueden tener distintos orgenes, por e'emplo de!ido a cam!ios en el am!iente de la organi#acin. ,or lo tanto este principio puede ser utili#ado para lograr la e(oluciona!ilidad del software y tam!i"n la reusa!ilidad de componentes, (iendo la reusa!ilidad como e(oluciona!ilidad de granularidad m s fina, a ni(el de componentes. &a aplicacin de este principio requiere que se disponga de +erramientas apropiadas para gestionar las (arias (ersiones y re(isiones del software en forma controlada. <e!e ser posi!le almacenar y recuperar documentacin, fuentes, e'ecuta!les, etc. de una !ase de datos que act-e como repositorio central de componentes reusa!les, y el acceso a la misma de!e estar controlado. $n sistema de software de!e mantenerse consistente, incluso cuando se aplican cam!ios a algunos de sus componentes. &a disciplina que estudia esta clase de pro!lemas es la @estin de Configuracin y se (er posteriormente. &a anticipacin al cam!io tam!i"n aplica al proceso de desarrollo de software, por e'emplo, en la gestin del proyecto los gerentes de!eran anticipar los efectos de una reduccin de personal, estimar los costos y dise0ar la estructura de la organi#acin que apoyar la e(olucin del software, y decidir cuando (ale la pena in(ertir tiempo y esfuer#o en la produccin de componentes reusa!les tanto como parte de un proyecto de desarrollo de software o como un esfuer#o de desarrollo paralelo.

Generalidad:
El principio de generalidad esta!lece que al tener que resol(er un pro!lema se de!e !uscar un pro!lema m s general que posi!lemente est" oculto tras el pro!lema original, puesto que puede suceder que el pro!lema general no sea muc+o m s comple'o 1a (eces puede ser incluso m s simple2 que el original y posi!lemente la solucin al pro!lema general tenga potencial de reuso, o exista en el mercado como

Instituto de Computacin 3 4acultad de Ingeniera 3 $ni(ersidad de la 5ep-!lica

, gina A de 6

Introduccin a la Ingeniera de Software

Curso 2002

producto offBt+eBs+elf, o se dise0e un mdulo que puede ser in(ocado por m s de un punto en la aplicacin en lugar de tener (arias soluciones especiali#adas. ,or otro lado, una solucin general posi!lemente sea m s costosa en t"rminos de rapide# de e'ecucin, requerimientos de memoria o tiempo de desarrollo, que una solucin especiali#ada al pro!lema original, por lo que de!e e(aluarse la generalidad respecto al costo y la eficiencia al momento de decidir qu" (ale m s la pena, una solucin general o una especiali#ada. &a generalidad es un principio fundamental si se tiene como o!'eti(o el desarrollo de +erramientas generales o paquetes para el mercado, ya que para ser exitosas de!er n cu!rir las necesidades de distintas personas. Estos productos de propsito general, offBt+eBs+elf como por e'empo los procesadores de texto, representan una tendencia general en el software% para cada rea especfica de aplicacin existen paquetes generales que pro(een soluciones est ndares a pro!lemas comunes. Esta tendencia es id"ntica a lo que ocurri en otras reas de la industria como por e'emplo, los autom(iles que en los inicios de la tecnologa automotri# era posi!le +acer autos de acuerdo a los requerimientos especficos de un cliente, pero a medida que el rea se fue industriali#ando solo podan encargarse a partir de un cat logo y actualmente no es posi!le pedir un dise0o de auto personal a menos que se est" dispuesto a pagar una enorme cantidad de dinero.

Incrementalidad:
&a incrementalidad caracteri#a un proceso que se desarrolla en forma de pasos, en incrementos, alcan#ando el o!'eti(o deseado mediante aproximaciones sucesi(as al mismo, donde cada aproximacin es alcan#ada a tra("s de un incremento de la pre(ia. $na forma de aplicar el principio de incrementalidad consiste en identificar su!con'untos tempranos de una aplicacin que sean -tiles de forma de o!tener retroalimentacin 1feed!acC2 temprana del cliente. Esto permite que la aplicacin e(olucione en forma controlada en los casos en que los requerimientos iniciales no est n esta!les o completamente entendidos. &a moti(acin de este principio es que muc+as (eces no es posi!le o!tener todos los requerimientos antes de comen#ar el desarrollo de una aplicacin sino que "stos (an emergiendo a partir de la experimentacin con la aplicacin o partes de "sta. ,or lo tanto, lo antes que se pueda contar con feed!acC del usuario so!re la utilidad de la aplicacin, m s f cil ser incorporar los cam!ios requeridos la producto. Este principio est ligado al principio de anticipacin al cam!io y es otro de los principios en los que se !asa la e(oluciona!ilidad. &a incrementalidad se aplica a muc+as de las cualidades del software (istas pre(iamente. Se puede por e'emplo, comen#ar con un n-cleo de la aplicacin que sea -til e ir agregando funcionalidades, tam!i"n se puede agregar performance en forma incremental si por e'emplo, la (ersin inicial enfati#a!a las interfaces de usuario y la confia!ilidad, luego sucesi(as li!eraciones ir n me'orando la eficiencia en tiempo y espacio. Cuando se construye una aplicacin en forma incremental, los pasos intermedios pueden ser prototipos del producto final, esto es solamente una aproximacin al mismo. /!(iamente un ciclo de (ida !asado en prototipos es !astante distinto al tradicional modelo en cascada, y est !asado en un modelo de desarrollo m s flexi!le e iterati(o. Estas diferencias tendr n efectos no solo en los aspectos t"cnicos sino tam!i"n en los organi#ati(os y de gestin. Como se menciona!a en el principio de anticipacin al cam!io, el desarrollo de software en forma e(oluti(a requiere tener especial cuidado en la gestin de documentacin, programas, datos de testeo, etc. que son desarrollados para las (arias (ersiones del software. Cada incremento significati(o de!e ser registrado, la documentacin de!e poder ser f cilmente recuperada, los cam!ios de!en aplicarse en forma ordenada, etc. Si lo anterior no se reali#a con cuidado, un intento de desarrollo e(oluti(o podra r pidamente transformarse en un desarrollo de software indisciplinado y perderse todas las (enta'as potenciales de la e(oluciona!ilidad.

Instituto de Computacin 3 4acultad de Ingeniera 3 $ni(ersidad de la 5ep-!lica

, gina D de 6

Introduccin a la Ingeniera de Software

Curso 2002

: partir de. 4undamentals of Software Engineering 3 Carlo @+e##i, 9e+di Ea#ayeri, <ino 9andrioli. ,renticeB Fall, Inc. 6GG6, edicin en ingl"s. IS?HB0B6;BI20A;2B2, Captulo ; 3 Software Engineering ,rinciples.

Instituto de Computacin 3 4acultad de Ingeniera 3 $ni(ersidad de la 5ep-!lica

, gina J de 6