Software

Software

Los procesadores de texto estn incluidos en la categora de software de aplicacin. Las imgenes son capturas de pantalla de OpenOffice (arriba) yKWord (aba o). !e conoce como software" al equipamiento lgico o soporte lgico de un sistema informtico# comprende el con unto de los componentes lgicos necesarios $ue %acen posible la reali&acin de tareas especficas' en contraposicin a los componentes fsicos' $ue son llamados %ardware. Los componentes lgicos incluyen' entre muc%os otros' las aplicaciones informticas# tales como el procesador de texto' $ue permite al usuario reali&ar todas las tareas concernientes a la edicin de textos# el software de sistema' tal como el sistema operati(o' $ue' bsicamente' permite al resto de los programas funcionar adecuadamente' facilitando tambi)n la interaccin entre los componentes fsicos y el resto de las aplicaciones' y proporcionando una interfa& con el usuario. Contenido *ocultar+ " ,timologa

- .efinicin de software / 0lasificacin del software 1 2roceso de creacin del software

o o

1." 3odelos de proceso o ciclo de (ida 1."." 3odelo cascada 1.".- 3odelos e(oluti(os 1.".-." 3odelo iterati(o incremental 1.".-.- 3odelo espiral 1.".-./ 3odelo espiral Win 4 Win 1.- ,tapas en el desarrollo del software 1.-." 0aptura' anlisis y especificacin de re$uisitos 1.-."." 2rocesos' modelado y formas de elicitacin de re$uisitos

1.-.".- 0lasificacin e identificacin de re$uerimientos 1.-.- .ise5o del sistema 1.-./ 0odificacin del software 1.-.1 2ruebas (unitarias y de integracin) 1.-.6 7nstalacin y paso a produccin 1.-.8 3antenimiento

6 0arcter e(oluti(o del software*"9+ 8 :)ase tambi)n

o

8." 3odelos de ciclo de (ida 9 ;eferencias

< =ibliografa
o o

<." Libros <.- >rtculos y re(istas ? ,nlaces externos

*editar+,timologa !oftware (pronunciacin >@7A*softBware+) es una palabra pro(eniente del ingl)s (literalmenteA partes blandas o sua(es)' $ue en espa5ol no posee una traduccin adecuada al contexto' por lo cual se la utili&a asiduamente sin traducir y as fue admitida por la ;eal >cademia ,spa5ola (;>,).- >un$ue no es estrictamente lo mismo' suele sustituirse por expresiones tales como programas (informticos) oaplicaciones (informticas)./ !oftware es lo $ue se denomina producto en 7ngeniera de !oftware.1 *editar+.efinicin de software ,xisten (arias definiciones similares aceptadas para software' pero probablemente la ms formal sea la siguienteA ,s el con unto de los programas de cmputo' procedimientos' reglas' documentacin y datos asociados $ue forman parte de las operaciones de un sistema de computacin. ,xtrado del estndar 9-? del 7,,,6 0onsiderando esta definicin' el concepto de software (a ms all de los programas de computacin en sus distintos estadosA cdigo fuente'binario o e ecutable# tambi)n su documentacin' los datos a procesar e incluso la informacin de usuario forman parte del softwareA es decir' abarca todo lo intangible' todo lo Cno fsicoD relacionado. ,l t)rmino CsoftwareD fue usado por primera (e& en este sentido por Eo%n W. FuGey en "?69. ,n la ingeniera de software y las ciencias de la computacin' el software es toda la informacin procesada por los sistemas informticosA programas y datos.

El concepto de leer diferentes secuencias de instrucciones (programa) desde la memoria de un dispositi(o para controlar los clculos fue introducido por 0%arles =abbage como parte de su m$uina diferencial. La teora $ue forma la base de la mayor parte del software moderno fue propuesta por >lan Furing en su ensayo de "?/8' CLos nHmeros computablesD' con una aplicacin al problema de decisin. *editar+0lasificacin del software !i bien esta distincin es' en cierto modo' arbitraria' y a (eces confusa' a los fines prcticos se puede clasificar al software en tres grandes tiposA

Software de sistema: !u ob eti(o es des(incular adecuadamente al usuario y al programador de los detalles del sistema informtico en particular $ue se use' aislndolo especialmente del procesamiento referido a las caractersticas internas deA memoria' discos' puertos y dispositi(os de comunicaciones' impresoras' pantallas' teclados' etc. ,l software de sistema le procura al usuario y programador adecuadas interfaces de alto ni(el' controladores' %erramientas y utilidades de apoyo $ue permiten el mantenimiento del sistema global. 7ncluye entre otrosA

!istemas operati(os 0ontroladores de dispositi(os Ierramientas de diagnstico Ierramientas de 0orreccin y Optimi&acin !er(idores Jtilidades

Software de programacin: ,s el con unto de %erramientas $ue permiten al programador desarrollar programas informticos' usando diferentes alternati(as y lengua es de programacin' de una manera prctica. 7ncluyen bsicamenteA

,ditores de texto 0ompiladores

7nt)rpretes ,nla&adores .epuradores ,ntornos de .esarrollo 7ntegrados (7.,)A >grupan las anteriores %erramientas' usualmente en un entorno (isual' de forma tal $ue el programador no necesite introducir mHltiples comandos para compilar' interpretar' depurar' etc. Iabitualmente cuentan con una a(an&ada interfa& grfica de usuario (KJ7). Software de aplicacinA ,s a$uel $ue permite a los usuarios lle(ar a cabo

una o (arias tareas especficas' en cual$uier campo de acti(idad susceptible de ser automati&ado o asistido' con especial )nfasis en los negocios. 7ncluye entre muc%os otrosA

>plicaciones para 0ontrol de sistemas y automati&acin industrial >plicaciones ofimticas !oftware educati(o !oftware empresarial =ases de datos Felecomunicaciones (por e emplo 7nternet y toda su estructura lgica) :ideo uegos !oftware m)dico !oftware de clculo Lum)rico y simblico. !oftware de dise5o asistido (0>.) !oftware de control num)rico (0>3)

*editar+2roceso de creacin del software Artculo principal: 2roceso para el desarrollo de software .

!e define como proceso al con unto ordenado de pasos a seguir para llegar a la solucin de un problema u obtencin de un producto' en este caso particular' para lograr un producto software $ue resuel(a un problema especfico. ,l proceso de creacin de software puede llegar a ser muy comple o' dependiendo de su porte' caractersticas y criticidad del mismo. 2or e emplo la creacin de un sistema operati(o es una tarea $ue re$uiere proyecto' gestin' numerosos recursos y todo un e$uipo disciplinado de traba o. ,n el otro extremo' si se trata de un sencillo programa (por e emplo' la resolucin de una ecuacin de segundo orden)' )ste puede ser reali&ado por un solo programador (incluso aficionado) fcilmente. ,s as $ue normalmente se di(iden en tres categoras segHn su tama5o (lneas de cdigo) o costoA de pequeo ' mediano y gran porte . ,xisten (arias metodologas para estimarlo' una de las ms populares es el sistema 0O0O3O $ue pro(ee m)todos y un software (programa) $ue calcula y pro(ee una aproximacin de todos los costos de produccin en un Cproyecto softwareD (relacin %orasM%ombre' costo monetario' cantidad de lneas fuente de acuerdo a lengua e usado' etc.). 0onsiderando los de gran porte' es necesario reali&ar comple as tareas' tanto t)cnicas como de gerencia' una fuerte gestin y anlisis di(ersos (entre otras cosas)' la comple idad de ello %a lle(ado a $ue desarrolle una ingeniera especfica para tratar su estudio y reali&acinA es conocida como 7ngeniera de !oftware. ,n tanto $ue en los de mediano porte' pe$ue5os e$uipos de traba o (incluso un a(e&ado analistaNprogramador solitario) pueden reali&ar la tarea. >un$ue' siempre en casos de mediano y gran porte (y a (eces tambi)n en algunos de pe$ue5o porte' segHn su comple idad)' se deben seguir ciertas etapas $ue son necesarias para la construccin del software. Fales etapas' si bien deben existir' son flexibles en su forma de aplicacin' de acuerdo a la metodologa o proceso de desarrollo escogido y utili&ado por el e$uipo de desarrollo o por el analistaN programador solitario (si fuere el caso). Los Cprocesos de desarrollo de softwareD poseen reglas preestablecidas' y deben ser aplicados en la creacin del software de mediano y gran porte' ya $ue en caso contrario lo ms seguro es $ue el proyecto o no logre concluir o termine sin cumplir los ob eti(os pre(istos' y con (ariedad de fallos inaceptables (fracasan' en pocas palabras). ,ntre tales CprocesosD los %ay giles o li(ianos (e emplo O2)' pesados y lentos (e emplo ;J2)' y (ariantes intermedias. Lormalmente se aplican

de acuerdo al tipo y porte del software a desarrollar' a criterio del lder (si lo %ay) del e$uipo de desarrollo. >lgunos de esos procesos son 2rogramacin ,xtrema (en ingl)s e!treme "rogramming o O2)'2roceso Jnificado de ;ational (en ingl)s ;ational Jnified 2rocess o ;J2)' @eature .ri(en .e(elopment (@..)' etc. 0ual$uiera sea el CprocesoD utili&ado y aplicado al desarrollo del software (;J2' @..' O2' etc)' y casi independientemente de )l' siempre se debe aplicar un Cmodelo de ciclo de (idaD.8 !e estima $ue' del total de proyectos software grandes emprendidos' un -<P fracasan' un 18P caen en se(eras modificaciones $ue lo retrasan y un -8P son totalmente exitosos. 9 0uando un proyecto fracasa' rara (e& es debido a fallas t)cnicas' la principal causa de fallos y fracasos es la falta de aplicacin de una buena metodologa o proceso de desarrollo. ,ntre otras' una fuerte tendencia' desde %ace pocas d)cadas' es me orar las metodologas o procesos de desarrollo' o crear nue(as y concienti&ar a los profesionales de la informtica a su utili&acin adecuada. Lormalmente los especialistas en el estudio y desarrollo de estas reas (metodologas) y afines (tales como modelos y %asta la gestin misma de los proyectos) son los ingenieros en software' es su orientacin. Los especialistas en cual$uier otra rea de desarrollo informtico (analista' programador' Lic. en informtica' ingeniero en informtica' ingeniero de sistemas' etc.) normalmente aplican sus conocimientos especiali&ados pero utili&ando modelos' paradigmas y procesos ya elaborados. ,s comHn para el desarrollo de software de mediano porte $ue los e$uipos %umanos in(olucrados apli$uen Cmetodologas propiasD' normalmente un %brido de los procesos anteriores y a (eces con criterios propios. ,l proceso de desarrollo puede in(olucrar numerosas y (ariadas tareas 8 ' desde lo administrati(o' pasando por lo t)cnico y %asta la gestin y el gerenciamiento. 2ero' casi rigurosamente' siempre se cumplen ciertas etapas mnimas# las $ue se pueden resumir como sigueA

0aptura' elicitacin< ' especificacin y anlisis de re$uisitos (,;!) .ise5o 0odificacin

2ruebas (unitarias y de integracin) 7nstalacin y paso a produccin 3antenimiento

,n las anteriores etapas pueden (ariar ligeramente sus nombres' o ser ms globales' o contrariamente' ser ms refinadas# por e emplo indicar como una Hnica fase (a los fines documentales e interpretati(os) de Canlisis y dise5oD# o indicar como CimplementacinD lo $ue est dic%o como CcodificacinD# pero en rigor' todas existen e incluyen' bsicamente' las mismas tareas especficas. ,n el apartado 1 del presente artculo se brindan mayores detalles de cada una de las etapas indicadas. *editar+Modelos de proceso o ciclo de vida 2ara cada una de las fases o etapas listadas en el tem anterior' existen subN etapas (o tareas). ,l modelo de proceso o modelo de ciclo de (ida utili&ado para el desarrollo' define el orden de las tareas o acti(idades in(olucradas' 8 tambi)n define la coordinacin entre ellas' y su enlace y realimentacin. ,ntre los ms conocidos se puede mencionarA modelo en cascada o secuencial' modelo espiral' modelo iterati(o incremental. .e los antedic%os %ay a su (e& algunas (ariantes o alternati(as' ms o menos atracti(as segHn sea la aplicacin re$uerida y sus re$uisitos.9 *editar+Modelo cascada ,ste' aun$ue es ms comHnmente conocido como modelo en cascada es tambi)n llamado Cmodelo clsicoD' Cmodelo tradicionalD o Cmodelo lineal secuencialD. ,l modelo en cascada puro difcilmente se utili#a tal cual' pues esto implicara un pre(io y absoluto conocimiento de los re$uisitos' la no (olatilidad de los mismos (o rigide&) y etapas subsiguientes libres de errores# ello slo podra ser aplicable a escasos y pe$ue5os sistemas a desarrollar. ,n estas circunstancias' el paso de una etapa a otra de las mencionadas sera sin retorno' por e emplo pasar del dise5o a la codificacin implicara un dise5o exacto y sin errores ni probable modificacin o e(olucinA Ccodifi$ue lo dise5ado sin errores' no %abr en absoluto (ariantes futurasD. ,sto es utpico# ya $ue intrnsecamente el soft$are es de carcter e%oluti%o? ' cambiante y difcilmente libre de errores' tanto durante su desarrollo como durante su (ida operati(a. 8

@ig. - N 3odelo cascada puro o secuencial para el ciclo de (ida del software. >lgHn cambio durante la e ecucin de una cual$uiera de las etapas en este modelo secuencial implicara reiniciar desde el principio todo el ciclo completo' lo cual redundara en altos costos de tiempo y desarrollo. La figura - muestra un posible es$uema de el modelo en cuestin.8 !in embargo' el modelo cascada en algunas de sus (ariantes es uno de los actualmente ms utili#ados"Q ' por su eficacia y simplicidad' ms $ue nada en software de pe$ue5o y algunos de mediano porte# pero nunca (o muy rara (e&) se lo usa en su Rforma puraR' como se di o anteriormente. ,n lugar de ello' siempre se produce alguna realimentacin entre etapas' $ue no es completamente predecible ni rgida# esto da oportunidad al desarrollo de productos software en los cuales %ay ciertas incerte&as' cambios o e(oluciones durante el ciclo de (ida. >s por e emplo' una (e& capturados y especificados los re$uisitos (primera etapa) se puede pasar al dise5o del sistema' pero durante esta Hltima fase lo ms probable es $ue se deban reali&ar a ustes en los re$uisitos (aun$ue sean mnimos)' ya sea por fallas detectadas' ambigSedades o bien por $ue los propios re$uisitos %an cambiado o e(olucionado# con lo cual se debe retornar a la primera o pre(ia etapa' %acer los rea uste pertinentes y luego continuar nue(amente con el dise5o# esto Hltimo se conoce como realimentacin. Lo normal en el modelo cascada ser entonces la aplicacin del mismo con sus etapas realimentadas de alguna forma ' permitiendo retroceder de una a la anterior (e incluso poder saltar a (arias anteriores) si es re$uerido. .e esta manera se obtiene el Cmodelo cascada realimentadoD' $ue puede ser es$uemati&ado como lo ilustra la figura /.

@ig. / N 3odelo cascada realimentado para el ciclo de (ida. Lo dic%o es' a grandes rasgos' la forma y utili&acin de este modelo' uno de los ms usados y populares.8 ,l modelo cascada realimentado resulta muy atracti(o' %asta ideal' si el proyecto presenta alta rigide& (pocos cambios' pre(isto no e(oluti(o)' los re$uisitos son muy claros y estn correctamente especificados. "Q Iay ms (ariantes similares al modeloA refino de etapas (ms etapas' menores y ms especficas) o incluso mostrar menos etapas de las indicadas' aun$ue en tal caso la faltante estar dentro de alguna otra. ,l orden de esas fases indicadas en el tem pre(io es el lgico y adecuado' pero ad(i)rtase' como se di o' $ue normalmente %abr realimentacin %acia atrs. ,l modelo lineal o en cascada es el paradigma ms antiguo y extensamente utili&ado' sin embargo las crticas a )l ((er des(enta as) %an puesto en duda su eficacia. 2ese a todo' tiene un lugar muy importante en la 7ngeniera de software y continHa siendo el ms utili&ado# y siempre es me or $ue un enfo$ue al a&ar. "Q .es(enta as del modelo cascadaA8

Los cambios introducidos durante el desarrollo pueden confundir al e$uipo profesional en las etapas tempranas del proyecto. !i los cambios se producen en etapa madura (codificacin o prueba) pueden ser catastrficos para un proyecto grande. Lo es frecuente $ue el cliente o usuario final explicite clara y completamente los re$uisitos (etapa de inicio)# y el modelo lineal lo re$uiere. La incertidumbre natural en los comien&os es luego difcil de acomodar. "Q

,l cliente debe tener paciencia ya $ue el software no estar disponible %asta muy a(an&ado el proyecto. Jn error detectado por el cliente (en fase de operacin) puede ser desastroso' implicando reinicio del proyecto' con altos costos.

*editar+Modelos evolutivos ,l software e(oluciona con el tiempo."" ? Los re$uisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo. Las fec%as de mercado y la competencia %acen $ue no sea posible esperar a poner en el mercado un producto absolutamente completo' por lo $ue se aconse able introducir una (ersin funcional limitada de alguna forma para ali(iar las presiones competiti(as. ,n esas u otras situaciones similares los desarrolladores necesitan modelos de progreso $ue est)n dise5ados para acomodarse a una e(olucin temporal o progresi(a' donde los re$uisitos centrales son conocidos de antemano' aun$ue no est)n bien definidos a ni(el detalle. ,n el modelo cascada y cascada realimentado no se tiene demasiado en cuenta la naturale&a e(oluti(a del software "" ' se plantea como esttico' con re$uisitos bien conocidos y definidos desde el inicio. 8 Los e(oluti(os son modelos iterati(os' permiten desarrollar (ersiones cada (e& ms completas y comple as' %asta llegar al ob eti(o final deseado# incluso e(olucionar ms all' durante la fase de operacin. Los modelos Citerati(o incrementalD y CespiralD (entre otros) son dos de los ms conocidos y utili&ados del tipo e(oluti(o. "Q *editar+Modelo iterativo incremental ,n t)rminos generales' se puede distinguir' en la figura 1' los pasos generales $ue sigue el proceso de desarrollo de un producto software. ,n el modelo de ciclo de (ida seleccionado' se identifican claramente dic%os pasos. La descripcin del sistema es esencial para especificar y confeccionar los distintos incrementos %asta llegar al producto global y final. Las acti(idades concurrentes (especificacin' desarrollo y (alidacin) sinteti&an el desarrollo pormenori&ado de los incrementos' $ue se %ar posteriormente.

@ig. 1 N .iagrama gen)rico del desarrollo e(oluti(o incremental. ,l diagrama 1 muestra en forma muy es$uemtica' el funcionamiento de un ciclo iterati(o incremental' el cual permite la entrega de (ersiones parciales a medida $ue se (a construyendo el producto final.8 ,s decir' a medida $ue cada incremento definido llega a su etapa de operacin y mantenimiento. 0ada (ersin emitida incorpora a los anteriores incrementos las funcionalidades y re$uisitos $ue fueron anali&ados como necesarios. El incremental es un modelo de tipo e%oluti%o que est basado en %arios ciclos &ascada 'ealimentados aplicados repetidamente( con una filosofa iterati%a. "Q ,n la figura 6 se muestra un refino del diagrama pre(io' ba o un es$uema temporal' para obtener finalmente el es$uema del modelo de ciclo de (ida 7terati(o 7ncremental' con sus acti(idades gen)ricas asociadas. >$u se obser(a claramente cada ciclo cascada $ue es aplicado para la obtencin de un incremento# estos Hltimos se (an integrando para obtener el producto final completo. 0ada incremento es un ciclo 0ascada ;ealimentado' aun$ue' por simplicidad' en la figura 6 se muestra como secuencial puro.

@ig. 6 N 3odelo iterati(o incremental para el ciclo de (ida del software'. !e obser(a $ue existen acti(idades de desarrollo (para cada incremento) $ue son reali&adas en paralelo o concurrentemente' as por e emplo' en la figura' mientras se reali&a el dise5o detalle del primer incremento ya se est reali&ando en anlisis del segundo. La figura 6 es slo es$uemtica' un incremento no necesariamente se iniciar durante la fase de dise5o del anterior' puede ser posterior (incluso antes)' en cual$uier tiempo de la etapa pre(ia. 0ada incremento concluye con la acti(idad de Coperacin y mantenimientoD (indicada como COperacinD en la figura)' $ue es donde se produce la entrega del producto parcial al cliente. ,l momento de inicio de cada incremento es dependiente de (arios factoresA tipo de sistema# independencia o dependencia entre incrementos (dos de ellos totalmente independientes pueden ser fcilmente iniciados al mismo tiempo si se dispone de personal suficiente)# capacidad y cantidad de profesionales in(olucrados en el desarrollo# etc. =a o este modelo se entrega software Cpor partes funcionales ms pe$ue5asD' pero reutili&ables' llamadas incrementos. ,n general cada incremento se construye sobre a$uel $ue ya fue entregado. 8 0omo se muestra en la figura 6' se aplican secuencias 0ascada en forma escalonada' mientras progresa el tiempo calendario. 0ada secuencia lineal o 0ascada produce un incremento y a menudo el primer incremento es un sistema bsico' con muc%as funciones suplementarias (conocidas o no) sin entregar.

,l cliente utili&a inicialmente ese sistema bsico' intertanto' el resultado de su uso y e(aluacin puede aportar al plan para el desarrollo delMlos siguientes incrementos (o (ersiones). >dems tambi)n aportan a ese plan otros factores' como lo es la priori&acin (mayor o menor urgencia en la necesidad de cada incremento en particular) y la dependencia entre incrementos (o independencia). Luego de cada integracin se entrega un producto con mayor funcionalidad $ue el pre(io. ,l proceso se repite %asta alcan&ar el software final completo. !iendo iterati(o' con el modelo incremental se entrega un producto parcial pero completamente operacional en cada incremento ' y no una parte $ue sea usada para rea ustar los re$uerimientos (como si ocurre en el modelo de construccin de prototipos)."Q ,l enfo$ue incremental resulta muy Htil cuando se dispone de ba a dotacin de personal para el desarrollo# tambi)n si no %ay disponible fec%a lmite del proyecto por lo $ue se entregan (ersiones incompletas pero $ue proporcionan al usuario funcionalidad bsica (y cada (e& mayor). Fambi)n es un modelo Htil a los fines de (ersiones de e(aluacin. LotaA 2uede ser considerado y Htil' en cual$uier momento o incremento incorporar temporalmente el paradigma 302 como complemento' teniendo as una mixtura de modelos $ue me oran el es$uema y desarrollo general. , emploA Jn procesador de texto $ue sea desarrollado ba o el paradigma 7ncremental podra aportar' en principio' funciones bsicas de edicin de arc%i(os y produccin de documentos (algo como un editor simple). ,n un segundo incremento se le podra agregar edicin ms sofisticada' y de generacin y me&cla de documentos. ,n un tercer incremento podra considerarse el agregado de funciones decorreccin ortogrfica' es$uemas de paginado y plantillas# en un cuarto capacidades de dibu o propias y ecuaciones matemticas. >s sucesi(amente %asta llegar al procesador final re$uerido. >s' el producto (a creciendo' acercndose a su meta final' pero desde la entrega del primer incremento ya es Htil y funcional para el cliente' el cual obser(a una respuesta rpida en cuanto a entrega temprana# sin notar $ue la fec%a lmite del proyecto puede no estar acotada ni tan definida' lo $ue da margen de operacin y ali(ia presiones al e$uipo de desarrollo.

0omo se di o' el 7terati(o 7ncremental es un modelo del tipo e(oluti(o' es decir donde se permiten y esperan probables cambios en los re$uisitos en tiempo de desarrollo# se admite cierto margen para $ue el software pueda e(olucionar ? . >plicable cuando los re$uisitos son medianamente bien conocidos pero no son completamente estticos y definidos' cuestin esa $ue si es indispensable para poder utili&ar un modelo 0ascada. ,l modelo es aconse able para el desarrollo de software en el cual se obser(e' en su etapa inicial de anlisis' $ue posee reas bastante bien definidas a cubrir' con suficiente independencia como para ser desarrolladas en etapas sucesi(as. Fales reas a cubrir suelen tener distintos grados de apremio por lo cual las mismas se deben priori&ar en un anlisis pre(io' es decir' definir cual ser la primera' la segunda' y as sucesi(amente# esto se conoce como Cdefinicin de los incrementosD con base en la priori&acin. 2ueden no existir prioridades funcionales por parte del cliente' pero el desarrollador debe fi arlas de todos modos y con algHn criterio' ya $ue basndose en ellas se desarrollarn y entregarn los distintos incrementos. ,l %ec%o de $ue existan incrementos funcionales del software lle(a inmediatamente a pensar en un es$uema de desarrollo modular' por tanto este modelo facilita tal paradigma de dise5o. ,n resumen' un modelo incremental lle(a a pensar en un desarrollo modular' con entregas parciales del producto software denominados CincrementosD del sistema' $ue son escogidos segHn prioridades predefinidas de algHn modo. ,l modelo permite una implementacin con refinamientos sucesi(os (ampliacin o me ora). 0on cada incremento se agrega nue(a funcionalidad o se cubren nue(os re$uisitos o bien se me ora la (ersin pre(iamente implementada del producto software. ,ste modelo brinda cierta flexibilidad para $ue durante el desarrollo se incluyan cambios en los re$uisitos por parte del usuario' un cambio de re$uisitos propuesto y aprobado puede anali&arse e implementarse como un nue(o incremento o' e(entualmente' podr constituir una me oraMadecuacin de uno ya planeado. >un$ue si se produce un cambio de re$uisitos por parte del cliente $ue afecte incrementos pre(ios ya terminados (deteccinMincorporacin tarda) se debe e%aluar la factibilidad ) reali#ar un acuerdo con el cliente( )a que puede impactar fuertemente en los costos.

La seleccin de este modelo permite reali&ar entregas funcionales tempranas al cliente (lo cual es beneficioso tanto para )l como para el grupo de desarrollo). !e priori&an las entregas de a$uellos mdulos o incrementos en $ue sur a la necesidad operati(a de %acerlo' por e emplo para cargas pre(ias de informacin' indispensable para los incrementos siguientes. "Q ,l modelo iterati(o incremental no obliga a especificar con precisin y detalle absolutamente todo lo $ue el sistema debe %acer' (y cmo)' antes de ser construido (como el caso del cascada' con re$uisitos congelados). !lo se %ace en el incremento en desarrollo. ,sto torna ms mane able el proceso y reduce el impacto en los costos. ,sto es as' por$ue en caso de alterar o re%acer los re$uisitos' solo afecta una parte del sistema. >un$ue' lgicamente' esta situacin se agra(a si se presenta en estado a(an&ado' es decir en los Hltimos incrementos. En definiti%a( el modelo facilita la incorporacin de nue%os requisitos durante el desarrollo. 0on un paradigma incremental se reduce el tiempo de desarrollo inicial' ya $ue se implementa funcionalidad parcial. Fambi)n pro(ee un impacto (enta oso frente al cliente' $ue es la entrega temprana de partes operati(as del software. ,l modelo proporciona todas las (enta as del modelo en cascada realimentado' reduciendo sus des(enta as slo al mbito de cada incremento. ,l modelo incremental no es recomendable para casos de sistemas de tiempo real' de alto ni(el de seguridad' de procesamiento distribuido' o de alto ndice de riesgos. *editar+Modelo espiral ,l modelo espiral fue propuesto inicialmente por =arry =oe%m. ,s un modelo e(oluti(o $ue con uga la naturale&a iterati(a del modelo 302con los aspectos controlados y sistemticos del 3odelo 0ascada. 2roporciona potencial para desarrollo rpido de (ersiones incrementales. ,n el modelo ,spiral el software se construye en una serie de (ersiones incrementales. ,n las primeras iteraciones la (ersin incremental podra ser un modelo en papel o bien un prototipo. ,n las Hltimas iteraciones se producen (ersiones cada (e& ms completas del sistema dise5ado.8 "Q ,l modelo se di(ide en un nHmero de >cti(idades de marco de traba o' llamadas Cregiones de tareasD. ,n general existen entre tres y seis regiones

de tareas (%ay (ariantes del modelo). ,n la figura 8 se muestra el es$uema de un 3odelo ,spiral con 8 regiones. ,n este caso se explica una (ariante del modelo original de =oe%m' expuesto en su tratado de "?<<# en "??< expuso un tratado ms reciente.

@ig. 8 N 3odelo espiral para el ciclo de (ida del software. Las regiones definidas en el modelo de la figura sonA

;egin " N Fareas re$ueridas para establecer la comunicacin entre el cliente y el desarrollador. ;egin - N Fareas in%erentes a la definicin de los recursos' tiempo y otra informacin relacionada con el proyecto. ;egin / N Fareas necesarias para e(aluar los riesgos t)cnicos y de gestin del proyecto. ;egin 1 N Fareas para construir una o ms representaciones de la aplicacin software. ;egin 6 N Fareas para construir la aplicacin' instalarla' probarla y proporcionar soporte al usuario o cliente (, . documentacin y prctica).

;egin 8 N Fareas para obtener la reaccin del cliente' segHn la e(aluacin de lo creado e instalado en los ciclos anteriores.

Las acti(idades enunciadas para el marco de traba o son generales y se aplican a cual$uier proyecto' grande' mediano o pe$ue5o' comple o o no. Las regiones $ue definen esas acti(idades comprenden un Ccon unto de tareasD del traba oA ese con unto s se debe adaptar a las caractersticas del proyecto en particular a emprender. Ltese $ue lo listado en los tems de " a 8 son con untos de tareas' algunas de las ellas normalmente dependen del proyecto o desarrollo en si. 2royectos pe$ue5os re$uieren ba a cantidad de tareas y tambi)n de formalidad. ,n proyectos mayores o crticos cada regin de tareas contiene labores de ms alto ni(el de formalidad. ,n cual$uier caso se aplican acti(idades de proteccin (por e emplo' gestin de configuracin del software' garanta de calidad' etc.). >l inicio del ciclo' o proceso e(oluti(o' el e$uipo de ingeniera gira alrededor del espiral (metafricamente %ablando) comen&ando por el centro (marcado con en la figura 8) y en el sentido indicado# el primer circuito de la espiral puede producir el desarrollo de una especificacin del producto# los pasos siguientes podran generar un prototipo y progresi(amente (ersiones ms sofisticadas del software. 0ada paso por la regin de planificacin pro(oca a ustes en el plan del proyecto# el coste y planificacin se realimentan en funcin de la e(aluacin del cliente. ,l gestor de proyectos debe a ustar el nHmero de iteraciones re$ueridas para completar el desarrollo. ,l modelo espiral puede ir adaptndose y aplicarse a lo largo de todo el 0iclo de (ida del software (en el modelo clsico' o cascada' el proceso termina a la entrega del software). Jna (isin alternati(a del modelo puede obser(arse examinando el Ce e de punto de entrada de proyectosD. 0ada uno de los circulitos ( ) fi ados a lo largo del e e representan puntos de arran$ue de los distintos proyectos (relacionados)# a saberA

Jn proyecto de Cdesarrollo de conceptosD comien&a al inicio de la espiral' %ace mHltiples iteraciones %asta $ue se completa' es la &ona marcada con (erde. !i lo anterior se (a a desarrollar como producto real' se inicia otro proyectoA C.esarrollo de nue(o 2roductoD. Tue e(olucionar con iteraciones %asta culminar# es la &ona marcada en color a&ul. ,(entual y anlogamente se generarn proyectos de Cme oras de productosD y de Cmantenimiento de productosD' con las iteraciones necesarias en cada rea (&onas ro a y gris' respecti(amente).

0uando la espiral se caracteri&a de esta forma' est operati(a hasta que el software se retira' e(entualmente puede estar inacti(a (el proceso)' pero cuando se produce un cambio el proceso arranca nue(amente en el punto de entrada apropiado (por e emplo' en Cme ora del productoD). ,l modelo espiral da un enfo$ue realista' $ue e(oluciona igual $ue el software"" # se adapta muy bien para desarrollos a gran escala. ,l ,spiral utili&a el 302 para reducir riesgos y permite aplicarlo en cual$uier etapa de la e(olucin. 3antiene el enfo$ue clsico (cascada) pero incorpora un marco de traba o iterati(o $ue refle a me or la realidad. ,ste modelo requiere considerar riesgos t*cnicos en todas las etapas del proyecto# aplicado adecuadamente debe reducirlos antes de $ue sean un (erdadero problema. ,l 3odelo e(oluti(o como el ,spiral es particularmente apto para el desarrollo de !istemas Operati(os (comple os)# tambi)n en sistemas de altos riesgos o crticos (, . na(egadores y controladores aeronuticos) y en todos a$uellos en $ue sea necesaria una fuerte gestin del proyecto y sus riesgos' t)cnicos o de gestin. Desventajas importantesA

;e$uiere muc%a experiencia y %abilidad para la e(aluacin de los riesgos' lo cual es re$uisito para el )xito del proyecto. ,s difcil con(encer a los grandes clientes $ue se podr controlar este enfo$ue e(oluti(o.

,ste modelo no se %a usado tanto' como el 0ascada (7ncremental) o 302' por lo $ue no se tiene bien medida su eficacia' es un paradigma relati(amente nue(o y difcil de implementar y controlar. *editar+Modelo espiral Win & Win Jna (ariante interesante del 3odelo ,spiral pre(iamente (isto (@ig. 8) es el C3odelo espiral WinNWinD9 (=arry =oe%m). ,l 3odelo ,spiral pre(io (clsico) sugiere la comunicacin con el cliente para fi ar los re$uisitos' en $ue simplemente se pregunta al cliente $u) necesita y )l proporciona la informacin para continuar# pero esto es en un contexto ideal $ue rara (e& ocurre. Lormalmente cliente y desarrollador entran en una negociacin' se negocia coste frente a funcionalidad' rendimiento' calidad' etc. Es as que la obtencin de requisitos requiere una negociacin( que tiene *+ito cuando ambas partes ganan . Las me ores negociaciones se fuer&an en obtener C:ictoria 4 :ictoriaD (Win 4 Win)' es decir $ue el cliente gane obteniendo el producto $ue lo satisfaga' y el desarrollador tambi)n gane consiguiendo presupuesto y fec%a de entrega realista. ,(identemente' este modelo re$uiere fuertes %abilidades de negociacin. ,l modelo WinNWin define un con unto de acti(idades de negociacin al principio de cada paso alrededor de la espiral# se definen las siguientes acti(idadesA ". 7dentificacin del sistema o subsistemas cla(e de los directi(os(U) (saber $u) $uieren). -. .eterminacin de Ccondiciones de (ictoriaD de los directi(os (saber $u) necesitan y los satisface) /. Legociacin de las condiciones C(ictoriaD de los directi(os para obtener condiciones C:ictoria 4 :ictoriaD (negociar para $ue ambos ganen). (U) .irecti(oA 0liente escogido con inter)s directo en el producto' $ue puede ser premiado por la organi&acin si tiene )xito o criticado si no. ,l modelo Win 4 Win %ace )nfasis en la negociacin inicial' tambi)n introduce / %itos en el proceso llamados Cpuntos de fi acinD' $ue ayudan a establecer

la completitud de un ciclo de la espiral' y proporcionan %itos de decisin antes de continuar el proyecto de desarrollo del software. *editar+ tapas en el desarrollo del software *editar+Captura! an"lisis # especificacin de requisitos >l inicio de un desarrollo (no de un proyecto)' esta es la primera fase $ue se reali&a' y' segHn el modelo de proceso adoptado' puede casi terminar para pasar a la prxima etapa (caso de 3odelo 0ascada ;ealimentado) o puede %acerse parcialmente para luego retomarla (caso 3odelo 7terati(o 7ncremental u otros de carcter e(oluti(o). ,n simple palabras y bsicamente' durante esta fase' se ad$uieren' reHnen y especifican las caractersticas funcionales y no funcionales $ue deber cumplir el futuro programa o sistema a desarrollar. Las bondades de las caractersticas' tanto del sistema o programa a desarrollar' como de su entorno' parmetros no funcionales y ar$uitectura dependen enormemente de lo bien lograda $ue est) esta etapa. ,sta es' probablemente' la de mayor importancia y una de las fases ms difciles de lograr certeramente' pues no es automati&able' no es muy t)cnica y depende en gran medida de la %abilidad y experiencia del analista $ue la realice. 7n(olucra fuertemente al usuario o cliente del sistema' por tanto tiene matices muy sub eti(os y es difcil de modelar con certe&a o aplicar una t)cnica $ue sea Cla ms cercana a la adecuadaD (de %ec%o no existe Cla estrictamente adecuadaD). !i bien se %an ideado (arias metodologas' incluso software de apoyo' para captura' elicitacin y registro de re$uisitos' no existe una forma infalible o absolutamente confiable' y deben aplicarse con untamente buenos criterios y muc%o sentido comHn por parte del o los analistas encargados de la tarea# es fundamental tambi)n lograr una fluida y adecuada comunicacin y comprensin con el usuario final o cliente del sistema. ,l artefacto ms importante resultado de la culminacin de esta etapa es lo $ue se conoce como especificacin de re$uisitos software o simplemente documento ,;!. 0omo se di o' la %abilidad del analista para interactuar con el cliente es fundamental# lo comHn es $ue el cliente tenga un ob eti(o general o problema $ue resol(er' no conoce en absoluto el rea (informtica)' ni su erga' ni

si$uiera sabe con precisin $u) debera %acer el producto software ($u) y cuantas funciones) ni' muc%o menos' cmo debe operar. ,n otros casos menos frecuentes' el cliente CpiensaD $ue sabe precisamente lo $ue el software tiene $ue %acer' y generalmente acierta muy parcialmente' pero su empecinamiento entorpece la tarea de elicitacin. ,l analista debe tener la capacidad para lidiar con este tipo de problemas' $ue incluyen relaciones %umanas# tiene $ue saber ponerse al ni(el del usuario para permitir una adecuada comunicacin y comprensin. ,scasas son las situaciones en $ue el cliente sabe con certe&a e incluso con completitud lo $ue re$uiere de su futuro sistema' este es el caso ms sencillo para el analista. Las tareas relati(as a captura' elicitacin' modelado y registro de re$uerimientos' adems de ser sumamente importante' puede llegar a ser dificultosa de lograr acertadamente y lle(ar bastante tiempo relati(o al proceso total del desarrollo# al proceso y metodologas para lle(ar a cabo este con unto de acti(idades normalmente se las asume parte propia de la 7ngeniera de !oftware' pero dada la antedic%a comple idad' actualmente se %abla de una 7ngeniera de re$uisitos"- ' aun$ue ella aHn no existe formalmente. Iay grupos de estudio e in(estigacin' en todo el mundo' $ue estn exclusi(amente abocados a idear modelos' t)cnicas y procesos para intentar lograr la correcta captura' anlisis y registro de re$uerimientos. ,stos grupos son los $ue normalmente %ablan de la 7ngeniera de re$uisitos# es decir se plantea )sta como un rea o disciplina pero no como una carrera uni(ersitaria en si misma. >lgunos re$uisitos no necesitan la presencia del cliente' para ser capturados o anali&ados# en ciertos casos los puede proponer el mismo analista o' incluso' adoptar unilateralmente decisiones $ue considera adecuadas (tanto en re$uerimientos funcionales como no funcionales). 2or citar e emplos probablesA >lgunos re$uisitos sobre la ar$uitectura del sistema' re$uisitos no funcionales tales como los relati(os al rendimiento' ni(el de soporte a errores operati(os' plataformas de desarrollo' relaciones internas o ligas entre la informacin (entre registros o tablas de datos) a almacenar en caso de bases o bancos de datos' etc. >lgunos funcionales tales como opciones secundarias o de soporte necesarias para una me or o ms sencilla operati(idad# etc.

La obtencin de especificaciones a partir del cliente (u otros actores inter(inientes) es un proceso %umano muy interacti(o e iterati(o# normalmente a medida $ue se captura la informacin' se la anali&a y realimenta con el cliente' refinndola' puli)ndola y corrigiendo si es necesario# cual$uiera sea el m)todo de ,;! utili&ado. ,L analista siempre debe llegar a conocer la temtica y el problema $ue resol(er' dominarlo' %asta cierto punto' %asta el mbito $ue el futuro sistema a desarrollar lo abar$ue. 2or ello el analista debe tener alta capacidad para comprender problemas de muy di(ersas reas o disciplinas de traba o ($ue no son especficamente suyas)# as por e emplo' si el sistema a desarrollar ser para gestionar informacin de una aseguradora y sus sucursales remotas' el analista se debe compenetrar en cmo ella traba a y mane a su informacin' desde ni(eles muy ba os e incluso llegando %asta los gerenciales. .ada a gran di(ersidad de campos a cubrir' los analistas suelen ser asistidos por especialistas' es decir gente $ue conoce profundamente el rea para la cual se desarrollar el software# e(identemente una Hnica persona (el analista) no puede abarcar tan (asta cantidad de reas del conocimiento. ,n empresas grandes de desarrollo de productos software' es comHn tener analistas especiali&ados en ciertas reas de traba o. 0ontrariamente' no es problema del cliente' es decir )l no tiene por $u) saber nada de software' ni de dise5os' ni otras cosas relacionadas# slo se debe limitar a aportar ob eti(os' datos e informacin (de mano propia o de sus registros' e$uipos' empleados' etc) al analista' y guiado por )l' para $ue' en primera instancia' defina el C$niverso de DiscursoD' y con posterior traba o logre confeccionar el adecuado documento ,;!. ,s bien conocida la presin $ue sufren los desarrolladores de sistemas informticos para comprender y rescatar las necesidades de los clientesMusuarios. 0uanto ms comple o es el contexto del problema ms difcil es lograrlo' a (eces se fuer&a a los desarrolladores a tener $ue con(ertirse en casi expertos de los dominios $ue anali&an. 0uando esto no sucede es muy probable $ue se genere un con unto de re$uisitos"/ errneos o incompletos y por lo tanto un producto de software con alto grado de desaprobacin por parte de los clientesMusuarios y un altsimo costo de reingeniera y mantenimiento. ,odo aquello que no se detecte( o resulte mal entendido en la etapa inicial pro%ocar un fuerte impacto negati%o en los requisitos( propagando esta corriente degradante a lo largo de todo el

proceso de desarrollo e incrementando su perjuicio cuanto ms tarda sea su deteccin(=ell y F%ayer "?98)(.a(is "??/). *editar+%rocesos! modelado # formas de elicitacin de requisitos !iendo $ue la captura' elicitacin y especificacin de re$uisitos' es una parte crucial en el proceso de desarrollo de software' ya $ue de esta etapa depende el logro de los ob eti(os finales pre(istos' se %an ideado modelos y di(ersas metodologas de traba o para estos fines. Fambi)n existen %erramientas software $ue apoyan las tareas relati(as reali&adas por el ingeniero en re$uisitos. ,l estndar 7,,, </QN"??< brinda una normali&acin de las C2rcticas ;ecomendadas para la ,specificacin de ;e$uisitos !oftwareD. "1 > medida $ue se obtienen los re$uisitos' normalmente se los (a anali&ando' el resultado de este anlisis' con o sin el cliente' se plasma en un documento' conocido como ,;! o ,specificacin de ;e$uisitos !oftware' cuya estructura puede (enir definida por (arios estndares' tales como 0337. Jn primer paso para reali&ar el rele(amiento de informacin es el conocimiento y definicin acertada lo $ue se conoce como CJni(erso de .iscursoD del problema' $ue se define y entiende porA $niverso de Discurso &$deD'A es el contexto general en el cual el software deber ser desarrollado y deber operar. ,l Jde. incluye todas las fuentes de informacin y todas las personas relacionadas con el software. ,sas personas son conocidas tambi)n como actores de ese uni(erso. ,l Jde. es la realidad circunstanciada por el con unto de ob eti(os definidos por $uienes demandaron el software. > partir de la extraccin y anlisis de informacin en su mbito se obtienen todas las especificaciones necesarias y tipos de re$uisitos para el futuro producto software. ,l ob eti(o de la 7ngeniera de re$uisitos (7;) es sistemati&ar el proceso de definicin de re$uisitos permitiendo elicitar' modelar y anali&ar el problema' generando un compromiso entre los ingenieros de re$uisitos y los clientesMusuarios' ya $ue ambos participan en la generacin y definicin de los re$uisitos del sistema. La 7; aporta un con unto de m)todos' t)cnicas y %erramientas $ue asisten a los ingenieros de re$uisitos (analistas) para

obtener re$uerimientos lo ms seguros' (eraces' completos y oportunos posibles' permitiendo bsicamenteA

0omprender el problema @acilitar la obtencin de las necesidades del clienteMusuario :alidar con el clienteMusuario Karanti&ar las especificaciones de re$uisitos

!i bien existen di(ersas formas' modelos y metodologas para elicitar' definir y documentar re$uerimientos' no se puede decir $ue alguna de ellas sea me or o peor $ue la otra' suelen tener muc%simo en comHn' y todas cumplen el mismo ob eti(o. !in embargo' lo $ue si se puede decir sin dudas es $ue es indispensable utili&ar alguna de ellas para documentar las especificaciones del futuro producto software. >s por e emplo' %ay un grupo de in(estigacin argentino $ue desde %ace (arios a5os %a propuesto y estudia el uso del L,L (L)xico ,xtendido del Lengua e) y ,scenarios como metodologa' a$u "6 se presenta una de las tantas referencias y bibliografa sobre ello. Otra forma' ms ortodoxa' de capturar y documentar re$uisitos se puede obtener en detalle' por e emplo' en el traba o de la Jni(ersidad de !e(illa sobre C3etodologa para el >nlisis de ;e$uisitos de !istemas !oftwareD. "8 ,n la @ig. 9 se muestra un es$uema' ms o menos riguroso' aun$ue no detallado' de los pasos y tareas a seguir para reali&ar la captura' anlisis y especificacin de re$uerimientos software. Fambi)n all se obser(a $u) artefacto o documento se obtiene en cada etapa del proceso. ,n el diagrama no se explicita metodologa o modelo a utili&ar' sencillamente se pautan las tareas $ue deben cumplirse' de alguna manera.

@ig. 9 N .iagrama de tareas para captura y anlisis de re$uisitos. Jna posible lista' general y ordenada' de tareas recomendadas para obtener la definicin de lo $ue se debe reali&ar' los productos a obtener y las t)cnicas a emplear durante la acti(idad de elicitacin de re$uisitos' en fase de,specificacin de ;e$uisitos !oftware esA ". Obtener informacin sobre el dominio del problema y el sistema actual (Jde.). -. 2reparar y reali&ar las reuniones para elicitacinMnegociacin. /. 7dentificarMre(isar los ob eti(os del usuario. 1. 7dentificarMre(isar los ob eti(os del sistema.
5. 7dentificarMre(isar los re$uisitos de informacin. 6. 7dentificarMre(isar los re$uisitos funcionales. 7. 7dentificarMre(isar los re$uisitos no funcionales.

<. 2riori&ar ob eti(os y re$uisitos. >lgunos principios bsicos a tener en cuentaA

2resentar y entender cabalmente el dominio de la informacin del problema.

.efinir correctamente las funciones $ue debe reali&ar el !oftware. ;epresentar el comportamiento del software a consecuencias de acontecimientos externos' particulares' incluso inesperados. ;econocer re$uisitos incompletos' ambiguos o contradictorios. .i(idir claramente los modelos $ue representan la informacin' las funciones y comportamiento y caractersticas no funcionales.

*editar+Clasificacin e identificacin de requerimientos !e pueden identificar dos formas de re$uisitosA

;e$uisitos de usuarioA Los re$uisitos de usuario son frases en lengua e natural unto a diagramas con los servicios que el sistema debe proporcionar' as como las restricciones ba o las $ue debe operar. ;e$uisitos de sistemaA Los re$uisitos de sistema determinan los servicios del sistema y pero con las restricciones en detalle. !ir(en como contrato.

,s decir' ambos son lo mismo' pero con distinto ni(el de detalle. , emplo de re$uisito de usuarioA ,l sistema debe %acer pr)stamos , emplo de re$uisito de sistemaA @uncin pr)stamoA entrada cdigo socio' cdigo e emplar# salidaA fec%a de(olucin# etc. !e clasifican en tres los tipos de re$uisitos de sistemaA

;e$uisitos funcionales

Los re$uisitos funcionales describenA

Los ser(icios $ue proporciona el sistema (funciones). La respuesta del sistema ante determinadas entradas. ,l comportamiento del sistema en situaciones particulares. ;e$uisitos no funcionales

Los re$uisitos no funcionales son restricciones de los ser(icios o funciones $ue ofrece el sistema (e . cotas de tiempo' proceso de desarrollo' rendimiento' etc.)

, emplo ". La biblioteca 0entral debe ser capa& de atender simultneamente a todas las bibliotecas de la Jni(ersidad , emplo -. ,l tiempo de respuesta a una consulta remota no debe ser superior a "M- s > su (e&' %ay tres tipos de re$uisitos no funcionalesA

;e$uisitos del producto. ,specifican el comportamiento del producto (, . prestaciones' memoria' tasa de fallos' etc.) ;e$uisitos organi&ati(os. !e deri(an de las polticas y procedimientos de las organi&aciones de los clientes y desarrolladores (, . estndares de proceso' lengua es de programacin' etc.) ;e$uisitos externos. !e deri(an de factores externos al sistema y al proceso de desarrollo (, . re$uisitos legislati(os' )ticos' etc.) ;e$uisitos del dominio.

Los re$uisitos del dominio se deri(an del dominio de la aplicacin y refle an caractersticas de dic%o dominio. 2ueden ser funcionales o no funcionales. , . ,l sistema de biblioteca de la Jni(ersidad debe ser capa& de exportar datos mediante el Lengua e de 7ntercomunicacin de =ibliotecas de ,spa5a (L7=,). , . ,l sistema de biblioteca no podr acceder a bibliotecas con material censurado. *editar+Dise(o del sistema ,n ingeniera de software' el dise5o es una fase de ciclo de (ida del software. !e basa en la especificacin de re$uisitos producido por el anlisis de los re$uerimientos (fase de anlisis)' el dise5o define cmo estos re$uisitos se cumplirn' la estructura $ue debe darse al sistema de software para $ue se %aga realidad. ,l dise5o sigue siendo una fase separada del la programacin o codificacin' esta ultima corresponde a la traduccin en un determinadolengua e de programacin de las premisas adoptadas en el dise5o.

Las distinciones entre las acti(idades mencionadas %asta a%ora no siempre son claras cmo se $uisiera en las teoras clsicas de ingeniera de software. ,l dise5o' en particular' puede describir el funcionamiento interno de un sistema en diferentes ni(eles de detalle' cada una de ellos se coloca en una posicin intermedia entre el anlisis y codificacin. Lormalmente se entiende por Rdise5o de la ar$uitecturaR al dise5o de Rmuy alto ni(elR' $ue slo define la estructura del sistema en t)rminos de la mdulos de software de $ue se compone y las relaciones macroscpicas entre ellos. > este ni(el de dise5o pertenecen frmulas comoclienteNser(idor o Vtres ni(elesW' o' ms generalmente' las decisiones sobre el uso de la ar$uitectura de %ardware especial $ue se utilice' el sistema operati(o' .=3!' 2rotocolos de red' etc. Jn ni(el intermedio de detalle puede definir la descomposicin del sistema en mdulos' pero esta (e& con una referencia ms o menos explcita al modo de descomposicin $ue ofrece el particular lengua e de programacin con el $ue el desarrollo se (a a implementar' por e emplo' en un dise5o reali&ado con la tecnologa de ob etos' el proyecto podra describir al sistema en t)rminos de clases y sus interrelaciones. ,l dise5o detallado' por Hltimo' es una descripcin del sistema muy cercana a la codificacin (por e emplo' describir no slo las clases en abstracto' sino tambi)n sus atributos y los m)todos con sus tipos). .ebido a la naturale&a RintangibleR del software' y dependiendo de las %erramientas $ue se utili&an en el proceso' la frontera entre el dise5o y la codificacin tambi)n puede ser (irtualmente imposible de identificar. 2or e emplo' algunas %erramientas 0>!, son capaces de generar cdigo a partir de diagramas J3L' los $ue describen grficamente la estructura de un sistema software. *editar+Codificacin del software .urante esta etapa se reali&an las tareas $ue comHnmente se conocen como programacin# $ue consiste' esencialmente' en lle(ar a cdigo fuente' en el lengua e de programacin elegido' todo lo dise5ado en la fase anterior. ,sta tarea la reali&a el programador' siguiendo por

completo los lineamientos impuestos en el dise5o y en consideracin siempre a los re$uisitos funcionales y no funcionales (,;!) especificados en la primera etapa. ,s comHn pensar $ue la etapa de programacin o codificacin (algunos la llaman implementacin) es la $ue insume la mayor parte del traba o de desarrollo del software# sin embargo' esto puede ser relati(o (y generalmente aplicable a sistemas de pe$ue5o porte) ya $ue las etapas pre(ias son cruciales' crticas y pueden lle(ar bastante ms tiempo. !e suele %acer estimaciones de un /QP del tiempo total insumido en la programacin' pero esta cifra no es consistente ya $ue depende en gran medida de las caractersticas del sistema' su criticidad y el lengua e de programacin elegido. 9 ,n tanto menor es el ni(el del lengua e mayor ser el tiempo de programacin re$uerido' as por e emplo se tardara ms tiempo en codificar un algoritmo en lengua e ensamblador $ue el mismo programado en lengua e 0. 3ientras se programa la aplicacin' sistema' o software en general' se reali&an tambi)n tareas de depuracin' esto es la labor de ir liberando al cdigo de los errores factibles de ser %allados en esta fase (de semntica' sintctica y lgica). Iay una suerte de solapamiento con la fase siguiente' ya $ue para depurar la lgica es necesario reali&ar pruebas unitarias' normalmente con datos de prueba# claro es $ue no todos los errores sern encontrados slo en la etapa de programacin' %abrn otros $ue se encontrarn durante las etapas subsiguientes. La aparicin de algHn error funcional (mala respuesta a los re$uerimientos) e(entualmente puede lle(ar a retornar a la fase de dise5o antes de continuar la codificacin. .urante la fase de programacin' el cdigo puede adoptar (arios estados' dependiendo de la forma de traba o y del lengua e elegido' a saberA

0digo fuenteA es el escrito directamente por los programadores en editores de texto' lo cual genera el programa. 0ontiene el con unto de instrucciones codificadas en algHn lengua e de alto ni(el. 2uede estar distribuido en pa$uetes' procedimientos' bibliotecas fuente' etc.

0digo ob etoA es el cdigo binario o intermedio resultante de procesar con un compilador el cdigo fuente. 0onsiste en una traduccin completa y de una sola (e& de )ste Hltimo. ,l cdigo ob eto no es inteligible por el ser %umano (normalmente es formato binario) pero tampoco es directamente e ecutable por la computadora. !e trata de una representacin intermedia entre el cdigo fuente y el cdigo e ecutable' a los fines de un enlace final con las rutinas de biblioteca y entre procedimientos o bien para su uso con un pe$ue5o int)rprete intermedio *a modo de distintos e emplos ()ase ,J2IO;7>' (int)rprete intermedio)' @O;F;>L (compilador puro) -./L (-icrosoft /ntermediate Language) (int)rprete) y =>!70 (int)rprete puro' int)rprete intermedio' compilador intermedio o compilador puro' depende de la (ersin utili&ada)+.

,l cdigo ob eto no e)iste si el programador traba a con un lengua e a modo de int*rprete puro' en este caso el mismo int)rprete se encarga de traducir y e ecutar lnea por lnea el cdigo fuente (de acuerdo al flu o del programa)' en tiempo de e ecucin. ,n este caso tampoco e)iste el o los arc%i(os de cdigo e ecutable. Jna des(enta a de esta modalidad es $ue la e ecucin del programa o sistema es un poco ms lenta $ue si se %iciera con un int)rprete intermedio' y bastante ms lenta $ue si existe el o los arc%i(os de cdigo e ecutable. ,s decir no fa(orece el rendimiento en (elocidad de e ecucin. 2ero una gran (enta a de la modalidad int)rprete puro' es $ue el esta forma de traba o facilita enormemente la tarea de depuracin del cdigo fuente (frente a la alternati(a de %acerlo con un compilador puro). @recuentemente se suele usar una forma mixta de traba o (si el lengua e de programacin elegido lo permite)' es decir inicialmente traba ar a modo de int)rprete puro' y una (e& depurado el cdigo fuente (liberado de errores) se utili&a un compilador del mismo lengua e para obtener el cdigo e ecutable completo' con lo cual se agili&a la depuracin y la (elocidad de e ecucin se optimi&a.

0digo e ecutableA ,s el cdigo binario resultado de enla&ar uno o ms fragmentos de cdigo ob eto con las rutinas y bibliotecasnecesarias. 0onstituye uno o ms arc%i(os binarios con un formato tal $ue el sistema operati(o es capa& de cargarlo en la memoria ;>3(e(entualmente tambi)n parte en una memoria (irtual)' y proceder a su e ecucin directa. 2or lo anterior se dice $ue el cdigo e ecutable es directamente Cinteligible por la computadoraD. ,l cdigo e ecutable' tambi)n conocido como cdigo m$uina' no existe si se programa con modalidad de Cint)rprete puroD.

*editar+%rue+as &unitarias # de integracin' ,ntre las di(ersas pruebas $ue se le efectHan al software se pueden distinguir principalmenteA

2rueba unitariasA 0onsisten en probar o testear pie&as de software pe$ue5as# a ni(el de secciones' procedimientos' funciones y mdulos# a$uellas $ue tengan funcionalidades especficas. .ic%as pruebas se utili&an para asegurar el correcto funcionamiento de secciones de cdigo' muc%o ms reducidas $ue el con unto' y $ue tienen funciones concretas con cierto grado de independencia. 2ruebas de integracinA !e reali&an una (e& $ue las pruebas unitarias fueron concluidas e+itosamente# con )stas se intenta asegurar $ue el sistema completo' incluso los subsistemas $ue componen las pie&as indi(iduales grandes del software funcionen correctamente al operar e inteoperar en con unto.

Las pruebas normalmente se efectHan con los llamados datos de prueba' $ue es un con unto seleccionado de datos tpicos a los $ue puede (erse sometido el sistema' los mdulos o los blo$ues de cdigo. Fambi)n se escogenA .atos $ue lle(an a condiciones lmites al software a fin de probar su tolerancia y robuste&# datos de utilidad para mediciones de rendimiento# datos $ue pro(ocan condiciones e(entuales o particulares poco comunes y a las $ue el software normalmente no estar sometido pero pueden ocurrir# etc. Los Cdatos de pruebaD no

necesariamente son ficticios o CcreadosD' pero normalmente s lo son los de poca probabilidad de ocurrencia. Keneralmente' existe un fase probatoria final y completa del software' llamada =eta Fest' durante la cual el sistema instalado en condiciones normales de operacin y traba o es probado ex%austi(amente a fin de encontrar errores' inestabilidades' respuestas errneas' etc. $ue %ayan pasado los pre(ios controles. ,stas son normalmente reali&adas por personal idneo contratado o afectado especficamente a ello. Los posibles errores encontrados se transmiten a los desarrolladores para su depuracin. ,n el caso de software de desarrollo Ca pedidoD' el usuario final (cliente) es el $ue reali&a el =eta Fest' teniendo para ello un perodo de prueba pactado con el desarrollador. *editar+,nstalacin # paso a produccin La instalacin del software es el proceso por el cual los programas desarrollados son transferidos apropiadamente al computador destino' iniciali&ados' y' e(entualmente' configurados# todo ello con el propsito de ser ya utili&ados por el usuario final. 0onstituye la etapa final en el desarrollo propiamente dic%o del software. Luego de )sta el producto entrar en la fase de funcionamiento y produccin' para el $ue fuera dise5ado. La instalacin' dependiendo del sistema desarrollado' puede consistir en una simple copia al disco rgido destino (casos raros actualmente)# o bien' ms comHnmente' con una de comple idad intermedia en la $ue los distintos arc%i(os componentes del software (e ecutables'bibliotecas' datos propios' etc.) son descomprimidos y copiados a lugares especficos preestablecidos del disco# incluso se crean (nculos con otros productos' adems del propio sistema operati(o. ,ste Hltimo caso' comHnmente es un proceso bastante automtico $ue es creado y guiado con %eramientas software especficas (empa$uetado y distribucin' instaladores). ,n productos de mayor comple idad' la segunda alternati(a es la utili&ada' pero es reali&ada o guiada por especialistas# puede incluso re$uerirse la instalacin en (arios y distintos computadores (instalacin distribuida).

Fambi)n' en software de mediana y alta comple idad normalmente es re$uerido un proceso de configuracin y c%e$ueo' por el cual se asignan adecuados parmetros de funcionamiento y se testea la operati(idad funcional del producto. ,n productos de (enta masi(a las instalaciones completas' si son relati(amente simples' suelen ser reali&adas por los propios usuarios finales (tales como sistemas operati(os' pa$uetes de oficina' utilitarios' etc.) con %erramientas propias de instalacin guiada# incluso la configuracin suele ser automtica. ,n productos de dise5o especfico o Ca medidaD la instalacin $ueda restringida' normalmente' a personas especialistas in(olucradas en el desarrollo del software en cuestin. Jna (e& reali&ada exitosamente la instalacin del software' el mismo pasa a la fase de produccin (operati(idad)' durante la cual cumple las funciones para las $ue fue desarrollado' es decir' es finalmente utili&ado por el (o los) usuario final' produciendo los resultados esperados. *editar+Mantenimiento ,l mantenimiento de software es el proceso de control' me ora y optimi&acin del software ya desarrollado e instalado' $ue tambi)n incluye depuracin de errores y defectos $ue puedan %aberse filtrado de la fase de pruebas de control y beta test. ,sta fase es la Hltima (antes de iterar' segHn el modelo empleado) $ue se aplica al ciclo de (ida del desarrollo de software. La fase de mantenimiento es la $ue (iene despu)s de $ue el software est operati(o y en produccin. .e un buen dise5o y documentacin del desarrollo depender cmo ser la fase de mantenimiento' tanto en costo temporal como monetario. 3odificaciones reali&adas a un software $ue fue elaborado con una documentacin indebida o pobre y mal dise5o puede llegar a ser tanto o ms costosa $ue desarrollar el software desde el inicio. 2or ello' es de fundamental importancia respetar debidamente todas las tareas de las fases del desarrollo y mantener adecuada y completa la documentacin. ,l perodo de la fase de mantenimiento es normalmente el mayor en todo el ciclo de (ida.9 ,sta fase in(olucra tambi)n actuali&aciones y

e(oluciones del software# no necesariamente implica $ue el sistema tu(o errores. Jno o ms cambios en el software' por e emplo de adaptacin o e(oluti(os' puede lle(ar incluso a re(er y adaptar desde parte de las primeras fases del desarrollo inicial' alterando todas las dems# dependiendo de cun profundos sean los cambios. ,l modelo cascada comHn es particularmente costoso en mantenimiento' ya $ue su rigide& implica $ue cual$uier cambio pro(oca regreso a fase inicial y fuertes alteraciones en las dems fases del ciclo de (ida. .urante el perodo de mantenimiento' es comHn $ue sur an nue(as re(isiones y (ersiones del producto# $ue lo liberan ms depurado' con mayor y me or funcionalidad' me or rendimiento' etc. :arias son las facetas $ue pueden ser alteradas para pro(ocar cambios deseables' e(oluti(os' adaptaciones o ampliaciones y me oras. =sicamente se tienen los siguientes tipos de cambiosA

2erfecti(osA >$uellos $ue lle(an a una me ora de la calidad interna del software en cual$uier aspectoA ;eestructuracin del cdigo' definicin ms clara del sistema y su documentacin# optimi&acin del rendimiento y eficiencia. ,(oluti(osA >gregados' modificaciones' incluso eliminaciones' necesarias en el software para cubrir su expansin o cambio' segHn las necesidades del usuario. >dapti(osA 3odificaciones $ue afectan a los entornos en los $ue el sistema opera' tales comoA 0ambios de configuracin del %ardware (por actuali&acin o me ora de componentes electrnicos)' cambios en el software de base' en gestores de base de datos' en comunicaciones' etc. 0orrecti(osA >lteraciones necesarias para corregir errores de cual$uier tipo en el producto software desarrollado.

*editar+0arcter e(oluti(o del software "9 ,l software es el producto deri(ado del proceso de desarrollo' segHn la ingeniera de software. ,ste producto es intrnsecamente e(oluti(o durante su ciclo de (ida. ,l software e(oluciona' en general' generando

(ersiones cada (e& ms completas' comple as' me oradas' optimi&adas en algHn aspecto' adecuadas a nue(as plataformas (sean de %ardware o sistemas operati(os)' etc. 0uando un sistema de a de e(olucionar' e(entualmente cumplir con su ciclo de (ida' entrar en obsolescencia e ine(itablemente' tarde o temprano' ser reempla&ado por un producto nue(o. ,l software e(oluciona sencillamente por $ue se debe adaptar a los cambios del entorno' sean funcionales (exigencias de usuarios)' operati(os' de plataforma o ar$uitectura %ardware. La dinmica de e(olucin del software es el estudio de los cambios del sistema. La mayor contribucin en esta rea fue reali&ada por 3eir 3. Le%man y =elady' comen&ando en los a5os 9Q y <Q. !u traba o continu en la d)cada de "??Q' con Le%man y otros in(estigadores "< de rele(ancia en la realimentacin en los procesos de e(olucin (Le%man' "??8# Le%man et al.' "??<# le%man et al.' -QQ"). > partir de esos estudios propusieron un con unto de leyes (conocidas como leyes de Le%man)? respecto de los cambios producidos en los sistemas. ,stas leyes (en realidad son %iptesis) son in(ariantes y ampliamente aplicables. Le%man y =elady anali&aron el crecimiento y la e(olucin de (arios sistemas software de gran porte# deri(ando finalmente' segHn sus medidas' las siguientes oc%o leyesA ". 0ambio continuoA Jn programa $ue se usa en un entorno real necesariamente debe cambiar o se (ol(er progresi(amente menos Htil en ese entorno. -. 0omple idad crecienteA > medida $ue un programa en e(olucin cambia' su estructura tiende a ser cada (e& ms comple a. !e deben dedicar recuersos extras para preser(ar y simplificar la estrucutura. /. ,(olucin prolongada del programaA La e(olucin de los programas es un proceso autorregulati(o. Los atributos de los sistemas' tales como tama5o' tiempo entre entregas y la

cantidad de errores documentados son aproximadamente in(ariantes para cada entrega del sistema. 1. ,stabilidad organi&acionalA .urante el tiempo de (ida de un programa' su (elocidad de desarrollo es aproximadamente constante e independiente de los recursos dedicados al desarrollo del sistema. 6. 0onser(acin de la familiaridadA .urante el tiempo de (ida de un sistema' el cambio incremental en cada entrega es aproximadamente constante. 8. 0recimiento continuadoA La funcionalidad ofrecida por los sistemas tiene $ue crecer continuamente para mantener la satisfaccin de los usuarios. 9. .ecremento de la calidadA La calidad de los sistemas software comen&ar a disminuir a menos $ue dic%os sistemas se adapten a los cambios de su entorno de funcionamiento. <. ;ealimentacin del sistemaA Los procesos de e(olucin incorporan sistemas de realimentacin multiagente y multibucle y estos deben ser tratados como sistemas de realimentacin para lograr una me ora significati(a del producto. *editar+:)ase tambi)n

2ortalA!oftware. 0ontenido relacionado con Software. 7ngeniera de software 2rograma informtico >plicacin informtica 2rogramacin @ases del desarrollo de software !oftware colaborati(o !oftware libre

7ngeniera informtica

*editar+Modelos de ciclo de vida

3odelo en cascada o secuencial 3odelo iterati(o incremental 3odelo e(oluti(o espiral 3odelo de prototipos 3odelo de desarrollo rpido

*editar+;eferencias ". X .iccionario de la lengua espa5ola -QQ6 (-Q"Q). wordreference.com (ed.)A CsoftwareD (diccionario). ,spasaN 0alpe. 0onsultado el " de febrero de -Q"Q. -. X ;eal >cademia ,spa5ola. C!ignificado de la palabra !oftwareD. 0iccionario de la Lengua Espaola( !!//1 Edicin . 0onsultado el "1 de mar&o de -QQ<. /. X ;eal >cademia ,spa5ola. CJso de la palabra !oftwareD. 0iccionario pan2ispnico de dudas( 3.4 Edicin (octubre 5667). 0onsultado el < de febrero de -QQ?. 1. X 2ressman' ;oger !. (-QQ/). C,l productoD. /ngeniera del .oft$are( un enfoque "rctico( 8uinta edicin edicin. . 3)xicoA 3c Kraw Iill.
5. X 7,,, !td' 7,,, !oftware ,ngineering !tandardA Klossary of

!oftware ,ngineering Ferminology. 7,,, 0omputer !ociety 2ress' "??/ 8. X a b c d e f g h i j k C0iclo de :ida del !oftwareD. Krupo >larcos N ,scuela !uperior de 7nformtica de 0iudad ;eal. 9. X a b c d e 2ressman' ;oger !. (-QQ/). C,l procesoD. /ngeniera del .oft$are( un enfoque "rctico( 8uinta edicin edicin. . 3exicoA 3c Kraw Iill.

8. X CF)rmino R,licitarRD. "ra. acepcin N WiGtionary. 0onsultado el

"6 .ic -QQ<. ?. X a b c d CLeyes de e(olucin del !oftwareD. 0onnexions N ,ducational content repository.
10. X

C0iclo de (ida del !oftware y 3odelos de desarrolloD. 7nstituto de @ormacin 2rofesional N Libros .igitales.

a b c d e f g h i

"". X a b c C,(olucin del !oftwareD. 0onnexions N ,ducational content repository. "-. X !oftware ;e$uirements ,ngineering' -nd ,dition' 7,,, 0omputer !ociety. Los >lamitos' 0>' "??9 (0ompendio de papers y artculos en ingeniera de re$uisitos) "/. X C777 WorGs%op de ,ngen%aria de ;e$uisitosD. W,; -QQQ' ;io de Eaneiro' -QQQ.. "1. X C;ecommended 2ractice for !oftware ;e$uirements !pecificationD. 7,,,N!> !tandards =oard. "6. X CL,L y ,scenarios como metodologa en 7ngeniera de ;e$uisitosD. Jni(. de 3orn' =uenos >ires. "8. X C3etodologa para el anlisis de ;e$uisitos de !istemas !oftwareD. Jni(. de !e(illa' -QQ". "9. X !ommer(ille' 7an (-QQ6). C-"N,(olucin del softwareD. /ngeniera del .oft$are.. ,spa5aA 2earson ,ducacion !.>.. "<. X C>03 @ellow 2rofile for 3eir 3. (3anny) Le%manD. >03 (/"N Q6N-QQ9). 0onsultado el -9N""N-Q"". *editar+=ibliografa *editar+-i+ros

E>0O=!OL' 7(ar# =OO0I' Krady# ;J3=>JKI' Eames (-QQQ) (en ,spa5ol). El "roceso 9nificado de 0esarrollo de .oft$are . 2earson >ddissonNWesley. 2ressman' ;oger !. (-QQ/) (en ,spa5ol). /ngeniera del .oft$are( un enfoque "rctico (Tuinta edicin edicin). 3c Kraw Iill. 7!=L <1N1<"N/-"1N?. E>0O=!OL# =OO0I# ;J3=>JKI ("???) (en ,spa5ol). 9-L : El Lengua;e 9nificado de -odelado. 2earson >ddissonNWesley. ;ational !oftware 0orporation' >ddison Wesley 7beroamericana. 7!=L <1N9<-?NQ-<N". Iaeberer' >. 3.# 2. >. !. :eloso' K. =aum ("?<<) (en ,spa5ol). <ormali#acin del proceso de desarrollo de soft$are (,d. preliminar edicin). =uenos >iresA Kapelus&. 7!=L ?6QN"/N?<<QN/. @owler' 3artin# Kendall !ccott ("???) (en ,spa5ol). 9-L =ota a =ota. >ddison Wesley. 7!=L ?9<?8<111/81<. Loucopoulos' 2ericles# KaraGostas' :. ("??6) (en ingl)s). .)stem 'equirements Engineering. LondonA 3cKrawNIill 0ompanies. pp. "8Q p.. 7!=L ?9<NQQ99Q9<1/Q. !ommer(ille' 7an# 2. !awyer ("??9) (en ingl)s). 'equirements Engineering: A =ood "ractice =uide ("ra. edition edicin). Wiley 4 !ons. pp. 1Q1 p.. 7!=L ?9<NQ19"?91111. Kottesdiener' ,llen# 2. !awyer (-QQ-) (en ingl)s). 'equirements b) &ollaboration: >or?s2ops for 0efining @eeds. >ddisonNWesley 2rofessional. pp. /8< p.. 7!=L ?9<NQ-Q"9<8Q81. !ommer(ille' 7an (-QQ6) (en ,spa5ol). /ngeniera del soft$are (9ma. edicin). 3adridA 2earson ,ducacion !.>.. 7!=L <1N9<-?NQ91N6.

*editar+.rtculos # revistas

Weit&enfeld N C,l 2roceso para .esarrollo de !oftwareD N -QQ-

0arlos ;eynoso N C3)todos Ieterodoxos en .esarrollo de !oftwareD N -QQ1 Krupo 7!!7 N Jni(. 2olit)cnica de :alencia N C3etodologas Ygiles en el .esarrollo de !oftwareD N -QQ/ 3artin @owler N CLa Lue(a 3etodologaD N -QQ/ 0utter 7F Eournal Z C;e$uirements ,ngineering and 3anagementD. >ugust -6' -QQQ. 0utter 0onsortium. C!oftware ;e$uirements ,ngineeringD' -nd ,dition' 7,,, 0omputer !ociety. Los >lamitos' 0>' "??9 (0ompendio de papers y artculos en ingeniera de re$uisitos).

Le%man' 3.3. N CLaws of !oftware ,(olution ;e(isitedD' pos. pap.' ,W!2F?8' Oct. "??8' LL0! ""1?' !pringer :erlag' "??9' pp. "Q<N "-1

%ttpAMMes.wiGipedia.orgMwiGiM!oftware