-:-~:--.-: ..' ... -~-:......... ~:.:.

-~,
"":;~=?==?:::.::::::==~======-
:.....:._ ...,.:.~: . ....... ~-- - --~-- ------...:..:..:. -=-
--. :-:~Jjfl~::~J:~!tJ~:~~~!1~~fr~~I!i~\~~~~~Jfth~~J~~;:1J~~~~it~~j,;~;~~i~~j~iij~;~i~:-~
Ehl~'b ciJt SO~ -k A-'2k 6N ;:_... !Vl::."'LtG '' c<..e.. L c.,. l:i <::.:. .,:, <::--i - '":' -<~,...,..4
. ' . . . :- 1
. . . l
Cap_fulol :. : .. :: 1 f
. lng~nicrb del soft-ware: Jn:rotluccin. ' \' 1 '
.
~
' . ; i\
..
!f

La_ ingeniera del'software es el campo de la c1enc1a de la computaGin que se ocupa de la '. '. : 1
- consl.r]Jccin de sist~mas de software que son tan largo? o corilplejos, que deben ser abordados por .
uno va.-rios equipos'.-de ingenieros. Generalmet1te existen, mltiples versiones de estos si~temas y.
- se usa11 durante varios allos. Dll!ante su tiempo de Vi~a:, sufren muchos cambios; ya sea )ara ...c:-L - ,.-:-"~ . f
c~rregir defectos, 'eliminsr 'viejas caractersticas e; a_qaptarsc para coner'en un nuevo ambiente: -)~ --~~~;:~::~(:\_
:. ' Parnas (1987), defirii la inge11;iera deL software cdr:i.o la "construccin de un software .:.. << : :-~~;~
mull versin realizada por rn~ltiple~ personas". Esta defi?.icia captura la. escencia. de la ingenieria :t._. ;~ _,"~);~i:: .f,
del software y remarca sus :hferencms con la prof,TTanmci'I5n. Un programador escnbe un programa - . : '>!
completo, mientras que un ingeniero del software escribe componentes de software que se' .: r
combinarn con otros componentes escritos por otros ingenieros para construir un sistema. El
componente que cada uno escribe puede ser mo.dificado por los otros. y puede ser usado para . .., .-
construir otras version~s. del sistema ~? cuand~ y ha p~sado un tiemp? des~le .hdtalizacin del ,,.,__ '.<;~tt::-~)!-;;;- 1

fProyec~o. La programa.ct~r~ ~s. un a?lVtdad personal, m1entms qt!e la mgeruena del software efl _:} ; -;;:;:: l
escenCiaJmente una aCtlVldad. Ot: equtpO. . . : . , ~J-- ,.".:_.:(:~;< i ,_
' El trmino "ingeniera del software" fu crear,lo 1!1 fines de la dcada del 60 cuando~!:::'::;_.. ' . f
comprendi que todas las reglas aprendidas hcerca de ins maneras correctas Je programar, ~fi-:
ayudaban a construir mejores sistemas. Si bien en el campe> de la programacin se haban hecho
. tremendos avances - a Lrri~s dd estudio sistcr;lico de algoritmos y eslrU~'~uras de datos, y de !a
invencin de. -la "programasin es~ructi.1raua"- e;<istbn an grandes difcuitades para construir
{ " grandes sistemas. Las tc!iiits usachts por un fsico pt;:i (e~o'lver.una ecuacin 'c::lifcretlciaLp,.<J.-a:-h!H _.,
.\
) 1 expcrimc~lto, no se udec..:aban a las de. un progratnador que estaba desarrollando ~sisl~m~
) operativo\) incluso un sim;;le sistema de contro: de.in,;elltario. Lo qu se necditaba en estos c.asos
era la propuesta clsica de la ingenier-a : ddi;1ir claramente el prob!emrr que se est tralandode
;
. ',
resolver, y desarrollar las hcrramiemas standard y las tcnicas para hacerlo .
,., . Sin duda, ]3 ingen!~:~ra del srA(w<tre ha hecho progresos desd:; los '60: Se hatt cstanariz.ado
' 1
tcnicas para usar en ese c.:mpo. Pero todava est muy lejos de alcanzar el slRlus.. de un discipliim
de ingeniera clsica. "tocbva qued3n muchas reas que se enseiian y practican sobre. las bases de
tcnicas informaks. Ni siquiera hay rntoc!os generales aceptados para especificar Jo que n
sistema debera hacer. Cuando se diseii utl sistema en ingcaieru elctrica-; lal como. un
ampli!cador, se lo puede: cspcci[c.:ar con exactitd. El usuatio y el ingeniero definen y entienden
con cln.ridad todos loB nrm.;tf')3 y niv;;les d::: tolerancia. En ingeniera del soflware, recin
i ,,~1' estamos comenzando a cid:nir por un lado, cules deberan ser los parmetros de un sistema de
software, y por el otro- i.uta tare;:; mL~ciJo m<\s compleja- cmo espccfcarJs.
Adl:ms, en h:.s discipLnas <.le la ii1genieria Ci~sica, el ingenir~ro est equipado con las
herramientas -y la nw.Jurez matemtica para especificar las propiedades del producto
independienten1.ente de rtqu!ls del d.isefi.o. Por ejcn1pl6) tUl ingeniero electricista- se basa en ! -
ccuciones m::>.ternticas )<lia verifir~ar' que el discfo no vioic .los requerimientos de energa. E;1
ingc:nier!a del softwal"L:nJ :>e lmn dcsarr~lado tale:> herramientas matemticas. I~llpico ingeniero
del software se basa muc~Jo m{ls en la e;o;pctiencia y el criterio que en !cnias ~nutcmlicas. Si beli
la cxpcri ticin. y el crh.::.r;.. _, son !1:-!.e<:so.nos en !a prctica de ia ingt~nkra, (lfnbin son cscenc.ialcs
las herramientas ele ;mL;is formr.!.
El enfoque de e~ le Ebro, es que la_ 11geniera del software debe ser praclicada t;:omo una
uisci pliua ele ingeniera. Nuestra pro~uesLa ,es prc.sentar ciertos principios, que creemos, son
csccnciale5 para la consl,,_ccin de "un :;onvv<ir~ muLi\:ersin realiz:1do por mltip1es personas".
e /

~ )/
/ .
1

... -- --. --- ............. - ..... - --. - . . -

.. -- ---. - . - . ---- .. - ._ .... : .' -~--- --- -- _..,.... . :..
_ ~--.--:-- ..
': : ,,, ~
 ,~~~~~~.li:ibq~"fh:f~~~'l,:E;tci;~~~~;t;;::c~\A~i:~d::.'i.iG:t~;;,<,",,;~,;,:'-'"~~2i:kf;~~-~i',;;;i: ..:2_~~:..;,;i''-
(:.\.-): >: . . . .: . . , . . . : . ; . '. . : . . . :
:~ . ::;,Pensamos que tales principios son mucho ms importantes que cualquier notacin o _metodologa. . .
_:-:_ :paraconstruir .. software. Estos principios capacitarn ar ingeniero del software para evaluar '':/' ' : !--.
diferentes metodologas. y z.plicarias en el momento apropiado. El captulo 3 presenta los ,.. <,-
prifncipios; el resto del libro ejemplifica su aplicacin a distintos de la del . . ; :_.; problt~mas ingenie~ia ::~,:. :.
so tware. -
En este. captulo, r~visamos la evolucin de la ingeniera de!' software y su relacin con . ''
otras disciplinas .. La meta es poder ver la ingeniera del software desde distintas. perspectivas.
. . . . . ;

1.1 El p1llH~l~e la ingeni.crfa dd software en el diseo de sstcmas. ,' 1 ~

.

Un sistema generalmente forma parte de un sistema ms grande. La actividad de la ingeniera del .,.
software es, en co~ecuencia, parte de una act.lvidad de diseo mucho ms grande, ~n l cual los
n!qu~rimiento~ del software estn balanceados junto con los requerimientos de las otras parles del
sisiema que ;se est diseflando. Por ejemplo: un siste1i1a de comunicaciones telfonicas est
fonnado por computadora,s, . lneas telefnicas, cabl~s, aparatos telefnicos y. muchos otros
apar~tbs tale~ . como satli:es, tc.; y finalmente el software que controla parte ele esos ...
componentes. Se espera pus, que ia combinacin de todos esos elementos, curnpl~ con. los
requerimientos de la totalidad del sistema. _
_ Requerimientos tales como "el sistema no debe permenecer inactivo ms de un-segundo en t.
20 aos" o "cuando el ustnrio levanta el tubo, deber escuchar un tono cada medio segundo" . f.
pueden satisfacerse mediante la combinacin de hardware, software y artefactos especiales .. La, -:; t ~ :, . ,: : _,~\:; ~:
decisin sobre cmo se llega a cumplir con los requer:rnientos de la mejor munera se puede tomar.
lL,Iego de haber- considerado muc:hs posibles combinaciones. Otros ejemplos que muestrrin la . ; :. :
\ecesidad- cfe'ver al~oft~var:~,:.como . r;;:l componente.de otros sistemas mayores son por ejemplo los . c.
7

. sistemas de m o ni toreo ele l.lllU plantR de energa elctrica, sistemas bancarios, "sistemas pata In . .. t.
administracin de hospitale~;, etc. . f
La prctica de la ingeniera del software de manera correcta, exige dar una mirada ms L -

amplia sobre problema general de la i11geniera de sistemas. Requiere que el ingeniero del sofL~:vare ....
intervenga en el momento :~n que se stn desari.-ollamlo )os requerimientos inicial_es del sistema:
completo. El ingeniero de'Je intentar comprender. ei rea de aplicacin ms que. entender las
interfases que debe reunir el softvvare. Por ejemplo, si el sistema apunta a usuurios que se , .....
manejarn por medio de u11 sistema de menes, no ser nada inteligente desrrollar un procesador
de textos sofisticado como parte del mismo. . 1 '.'' '

Sobre todo, cualqu:er disciplina de ingeniera requiere un compromis<;>. Un compromiso.

clsico tiene que ver con la definicin de qu deb.e conseguirse mediante .el sofh~are y. q~ t
mediante el hardware. La implementacin del software ofrece fleyjbilidad. rhientras que la del ' J .
hardware ofrece performaHce. Por ejemplo, en el captulo' 2, veremos el ejemplo de tma mquina .. , 1
operada con monedas, d~beremos decidir si tendr varias rant:ras, para Jos distintos tipos de ;
monedas o una sola ranura, dejando que _-el soft\vare reco'1ozr::a las moedr!.s. Un com_jJromiso an , 1 '
ms simple puede ser el t_ener qu~ decid( qu procesos deben ser aulomuzadOs y cules se harn .. : ! . 1
:.
en forma manuaL .. ;.; .:->:;:;,~~~J
1.2 ll is to ria de la ln gcul ~ra de i so flw a re.' .. ; iii;!~}])Wf~i~~ 1
El nacimien;o y la evolucin de la inge11ieda del softvvare comq disciplina dentro de la ciencia de : . r
.la computacin, puede ertconlrarse en la evolucin y la maduracin de la programacin. En los : . .! .
'.
inicios <.le la computa~i~n, el ~Jroblem.a de la i)rogra~11~cin se vea b:i~amenle com'o la manera \j 6; : .

1

de generar w1a se~uenc1a de msu~ccwnes que le lucieran hacer algo ul!l a la corn~utadora. L~-~-. ~-_:-:/

\
-:--~--- ...... =--- ' '
"'7. --- -----..--:--~:-- , ... -:: , : - - : ........ .---. ,.,. ___ ... , . :- ._-: , ~-. -. . . . . . . . . -- -~ ~- ,
, ,, , '. e - ~.' ~ ~
o - 0 - ,''

. ..
'.','1' ''".,''

-
o
0
"' "'" ' ~. ':.~L:.-:'~:,.:,;':'
~-
.i.J__:,.,_:;,,,
. ,l,,ii
 .;~ _-:~: .. ' : .. :-. < .. ~ ._. -- ..

:~~~~~'TI~1l~~t!~.&is;S}L;ij;_;ft~J'J;1Y.:'~i2;~ti~~f~:ii~tnl'i~)~';F\1-~,'/~':~~;};;:::;~~~-''' -o:r,.~c';c.,,~.:<-;i',~"-~:;~;:::;L~.:_~-_-,;;<-~-;-~~E;;:;~;~_;; __;;~~:

' . ;;;'lll.'
- ~9
' . '' 1!
' 1
'--:-
.. ; -:
problemas que se progrmaban se entencan: -con claridad -_ por ejemplo, cmo resolver una
ecuacin diferencial. El programa lo escriba por ejemplo un fsico, para resolver la ecuacin que - . -

le interesaba. Et' problema estaba entre el usuari~ la computadora; no estaba involucrada ningm1a-- y 1

~~~~ _, . \

A medida que las computadoras se volvieron ms baratas y ms c~munes, n1s y ms gent7

.comenz a utilizarlas. Se d!~sarrollaron lenguajes de_ alto nivel a fines de la dcada del '50 para
- ', :'::~):
facilitar la co1unicacin con la mquina. Pero todava, la actividad de hacer q~e la computadora' ';::: :.{J!
--- 1-iciera algo tii, era dess:Tollad3. por una persona que esc1~iba un programa para una .tarea
j : .. . . ~

concreta. 1.
.
1

) Fue en e~ta poca que la "programacin:" alcanz. categora de -profesin : uno le peda ~~ !
la
programador que escribiera un programa en -~ugar de. hacerlo uno mism~. Esto introdujo unh
separacin entre el usuario y la computadora.:' Ahora el usuario deba definir la tarea d~. una. ..'.' ~ :

) :_.~- :~:~ .
manera distinta a cuando s~ lo baca en los precisos tni1inos de la p~ogramacin. El programador : .. ' . . . . ~ . ..
..

) ' interpretaba la especificacin y la traduca en un conjunto de instrucCiones de mquina. Esto, por 1."'

'\ su-puesto, algunas veces, te.m1inaba con una equivocada interpretacin por parte del prognundor
de las necesidades del usuario, an en tareas de poca envergadura.
_ Para esta poca --: inicios de los '60 - se concretaron muy pocos proyectos. de grandes . .~ ;"

sistemas. Por ejemplo el sistema operativo ,CTSS desarrollado en el MIT fu urr proyecto
~)-'
verdaderamente grande, pero fue llevado cal?o por gente muy motivada y con gran conoc!~1ienLo' a
J del tema. , -- , ,1 -

J Desde mediados a fines de los '60; s~_'\nt~nto _presentar comercialmente varios g~nndes
) sistemas. El1i1ejor documentado de estos proyt:#os fue ~l sistema operativo OS 360 para la faniilia
- ., de computadoras IBM 360. Los gnindes:pro'y2tos,:hicieron tomar conciencia de que construir
_)
.';
grandes sistemas era mal :~rialme;-le c!iferen:Lc _a- cnstruir pcquefos sistemas. Haba di ficullncles
........ bsicas cuando se queran aplicar las tcnicas para el desarrollo Je pequeios programas al
desarro-llo de grandes sistemas. Fu entonces_ cuando se invent el trmino "ingeniera- del
n soflware", y se realizaron conferet1cias paia discutir las dificultades que estaban encontrando eslos
o proyectos y que impedi<.'!.n la crmega de los 'producto_s prometidos: Los grandes proyectos de
software -Lenninaban sali:ndose fuera- del presupuesto y. de los tiempos planeados. fu entonces
-~.
(__;}
cuando surgi el trmino "crisis del software".- - '
(\)
; -\ Descubrie-ron que construir grandes s\steil1as era algo ms que escribir una cantidad de
o instrucciones para la cor:Jpuladora. Por el contrario, no todos los que estaban en el proyecto
i('' comprendan por completo el problema que se esta)Ja resol\,ienclo. La gente pasaba m~s- tiempo
1 --
comunicndose enlr~ s que escribiendo cdigo. Alg11nas personas abandonaban el proyecto y esto
O- afectaba "no ?lo al trabajo que estaban haciendo; -sin tambin el trabajo de los que dependan ele
lO
ellos. Reemplazar un individuo requera un~ considerable cantidad de entrenamiento sobre el
Jb
< "Docklore" de los requerimientos dei proyecto y el diseiio del sistema. Cualquier cambio eil Jos
Q requerimien~os originale.s del sistema pareca afectar a muchas de las partes del proyecto,
o demorando la entrega c:el producto final. Est~ clase de probiemas no exista en los dias del
:Q comienzo de la programacin y estaba clamando por Ltna nueva propuesta.
Se propusieion _).se intentaron muchas soluciones. Algunos sugirieron que la solucin
@
estaba en encontrar mejores tcnicas de administracin. Otros propusieron diferentes -maneras de - - .
G organizar los equipos. Otros incluso pidieron IJwjores lenguajes y herramientas. Muchos ,'
; () propusieron convencan!~.:; uniformes ele codificacic. entre organizacio,nes. ldez{s no fallaron. El
o consenso final fue qt:e el problem::t de la construccin del software deba encararse de la misina .
o. . fonna en qe los ir.geni~::ros lo hacan para- otros grandes sistemas complejos; tales como puentes,
:o refineras, fbric3s, barcos y aviones. ~to era conside~a.uLsJeJ:na: como un producto
(_ complejo y a su Cllli.$li__ ~lcci?~como }!11 trabajo d_~_jng~_2-~ El enfoque clescle la ingeniera.

~
._/

e ._:j,

,le- 1 '!
. "l.,':--],
' .

('') ' . :.. :~: .. ::_{:.:::,_:~::;_~~- _:

.. P - - . - . . . . - "". r - : : : -.-: .-~:"_': t.-:- :1: ::::-::-:~ "": ; ..,. -.: - . . _:--: :r-: r ~ ::-.t -:- ..-- :~--: :.... . ":: :~ ,~ ..~-... :..:. : _:~:-~:~~~~~~~!.~~:;:~' ;~;~
 <: <'"~ ::.. . ~ -;_.,...
Ahg ....Ctrhzwe;{;m.e6.e . .. , .. ;;;.._~- '>
.~

l~\ ~ ,;
'.~ . ~-
requera direccin, organizacin, herr~micnt:s,~s, n~todologas y ~s. Y a~ naci la. ,!~~ -'.
ngeniera-del software:_ . ] -
La historia anterior enfatiza el crecumento de la ingeniera del soltware desde la : ! ~ ~:
programacin. Hubo tambin otras tendencias tecnolg.icas que jugaron roles in1po.rtantes e11 la .. :. :
evolucin en este campo. La inuencia ms.importantt:. fue el cambo que hubo en relacin de, . j .. : :":,;~. la
costos entre e~.:so.ftware y el hardware. Miet~lras que el costo de un sisterna compt!te~rizado estaba ~;._-. ;.,'j'.'_,~KiiN
def!-jdo mayonente pcir: el costo del hardware, y d costo c!el software constitua Ull factor.: :; ~;;~-~~.::i;,],i"_},~.~;?(_
in~i.grriicame, hoy (;D da, ~1 costo 0<;! s0n'l.'9p~ :fltwde significar ms de la mitad del costo total del .; f:-:~~ 1:<i: 'JVr::i:\ !
sistema. La disminucin del costo clel harc!\-va: ~ . : d .:;,~.::;nt;; Jel Cf'l<:10 rl-:1 ~0ftware !1~. ircEnaC:-; la ;:_'i.'~':"":: ~.:: _; '. 1
. } ..1 - . . - :' . . ~.== :_,~. ,-''~

?ala~a en direccin al sof"Iware, poniendo un nuevo nfasis ~con~1ico en el de~arrollo de la. ; t .,:;:~ :~-)~~-
mgeruera del software. . . _ ." r.;,:.\ '(j'f.',:
Otra tendencia evolutiva ha venido des-de dentro d~l propio campo de la ingeniera dei : . :; l
software. Se com~-tlZ a poner nfasis .e1i considerar que se trataba de algo ms que "codificar". En , !
cambio, se comenz a ver el softw.are como poseedor de un ciclo de vida, comenzando desde la ; :~.:. ?:'.~;'. !1
y
l:_;'_:_:.:..:'._:__

concepcin y continuando con el disei'.0, desarrollo, implementacin, m~mleriimiento cvo'Iucin. . ; : ;:: ;

La disninucin del inters en la codificacin, alent ei des~rroilo de rri~todologas y herr~rnientas : ) .. _.:;;;.,;!
sofisticadas para apoyar a lC.s equipos involucrados en el ciclo completo de vida del softwa;e. . ..... ::::-_. ,"_; .: ,i
Podemos esperar que la importancia ele la ingeniera del software contine crecierK!o por :..:, -
varias razones. Prit:~ero las econmicas : en 1985 se gastare:< :1lred~dor de U$S 1L10 billones et1 ; ~

software r-n todo el mundo. Se anticipa que los costos de software superarn en 1995 los U$S 450.
billones. Est~ hecho solamente asegura que la ingeniera del softwar-:.: ::::~L~;:;- como disciplina.
Segundo, el software est penetrando en la sociedad. Cada vez se utiliza ms software para
. controlar funciones crticr.s de diferentes meanismos tales como aviones y apmatos pllra- la
nicdicnil:: Este J.J.~ho asegUia el inters creciente de la sociedad en software confiable, ep la
creacin de estndares especficos, requerimientos y certificacin de procecli.rnientos. Sin eluda,
seguir siendo importante prender la mejor manera ele construir mejor software.

. .
_) La evolucin del campo ha definido el papd del ingeniero del software, la experiencia y la . ~

educacin re'queridas.1fu..ingeniero del softw~be s~or supu~_?to, un buen prograr~ador, debe

., ~~9-EL~SilllClU!~-~e datos__ y al_s.~itr::~os,_x__~nanejar con fluid~~~<:.__O ms l:_:~S.:~~-~.s_de .
,, ra
~---- ---
programacin. Estos son rt:querimientos para "programar en chico" es decir, coistruccin de
----- . -- ---------- ----- ----. -~-----------------
programas que pueden se: escri los e:!1 su totalidad pot u!1 nico individuo. PerS?._~p_jl)g~nier.q_~~J.
software tambin ~a-_~v~li.Jc@.~l~t.jw._~rC?.f:~itnac{qA.--~~-=~gtand~"' sta tiene otros :y
~; recueri mi en los.
- ..-- El ingeniero del so ftv,_a!:~!l~~~- e~~~~.[~~!!.Jil0Ii?~t-~9.-c;;s>B...c!~feren~~P.~~: d_iseo~~l?~ . :
. e~ tar c<p~~t~..9.?.Y~r:_a ___ !!..~::~~.!:_req~_:::runiento_:;y,..sk?.tQ.:LY..a.g~E,_~_s_peci.fl.~?.S!.J.J.es.pi:~.~~s_-S,_Y-~~-b~ ,. .'/ ,
,.
-sabr-conversar con el us1.1a~jo en trmmos de la aplicacin ms que en trminos computacionales. ... .
:
.Ji

src;:-a:--su
,;-z. ex.ige ne-:.:15111daCf y-a.Jerflirara.'raeEten.Ciery ..co'CerTaescCI-adeTs-diferwtes.. :...
reas de aplicacin. El ingeniero del software debe poseer habilidad para mqverse entre distii1tos ":-
niveles de abstraccin-eu!rlsd:ITerentes etapas dd proyecro., desdc'.os-p[=-ocd.ii11e.ii:t'os~ ;i";(:'
req:Uefli:;~ntos. ctc-i.f..iJi;;;~-i1,
1mali1ei1te-e.I1ilvcl--~Jef (:digo ie"tiTicto~--------:----.-- .. --- ----- - --- ,_, .... - .!
pasando por las abstracc1;-;;e~ -:-I~l ~ist~m~~ ~IC:Gse1o_.~ir:~~Jzf~-~~y ' .
--- o-(.;~~-~l"L~ri~~;~;;l.o..e;-~Ti:oct~Edo. El ingeniero del sofhvare tl~be ser ca_R~ms!DLLY : ",

usar un modelo de la al2.!_iS:l:~~n pai~LC!r la eleccin q~.Jas cljs_tinl''U2f9.J?.\.lestas g~~ erifrelltoL:-1.-..m_i

,. '
'-.,;'
modeiose usar pan co"~1J_est:ar preguntas sobre el comport~miento del sistd.1a y su performance. ;
_____________
------~----- - - - - - - - ---:-~---
PfeTerentemcnte podr s:~r usado tanto . por
.
---- .... ----.
el ingemero como .l22_f el . usuario.
--------------- l
___ :;.----

- . . . 1,
1
.. ..

/.
'

lo 1v ...

.
C.:
. . .

O 0 0 _ , . o0MO 00 - - -OOOOo- . . 00 jO' 0 ' . - , _ 0 ' , --~: 00 . - - - O O -,-::-.,.:-~:-:---~'!"0'0 ,--~: : 0 0 - : - - - : 0 - : 0 0 ~--. - 0 - 000 000 O O O 000 - : - - . . , . - - - 0 0 0 oO !' 0 00 . . - : - - - - : - . . O o ~-----~~ ~---~ ~ -~::!.~:~~: :--~:~: ~- .
.... ... O

-...,--~- -;"""":'~.'"1"1'.,..~-r-;r-._-,~~-; .... .. - . :-:--:7:---=-'

 ,, .... -; :- .. : : .,_.. ~. :

.. ''Codificacin y testeo de mdulos .. Esta es la fase que produce el cdigo real que ser ....
' r
....... entregado al usuario como el sistema para ejecutar. Las otras fases del ciclo de vida
tambin pueden desarrollar cdigo, tal como prototipos y rutinas de prueba, pero
stos son para uso del desarrollador. Tainbin se prueban los mdulos individuales
desarrollados en esta fase antes de entregarlos a la fase siguiente.~ . . ! .

* Integracin y pnieba del sistema. En esta fase se integran todos los mdulos que se
probaron individualmente en la fase an'terior y se testea el sistema completo. ' 1. . :~
* liber~ci'l y r:Jar:.t~:::nimient0,. Un::1 vP.z que el sistema pasa toda? l~s pruebas, se lo . . : :::::
entrega al usuario y-::::~:::. .::nlc: ,. i."'~'<'' (k. rn~.;:..:r:irr:eni.:. Cualquk: rnoJicacin que 5e ' ":) 1 .
efecte luego de la liberacin se atribuye a esta fase . . , : : .~':;~~ti:
. La figura 1.1 da una idea grfica del ciclo de vida de desarrollo del software, y provee una
exi)licacin visual del trmino "cascada" utilizado para defio.irlo. Cada fase produce resultados que
.. 1
"~uyen" hacia la siguiente y el proceso contina de una. nianera lineal y ordenada.

. "} .. . ~.

.: . ,.
.... ~-.

Figura 1.1 : Elmoddo de casctda del ciclo de vida del software .'
;_:::: ,.
.: ;".

1 - Anlisis y especificacin de requerimientos ; .

'2.- Di:;co y especificacin
3.- CodillcaC10n y testeo de mdulos
.~
4 - Imegracin y prueba del sistema
S- LiberacinfTrirHenitiento

Una terminologa c::Jmiln. distingue entre las fases altas y bajas del ciclo ele vieJa del
software : el estudio de factibilid01d, el anlisis de requerimientos y el diseo de alto nivel
pertenecen al primero; mientras que las actividades orientadas a la implementacin pertenecen al
ltimo.
Tal como' se I:J present aqu, las fases clan una vista parcial y simplificada de la
convencin que define el modelo de cascada. del ciclo de yida del software .. El procesq pl)ecle:
descomponerse en diferent~s conjuntos de fases, con nombres diferentes, propsitos diferetites y
diferente granularidad. Es :;msible definir esquemas .del ciclo de vida completamente diferentes, no
basados estrictamente en el desarrollo en cascada. Por ejemplo, est claro que si algunos tests
descubren defectos dd sistema, tendremos que retroceder-por lo menos a la fase de codificacin y
!al vez a la fase de diseo para corregir algunos errores. En general, cualquier fase puede. descubrir
problemas en fases previa:;, esto nos obligar a volver atrs hacia fases previas y rehacer algn.
trabajo anterior. Por ejemplo, si la fase de discfo desc.ubre hc.onsistencias o ambiguedades en los ,.
requerimientos del sistema., deber revisarse el anlisis d~ los requerimientos '-'jJara comprobar
cules fueron incorrectamente analizados. .!
)
Otra simplificacin en la presentacin anterior, asume que. cada fase se,eompleta antes qu .. -.

comience la siguiente. Er. le prctica, es a rnenudo conveniente comenzar una fase antes de que
finalice la anterior. Esto p:.1ede ocurrir por ejemplo~:_si-igunos de los datos pala: completar la fase
j de requerimientos no cst<:.rn disponibles hasta ~el1tro de LUl tiempo. O puede suceder que las
,~
personas que realiz::un b etapa siguiente se :,encuentran disponibles. sin nada para hacer. 1 i

Pospondremos estos y otros temas .relacionados cqn'!=] ~iclo de vida del software hasla el captulo
_,

7. . . (',' -'Y 1

...Ji
. :'' '.- .
1 '
:;r1 ' 1
. .,.. ;-r - ........... , ~-- ~ ,. ~ , . , - ---; - .... . ~. - r "''."::." '.:- :~. r ~,... , , '" '" : .... : "": . r; : ~ ~ :- t O .... .... - .;r: : -~ ! ' ' -- ,.,. - -:- ; : : '' .-:- - ' i ...... ~ .. :-- ,.". .
------~~---- -~- ------- -;~----.- ~- .... - ... ~ : . : .. .! ... ~ ......... .
 . . . . . .. . .. '.
~
.;::>: .. :- ..=: . .
;:-: -~

........ 1

: i fu~~E~I.O.-deL~sof:Wl1J.C es n~ie!nbro:: ~le: -~~---~gui_R.q_j~deb.i!..~pose.eLhabjl_igad_para ~: .'... ... ~ :~ 1.

comur~i~:~~-9?-...Y 2....r.el~~!.9J.l~..s .i~l.~~~p-~~~~_!?:~.!_e~- Tamb~il_~~be_~~~--~~P-L9L9Jg::u~iz~:,:.. ~l L_:~~~-o, : : . l
lalit6-el ~~Y.O_ como el de los ceE?-~ . . . . !.
Como se discuti antes, el ingeniero del software tiene muchas responsabilidades. En la, . i . . .
prctica, muchas organizaciones dividen las responsabilidades entre dif~rentes specialistas, con : .., . . _
diferentes ttulos. Por ejemplo, un analista es responsable de relevar Jos requerimientos, y un. : .. 1 .
~~:~~~~:~~~~~:'~: :~ ~~~~;;~~:bJ~o~~~:~:s:s.d:ela performance. ~in 'mbargb, a menudo, . l .. ;,'~/
...
l.A :iDl;cicJo d.e . .yida deloftware i . .,. , \ ,:( :
1 ;, . )
Desde qu~ nace la idea de hacer un sistema, basta que se lo implementa y se. entrega al usuario, y
an despus, el sistema sufre un desarrollo y evolucin graduales. Se dice que el software tiene un
ciclo de vidgs.Mip~_: vari~ ra~es. _9lc.ia t!!J-...9.:....~~-~~...f.a.~~~-.:r:~~~-~!~ ~-~~-~J..~~~?.:~~9Jio .9~ u~1a
parte del sister~~_Q_illg.o_asociadq_c.olL~UP.:~~?.~O, tal como un plan de pruebas o el manual de!
i.
usuario. En el modelo tradicional del ciclo de vicia, llamado "modelo en cascada", cada fase tiene
puntos de comienzo y finalizacin. bien ;de1 f1r1ido~:. e;~~ e~tregas identificables a la fase _si guienle. i
En
'
la prctica, raramente es tan simple.:.~:'.! >; ~:-~.!~r:'i?i.l-"1':.::!;i.:\:}
1 . .
~:: ~~~ ")~1;~\:,;.~.,:~::1 .. !- .
: .t
.
Un ejemplo ele moddo de ciclo ?.~.:~W,<;,<~~l~~r-.~~\?~ ~.?r:nprencle las siguientes fases :
o

!~ :
. .. .;Jif&~.;:,;:i::J~;:~l)~:Y(~~:)iii!!;-> t . . ... 1 -.:: . -'
~";.z&jl:'ti''tt'S'i:&~:t~0s-i12fie,j;ki~ca,ci.I-1A-k:.,~q:i:.ei:i1i'ii'fo~:~:.i~F.l ~ril i si s de req ueri miento s es 1 1
.,.- . - ..1;~ .. ":'"....,.,:i:'''".'<:::\,l<f.J''~~-;,...JC.~ 1r~'"'':"' --.-.--, -~:-.\fl,. ,...... ll' ..,,11' ' , ' ~ :: 1

generalmente
.
la pi:iri1ra:'fase de:.ri;pr;o):~:(cr'de'desarrollo . . . . 1 : .
!;~.:- ~ '. . o:J,. ., ": ."' ..
de

software en gran escala. 1

Se lo aborda Juego de haber heclioi.m e~tddiode f~c;tibiliclad de los costos y beneficios

del sistema. El_ propsito de.es1.fase ~:s~\de~~-Qc~['y dqcwnentar los requerimie.n1o-s~ ' '
exactos para ei sis:erm.. Este estudio pu.diH~r .telizado po.r el usuario, el ; ":.

.!
desarrollador, una organi~cin de n1ak:eting, cualquier combinacin de los tres. En o
los casos en que les requerimientos n sonclaros,"-: por ej. para un sistema que se hace
por primera vez- t::s i1ecesp.ria una gran interaccin: entre el usuario y el desarrollador.
Los reouerimienlos en esta eiapa,.estn en trminos del us1.iario finaL Varias
metod~logias sost:.enen que en esta fas se deben producir lambi~ Jos manuales del
. , usuario y los planes de prueba. . . . .! - . . .

;;:;'g\!OishffdLy'(ls>ifi;::cirl. -Una vez que. se hai1 documentado ios requerimientos, Jos ..

-~.
ingenieros del sof':vval'c disear1 \.ut.sister11a que los satisface. @a fase se d:ide a vec~s
... e!1 dos subfases: dise.iio de la arquitectca o de. alto nivel y dise1o detailado. El disef.o
de alto nivel trata ms con la totalidad .de los mdulos de la estructura y organizacin.
que con los de taLes. El di.sdio de ailo .n'vel se refina diseando cada mdulo en
detalle (diseo detailado). : .
:)
La separacin de la fase del anlisis de requerimientos de la fase de diseo es un
J ejemplo ele una d::;cotom.a bsica que a menudo encontramos en la -lencia de la
:x 1
computacin: la dcl"que/como! El principio general implica una clara distincin

J entre cul es el j;rcblema y el cmo reso!ve.do. En este caso la fase de requerimientos

.) -iteiltadefi1r cu::Ies el problema. G~n~ralmente h!Y_!!.1uchas forn)_-~Q.9_~~Usf~~~J.:J.?.s ,.,

requerimicnt~j::.:.:l~~ by soluciones que no inciuyen el uso de computadoras. EJ

1 .

~J ~la fase e\ e c!!Seri"oes<fIii::J.I~tej_lfi de. so'I'tvi-are-iile."ios. sat15-.taga.

\...J 'N~-i.rite~-l1:1);-ullas1a;-1e-r.as de construir et~la~'E.T- EseCfe. CJlTiccin,.
1.:..) que si_~1e a~ fa;f__~~-~-~li;;_ef'J, s~ ~.?5.~.!!:~.~ l0~i~tema en J2~~i5:u~~r q~-~~.!.~~p_!_'!.S,Q.IJ_)_~s
especificacion~:i -~-~Ld~seio_. Ve:'emos muchos otros ejemplos de ia dicotoma "q~1e/como"
aJ largo-;-~~ le 1ibro. . .

.
. - ~-~--~~-- ----~ . ..
~ : . : :' : ............! ... ~... ---=~ ..... ,
 ;itcy~~-Ai~:i;j;~~.ji'j,$cit;,;&z.>rteie:7~~~--..,;_::~-w ~~~~--~:_: - .:_;_..; .-;;. .::: ~:: ..;;.,:_:::- -:-~;::} -~<:";_, .:--::---
'-
(;.~. ' ~ . . '
:.,t~ '~ ' .t

' -.. . rnuy bien desarrolladas - p<:,ra el desarroilo del sollvvare en ger1eral.- Por ejemplo podemos usar la ."--;. --~
gramlica para definir la sinlaxis de la interfase y :malizadores-generadores para verificar la _;
. c~n~istencia y la falla de ambiguedad de la interfase 1 y automticm~1ente generar .el front-enel para '. . ;- ...
el s1stema. -
Las interfases de usuario son un caso especialrnete interesante. porque nos hacen ver ia . . ~:;;;;{
influencia en la direccin opuesta. Las disc~1siqnes ele ~a i11ge11iera del soft'0'are girando_ alr~dedor ,'
de las interfases de usuario fueron posibles por la difusin del uso de imgenes de mapas de bils y . . -~:~,~,J
1::ouses e:"' h'Hl ):r:y;_;ca ~ l:Js lenguajes r:ie .programacin a trabajar en el rea !e los lenguajes> _ ,-. ytVff:
",vtsuales" o ".;i:.:~ricos''. Estos lenguajes intentan capturar la :;emntica 1:e'. mailejo :-:<".ventanas.,._ , . : .>:.
(windowing) y los paradigmas ele interaccin ofrecidos por los nuevos y sofisticados -clispositivu::, :: . :. ,\:./ ..

grfi.co~dems, otra inOuencia. de los lenguajes de pro~~amacin sobre la _i;1geniera ~lel soft,~a;i:e, . , :. . ..,'.H:,
se da a travs de la nplem~ntacin de tcnicas q~le se han desarrollado para el procesamiento ele. ' ' . . .:
'
' .l-enguajes. Probablemente, la leccin que mejor se aprendi fu' que la formalizacin llevaa la . .: .,,
'
' automatizncin: definir una gramtica formal para un lCnguaje pennite producir aulom!icamcn!c }t;
... ~
un ~nalzador. Esta tcnica fu explotada en muchas reas c.le la ingeniera cid softv,,~e p:,m; b : ; . .: : '{:' .;
especificacin formal y la generacin autom{\lica ele software: _ ; ~'-;,
Otra influencia proviene de los dos elementos. ms importantes del procesa1niento de
.1
lenguajes - compilacin e interpretacin - que han sido ampliamente estudiados por los
diseadores de compiladores. En general, los intrpretes dan mayor Oexibilidael en tienipo de
ejecucwn, y los compiiadores ofrecen mayor eficiencia. Cualquiera de los dos criterios es
aplicable generalmente a cualquier sistema y puede pasar a ser una herramienta ms eh la caja de
het'ramienlas del ingeniero. Un ejemplo de su aplicacin fuera del rea de los lenguajes ele
prograrnac.in puede vers::: en el campo d;; las bases de datos. Las consultas que se realizan sbre
..:.'
una base Je dato's, pued=:1 ser. compilac.ls o it~terprctadas. Los- tipt:rs c.le consulta. ~i.s comunes se
compilan para asegurarse la rapidez en la ejecucin: 'tntes de hacer cualqui;.::r cunsulta al sistema,
ste detenoina el c:u_nino exacto ele bsqueda usado por la base de datos. Por otra parte, como el
,-.
'. .:~ 1
diseiiador de la base no puede pre-determinar iodos los tipos .de consulta, es posible realizar
cons:.:ilas ad-hoc, que requieren que la base de datos seleccione el camino de bsqueda en tiempo
de ejccuc[n, tas consultas ad-hoc lardan ms en ejecutarse pero le dan al usuario. mayor
flexibilidad.
e
u !
("',
\. ..
La influencia de los sistemas operativos en la ingeniera del software es muy fuerte, principalmente !
e porque los sistemas operativos ueron los primeros grandes sistemas que se coristruyeOn, y adems '
(~
-~
fueron los primeros ejen:.plos de softw?-re que deba s~r "ingenierizado". Muchas ele la$ primeras . , ..
o ideas de diseo de softwe smgiercin de lo~ pLi.meros intentos de construir sistemas operativos. .
u Mquinas virtual:::s; niveles de abstra~cin y la sparacn de ia poltica, del mecanismo son ;.:'
\Y conceptos desarroiados :::11 el campo de los sistemas operativos con aplicacin a cualquier sistema !
de envergadura. Por ejemplo, la idea de separar una ")oltica que. quiere imponer un sisiema. ,
.o operativo, como la de as:~.s'Lirarse la interferencia entre procesos, del mecanismo("time-slicing'')_::: no
ca usado para manejar con xito la concurrencia. es un: ejemplo de la separacin entr_e el "qu" y el
u "cmo" - o bien de la. :~spccificac.in la in1ple:i1entacin - y de la separadon de las parles de
u intercambiables de lo qt:e queda fijo en un .sis~~:11~.La idea de niveles de abstraccin es slo otra l
lc aproximacin. a la mod:.darizacin del diseo :m{ sistema. ' . : . 1. de
e En la :direccin opuesta, la in.h~e~lc(a;J~;:i,la:~_inge.nie.rla del software sobre .Jos sistemas <t >
operativos puede verse tanto en Ja man~ .. 9n):qt!. :se estructuran estos sistemas como en los . : .. 1
. ... . : .' . (:: ~d.i\i_;: _.:: .: - 1

:..::_::'[:o_;J:,:.f:
.. _,_../\

. - .... -~ --:t:r' ;. ~-- '":' --.--- ... ~- ...... . :. .... r: ~:-.,.,,:: ~ :::.:;:-::~~ 11" : t -. \' ;-~ . ~ .... : ...,.-: . .. . : :-
.. ......... ..
~ G r-::- -~----= --:: ':'-
-~ ~-::- _--~.:: - ~- .- -. ..-'.~';.~.A_;,, .~ _ ~= .,: f.~_-~-
-:. -- . . .. . . ..- . - _ :.... ..
... - -- ... .
_ ..:_.: . .-..c.. .
 .. : :, ; ' . . .. '; .
La mayora de !os libros sobre inge~ierl~ del so.ft~are estn organizados de act~erdo
con el .. ..':_' {'~,;
modelo del ciclo de vida tradicional, cada seccin esta dedicada a una fase. Nosotros eri cambio,
hemos orgari.izado este libro de acuerdo a principios. Una vez que Jos domina, estos principios
pueden ser aplicados por el ingenierp del software ri. todas las fases del. desarrollo e incluso a
modelos de ciclo de vida que no estn bsados en.'un desarrollo pot fases, como se discllti ; .; }:j~
anteriormente. En realidad, las investiga done$ y :Jn xperiericia de la ltima dcada han :! .:
..... demostrado que existe una, vadcdad de m.del;sA~. cicios ~e vida y que ninguno es apropiado P?ra '. . ' ',,: .
:ser aplicado a t;dos Jos siStemas. En.el capftlq.:~ex,atnlJlaremos varios de ess modelos. ; :.~... :.: :
; . r. : . .'! ,,. . ; , ; :., .. ;. :.,; ,:, .,':-;:f.i;:/;.;~,;.::~'!~;::;\;:.;:;:.,)(._,.,;.. ,... ;; .. :~ ; . . :. . 'i,;,>,' ~ i!

. 1'_i.s La re!~ ci!: cnti~e'l ingeni~a;"~~~i.'_i.~.f~;-~~.~~~{~fi-~s

computaciOn. .
ftre~~ de la d~ncia de I:i :.'_:.' ~. i .r :. : :.='!: .:~; .:; .:f _.:~.- ~
:,.-.~.:. 1/~\.:;.>,.:::
f .._::.. .. ...:!i[.:::'..

~.
. ..

) l; , ! :.~:~,J?iirt~~:;~q"- ~ : . :.: i .. .
un
La ingenieda del software ha surgida corno':' .'.campo .importante dentro de la ciencia de la . ,.
computaciri. En realidad, hay una relaci~n.~ii;lrgi~ entre ella y otras reas de dicha ciencia : ~: .... ; .,. ,
estas reas ejercen influecias y son, .in.fh..i~n:ciadasjxir:'.Ia. ingeniera del software.' En las sub!;' ')1\;')i:,'J:/Ji
secciones siguientes exploraremo~ l' !~1a~l.qii'; ~i~ti:e:)a. 'ingeniera del soft\vare': y otros campos. ;:i':(:)t.~~irt~~:;~,
importantes de la ciencia de la computaciqh:!\yr\.i.>ij(, :;; 1:;:: ;i.: . . . . ,, . ,. y '. :;t<; . ;:.;;:.X,

, ) .5.1 Leuguaj;~ prJ+~aciu :''',;~~~~~~~~~f*t~~')j: . . ' ' r .

de . . . :,: ,', ,,: :
.. La nfl uencia de la ingenra del softwari'.e'ir os.,. 'bgujes .de programacin es bastante evidente. . . \: -.
Los lenguajes de programaCi'n sori las.~~b:~m:\WE~~~:t,:t.f~c!~~les 'para
:er'desarrollo del software. Por .._, . ,
lo tanto tieJlen. una profw;.da influencia' sobr<f)t~}p_osib'iljd(\d' ele alcanzar con xito nuestras melas.
Por otra parte esas metas i.nf1uyen sob.re~8~sa'd!Jo:'(to~ ienguajes. de programacin._
;.., . El ejen?!~lo ms notable de esta)~fi-~~i.\9{~:~l.~.hr1engtiajesdeprogramacin recien-les, es la ..
-'
r- .. inclusin de las carac:terslicas de l!10dularid;id; .J.a!es como la compilacin sepnmda e
1\
1. . independiente, y la sepan:;cin de ~a esp~cificacJl d~ 't~i. implementacin, con el objetivo de apoyci.r

1
~: ~.: el desarrollo en equipo, de software ele .envel-gadur.a:. El lenguaje de programacin ADA. por
. ,.. ... _
ejemplo, soporta el desacollo de "paquetes":: perm!tit~ndo la separacin de la interfase del paquete,
;~=:1 de su implementacin :- y se pueden usar. bibliotecas de paquetes como con1ponentes en el
;t.J.. desarrollo de sistemas illdependienles. Este. ~s . unpaso hacia la posibilidad de cor,struir software, ; ~ . '
~ '
~~-'
eligiendo de n catlogc 'los componentes disponibles y combinndolos1 en forma pa~ecic!a a la
l.-.
manera en que se Cnstruye el hardwar~. ; . , :; ' 1

~
!. '
f .......
~ l.::;
lll(".
En ln direccin opuesta, los lenguajes de
programacin, tambin influenciaron a la
;1.;: ingeniera del softwar:e. Un ejemplo es la idea cie que l.os requerimientos y el disefio deberan. ,
" ..
describirse usando un k:1guaje lali riguroso corno un lenguaje de programacin, y que puJiera ser

~
' ( :.'
! ..,
procesado en una cor:apuladora. Como otro ejemplo; considere el punto de vista de que la entrada 1
iC de un sistema puede ser tratada como un prgrama codificado en algn leriguaje de programaci1i.. 1
~.("
}~. ~} Los comandos que el usuario escribe para el si"3tema no son una coleccin aleatoria de caracteres;.! :
.;-e~ ellos forman parte del knguaje usadopara comunicarse con el sistema. El diseo del lenguaje de
cntmdn apropiado es parle del diseo deJa jnterfase del sistema.
Los sistemas operativos ms tradicionales, tales como el OS 360, se desarrollaron antes de
que se conociem este enfoque. Como resultado, la interfase - el lenguaje de control de trabajos;
(JCL)- es muy difcil d:~ dominar. Por otra p;:. rte, les sistemas operativos mns recientes, tales como
UNJX, proveen al usuao una interfase que semaneja como n lenguaje de programacin, !o que
los hace ms faciles de aprender y usnr. :: .
Una consecuencia de en.focar interfase de! software del sistema como uri. lenguaje de :f\.1 \ .
programacin, es que s:: pueden utilizar las herramientas de desanollo del compilador -que estn .. i ':~~
l. .. ' ....
. . /:.'! :. ;' :.
.-.

. . . .:'f~;>G:i
',
. .. . .

-r"':,-o"'''"':'"'w-- ""'-'"-w-- .. -
 ' \

~~;_ : :~: .: . . ... .: . - .......... :~- ..;_;. . .

~~~~~~ey,~~~~~~~:~~~r:it:f!I~;,r,i;~i~;Y;:s?'F':1~;1G-.s;:;,::.:;;::.;;,:.;t~:;::~~~~;:"',~';='~:..,~,.,"'>;;;,,,;,k~"~-"-"~.::.lf.LL.,.:,:.-::iL
'
' ._
~
41':,/1./~l
1QJ!.Y
..... ', . ., 1 . ' ...... ,
:: ~;.::.. . . ;,, .
\ ' '.. ~bj~tivos que tratan de sat:sfacer. Por-~je:n;~~~- . .~1 ~istehi~ operativo UNIX intenta proveer un ,:'. j ; ~-:..::;.:2
ambiente productivo para el desarrollo del software> Una
clase de herramientas provista por es le .,: . '.. ::. ::. p
ambiente, soporta un mam.jo de la configtiracin d~l software - una manera. de mantener y

; ) .. -... -.......uevamente)'y los sist~nas. operatl.vo~.. qe~:~s'tlti:. disellados para contener un pequeo
': . : .. .. ',:;,protegido'_' qu~ provee' u~ mnimo. ~e ~~~ci.~J?.~~~~~. ~;~t~ }~1ter~ctuar con ~ hardware y ~na parte,~ .<+,:f:\.~f:i~-
~~~-~t. l..~- kernel . : .-... !;.. _';..

' . . ; '~no proteg.da'~. que provee la ftmc~ona~1qad a.l!-tep?[~~nte .,asqcwd_a a los s1stem~s operat1 vos. )?'or. ,i) :. .: :; ;;r
-! ~sti~d_o c~mtro 1ar el' esquema de pagiiiado, q~,e, .-, :- .;~:~::.:/;. ;;;:': ,-F
yj emplo, la Pcutf? no protegida p:.Jede perm_i ti(l
) . tradicionalmente se consideraba parte integral ~el.sistenja operativo. . , . . . . . .: ..:; .. ._, ., -\ ;'
.. En forma parecida, en los primeros sistemas operativos, el intrprete del lenguaje de ; /'~.;
-~~: ~01n~ndos, fonnaba parte. integral del ::sistei1).~. ,.Hoy, est cotl.siderado simplemente como un ..
y: u'tilii~rio m~s. Esto pei-mit~ por ejernpl_?}ct~t.s~4a usua:~o tenga Ul~a v~rsin p~rSO!)a!i~ada del' ' : ..... ,
}:~: :. i~~trp1:ete. ~ri muchos sistein~s UNIX ]?.ay 'pcj_r)fiJ?.e~g~ .~res intrpretes: distintos. . '

!:.i . Y~;~;~:~~sc~;~Ma
- -
tos. ,::,; ; ;:l~*~i;~\!~J:~:;f~!:ti;
.:. lf. ~~~ .;. ~ , :- .l:!'~.'.:' : ;, ~.:''1\~f.;~~ ~t.rl~tt; ~~r~/:h:~~:
1: f:,; :r;tlh' ;1L: '
\;
1 '! .i .,:: .
' .
.. ,
-'-' ;, . ,:: t~'s 'bases d.6~'di!Los represe:.ntan otrdtcHis''j'Ci~~tia6:S'si.sthnas .que' ha~ tenido itiD uencia sobre la
?.: _.:: . : ;::irig~riiera.cTei\6nware(ift:~Vs del:'d~'!Jbfi~i~fit~\Ci~"R60~~ tchicaXdJ diseo. Probablemente la .;
'\' .' ' . ...;:.:j nD ~~ncia':~~s:: importi~~f6' d~. las_. ~;if~g{1 a~dA"t~;,est <d'~da'' p6r j'~ ~o'dn
'~:- '',~,.,t~;:t'f":-l,l)1,1f1'~',/'\'t\r:ot',,:'"lll,
o'(ll1 , lo ~,,,o.
de "independencia ele .. ;, - .:
, ,'.,, 00

. datos", que es .9tro ejemplo de la separ).ci~-~~.:d~:la;'esljetpcadn cleta. {mplemelitridtt La base de :.. : -~: .. ~.
: \ : . ; " . ,'.,, , ' 0 0 0 0

"~(.\
1

. .
,_... , . . ;: 'datos permit~ 'escribir i)licaciones ;'Cjue.:::t~~:ii\J9f.tat9s 'sin preocp~rse por la represenlaciti
;r~ ...
'.'subyacente de:los mism.(;s, .Esta il~depen~~l,12lrl.'petli:i.(te.'cah1biar la base de elatos de_(:liferentes
1..- ' maneras -por ejemplo, para'aumentar la )~rfi)iah~e del sisleri1a ~ sin que se haga necesario hacer
.(-) ningn cambio en las CJ.pJicaciones. Este es un ejemplo perfecto ele los beneficios de la abstraccin
C.! y la scparac.in de los objetivos, dos pr~ncipios_ Clave. de la ingeniera del software, como .veremos
:e;
..:.-
en el captulo 3. . . . . . . .. .
o ..
Otro impacto inte:esante de la tecnologa de bas de datos sobre la ingeniera del softw~u-e
lC_ J..) .; es el que pennite usar los sistemas de bases de. datos como componentes de sistemas de rnayor
.

~ .tamaf.o. Desde que las bases de datos resolvieron los lllUChos problemas asocin,4os al manejo de . . . . .
jU . . ~ccesos concurren les a grandes cantidades de informacin por mltiples usuarios, no hay necesidad !
C: ' .: de re-inv~ntar, estas soluciones cuando construimos. un sistema; sir:pplernente. podernos usar tm
1() sistema de base de datos :!xstente como un componen le. 1 . . .!
(j . Otra illiluencia interesante de la ingeniera det' software sobre la tecr1ologa de bases de
(:~; datos tiene. su origen er1Ios priue~os intent<;JS de usar bas~s de datos coino sopdrte de los ambientes

-,(j
de desarrollo d.e software:. Esta experiencia demostr que la tecnologa de base de datos tradicional_. !:
'. era incapaz.de manejas bs problemas generados por los procesos de la ingeniera del software. Por , ! .
:o -.. ejemplo, las' bases de datos tradicionales _no pueden manejar bien 'los siguientes requerimientos : ' r.
C . . . almacenargra..ndes objets estructurados, tales como programas o manuales de usuario; almacenar
grandes objetos no esl:ucturados tales .como cdigo objeto y cdigo ejecu.lable; mantener
'("'
1 ';~ ... diferentes versiones de .m mismo objeto;. almacenar objetos tales como un pro,clucto que posea
~~ C".
f
. campos gra.p.des, estructJrac..!os y no estr~tcturados, que pueden ser cdigo fuente,' cdigo objeto y '
: C.J rnanualdel tisuario. '
' . - . 1
'; ("
r .l-J Otra dificultad t.iene que ver con la ,longitud de las transacciones. Las bases de datos
o ... tradicionales soportan trrrnsaccicecs co~ias como por ejemp[o. un depsito en una cuenta bancaria o
. A'/
\17
un retiro. Los ingenieros del soft.vare, por su parte, necesitan realizar transcciones muy largas : un. /
i /
ingeniero puede querer. :~jecutar tma larga coinpilacin en un sistema mull-mdulo o puede querer ! .
!.
iC : .: .~ :
.l .. ,.
~
-,~- -
('' .
' 1

'
. ;./

;~ ( :~, 1 '
- . 1
-- -' ': -~-: ' '':"' - ,_~":T':'" .. ,_ -;:r -,..-;- :.-... '''"':-..,- "t ,' ~.::~ :, .. ,~.: ~~'=', : l'';' 0
''":':''\ '" ~:
 . : -- < :":: .

~ r:::j~:i~i~~:~~:~~~~pi:~i:s~f: ~:~ ~ : ~~ r:!: ~ ~z~:~i~r=:;I:~ ~ ~;b~:~;~ :, <:",;';}rf

prohibido el acceso a todas hs otras partes del mismo ?. .."' !
En este. momento se est trabajando mucho ::;obre el rea de Jas bases de datos pant
so!Licionar tales problemas; desde introducir nuevos modelos hasta adaptar los modelos actuales.

::::~:~:~:c: ~;: :lc: : olro campo que ha ejercido su influencia some 1a 111 a del
s,oftware. Los sistemas creados por la comunidad de investigacin en ~n~eligencia artificial .S~, :;;,f,i~1i?~i!'~.;~r
g~nieri ;:!j~~
encuentran
' .
entre

Jos ms complejos que se. han desarrollado. Pero difieren .
de otros sistemas de. ~,=::L{ff:~:
. ' J , .,
jj

manera muy significativa. Tpicamente, un sistema de inteligencia artificial se construye slo con . r.
:,-:~. ':,',?r\E
ttna vaga nocin sobre cmo debera ttabajar. : El proceso', seguido para el desarrollo ele estos fic:
sistemas se ha denominado '\.l.esarrol!o exploratorio". . : ,_:
Este proceso se opone a la-ingeniera del softw<i.re tradicional , en la cual, avanzamos Jando
pasos bien definidos y tratamos de producir un diseo comple.lo antes de pasar a la codificacin.
Estos desarrollos han dado origen a nuevas tcnicas para el trato de las especificacioJles,
verificacin, y razomunier!to en prescencia de la incertidumbre. Otras tcnicas aportadas por la
inteligencia artificial incluyen el uso de la lgica tanto en las especificaciones de soft,ivare co1~10
en los lenguajes de programacin.
. .. ..r ~-
La orientacin lgica parece llenar el espa~io entre la especificacin y la implementacin
Clevando el nivel de los lenguajes de implementacin. La propuesta. lgica para la espe~ificacin y
'. ,
la progr'ainac'.. tarnbi1i hn sido Hamada declarativa. La idea es declarar las especificaciones o
requerimientos en lugar de especificarlas de una maneia procedural : la escripcn tleclarativn
ser entonces ejecutable. Los lenguajes ele programacin lgicos tnles como el PROLOG nos
ayudan a seguir esta metodologa.
Las tcnic~s ele la ingeniera del soflware han sido empicadas en !os nuevos sisLe1nas de
inteligencia artificial, por ejemplo en los. s.istemas expertos. Estos sistemas esln modularhados, .
con una clara separacin enlre los hechos "conocidos".. por el sistema experto y las reglas usadas .
por el sistema para proc,~sar los hechos - por ejemplo,' una
regla para decidir, ,el curso de una' .
accin. Esta separacin ha permitido ostruir y coin~rcializar "mdulos ele sisterr1as expertos" que. .. ;
_... incluyen slo as reglas. El usuario puede integrar el mcl\llo a la aplicacin e su inters inclicumlo ~ .
los hechQs especficos a considerar. La idea e:; que d usuario provea la experiet~cia general sobre la 1
aplicacin, y el mdulo aporte los principios generales sobre cmo aplicar la experiencia a , ':<!
.~ ........ cualquier problema. . . .
-_:;.,'; ..' . :: ....:.:.. ~::.... ., .. ... Ei1..:-a. ,jnterscc:-~i~n d~ la ... !~gen!cr.t~r:.Ael . sp(t_y,i_a,re c<;>n la "inteligencia artificial .~~ esl . ,
(;J.:< .:.:_::.::~:.:-:.~~(o.<Juciep~{::~ii~ cl~e:}_i.~r.?nte\:c~~i:;.~iibisr~;::.:s.:. ~_sta1~:.. aplic_a_nd~::,:t6cni~as :de la inteligencia -; !.. . '
() :'' . :. . : rtificial ,pa1. J~1ejor'ai-'.tares propias de la. in.geniera :del 'sofl'\.;~~~e~. Por jern.plci, se estn -~/: : (
tf~:. . . .. ~. :d~sar.rollando i ,asistent~s. d .progr~i11at'i9h.'; l~: que. actan. corno'
:~iesor~s: dd .:)rogr~~nador,::_:/_::::--_.:;:/t
~ . .. :.: ..:.: ;.. .coi1t;:~ !a11d~::~~~ruct un~.~:_de: progra111~i.~.~i / . . {eq~ff.1ij}l"~t?s. dh sis te~ a .. tal~s .:" sistei1 tes" han. sido ?/:;:::~'':t':i~:;
1

.!
.~ ;0...:~: /~,:,'. : . \./ ,: ~:::h~~:,#.~t,~:t:~~t;;::~~~:~S~~!At~f~F~;),:\1?! prueba del software desniJOIIado, es. de.ci~ f:'J::r~[ij/if
0

. : .! , ';. L3.:1n{~ligenci< l:dificial f'u.i3::.P.tH?F'in:~~:Ii/i,i_i~t~i-~.el.prob!ema de la genemsin de interT;1ses 1

:
'-~'. . : para usuafios'inexpcrL_o~, a. travs d~Ll.lM~.;.?~J;I~nguje i1~tural. Los modelos cognoscitivos [l.ieron
C ..' . usados tambin para modelar ai us~ario_l':,E~t.?s.frabajos han ejercido mucha inDucncia en e! rea
1
e, .. . ; del diseo de inlerfascs de usuario de Ja'.i'iigfiileda de!sofhvare. (\':-\ /
,.1 /
:
: ':: ; . . . .. . .'. . . : , .';~(_;: :.~~.~~-.t,:\;1_:,;'.!/f.~~,::\'\ . :_.!..~. :. . . . .1! ; .. / .

~ t_., :;<:~ ~: ': : ':' ..:.> :~ ' '.:::- :. '....

.. ,

\ (j:~ . ... ~.
 . . .
.; . .. .,. :. i~~~;: {
~~ 1.
1'
1.5.5 i\'lo<.lelos tericos '
. '.. :
La teora de la cieqcia de la computacin ha desarrollado una cantidad de modelos que son'' . . . :...~ r.}: ~'
henamientas de gran utilidad para la ingeniera del software. Por ejemplo, las mquinas de estado
finito han servido tanto como base pala tcnicas de es:;ecificaciones de software C<?mo para
modelos de di.sei1o y estru.crura.. Los protocolo? de comunicaciones y los analizadores de kriguajes'
han us~do mquinas de estado finito ~omo modelos de procsamiento. .. .
Tambin se han usac~o autrr,tas "pushduvvn" por ejemplo, para especificaciones
oper~ttivas de los sistemas y para. la constntc~in de procesauores para tales especificacio~1es. Cabe '!'
{~-
sealar que los autmatas 'pushdovm". surgieron de los . intentos pr:icticos para construir.
~--~ . 'J. ' :

analizad::Hes y compiladores pam los lenguajes de programacin..

. Otro aporte de la teora de .la ciencia de la c~mputacin al campo de la ingeniera del'
. 1
software son la redes de Petri, de las cuales tendremos mucho que decir en el captulo 5, Si bien .. ;:-
las redes de Petri fueron usadas riginariamentc para modelar sislemas de hardware, en los aos
rccicntt:s se las ha comcnz.ado a aplicar al modelado del softv,:are. En la actualidad son objeto d~
un estudio intensivo por parte de las organizaciones de investigaci~)n en ingcnicria del software. :~-:

Como otro ejemplo se puede citar la seinntica' denotacional (deriotatiorml) - um;: teoda
matemtica desarrollada para la descripcin deJa senu\ntic::(de los lengU~CS ue programaciil-',.
Est<1 ha sido la fuente de cles~.r::ollos recientes en d ;:-ea de.
lenguajes de especificacin.
l.::t illgenicra del sofl.,vare tambin ha ejercido su. influencia en la teora de la ciencia de la
compul~tci0n Las cspccific;,:::iane:; <elgebruicas y la teora de los tipos abstractos de datos fueron
algunos J._; los resultados. Tar:.-~bin c.n el rea ciclas especificaciones, la ingeniera del software se 1
1
lia coJJccntrado en teoras ta:cs como la. lgica temporal (no de primer orden). Los l~rico~ s.1itn !
1
prestar ms atencin nJns teorins de primer ordn qu~ al;:.::; de ordcri superior porque si bici.l las dos
eran cquivatcntcs en pGder, las teorins de prime; orde;~ ~:mn ms simples desde el punto de vista
matemtico. Sin embargo no son tan expresivas como Ja.s teoras de orden superior. A diferencia
dd ltrit:o, d ingeniero Jd sofl \vare esl interesado tanto en el poJer como en la falla de
expresividad ele una teora.. Por ejemplo, el estilo de la lgica tempor::d es
ms naturaly compac''.'
para cspcciricar los requerillli~nlos de w1 sistema concmrente, que el estilo ele las teoras de primer
orden. Adems, las nece~~idadss de la ingeniera del software han encendido el inters de Jos
tericos en tales teoras de c~rckn superior.

1.6 La relacin entre h ing~:.uicr:: del softwal"! y otr:;s tlisciplinas

En las secciones anterimcs examinamos la relacin entre. la ingeniera del software y otros campos
1
de b ci~ncia ele la con;put::.c.in. En esla secc.i6.1, exploramos la m<n:era en que la ingeniera del
sow:m:: se relaciona con 0'.!2.S re<~s fuera deJa cc;1cia de la comDutacin. 1

La ingeniera del. sc~f!warc no se pn:ctica en et vacio. Ha;, muchos probiemas que no son
pwpios de la ingeniera de:. son ware y que h2..n sido rest.:cltos en otros can< pos. tur:;go se adaptar_on
....1 l:1~ soluciones. As, no ky m.:ccsidr,cl d'3- reinvcnlar cada solucin. Por ejemplo, las re::ts de la
) psicolog:t y el diseo indu:;t!iat pueden guio1rnos para desarrollar mejores iulerf;ses Je usuario. .1 !'
)
1.6.1 Cit:ucia de la adiJJillistracin (managcmcnt).
-j
....
j U::ty una gran parte de la i:gcniera del software reiacionada con lemas de aclm.inistrncin. Dicha
::uJministraci1i presenta t.bs a:;pcctos : admini.:,~racin tcnica y administracin de person11l. Las
. _._ .1
l:trca:; cll: cualquier proyecto ndministralivo incluyen en general : la estimacin del proyecto, el
):!\nL~amicnto, organizr,cin ck .iOS r~:cursos ht~!llanos,' descomposicin y asignacin de t8reDs, y
. _/

1 .
1
 ':;;~;7:);,:=-~<: -~::.',::::<< :::-.::~_.:;.;::;:.,: .:~-,-:,-.;. -. .-.,
iir?W.gjsieni.e;.;41.;.;,";.j,:;;.; .;e , ~~~.:.. .

seguimiento del proyecto .. En el aspecto de administracin del personal se incluyen: la

contratacin del personal, la E1olivaciqn de esa gente, y la asignacin de tareas a las' personas
apropiadas.
La ciencia d la ad::nii1istracii1 estudia exactamente todos estos temas. Muchos de los :._ ':' 1
modelos desanollados se pl'~den aplicar a la ingenieria del software. Observando la ciencia de la'
.'
admirstracin podemos apiOvechar los resultados de muchas dcadas de estudio. . 1 .

En la direccin opuesta, la ingeniera del s.oftware le di a la ciencia de la administracin ' ''

_._. :
m: nuev<;> domio donde prb:~r ~-,_,srnode!os y teo"ras adrninis<rativos. Las propuestas Lradiciorialcs .":..

de pruJuccin- [;t... :;~.:-ie nc ~~ t:~~::dtn <iJ.ilic:l..l ;~.- la inj;eniei~a del softvvare, dandO origt!1 ., ra
il~vestigacin de nuevas propuestas.

1~6.2 Ingeniera de sistcm:1s

La ingeniera de sistemas es el rea que se ocupa del estudio de sistemas compiejos. La hiptesis es
que existen cier:t.as leyes que gobiernan el comportq.miento de cualquier sistema complejo formado
por muchas compone11les con relaciones complejas. La ingeniera de sis~emas es til cuando
deseamos coi1ccntrarnos en el sistema y no en sus componentes individuales. La ii1gcnicra '.e. . ;

'/
sistemas trata de descubrir Jos tcfnas comunes que se pueden aplicar a los distintos s.islemas- por. . .:
'',;
} ..

ejemplo, plantas qumicas, edificios y puentes. .

El sofl\.vare genera\;ncete forma parle r:!e un sistema ms grande. Por ejemplo, el sortware .
de un sistema de control de [abicacin o el software de vuelo tk un avin son slo partes de
sistemas ms complicados. Se pucd10:n aplicar l<<S tcni1:as de la ingeniera de sistemas al estudio ele
(iichos sistemas. T!-Hnbin podemos considerar' a un sistema con miles de mdulos _como un sujeto
Tiue ser candidato a la apEcacin de las leyes de la ingeniera de sistemas.. . .'
Por otra parle; la :.ngenicra de sistemas se ha enriquecido expandiendo su coi"\iunto de
moddos de anlisis- tradicionalmente basado~ cr1 las :>l<emticas clsieas- xtra incluir modelos
discretos que se han usado en ln. ingeniera dd softwar:~.
)
1.7 Conclusiones

La. ing-,:licra del softwar~~ es una disciplina emergente. Consiste en la construccin de grandes
_j sistemas ef~.:ctuada po; equipos de programadores. }.-lemos visto la historia de su evolucin:-,
presentado su relacin con otras reas .Y descri plo l'os requisitos ele un ingeniero del software. En . ~ .
.,
1 este libro, estudiaremos l::>s principios que son escenciales para la co1itrucciu del softvvarl! por
medio de.Ia ingenicri<l.

...''
:_:1
,...

. 1

C;

1. \1 ..
.. i . :<-
!"' '
. -: :."' .................. -- -..- ............. -.. :- -'":"
.. ...: ..... ,. - .... : ----- -- ... . ... . . .. .. . :. -:"!--- ,.. _.: .. -~ ..-
.-. --.-
:-:-=;~--~,---
...........................
...... :-~- .. .. .
o';

1 ..........
:~ .-.
:
 . .. . . ..::. .. .. : ;_ . ..... .. _;:
. ;- ..
~.;:.. .

..r~~~~f~~.0:X~tt~ii~::i~~;-:;f~:Jli1~~~~-~;::;~~~;i,,j:;:~:;{:;~c~~L~<f;'t~zj,:;~-:.,:~:!r~,:..~'"'.Ok,, ..~:,,",.....~LSiJi'2:2;~:

)~?~~~~a;::;L natural~za proP~i': y ''-'''

.1
:.:
1 .
1

. ! ,
La meta de cualquier. actividad de ingenien a es constmir algo - un producto. El ingeniero civi.l \ .
c?nst~11yeErnln p~ente, del tn~en.ier? ~erodes pacftwiat construy~' ~t avi~, y .eflt;inge~ieNro electricistda, utn
c 1rcuJlo. 1
proaucto e 1a mgemena e so are es un S.! S ema a e so :ware . o es un. pro uc o, . . , ..
.. :.'''.>:
.; ,
.'

tan tangible como los dem.s, perl? oCleJa de ser-llil pro~~ct?. Y c~Tet:ilafncin:.. . ' ;
En algunos aspecto~. lk.Jllildiili.tos O.wo.ffwa.~:e s~~~ similares a ot~?-~--1~!.<?.~~.::.~?~. -~~
ingeniera, pero en otros son muy diferentes. L::':.5:~E.~~~~~J~.f.i.~;;,_que lJ!~~-~epara alsoftw-r.t_d_e ot[_Q.S '
pr.QQ.~_t:os ~_ing~err-esque-es'/'Zi'Ofe. Podemos modificar el producto con cierta fac.ilitlad -,,. t'i'.

an oporndonosasu-Clis-eiY:J-:::..ES1oli5.ce que el soft\vare sea completame1~te diferente de otras

productos tales como hornos o automviles.
~ : .
A menudo, la maleabilidad del software se usa mal. Si bien es posible modificar un puente
o n avin para que satisfag:m alguna nueva necesidad- por ejemplo, que el puente soporte ms
trnsito o el avin pueda trar1sportar ms carga- dicha modificacin no se toma a la ligera y no se. " '
la aborda sin hacer primero i.m cambio en el diseo y verificar el impacto en toda su extensin. Por . ' :
otra parte mucha.s veces se le pide a los igenieros del software 'que hagan rl10diticaciones a su. . .. :-
..' , . !
'''

trabajo. Dada su maleabilidad, pensamos que el software es fcil de modificar. En la practica, no

lo es. .,
Podremos cambiar el cdig fcilmente con un editor de textos; pero satisfacer la necesidad
... ..: ..1 gue origin el pedido de modificacin no es tan sencillo. Ciertame1te, debemos trntar auoflyr.e
~no cualquier otro produc~~: t?_do c:._~~ebe enfocars~o_~~n c~E~.:bio _:_12__::.!_di~~~C?-1?~~?-9.~~
un cambi_Q__~_!).Ja codificacin, que e.u_ylamcl!J:e ~~J.!lstancia de!_p.r9J:)ucto. Seguramente pockmos
.: .
~~la mal~b!Tid.acC"20~i2.. debemos hacerlo con disciplina.
~

,~
. .. "
;
...... 1

Otra de l,ill>.S-!:~!sti.f_as __e!_~oftwsi~--t::.L.m~-?~S.f.e.~.~-i9r1._~g_~~.2:.e_m~~---~~.t.\~.i_clad_..sie

ing~niera que de fabric:lc~)n. En la mayora de las actividades de la. ingeniera, la fabricacin se
consicleraci:C!auosaTeTire-:Eao que detem1ina el costo final del producto. Tambin es necesario
(~). vigilar el proceso de cerca para evitar. Ji llroduccin de defectos. Las mismas consickracion.;:s se
pueden aplicar a tos prodJctos d_e hardware. Para et software, por otra parte la actividad de
o. fabricacin se limita a un simple proceso de duplicacin. La produccin_de so(~~'!?-X~Jiene ms que
j(:-.
.~~ ver con el diseio LJ_r, i~El~.:'Il~!:~~~~.!:-_3~0on 1a iric.B.\;;n. p-~~eso debe ~ot~ ::-Est-;- -cmpiTr ..
ciertos crrtefiO'S::para ase.guJa.rse l:u?roduccin de software de alta cal1dad. -----
Cual ~.ca...s:L!;x.oSJ.~:-sees !?.~~~:.~~le -~~.i~;g-;~;ig.l:~0a' nec.~_~j-~~-~sl y_ 'tu mpl a 'e o il o S .
est~l.Qil..!J:i>_JJ.tte__ d~fi.1~9J..k~ .. P.IQPi~s!ades qLle debe 12o~~E- Un puente ctunple la ft~ncin de.fi'a'cer
-m~~s fcil el
viaje Je un'punto a olro;illi.""~J'e"fasp~opieJades qw~ se espera que posea, es que no
colapse con el primer vi'~nto fuerle o cuando un gran camin lo atraviese: En la ingeniera
tradicional, el ingeniero li:~ne herramientas pn.ra describir bs propiedades del producto separadas
. de las del disei'.o. En la ingen:ria del software la distincin no es tan clara, todava. A menudo; se. !
1.
entremezclan las propiedades del producto de software con la especificacin de las propi.edades del
diseo. 1 !

En este captulo, ::.;mminare_mos las propiedades pertinentes al producto de soCtware y los

procesos de produccin dd mismo .. Estas propiedades se convertirtm en melas para ta prctica de
la ingeniera del. software. En el prximo captulo, presentaremos lgs nrincit>ios de 'la D,g~ll.:i.f;'J.i.I!.
~software qu~ pueJ!E...<'U2li~~~-~~-.Q;[~~ill17;!~~as l~Jeta~J.Ja prescencia ck cualquier propieJad
debcra tambin ser veri!~cacla y medida. Introduciremos este tpico en la seccin 2.4 y lo.
7studiaremos en el cap.ltu:::. 6.
1 .......

2.1 Clasificacin de las propiedades del software

t;l .
v
... . .! ...
1 .

-: ~ -------.. -- ~-~~:- ... - .. -- --~:- .. ,.-- ..-- ...-... .

~-~ ::.':~-- .. ::
., ....
 ;J. :> '.

Exi~~.... n
muchas propiedades deseables para el softvvare. Algunas se aplican tamo al producto . .
c6;10 al proceso utilizado para producirlo. El usuario quiere que el producto de software sea
confiable, fcil de mantener, po.rtable y e~tensible. El encargado .del proyecto de software quiere
que d proceso de desarrollo de ese software sea productivo y fcil de controlac ;
En esta seccin, consideraremos dos clasificaciGnes distintas las propiedades del de' 1.
1 ..
software : Internas vs. Externas y de Producto vs. de Proceso. . i

. '
2.1.1 Propiedades Iuternns vs. Externas
!.
1
~ . . '
Podemos dividir las propiedades del softwareen l}temas y externas. Las cualidades .externas estn . ::_, 1;
a la vista de los usuarios del sistema; las internas conciernen a los desarroadres del sistema. En .; : ~- ~ ~.'.;....:._

l
~ ~ :

general, a los usuarios del sistema les import<m slo las propiedades externas, pero son Jas
propiedades internas - relacionadas con la estructura dd software - las que ayudan a Jos
desarrolladores a alcanzar las propiedades externas. Por ejemplo, la propiedad . interna de
"verificabilidad" es necesaria para alcanzar la propiedad externa de confiabilidad. En muchos
casos, sin embargo, las propiedaues estn. relacionaJas tan estrechamente, que casi no hay
distincin
'
entre .interna y externa. . ..
1
2.1,2 Propiedades de prod<tcto y de proce.so \
1 : ~::-~ ~~t: ;~t :: ..
:_: . .)

Usamos un pro_9esopara producir un producto de)oftviuie. Podemos. atribuir algunas propic<-i<.k:;

al proceso,
.
aunque a menudc-, estn
.
estrechameD;te
.
r~J~Cionadas con las propiedades del producto.
.. . . . . . 1
Por ejemplo, -~i el proceso requiere w1a planificaciri cuidadosa de w1 sistema de prueba de datos
.1 antes de comezar con el diseilo y el desairo del sistema; la confiabiliqad del producto
aumentar. Algunas propieciades tales como ia diciencia, se aplican tanto at producto corno al
proceso.
En este punto es interesante examinar... la. palabra producto. Generalmente usarnos ese
trmino para referimos a lo qu s~ 'ie-~ntrega al ~lente. Esta es una definicin aceptable desde ~a
perspectiva del cliente, per::> no es la adecuada para el desarroilador, que nece~ita una definicn: .
general del producto de software, que abarque no slo el cdigo objeto y el manual del usuario que \

se entrega al cliente, sin :arnbin, los requerimientos, el cliseo, el. cdigo fuente, los datos de
prueba, etc. Con taldefnicin, todos los artefactos producidos durante el proceso; forman parte del,
' . producto. De hecho, es posibie entregar diferentes subcot~Wltos de un mismo producto a diferentes
,. ...
~

'-:. el ientes.
(~. Por ejemplo, un fabricante de computadoras, podra ve.nder a tma compaa de control de .
( ~:,
procesos, el cdigo objete que ser instalado en un hardware especialtzado con una aplicacin
integrada. Podra vender el cdigo objeto y el n1anual del usuario a los distribuidores de software.
(j ::
Incluso ood.da vender el cdigo fuente a vendedores de software que lo modificarian para elaborar
(3 otro producto. En este :;<:.so, los desarrollado;es del sistema original ven un producto, Jos
r:-::, vendedores de la misma: c:Jmpaia. ven un conjunto de producws relaco_nados y el usuario final.ve
1 '-..J
r:~
<.5)
otro, todos Uiferentes. ... . . . . .. .::.:.:
El manejo de la CO~lfigt:.racin es. la parte' del' proceso de produccin del software que se
relaciona .con el manlen.irniento y contwt de las relaci9nes entre todas las piezas._,de las diferentes
versiones de un producto. Las herramientas para la administracin de la configillacin, pem1'iten el
c:- mantenimiento de familias de productos y sus componentes. Discutiremos la administracin de . :
c~ configuraciones en el capte1lo 7. 1
:.
e_; ! ';.:.
.: C: ~7.;'1.
:~u,
-'ll -
1 1 . -~.

:, u 1

~ ...... _ .. ~--. .-~-:;.; ~ .. :~-. :.----:-:.-. , . ......... --\~-----: ......... -:.p... ~ ...... - .. -.......'
-~ ~ :-.-:-- - -r.! r .:-~ ::::.~:~.~:: ~.,. : ;.,;._.. :~\:::..:
 ; ' ' .
1

''
2.2 Propiedades representativas !
'!
1

En esta seccwn, presentamos las propiedades ms importantes de los procesos y productos de .: ;.

.1 .
software. Donde \o consideramos <\propiado, analizamos las clasificaciones discutidas
} .
anteriomente,
. i . ~ ..
) r: . . i .

.
2.2.1 Correccin,
. . Coiifiabilda.d y Robuste7-
..
. 't\

Los' trminos ,;correccin" ;,c.onfiabiliciad" v "robustez'\ se usan a menudo de manera indistinta,

. ' . =- ,., . . . .

para caracteriz~r una propiedad del softvv"are qve imp!ica que ste realiza todas sus funciones tal
-..1 como se espera. Otras veces estos tnninos son usados por diferentes personas _con distintos,,
..
Sgllificados, pe~o' la teminologia IlO se ha e.st~darizado. Es una lstima: porque es'tos ,trminos'; 1
1

estn relacionados con temas muy importantes. Trataremos de clarificar esos ten1as a continuacin,
no slo porque necesitamos usar una temlino!oga uniforme a lo largo del libro, sin tambin
porque creemos que su aclaracin es necesana para . comprender y ana!iz.ar los signilicaClos ., :J .
subyacentes. 1
:-~~:~f:~-~-
. ~- :
: ,
2.2.1.1 Correcci.n

Un programa es fimcionalme.n! correcto si se comporta de acuerdo a la especificacin de las .

., : ~

funciones que debera proveer (llamadas e:,pecificaciones funcionales de requerimientos). Es ms

co'mun usar el trmino "correcto" que "fw1cionalmente correcto" : asimismo, en este conte:-<.to, el
t~mino "especificaciones" implica "especificaciones funcionales de requerimientos:: Seguiren_1os
es la convencin cuando el c:onlexto est claro.'
La defi.picin de correcciri, supone que se dispone de una.especificacin del sisl6111a )4;91Je
es posible deteriTunar sin a:.nbiguedades si Lm prograni.a cumple o no con ella. Para la mayora de
los sistemas dicha especificacin no existe. ' Si existe alguna, generalmei1le est~:r escrita en un
estilo informal usando el. lenguaje natur~L.Jal especificacin contendr sin duda, muchas
C.'i ambiguedades.' A pesar de ~stas dif!tades con .las espe~ificaciones la definicin de correccin'
() sigue siendo L Claraniente, esta es tw propiedad deseable para los sistemas de software.
La correccin es ur:a propiet.l.2.d matemtica que establece la equivalencia entre el sft~are
. C?-',
y su e?pecificacin. Obvia:nente, podemos ser ms sistemticos y precisos al evaluar la correccin \
() dependiendo .de cun rigurosos seamos al especi.fic::ar ios requerimientos funcionales. Como
() vere!TlOS en el capitufo 6, la correccin; puede evaluarse a travs de una variedad de mtodos, unos
e enfatizan la propuesta exp~rimental (por ej. testeas), y otros enfatizan la propuesta analtica (por ej.
la verificacin formal de la correccin). La correccin. tambin puede mejorarse usando las
( ::\
' ~"
he.ramientas apropiadas 12.les como lenguajes de alto nivel, pat11cularmenete aqueilos cue soportan
e: anlisis esttico extensivc~ Otra manera de m:jorarla es usando algoritmos standard o bibliotecas
.~~ .e::.
./ de mdulos stand::1rd en h.;gar de inventarlos .
ji . '\
!'\:.;)
:e. 2.2.1.2 Confiabilidad. . ....,
. c0 :. ;.'

Informalmente, el softv:are es confiable. ,si,'t~i :~\lSUaro puede confiar' en L La literatura . ::

! C} especializada en con.fiabi.lidad det soft-..va:{~~qp;~:.ii.~.;:;~~n.fiabilidad en trminos de comportamiet~to
. ~-
! l.}
11 _, estadstico - la probabiljdad de que elstt\ihiiC.ftihione
1 . ' ' ~ .':. .. ;: ..
.,. ;". .: ,, . . ' . . ..
como se espera dentro de un intervalo de
~ 1 ...
1 :-.
i l.::> tiempo determinado- . Discutiremos e'sta:piqp0~sta:;~lda seccin 6. 7.2. 1 Para el 'propsito de este
.:! (~: captulo, s<,embargo, la defniin in.forr~a) ;es.'s{rfidente. 1

. ... ! . .,!
: : t.;
: -
 -... .
\

~- ~ : La correccin es una cualidad absoluta: cualquier desviacin .g_eJos. requerimientos, hace

qucls.iSJ:ema.se.a-J.ncorrecto,....c.o...inter.es__cun leveoserf~"Se-~."ct~~!~s:ign;_ --.. -~ .... ...... ------ i ... , . , :~ ~J
. El concepto de confiabilidad es, por otra parte) re!Utivo : si la corisecuencia de Un error Cle ~:
t
J
. . .. J

software no es sena, el software mcorrecro aun puede ser confia~. ---~---:----..- - - - - - - . . . . , :.

. Los pr?ductos ~e la. ingeni~r~ deben ser confiables. Los productos n~ confiables; en ~- . 1 1

. ;:;:~~, 1~~s~~~r:~~~~:~~n::~:ds~a::~.ld~~:;~lm~~~a;~r~6~a~~~::n~e~ 1:o~~~t~~~t~~~~ ~~r~o:e:::: . ) .' . \ .

conoc:-!rhs" rtugs). En general n.o esperamos que nos entreguen un automvil cbn una lisia de ,'.-,r.. .:_ .:_;: - .-~..i.?~:_:;
d~f~ct~s ~ ~ p'..!':';~r,-. cor.. ur.~ ~dvertencia' pora no usar la bar:::da
1,! ....

l !).,, errores: de diseo son o>

extremadamente raros y ocupan l~s titulares de los diario_s,_ Un puente que se 4errumba puede - -' :.,:;~ . 1
incluso llevar a la corte a sus diseadores. .
Por el contrario, los ecores de diseo del ftwme ~o son
tratados a me:nudo como inevitables. :' .. ! f , .:~(i~?:
Lejos de sorprendernos cuando ocurren, en general, los estamos esperando. Mientras que con otros : .,
productos el cliente recibe una garanta de corrfia,bilidad, con el software recibimos una :i
dec~aracin donde se nos dice que el fa:bricaryte no se l~ace responsable por los daos que puedan . :

ocasionar los errores uel producto. La ingeniera .del software podr ser llamada una disciplina tlt: ! '
ingenieria slo cup.ndo el soihvare alcance un.a confiabilidad similar a la de otros pro,ductos .
. . . . : .:. La figura 2.1 ilustra la relacin entre la confiabiliclad y la correccin, bajo el, sup!_.lesto ele
. 'qu~ la especifi~acin de reqtefimientos funciona es contiene todas las propiedades deseables para
la;ap,licacin y ,'que no se h~n especificado:_ errnearneille propiedades no deseables. La figura
. mt~estra que e!': conjunto. de:)os progran1as confiables li-icl_uve al conjunto de los programas
:co'rre:ctos. Desatortunadartie!lt~.:en la pr~cUc.a., la..e.Specifj.c~ci es un modelo de lo que el usuario
:,
:1 ,
.
q~i~re; pero d ':modelo P1J;~de o no,~ ~ser .'~t?a,. . c,t~0n19)~~: _a~ertada de. sus necesidades 'y de los '
1'
1

)
\1-erdaderos requerimie.ntos. Todo lo que eLsoftv;;aie pl.iede hacer es cumplir con los reqUerimientos
dd moqdo - no 'puede as,~g~rar la precisin ~el modelo'~ ~ . ' . . . . . .
~ .
) '
:... .. As, la. figura 2.1 . representa una=. situ~cin' 'idealizada- donde se supone que Jos
. requerimientos son conectes, es decir que son la representacin fiel de lo que la implementacin
/ debe garanlizar para satisfa_:::er las neccsida?.~s..sJel usu~rio. Como se discutir en el capitulo 7, a
... menudo hay obtculos invericibles jjfa alcanzar este. objeti'vo. El resultado es que a veces tenemos .

aplicaciones "correctas" que f~eron d{seadas para requerimientos "incorrectos", por lo que la
:
correccin dd software puede no ser suficiente para garantizar al usuario que dicho software se
!
comporta de la manera esperada. Esta situacin se discute en la siguiente subseccin.
1. . . ' . .

Figura 2.1 Rel~c.in entre correccin y confiabilidad en el 'caso ideal

Reliabili ty = coniabil idad

Correctness = correcciri

. 2.2.1.3 Robustez ; =
',.

''
Un programa. es robusto si se comporta "razonablemente". an en circunstancias que no fueron
anticipadas en la especificaCin de requerimientos- por ejemplo, cuando encuentra tina entrada de .
datos incorrecta o alg\m dispositiv-de hardware fur.ciona mal (ej. un disco)-. Un programa que ... . 1 ,,
supone Wl3. entrada ~ CatOS p~rfecta, generar Ull error irrecuperable en tiempo de ejecucin \,.

cuando el usuario inadvertidamente escriba un comanC!o incorrecto. Este programa no puede ser
considerado robusto. Poc:.ra ser correcto, sin embargo; si la cspecificacitl de requerimi'entos rio.
establece qu acciones e_iecular ati.te la entrada inconecta de un comando. Obviamente, la ro_bustez
es una propiedad diflciLie clefin : despus de todo, s_ pu~irarnos establecer con precisin que

.. :
.. - ......... - ": .. ::-.~ -:-:::.:. ::. :~"- -~ ::..:--- . ''''7 ____ - --. -=~::.'~ .-. ..-:: ...... -:: .- .. _.,-: ;' ..... ...:. :': .. . ';' . .... "1'', '" .'~--- ..
...... _ - - - - . - - o -:-~- - -: ~-- :: --~: : - :-.:;-- :.- ~ .-;1 ~; :: : 1 : :~ : ~:!- --~.
 .'>_.eberamos hacer p~ra que ur~a a.plicacin sea robusta:_tambin podramos definir con exatitud e\ ..
trmino "razonablemente". De este modo la robustez sera equivalente a la correccin (o
confiabilidad en el sentido de la figura 2.1) .. ,, ...
Nuevame~1te la ru1aloga con Los puen~es es instructiva. Dos puentes que conectan ambas
mrgenes de un misrno ro son los dos. "correctos" si ambos satisfacen los requerimientos. '
establecidos .. Sin erpbargo, si durante tma inesperada y torrencial lluvia, tmo se. demunba y el otro
1
no, poJremos Jecir que el segundo es ms robusto'que el primero. Ntese que la lecc in aprendida
con el derrumbe del puente, llevar probablemente a mejorar los requerimientos' para futuros
puentes definiendo la resistencia alas lluvias como un requerimiento para la correccin. En otras
\ . palabras, a medida que el fenmeno bajo estudio se vuelye ms y m ~ conocido nos acercaremos a
\ la propuesta de la:figwa 2.1 .don~e las especificaciones capturan exactamente los requ~ririlienlos "' :i 'Tl. ;>
. \ ....
esperados. . ;. . . . ,. . . . . i
La cantidad de cdigo dedicada a la robustez, depende del rea de aplicacin. Por ejemplo,
un sistema dedicado a usuarios poco experimentados cle\:,cr estar ms preparado para manejar
entradas de datos incorrectas, que un sistema integrado qe recibe su entrada de un sinsor.; sin
embargo, si el ~istema integrado est contro[anJo el transbordador espacial o algn Jispositivo
crticp para la vida, es aconsejn.ble disear una robustez extra.
: :. En conclusin, podemos ver que la robustez, y la correccin estn fuertemente relacionadas,
s\n q~e ha~.a una c.lara ~,nea de separacin. e~:re e!las. Si po~emos un requerimiento- en la
~ficacwn, su ejecucwn aporta a la correccwn; Sl no lo mcluunos, puede pasar a ser un tema
de robuste:JLa fronteraentre las dos proptedades es la especificacin del sistema. Finalm.ente, la . i

....confiabilidad aparece, porque no todos los comportamientos incorrectos generan serios problemas~
alguno.s comportamientos incorrectos pueden tolerarse tranquilamente. . ..
. Correccin, robustez y confiabilidad tambin se aplican al proceso de produccion .,.del 1' . . ~
.1
soflware.~n prOceso es robu~;to, por eje_~plo, si _Puede acomo~ars.e a~bios .no anticipaJos ... ' 1

del entorno, tales. como un~ nueva verston del ststema operatiVO o la transferencta brusca ele la i
mitad de los empleados a ofrr:yficina. ~ceso es coliable st cooduce en forma consistente ~ ~
1
~eracin de p;oduc~os._t:_ alta ~~dad ..ll;,n.m.':lc~ms di~ciplinas de la ingeniera, se dedica un_a
buepa parte de las mvesttgact::mes para d descubmmento de procesos confiables.
' . .

2.2.2 Perfonnance

i_.' Se espera que cualquier producto de ingeniera cumpla. con LU1 cierto nivel de performance. A
1 ': diferencia de otras discipli:oas, en la ingeniera deL software ~para petfarmance c.on _
L.:.. eficiencia. Aqw tambin seg-.1iremos esa pri~ctica. Un sis~ema de software es ebctente si utiliza los
"
'
.. recursosae la computacin, econmicamente. . . .
. ''
La perfonnance e~. i.mportante porque afecta la "usabilidad " del sistema. Si un sistema es
J muy lento, se reduce la productividad de los ustmrios posiblemente hasta el ptmto de no satisfacer
'
i~ sus necesidades. Si un sistema usa mucho espacio en disco, puede resultar muy cara su ejecucin.
L.
Si un sistema 'usa mucha memoria, puede afectar otras aplicaciones que corren. en el mismo

~~
equipo, o pued~ ejecutarse con mucha lentitud mientras el sistemq; operativo trata de balahcyar la
asignacin de la memoria c[,tre las distintas aplicaciones.
Subyacente en. todos estos ejt:iplos- y es lo que dificulta el terna de la eficiencia- estn los
r'
i~ cambiantes lmites de la eficiencia a. medida que la tecnologa cambia. Nuestro enfoque ele lo que
~ .. ) es. "Jemasiado caro" sufr:~ w1 constante cambio a medida que los avances de la tecnologia
~ - extienden sus lmites. Las computadoras ele hoy son muchsimo menos costosas que las de hace
r:
: _1
algunos aos, y significativamente ms poderosas.
,.
''\'
1
l-' . .
. .,
L/.,,
.. >- :
' _, .
.. '
/
.
...__ : . .

. ... ..... ~ . ... . . .~:.-.::.::.. .-.~;:~:~: ~:. . :. :~:. ,;~:..'.'::.~~::_~_~::.. : :.--~~-~:::~:~--~=:.. . .~-- --... --.. - ..

1' '
-.. r-..r;:-: .. ,.,;-~--:-.. :~-:t .
_;~-~\ - ,:.;;_.... , ' 1
.',,.,,,:;;":::;
..
 . ,

1
.1.
i
l
i'
. '
-
.
. 1

1!
' 1'

i.
) ~.

' .'

'.l
1

.1
::.

'_,
.
(~

u
C)
o
()

,
() Se dice que un sistema de soft.vare es nniigable con el usuario si los usuarios. humanos lo
encuentra~ fcil de usar:. Esta definicin refleja la. nnl11r2.ieza subjetiva de la amigabilidad con el , ....
o .. ,r'' .
u
(:; -~,
 ;.'-.-
. :.-::.

.1- ~ ~s_ua~io. Una apli~acin usada por un prograzi:ador.novato, deber poseer cienas ~uadades que ' .
sern distintas de las que tendr una aplicacin que usar un programador experto. Por ejemplo, el > .. . '
P rin<;ipiante aprecia Jos mensa.ies de ayuda mientras que el usuario experimentado. los detesta y :
ti~nde a ignorarlos. pet mism modo un.no-programador valorar el uso de menes,_mientras qu .. 1 .
1

. un programador se sent~r ms :::modo e'scribiendo Jos comanqos. . o '. ' ; ;

. ; ~a inte~~~se con el usuarioes una parte ~portan-te de Ja amigabilidad con e~ usuario. ~n ::- .. , .:--,~,- ,
s 1st~ma Je software que s~ prese~t~ como_ un.. s. tstema d~ ventanas y_un mouse, sera mucho m~~-.-.,,:- .. , !:<J
amrgable que uno que ex.Jge c:scnbtr comanq9~ fonnados_por U[1a letra. Por otra parte un usuano . . :. , :'.i l .'

experimentado preferir uri conjW1to de comandos que minimicen la escritura en el teClado a 'una "'- : :,;_:~
bonita interfase de ventanas que lo obligue a navegar hasta encontrar ui1 comando del cual ya . ... ~- ;.
conoc~ la sintaxis. Discutiremos los temas sobre ia.inrerfase con e.l usuario en el captulo 9. i" .-:;: :,, )_ 1,/:' _
Hay algo ms que la in:erfase con el usuario para de fin ir la amigabilidad con el usuario. .. . . ,, H
Por ejemplo, en un sistema irr:.egrado con el hardv.are no hay una interfase c.on los hwnanos. En su .. i
Jugar, d sistema interacta con el hardware y probablemen_te con otros sistemas de software; la i
amigabilidad con el usuao se refleja en estos casos en la facilidad con que. estos sistemas pueden .
) . ser configurados y adaptados al ambiente Jel hanlware. . ' ,_,:~~ t\;
En general, ja amigub.ilidad con el usuario de un sistema depende de la consistencia de las .. , ' ! '
interfases con ~~ oper'ador y con el usuario .. Claramente, las propiedades men_cionadas . .1, :_ .:
anteriom1ente ~ tales como ::orrccin y performance .. tambin afectan la amigabilidad con el
-.....
usuario. Un sistema que produce r~spuestas con errores r:to es amigable, por ms boriita.que sea su
_}'
interfase con el usuario. As tambin, un sistema que ent:r:ega las respuesta ms lentamente de lo ,
que requiere et usuario, no e~:: amigable, an cua..r1do las respuestas se muestren en colores.
'").
j,;i
La amigabilidad con el usuario tambin se discute en trminos de "factores humanos".. Los
factores hwnanos o la ingeniera humana, juegan tU1 papel muy iinportante en muchas disciplin~s
:--, de la ingeniera. por ejemplo, los fabricantes t.le automviles dec.l,ican un importante esfuerzei a"l<l
determi!Jacin. del lugar _que ocupo.r:ln los control~ en el tn.blero. Los fabricantes de televjsores y
hornos de microondas tambin tratan de hacer que sus productos sean fciles de usar.. Las
decisiones sobre la ,inlerfa,se con el usuaru;:_;J ~stos _campos clsicos de la ingeniera, no son
tomadas al a:z~r, sino luego de mir1'd?sos estudios sobre las actitudes y necesidades de! usuario,
realizados por especialistas en campos tales corno el dis~o industrial y la psicolg(}.
Es interesante notar que la facilidad de uso en muchas de estas disciplinas de la ingeniera,
se alcanza gracias a la estandarizaci?n de la interfase humana. Una vez que el usuario sabe como 1 ! ..
utilizar el televisor, pocli~ operar casr cualqujer televiso_r. . 1
La importancia de la investigacin y la actividad de desarrollo que se es.t llevando a cabo
en la actualidad en el rea de la estandarizacin de la interfase con el usuario para los sistemas de
~oftwa.re, conducir a siste:nas_ ms amigables en el futuro ..

Ejercido.
i .
------------------------------------------------------------------------------------------------------------------
' . ; 1.

2.1 Discuta la relacin entre los aspectos de 1a interfase hur.i1ana del s.oftware con la.
confiabilidad.
.
... ...
_;' :-: .,, . . .
!

_
:r \._;'
:,:.o.
......
e,
2.2.4 Verificabilidad :~~~~~~~~~t~!~tt!t
Un sistema de software es verificable si;~~s-jjrppi~cl~.l~s se pueden verificar con facilidad.' Por
.
ejemplo, la coneccin () la performance" _de \~n sistema
son propiedades que sera i11teresante' .. ;
'

,' '1-~~;.
:

' \:_./ ':. .\')( :~

r, 1. ( -- . :: ,.
:)c; '-...
 ;,.::.:-..-.
.
1
.
.. 1 ",:.. .,

~:~ ~;i:~;;z~<;~;..~~,:-:=: =--~ ~" . - .-..;....-... ..
~ ;<;;:_-.~,.---~:~-:~ :>::~::-~::
.. ..

t@ ~-~rifi~r.: Como veremos en el captulo 6, se puede. efectuar la verificacin ya sea mediante . ._::t!.:"_', .. -~'.'
. n1todos de anlisis formales, o bien a travs de testeos. Uria tcnica comn para mejorar la . !. ~
ve1ifiabilidad, es elllso de "monitores de software", es decir, cdigo insertado en el soft\vare que :. . /- 1
monirorea varias propiedades tales como performance y correccin. :. .
.. El diseo modular, las prcticas disciplinadas de codificacin y el us~ de un lenguaje d~ l
programacin adecua<;io, contribuyen a. la verificabilidad. , .1. ' . i

La verifcabi!dau es generalmente una propiedaJ interna, aunque a veces se convierte en . .

;J1.1a Dm?iednd e-;-rterna tarnbin. Por ejemplo, en muchas nplicaiones criticas. de seguridad, el :... J-~. ;{ J
cliente requiere 1~ vericabilidad dr cil:'rtns !)rop;,_r~ades~ E!' ms <d[o nive.: de 1 S~f:'.'Jidad st~nd~rd Y::\ .::!
para un "sistema de. cpmputacin ~ofiable" requiere ~~~ verificabiiiciad <..i.~.l kernel e.{ ststema : .
oper~tivo. . ,, " . :':
1
!
2.2.5 Mantenibilidad 1
. !
: .
El trmino "mantenimiento del software" se usa generalmente para referirse a las modificaciones
que se hacen luego de que ei s~stema ha sido liberado. Salia verse al mantenimiento simplemente
corno una "correccin de errores" y fu penoso descubrir que se invirti tanto esfuerzo pa.ra
corregir defectos.i Los estudios demostraron, sin embargo, que la mayoria del tiempo dedicado al
mantenimiento, 's~ -~~up en realidad, para mejorar ~1 prodcto con propiedades que no estaban en .. \

las especificac.ioll.es: orig.nales o que fueron mal definidas. ':

"Mantenii:niento" no es, por cierto, 'el t{tino adecuado para utilizar con el sr~rtware.
Pril11ero, como, se lo utiii~a' hoy, el t~1i~~o inblye uri amplio rango de actividades, todas
relacionadas con la modifc~9in de. alguna p;:ut~~ de~ .~oftware existente, para mejorar) o. Un
L~nnino que, qtizs, capfura mejor la. escencia ,de: este proceso es "evolucin del software". . '
Segundo, en otros productos de la ingeniera tales coino computadoras, automviles, y lavarropas,
el "mantenimiento" se refiere a \a conservacin del producto en respuesta al deterioro gradual de
las partes debido al uso prclongado. Por ejemplo, pr~ridica.mente se cambian las correas d~
transmisin y. se limpian l9s filtros. Usar !?.-... p.~l~bm "m3:ntenimientci" para el sciflware, da una
cormotacin errnea dado e Le er soft~vare no se gasta. Desafortumidamente,. sin embargo, el
. ; . ::J .,
trmino est tan arraigado qut~ continuaremos usandolo. . ' .. 1 ~

Hay pruebas de que los costos de mantenim~into del software exceden el 60 % del G:osto ' .. .:~ ::. --~;: ;
. .
:": .

totaL Para a...'1alizar los factor::;s que afectan tales costos, es habitual dividir el mantenimiento del.
software en tres categoras: mantenimiento correctivo, c::laprivo, y perfectivo. .
El mantenimiento correctivo tiene que ver con la remocin de los errores residuales
presentes en el producto cuando fu liberado, as como tambin los errores introducidos en ~~
software durante su mantwi:nie:nto. El mantenimiento corree ti vo representa W1 20.,.% del total de
los <;estos de mantenimiento.
Lm?:pte!~!.!!.i.e.nt?.~..<:\~p_!._i_~~-L-P.&r~~i,~o son ias vercl_.a.de~~- fuentes del ~mb.io._e_!l el
.. 1'
software : ellos motivarmi la introduccin de la "evolutiv-idad" (defl..D.da ms. abajo) como una
;' propiedad fundam't;~ta.i'~fci-;:ftware y de 1~ "anticipacin del cam5o" (definid<!. en el cap~~do 3) ':.
como un principio general qu~ d~bera guiar al ingeniero del software. El mantenm iento adaptivo
'. . . .,

representa aproximadamente: otro 20 % del costo tolal de mantenimiento mientras que ms del . 50

.,
% es absorbido por el malltCilill.e!ltO perfectivo. . .. . .
El mantenimiento adaptivo consiste en el ajuste ~e la aplicacin a los cambios Jel entomo,
. .
.;:
i
':},
;)
por ej. una nueva \rersin del hardvare, o del sistem operativo, o una nueva base de datos. En
'
\
otras palabras, en el mantenimiento adaptivo la riecesidadde efectuar cambios en el soft_ware no
puede ~tribuirse al software en s, tales como la prescencia. de errores residuales o la
, 7\.: >"' .
el_..- /
..
! ; ---!

~,
 ;~~~;~;;1~-~~;~,,~:~~,:~~~::.~:.~~~t,:i~:,.fw:.-;;:~:. . -~..
/ ' l :.::~ac-;,C:~'d'j.:'.c. -,..,_.., ----~~~.-~,.,~2...__.________ ____:;;_-.

-~l-: ;mp~s;bilidad deel~roveer alg;~,dfuncionalid~d ~~q,::iid:r.of el usu~rio Mas bien, el softwar d~be >- .. , ;
:,. . cambiar porque ambiente en cual est iiurierso; cambt, -:: . . . . .. ! .. ..
\
..
''
. : Finalmente!' el manteni::11i~nto perfectivo consiste en_ la modificain del software para ! ._: _,_ _:. 1
mejorar algtma d sus propiedades. Aq~i los cambios se deben a la necesidad de modificar las . . 1 . 1,
funciones que ofrece !a aplicacin, agregar nuevas funcione~, mejorar. la performance ele la '~ \ .. : l
aplicacin, hacerla fcil de usar, 'etc. Los pedidos para rerJizar uri mantenimiento perfectivo ' :,_J::; . . 1 :
pueden provenir directamente del ingeniero del software con la intencin de mejorar la posicin. ..
del producto en el mercado,. o pueden venir del cliente, par~ satisfacer un nueyo requerimiento.
Veremos la mantenibilidad como dps propied~des .por sepanido : reparabilidad y .,
. evolutividad. .
1 La diferencia entre reparabilidad y evolutividad no siempre es cl<!-'ra. Por ejemplo, si ias ;t'
especificaciones de requerimientos son vagas, puede no quedar cl~ro si estamos corrigiendo un
defecto o satisfaciendo un nuevo requerimiento. Discutiremos este punto, ms adelante eri. el
captulo 7. E~ general, sin ernbargo, es de ~tilida:d diferenciar las dos propiedades.
1' .:

2.2.5.1 Reparabilidad
.. ;1

Un sistema de soflware es reparable si admite la cor:reccn de sus defectos usando una ...
limitada cantidad de trabajo. En m!.1chos productos de ingeniera, la reparabilidad es una
)
. importante meta de disei'io. Por qemplo, los motores: de los automviles: se constryen con Jas
partes que ms pu~den fallar, ubicadas en h1s_parres ms accesibles. En la ingeniera dd hard\vare
hay una subespeciaiidad llamada (RAS) : Reparabiliclad. Disponibilidad y Serviceabilidad.
) En otros campos de In ingeuicra, a medida que el costo de Lll1 producto disminuye, y que el
_) producto alcanza el status de bien Je consumo, 1a necesidad -de reparabilidaJ, disminuye: se hace
ms barato reemplazar el ob~;eto en su totalidad, o al menos la mayor cantidad de sus partes, gue
repararlo. Por ejemplo, en los primeros televisores, se reempbzaba una lmpara, ahora se
,) reemplaza el tablero comp[el::l.
De hecho, es w1a t~c.nica comn, p~r.a...;J,Jcanzar_la reparabilidad en tales productos, . usar
partes standard que sean f,;irrtent''r.emplazab!e~. Pero l~s partes del .software no se deterioran.
De esta manera, mientras qt:.c d uso de partes standard puede reducir el costo de produccin del
J
software, el cQnceplo de pmles reemplazables parece no poder aplicarse a su repatabilioa~. El
)
.. software tambin es diferente en ese aspe;cto dado que el costo est detenninado no por partes
) tangibles, sin por una actividad humana de diseo. .
La repambilicbd tambin se ve afectada por la cantidad de partes de un producto. Por
... ejemplo, es ms dificil reparar un defecto en el motor de un automvil construido corno una pie-la
nica, que si estuviera co1~1 puesto por varias piezas con- diferentes formas y tamai)os. En este
J..
ltimo caso pocl.riamos reemplazar una nica parte ms .facilmente que' el ri1otor completo. Por
supuesto, si el motor estuv:iera formado por muchas partes seria necesaria una gran cantidad de i
1
(j conexion~s entre ellas; lle::ando a la probabilidad lk: que esas conexiones tambin necesitaran
() re pn rars e.
o Una situacin anillog2. puede aplicnrse al sofhvare: un producto de sofhvare que consiste de
mdulos bien diseados, es inucho ms f:icil de revisar y repamr que uno monoltico. Sin embargo,
o aumentar la cantidad de mdulos, nhar ms reparable el producto. Debemos eleRr la estructura _!
()
de mdulos 'correcta C::>fl }a~ interfases. de mdulos. adecu.adas para reducir }~ 1ecesidad de. ;
o conexiones entre mdulos. Lu modulari?..acin acertada promueve la reparabilid.ad permitiendo '
. () limitar los errores a unos pocos mdulos, haciendo ms fcil su ubicacin y correccin. En el
u captulo 4, examinaremo~; varias tcnicas de modularizacin, incluyendo el ocullamiento t.le
o informacin y los tipos abstractos de datos, er.. detalle
1 'lJ~i ..
( :-.
_ ........ ' {
. .. ,t ':'(..':~ . :
u /.;- . .t .;,. ,:

-.
1

. ;:.:;-.:?
,1 . .

C..
.. ' \ .
. .. . ... .. .... ,..., .. -. -::: :: .:;.--.. :;. :;.:: ..e:::;.;:;:.:.:".:; ;: :::~:;.;::::::::.: ~ ,:. -~~';:::' .,,:;::,::;e:;:- ::)
 ... -. . .. - -
~-

. i

-~ . La reparabilidad puede r:1ejorarse con el_ uso de las. herramien.tas adecuadas.. Por ejemp).o, '_
'' '
. _ - usar Wl lenguaje de alto nivel en lugar de un asserp.bler,. conduce a una mejor reparab\lidad. 1,

. Tambi~n herramientas tales como "ciebuggers" pueden ayudar a aislar y reparar errores. i!.
. 1
- _bt~12.~@id.ag__~_un producto af~cta su confiabilidad._ A m~dida gue la necesidad de .,
reparabilidad decrece, la c..Qll[iabilidad aum~nta. .
----
2.2.5.2 Evolutividad
. . .
_ _
:
. - -

;_ :.: i
1

i. J

Al igual que otros productos de ingeniera, e! software se. m{;diiica a rn-:d\da au~- o::1sa el tiempo,
'
. pc.ra: agregarle nuevas funciones o carnbiar .funciones existentes. Dadv que e: ;._,~,_,.~-:;_,~ e::. l~n
~. 1 ., !
,
\
1
maleable, se hace muy fcil ap!icru- las modificaciones a una implemntacin. Sin embrgo, existe . !
Wla grall diferencia entre modificar SOftware O modificar cualquier otro producto de la ingeniera ..,, .. '
En el caso de los. otros producto.s, la modificain comien.,.:a en el nivel de diseo, y luego ;:ontina '.
1
con la implemeptacin. Por ejemplo, . si se deGide c.onstmir lln nuevo piso en una casa. habr que . '

_ hacer primero un estudio de factibilidad para ver si es segura la construccin. Luego habr qi.11~ ;
1
: i ;
hacer un diseo basado en el diseo original de lh casa. Luego deber aprobarse el diseio
verificando que no viole las normas existentes. Y, finalmen-te se encararla construccin de esta
. i: i .. . :
nueva parte.
. '
.
.. 1 ._:__._, :
En el caso del soft'rvare,' desafortunadamente; raramente se procede en una forma tan ' . i
ordc.1ada. A!J. cuando el caqiio en la ~plicacin puede ser radical, muy a mei1udu se conienza
con)~ impleme_n~acin sin)incer, un e~tHdio de _fapt~~ilid~d, sin solamente el cambio en el diseo
origimil. Peor an, cuando ~e cc;)mpleta la modifi~a~in, ni siquiera se la documenta a posteriori; es
decir que no S~- actualizan la's. e!'pecficaciones_ 1 p~n( qi.te. ref1ej~n el carnbio. Esto hace que los
futuros cambi_os sean cada ve-z ms dificiles de aplicar.
. Por ot~~ parte, los pi-~du~tos ele software exitosos tienen larga vida. Su primera versin es .el
inicio de esa larga vida y c\cia sucesiva versi,n, representa el paso siguiente en la evo1ticiri del
sistema. Si el software fu diseado con cuiuauo. y cada motlilicacin se hace cuiJaJosamenle,
evotucionu.ri airosamente.:.... . . . __ .: -~---:.~ ... _... , . .
. A medida que crecen el 'costo de la p'roduccin de software y la complejidad de las '"-l.l
) aplicaciones, la evolutividad adquie;c cada vez ms_ importancia. Una de las razones es la
necesidad de impulsar l2. ilwersin hecha eri el soflware a medida que la tecnologa del hardvvare
avanza. Algw1os de los primeros sistemas desanollados en Jos aos '60 aprovechan hoy las ventajas
_
dd nuevo hardware, dispositivos y tecnologas de red. Tal es. el caso del sistema de reservas de
American Airlines SABRE,. desarrollado iniialmente_ a mediados de los '60, y que sigue
evolucionando con nueva funcionalidad. Esta es una hazaa sorprendente, considerando las
\" crecientes demandas de perfonnance sobre el sistema. : .
Muchos sistemas de. sofn,'are comienzn.Ii siendo evolutivos, pero luego de aiios de
:evolucin, alc~an llll estado en el cua~ cualquier gran ni.odficacin, corre el riesgo de "quebrar"
'1
1"

las C>iracteristicas existentes. .

De hecho, la evolu::ividad se alcanza mediante la modulariza.cn, y tos cambios suces1vos
.:...:.:.
-.....
tienden a reducir modulariciad ctel sistema onginal. Esto es ari peor s las modificaciones se
aplican sin ha~er un cuidadoso estudio del djseo o-riginal y sin w1a precisa descripcii1 de los
cambios tanto en el diseo como en la -~spcc.ificacin dt~ requelimientos. .
l) Los estudios de gr?.ndes sisten1as de software demuestran que la evolutvidad disminuye .. :.
1_ ' :
con cada nueva versin dd producto. Cada n:ueva versin complica la estructura del software, de
manera que hace ms dificiles las L'utum.s modifcaciones. Para evitar este pro?.Jema, el Jiseo
inicial del producto as como cada uno de los cambios sucesivos, debe'r. hacers pensando en la - i
evolutividad. Esta es una de las propiedades ms importantes del softvvare y los prii1cipios que;
"'/' \ ; . 1

_:-~//,:
( :'
'--.

u ... : ..
' . .' !
~e-
 .;;;:~~\-:,.'.- :.-:- ._ -. . ' . . . . ..., .. ,, .. '''.:- :-;.:- .

~-.:W~~i+~W;:i;,~~~;;;rr~i:::~',~-~;;~~;~A.:;.,:;;:;:~:.::;;:-.~:~~,~:.:$,:;,s:}];~~~iE~~2;,~~~3:2::~'-~~:t;.:~:~:~~-,~r!::::~-tiEEJt'J. :=;;.~J:
,. : : 1
_--.~ p~esentamos en el proxuno capitulo ayudarn a conseguirla. en el c;:~pttulo
4 se presentan -~ '. ~ /

conceptos especiales, tales como el de familia de programas, propuesto exactamente para fomentar ! ; .'
la evolutividad. t- : i
1 1 :- i
La evolutividad es tanto una propiedad del producto como tambin del proceso. En este 1 '
1
ltimo caso, el pro ceso deber poder. acomodarse a las nuevas tcnicas de direccin y . 1 ., -l ;
organizacin, cambios en la ingeniera, etc. :. -:: ;: 01- ::;
.'' .i . 1 ic
,.,_
2.2.6. Reusabilidad
. <,_ ,. i:,
La r.eusabilidad est relacionada con la evolutividad:.... tn la evolucin d~ un producto,_ lo ~ i ~.
modlticamos para obtener una nueva versin del, inismo;--sr ioreusainos,-ro-estamos'U:_sai1Cio-~- 2'
quiis-Ori-pocos cam6tos- para constrwr otro pro~areusabilid~d parece ser ms aplicable a .1j .-.~ ~.:; ._: -:.;.!il 1..
los componentes del soft\-Vare que al producto en SU totalidad; pero S es posible CO!lStruir 1 . . .,:~~ ll .
productos que sean reusables. 1 i .. ; -. ;~ 1
Un buen ejer11plo de un producto reLisable es el shelr de U1'-IJX. El shell de tJNlX ~s n
' ' .. : 1
_,_
intrprete tlel lenguaje <le cornantlos~ es Jecir, acepta comandos del usuario y los ejecuta. Pero esta :~ j 1
diseado para ser usado tanto en fonna interactiva como "batch". La posibilidad de comenzar un . ' . ':i -:
nuevo shell con un archivo que contenga una lista de comandos, nos pe:mlite escribir programas - . :_ ; 1

scripts- en el lenguaje de co1e1andos de.! shell. Podemosvcr ese programa como un nuevo 'p-roducto . 11
!
que usa el shell como un componente. Alentando las intrfases standard, el ambiente UNlX de
::_. .-:
hecho, soporta el reuso de walcuiera de ss comandos as co111o tambin el reuso del shell, '
,

creando poderosos utilitarios .

!l 1

1 ',.''!
,: ;
La bibliotecas cientEcas son los componentes reusables ms conocidos. Durante aos han
exi~tido varias grandes bibliotecas FORTRA.t"t. Los usarios pueden compradas y usadas para
. . .~ .
desarrollar sus propios prc-ductos, sin tener que re-inventar o re-codificar algoritmo-s bien
: -
conocidos. Existen varias compafras dedicadas a producir so~rrmente dichas bibliotecas.
Otro ejemplo exitoso de paquetes reusables, es el desarrollo reciente del entorno de
programacin Windows, ~on sistemas tal~~-s_omo X _windows o Motif, para el desan-ollo de
interfases de usuario. Los disutiiiiics.en el capitulo 9. .
,....
i Desafortunadamente, a pesar d que la reusabilidad est considerada como una herramienta
importante para r~ducir d costo de. de.san-ollo del software, en la prctica hay pocos ejemplos de ' ,.
reutilizacin del software.
'Es dificil alcanzar lz: reusabilidad a posteriori, adems se deberia pensar en ella cuancl? se
desarrollan los componentes del software. En Jos pr);imos dos captulos, examinarem-os algunos \.

principios y tcnicas para alcanzarla. Ui1a de ias tcnicas ms promisorias es el uso del disei1o
orientado a objetos que puede wliftcat las propit~dades de ex;oJmividad y r:eusabilidad.
. . . !{asta aqu, hetn)S discutido la reusabilidad en el marco de ios componentes reusables,
._,.
p~rO' el concepto tiene rna aplicacin ms amplia : pt:ede ocu..rrir que en diferentes niveles afecte
C:~;l tanto' al producto como al proceso. Una prctica de reusabilidad simple y muy difundida es la
,() reutilizacin de la genl;e; por ej. reutilizamos- su
conocimiento especico del dominio de un
it!J aplicacin, 1.m desarrollo, l!.n objetivo, etc. Este nivel-de reutilizacin es poco satisfactorio, en parte
ln, por la rotacin de los ingeniero;; dd software: e~ conocimiento se va con la persona que lo posee y

'-:3.
no llega a ser nunca una posesin pi:nanente. . :
10 Otro nivel de reutilizacin puede ocurrir en e!
nivel de los requernmentos. Cuando se
! -~ .
JU concibe una nueva apli.;;nc.in, podemos tratar de identificar partes que son parecidas a otras panes
k} usadas en aplicaciones previas . .r\s podremos reutilizar esas partes. de la especificacin de
e~, requerimientos efectuada _;m:viat111':nte en lugar de des~wollar una c01ripletarnente n.ueva.
.
e: ..
1
~ .

C:
 '

; ~ :~ .: : . Tal como .lo discutimos antes, puede haber ms niveles de reutilizacin cuand() se diseii~ <: :: l
una aplicacin o an en el nivel de codificacin. Muchos expertos en software afinnan hoy que en : .' .;.: ;':~+'[
d futuro, se producirn nuevas aplicaciones ensamblando conjuntos de cornponentes construidas ., ~
con ~tei-ioridad a ese efecto. Las compaf?.las de software invertirn en el desarrollo de 'sus propios : '? ~
catlogos de compobef).te~ reusables de modo tal que el conocimiento adquirido- al desarrollar . e..:: 1
aplicaciones, no desaparecer a medida que la gente. se vaya, sin que se ac~ular ' ., _; f
:...... progresivamenle ~n sus catlogos. Otras compaas invertirn en la prouuccin generalizada de. : 1 i': !!
. coniponentes reusables, que pomlril en el n::ercado para que las usen otros productores de , , :.o.! . _;~:'

., . sofnvar~a reus?-bilidad se'aplica tambin a.losJJ~v~es~'s.:D~~echo, h variedad de metodl~ga: ce ::;;r . ~~J~~~~;

software existentes puede verse como el intento' de reutilizar el mismo proceso para la . , . .'_ r;;:,(
construccin de diferentes productos. La variedad de triodelos del ciclo d.e vida, intenta tambin/ . .. : i!i. :;{:J
reutilizar procesos de tvel superior. Otro ejemplo de reusabilidad de un proceso es la propuesta ' ;
de "replay" para el ~ntenimi~o del software. E,n esta propuesta, se repite el proceso completo
cada vez que se hace tma modificacin. Es decir, primero se modifican los requerimientos, y tl:lego
se s_iguen los pasos que se J.efnierori Jurante d desarrollo inicial tlel prouucto. En el-captulo 7 se
dan' ms detalles sobre este tema. :.. . .
. ' ~.

' ; La reus~bilidad es un factor clave que caiacteriza la madurez del rea industriaL. Vei11os (:):-;
altos grados de. reusabilidad en reas tfm rnadur~s 'corno la .i.ndustria automotriz y la electrnica de
consumo.' Por~jemplo, en:];~' iridust.ria automotriz;. el inotor se reutiliza de modelo en modelo.
. .,

Adems un a:uto,mvl se S;~mstruye,n1edia!lte ,el- ~p.~~~~l;>la?p de muchos coniponentes altamente

estandarizados y usados a a'ls de ni~chofmodelos producidos por la misma industria.. . .
:.. . 1 ,. : ' . . :; ' . :
El bajo grado de reusabilidad del soflwar es i.111a iridicacn clara de que debe evolucionar
hasta alcanzar
. '
el estado de. L!r:,a biGn definida d.iscipliria
.. i . . .
de .la ingeniera.
)
Ejercicio
)
2.2 Discuta cmo la reusa'qilidad puede afec;rar.. .la confiabi_lid.ad de ios productos
~ . . ... .. ... . . .
------------------------------------~--------------------------------------------------------------------~ ----------------

2.2.7 Portabilidad ,_.

El software es poitable si ~:s posible ejecutarlo en difcreptes ambientes. El tnnino. "ambiente"

~). pucd~ referirse ta.nto a una plataforma de hardware como a un ambiente de software tal como un
..
;.-~

sistema operativo en pm~icular. Con la proliferacin de diferentes procesadores y sistemas

'"
operativos, la portabilidad s:: ha co:wenido cti u.n tema muy importante para los ingnieros cld
software.
An dentro de una n~isma fa:nilia de p~ocesadores, [a portabilidad puede ser importante
o debido a las vanacones en la capaCidad de memoria y a las instrucciones adicionales. Una manera
o de conseguir la portabilidaci dentro de una determinada arquitectura, es hacer que el sistema asuma
o
1
una configuracin m1Ilim_a en lo couccrnknte a la capacidadcre memoria y ''que utilice un
':.
. .
0 subconiunlo de recursos_gy~ se sab~~ est~rn disponibles en todos Jos modelos de la arquitectura . .. . ;
(tales como instrucciones de mquina y recursos del sistema operativo). Pero esto perjudica a los:. :::) >
o modelos ms g1anJes porc_ue el sistema podra operar mejor en estos equipos si no se utilizaran
:0
1 , ... requisitos tan restlictivos. E~ por eso que necesitamos usar tcnicas que permitan que el soft1-vare
- detennine las capacidades o:~:;! sistema y se adpa_te a ellas. Un buen ejemplo de esta propuesta es la.
ll?.
\.....; manera en que UN'IX pe;:mite a Jos prosrramas interactuar con muchas terminales distintas sin
h.J suposi~tanes explcitas en los programas acerca de las terminales que estn usando. El sistema X '. -~,
' 1 .,:,

!t . ;'
1 e : )'"
...

1().
1C
'l
 '~~
,, ... i.
)'.~
. Wind~ws extiend~ esta capaddad para permiti~ q~e las ~p~icaciones se ejecuten sobre cualquie~ l .
\

mapa de bits. . .
.:
. i
.Ms generalmente, la portabilidad se refiere a la posibilidad de ejecutar un sistema en .l
distirtas platafonna.S,de har~wnrc. A medida que <1Umenta la proporcin de dinero que se gasta en
software comparada con el gasto:J en hard\vare, la portabilidad adquiere mayor importancia. ...
1-

Algunos sistemas de: software son inherentemente especficos para una mquina. Por
ejemplo, un sistema operativ~ i::st escrito p;Lra controlar una mquina especfica., y un cot~lpilador
tambin produce cdigo para una mquina determinaJa. An en estos casos, sin embargo, es
. posible alcanzar alg!). nivel de portabilidad. Nuevamente U1'fL'X es un. ejemplo de un sistema
.
'
1

'~' ';~t
.',

operativo que ha sido transportado a muchos sistemas de hardware diferentes. Por supuesto, el 1
. 1.
esfuezo para transportarlo requiere meses de trabajo. Todava podemos llamarlo portable ya que si .,,
tuviramos que escribirlo desde cero, seria mucho ms complicado. . .
Para muchas aplicacincs, es muy in1pottante que sean transportables a travs de los
sistemas operativos. o, mirndolo de otra fonna, el sistema operativo proporciona la portabilidad . i,
. ~.
a travs de las pla.~aformas de :1ardware. . ~ :
., .;
?~. ': i .
.' ;
. -
-------------------------~--------------------------------------------------------------------------------------------------
.
2.3 . Discuta la portabilidad como un caso especjal ?e reusabi1idad .
----------------~---~------------------------=------------~---~~------------------------------------------------------------ : ..._

2.2.8 Comprensibilidad ( ... de comprensin)

Algunos sistemas de sofhvare. son ms comprensibles qtie otros. Por supuesto, algunas tareas sn
ms complejas que otras. Por ejemplo, un sistema que calcula el pronstico del tiempo, no-
irnporta lo bien escrito que est 1 ser ms dificil de comprender qu uno que imprime un mailing ...
Dadas dos tareas con utt ru1~:mo nivel de dificultad, P)demos seguir ciertas pautas para producir
diseos y programas ms c.r;nnprensiblcs. . . .
' La comorensibilidad
. -es i..ia oropiedad
.' interna del producto, y ayuda a conseguir otras
propiedades tales como evoltltividad y verificabilidad. Desde el punto de vista externo, el usuario
,1
considera que el sistema es comprensible s tiene un comportamiento predecible. La
comprensibilidad externa es un componente de la mnig::cbilidad .
.:.i.

2.2.9 Iuteropcratibilidad ( ... de interoperatividad) ,. . ~

_,_;

La interoperatibilidad se refiere a la habilidad de un sistema pma coexistir y cooperar con otros

sist,emas- por ej. un proces2.dor de textos tiene la habilidad para incorporar un diagrama producido
por un paquete grfico, o el paquete grfico tcpe la habilidad de graficar los datos producidos pbr
w1a plauilla de clculo,. o la planilla de clculo tiene la habilidad de procesar una imagen
"'
_j} escaneada.
-.
.. ) Si bien es raro en les productos de software, la in~eroperatibilidad ri'bunda. en otros
;
prouuctos de igcnicra. Po;: cjenr,Jlo, los sistemas streo de diferentes fabricantes trabajan juntos y i
1

pueden conectarse a televisores y. grabadoras. De hecho los sistemas stre~ producidos hace 1

d~cadas, se acomodaron a tecnologas como las dd compact disc, mientras que virtualmente todos
los si~temas operativos de:)r:':n ser modificados - a veces de m~nera significativa - antes de que
puedan leer los nuevos discos pticos .
. Una vez ms, el ambiente UNIX, con sus interfases staudard, ofrece un ejemplo [imitado .1 1
. ...
de interoperatibiiidad dei:.tro de un nico ambiente: UNIX alienta el disefo de aplicaciones que

\) 7
. .
'J-
.
\) 1
. ~~ / ..
.,
e
. .. j ....... -
 !-------~
.:.-<:: .

:. ;erl~an u~a interf~e simple stondard, pe;m;;.\u~Ja salida de una aPlicacin pued. Ser usada
como la entrada de otra.
que
. . 1
n}:t'f'! ,: ~ ,.
El ejemplo de UNDC; tambin ilustra.las limitaciones de la interoperatibilid~d en los ..:. .L: .;>~ r:-
ambientes actuales : ,la interfa:=;e standard de UNDC es primitiva y orientada al caracter. No resulta :. , . , 1 '

~~~j~E/!f~~;:~:~~J:::.::;~S:~r~;:::::~ce~:~~~~~ ~~o:n"~tn;i~~~~n:~:;~~:~e;a;~~ .~:. ~. ~.: ~.'_! ~. !~.

':]!.,...:.:.. .... .
_,.
_ ,.: .

...... :. Otros ejemplos de bs limitaciones de la interope~atibilidad en. el software actual, se . . : ..

. pU::::;t~~l er.co:1tr~~ er~ !s sisi.ern.as de t6n1put~tdorc.s' pei-son_ales. Mucho~ v~ndedores fabrican ;,::(! : : -.~~-!- ;: -
productos "integrados", alegando que dic~os productos poseen .una variedad de f:..;;::c.:io;es. Con una . : :~ , . ;,;; r~
mejor interoperatibilidad, el fabricante" podra prqduc distintos productos y pennitir que el ./:!i'~ .~~;~(':
usuario los combine si lo considera necesario .. Esto haria que los produc'to.s fueran ms f~i1es de t : . ,;,, :'/;.
' >
.vender, y k dalia al. usuario ms libertad para 'elegir las fw1ciones que desea combinar. De hecho, : ) .. ',.
en muchos casos, el vendedor del "producto integrado" tambin tiene productos independientes, ; ."
.. cada. uno. para. una ftmcin determinada, perq 'estos productos no trabnjnn juntos. Se pue.de . ! ..'. :.: l
conseguir la ir!leroperatibilidatl a travs de la estandarizacin de las interfases: "', " ' . '
. ,Un cori.~epto relacionado con intero.peratibilid::'.d es el de sistema abierto. Un sistema '>:;(;;~;~/)
abierto es Wla; c_oleccin extensible de ap!icacione's independientes que coopern para funcionar
. como un sistema integrado. Un sistema abiertq perinite el agregado de nuevas funcionalidades
provistas por organizacioLes independientes, iuego de qu el sistema ha sido liberado. Esto pttede !
conseguirse liberando el, sistema jUIO COn u,na especificacin de SUS interfases "abiertas".
Cualquier. desarrollador derplicacioncs .podr saca( partido de esas interfases. AJgunas de esas .. ' :. ': i
interfases se. pueden usar para la comuni~~cin ~nt're 'a1stintas aplicaciones o sistemas. Los
...
~
1
.
.i .. sislemI~ abiertos pemten que diferentes aplicaciones escritas ,por diferentes organizaciones, '
. puedatnteropera'r. . .
Un requisito interesante de los sisteinas abiertos es que se puede agregar una nueva
fw1cionalidad sin clesconec.t~'.r el sistema. Un sistema. abierto es similar a una organizacin . ;;
..

creciente que evoluciona ~!1 l tiempo, adaP.!~P_s)._ose a los cambios dd ambiente. La importancia de
la interoperatibilidad ha provocdo" un inters creciente en los sistemas abiertos, produciendo
algunos esfuerzos de eslm)dariz'acin en este rea. . .

Ejercicio .:

-: . .
Discuta la relacin enl.re e~tolutividacl y sistemas abiertos
i
2.4
.\ -----------------------------------------------------------------------------------------------------------------------------
.'.
;
2.2.1 O Productividad \

La produclivi~ad es un::1. prGpiedad del poccso .de. produccin del software; mide la eficiencia del
.,
.....: pr~ceso y, como dijimo; cates, r:s la propiedad de per.~ormance aplicada los procesos. Un proceso

~
. eficiente hace que el produ:::to se libere rpidamente. . '.,

)
ltidivldualmente lo:. ingenieros producen software a un determinado ritmo,' si blen hay-
;. grandes variaciones entre iEdividuos con diferentes habilidades. Cuando los indiv1duos son parle ,:: ,, ..
.'
-' de w1 equipo, la productividad del equipo es en pan~ una funcin de la productividad de los
individuos. Muy a menu.Jo, la productividad combinada es ffiLtcho menor que la suma de las
. ~ .'

--' partes. Las tcnicas y or?;:;.n.izacicnes de procesos son intentos ele capitalizar la productividad
individual de los miembros de Jos :!quipos.
.. ;. .

. 1 .....
 .=::_'' -.,:, . -~-

~~~,~~~~~~:~~{;~fSS::~~~~:~
~\~ ,,:f:\.n~f.L'a P!OdUftiv'i~ad ofr~~:e ~11~cha_s; C?mbi~a_ci_8n~~~;;f.ri"t~,el~cci~~ de_ Pr,~-cesos .. Por::~jemplo/~:t\;!.~~Yf .. : -- n1
. . un proceso que reqmere especmllzacton d~ algunos m1embros del eqlilpo, puede al:ill.1entar la:_-o,-,c;~,i".:""
<-;.;::: :: prod~ctividad ep. la fabricae;in_ de w1 detenninadci producto, pero nci en! a produccin 'de una)J;f,g :;{f,/
: -:;:~l'.<;_._varie~ad de pro.ductos~ La tcnica de re~tilizaGtn del_ softtvre_ es w1a tcni~a que amenti, ID. {f!,f,,, 'i~ ~l
. ' ~. : ' . ' 1 . . ... ' ' . -

. :_:;:r/:-';:: P:9~~~tivida~. general -~~. U~la crganiz.aci~ :q~e:: se dedica. a_-. pioducir. muc??S. pr:o?.l!S~~~~;/ p~~Y. ~\z:~i~!
. . 1''' ~ . .

:; ,; ......

.)/'.. desarrollar modulas reutllJzables es mas compbcado que des~rrollar modulas parael propw:uso;.-'-'"'' 1
,::1~/'..: :-- ~n.i9.he$ :ia prQd~c.~iyidad de(grupo qu~ lo$ e~sJ~;:~~~arr.o~pdo ,S,e've~ tlisiT1i[lui~~- . -~j;~~@.~~~{tr;;~~{.
. :: . . ,: Si bien la productividad es de gran intet~s.: d~bi_do.~l c9st6 crecienie:_gel..~oft\v~~~';:'es:dificir
de medir.. Claran:iente, necesitamos una mtri;a''para. medir la
.produetividacl:_"~ ctia_fqu{r-fot'af: o.
... propiedad - si te~emos alguna esperanza de pode.~ comparar difere~te:s p~~c'~s~s en 'f~if.o'~-~e:::\.~.. ,. __ "''" ._ g
productividad. Las' viejas mtricas tales conq la cantidad de lfneas de c?igci producidas tienen ;:>';\.);;:~}[;.'~~;:; '1-~:s:W'
muchos defectos: _En el captulo 8, discutiremos mtricas para la medicin de la productividad y'_\-~);;,,_:;:~',. , ,:}.
, . . - . . ' :-:... ~ ,':o~. _, - ;. ..:-/;_!::.;!' Ct)

organiz~cio~1es ~e equipo para 1\1ejorar!a .. Como ~rt otra~ discipli~as de la !ng~~iera,y~:f~p;~s _q~e '-:::.:.f:J~~;.-,~1; . ,-~(
la eficencm del proceso, esta fuertemente afectada por . la, automat~:zac10n .. Las r modemas ,. ;.' :;~;;_:.r,J:~!Nt;'}
h~mamientas 4e la inger:ti_~rb~ dei software conducen a- tm aumnto de l~_ .rroduc~iy~d,,~~:_.Es.ia_s .:<:\~:!:1:,~;:~~_{:~~-~:i,'
_, .
. herram1entas . . en ,.. l caprtu
se d'lSCUtJran . 1o 9 . ,_ . . _.,- . .-. '' . .. ---:'+ ''< ,, '!;l!~. ?''"""~~';'
"' ,,,_.,:.lh1';' ... ,,.r;,:;l~.l~''"~jji~r.~''';\'' 1
~
' .
-'.

,.... , .
~~~~--~~-~~--------~-~-,~4~-----=-----::;r:
copo.
_ ::"tll,~l~~~
2.~ Evale criticamente la cs.ntidad de lneas de cdigo medida de la productiyidad <,.-;.-, \:;2 {?' r.: ', ~.-~.:_ .~ :~.\, .;
. (Este tema ser analiz~do en profw1d_idad en el ca1)~t~~p:,8) . : . . . :.\~:.!::.i_;:.:<.::_i;~(.;,c,~ .
-----------------------------------------------------~~-~---------------;_:-+~-----------~-------.-------~-:;~~~~~-~:--e-~~_:_:_ e';:,':. !&[~

~::,~;o::::::n~::n:!i::::~ee::: relacionada c~l habil!d;rit;;'1~r~~~>

........
' ~ .;
1 .,.
.
;. -~..
el prodUcto, que consiste en la
entregar ese producto en el tiempo estipulado. Histricamente, la oportunidad ha fallado siempre ;..:'HL~irJ~'i--~'Sh/
en los proceSOS de prod'.!C~i:?~ del SOf~ware,..desembocando en ta "crisis del software", que a S~ vez::::;-.~~#.~;~;~~{;';ii,1~;;:'.
gener la necesidad de crear la ingeni~da del software. An ahora, muchos procesos. fallan: a,; la;f~~~'~:F:}~:%.~N.b.i:
hora de entregar el producto a tiempo. ._ . .. .: ;: _ -'> i-h>j~~:H;;T:;;:it!1i[~;.r
El siguiente ejemplo (real) caracteriza la Pfctica industrial en la actualidad. (circa 1988): ::';::-?'Jrl':ni}'1;i)t;'t
Un fabricante de computadoras prometi la primera versin del compilador .A.QA para una' )_!:,;)::::f::;(~.';
d~terminada fecha. Cuand:J lleg el da, el. cliente qu~ lo haba solicitado reCibi. en lugar ,~el;~'/;;:~{~!(:-;~,;;}}
producto, Uila carta diciendo que, dado que el producto todava contena muchos defectos> d ')29t;:~~'~i{Hs!+:
fabricante .haba decidido :Jue sera mejorpostergr la entreiza antes que entregar. el producto en -~-~~-;~t;:M;\~;ji;):
esas condiciones. La fechE -se po$terg tres meses. . - _ ' " . ; ,_;:;;~:hW:\~~f#:1,t
1 ,. ~- , A los cuatro meses! el pr-~ducto lleg, jnto con tma_ carta que deca que se haban corregido -:::::t:::_-_~i.~}if::,
. ,__.;,:
muchos, pero no todos los defectos. En ese momento el fabricante decidi que era n1ejor qe los;~i:.':.'_;,/~:~:::(~:n::
clientes recibieran el compilador ADA, an ctando tuv1ese serios defe~tos, para qu'e as p-udie5~n-~:t;~j;;~;L;t.:}{tt
comenzar a desarrollar su::: propios productos usando .tillA. El valor de una entrega' tiempo pes i:/J:':;(j\\~:)1:') a
ms. para este fabricante,. que el costo de_ haber entre.gado un proucto defectuo~?:: Por lo que,.;;;~i.~:;,0[',:}:i~i?,::.
finalmente el producto qu:~ se entreg lleg tarde y con defectos. . . ' .. ., . . _, -:,_.::>::}ii:::::::i;:
La oportunidad en s no es u~1a propiedad tiL Aunque llegar tMde puede_ hac~rnos pel:cle;~~MWWJr;.
posibilidades en el merca:io. Entregar a tiempo un producto que adolece de otras propiedades, taleS!:~';:[!i;[~iM~r~t
como confiabilidad o per::ormance, es intiL _. . ; :.}~;p:~::;(~ (
. . . . .. ; 'H~- -~~-~.:~; ~ .:r

La oportunidad requiere un planeamiento cuidadoso! una estimacin del trabajo acertnd~,fi::/;:-':.':~- :'-.-,
. punces de controi clara~:r1entc especificad?s y .vel'i.fic.abks. Todas ID.s otras disciplinas de' la:.~,;~::;;~,>.>: .
. . . ~::t_\)_;~;:;;)}i~~~:r~~~-; ;:
 :f;::.::.;;::~. :.:> :-:..:..;.. .-.. . ..: .
~~~-.. -:_. _,...._.. -._\>-.::,~:s:-::

.~~ :~i;eni i~ ~ti! iZa~ tcnicas standard para

de contro"t de procesos implementadas para computadoras ..
conttold~
proyectOs, Hay inel o u; :1~~:;~:~~t~).,~:;
>'

: . Estas tcnicas standard son difciles de ~plicar en la ingeniera del software, debido a; ( 1) la ...
dificultad pam medir la cantidad de trabajo requerida para producir una determinada pieza de . :: ,;: .'
' . . . .
software, (2) la dificult~d para medir la productividad de los ingenieros y (3) el uso de puntos de "~
. : .. ~?ntrol impreci~os y poco verificables. . , ... ... .- .: _:: . . ,: . : , :':i!i;,; :. > .
<' :. . :'. Otra razn para consegu:r la. oportunid(.l.q_ell. el prqcesodel software,.esel,.contriuo. ~ambio
; :~ . . in _l~s requerimf~~t;s del usa::io. La figum ~~~'.'co~1p~r~. 19~\i~quepmi~~to{\~il us~iHJtE~ar
,i;: ._c~p~cidade~ reale~ ciel sisteti:.a y mue~tra porq~ f~ll.2ll !a l11ayod~ ~~e ~osi~tlia~~s d~ja'rro_llos'cte! ,
,',' . ; '_softyv~re. . . . .. , . . . :i;;;:;:i .:::,, ' ... : .;:~;::...,, .:. . . :. .. !~:}::~ .,. :;.,.:;.;\ '. :; .-;
:.~:.: (Las unidades de. ~~cala no se muestran, pero se supone que soii. umformes).:En el moirierito t-0 se
<:. . .. '. .' . , '' . :. :-i.};:::;~ . : -~-. :: .. : --;_~--~-- ~-\{t .i:: ::<~ .' :-, . :. - -~.::.:,::~-~;\;, .. '::.J.~~~i f:fty .::;;!-:.\ ~ ;::~
...

:reconoce la necesidad de un sistema Qe softWare: y cqmlenza' ~l)iesarrollo'-'cori un,cogoclf[uept

bastante incompleto de los requ~rimientos~ Como ~esi.tlt~do, d ''prodct' irliciai knt~e'gri'ci(?;~rn::~i~
. mogl.ento t-1, .no satisface ni J ::ls requc:.rimierttos iniciales del in omento t-0, ni los requinlientos
. '. . . ~el usuario en d r1;1omento t-l. Entr~ los m<nnento~ t., 1> y ; t), el producto se .:'mant{e,ne:::pa ' ,.
'i''.'i ' ajustarlo a las Mc;;esidades d,el usuario. Evenn1.~Iment~,i ooinigEt. c~n los-.r~_querini.ient_~s,;,~~hm! :
del.usuario en el momento t-2. Por Jas razon_e~ que. hemos -visto en 1a>seccin:2.2-,5.
'' e ,'/, ' O o ,. ' ' ' ' '~~.. ', ~ l ;:
'':-:-~ !,,;:l' '

momento
. . . . .' '
t-3, ;'.s:l
. l'l'. ....
costo
'
de . mantenimiento
. . .. . . ..
es:)an_,
. . ,.... ,.._,
alto que:~\ 1 . ;:
desar~ollador
. . j 1 . 1
..
decide.:; h.a .... -
' ,;
.
. ' ; ~ ...,l.1 ' - ,. ~-. :.

importante re~~-~~fo. La ~u~Y :versiri e~.t disponibl~.'-~h el:)Iiiento t-4 pr6 b sepafac(n de las .
. necesidades del':ustiario 'en}ste punto, es' mayor que ari.tes: .. : . . . ' ;.,~;(~; ;;,:-_ .
.1.: . : if::; . ..-v;~.: ~ .~ ::. .. . .. ,. . :',ir . . . J ., .. . . ;. = .
Figura2.2- Las falencias en la "oporturiidad~' .. ctel software. (De Davis (1988)) :,:;:
.;.\:.~ :.~,~_;:;.-,. ::.,.~?:1t;::ff.i.;::.;. i.:::
1

1. . Fw1cin; . . . ;. .
-~- 2;.~ Necesidades del uSuario . ~\-'_ . ~ i:-.: :._.::.. ; .---

3.- Capacidades reales del sist.ei:na: '::,

4- Tiempo . . ,

. Una tcnica para '~i.:a~cir'."la: opb~t~~Id~d, es:a.,.travs de t:ntregas incremenla!es:_ . dd

!' producto. Esta tcnica se i~.ustra en el siguiente ejemplo: de la entrega del compllaoor ADA
efectuada por.otra compafia (real), diferente de.l<i. que s-~ describi con anterioridad. . .
Esta c~mpaflla entreg - !nuy tentprano :. wi cotl1pllad.or qi..le soportaba un subconjunto ttl. .
pequeo del lenguaje AD/\. Bsicamente era. equivalent~ a un Pa~al: con ."paq1.1.etes" .. E
cqmpilador no soportaba n:.glma de las nuev.as caractersticas del lenguaje' tales como el man' .
ti~ lare~s y ~xcepciones. El resultado de es la entrega adebintada fu un prod~cto confiable.: Como : .
consecuencia los usuario~; comenzaron a experimentar con. et nuevo lenguaje.yla cornpai.a c.ont . ,._~.,, ... ,. .,..,,,",
c~n: ms tiempf? para comprender las sutilezas de las nuevas caractersticas de ADA.. Despu~~ de_-.:- '
varias entregas que se prolongaron a lo largo. de dos aos, se termin un cornpila1or ADN/
...
.--! completo . > :: . : ~~- .. , .. 1 : ;o;",,;'.'\: ;0-' >. , . ' : .;
,...,
:J L~s .entregas incr;.b1entales pex~iten que ~1 pt~du~t~: es~ disp~ibl~ .antes; y el 'is~rde/;'..,..,.;. . .,.,,.,_,_
.,..,
1 producto aYl;tda a refinarlos requerimientos.tambi~1 de rria~a-incrementa( : '
. . Fuera' del campo 'd~.. la ng~nieria del software, ..UD:, .. ejemplo clsico de la dificltad .
tratar :::on los requerimientos de sistemas 'c~mp!ejo's;. los sisterrias de rumas ri-iodeinas.:: son
. varios casos muy publicila.cios, l~ armas ya. eraa obsoleta::; cuando fueron enlregdas; . ,,, .....
,..
. satisfacan los requerimientos, o en ~n'Jchos casos arriba.scosas. Pero despus de diez ai.os: de.::
L'' desarrollo,. es
inuy dificil decic!.ir qu6 hacer con, Wl producto que no satisface Ltn requerimie.rrto.; ..
establecido diez aos ::;trs. El problema est exac~rbcdd por el hecho de que e~ estos. casos)cis\

e ' . i; .. . . .. ' . . . . . . . .. .. l.i, t~i ~:l~j) ;.: . '"""'"''"'"l<'i?

(-: .-: :-: - '

... ; ... - .
 .. :~-~-P - ~-:_: ~. : ~--. -~~;- ... f.: ; . .. .~ .... . . .. . . -;.; . .

ff~~.-."~~.~~~.t$~.---;~,;;~&a~~'S>>f:,~;;;.~-;:;'4~;a:r.Zli~t..~:~;:~~,~#'~~-tii;.s0,;~8c..~i;;,;-..~.->~.~=.-"""~w-~;"'~~... , ..,... ,..,:c"',~~-.-.. <.

- ~ -
o:~~~ .;-.~

\. -~ requ~rimientos deben apuntar al mejor sistema posible al momento de la entrega y .no; en el . ~

momento en que St? definen los :-equerimientos. ' ' ;, ,: .. .."
Obviamente, la entrega increrri~ntal d~pel1de de la habilidad para dividir el COl~ unto de .
funciones del si$terna erl subconjuntos que puedan ser entregados por incrementos. Si no es'posible ..
def~ir ciichos sl;><;:onjuntos, no existir ~n pr9.ceso que pueda poner. el prducto disponib,le po:
~ntre:g~s. Atm c~ando se pqedan identificarl.e~ :s~tbconjUil;ts, s el proceso. que, los ,tF~~aL~o: ~~.
in~rein~~~l:tampoco. se podr~ hac~r una e~~~~,~f:;,i~c/.~~71-~Pt:~~ri~f.oportuni?~~}e al~~~.~-~~?..;~(~.~ ..
pue9~ dtvldtr yl prod~cto en SUIJCOnjuntos Y. ~~!W~fp~.yp,~PFR,2~-~9:,~pcrel11e,I1!,a\:A;,, . i~;t1.\fN!.~~:~~};J: .
La entrega 'mcrementa[. de SUbC()HJ~~~ps,;':.,}_llt1t~!es;:.;:P9r' surue~tO;;~o tl~n~_-:_ \.~l~r;;:l
oport~Jl,id;;td deb~ ~ombinar~e ~on otras protn.<?,?:id~.~,: 9~1 so ft;x~_fe: El capi~lo 4 verep1os: mue h.
tc~ca~ pr?: ol?!ener subconj:.mtos d~l pr99,~~to;?_y'e1_ ~apitill, 7,, discutir :las t~cnfc~sTp~ra._.
pro~esos experimentales. . .: }.~~:/~3 ~- '::::~:~NYt' .:~ , :. ~;,., i..:;:~f~f:nrr.~;::~. ~_:
. . .:: :._ "::-":tt:: ..
2.2 ..12 Visibilidad -~ '<\ ..' . . . ;~ ;_: . . .. . .-!:~'-L~;: .... ;:}\firJd{i1;.~ ,;,/ .
. '!. UP;: proqeso de d_esarrollo de soft,vare es r.t~i(J[.e _si tod~t;_s}f.~ pa~os. ~~,.;~~~~do 't,yal '. y:
doc;.um~nt<,~-dos ~op clarida~l. El t:mino ,que.: descril::l~ inej6f.: ,esta prpi~d~O.::es Ja .
glas~sr,
.
Otros.
.t.
tn;nos son transparen~ia: .- .
Y .~-pe.rtui:a.
,.. . . ' '.
L'a.~~ide~('es
~,.,
. ::l" :. ; -. =
q~~:Jo~~:;;r~~;
, . ~~
y e
&"
es
).~... :
. ~ . , . '

proyy~to esttJ;W9-iponibles y son fcilmente accesibles desde"afuenl'Nrap9der.$~r exarpimi'dos ..

: En mi.~chos proyectos, la_ mayora ;'de los ingenieros e i'ncluso:1os administradore .
de~cohocen el estado exacto en que se encuentra el proyecto. Algunos pueden est~r'd[s~fi~1'do .
~\ otr~s codificando, y algunos haciendo pruebas, todos al mismo Liempo. Esto, en s mist~o, no es , .
malo. Sin embargo, si un ingeniero comienza a' redisear la mayor parte del cdigo jlisto en el,'.;_:
!Tiomento en que se supone que se integrar ese cdigo para tma prueba, correr es riesgo el~
padecerseriosproblemasydcmoras. ':_:.. .. . f' ,,,t>,r>' '' _.. . . ... . . ._.;. .. . .. ,,-,;~:).L,J .. .....~:..
..... ,. ,,._.......... ' <',;
La visibilidad penni te: a los ingenieros sopesar el impacto de sus acciones y as las gul. en.
la toma de decisiones. Penni~e que los miembros de un equipotrabajen n l: misn1a~ire.cciri,' en:
lugar de hacerlo, como e~_bastame rrecuet~~~<_:::.n direcciones cruzadas. El ejemplo mtts'comw1 de .
e~ta ltima situacin,es, corn'o se' Inncon antes, cuando un grupo ha estado hacierid_o.,un test de, , ..
integracin de una versin del sof1ware suponiendo que en la prxima versin habr, pocos:.'.
defectos que corregir y lendr muy pocas diferencias con la. presente; mientras que :al mismo '.
tiempo un ingeniero decide hacer un gran rediseo para co1Te'gir un defecto menor. Es ~oni.n que . .
. . h.ya tensin dentro de un grupo que est tratando de estabilizar el software mientras que.: otra . . .
p~rsona o grupo io esta desestabilizando de una. manera no intencional, por sJ.pesto. El p . '
d~be alentar una visin cons~slente de las reales metas entre los participantes. . ..
La. visibilidad no es::lo una propiedad interna, tambin es extefJ!a. Durante el curso 'de, un.;':' ... ,
. ..... largo proyecto hay muchas preguntas acerca dd estado dd mismo. ~ veces se requiere una . . . , . :
...::.:.
.
, ..._ exposicin for:rnal d~ dicho estado, otras veces el pedido es informal. A veces el pedido vien~ de':_tU;.~>;~-t::.,
\,.:.)
los administradores de la organizacin; y otras del propio cliente. Si el proceso de desarrollo d~\t(,li(~~;!:~W::~~:{f
software tiene una baja viscbilidad, cada uno de esos. infom1es de e~tado puede no :ser exacto,' '!i'',0~!;'.::,~iM1?1t:~;
requerir much9 esfuerzo p~ra prepararlo cada vez.. . . ... , .-~- .. .... ;,:: .; . '.:.,;_; ,_~i;,;.;..::-~r1;:;;0-~G}~JA;-
. Una de las dificulta ::les para ni~nejar. grandes pro)"ectos tiene que, ver con_ la i-~;tacin dei[U(i(;::.L};i~\i(
personal. En ~muchos proyectos, li ..Tnforil}acin_; .crticft e efe a de los requernie.ntos :y-:el :disoU.' 1!,;;;:.;r[~f)l1p;
- ..-~~.~l-I'I.L:t"':t~~, q;:.!o~n . -- . ~ ..... ._.,..;~X ~ .. \j,,~--~-
toma la forma de un "folk:.ore" slo c.o~Ji?_~}P?:r.P.9WJ~i.:g~j1te que ha es.tado en el proyect,o ;ya 'se~~)~:. }E~isf~;
desde el principio, o bien durante uiCt1~m~q:g:P,roi6H~d6> Err muchas situacicnes se :hace'. muy';;,,:?'::~i!:\:t?~
dificil recuperarse de la prdida de Wl:-g~N~r,()J~r~~gii~ar
. ........ \ lj,.; .. 1 r. ! ,, .
la incorporacit1 de otros .nuevos. . De. .>:u;h::}>f!i:f{
.,l . 1. _... : ' .... . .,t._.r~

hecho, el agregado de nue.ros ingenieros _r-e,q_Hq!r~~~;P~.~~udo la productividad de td e1 proyecto::r:;;~:~{~t.~~;..f(:r

~ . ..~ :_. 1 :

' ..
. . ..

' .,
. .~ ~ . ::
. .. -~: :} . .
( ",
.. ..... ,........ .-:- . :----.-.~.--~-----.'=',. -----:-.-.--- .. :.
 :.-:
.;-.':_;_.;.;:_:,;,:.=.-..:. :;:: =:~::-;-::-. : :-:-:-:
:: -... ::i~_:;0_~:;i4~;-~.-:-

:.~9 rrii~~liras ?e efecta lentauiente la transfer~~~i del~ "folklore". de

..... : : 1 ' ::.:'""'- '

... . . . .
;
que los viejos a Jos nuevps . :. :
)nge~eros.. - - _ . . _. < ._ - ~- _. .... -... ; .,... .. . _ . . : ~ ::_-.-
. .... Lo dicho a.nterionnente, puntua.li.za que la visibilidad .de 0n proeso requiere n:o solaJnerite' '"
. que t9dos los pq,~os del proyecw estri d9cumentados, sin que t.~mbicn estn documentii.dos .las
;< est~99~ d~ los pr9qus;tos interm.edios, y que se :mantengan c~il..:acti~d 'Ias~specificajbnes de.
' ~ecpyurniento$ y. ~Y diseiio. Es d.ecir que tambi~i1 :;e exige visil:ilf4ad para ~l'prociucto'." : ,;+-5.
' .,.. :i'. ;:;. Intuitivamn'k un producto es visible"si estclaramenfef~struct~ra'doc'om
:_,.,.:, ....... ,, ..... '\'';.,
,
.,
''
-...... cVinoctutos, con f1,1n.ciones claraf:nnte ~omprensibles y dociii"entcin acd!sible:.. >
, . . ., , h" ' . . .;:: ....... ,

' . '." . _J,;.:.' : .; . ' . : .: ;., :;~-~ :: :. ' >h:.,:::; . l;, : . .:!'.'::~:;;;i:_;, .. ',: . ,,.,,
. .,.. . ,.~........
\. '2.3 J.,as propiedaq~ de los--requerimientos segn ia;, distit?S ~eas'de apHcacii:i'
. . . . ... !. ~ . ':- ! . -~ .

~- ,4~ \'~::_. ~, \:~... --~~:.::-(' ~ f_:<:: .

1

'. ,: ; , ... . !... . _ . ' .

Las propiedades descriptas anterio.rrr:ente son genricas en el septido en 'que s'eaplican ~- calqir'::~:'~.-::l~w:(..;>;:w~~i~~
sisterna de software. Pero los sistemas de .sofu'{are se cntruyen para automatizar una ~plicacin en.
partic~lar y por lo,. tanto podernos caracterizar.. \m: sistei:na; .. <;J.e softw~re. basndono.s'/ en.; los:.
reqqerimien,to.s det rea de apli.cacin. En est~ $ecGin/ ideritiffs~emos .ctro~:in.:iportan:tes~(e:ls 'de ..
~p~ip~ci9n de Jos si~temas de software y exan11narems stis)eq~erirnientos:.adi"cionai~;mt~~bi~.
!riostraremos C0ll10 refuerzan ,de diferentes maneras, algtl!la~J<;ie las prqpiedades g~~eraJescitl .,
~1erp~s discutido anteriormente: . ~. ;: .. '.-:::.. "(; . '. '
... !1':
' ,1\,'

2.3.'i~
1
Sistemas
:
de informacin
' ' .
~. . : 1 ; ~
: .', '
.. ;. i.i . : . ~. , : . : . . . . :_. ,:_~.. '; :: ~. '<:~ .. .. . . .. ' 1 :..

Una de las reas de aplicacin de "comput'adoras: qt1e ms rpido est reciendo es la .

almacenamiento .y recuperacin de dat'os. EstaClase de sistema se llama "sistemas basados eri. la:=( ,.
. 1 . .
i.p.formacin" q .implemente "sistemas de informacin". porque el propsito principal del sistema.,'')!) : . / ..
es el manejo de; ta infom1acin. Sonej.ell1p!os. de sistemas de infomlacin los sistemas bancarios, :'V)~~;': ::, . .:
sistemas de catalogacin de bibliote'(;as, y si~temas de personal. En el corazn de ~sos sistemas ,,<:~J::. : ,.'. ;:

~ ~~;:,:~~:i~;~t~:::sd: :::::i;;d::o:~~:~z ::~::::::e::::doc,e::~::::~::.~::u:~~E ,~,*~i~

infom1acin corno recurso. :i...os datos que manejan estos sistemas son, a menudo, ~el :recurso de \j;t:~:~i;{~'''-i0l;!:
:. mayor valor de una empresa, Tales da,tos Lienen relacin- tanto con los procesos ~b~O en los: 1)\c;e:r:):'}(:' l~
,.
:recursos

internos de la e1j1presa- plantas,

mcaderias,

personal,
-
etc.- y tambicnin.formaciri
: - _ .
sobrd;y:=
- !-r<:
i~i
1 :. \ ~

recursos externos - competidores, proveedores, clientes; e~c~-- Cada vez ms; las' corpora.cionesJ~} '~~
estn compLltarizando ss proceso manuales y confiando s informacin a las computadoras .. ,Laf' .:
> mela es hacer que SUS proceciOS Sean ms eficientes y que Sus' datOS estn disponibles enJnea~ . ..::,ii:~:~,,, i>t~~
Los sistemas de informacin estn orientados a los datos, y pueden caracterizarse sobre la ")}:tr.~,,~~;;,:,:~~t'i
. ,',. .. ', " . . ~ ' ... l . .-:. .,.~

. . base' de la man.era en que tratan esos dJQs. Algunas. d~ ls propiedades. que caractenzan a ,los_:\cU'(:~U;:~;,;~~\i

..;) ' sistemas de i~orm~cin son las si~ientes : . . . . . ... ~- ~:-:;..,~:_,,:.:::d:J\~ftfi:?f.{;.:~:r~J-~

t..:.'l
..;J *Integridad de los datos. Bajo que circunstancias se corrompern los ciatossi.'el sistema: :?:~;,i.
Cl
(')
fun~:ona mal?. , , ;;:; ' . ' >'<.: :'~j~~f~~~~j~)
x Seguridad. Hasta que punto el sistema protege los.. datos de accesos no autorizados? ..!.~:.:; :~:it~:~..._i((;~:~W~i
()
. . . . . . . . . . .... > . . ,:. ~-r::.1~;;n;~;ff(t1J
r':) .
x Disponibilidad d<:: los datos. Bajo que condiciones podrn no estar disponibles los datos i:;::(~ i::;.t!.~t{
1
'---
1,-.
u
e y dillante cuanto l.iempo ? .. , : ~i~~~~rj
.
~u

. .~ : , ~ ,;~:t ~ ~ __,_L_:-~ _ i~1~__ 1~t~~ ~'~.!.l.\__f_!.f;

Jc
,j .
J(.:l
lr>
;1~
. -.i:

.. . --.,, .. y----,- .. . 1
 ...
_ ,,

-------.--.-.
. . .;- .. .-,-.. .-.--.- ..

G~~:~;~ ~a~
iffll :. :; ' Per f onna~ ~e de las ;ra,;sa c~io nes Dado que .le ~et8. ~e 1~s sisteril as dO inforinai n ~s >< r ' 1

.:'. :. . 2::::i~:~~~~~e~::~.l~~~;~:~t~:d~~:~~~i:~?~~e~ee~:~~~~~::;: ~;~:~s~; . ': :~;liil,~!

. Otra caracterstica importante de los sistemas de informacin es la necesid?-d de provee~ ,.. ,, ... c~{J!.t.{ ~.1: J
inter?ccin con ~os l;J!?Usarios ~ue. tiene11 'poca o ninguna t::spe~encia tcni~a .- ppr ej. ,yendedores 1 '~"!1f ~ ;~~~
. ~dmini~trativOSJ'j directores/ As; lbs r~quer~rrleiltos 'de.' int.erac7iri hmano-comp~f~~.2r~}~l.~~J,;;~{~1 ~!:t
. como la amigab'ilidad con el).1suario son de P.rimera releva11c!a ~n este caso. En part.~9:\-na,<~;:esi ;:.;;jt~ ~t
requiere que la interaccin cci,p. la aplicacin ~e. ?aga va men.. Los menes de9eria'!J: di~e~#se de:: ,i~}:i~?j :rr
manera unifonne', y la navegaCiil entre las distintas ftmcion~s ofrecidas por la. aplica~in, deberi~.:,1:(~f~~;~~~:.
ser fcil. Los usuarios nunca.. deberan, sentir~e perditlos; , deberan poder', cbntrolar :.sienipre: la,;):~:it}IIJ.{
intericcin de la:plicacin, y la apl!cacin deberla proteger al sistema de un mal uso poi parte ?e
}::;,;~;;Jt~1!;~.
los operadores. . : , . , . . ; \. . '. >,';::>M~:)j.j~.~~J
. . Los mod~mos sisterri~s de in[o~acinapvntan e~1 esa direccin. No slo provi?P,:}:l!},f(lci!::;~;Jgz:t1?,.. <:
acceso para el U$uario, sin_ q~e tambin lo alient;1n para la creacin de .apti:~cione,s, 1.~~plf~: En :~~t):l,~~?lli~t:~?~~f 'Wf
lugar de depender de espectaltstas para hacer programas ad-hoc para, por.eJemplo, tener nuevos ::;,',,~:~;.;.!i:;J~.-.,.,:S
lis.t~do: de la b~se qe da'o~ o ~:o~~ui'tar a _la base d~~ wui m~nera d.istinta, el.u'sio p~._de. usar :::{j\};~!,;i}f.J~1i~fiK
final
utlhtanos provtstos por el.sJstema de mformac10n para resolver este tlpo de problemas. Esta:::;~ 1:;: .;,~:~;;:'j}. ,;;h
c~racterstica se llama a me~udo."c~mptacin del usuario final": .. . O;:jt,.<i~J~:( th~~:

).
; ;~; : ; :;:~o;.; :; :~ ~:~:~':,~:c:~a~':e ~ :sc!~:,: ,: ': e:u:sd:~b~ ~: ;~ ~:;:~ : '(''~~,f~~
eventos dentr.o de un perodo de tiempo estricto y predefinido. Por ejemplo, en mi sistema de :::. :. . ;-,-i:':';.'
mo1J.itoreo de fabricacin, d software debe responder a un rpido aw1iento de li temp~ratura' ; ..,:-:; :, :,,. .,; . .,':
accionando 4eterminados c;o1~ando~ -~. oien..baciendo sonar una alanna. o
un sistema para guiar u;:~~!~i~(;b<H.(/
misiles necesita monitorear petrnarien~emente las condiciones ambientales y la posicin del misil.; :;Jjff(.' .:::;o;
para corregir su tray~ctoria adecuadmente. . . . , . . ;~ ,;,;;;;.,;';:;;
:;;!.~i;:,i,'f
' Si bien la clasificacin de tiempo real se apl~a generalmente para referirse a !us' :;~.4(/:Uv.':.<~?:::;
automatizaciones de fabricacin, sistemas de vigilancia, .etc., se pueden encontrar requerimient~s ,: ;1::f:.~!;');f![,t/:
de tiempo i:eal en sistemas ms tradicionales. Un ejemplo poco usua( pero interesante, ~s el d.et. ;:;:~j~{-:1 :;~!0~\t\.
softwa,re que maneja el mouse de Wll computadora; elcual debe responder a l~s interrupci~nesT;;:::{!j)ij~:;:,v
generadas por el click del :;nouse dentro de tm detenninado perodo de tiempo. Por ejemplo, en. . ::;.:;~:<
algunos sistemas, Wl r~r.o click es lUl comando para seleccionar un objeto mientras qi.te un doble ,, ;, ..;~
clic)<:, si los dos clicks ~:stn lo sufi~ientemerlte cercar~os en el tiempo, es un comando diferente ,: 1 ::,:, :~:.
para "abrir" un objeto. Esta clase de interfase establece tm requerimiento .ele tiempo real en e[:.,'Y~d;-~~J.I!:.,,~::.;:.
() software porque deber procesar el primer click lo suficientemente rpido de manera que 'pueda. :::f?;)~:;J~?;!'iii!:'
o aceptar una 'segunda iaterrupcin y deterniinar si el usuario ejecut un dol;lle click o bien dos. +t!,:(::~;~i';.{'.
C) nicos clicks sucesivos. . . . . ,. .. '; ;.,~'{{~).]~fL~;i;;~~~
.c:~ Existe una mala interprctaci~Q_respecto del tiempo real, que lo defne comQ un sistema que''7:f'?(~~'?:~:
,;~
.requiere "tiempos de re~.puesta rpidos". Esto no es verdadero ni suficientemente preciso. La ' . ,:
().
"rapidez" es una propiedad cualitativa de una aplicacin : ro que se requiere para un sistema en ;,
Q tiempo real es WJa nccin dd tiempo de respuesw. que sea cuantitativamente esp.eCificable y.
!5' . verificable. Tambin, en algunos sistemas en tiempo real, una respuesta que llega deiT\asiaclo , ..
(j temprano puede ser tan ir.correcta coh1o wm que llega demasiado tarde. En el ejemplo del mouse, ,. . . , .''

;;;11?(1,:&~
... ~

_;.1

G. ;
. .\.o ~f~i''l ~:,"';~ ~
[> '.
... .

:::~::~~~~~;~'-"':c~:~;~;:;;;;~:~;;!;;c~~~:~~~:~t~~l~~~~
(j
e>,,
.. . . . . . : :
 ..,

,@ ~~:~c~~~~~;edi~k se pro~:esa dernOsiado. rpi1oi,~ob,le ,click puede no m d~~eciOd :''li~f

Los sistemas en tiernpo real han sido estudiados por deteho propio. Podemos d_ecir que los ., ., i~'::~z~h{{::\;
sis_tem.as de infonnayin estn orientad~~ a lo~ da~os y que .l?s sistemas en tiempo r~al estn ,: :::\:.r.fma:~f:~_,- '
on~nt~dos a los _controles. En el corazon de un SIStema de tiempo real. hay un "plamficadorn ,.;~:14;,! ''. :
(scnedu.ler) . que ordena o planiflcp. las acciones del sisteiJ1a. Hay dos algoritmos bsicos. deif-:[i::-7"':;<
pla.r:fca~in: pr ~nt~rvalos (~ea~lne) por ?~oridade~. _E~l~ plani~cacin por prioriJ,~q;s;~ a.da)~::U{):
y
. 1;Mj
~c;::c~on tiene aso.ctada una pncnda~ .. La accwn con la. pnqnda~ mas alta. es la que: s_e eJecuta ,>;;J:,\:;: . .(j!,ij 1
. F.r_irero. E:~ ~a .?_anificaci~Sl). _por i~:tvalos cada ~ccin tene .'":~pecificada un tiet~lpo''dentro. :?e";-:,!fJ~t~;, ~tJ.;j
..c~?-l.debera m1ctarse o_ b1en finalrz~r su tare~.. Es re~ponsa:btlJda~ :l pb!1!~c::~~~or:_(s~beduler) .i,!\(r(~:~:::::;t;;.l2 ~!_
ase~ITars~ .que ~~as acciOnes se pla:mfquen ~e. tal mane m :qu~ sattsfagan los requenm1entos de~,~;;:::" lf:ti:~\
plnmficac10n. . . . 1 ~. . . . . , .. , -'>.:_ :i(f:. ;
. . : Adems de las propiedades 'genricas del softwar~, los sistemas en tiempo re a~ se defiri.eil ;:;~~:1! ~~:ii'-~:
por la exactitud con que satisface) los requerimientos_ de tiempo de respuesta. Mi~ntras que en : g.:::;:{;:;~((1.
otros sistema~ ~1 tiempo de re:spue~ta tiene qu~ ver con la performance, en los sistema~ tiempo _.:;;::}f;~h:JJ:~~~~d en
i~al, el tiempo de respuesta es un ciiterio de "~orreccin". Adems, los sistemas. en lieinpo real,son iA;~~(;;:l: i~\~1'
usados genenmente para. operacion.es .crticas (tales como If!.Oi"Iitoreo de i:mcie~tes, sistemas .!.'<[?<fL,;;. ~Y~1 de: l
~ef~nsa, y control de procesos) y tienen requediierits de"i:~nfiabilidad niy_ estdctos: (S_e ttli.!i,za::i~~':.Y:'t~~~K "' ';;
. 1 . . 11 11 d" f . ! . 1 ) . ':l.:.- ~
e termmo mtstoncnt1ca para emtrtaessistemas .... ,._:1~':- . . . :;::~.: :, . ..; :.;~i_<.~:,
: .:, .: ... En e~ caso de sist~rn?-5. altamente. crticos;.se, usa:~: menudo el tn~ino seg~1/idad _:-r:::"/m. .. 'par?- ,_. Jt
re~arcar: la ~nisencja de cRmport'mientos inde~~~bt~~ q~e _puedan provoc~r riesgos en el sistema. ::: ;qHf,~~;:?:.~~~~~
La seguridad _implica ms r,equerimientos_que los,de una misin primaria y exige que el sistema se :_::.~ :;~!("~\'::
. ejecute. sin causar riesgos' inaceptables .. A. diferencia de
:los requerimientos funcionales," que ; o~ ~~:':fT3:''. .
':,describen el comportanemo adecuado en trminos de relaciones de entradas y salidas, los :<:.:-::,,:.~):
requerin1ientos d~ segurithl describen lo que nunca deqera pasar mientras se ejecuta el sistema. :;:!:!/<~;_:.
En cierto sentido son requeriment::>S negativos: ::!specifi.ca.rr los estados en lsqucel" sistema jams ;.,.
debera ingresar. :i . . ; . . . . ~ -.' :_ ':_.

; finalmente, hay otr.a_s propiedades q~Ls.of!ware .qu_e tambin podran ser importantes en el ' ~ ':
caso de los sistemas en. ti.mp<rreaL Hemos 'visto cue los aspectos de la relacin hwnano- :.
computadora son importantes en 'los si'stemas de infonnacin. Y pueden ser an ms irnportailtes :
en d caso de los sistemas en tiempo real. Por ejempo, la i11terfase extema de un sistema de ' l .' :;
control que monitorea una plan;ta industrial crtica, debe e_star diseado de tal forina que el .. J:.
operador comprenda c!aramente:el estado del sistema bajo control. para que as pueda oper_la ...
planta con seguridad. . ;
..'l
.~\ .. 2.3.3 Sistemas distribuidos
-
,..

_._;
Los avances en
la tecnologa de redes han hecho posible la construccwn de los as liamados . ..
sistemas distribuidos, q~e consiste'n en computadoras indep~ndientes o semi-independientes, . ; :: . : .. :
cone~tadas pr una red d_e comunicaciones, El alto ancho de banda y ei bnjo prQmedio de erro~es; -':-~ ,_'..,

~~
hace' posible escribir sisr~mas de software discribulqo"s, es decir, sistemas con componentes que se :};-;.;.:~:ii:i.JH;,::
ejecutan en distintas CO!nputadoras." . . . . . . . . . . . ; >1{;:?".;;'
Si bien aplicamos las propiedades genricas del software a los sistemas dislribuidos, s~ ~A;<:'ff~;
?~
.......
-
agregan tambin algunas .: :;evas propiedades. Por ejemplo, que el ambiente de desarrollo del. ~:. _. .. Ii'
<J software soporte et desarrollo de. software sobre mltiples computadoras, donde los usuarios ... :.. :~.
puedan estar compilando y tal vez haciendo lihks en diferentes e~1uipos. . ..
Entre las caracterist~ca~ de los sistemas distribuidos estn ( l) la cantidad de distribucin.::::.:.<):.
soportada- por ej. estb distribuidos los datos, los procesos o ambos ? (2) puede el sistema :. ; ...:,,.':

A\o.-.. ~ .:_ :.
.. l . ..:

-: ,,_., -. ,_ ',"''' ''.r"'',:-:HdHo;- Jt~o: .. '''"' '"!"f'',:":"''--~--; - ~:'";:--:-:- :.::o ;-o.:~.'"''""''''"'~'"'"r' .. ~',;'~o:-0': OOo:to~
.... --- -.-- ...------::;-:-:-----:" ., ... - : ..
 rolerar el pamcwnamiento de la red ? - por ej. cuando una mala conex.in hace imposible la
comunicacin entre dos subconjuntos de computadoras; y (3) el sistema tolera la falla individual
de una computadora ?
Un aspecto interesante de los sistemas distribuidos es que ofrec~n nuevas oportunidades'
para conseguir algunas de las propiedades discutidas. Por ejemplo, replicando los mismos datos en
ms de tma computadora, incrementarnos la confiabilidad del sistema. O distribuyendo los datos' '
entre ms de una computadora, pouemos aumentar la performance y la confabiliuad. Por supuesto,
replicar o distribuir datos no es tan simple y requiere un trabajo de diseo significativo. Existem
muchas tcnicas establecidas para tratar estos temas. Veremos algunas en el captulo 4.
'1 n

2.3.4 Sistema integrados (embedded).

Los sistemas integrados son sistemas en los cuales el software es una de varias componentes y a
menudo no tiene interfase. con el usuario final; ms a menudo tiene interfases con los otros
componentes del sistema y probablemente los controla. El software integrado se usa en la
acualidad en aviones, robots, hornos de miCroondas, lavaplatos, refrigeradores, autos, y otros
instrumentos.
Lo que distingue al software integrado de otras clases de software es que la interfase es ms
frecuente con otros dispositivos que con los humanos; por ejemplo, el software enva los datos de
control de velocidad de un robot a .J.os motores en lugar de dibujr una curva con los datos en una
pantalla. Esto elimina algLLtlOS de los requerimientos respecto del diseo de la interfase. Por
ejemplo, a menudo es posible modificar la interfase del software - complicndolo - para simplificar
eldiseo de tm dispositivo de hardware.
Consideremos una mquina expendedora que funciona aceptando monedas de diferente
tamao. Podemos construir un dispositivo de hardware que determine el valor monetario de cada
moneda insertada - tal vez con una ranura distinta para cada tipo de moneda - o perniiti'r que el
hardware evale el peso y la dimensin de cada moneda y se lo comunique al software, quin
calcular el valor de la mo_neda' y si se insert la cantidad adecuada. Si ponemos el poder de
decisin en el software; haremos q\.i'e el sistema sea ms flexible para ios casos en que se acepten
nuevos tipos de moneda o se eleve el precio del servicio. En estos casos no ser necesario redisear
el dispositivo de hardware sin que bastar con resetear algunos svlitches internos si el software
estuvo bien diseado.

Si bien hemos discutido las cuatro reas de aplicacin precedentes considerndolas

distintas, in _la prctica, ~~ch~s si~temas, e~iben cara:terstica~ .que son com.~es a muchas de
ellas. Por eJemplo, es facll 1~ag1nar un Sistema de mformacwn que tam.b1en tenga algunos
requerimientos de tiempo real. Tal sistema pod.ria, por supuesto, ser distribuido. Adems el
sistema podra estar integrado en un sistema de monitoreo ms grande. Como otro ejemplo, los
sistemas integrados a menudo son en tiempo real.
Un sistema de monitoreo 'de pacientes en ~n hospital es un buen ejemplo. Debe mantener la
base de datos con las historias de los pacientes. Puede ser distribuido para permitir el ingreso y
recuperacin de datos de las e~fenneras en distintas estaciones o en varios faboratorios. Puede
tener algunas caractersticas de tie~po real por ejemplo, para los dispositivos de mo~itoreo de la
sala de emergencias. Y finalmente, puede poseer algu..11os sistemas integrados para inte!a~~ar con
dispositivos de laboratorios con el objetivo de actualizar los registros de los paciente~-~11J!l ba.Se a
medida que se realizan las pruebas. . .. : :--:: ,. :~:,. .
:..
 }\ ,. . . .. . . , . _; . .. . . .
~~~: : . :~ . .-:.-~A{)~:
-, ' Una.vq. que hemos definido las ;propiedades que son la meta de la ingeniera .del software;~::
) necesitamos principios y. tcnicas 'que. _no~ ayuden a. concretarlas: Tambin necesita[nos. po~.e(i(i~~;i?J;;:~~r~,
) me di~ una determinada propiedad. , ,: ; . _. . . . . -. :>T: .,': .: ;.;~( ]\:\'.':t~t~Ht~l. ~J:. ;;..
1 _... . . Si identificamos w1a propiedad como importante;::_querremos r_nedirl_a _-s~b~r's(rios ~;;]';:~i~~JJ'' \;;~f!n para: _
: . . _ac;;rcaplq$ a: los. _valores esperados .. Esto .n ..:;~,-y~~- F,~qu~~~e" que definamos. cada proptedad ,_de::':~~:-;];.;~;. "~ h;;
) ' : ~i~~ra preci?a que quede claro qu esu1-ios mld1end?:.s.q_h1ediciones!cualquier_ pe_d~"do,p~ra_:),? ..
pa.ra l';':
) -~: meiorar el sist~ma no tendr !;>ase de susten~a,cin.-.Pero sin~U[l<{pefinici~'pr_ecisa e.la.'pr{)pit!,da"d~\
no hay esperanza de que podamos medirla con exactitud.. ~-~:.;~\_:' . :.,. ... : ;. .~?!(;~. :.. ' ,?L~<:. :~ /~~:wr~>
:''' : Las dis~iplinas de ._ti. ingeniera:_ ~~isie.re~ .~tie'n~~:)cni~asst~~d~rci:'. p'~i:~,}i\~cf:;J~,_:;.,
propiedades. Por ejemplo, la confiabilidad de un amplificador se puede me-dir detern1i~'ando l_{~;~~ .... , .. -";.
. -.\ rango dentro del cual opera. La conpabilidad de un puen.tc -puede medirse por la presinque puede).f';'~(,'}]f/~~~fj;_
.... soportar. Incluso, esos nivel-es de tolerancia se entregan junto con el producto como parte de las . :: .:~:: .:':: ~;;}\(:J,
...
~-

especificaciones tcnic-as en el mauaL . ; .. ' . , . . . : '. -'~- ;_ .;. , . i i ,: _;,::.:, . ;:; >~~;.!';";~.
, ,
..... . Apesar de que al~unas propiedades. del sftware se pueden medir fcilmente,:~t~l ~orril~j;~1i:(J';;~~(,gg~~~;f
,. ;. perfom1ance, p~ra la may_oriade las propiedag~s no exist~n mtricas universalmente aceptadas;{Poi!~ t~J+~:i.i.K,\,
r
' . .J
; ejemplo, se q~t~rri:J.ina e ITElera subj~ti~~~ si. Ut~ s~~~~rr:a e~o\ucionar ms fcilmente tlue.olro.No'Hi r];J:~';ti:~F
obstante necesitamos mlricas, y en al actualidad s~ est dedicando un gran esfuerzo para clertnir :'>'i:8%_f:f.i?}!f~#if~
. . . ' : , . .' ' . ' --~: . . . .. . . . -l!:'.-~!.:::;:'!,.~~--::::; ..;.~-'~::.
' mtricas objetivas. En el ~apttulo 6 e:~al~lma_r~t1:1?S1 :~~~~- tema en profundtdad. .. : :.,,~;,i;3),j.\)\'p~:J;;!)'
.?\

'';. :;:~~~~})
. .

2.5 Conclusiones '' .. . . :: ; 0:

:.~ ... La ingeniera .del soft\vare consiste. ea la aplicacin de Jos principios de la ingenira para la. {;j';;.':i
,.;._;).
fabricacin det sofLware-:Par2. poder dertnir ui1. co1~unto de principios que sean unioni1emente :. :::~: (>: /:<
aplicados a una variedad de productos, el primer paso es elaborar un conjunto de propiedades que.: ..~;i\L S}>
caracterice dichos productos. Eso es lo que hemos hecho en este c.aptulo. Presentamos un ~~:t::; '',;.1i1-/
conjunto de propiedades q~!e determina el Jn_~rjJo de cualquier producto de soft,vare. La prximat>if}._': ..
tarea ser apren?er qu pr.inci:ii'o's'aplicar para .poder .constmir software que cw11pl~ con esas.:: !_::....._._::- .
propieJaJes. Ese ~s ellpic:J Jel prximo capitulo. !./
~Hs ejerdcios (:jfi'!i'~f(~
2.6 En este capitulo hemos discutido bs propiedades del software que consideramos que son ,, :_; ~:-:
las ;ns importantes. Otras propiedades son: Faci1idad de testeo (testeability); Integridad;
. ,.
, _1 d

- . ',.- ,:..
Facilidad de uso, Facilidad de operaci:1; Facilidad .de aprendizaje, Defina cada una de
estas propiedad..;s - :r otras, si las hay- da11do ejemplos y relacionndolos con las
propiedades que di~.cutimos en este cap_tulo.
:1

2.7 Clasifique cada um de las propiedades vistas en el captulo como internas, externas, de
producto o de proc~::;o, dando ejemplos. Las chlsesno son mutuamente excluyentes.

.. 2.8 Muestre grficarhe:ltC la interdependencia de tns propiedades discutidas este captulo)':;~;_:;,;:r/.:,~_::~e\~~b en

dibuje Ull grfic<:J donde cada nodo representa uua p:opiedad det software y una necha ctet~;:;;~~:,:iM:-;:;~~,:;Mfr2\
nodo A al nodo B~.ndica que la propiedad A ayttdaa conseguir la propiedad B'. Que : i_}:;'}~j;r~f):/
muestra d grfico acerca de la impo11ancia relativa de las propiedadc~ dd software? . -.~.;\.';J(:b.~(j,-.:~:.F
Hay algn ciclo en el gr'ico? Que implica un ciclo? ,:':.:y,~~'t,':;~)!)<~

. - :J'i\~ii:[
1 . --~~- ' . :- ... : ......;::-:---!""'',''''. -.::-.- -~-~"-~ ............. :---:- . . . -".,. ............... ---~--:- .. , ...,::.,.:', ..... :..._~ .:~
-~--- ------' - -- : ~ ; __ ----- ... :- r_ ;~--::-:-.~:-...--;: :~ ~--:.- ~-1 ;.:~- -~-~-~::~.:;.::.~~~~ :.
- ., - ---. ,.-:..- .. : ..
 . --- .. :: :. ;. .: :'~.:: ;,.::_::.=:::_:_;:;:::~:~:,;_:_:::~~..:;: . .. ..
' 1
. .. :. /~ "- . ,.:', :.: ':' . ; . .; ~;;~:i:~~~:::r~~!I\.,. :
; (\) 2.9 Algunas yec~s, un nueve admin.istra,dor usa mchas de las tcnicas qu'tiliz en "su'~~.':t'~,,~>~.:,l:::'.' ': ..
proyecto ms reciente. Usando. esto corrio ejemplo, discuta el concepto reus~nilid~d :o: : ;'., .'; de
. aplicado al proceso del ~oftware.: :. .'
. . , . ..
: . . '. .. . , ... .. -' . . :~- . . . ~ . . .. . .; .

2.19 Si est. familiarizado con los protcolos ARPA para ftp y t~lnet, discutasupapel'enh(ri~):.: ,::r:

t.
inreropratibitidad. _ __ _ ____ - _, , _--- __ " , - _ ___ ;;~~.,. ___ /J~f:Jim~~~i[~'
2.1 i Hymo~ ~iiscutido la interoperatibilidad c;omo una prpf:Jic:;:dad relativa at producto.
' ..
:Tambin
-o.:.- : . :.,..} :
,' ; ,.. ; .

-:.. "-< . :, ~J;:-, ~.

podemo::; hablar de intt-:roperatib:~idacl c.le proesos. Por ejempl.o, ei proceso seil!id para:
asegurar i.ma organizacin de,be ;:,ef COl~~p:::~i':J!~ (.;Qn -::\ p!oces~. ::;egut~O p&ra desa:'rrc;lJar\<~0':
Otro ejemplo puede ser el de una compar1la que c~ntrata una organizacin indepeildiente .: . : .
para producir la documentacin de un producto. Use estcis.ejemplos'y otros propios.pant ~~:,. h .
analizar la interoperatibil: iad pllcada a los proe~sos. ,

..... .

,:
~!. _:; ,;.r. : .J
-:::- :_:.:. .= ._:{Z:;;~-~- . ~ :(
Pis'tas y yudns pai-a las solucione~ ,,
~ ;_~: ~- ~: : ... ' . .. J~~!.r~j:l?: . _,:-.~.:
. . . . . .... ; : . ;' .. .,:-.o:,;: . .. -~ . . . r.
2. J En alguno~ casos, las decsi~mes sobre la interfase con el usuario puecleii afectar _t ,
confiabilidad del sistema. Por ejemplo, debemos a.seguranos que dos' teclas que'producen :.. :
dos .comandos diametralmente f:mestos, no estn ubicadas una al lado de la otra pa;a; ' ' '.:
evitar que el usuario desprevenido accione una en lugar de la otra.
1.'' ' i \,;;:?:lhi1i.:.:<;r., .
A medida que los con~.ponentes se reutilicen ms y ms, se volvernms c.onilabtes, dado . :~}:;';,,k;.f~;:~J~~;}
que se eliminarn pro;sresivamente los emores residuales. '' .
' . ~~

... ...
),

..
-\
'
:;i
~

::'
i\J~i~
~: ~.:~~~~
.....
:
_;J~t/\

.~ 1 ! .. .. . .:::.:;_;:~~
..... ..~
.
':) '
-
' .:
,:/)
. ,.
r.
,,;)
'f)
0. 1,''
---'

--~
::.)
,:"\ .,
~- . ?

() .
. .'
'e.-:;
..,. ; . . -~

i. . '

:.:;:.:::: :.:.~~;~:~:;~:;~~~..:.;:::~.- ~;;.~;;;,~~,,ir.-, :7;~=.:;;:;;~;;:::.;.-;;.:~~:..!.~~;'f:;,:,:~:~~;6;~+;,~::: ~,: :~ ;~~ .~ ;:~~ . i .;~,~\ ;;;\~.:,!;f~i.~rJ.~~Ev~:.;:~~i;;.:p ;;;z.Ni?~;~;H~!=.~ ~: i
 '' ....

~:"~;::~?t,;:-. : ... . 4-! : .

r:~i~*~~~=;;&~~-~~<z"";:,a~~"'~y~~
i\/ _:,Ti]1:f' \, : . Princi p i~s de ia I~geO i',~--d el software ___ . -_- __-___ -_ __
:):,{":,:;:En' ~;>t~c~pt~lo, slis9utiremos algunos de los imponantes prin~ipios generales 'que. so~,;,: ... .. :.
.::/~:':':. p~r~ )ll}, exito~o, ~~sarf9llo. del software. Estos r,rincipios se refier~n t~.~to a ~O.s~p~?ces~,j:~~i-!~~~~g. ...
"::\:~i ; d.el ~of1ware com? al producw final. Un pr~ceso c.orrecto ~()ntn):>Uua a prod~cu el pro9,~ftO
;~: ;' "pyr9 ~1 producto .desea~p influir t~mbi en la.e.lecci?tl.del pr.c;>ce~o.a util~z~~(:[J1tl p~o~r''"
1~;.., .:.;.~.9:tla ingeniera del softvyar~ );,a sido el poner enfas.ts ya ~~a en el proc~so;, o en eL .. ,
;.~.).;.''exClusin del otro. Pero ambos son importantes.. : ' ,:,
!:) :. : , , Los principios que desarrollamos son lo suficientemente g.enerales como para po.der ser aplic . ...
]'J) . : .a todo lo largo del proceso de cp.nstruccin y gestin det software. Estos principios, sin embargo, n9. soh
:("' suficientes para conducir el de:::arrollo del software. En realidad, son principios abstractos que describen: :,:e,
(:;; las propiedades deseables para los procesos y el producto. Pero, para aplicar esos princip~os, el ing~niero. :'.: (~ . ,.
r:.. . del software deber estar equipado con mtodos apropiados y tcnicas especficas que ayuderi a ; ::,' .
- ~ncorporar las propiedades deseadas a los.procesos y productos. . . . .>. :. :::; . ,:, .. J.;
;(;) En principio, deberamos distinguir entre mtodos y tc.nicas. Los mtodos son pautas generales:::/' '<t)!
: (.) que gobiernan fa ejecucir; de: alguna actividad; son propuestas rigurosas, sistemticas y di.sciplinadas. ;... :'.~; :::i'(. .'':
(- Las tcnicas son ms tcnias y mecnicas que lo~. mtodos; a menudo, su campo de aplicacin est rn~d"\~
:1;: . . restri~gido. En general, siri. embargo, la diferencia entre los dos trminos no es tan pr~nunciada. En ,;;(k
~ . ~/ .\.- ConSe!cuericia 'usa~~ntos arribos trriinos indistintciill:erite}:. ..... :_:~ ,. ,.
: . ,: :. .
~.-:~.- '<(, :.:: . A veces, l~s mtodos y tcnicas se-~grupan. para formar una metoUologa. El propsito ele
1
las
.,:.metodologa es adelantar una (:ierta propuesta' para res'olver un problema, preseleccionando los mtodos y!
m1a.l.
1 a
, r,F.1 , . 'las tcnicas a utilizar. Las henan;ientas. su vez, se desariollan para sustentar la aplicacin de tcnicas/
1l ~~. mtodos y metod. ologas. : ' . :. . . :..
~~~~: . . . . La figura 3.1 1nuestra: b relaCin entre prindpios: 'mtodos, metodologas y hermfnientaos. Cada;
~~>; capa en la fig\lra, se basa ~ri,:.a capa anterior y es ms suceptib!e al cambio, debido al paso ele\ iiernpo.i
.1 '--. Esta fi,S'1lra mi.testra claramente que los. principies soi1 las bases de todos los mtodos, tci1icas,!
jC metodologas y herramieeta~:. La figura taniP.j~!J .. puede..explicar la estructura de. este libro .. En este:
f O captulo, presentamos los princi'pios sepciales de i ingeniera del software. En los capitulas ~1 .. 5 y 6;
!ir) presentamos mtodos y tcnic~s basados en los principios de este captulo. El captulo 7 presenla alglmas
[ (\ metodologas y el captulo 9 r.liscute herramientasy ambientes. '

~~( :.

s
m.el
Figui-a 3.1
Reiacin entre principios, t~rJcas, metodologas y herramientas

l.- Herramientas
; ~i:; 2.~ Metodologas
3.- Mlodos y tcnicas

~~ 4.- Principios .. '

~~C~ En nuestra cliscusi.:1 de principios,. tratamos de ser lo suficientemente generales como l)ar:a
;6 abarcar todos los. tipos de apiicncione~:_As lo hemos beeho tambin con los mtodos especficos y con

~
~ ~
!~\ g..
las metodologas. en los captulos siguientes. Sin embargo, hemos puesto un nfasis deliberado en la:
~.eleccin de algunos pri!Jcipios, mtodos y t8cn.1cas. Entre las propiedades que discutimos en d capitulo:
anterior remarcamos la confi::.bilidad y la evolutividad; y esta eleccin a su vez, afecta el nfasis sobre los
U p,rjnc;jpios, mtodos y tcnjc:as.
me .
Tal corno Llijimos e:J el captulo 1, consideramos el caso en el cual el software no se desarrolla
~C ' cmo un experimento par ser ejecutado slo unas veces, tal vez por el mismo desarrollador. Mas bien se- . ,

~ e,. '~-.:/\.>;:.\:'
:~~.\.
:f~ ~3 ...
~
.. :. ' ,<;~ .
. '.f :.'.!,

~~:::.~~~:~::~-:::-..:.n"; . . :;;;~:~~:;;:~~;~;..~ ~.;;;~;~;~~:~;~~;;;p;;~;;~;:;;;~~~:~:;~~.;~:; ~~'~~;.~;;;:::~: ~ ~~;:;;,;;..:::~.~:;:~r= :;~;;;;ir:.~;r;;~;;:;~~,:;:,~;:: ~:=~?~Ft~;;f.j

1
:.?, . ' :, ,.. :-.. : ::::. :::::
 . . . ::

.t.:spera que -los usuarios tengan muy poco o_ ningn conoclmtento sobre computadoras y softwnr. O. . <!
podda ser necesario soportar una aplicacin crtica, en la cual el efecto de los errores puede ser serio y .. _"' -:<.!
hasta desastroso. Por esta y otras razones, la. aplicacin debe ser confiable. '
Tambin suponemos que ~-~-Qlicacit_u~sJo ~IJD.C2~~1:\1~J.P.~I)._t_e~_g!:_-D.4.~.Y-~9!~2~l~P~~!:~q~:~_srJiJd.@.. _: - . ;> '
descomposicin en partes maneja'Jles. Esto. es especialmente cierto para el caso_en que el proyecto ser.:".-<:.:.::_~!-;,~';
'cies'irollaac)"f:ior.l'm eqi:iip0.'1'ro-1a-lbin es cierto en el caso en que un {mico ingeniero del software est ~ ; -_,:;; ;.,; :~_;,
.. -~~~~~~~ol:~~:~~~Jid~; ambos casos hay necesidad tl~ uua pr~puesta de d~-~~sl_Vq__q~l__-~of!_\~ar~ qhl~. _.._.:..- -._: ~-._ -:~ .- ~'-, .:_;':!t_.' l_:;~-:_; !._~: _='_:.:;__ __

-------'En todas las--r1reu.:.~stanf:ia;; aP!eriorf"s, !Gs cuales representan situciQ11~?.J!Ricas del d~sarr.ollo del __
softvvl.;c, ia Cui>ctbili.ad y ia e~::ol~tividad juegan un papel especial. Es1 claro que, s_i_eL.o;r:_f.:w.are_!22 ::..;>!:',-;_,
~Le~.:__IOS-rQ~~ri~ei1~?.~-9~ ...c.o_W}abilida~__ ~y9liilv'C1iCia-neceS!dad de principios y tcnicas para la .' : __
ingenie_r~ del software, disminuye. En general, la eleccin de los J2rt:g.s;_i_J2i.q.? Y-J.e.~n,\~a~ _est_ delqmin.~ ,1 . ' '
_or las metas de calidag_ge softW_!:lr ~-~~gic!_~~:. ;_ i,
. En este captulo, discutiremos siete principios generales importantes que se aplican a lo largo del _.:;.<:.
proceso de desarrollo del softvvare : rigor y formalidad, sepa'racin de los objetivos, modularidad, . :
abstraccin, anticipacin de c2.mbio, generalidad e incremenlalidatl. La lista, por su propia naturaleza, ni.) ,{1\~_;~_._:.~_
puede ser exhaustiva, pero cubre las reas importantes de !a ingeniera del software. Si bien, a menudo,
los principios parecen estar fuertemente relacionados, preferinios describir cada uno por se~arado a :. :.-.
continuacin, en trminos gen,~rales. Los abordaremos en tn11inos rn.S concretos, detallados y
especficos, en los captulos siguientes. En particular, el principio de modlaridad, se presentar en :ei '
. captulo 4 como piedra angular del dis-eo del software, ,_,.

3.1 Rigory fonnalidad

-.El desarrOllo del software es una actividad creativa. Hay una tendencia baca la falta de precisin y 1
exactitud que es inherente a cw.uier proceso creativo; y que llev~ seguir la inspiracin del momento, 1 a
de una manera desestructurar..la. El rigor, por otra parte, es un complemento necesario para-la creatividad, !
en toda actividad de ingenierl<:,; es slo a travs de una propuesta rigurosa, que podemos generar :
produ~tos ms confiables, cnti'Jlar- sus costos;--~--in'crementar nuestra confianza en su confiabilidad. El i
_!j_g~_~ __no deb_~~~~!}~gir.Ja~r~ativ_id~~-- Er lugar de ello, la mejora, aw11entando la conlianza del ingeili~-:
en los resultados creativos, um. vez que han sido crticamente analizados a la luz de una. evaluacin : 1

ngurosa. .
Paradjicamente, el rigor es una propiedad intuitiva que no p.uede ser definida d~ manera r_igurosa.
Es posible alcanzar distintos niveles de rigor. El ni.vel ms alto es el que llamamos [orn~lidad. De esta :
manera, l!...f.onnalidad es un req.1erimiento ms fuerte__ qtle _el rigor: exige que el pr~.c~-~g__Q_efi9.'f~\~'1_f_'7 . S!:-_i.
conducido y ;,;ci:luaClopor meiic.-del~y~s n;~~~mticas._ Por sppuesto, l~_f9.r:m.~l:i.~~c;U.rnplis;~ rigo_r,_ pero la: - ,
inver;sa' es
ti' Ve-rdad: se pe'lie.ser: rigw-oso allen Wlmarco informaL- .. !
'' En todos los campos de la ingeniera, el proceso d~ diseo sigue una secuencia' de pasos bien:
definida y precisamente estab:.ecida. En cada paso, el ingeniero sigue algn mtodo o aplica alglma:
tcnica. Los mtor..los y las tcJ:icas aplicadas pueden estar basadas. en alguna combinacin tle resultatlos; -
tericos derivados de algn modelado fonnal de la realidd, ajustes emp[ricos que tc;,an en. cuenta;'
fenmens que no tienen relacin con d modelo, y re8las e1;1pricas que dependen de la experien~ia . . . ._
pasada. be la combinacin d-:: es lOs factores. resulta una propuesta sistemtica y rigurosa - la_., '.
metodologa- que puede ser fc:lmente explicada y aplicada U...'1a y otra vez. ' '::::.::=.-
, . l.J'o es necesario ser _siempre formal durante el diseo 1 pero el ingeo.iero debe saber cmo y cundo
ser .formaL Por ejemplo, puede cotar e u la experiencia pel pasado y en reglas emplricas, para diseilar un
pequeo puente. que ser \.1sad-:) temporatiaq-ente para conectar las. dos mrgenes de un riachuelo. En
cambio, debera usar un model-:) matemtico para verificar si el diseii.o es seguro para un gran puente que
se usar de manera pernJ<li~enl!:_ Tendra que, usar un modelo matemtico ts sofisticatlo si el puenle
.. ?
...
;1

~;. : ~
, . .. ~- .. ~
-: --.-., r - ;""( ..-:-- . -, .. - .. :;~-~--_- -: .:.- . :: ;-: - ~:.-:---:.~: .-~ ~ .':" "-:::=:-~:-;:- .'" !'"';"'~, . : : 7 ... ~- :"" -~: , ........... : : - , ..... :--- --::""':-~-- .~,_ :~ ,. ~ r: : .:--,,: ....! , , :..... .
.. .. .. ........, ..._,., ........ , ...............,_ ............... ..........., .. . -- .. ,.... - -------- . -
~ . . .. - ..
 -:_ .~.

.' :_-::.-:::- .<-->:--: ~

l@t...~~ra e~~epcion~lmente largo, o 51 se conlruyera sobre un rea ssmica. En este.. caso, el modelo
matemtico debera considerar factores que podran ser_:ignorados en tos casos anteriores: . . \

Otro - tal vez sorprendente - ejemplo de la accin recproca entre rigor y formalidad se puede
observar en las matemticas. Por ejemplo, los libro? de texto sobre d clculo de funciones son rigurosos, .... .. 1
.
pero pocas veces fo~a!'es : la prueba de teoremas se hace de una manera muy cuidadosa, como una ... ~-
. ~

' ': ~-
. secuencia de de deducciones intem1edias que conducen a la declaracin. final, donde cada pa~o
deductivo, se apoya en una justifir.:acin intuitiv?- que deberi ~onvencer la lector de su validez. Casi
. . ;!,: 1 .
nunca, sin embargo, se plantea la derivacin de una prueba, de manera formal, en trminos de lgi~:;t
;11atemtica. Esto significa que m"uy a menudo, el matemtico, queda s~tisfecho con una descripcit1. ,-;
1
a
rigurosa de la derivacin de una prueba, sin llegar formalizarla completamente. En los casos crticos.
.,
''!

.sin embargo, qonde lf!. validez de a:ig>.ma deduccin interri.i.edia no es clara; el matemtico puede tratar de
fotmalizar algn razonamiento informal para determinar su validez o falsedad. ' , . ' 1
1 : !
. Estos eje1~1ptos muestran que e1 ingeniero CY el matemtico) deben. ~star ca.pacitados il ira !
'comprender el nivel de rigor y formalidad que se debe alcanzar, dependiendo de la dificultad conceptual
de la t~rea y de su rigurosidad. E~.te nivel puede an variar para diferentes partes de .UfJ.)11smo sistema.
. !!. i
Eor ejemp]o, las partes criticas pueden necesitar una descripcin formal de las funcines deseadas, y um
propuesta "[orriiarpa.ra.- "s"'e\i"~tluacin."-I.:a."s o~ra? pr"tes -standard.:; claramente" comprendidas~ .pclria"n
re_9~erl!:.0_o-p"~s~af~~s_j~l~ pu~s:. . ' . :; . ... ;. .~ ,-~.~x ; -'" . . . . . ... - .
j - ..... - .
: : :.:Lo mismo s~cede con l.a ingeniera:_ del. ~oftwar~,!j~l;~~Pt!tllo 5 profundiza este. tema en el contexto
de .las ~specificaciones del softi:are.! De"n1ostrarernos::qu~Pa::descripcin de lo que hace un programa
,. p~~l~?-~.~.r~~. ~e ;;una ~aner~, rigl?os_~:~~~,r1~o..;;l.~~~~?-jf}::.~atural; tam\?.[~~:~~~-~~---p~~~e describir
fom1al~ente. dancto.~.\.~1a desc~ipcin fonn~l'.:e~, :\\P;')~h~~}.tje: de. sentenc_i_a~ J.gic~.~.. La ~~!~ja__ ,?~. !__!
formahda~Lsobre el ngor es.. que la fom1ahpad. _pue~e.;;s~r la base de la mecamzacton del proc.eso. Por
. ; ej~urio puede esperar usar la' descr{pcin form<a:~e prb,aina pa~a crearlo (sl'es "que el pro'grama
no existe an) o para denioslrar que el programa. se:. corresponde con la descripcin formal (si el
programa ya existe). ! ' . . ...., .

Tradicionalmente, hay ~lo 1.ma_etapa .9~~~E:oiL~del.2_Qft~are ~!!Ja..~~u.al ~-~-~~.':l:_.la .P.~.f?.P.~~_sta

formal": l~. J~I.Q.m:,~macin. De he:cho_._L~.~- P.J..Qg@_ma~- S9~..?.~J~!os for~~~~ : estn escritqs en un lenguaje ! .
! ..
cuya sintaxis y cuya semntica estn completamente defini-das. Los pro~son_Q.~-~FiP~_0_~~~ formales
que pueden ser manipuladas automticamente por los compiladores : se verifica su exactitud, 1 sefOS
trans"fo~i1 t1 prograiila e ci i.vlen te""ei1 o"-o 1ngije (ass"il1 Gl[ o 1enga:jecre_rl}q\:iJn.)..l.-~!C... EStas-; .
. operacwnes medriCas,-~so:l.-posibles-gJ.cas-ar-so. de.Ta ...forrnadad. en. a .programac:}.n, pueden /
n1ejorar electivame~~J~~nfial2_.llid0.SJ:' 1!LY~I.ill~-Pllf.diliC4.~jQ_sJ?.r.9!.h1~~g~~l-~q~ty.,rare.: ..-... . -~
El rigor y la formalidad no estn rcstrir:.g~~~~ a_! a J?!gg.:..Il!~.cjn : <l.~~Iig~lic_g_!l;_~. _lo .Jargo_<.\_e
todo el proceso dci-5-oti\v~tre~Ercapitulo 4 muestra estos conceptos en LJ.ccin para el caso del diseo del:
"S"oftwre:El Captlo 5 describe propuestas rigurosasy formal~s para las especificaciones del software. ,y;
.1 el captulo 6 hace lo mismo pq.r:1 la vc:rificacin del software. .
.. \ ' Hasta ac, nuestra discusin ha enfatizado la influencia del rig.or y l<L.fu..[Dl3.lid.ad._e.Ll~
::.
cQnfiabilidad y verificabU_Lciact de los productos de softviare. El rig_or )1 la forJllali.9.?.c;\..ta~~1bln_ ~ienen
la
efectos beJ!ficos en mantenib-ilidad: r~usab\iiciacCportaFi'lidad, comprensibilidaq e interoperatibiliciad~
Po( ejemplo, una documeii."tci!l.--del soft~vre --rigiirosa- a!1--forral"-puCl --ine}orar todas esas '.
propiedades en oposicin a nna docu~nentacin infom1al 1 que a -~;:wao-es-a1bigua,Tnc.6!1sis""tei1te-e --
irirtpl"eta. ---- - - --~~-----------.:e----.--~-- - . --- ----:---------..
.il...!ig~y la J9!malidad tambin se. aplicari a_ ~.os procesos del software. Una docurnentacn
rigurosa de un proces(~fav"oreee. su-
reutlil"zaci"I1 en otros-
proyc.tos--simllars.-Basados- a en
d"cwentaci;~ .. ios..T~genicro:; pu~den ztnti:::~P~_r_ ..~os p~sos en
.los . q~ -~~olucl;;~reL. nuevo proy~c:;to,
s!gnar los ..recrs.os apropial.cis ..ameCiaa-(urise riee.s1iri, etc~ Asimisn1o:una-dc;~~~;ntacin !igurosa
p.rces
d~l .. d! soft\vare p~te:le. yudar a:rrliieriei. .
i-i. proii:icto existei1te_--S-i se. i~at; docwnet~t;d~-lo;
disli"tos pasos .a. travs ... d~ 1:)S cuaJes ha. evo!uCio-a."do erp-roye:Cto, --;-~- puede-nocii"fic'r~;;~ ...produ~t~-:
. - -. . - - ---. . . . . . ....
 '~ .-.

-~ .. .:

. : .

.J
......
:'
_.;,'

\
.;.!
,_....

::~, --~-.. . : . .
/1:
.. ----:: -;--: ...... --- .... : -- ---~ ... ~-- .. ,_. -~- - ... -~ . . --._- -:... - -~ ::-: .. :- ........ -. - - .. .. . ... . .. .. . ... - ...-: ~ ..... - ... :- -. ......... : .... i. :: .. : ..!. :
.. . ' . '
'" ' ,, . .., -: ..,~-,--.-:"'IT'-..-:-::"'.''";""~''''''":"'',.,~t;'"!_,_f7'"-l'~ .. _...,.,.,. 1 -"1"'''.'~:----:ro .. ~":"T':'I."'t-~'-~':;'._o:-;-~-:~l~'.'~ :_t':
 -.
---~-.:._.;._

~- ': -: . Ot~~ tipo im;ortant~ d_~~P.~r-~~!9.~ -~e:__<?bj~-l~_Y_?._?._ ~S_CI~nsid~rar el,:.'.9.fl.".Y.~E~--d~sde uj_~_ti!1~~?.P~11!l_9.~~

' !
: ele ,,ista yanaiiZailOS-pOr separado. Por eje1nplo, al analizar los requeri1niento_s de un aplicacin, puede ;_
. ser 1:1rconcentrarsesepa,1dai11ei1te en el flujo .de datos_ de una. actividad a otra del.sistema y en el Dujo :
la
!de control que gobi~ma manera en que se sincronizatllas distintas ac.tividades. Ambos pW1tOS de Vista :- _: ~ r .,
-~ :~o~. ayud~n a .comprender mejor el sistema en el que estamos trabajando, pero ninguno nos da una visi,n _ H,,. ,, j :=:~
completa de el. . : ;"'. , .. i
..:: .. , _, Hay incluso-otro tipo de separacin de objetivos que trata l~s lliferentesparteS e un sistema; ~c . >:::!_!. :~; f
...:,la s~paracin es e~ funcin c!el_tam~o. Este es. un concepto .fundamental que necesitamos manejar para :l
\ ~~::::~:,:~: ~~j~~~~ ~~~~~~~od~~::'i:~d~d sort"~r~: Es tan importante que preferimos.~ratarl b como un ],__ !_..- __:_:___-__:_': ,_1

:' .: Podramos _sospechar que hay una desventaja en la separacin de objetivos : al sep:;trarlos en dos o .
ms partes podramos perder la optimizaci-n globa 1 que se obtendra abordnd?[os jtmtos. A menudo '' . ! )J' :;
. esta objecin pone demasiado ~nf::l.sis en nuestra ~labilidad para tomar decisiones "ptimas". Cornbir1arid6 _.d. _:. !
.. los objetivos, es ms probable que to!Jlernos las decisiones equivocadas porque no. podemos vencer la ' i
complejidad. Ep cambio, podremos superar la complejidad globl de un sistema, concentrndonos -en sus 1 '' .: ;
dift1r~ntes aspecto~. separadamente, an a expen$as tle pen.ler alguna optimizacin potencial. , / .;. i,;
. . _: .. _- Ntese qu~: si dos aspectos de un problema estn est~echarnente relacionados (por ej. no podernos 1 ! :::,.: }L:
separar el probleffi.a en dos partes), a menudo es posible tomar algunas decisiones genei-ales y luego ! >}it-~\\.11:
ef~~tjyamente sepa_rar el obj~ti~ en sus distint~s partes. Por ejemplo, consideremos n sistema en el ;, . ._<~~;.!}
cual' se ~ccede a umi base de datos en forma concurrente mediante transacciones on-line. En una primera : .. >;,_: ;;-
imple~'i~ntacin det sistema, ada trar1sacc1n bl?quea la base de datos c_ompleta al iniciarse, y la libera al ' "-'-l'"'"'
fin~iza[. Supongamos ahora qne tm anlsi~ jrcl.iminar de la perfonnance, nos demuestra que una ! , f :{;,:
lrans~scin t (que podra ser ~ gn listado complejc q~e extrae datos de la base), demora ms de lo que. l.; ', .:
podems tolerar para dejar la base de datos disponible para otras transacciones. Entonces el problema es :
corregir la implementacin de manera tal que rilejore la performance manteniendo la correccin_ gel"!eral i
del sistema. Se puede ver clara:nente que los dos aspectos - correcin funcional y performance - estn '
fuettemente relacionados. De e~.te modo, una primera decisin de diseo debe considerar ambos : t no i
. puede ser implementada como una transaccin atmica, sin que debe di~idirse en varias subtranscciones i
tii ; t.2 ' ........ , .. tin cada una de e'<las.almica. EsUi."1'1ueva implementacin-puede afectar la CQtTeccin del
sistema debido a' una posible intercal~cin entre dos transacciones. Ahora, sin embargo, hen:~os .separado:
los dos objetivos; la vel'ificaciride la correcci fw1Cionai y ~1 anlisis de la performance. Por lo tanto se ;
podrn hacer anlisis distintos, incluso: hechos por personas diferentes con diferentes experiencias.
Como observacin final, ntese que la separacin de objetivos puede derivar en una separacin de
responsabilidades para tratar diferentes aspectos. As, este prin~!P.i~--e~Ja_J?ase par~.. Ji yidi_r _el lra~aj o
sobre un problen~a complejo en asignaciones de trabajo especficas, p~qp~blemente a diferentes personas:
con{Jstnt"s--habilidds ... Por ejemplo: separando -los aspec~os tcni~os de lo~ d-~- ~-~dccio.... periittnos
iaco'Operacinde dos ,tipos de individuos diferentes en el prC:Ces'Ciel software. o'tro ejelplo es que al
y
separar el anlisis de requerimientos especificaciones de las otras actividades en el ciclo vida del_ de
software, podemos contratar analistas especializados en el rea que nos interesa en lugar de depender de
Jos recursos internos. El analta, por su- parte, podr concentrarse separadamente en los requerimientos
ftm~ionales y no-funcionales del sistema.

Ejercicio

3.1 Escriba un programa simple en el que pueda demostrr que trata separadamente la correccin y_l,a '
eficiencia. -
\

...
- ~ 1 5.
.
_,;, ./ ' ..
: J
-"
,... /
.

,~,, "' '-"'' ' - - ....,_~. ,.,,.. , . , ~"f '~..-:ro;. '':::- '' l o,
 ~~J::'.:;.>:~I~dularid:~:d ..< . ,: . ,.. . . . ,.,,,_.

~n~;~.J~:~ compl~j~puede diVidirse en pietas n'.as p~q~<fi;,. denominadas mdulos. Se dice ~ue un
:sistema compuesto por mdulos e.s modular: La ventaj~_psjp.c~.P..-L2:~J~__mqcJ~(a~:!ad __es __que... pennite .' / ;'
..

aplicar el principio 9e sp~raci<)n de objetivos en dos fas~~ : cuando se tratan los detalles de cada mdulo
~for1aaiSThaa"{e' ignotando:)os detalles de 'iosotros rndulos) y cuando se tratan las caractersti<(aS
generales de todos los mdulo y sus rel~ciones para integrarlos en un sistema coherente. Si estas dos
fases se ejecutan ter11poralmente en ei orden mencionado, decimos que el sistema est diseiado boa~_;,ir . ,,
up (de ~bajo hada ;'..rtiba); la inversa e~ el diseo tup-duwn (de arriba hacia abajo).
..?

. La...!llQ_dulatidC~;d es ;_;r;,~i;GJJJied='3:tDl:dYlmR9J1.:;~,nt;.. pc:::~::..l~- mayora de ios procese;:$ y_yr~~<?.~.~s _:~e.

in.gen.ie_ra. Por ejemplo, en la inciustri~ automotriz, la construccin cteTo_s_ccE'ess.elec'ti:iaensamblando
b!o~es ...gye. ferci'""diseados 'y construidos por. s-parado~- Adem.s: 6I disen.o dichas partes. 's .. de
~ti~~do de m~ct"io-~n modelo, probablemente luego d~llaberle hecho pequeos cambli.li1i!~~ia. . ''
de l'osprocesos-d.tistiides so e~cencialmente mod!ares;-hethos 'd paqeies de. tra~ajo. c~mbinados "(i"e .. .
maneras sencillas (secuencialmente y. por superposicin) para alcanzar el resultado deseado. 1

.
:
:,
. 1

~jercicio
---~----~-~-------~---~---------------------------------------------------~----------------------------------------------------------
3.2 Describa los paquetes de trabajo involucrados en la construccin de una casa, y dern uestr~ como se
organizan secuencialmente y en p,!lialelo.
1

'Enfatizaremos la modularidad en el contexto del diseo del software en el prximo capitulo. 1

.. La '
modularidad no slo es un principio deseabk para eLdiseii.o sin tambin para la produccin completa :
del software. En particular, hay :netas qLJ.~ la modularidad trata de alcanzar en la prctica; 'la capacidad .!
de deseo m pon~r U1 sistema conJ g~o, ~-omp.on~L~P _a-:~~!".~.~r_ g~_.n~_9.9\dlQ.~--~sJ:,;nJf-_s_,~_y la comprelisTci :;
-~el sst~~-~Q.OJ...Ra!Jes.
_La de5J?J.!ll.f22!.!ib iJ!~.~(~~~.~.~. ur~ ..?..\~_teina es}~. -~~.s~da en)0_ d.iyj~9n d~ __llD,_pr.o.Q~~.tn.,a origi'n~_.~c.?.I?-d~wn
(de arriba hacia abajo) en subj?.it!_j.)le~sy en, la aplicacin de la descomposicin a caJa subproblema-en
forma....recursi.va. Este .P'rocd1miento reE-Uaeroieti.coocdodtcho-Cki"la-dlvide"efliilj.Jera (divide y
re:inars), ~ describ~_!~L?~~:!}~ practicada p_or los antiguos romanos para ,dominar otras naciones:
diy~~~~"J~?.. Y..~.i~l~!!~~-pnm~:.o, y c:onquisiarl~S.l~~-~C? in?.L'fiduali:J;l~n.~. .. ;
La componibilidad de u.r~-~!2-~m'!-_2.e__ p_~~~---~P.3.2!!.1.~.n:?ar desde ab<ljo ha.~.i.~. a~~~a. (bott_om up).
parti~~)~Io ..ife..los. compone.t}t~.s. e!_~~~-~ntales y prosiguiendo co.n el sistema te~in~do. Como ejemplo, un
sistema para a~romatizacin d':~ oficirias .. poCI.da ..disehai:se "e1sli1blando los componelltes de hardware
existentes tales como estaciones personales, .una red y P.erifricos; sistemas tales como sistemas
operativos y herramientas de productividad tales como procesadores de documentos, bases de datos, y
planillas J.e clculo. Un coch:~ es otro ejemplo obvio J.e un sistema ensamblaJ.o por com.ponentes.
Considere primero los subsistemas en los que se puede descomponer un coche : el cuerpo, el sistema
elctrico, el sistema de encendido, el sistema ele transmisin, etc. Cada uno de ellos, a la vez, est.
fonnad por partes standard: por ejemplo Ja batera, los fusibles, cables, etc., que forman el sistema
elctrico. Cuando algo no func\ona, las p?;rtes. d~fectuosas pueden reemplcu:arse por otras nue!'as. .
__r&armej}t;'~l~p.C;iu~.ci.ll...uci:..software, ~~~.aramos.poder. ensamblar las nuevas aplicaciones
tmando mdulos de un.a .b!.bJi.ot.e.~a y combinndolos para formar el producto deseado. Tales .m.dtifos->. .
deberan hab.er-sict'-di~eados e o~- ~1" ~bjetivo expreso de ser re-utilizados. Utilizando componentes':,:: .
,
,.~

rtisbies,-pod~~-os ag1iiZarla construccin inicial del sistema y su afinacin posterior. Por ejemplo, .sera .
posibi"e" reemplazar un comp:)!le.Hte t)or otro que 'realice la misma fw1cin pero que difiera en la. . 1

utlzacin. de }O-~ recurSOS C(Jrnputaciona[es.

.) .. ;; 6 .
'. l ......
'\ . 1
., .' . .. .
.'1 ... '.t.'
....: ..
. ,: '
... - ~ ...... - ... ,. : -~-" -- ~ . . ~ ......:,.~. :.:. . ":- --,.. - ::::.-~ :.; ..... :-::-. -::" _.................... -~ -~ ...... -.... :: . . ~:-- ,....... :..... -4 ~- . ._...: :: .:~.: :
-~~,.-:;:-!tr:";'"'";--":":""'":''- ,. ..
.'
,.,.,.,_._, ..
. ~
 \ ~.

..
..- . .....,,..
... . .. .....
~------------- .

. , ..
~!GURA 3.2 Descripcin grfica de cohesin y acoplamento. (a) Una estructura fuertemente
acoplada. (b) ..Jna estructura con alta cohesin y bajo acoplamiento.

. La capacidad de ~omprensin de cada parte del sistema por sparado, facilita su modificacin. La
naturaleza evolutiva del s'oftware es tal que a :1enudo se le pide al ingeniero que vuelva atrs y modifique
su trabajo anterior. Si e[ sistc:ma slo , puede .ser comprendido en su totalidad, ser dificil hace{
. modificaciones y el resultado ser poco confiable. Si sw-ge Wla necesidad de reparacin, una modularidad ' ..
. apropiad~ nos ayud~i-i a buscar el origen del problerm1 en 'cada componente individual. . :., , i'

>: ~ ,../P.ara'poder alcarii:ar conipf..ibilidad,'descothpO'nibil~dad y_-:c~ompren?in, los md~l,l.os de~eo ten~r.. : : :>
_<:~ alla.culzesi-y-bU.J ~copliirrieriirJ'.~ .. --- .._. -._., ...:,~:..... ;:--.. ' . ~".
-: --=----un:-.mdl'o tiene alta. c.ll.esin si todos sus compo11entes estn relacionados fuerterriente. Los ;.. , .. ,:
el~me~tos. de mdulo (por-ej."1ii:rtrucCi"oies, procedimientos y. declara~nes), 'se agrupan jun~q_s en un...~ . :.: ;_-
wf.?ffi_Q~ID..dulo_p_qr ~na raz!l- Jg~ca, nq al azar~ ap~~tan ~ un objetivo comn qu~ es ei fu~i~~ami~~- . . :. ~
del mdulo. , :
--c;~~s~~-~.P'J.ndo que la cohesin es tma pro:iied0d interna de un mdul9, el acoplamiento caracteriza ,!

~J.;ldel mdulo con otros nHSdufos. ~l~?~l~r-~i~r:to mi~~ la interdepende.n~Ia ent,r_~ __uo.~. m~-~!C?..f ... ,
(por ej. el mdulo A llama a una n:.tina provista por el mdulo B o accede a una variable declarada por el . ; ::.:: !
mdio-B)~'"'"fO's'r:ncJ.ulq~ dependen pesadamente lUlO del otro, tienen un alto acopla):i~nto. ldeaJn'ente-... ; ::> ,,: ;
deseara~os que los mdulqs .d~~u sistema.'ti.ivieran un bajo' acopla.miento, porque si Jos 'ni.llulos estn. i . <.' .
altam~t~~co.piad(;;;::s~ -~o~plicar el anlisis,. la :compr~risin; la modificacin, prueba o reutiliiaci.n de . ~::::! l . :"..
cad~ Wl?d:e elra-sp~f'.separado .. Lafigtlia 3.2 nos pa u,na vis~n grfica'dela cohesin Y; el acoplamiento. .. .-; ~_.,:!' f:\!;
. ::::.un:buen ejemplo de un sistema con alta co)Je~ir1 y)ajo acoplamiento, es el ~ubsistema elctrico- ' .. )Y
de Wla casa .. El sist~_na tiene bajo acoplamier~to :porq~~ ~st compuesto por un conjunto de artefactos con ' t ,1
funciot~es clarame~te definibles e intercone~tado~. pr' si~ples cables.: Tiene alta cohesin porque los 1 :
componentes inte1:nos de cada' a~rarato son e.x.acia1ente los necesarios para que ese aparato ctJmpla la , '
1

funcin para la cual fue creado:.' ; ':i.

~~s estru~t~~ili, m~dulares con alta cohesin y bajo acoplamiento nos penniten ver los nidulos
como caj~s negras cua~uo uescfi~iiii.os_la..estr~ctur~_~ge.eral-Jet-s1s.tei:1ui~-Y. tratar co cada JA9..!J~i.9-J?oC
s'ep.arado cuando se .ds.cribe-:o .. analiza .. la funcionalidad del:
-iisrno. Est~ es justamente otro ~jemplo del-;. ! ';

pr{cip-io-C1sepiti-'a.i'6~?=~e-:b.j'CTi~::-s. .. .. -- ..
.- ---~ -- .
Ejercicios
.J

3.3 Supongamos que decide modularizar la descripcin de

un. coche dividindolo en pequeos cubos de
15 pulgadas de lado. Discu(a esta modularizacin en trminos de cohesin y acoplamiento.~
Proponga i:ma mejor manera Je modularizar la descripcin, si la hay. Saque conclusiones generales
acerca de cmo se debera ::nodularizar un sistema coinplejo.

,
3.4 Explique .las..causas y soluciones para la baja cohesin. en tm mdulo de software.
; '
)
\ ..: ::,
3.5 Explique las: causas y soluciones para un alto acoplamiento' entre dos mdulos de software.
',1
------------------------------------~:-----------~------------------------------------------------------------------------------------
~
.\
.J

)'

..1
_)

-1
) ,' '
.. t;. : .... ..
_

-.'
''
 _,. __ . '
... '"

La.abstraccin es el proceso por . el cpal identificamos los. aspectos importantes de un fenmeno e

. - --. ------- . . . -. ... . -, . . . ' . . . . . ... . '
i~~~~~--~';IS Q.etalles. As, la abstraccin es un caso especml de separacin de objetivos, en el cual
1

.separamos los aspectos ilnportantes de los deial!es que. no lo :;on. !

'
. Depe~~~- d~,l p,rpp_6sjto qe la abstracci<?.n! cuaies aspectos sern. abstra(dos Y.. qu _det~~~~~1..POdrn .. 1

ser ign.9!:.dos. :por ~jemplo, consideremos un reloj d~ cuarzo. Una abstras:~in til pani. el.usuario es utia i1
.es~ripcin de ios'efectos al apretar los diferentes bo_tones, que le permitirn entrar en los diferentes '

nL>:.hs.J."tricionsrniento ) ;,~3-f:(:i()nar a la.s distintas secuenci.as de comanuos. Una abstraccin til para
- . . . 1 1 --- 1 . - - -
la persona a cat"~G del mam~;umer~n (.<:.: J.lOJ e~ :.!n:3 ca_'a que. pue:j::. anrse p~\Ia re:;;~lph7.;:;.r h b.(l.tena.
....--..~ ......Podemos ad~rris t:ncorlfrar. otras bstracciones ..~t1is para comprender y manejar las. actividades
necesarias para mantener el reloj de cuarzo. De este modo puede haber muchas abstracciones diferentes
. para la misma realidad, cada una dndonos un punto de vista distinto y- sirviendo a algn props~lo . lli:

especfico. ~ 1
1

Ejercicio
.i
1
3.6 Diferentes personas intenictuando con ui1a misma apliccin pueden requerir diferentes 1
i
abstracciones. Comente brevemente qu tipo de abstracciones son tiles para el us~tario . .
final, el ~iseauor y la persona qt}.e hace d mantermento.

La abstraccin es una tcnica poderosa practicada por los ingenieros de todos los campos para 1

ppder manejar la complejidad. Por ejemplo, !a represe~tacin de un circuito elctrico en tm1inos de i ..'
resistencias, capacitares, etc,, cada w1o, cnract~rzado por un modelo en trminos de ecuaciones, es. una i
abstraccin idealizada de un di~;positivo. Por un lado, las ecuaciones son w1 model simplificado que . ~
aproxima el comportamiento al de los componentes reales; por el otro, el modelo que construimos, a '
menudo ignora detalles taJes .CytllO el hecho de,que !10 hay conectores "puros" entre componentes y que
esos conectores tambin deber~n ''ij~9Jelauos en lrn-linos de resist.encias, capacito res, etc. Ambos ser
factores pueden ser ignorados por el 'diseador porque los efectos que describea son despreciables en
trminos de los resultados que deseamos observar.
: Este ejemplo ilustra una irnport;:mte idea general : los modelos de fenmenos que construimos,
- tales como ecuaciones para de~;cribir dispositivos..: son una abstraccin de la realidad, ignorando ciertos :
hechos y ~oncentrndose en otros que se consideran relevantes. Lo mismo se puede aplicar a los modelos ..
construidos y a11alizados por los ingenieros dd software. Por ejemplo, cuando anali.zan y especifican los .
requerimientos para una nu~va aplicacin, los ingcnier?s del software construyen un modelo para dicha !..
aplicacin. Como veremos. en el captulo 5, este modelo puede expresarse de varias maneras,
dependiendo dd grado ue rigor y fonnalidad requeridos. No in1porta qu lenguaje usemos para expresar :
los requerimientos- sea ellen(,'1.laje natural, o bien el lenguaje formal de las frmulas matemticas- lo ;
que producimos es Wl modelo que se abstrae de corllemplar" una cantidad de detalles que hemos decidido
ignorar sin correr riesgos.
La abstraccin afecta :t la totalidad
. -- de la programacin.
'
Los lenguajes de programacin que
usamos son abstracciones CO!:lSlnlidas en la parte ms alta del hard\vare (top) : ellos nos proveen
. construcciones tiks y poderosas de manera tal que po~nmos escribir la mayoria de los programas
ignorando detalles tales como \a cantidad de bits usados pa,ra representn.r Jos nmeros o el mecansrno de
direccionan~iento.' Esto nos ayuda a concentrarnos en el problema a resolver ms que en la fonna de
decirle a la mquina cmo regolverlo. Los programas que escribimos son, en s mismos abstraccior1es. Por

r>_
.1
'l. ~:.-.
...
:) . . :1

o "' o" ~ o - ;, : ; , : . ' , , , , , _ , ::-.o , :: '.' : ; '' :: .'"' -~-:,_J:' :;":":-'".', .-o::.,,,.,,, __ -: -;--;,.. -: rr-. -;: :'- :, ~- ,. 0
: ' '' .... : .: ' ' ~= '': ~:: ', : o''' .' .>;. ,' .._ ; .. ;-~l,"!''
o
00 0
.. 'ooO~--~-;----- ... -:---=r-o-oooo.' ;o --~r.~-:-r',O rr:- r .....--~----,;-oH'-:':'' .. O0 O00 0 0 0 o
0 o O:- 1' O
 -. ..

). ' . . . . . . . . . .

>: ,~;.~pl;,
1
un sistcmade pago de sueldos compularizado es uta al):ll.
) ~:(_"reemplaza: contiene la escencia del proceso manual, ~o sus d~talles exactos.
. . . ... . . .. La abstraccin es un principio importante que se aplica tanto a los productos como 3. los procesos.
~-. :Por ejetnplo, los con1enfarios que aparecet~ en el eticabezamiento de un pocedimiento son una
1.: . :abstraccin que describe. el efecto del procedimiento. Cuando se analiza la clocum.entacin del programa,
1.:.1 ' se suporie que tales comentarios proveen toda la i.nfonnacin que se necesita para comprender las otras
1 1.:::: partes del programa que utilizan el procedimiento. ' .
. ~j. <L.:., :: Como ejemplo del uso de la abstraccin en !os procesos del software, consi~leremos el caso ele una
j. ::.:\:stri~cin de costos. para una eva aplicacin. Una posible forma de h:~cer 1?- estiniacin ele co~tos
::O' :consiste en identificar algunos factores clave del nuevo sistema y extrapo~arlos 'de las estimaciones de
:.:~; , -<c.osto de sistemas similares anteriores. Los factores da ve usados para bac~r el anlisis son abstracciones
1 . .
, . del sistema.
''
11
Ejercicios
-------------------------------------------------~----------------------------------------------------------------------------7-----
. .
/ '. '3.7 . . Las variables que aparecen el los lenguajes de programacin se pueden ver como abstracciones ele
' las posiciones de memoria. Que d~talles no se consideran pam ia abstraccin de las variables de
.-... los lenguajes de programacirr? Cuales son las ventajas de usar ai)slrat;cin 7 Cunles so11 las
' . . desventajas i
~~, .:. :-_ .:.:: . .
) . . .
1.
."\
..l.-
. 3.8 ,Un modelo del ciclo ele vida del software, la! como el modelo en cascada delinc::ldo en el Cllpitulo
'.
.1, es una abstracCin de un proceso del. softvvare. Porqu?
. . .
------------------------------------------------------------------------------ ---------------- ------------- ----------------------

3.5 Anticipacin de cambio

,,; . ;::\
.J

El. software sufre cambios constantemente. Com<? vimos en el captulo 2. los cambios se deben tanto a la
: -~ : necesidad de repararlo- eliminando errores que no detectamos antes de liberar la aplicacin- co111o a lrr
..,,... ' necesidad de dar soporte a la ev!citr de la apl{cacin a medida que. ;,p;1reccn nuevos requerimientos y
catnbian los VIeJos. Es por eso que idtltifcamos la manteujbilida.d eomo una de lns prncipnks
propiedades del software. ---- -:-:-:._..
La habilidad del software para evoiucionar no es gratuita - requiere \Ul esfuezo especial pcira
anticipar t./::'io y cundo ocurrirn Jos posibles cambios. Una vez idenlifdulos estos cambios, se debe
tener especial. cuidado en proceder de manera tal que en ei futuro scc:.n fciles de aplicar. Verer~os este
. importante puntoen accin en
el captulo 4, en el caso de diseo. Den",ostraremos cmo se puede disdiar
. el software de muner tal que esos posibles cambios q\,le anticipamos en los requerimientos. o';
modi.Qcaciones que se planean como parte de la estrategia de discfi.o, pedan ser incorporad.os a la
aplicacin de manera suave y segura. Bsicnmente 1 deberamos aislar los posibles cambios en porciones
' especficas, de tai manera que las modificaciones se restr~an slo a pequeas porciou'es.
La anticipacin de cambio es probablemente, el nico principio que distingue'al soflwu de la
. mayora de Js otro.s productos industriales. En muchos casos, se desarrolla una aplicacin cuando sus
requerimientos no han sido an, totalmente comprendidos. Luego, despus de liberarla, y basados en ;i
..realimentacin del usuario (feedbaCk),- la ap!ica.ciri debe evo!.1.:conar a medida que se descubren
nuevos requerimientos o se actualizan los viejos. Adems, las apl tc.aciones existen dentro de un medio
ambiente, tal como una estructura organizacional. La introduccin de la aplicacin afecta el ambiente y ,
~O esto genera nuevos requerimientos que no estaban presentes inicialmente. As, la antici:mci,n de cambiQ.?..:
:~ ( ;-. es un principio que pod:!_l!.?.~ _us_at_para_ o~_t~ne_~_}a .. ~:-:.~.!~-~iy!~!l~ ----- --------------
~~r~ \ -- ----'L~ rusab-li~ad- eJ._..Ptta prOt?~:~a.re q~~~-...e~t fue.t"te:~!ente_.afectada_~a anticip~ci?!_l
, ..: ~ . de cambio. Como vimos, un componeJte .es reusable, SI se lo puec~c usar dtreclamente para proch.tctr un
.' <_;_ ----- ' . -- . ' o'
.:() . . ..
~ /
:::a ( ~"'- ~ :-~-:.-.-_:~ ,----.- "'-~.-.,. ~-:,; :: . -----.--. .-::-- - ......... :.~ ~........ --;-.-..----.: .._......... .-. . . . . .- . ... -.-.-f ...-- .. . - -. ..... - .... --~--:
. . .
...------ ..
--m,,.""'f~lifiili!'c'!"?iji~i;i~JW~@illiQSi'J.;~~~:~!i~~~~~~~(~, ,.;; r
 ~;.
.. .. . . .

~.u~ vo prod uct?. O, de una mane;:a mas realista, podra sufrir :~m b ios le ves an t:" de s~;reu:a~~:.c ~~!''"-:'.,/'~>~~c. i.~,.:l 0

tal, la reusabilidad puede vers_~ __C:_~~.~~ tu~-~~-~~l_~I_9a_9_~.~.P~CJ.::l~na ~,S,~]g, .R9.I..f!.:...~::._qlgtiv.Jgad ~!.!~~~ !-~~- _ ~ .~
c~~es. Si pbde~no~-atiCip .. los-cai1i.b.ias det contexto er:
e_l cual se encuentra_ 1:1n componente del -: ..'.
sOTtware, podriamos d1senarlo de manera tal que se ac.o!1loda.ra facdmente a Jos cambtos.
La anticipacin i:le cambo exige disponer de las herramientas apropiadas para manejar las i
diversas' versiones y revisiones del software de \.lila manera controlada. Debe ser posible al1acena( y
reGuperar UOCUIUentacin, mJu!OS fuente, mdulos Objeto, etC. JesJe una base de datOS que acte COnlO
depsito de componentes reusables. Debe controlarse el acceso a la base de datos. Un sistema de
software debe mantenerse consistente an cuando se. efectuen cambios en algunos de sus componentes... ... :
Tal como dijimos en la secciu L:.l.2 -y ccrn;J ':-~remo5 nuevalm:ntt- en b:: .:;;:..~ituios 7 y 8- la di<>ciplina 1

que est~dia . esta clase de problen1as se llama administracin de la configuracin (conftguration

------------------ ---~------
management). ,.
EJul.ues.tra...J~cusiil sob:e la anticipacin de cambio, concentramos nuestra atencin ms en 'los
}Jrductos, que en los pi:;C-;~os-ci..~f_s?.ft~.~-~~-e_.--Sii~l-~mb;rgo, ]a intJc:}.'lc]Oi}aeca-ibto.tambJ'--afecfaah
adi1~rilistracn delp:oceso--dei ~oftwan;_ Por ejemp!o, los r:::sponsables deberian anticipar los efectos de
la rotacin del personal. As mismo, cuando se Jiseiia el cicLo de vida tle una aplicacin, es importante
tener en cuenta el rnantenimie:1to. Dependiendo ele los cambios anticipados, los responsables deben
estimar los costos y diseii.ar la estructura ~rganiz.acional que soportar la evolucin del software. Tambin
deberan investigar si vale la pe;1a in.vertir tiempo y esfuerzo en ia produccin de component~s reusables,
~ . ya sea como parte del producto o como Llll esfuerzo de desarrollo paralelo.
j.''
Ejucicio
~
'\
3.9 Tome un programa de ord!:namiento (sort) de cualquier libro de texto. Disciaio desde el punto de
)
de vista de la reusabilid.1d. Podra reusarlo si el tipo de componentes cambia? Que pasa si la
. :J
'. secuencia Je valores a ou.Jenar es tan larga que hay que usar un alm<H.:ena111ento secundario para :.:. .
) almacenarla? Co111o moJi 1\c;:~ra el programa para mejorar su reu:;abilidad bajo esr~s circunstancias?
., Basado en esta experiencia escriba w1a lista de sugestiones generales que favoreceri,~n la anticipacin
., de cambio en un programa. .......
1
. .. .
--------------------------~----------------------------------------------------------------------------------------------------------
',.-'
1
.':"\
,,
3.6 Gcn~ralidad
~
- 1

e:
e: El principio de generalidad pu::de enunciarse de la siguiente manera : ! !
i
("\
'-"'
. Calla vez. que se le pide que resuelva un problema, trate de concentrarse en el
c.~
~
descubrimiento de un problema ms general que puede estar escondido detrs del
e:J problema consiJerado. Puede suceder que el problema generalizado no; sea ms
.\o

(':~. complejo- incluso j)UCde ser ms simple- que el problema origin:J.l. Al ser ms general,
o es posible que la so lucin del problema generalizado tenga m :; potencia!, para ser
reutilizado. Puede Sll:~eclcr que la soluCin ya exista en un sistema empaquetado.
(J
Tambin puede sucec~er que al"generaliz:ar un problema termine diseiia.ndo un modulo
o que ser invocado en ms de un punto de la aplicacin, en lugar de tener vanas
C
..1 soluciones especializadas .
e .:)
r, --'
Por otra parte, una solucin generalizada puede ser ms costosa, en tnninos de velocidad de jec_ucin, o:
,,_j tiempo de desarrollo, que la :;olucin especializada que se ajusta exactamente al problema original. A.s,:
1
( l

j~
( __ .

l1'\~...
, , , , . , . o-:"r oO ' ooOPo -:"''''''0'" ooo 'O"''''' -:~o.oo~:oOo.oo.o .. ooOR~:
 :..\

":-" ..-. :: ... ...

_,, ....
.- . .,::... .. ~,-.: -:.<

[9J..'> 'ne~~~ari~ evaluar las distintas coubinaciones ele la generalidad, con respecto al costo y eficiencia, con
' el objetivo de resolver el problema generalizado en lugar del problema original.
Por ejemplo, supongamos que se nos pide que intercalemos (mcrge) dos archivos ordemidos
produciendo un rco archivo tambin ordenado: Basados en los requerimientos, sabemos que los dos_
a~c~livos de entrada no contienen ningn registro con claves duplicadas. Ciarame.nte, si generalizamos la,
solucin, de manera que podamos aGeptar registros que contengan elementos d~ferentes an con el mismo
valor en la clave, obtendremos un programa que tiene un ms alto potencial de reusabilidad.
Como otro ejemplo, supongamos que nos piden que diseemos una aplicacin para organizar una
pequea biblioteca de -recetas. Supongamos tambin que. las recetas tienen una informacin de
encabezamiento que contiene un nombre, Ui1a lista de ingredientes, e infonnacin para cocinarla; tambin
contiene una parte textual describiendo el procedimientc. Adems de almacenar ias recetas en una.,; .
biblioteca, debe ser p~sible efectuar una bsqueda sofisticada basada en los i-ngredientes disponibles, el'
mttximo de caloras, et.c. En lugar ce disear un nuevo.conjtuHo de rutinas, estas bsque_das pueden verse
como un caso especial de un conjunto ms general de rutinas para procesamineto de textos., como las que
provee el lenguaje AWK bajo UNJX. Antes de comenzar el diseo de un conjunto especializado de
rutinas, el disenador debe considerar si la Jopcin de uua henamienla para pr.ocesm~1iento ue textos
generalizada puede ser ms til.. Sin duela, una herra~ni~-Il~~-g~l}~~~-U~C!Q~.esJTis_c.on.fiable. que disear un_
programa especia!!_do , y probablemente se~"cie a lo~ cam\?J.Q?_~!lJ9..S..X~.9.~~I.(!uienlo..s, o incluso, a
nuevos requerimientos. La parte r:egativa, sin embargo, es que p_ued~- haber__ll!!.S:.2~~-q__Q..~. adq~~i?isi.QT_J._ y_
glstos-ad!CaT~;-e el uso de una berram1enta generlizacia~-- -.
- La generafioaaes-lin-prii:i;::pio-fuilct"ament;T-sl:-}~i.stra meta como ingenieros del software, es
desarrollar herramientas generales o paquetes para el mercado. __E.Lxito_cie __ herramientas tales como
. planillas de clculo, bases Lle datos y procesadores d~ t~:o, reside en que son l~SL[~r~[e;;lenie
generaiesc~r~-r~.r:a cbfr- ias-n~;c~sTd~cte:~-p-~actl"~~t~:;de-1~ a.Y_()ila ele T~-g~~~--c~;a~d~deseari~l~n~]iir-
smasUiilos personales con una computadora. En lugar de crear solucior1es especficas para cada neg.ocio ,.
p.i-soar;~-s mi.(e.co~;uico elegir entre los p-roductos .que se. encuentran disponibles en el mercado. !
~~!os .~J~~o~~9.~~~-~rnpaq\l:l.~~?.~~-~:a...~~~--l?..~_psito gen_::)~-~.?.}_epres~-~~~~2 ~~n~ tenden~ia bastante :
generalizada del -software. Para cada area especrfica de apl1cacwn, ex1sten cada vezmas-paquetes-:
.g~~les _qtie. p~ov_e_e.l-so~~~~ii~c~~- ~ii~.;~~i?T9. ~- iJ_roblei:~s<~-~~~~n~. ~ -~-1 _.e~_l?.l~-~~~- p_ued~_ r~_cjefi!D.~?.~~~n~o- ;
una instancia de un problema q:.1c es posible-re-sol\ici'- mediante un paquete general, podra ser rn$1
C.Oil VellJentc.adoi).taLdicho. i)ac(u"etfe- lugat de. i1hple)etar-na SOCJO~e-s.i).e.Cl~izada:. .. .. ... :
Esta tendencia general se observa tambin en otras ramas de la industri~~--- Por ejemplo, en Jos! i
inicios de la tecnologa del autcmvil, era posible construir coches de acuerdo a los requerimientos
especficos del diente. A medida que este campo se industrial iz, los clientes pasaron a degii de un
..[::
catlogo de modelos - que corresponden a soluciones pi"e-empaquetadas - provisto por cada fabricante.
i
En la actual~acL.P no es posi.bk pedir un coche con un disei1o_.P.~I~onal, a mer1o.s que
r~an.sLm;aae-Jmer":- ----------- ------ .. -, ------ :-
est dspueso__ a
. .
se r
- __ _:=------:-- .. . . .. . ....
f
f
3.7 'Incrcmcntalidad
1
La incrementalidad caracteriza a los :rocesos que se ef~ctan paso a paso, por incre11"\entos. La meta : r
f.

deseada se alcanza por aprximaciones sucesivas. Cada apro:Umacii1 se alcanza a\ 'travs de un !

incremento de la anterior. . . t:
La incrementalidad se emplea en muchas aclivida<;les de la ingenic1a. Aplicada al software: [
significa que la aplicacin desea::ia es producto de un proceso evolutivo. ; t
Una manera de usar la iucrememalidad consiste en ident~.:t;~ar Sltbconjunros iniciales que pueden
desarrollarse) entregaise--lclierile," .... . ..
coil el ..objt:to de obte.ner w1a re!inH!ri{;;~;~; !mn;ancl
feedbac:k):--Este_~0.!ijte __qu~ __}a_ap!ic_aci:l evolucione ele manera c6'nirolada
r
(early
los. casos en que los .. en ..
!i


req_~1::-irilientos iniciales no son estabks o no fueren completrullente corilprendiclo~. L.a motivacin para ..

11
\ '\ \
\\1/

- " ,,. - ' ,. ' ' 1 ' ' ' -' 1. _.:7 . ,.,: ' -.' "''': ,-.
~-.:: : .,,,. 1 . .:.; .... ., --.' ... ~-; ':-:- . - T - ~-~ _:" ,-, -:: ' ," : - - --~ -"':":: 1 ' " - -::: - : "r . , .. ,, :- .. :: "\ " 1'"'
 .. . .. .. .. . .. . ~
'' - -...-_

-~~L)_~J!~~r~_!]J~ntalidad.es que en la mayora de los c;sos prcticos no b;1y manera de obtener_ t~d;s lo;, .

-':: requerimientos con-ectas antes de desarrollar la aplicacin: Mas bien, los requerimientos van apareciendo
alnedid qe. la aplicacin - o [)artes de ella - estn disponibles para la experimentacin prcti<;:a. En
consecuencia, cuanto ms temprano recibamos la rt:alimentacia del cliente (feedback), ms fcil nos
ser incorporar los cambios requeridos al producto. De esta maner~. la in~r~m.~.n~alidad est__~;!_cjg_da a la
anticipacin de ca~nbio, y es u!~~~~--.L~~.PJ.~W.as_~l}-~tlar~-~-~p _que se _debe~a basar la evoluti',~i_dad. _ '- -
- -- La increie~talidad s ~IJ~ca.a la mayor..a .~le _i_?.s propiedades que virno? en_ d capitulo 2. Po~emo~-
agregarfuncioi1es ')'rogresiv~mente a la aplicacin q;~- e~~~mos ~l~s~ria""tbnci~, 'Com~-ri;:-triCio.-por un .
!':.'.Jc:.tc!cto d:: .u~iones que har:,n que d sistema fuera til a pesar de estar incompleto. Por ejemplo, en
algunos sistemas de automatizacin de oficinas, habra algunas func:~n<'s que :;e .:rjntinl!:lrrrn. !.~~iencto
en forma manual; mientras que otras se haran al!tomticamente us~ndo la aplicacin. ,
Tambin podemos agresar performance de manera incrementaL Es decir, la versin inicial 'le la ''
aplicacin podrla enfatizar las intertasestie usuario y la con.fiabilidad ms que la performance, y las
.,. sucesivas versiones, n1ejoraran la eficiencia en el tien1po y el espacio. u

Cuando desarrollamos una aplicacin de manera incremental, los estados intem1edios pueden
constituir prototipos del proJudo final; es tkcir, son slo una aproximacin ele l. La ide;.~ Je desarn)ll<tr
.. ,
una aplicacin generando rpidos prototipos, es a menudo promovida como una manera de ir
desarrollando Ja aplicacin junto con la comprensin de sus requerimientos. Obviamente, el ciclo ele vida '
del software basado en la gem~racin de prototipos, es bastante diferente del tpico modelo de cascada
i visto interiormente, en el cual, primero completai11os el anlisis de los requerimientos y la especificacin .
y luego comenzamos a desarrollar la plicacin. Est~ basado en un modelo de desa1Tollo ms flexible e'_;.
iterativo. Esta diferencia, por supuesto, tendr efectos sobre los temas de organizacin y g-c.stion.
Veremos ms acerca de este IT..mlo en d captulo 7.
Como dijimos en conexin :on la anticipr..cin de cambio. el desarrollo ele software evolutivo
["eluicre 't~peciaTtt:iiod~it)~::e-r!iia-i1ej-:.Je doc~iii~t)tos:-)rog:t~~~~~;~. datos de pr1.1eba, t:tc., que fueron :
. ~
-desarroif~ios-p-;;:-~ ;;a!stas vet~s-iolcs del software. Debemos registrar cada pcq~~o paso ii1Cierncnta( -
debemos poder recuperar caua documentacin con facilidad y aplicar los cambios de manera controlada. ;
Si r;o hacemos todo esto c:m cuidado, el esi:1irollo-. evolutivo que hemos intentado se convertir, -
rpidamente e11 un desarrollo-indisciplinado, haderidonos. perder todas las ventajas de la ~volutividad.

(__) Ejercido
l..

( ..:. 3.10 Discuta el concepto de prototipo de softw<tre iluslr<~do aqu, en oposicin al concepto de prototipo
cisado por los ingenieros en otrns ramas de la industria. (por ej. el prototipo de un puente o un au\o-.
e: mvil). .
\_ .
le.
e~.

Notas flnaks

En este captulo hemos tli:;cutido siete importantes princtptos de la ingeniera del software: Estos
pri;Kipios se aplican a lo lar;:;o de todo,et proceso de desarrollo del softvvare y durante su evolucin. Dada
su aplicabilidad general los hcm()s presentado por separado como bs piedras angulares de la ingeniera
.e; del software, ms qu~ en d contexto de WJa fase especfica dd ciclo de vida del software. Otra razn para
(; presentarlos por separado es que la tenninolog!a usada-no est estanclarzada, y a menudo un mismo
trmino es utilizado por clift:rcnlcs personas con distinto significado. Comprendiendo estos principios del
~ l.;
sollware destle un co;nietW\ podremos usar los tnninos ms importantes sin 1rnbigueuades en el resto
de! libro.
.12
 ~.~ -

ill!9~. Estos principios de la ing::niera del soft\yare, como los presentamos aqu, podran parecer
demasiado abstractos. Los iremos haciendo ms concretos con ms detalles en el resto del libro, _dentro
del contexto de diseo; especificacin; verificacin y gestin del software. Esto se har en parte
explicitall~~nte, sealando los prin::ipios importantes (cuando sea apropiado), y en parte implcitamente, .
dejando su reconocimiento al lector. ,
Enfatizamos el papel de los principios generales antes de presentar m~todos especficos, tcnicas
y herramientas. La razn es que b ingeniera dd softwar~.- corno cualquier otra rama Ll.e la ingeniera-, .
debe basarse en un conjunto probado de principios:.._L,os prin~ipios a su vez, son las bases para~!- ~~.l~lJnto'
de m!Q~Q.S .!.\;;ados en la disciplina y" para las tcnica:; especific_a:; YJ1t:~r:.~r~:-~~-~~as.~~~~-~s en)~yida -di_a~ia.
--- A medid~ -que
la tecnologl"a evo lucio na, tambin lo__
.hacen las herramientas de la ingeniera del
softwar'e. Los mtodos y las tcnicas. evolucionarn tan~bin - aunque menos rpid~mente que In,~
herramientas - a medida que aum:::.nta nuestro conocimiento del softvvare. En est~ cuadro, los principis ''
permanecen 1s estables; ellos cc.r1stiluyen las bases sobre las c.uaks se construir d resto. Tambin son
la clave que deber usar el lector rara interpretar Jos conceptos discutidos en el resto del libro.

l.\'Is cj ercicios
-------------------------~----------------------------------------------------------------------------------------------------------
3.11 Supongamos que est escribiendo un programa que manipula archivos. Entre las rutinas ud. ofrece
un comando para ordenar un archivo ya sea en foana ~scendente o descendente. Entre lbs archivos
que ma1~eja, algunos se mantienen automit(camente ordenados por el sistema. UJ.. podra sa~ar
ventaja de este hecho :si el arch[vo ya est ordenado, no se efecta ninguna accin; si el archivo
est ordenado al revs, aplica una fttncin inversa en d orden opuesto. Discuta lo~ pro y los contra
de usar soluciones espcciak:adas en Jugar de utilizar la rutina st:ndarcl de ordenamiento (sort) cada
. vez que se ej-ecuta ese ccun:wdo.
i
i

3.12 Discuta brevdmentc las rdaciones entre generalidad y anticipacin de cambio.'
! '
r
3.13 Discuta brevememe las rciaciones entre generalidad y abstraccin. '

3.1'\ Discuta la relacin entre i~:cre.mentalidad y oprtunidad (timeliness).

3.15 DiscULa los principios que podran ser tiles para e.! desarollo del software, y deni.uestre cnio se
relacionan con los principios discutidos aqu.

Pistas y soludoucs ingcnios::,s

. .
3.'1 Al dividir un programa largo en fragmentos continuos no necesariamente generamos una buena,
estructura con alta cohesin. 1\grupar instrucciones que cumplen alguna funcin conceptual da una '
cohesin mayor. (Esto corespo1cle a la descomposicjn convencional de progr:nnas en subrutinas). Es!
mejor a11 si podernos agrupar .os dato:~ y las ruti!las que: acceden a esos datos, porque esto aumenta la
facilidad de lectura y modifcac:(m.

3.5 Los mdulos que no r.'.(::actan con otros md1.dos, tienen un acoplamiento mmtmo, pero esto
ta111bin significa que ellos uo "cooperan" en nillg:1 sentido. Si un mdulo tiene acceso a las vcriables
locales de otro - por ej. si puede llll)c\ificar directamente el .::stado del otro mdulo -el acoplamiento es
mayor que si un mdulo llama ;:1 un procedimiento ddlniciJ dentro de otro mdulo.

..,
\ .., J.. ,
\ ' .. ~
..)
' 1/l
1
 ------" :....~ ........- , ; . . . : . __
~_
... ~--~-

' '. ----~--._,;.'--o-.--:.__"------.::...-__-:-:_,7.;.~---"'-~'~-:~ ::-. ~ . j: _.:.;;:: :::~~;__ '":?'i:Q:~~:::.:.:;;..;: '<'' :;:;:<::~&: ::~;;;.;~,
f-.6 p usu::nio final se interesa :;olarncl\le ~n la Jcscripcit; abstrnc 1:; de cmo operar la anlcacin ~ i - . -
todos los detalles concernientes a la forma en que fue diseiiada e impiementada deben omitirse. -El
disei.ador debera saber cuales ~;on. los requerimi.entos y; al diseunr una pan e, deber::~ tener una visin
absrracta del resto del sistema qu,= le permita imaginarse la manera en que: esa parte interacla con el
.l
resto, pero ignora-ndo los detalles ck ese resto. Cuando se hace e! nw.nteoimic:nto-de! sistema, deberiamos
tener tambin tma visin abstr[)cta de la exposicin dd diseo ( porqu se tci.Iriaron cietias d~cisiones Y,
porqu se descartaron otras). Esto pr::rmitira mouifi.car d sistema Je una maner;1 cori.Gable sin ueterior<:1r .
su estructura._ .. _ . J

~:
3.3 Ve~<:~mos
en ei ~:..:.;::~,:~; 7 q;c: e! P.Jodeio le cicb de -vida .en ;;:.aseada e:::- uti pt.:.I1to de vista
idealizado del desarrollo del software._ Por-ejemplo: el modelo de la figum l. 1 ignora e'l hecho" de que se
deb~rn repetir algunos pasos si ur1a fase revela inco~1sisterr.cias o errores en la fas.e anterior>.'!' . i'

3.10 Esta es la creacin evolutiva de prototipos. Sin .;:-.;nbargo, en otros campos es mejor usar los
prototipos por descarte (thrbwavvay). Estos trminos se disctitirln en el captulo 7.

3.14 Entregando una ap!icarin de manera incremental: jodramos entregar un subconjunto til de la
aplicacin a modo de adelanto. 1::s decir, que podernos entrar antes ~n el mercado con un producto,
aunque est incompleto.

.
...::,..;.
.. .

.i--.:.

1!

.
...

-'. .: :- - :.t_'~~;.~---- -.-;;~::.~:~:.:;:.::::~::.-.:. : ....... . ...

'
- .. - -.~-

.
-.
"".;: