Software

DeWikipedia,laenciclopedialibre
Se conoce como software1 al equipo lgico o soporte
lgico de un sistema informtico, que comprende el
conjuntodeloscomponenteslgicosnecesariosquehacen
posible la realizacin de tareas especficas, en
contraposicinaloscomponentesfsicosquesonllamados
hardware.

Software

Loscomponenteslgicosincluyen,entremuchosotros,las
aplicaciones informticas, tales como el procesador de
texto, que permite al usuario realizar todas las tareas
concernientesalaedicindetextoselllamadosoftwarede
sistema, tal como el sistema operativo, que bsicamente
permite al resto de los programas funcionar
adecuadamente,facilitandotambinlainteraccinentrelos
componentes fsicos y el resto de las aplicaciones, y
proporcionandounainterfazconelusuario.
Elanglicismosoftwareeselmsampliamentedifundidoal
referirseaesteconcepto,especialmenteenlajergatcnica
en tanto que el trmino sinnimo logicial, derivado del
trminofrancslogiciel,esutilizadomayormenteenpases
yzonasdeinfluenciafrancesa.SuabreviaturaesSw.

ndice
1
2
3
4

Etimologa
Definicindesoftware
Clasificacindelsoftware
Procesodecreacindelsoftware
4.1 Modelosdeprocesoociclodevida
4.1.1 Modelocascada
4.1.2 Modelosevolutivos
4.1.2.1 Modelo
iterativo
incremental
4.1.2.2 Modeloespiral
4.1.2.3 Modelo espiral Win &
Win
4.2 Etapaseneldesarrollodelsoftware
4.2.1 Captura,
anlisis
y
especificacinderequisitos
4.2.1.1 Procesos, modelado y
formas de elicitacin de
requisitos
4.2.1.2 Clasificacin

Dentrodelacategoradesoftwaredeaplicacin
estnincluidoslosprocesadoresdetextocomo
LibreOfficeWriter(arriba)yloseditores
grficosrasterizadoscomoKrita(abajo).

BuscadordeProgramasenUbuntu
13.10

5
6
7
8
9

4.2.1.2 Clasificacin
e
identificacin
de
requisitos
4.2.2 Diseodelsistema
4.2.3 Codificacindelsoftware
4.2.4 Pruebas (unitarias y de
integracin)
4.2.5 Instalacinypasoaproduccin
4.2.6 Mantenimiento
Carcterevolutivodelsoftware
Referencias
Bibliografa
7.1 Libros
7.2 Artculosyrevistas
Vasetambin
8.1 Modelosdeciclodevida
Enlacesexternos

Etimologa
Software(pronunciacinAFI:[sftw]) es una palabra proveniente del ingls,que enespaol noposee
unatraduccinadecuadaalcontexto,porlocualselautilizaasiduamentesintraduciryasfueadmitidapor
la RealAcademia Espaola (RAE).2Aunque puede no ser estrictamente lo mismo, suele sustituirse por
expresionestalescomoprogramas(informticos)oaplicaciones(informticas)osoporteslgicos.3
SoftwareesloquesedenominaproductoenIngenieradesoftware.4

Definicindesoftware
Existen varias definiciones similares aceptadas para software, pero probablemente la ms formal sea la
siguiente:
Es el conjunto de los programas de cmputo, procedimientos, reglas, documentacin y datos
asociados,queformanpartedelasoperacionesdeunsistemadecomputacin.
Extradodelestndar729delIEEE5

Considerandoestadefinicin,elconceptodesoftwarevamsalldelosprogramasdecomputacinensus
distintos estados: cdigo fuente, binario o ejecutable tambin su documentacin, los datos a procesar e
inclusolainformacindeusuarioformanpartedelsoftware:esdecir,abarcatodolointangible,todolono
fsicorelacionado.
El trmino software fue usado por primera vez en este sentido por John W. Tukey en 1957. En la
ingenieradesoftwareylascienciasdelacomputacin,elsoftwareestodalainformacinprocesadapor
lossistemasinformticos:programasydatos.

Elconceptodeleerdiferentessecuenciasdeinstrucciones(programa)desdelamemoriadeundispositivo
paracontrolarlosclculosfueintroducidoporCharlesBabbagecomopartedesumquinadiferencial.La
teora que forma la base de la mayor parte del software moderno fue propuesta por Alan Turing en su
ensayode1936,Losnmeroscomputables,conunaaplicacinalproblemadedecisin.

Clasificacindelsoftware
Si bien esta distincin es, en cierto modo, arbitraria, y a veces confusa, a los fines prcticos se puede
clasificaralsoftwareentresgrandestipos:
Softwaredesistema:Suobjetivoesdesvincularadecuadamentealusuarioyalprogramadordelos
detallesdelsistemainformticoenparticularqueseuse,aislndoloespecialmentedelprocesamiento
referidoalascaractersticasinternasde:memoria,discos,puertosydispositivosdecomunicaciones,
impresoras, pantallas, teclados, etc. El software de sistema le procura al usuario y programador
adecuadasinterfacesdealtonivel,controladores,herramientasyutilidadesdeapoyoquepermitenel
mantenimientodelsistemaglobal.Incluyeentreotros:
Sistemasoperativos
Controladoresdedispositivos
Herramientasdediagnstico
HerramientasdeCorreccinyOptimizacin
Servidores
Utilidades
Softwaredeprogramacin:Eselconjuntodeherramientasquepermitenalprogramadordesarrollar
programasinformticos,usandodiferentesalternativasylenguajesdeprogramacin,deunamanera
prctica.Incluyenbsicamente:
Editoresdetexto
Compiladores
Intrpretes
Enlazadores
Depuradores
EntornosdeDesarrolloIntegrados(IDE):Agrupanlasanterioresherramientas,usualmenteen
unentornovisual,deformatalqueelprogramadornonecesiteintroducirmltiplescomandos
para compilar, interpretar, depurar, etc. Habitualmente cuentan con una avanzada interfaz
grficadeusuario(GUI).
Software de aplicacin: Es aquel que permite a los usuarios llevar a cabo una o varias tareas
especficas,encualquiercampodeactividadsusceptibledeserautomatizadooasistido,conespecial
nfasisenlosnegocios.Incluyeentremuchosotros:
AplicacionesparaControldesistemasyautomatizacinindustrial
Aplicacionesofimticas
Softwareeducativo
Softwareempresarial
Basesdedatos
Telecomunicaciones(porejemploInternetytodasuestructuralgica)
Videojuegos
Softwaremdico
Softwaredeclculonumricoysimblico.
Softwaredediseoasistido(CAD)
Softwaredecontrolnumrico(CAM)

Procesodecreacindelsoftware
Sedefinecomoprocesoalconjuntoordenadodepasosaseguirparallegaralasolucindeunproblemau
obtencin de un producto, en este caso particular, para lograr un producto software que resuelva un
problemaespecfico.
El proceso de creacin de software puede llegar a ser muy complejo, dependiendo de su porte,
caractersticas y criticidad del mismo. Por ejemplo la creacin de un sistema operativo es una tarea que
requiere proyecto, gestin, numerosos recursos y todo un equipo disciplinado de trabajo. En el otro
extremo,sisetratadeunsencilloprograma(porejemplo,laresolucindeunaecuacindesegundoorden),
stepuedeserrealizadoporunsoloprogramador(inclusoaficionado)fcilmente.Esasquenormalmente
sedividenentrescategorassegnsutamao(lneasdecdigo)ocosto:depequeo,medianoygran
porte.Existenvariasmetodologasparaestimarlo,unadelasmspopulareseselsistemaCOCOMOque
proveemtodosyunsoftware(programa)quecalculayproveeunaaproximacindetodosloscostosde
produccinenunproyectosoftware(relacinhoras/hombre,costomonetario,cantidaddelneasfuente
deacuerdoalenguajeusado,etc.).
Considerandolosdegranporte,esnecesariorealizarcomplejastareas,tantotcnicascomodegerencia,una
fuertegestinyanlisisdiversos(entreotrascosas),lacomplejidaddeellohallevadoaquedesarrolleuna
ingenieraespecficaparatratarsuestudioyrealizacin:esconocidacomoIngenieradeSoftware.
En tanto que en los de mediano porte, pequeos equipos de trabajo (incluso un avezado analista
programador solitario) pueden realizar la tarea.Aunque, siempre en casos de mediano y gran porte (y a
vecestambinenalgunosdepequeoporte,segnsucomplejidad),sedebenseguirciertasetapasqueson
necesariasparalaconstruccindelsoftware.Talesetapas,sibiendebenexistir,sonflexiblesensuformade
aplicacin, de acuerdo a la metodologa o proceso de desarrollo escogido y utilizado por el equipo de
desarrollooporelanalistaprogramadorsolitario(sifuereelcaso).
Los procesos de desarrollo de software poseen reglas preestablecidas, y deben ser aplicados en la
creacindelsoftwaredemedianoygranporte,yaqueencasocontrariolomsseguroesqueelproyectono
logreconcluiroterminesincumplirlosobjetivosprevistos,yconvariedaddefallosinaceptables(fracasan,
enpocaspalabras).Entretalesprocesosloshaygilesolivianos(ejemploXP),pesadosylentos(ejemplo
RUP),yvariantesintermedias.Normalmenteseaplicandeacuerdoaltipoyportedelsoftwareadesarrollar,
acriteriodellder(silohay)delequipodedesarrollo.AlgunosdeesosprocesossonProgramacinExtrema
(eninglseXtremeProgrammingoXP),ProcesoUnificadodeRational(eninglsRationalUnifiedProcess
oRUP),FeatureDrivenDevelopment(FDD),etc.
Cualquiera sea el proceso utilizado y aplicado al desarrollo del software (RUP, FDD, XP, etc), y casi
independientementedel,siempresedebeaplicarunmodelodeciclodevida.6
Seestimaque,deltotaldeproyectossoftwaregrandesemprendidos,un28%fracasan,un46%caenen
severasmodificacionesqueloretrasanyun26%sontotalmenteexitosos.7
Cuandounproyectofracasa,raravezesdebidoafallastcnicas,laprincipalcausadefallosyfracasosesla
falta de aplicacin de una buena metodologa o proceso de desarrollo. Entre otras, una fuerte tendencia,
desde hace pocas dcadas, es mejorar las metodologas o procesos de desarrollo, o crear nuevas y
concientizaralosprofesionalesdelainformticaasuutilizacinadecuada.Normalmentelosespecialistas
en el estudio y desarrollo de estas reas (metodologas) y afines (tales como modelos y hasta la gestin

misma de los proyectos) son los ingenieros en software, es su orientacin. Los especialistas en cualquier
otra rea de desarrollo informtico (analista, programador, Lic. en informtica, ingeniero en informtica,
ingeniero de sistemas, etc.) normalmente aplican sus conocimientos especializados pero utilizando
modelos,paradigmasyprocesosyaelaborados.
Escomnparaeldesarrollodesoftwaredemedianoportequelosequiposhumanosinvolucradosapliquen
metodologaspropias,normalmenteunhbridodelosprocesosanterioresyavecesconcriteriospropios.
Elprocesodedesarrollopuedeinvolucrarnumerosasyvariadastareas,6desdeloadministrativo,pasando
porlotcnicoyhastalagestinyelgerenciamiento.Pero,casirigurosamente,siempresecumplenciertas
etapasmnimaslasquesepuedenresumircomosigue:
Captura,elicitacin8,especificacinyanlisisderequisitos(ERS)
Diseo
Codificacin
Pruebas(unitariasydeintegracin)
Instalacinypasoaproduccin
Mantenimiento
Enlasanterioresetapaspuedenvariarligeramentesusnombres,osermsglobales,ocontrariamente,ser
ms refinadas por ejemplo indicar como una nica fase (a los fines documentales e interpretativos) de
anlisis y diseo o indicar como implementacin lo que est dicho como codificacin pero en
rigor,todasexisteneincluyen,bsicamente,lasmismastareasespecficas.
Enelapartado4delpresenteartculosebrindanmayoresdetallesdecadaunadelasetapasindicadas.

Modelosdeprocesoociclodevida
Paracadaunadelasfasesoetapaslistadaseneltemanterior,existensubetapas(otareas).Elmodelode
procesoomodelodeciclodevidautilizadoparaeldesarrollo,defineelordendelastareasoactividades
involucradas,6 tambin define la coordinacin entre ellas, y su enlace y realimentacin. Entre los ms
conocidos se puede mencionar: modelo en cascada o secuencial, modelo espiral, modelo iterativo
incremental.Delosantedichoshayasuvezalgunasvariantesoalternativas,msomenosatractivassegn
sealaaplicacinrequeridaysusrequisitos.7
Modelocascada
Este,aunqueesmscomnmenteconocidocomomodeloencascadaestambinllamadomodeloclsico,
modelotradicionalomodelolinealsecuencial.
El modelo en cascada puro difcilmente se utiliza tal cual, pues esto implicara un previo y absoluto
conocimientodelosrequisitos,lanovolatilidaddelosmismos(origidez)yetapassubsiguienteslibresde
erroreselloslopodraseraplicableaescasosypequeossistemasadesarrollar.Enestascircunstancias,el
pasodeunaetapaaotradelasmencionadasserasinretorno,porejemplopasardeldiseoalacodificacin
implicaraundiseoexactoysinerroresniprobablemodificacinoevolucin:codifiquelodiseadosin
errores,nohabrenabsolutovariantesfuturas.Estoesutpicoyaqueintrnsecamenteelsoftwareesde
carcterevolutivo,9cambianteydifcilmentelibredeerrores,tantodurantesudesarrollocomodurantesu
vidaoperativa.6

Algn cambio durante la ejecucin de una

cualquiera de las etapas en este modelo
secuencialimplicarareiniciardesdeelprincipio
todo el ciclo completo, lo cual redundara en
altoscostosdetiempoydesarrollo.LaFigura2
muestra un posible esquema de el modelo en
cuestin.6
Sin embargo, el modelo cascada en algunas de
sus variantes es uno de los actualmente ms
utilizados,10porsueficaciaysimplicidad,ms
quenadaensoftwaredepequeoyalgunosde
Figura2:Modelocascadapuroosecuencialparaelciclode
medianoporteperonunca(omuyraravez)se
vidadelsoftware.
lo usa en su "forma pura", como se dijo
anteriormente. En lugar de ello, siempre se
produce alguna realimentacin entre etapas, que no es completamente predecible ni rgida esto da
oportunidadaldesarrollodeproductossoftwareenloscualeshayciertasincertezas,cambiosoevoluciones
duranteelciclodevida.Asporejemplo,unavezcapturadosyespecificadoslosrequisitos(primeraetapa)
sepuedepasaraldiseodelsistema,peroduranteestaltimafaselomsprobableesquesedebanrealizar
ajustesenlosrequisitos(aunqueseanmnimos),yaseaporfallasdetectadas,ambigedadesobienporque
los propios requisitos han cambiado o evolucionado con lo cual se debe retornar a la primera o previa
etapa, hacer los reajuste pertinentes y luego continuar nuevamente con el diseo esto ltimo se conoce
como realimentacin. Lo normal en el modelo cascada ser entonces la aplicacin del mismo con sus
etapasrealimentadasdealgunaforma,permitiendoretrocederdeunaalaanterior(einclusopodersaltara
variasanteriores)siesrequerido.
Deestamaneraseobtieneelmodelocascadarealimentado,quepuedeseresquematizadocomoloilustra
laFigura3.
Lo dicho es, a grandes rasgos, la forma y
utilizacin de este modelo, uno de los ms
usados y populares.6 El modelo cascada
realimentadoresulta muy atractivo, hasta ideal,
si el proyecto presenta alta rigidez (pocos
cambios, previsto no evolutivo), los requisitos
son muy claros y estn correctamente
especificados.10
Hay ms variantes similares al modelo: refino
de etapas (ms etapas, menores y ms
especficas) o incluso mostrar menos etapas de
Figura3:Modelocascadarealimentadoparaelciclodevida.
las indicadas, aunque en tal caso la faltante
estar dentro de alguna otra. El orden de esas
fasesindicadaseneltemprevioesellgicoyadecuado,peroadvirtase,comosedijo,quenormalmente
habrrealimentacinhaciaatrs.

El modelo lineal o en cascada es el paradigma ms antiguo y extensamente utilizado, sin embargo las
crticasal(verdesventajas)hanpuestoendudasueficacia.Peseatodo,tieneunlugarmuyimportanteen
laIngenieradesoftwareycontinasiendoelmsutilizadoysiempreesmejorqueunenfoquealazar.10
Desventajasdelmodelocascada:6
Loscambiosintroducidosduranteeldesarrollopuedenconfundiralequipoprofesionalenlasetapas
tempranasdelproyecto.Siloscambiosseproducenenetapamadura(codificacinoprueba)pueden
sercatastrficosparaunproyectogrande.
Noesfrecuentequeelclienteousuariofinalexpliciteclaraycompletamentelosrequisitos(etapade
inicio)yelmodelolineallorequiere.Laincertidumbrenaturalenloscomienzosesluegodifcilde
acomodar.10
El cliente debe tener paciencia ya que el software no estar disponible hasta muy avanzado el
proyecto.Unerrordetectadoporelcliente(enfasedeoperacin)puedeserdesastroso,implicando
reiniciodelproyecto,conaltoscostos.
Modelosevolutivos
El software evoluciona con el tiempo.11 9 Los requisitos del usuario y del producto suelen cambiar
conformesedesarrollaelmismo.Lasfechasdemercadoylacompetenciahacenquenoseaposibleesperar
a poner en el mercado un producto absolutamente completo, por lo que se aconsejable introducir una
versinfuncionallimitadadealgunaformaparaaliviarlaspresionescompetitivas.
Enesasuotrassituacionessimilareslosdesarrolladoresnecesitanmodelosdeprogresoqueestndiseados
para acomodarse a una evolucin temporal o progresiva, donde los requisitos centrales son conocidos de
antemano,aunquenoestnbiendefinidosaniveldetalle.
Enelmodelocascadaycascadarealimentadonosetienedemasiadoencuentalanaturalezaevolutivadel
software,11seplanteacomoesttico,conrequisitosbienconocidosydefinidosdesdeelinicio.6
Losevolutivossonmodelositerativos,permitendesarrollarversionescadavezmscompletasycomplejas,
hastallegaralobjetivofinaldeseadoinclusoevolucionarmsall,durantelafasedeoperacin.
Losmodelositerativoincrementalyespiral(entreotros)sondosdelosmsconocidosyutilizadosdel
tipoevolutivo.10
Modeloiterativoincremental

En trminos generales, se puede distinguir, en la Figura 4, los pasos generales que sigue el proceso de
desarrollodeunproductosoftware.Enelmodelodeciclodevidaseleccionado,seidentificanclaramente
dichos pasos. La descripcin del sistema es esencial para especificar y confeccionar los distintos
incrementoshastallegaralproductoglobalyfinal.Lasactividadesconcurrentes(especificacin,desarrollo
yvalidacin)sintetizaneldesarrollopormenorizadodelosincrementos,queseharposteriormente.
El diagrama de la Figura 4 muestra en forma muy esquemtica, el funcionamiento de un ciclo iterativo
incremental,elcualpermitelaentregadeversionesparcialesamedidaquesevaconstruyendoelproducto
final.6 Es decir, a medida que cada incremento definido llega a su etapa de operacin y mantenimiento.
Cada versin emitida incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron
analizadoscomonecesarios.

El incremental es un modelo de tipo evolutivo

que est basado en varios ciclos Cascada
Realimentados aplicados repetidamente, con
una filosofa iterativa.10 En la Figura 5 se
muestraunrefinodeldiagramaprevio,bajoun
esquema temporal, para obtener finalmente el
esquema del modelo de ciclo de vida Iterativo
Incremental, con sus actividades genricas
asociadas. Aqu se observa claramente cada
ciclocascadaqueesaplicadoparalaobtencin
de un incremento estos ltimos se van
integrando para obtener el producto final
completo.CadaincrementoesuncicloCascada
Realimentado, aunque, por simplicidad, en la
Figura5semuestracomosecuencialpuro.

Figura4:Diagramagenricodeldesarrolloevolutivo
incremental.

Se observa que
existenactividadesde
desarrollo (para cada
incremento) que son
realizadasenparalelo
o concurrentemente,
asporejemplo,enla
Figura, mientras se
realiza el diseo
detalle del primer
incrementoyaseest
realizandoenanlisis
del segundo. La
Figura 5 es slo
esquemtica,
un
Figura5:Modeloiterativoincrementalparaelciclodevidadelsoftware.
incremento
no
necesariamente se
iniciar durante la
fasedediseodelanterior,puedeserposterior(inclusoantes),encualquiertiempodelaetapaprevia.Cada
incrementoconcluyeconlaactividaddeoperacinymantenimiento(indicadacomoOperacinenla
figura),queesdondeseproducelaentregadelproductoparcialalcliente.Elmomentodeiniciodecada
incremento es dependiente de varios factores: tipo de sistema independencia o dependencia entre
incrementos(dosdeellostotalmenteindependientespuedenserfcilmenteiniciadosalmismotiemposise
disponedepersonalsuficiente)capacidadycantidaddeprofesionalesinvolucradoseneldesarrolloetc.
Bajoestemodeloseentregasoftwareporpartesfuncionalesmspequeas,peroreutilizables,llamadas
incrementos.Engeneralcadaincrementoseconstruyesobreaquelqueyafueentregado.6
ComosemuestraenlaFigura5,seaplicansecuenciasCascadaenformaescalonada,mientrasprogresael
tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y a menudo el primer
incrementoesunsistemabsico,conmuchasfuncionessuplementarias(conocidasono)sinentregar.

El cliente utiliza inicialmente ese sistema bsico, intertanto, el resultado de su uso y evaluacin puede
aportaralplanparaeldesarrollodel/lossiguientesincrementos(oversiones).Ademstambinaportana
ese plan otros factores, como lo es la priorizacin (mayor o menor urgencia en la necesidad de cada
incrementoenparticular)yladependenciaentreincrementos(oindependencia).
Luego de cada integracin se entrega un producto con mayor funcionalidad que el previo. El proceso se
repitehastaalcanzarelsoftwarefinalcompleto.
Siendo iterativo, con el modelo incremental se entrega un producto parcial pero completamente
operacionalencadaincremento,ynounapartequeseausadaparareajustarlosrequisitos(comosiocurre
enelmodelodeconstruccindeprototipos).10
Elenfoqueincrementalresultamuytilcuandosedisponedebajadotacindepersonalparaeldesarrollo
tambinsinohaydisponiblefechalmitedelproyectoporloqueseentreganversionesincompletaspero
queproporcionanalusuariofuncionalidadbsica(ycadavezmayor).Tambinesunmodelotilalosfines
deversionesdeevaluacin.
Nota: Puede ser considerado y til, en cualquier momento o incremento incorporar temporalmente el
paradigma MCP como complemento, teniendo as una mixtura de modelos que mejoran el esquema y
desarrollogeneral.
Ejemplo:
Un procesador de texto que sea desarrollado bajo el paradigma Incremental podra aportar, en
principio,funcionesbsicasdeedicindearchivosyproduccindedocumentos(algocomouneditor
simple).Enunsegundoincrementoselepodraagregaredicinmssofisticada,ydegeneraciny
mezcla de documentos. En un tercer incremento podra considerarse el agregado de funciones de
correccinortogrfica,esquemasdepaginadoyplantillasenuncuartocapacidadesdedibujopropias
y ecuaciones matemticas. As sucesivamente hasta llegar al procesador final requerido. As, el
productovacreciendo,acercndoseasumetafinal,perodesdelaentregadelprimerincrementoyaes
tilyfuncionalparaelcliente,elcualobservaunarespuestarpidaencuantoaentregatempranasin
notar que la fecha lmite del proyecto puede no estar acotada ni tan definida, lo que da margen de
operacinyaliviapresionesalequipodedesarrollo.
Como se dijo, el Iterativo Incremental es un modelo del tipo evolutivo, es decir donde se permiten y
esperanprobablescambiosenlosrequisitosentiempodedesarrolloseadmiteciertomargenparaqueel
software pueda evolucionar.9Aplicable cuando los requisitos son medianamente bien conocidos pero no
soncompletamenteestticosydefinidos,cuestinesaquesiesindispensableparapoderutilizarunmodelo
Cascada.
Elmodeloesaconsejableparaeldesarrollodesoftwareenelcualseobserve,ensuetapainicialdeanlisis,
queposeereasbastantebiendefinidasacubrir,consuficienteindependenciacomoparaserdesarrolladas
enetapassucesivas.Talesreasacubrirsuelentenerdistintosgradosdeapremioporlocuallasmismasse
debenpriorizarenunanlisisprevio,esdecir,definircualserlaprimera,lasegunda,yassucesivamente
esto se conoce como definicin de los incrementos con base en la priorizacin. Pueden no existir
prioridadesfuncionalesporpartedelcliente,peroeldesarrolladordebefijarlasdetodosmodosyconalgn
criterio,yaquebasndoseenellassedesarrollarnyentregarnlosdistintosincrementos.
Elhechodequeexistanincrementosfuncionalesdelsoftwarellevainmediatamenteapensarenunesquema
dedesarrollomodular,portantoestemodelofacilitatalparadigmadediseo.

En resumen, un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del
producto software denominados incrementos del sistema, que son escogidos segn prioridades
predefinidas de algn modo. El modelo permite una implementacin con refinamientos sucesivos
(ampliacinomejora).Concadaincrementoseagreganuevafuncionalidadosecubrennuevosrequisitoso
biensemejoralaversinpreviamenteimplementadadelproductosoftware.
Estemodelobrindaciertaflexibilidadparaqueduranteeldesarrolloseincluyancambiosenlosrequisitos
por parte del usuario, un cambio de requisitos propuesto y aprobado puede analizarse e implementarse
comounnuevoincrementoo,eventualmente,podrconstituirunamejora/adecuacindeunoyaplaneado.
Aunque si se produce un cambio de requisitos por parte del cliente que afecte incrementos previos ya
terminados (deteccin/incorporacin tarda) se debe evaluar la factibilidad y realizar un acuerdo con el
cliente,yaquepuedeimpactarfuertementeenloscostos.
La seleccin de este modelo permite realizar entregas funcionales tempranas al cliente (lo cual es
beneficiosotantoparalcomoparaelgrupodedesarrollo).Sepriorizanlasentregasdeaquellosmduloso
incrementosenquesurjalanecesidadoperativadehacerlo,porejemploparacargaspreviasdeinformacin,
indispensableparalosincrementossiguientes.10
Elmodeloiterativoincrementalnoobligaaespecificarconprecisinydetalleabsolutamentetodoloqueel
sistema debe hacer, (y cmo), antes de ser construido (como el caso del cascada, con requisitos
congelados).Slosehaceenelincrementoendesarrollo.Estotornamsmanejableelprocesoyreduceel
impactoenloscostos.Estoesas,porqueencasodealterarorehacerlosrequisitos,soloafectaunaparte
delsistema.Aunque,lgicamente,estasituacinseagravasisepresentaenestadoavanzado,esdecirenlos
ltimos incrementos. En definitiva, el modelo facilita la incorporacin de nuevos requisitos durante el
desarrollo.
Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa
funcionalidadparcial.Tambinproveeunimpactoventajosofrentealcliente,queeslaentregatempranade
partesoperativasdelsoftware.
Elmodeloproporcionatodaslasventajasdelmodeloencascadarealimentado,reduciendosusdesventajas
sloalmbitodecadaincremento.
El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de
seguridad,deprocesamientodistribuido,odealtondicederiesgos.
Modeloespiral

El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que conjuga la
naturaleza iterativa del modelo MCP con los aspectos controlados y sistemticos del Modelo Cascada.
Proporcionapotencialparadesarrollorpidodeversionesincrementales.EnelmodeloEspiralelsoftware
se construye en una serie de versiones incrementales. En las primeras iteraciones la versin incremental
podraserunmodeloenpapelobienunprototipo.Enlasltimasiteracionesseproducenversionescada
vezmscompletasdelsistemadiseado.610
ElmodelosedivideenunnmerodeActividadesdemarcodetrabajo,llamadasregionesdetareas.En
generalexistenentretresyseisregionesdetareas(hayvariantesdelmodelo).EnlaFigura6semuestrael
esquemadeunModeloEspiralcon6regiones.Enestecasoseexplicaunavariantedelmodelooriginalde

Boehm,expuestoensutratadode1988en1998expusountratadomsreciente.
Lasregionesdefinidasenelmodelodelafigura
son:
Regin 1 Tareas requeridas para
establecer la comunicacin entre el
clienteyeldesarrollador.
Regin 2 Tareas inherentes a la
definicin de los recursos, tiempo y otra
informacinrelacionadaconelproyecto.
Regin3Tareasnecesariasparaevaluar
los riesgos tcnicos y de gestin del
proyecto.
Regin 4 Tareas para construir una o
ms representaciones de la aplicacin
software.
Regin 5 Tareas para construir la
aplicacin, instalarla, probarla y
proporcionar soporte al usuario o cliente
(Ej.documentacinyprctica).
Regin6Tareasparaobtenerlareaccin
del cliente, segn la evaluacin de lo
creadoeinstaladoenlosciclosanteriores.

Figura6:Modeloespiralparaelciclodevidadelsoftware.

Lasactividadesenunciadasparaelmarcodetrabajosongeneralesyseaplicanacualquierproyecto,grande,
medianoopequeo,complejoono.Lasregionesquedefinenesasactividadescomprendenunconjuntode
tareas del trabajo: ese conjunto s se debe adaptar a las caractersticas del proyecto en particular a
emprender. Ntese que lo listado en los tems de 1 a 6 son conjuntos de tareas, algunas de las ellas
normalmentedependendelproyectoodesarrolloensi.
Proyectos pequeos requieren baja cantidad de tareas y tambin de formalidad. En proyectos mayores o
crticoscadaregindetareascontienelaboresdemsaltoniveldeformalidad.Encualquiercasoseaplican
actividadesdeproteccin(porejemplo,gestindeconfiguracindelsoftware,garantadecalidad,etc.).
Aliniciodelciclo,oprocesoevolutivo,elequipodeingenieragiraalrededordelespiral(metafricamente
hablando) comenzando por el centro (marcado con en la Figura 6) y en el sentido indicado el primer
circuitodelaespiralpuedeproducireldesarrollodeunaespecificacindelproductolospasossiguientes
podrangenerarunprototipoyprogresivamenteversionesmssofisticadasdelsoftware.
Cadapasoporlaregindeplanificacinprovocaajustesenelplandelproyectoelcosteyplanificacinse
realimentan en funcin de la evaluacin del cliente. El gestor de proyectos debe ajustar el nmero de
iteracionesrequeridasparacompletareldesarrollo.
ElmodeloespiralpuedeiradaptndoseyaplicarsealolargodetodoelCiclodevidadelsoftware(enel
modeloclsico,ocascada,elprocesoterminaalaentregadelsoftware).
Unavisinalternativadelmodelopuedeobservarseexaminandoelejedepuntodeentradadeproyectos.
Cada uno de los circulitos () fijados a lo largo del eje representan puntos de arranque de los distintos
proyectos(relacionados)asaber:

Unproyectodedesarrollodeconceptoscomienzaaliniciodelaespiral,hacemltiplesiteraciones
hastaquesecompleta,eslazonamarcadaconverde.
Siloanteriorsevaadesarrollarcomoproductoreal,seiniciaotroproyecto:Desarrollodenuevo
Producto.Queevolucionarconiteracioneshastaculminareslazonamarcadaencolorazul.
Eventualyanlogamentesegenerarnproyectosdemejorasdeproductosydemantenimientode
productos,conlasiteracionesnecesariasencadarea(zonasrojaygris,respectivamente).
Cuando la espiral se caracteriza de esta forma, est operativa hasta que el software se retira,
eventualmente puede estar inactiva (el proceso), pero cuando se produce un cambio el proceso arranca
nuevamenteenelpuntodeentradaapropiado(porejemplo,enmejoradelproducto).
Elmodeloespiraldaunenfoquerealista,queevolucionaigualqueelsoftware11seadaptamuybienpara
desarrollosagranescala.
El Espiral utiliza el MCP para reducir riesgos y permite aplicarlo en cualquier etapa de la evolucin.
Mantiene el enfoque clsico (cascada) pero incorpora un marco de trabajo iterativo que refleja mejor la
realidad.
Estemodelorequiereconsiderarriesgostcnicosentodaslasetapasdelproyectoaplicadoadecuadamente
debereducirlosantesdequeseanunverdaderoproblema.
El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de Sistemas Operativos
(complejos)tambinensistemasdealtosriesgosocrticos(Ej.navegadoresycontroladoresaeronuticos)
yentodosaquellosenqueseanecesariaunafuertegestindelproyectoysusriesgos,tcnicosodegestin.
Desventajasimportantes:
Requieremuchaexperienciayhabilidadparalaevaluacindelosriesgos,locualesrequisitoparael
xitodelproyecto.
Esdifcilconvenceralosgrandesclientesquesepodrcontrolaresteenfoqueevolutivo.
Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por lo que no se tiene bien
medidasueficacia,esunparadigmarelativamentenuevoydifcildeimplementarycontrolar.
ModeloespiralWin&Win

UnavarianteinteresantedelModeloEspiralpreviamentevisto(Figura6)eselModeloespiralWinWin7
(Barry Boehm). El Modelo Espiral previo (clsico) sugiere la comunicacin con el cliente para fijar los
requisitos, en que simplemente se pregunta al cliente qu necesita y l proporciona la informacin para
continuarperoestoesenuncontextoidealqueraravezocurre.Normalmenteclienteydesarrolladorentran
enunanegociacin,senegociacostefrenteafuncionalidad,rendimiento,calidad,etc.
Es as que la obtencin de requisitos requiere una negociacin, que tiene xito cuando ambas partes
ganan.
LasmejoresnegociacionessefuerzanenobtenerVictoria&Victoria(Win&Win),esdecirqueelcliente
ganeobteniendoelproductoquelosatisfaga,yeldesarrolladortambinganeconsiguiendopresupuestoy
fechadeentregarealista.Evidentemente,estemodelorequierefuerteshabilidadesdenegociacin.

ElmodeloWinWindefineunconjuntodeactividadesdenegociacinalprincipiodecadapasoalrededor
delaespiralsedefinenlassiguientesactividades:
1.Identificacindelsistemaosubsistemasclavedelosdirectivos(*)(saberququieren).
2.Determinacindecondicionesdevictoriadelosdirectivos(saberqunecesitanylossatisface)
3.Negociacin de las condiciones victoria de los directivos para obtener condiciones Victoria &
Victoria(negociarparaqueambosganen).
(*) Directivo: Cliente escogido con inters directo en el producto, que puede ser premiado por la
organizacinsitienexitoocriticadosino.
El modelo Win & Win hace nfasis en la negociacin inicial, tambin introduce 3 hitos en el proceso
llamados puntos de fijacin, que ayudan a establecer la completitud de un ciclo de la espiral, y
proporcionanhitosdedecisinantesdecontinuarelproyectodedesarrollodelsoftware.

Etapaseneldesarrollodelsoftware
Captura,anlisisyespecificacinderequisitos
Aliniciodeundesarrollo(nodeunproyecto),estaeslaprimerafasequeserealiza,y,segnelmodelode
proceso adoptado, puede casi terminar para pasar a la prxima etapa (caso de Modelo Cascada
Realimentado) o puede hacerse parcialmente para luego retomarla (caso Modelo Iterativo Incremental u
otrosdecarcterevolutivo).
Ensimplepalabrasybsicamente,duranteestafase,seadquieren,renenyespecificanlascaractersticas
funcionalesynofuncionalesquedebercumplirelfuturoprogramaosistemaadesarrollar.
Las bondades de las caractersticas, tanto del sistema o programa a desarrollar, como de su entorno,
parmetros no funcionales y arquitectura dependen enormemente de lo bien lograda que est esta etapa.
Esta es, probablemente, la de mayor importancia y una de las fases ms difciles de lograr certeramente,
puesnoesautomatizable,noesmuytcnicaydependeengranmedidadelahabilidadyexperienciadel
analistaquelarealice.
Involucrafuertementealusuariooclientedelsistema,portantotienematicesmuysubjetivosyesdifcilde
modelarconcertezaoaplicarunatcnicaquesealamscercanaalaadecuada(dehechonoexistela
estrictamente adecuada). Si bien se han ideado varias metodologas, incluso software de apoyo, para
captura, elicitacin y registro de requisitos, no existe una forma infalible o absolutamente confiable, y
deben aplicarse conjuntamente buenos criterios y mucho sentido comn por parte del o los analistas
encargadosdelatareaesfundamentaltambinlograrunafluidayadecuadacomunicacinycomprensin
conelusuariofinaloclientedelsistema.
El artefacto ms importante resultado de la culminacin de esta etapa es lo que se conoce como
especificacinderequisitossoftwareosimplementedocumentoERS.
Comosedijo,lahabilidaddelanalistaparainteractuarconelclienteesfundamentallocomnesqueel
clientetengaunobjetivogeneraloproblemaqueresolver,noconoceenabsolutoelrea(informtica),nisu
jerga,nisiquierasabeconprecisinqudeberahacerelproductosoftware(quycuantasfunciones)ni,
mucho menos, cmo debe operar. En otros casos menos frecuentes, el cliente piensa que sabe
precisamente lo que el software tiene que hacer, y generalmente acierta muy parcialmente, pero su

empecinamiento entorpece la tarea de elicitacin. El analista debe tener la capacidad para lidiar con este
tipo de problemas, que incluyen relaciones humanas tiene que saber ponerse al nivel del usuario para
permitirunaadecuadacomunicacinycomprensin.
Escasassonlassituacionesenqueelclientesabeconcertezaeinclusoconcompletitudloquerequierede
sufuturosistema,esteeselcasomssencilloparaelanalista.
Las tareas relativas a captura, elicitacin, modelado y registro de requisitos, adems de ser sumamente
importante, puede llegar a ser dificultosa de lograr acertadamente y llevar bastante tiempo relativo al
proceso total del desarrollo al proceso y metodologas para llevar a cabo este conjunto de actividades
normalmenteselasasumepartepropiadelaIngenieradeSoftware,perodadalaantedichacomplejidad,
actualmentesehabladeunaIngenieraderequisitos12,aunqueellaannoexisteformalmente.
Hay grupos de estudio e investigacin, en todo el mundo, que estn exclusivamente abocados a idear
modelos,tcnicasyprocesosparaintentarlograrlacorrectacaptura,anlisisyregistroderequisitos.Estos
grupossonlosquenormalmentehablandelaIngenieraderequisitosesdecirseplanteastacomounrea
odisciplinaperonocomounacarrerauniversitariaensimisma.
Algunosrequisitosnonecesitanlapresenciadelcliente,parasercapturadosoanalizadosenciertoscasos
los puede proponer el mismo analista o, incluso, adoptar unilateralmente decisiones que considera
adecuadas (tanto en requisitos funcionales como no funcionales). Por citar ejemplos probables:Algunos
requisitos sobre la arquitectura del sistema, requisitos no funcionales tales como los relativos al
rendimiento, nivel de soporte a errores operativos, plataformas de desarrollo, relaciones internas o ligas
entrelainformacin(entreregistrosotablasdedatos)aalmacenarencasodebasesobancosdedatos,etc.
Algunosfuncionalestalescomoopcionessecundariasodesoportenecesariasparaunamejoromssencilla
operatividadetc.
Laobtencindeespecificacionesapartirdelcliente(uotrosactoresintervinientes)esunprocesohumano
muyinteractivoeiterativonormalmenteamedidaquesecapturalainformacin,selaanalizayrealimenta
con el cliente, refinndola, pulindola y corrigiendo si es necesario cualquiera sea el mtodo de ERS
utilizado. EL analista siempre debe llegar a conocer la temtica y el problema que resolver, dominarlo,
hastaciertopunto,hastaelmbitoqueelfuturosistemaadesarrollarloabarque.Porelloelanalistadebe
teneraltacapacidadparacomprenderproblemasdemuydiversasreasodisciplinasdetrabajo(quenoson
especficamentesuyas)asporejemplo,sielsistemaadesarrollarserparagestionarinformacindeuna
aseguradora y sus sucursales remotas, el analista se debe compenetrar en cmo ella trabaja y maneja su
informacin,desdenivelesmuybajoseinclusollegandohastalosgerenciales.Dadaagrandiversidadde
campos a cubrir, los analistas suelen ser asistidos por especialistas, es decir gente que conoce
profundamenteelreaparalacualsedesarrollarelsoftwareevidentementeunanicapersona(elanalista)
no puede abarcar tan vasta cantidad de reas del conocimiento. En empresas grandes de desarrollo de
productossoftware,escomnteneranalistasespecializadosenciertasreasdetrabajo.
Contrariamente, no es problema del cliente, es decir l no tiene por qu saber nada de software, ni de
diseos,niotrascosasrelacionadasslosedebelimitaraaportarobjetivos,datoseinformacin(demano
propia o de sus registros, equipos, empleados, etc) al analista, y guiado por l, para que, en primera
instancia, defina el Universo de Discurso, y con posterior trabajo logre confeccionar el adecuado
documentoERS.

Es bien conocida la presin que sufren los desarrolladores de sistemas informticos para comprender y
rescatar las necesidades de los clientes/usuarios. Cuanto ms complejo es el contexto del problema ms
difcil es lograrlo, a veces se fuerza a los desarrolladores a tener que convertirse en casi expertos de los
dominiosqueanalizan.
Cuandoestonosucedeesmuyprobablequesegenereunconjuntoderequisitos13errneosoincompletosy
porlotantounproductodesoftwareconaltogradodedesaprobacinporpartedelosclientes/usuariosyun
altsimocostodereingenieraymantenimiento.Todoaquelloquenosedetecte,oresultemalentendidoen
la etapa inicial provocar un fuerte impacto negativo en los requisitos, propagando esta corriente
degradantealolargodetodoelprocesodedesarrolloeincrementandosuperjuiciocuantomstarda
seasudeteccin(BellyThayer1976)(Davis1993).
Procesos,modeladoyformasdeelicitacinderequisitos

Siendo que la captura, elicitacin y especificacin de requisitos, es una parte crucial en el proceso de
desarrollo de software, ya que de esta etapa depende el logro de los objetivos finales previstos, se han
ideadomodelosydiversasmetodologasdetrabajoparaestosfines.Tambinexistenherramientassoftware
queapoyanlastareasrelativasrealizadasporelingenieroenrequisitos.
El estndar IEEE 8301998 brinda una normalizacin de las Prcticas Recomendadas para la
EspecificacindeRequisitosSoftware.14
A medida que se obtienen los requisitos, normalmente se los va analizando, el resultado de este anlisis,
con o sin el cliente, se plasma en un documento, conocido como ERS o Especificacin de Requisitos
Software,cuyaestructurapuedevenirdefinidaporvariosestndares,talescomoCMMI.
Un primer paso para realizar el relevamiento de informacin es el conocimiento y definicin acertada lo
queseconocecomoUniversodeDiscursodelproblema,quesedefineyentiendepor:
Universo de Discurso (UdeD): es el contexto general en el cual el software deber ser desarrollado y
deberoperar.ElUdeDincluyetodaslasfuentesdeinformacinytodaslaspersonasrelacionadasconel
software. Esas personas son conocidas tambin como actores de ese universo. El UdeD es la realidad
circunstanciadaporelconjuntodeobjetivosdefinidosporquienesdemandaronelsoftware.
A partir de la extraccin y anlisis de informacin en su mbito se obtienen todas las especificaciones
necesariasytiposderequisitosparaelfuturoproductosoftware.
El objetivo de la Ingeniera de requisitos (IR) es sistematizar el proceso de definicin de requisitos
permitiendo elicitar, modelar y analizar el problema, generando un compromiso entre los ingenieros de
requisitosylosclientes/usuarios,yaqueambosparticipanenlageneracinydefinicindelosrequisitosdel
sistema. La IR aporta un conjunto de mtodos, tcnicas y herramientas que asisten a los ingenieros de
requisitos (analistas) para obtener requisitos lo ms seguros, veraces, completos y oportunos posibles,
permitiendobsicamente:
Comprenderelproblema
Facilitarlaobtencindelasnecesidadesdelcliente/usuario
Validarconelcliente/usuario
Garantizarlasespecificacionesderequisitos

Sibienexistendiversasformas,modelosymetodologasparaelicitar,definirydocumentarrequisitos,nose
puededecirquealgunadeellasseamejoropeorquelaotra,suelentenermuchsimoencomn,ytodas
cumplenelmismoobjetivo.Sinembargo,loquesisepuededecirsindudasesqueesindispensableutilizar
algunadeellasparadocumentarlasespecificacionesdelfuturoproductosoftware.Asporejemplo,hayun
grupodeinvestigacinargentinoquedesdehacevariosaoshapropuestoyestudiaelusodelLEL(Lxico
ExtendidodelLenguaje)yEscenarioscomometodologa,aqu15sepresentaunadelastantasreferenciasy
bibliografasobreello.Otraforma,msortodoxa,decapturarydocumentarrequisitossepuedeobteneren
detalle, por ejemplo, en el trabajo de la Universidad de Sevilla sobre Metodologa para elAnlisis de
RequisitosdeSistemasSoftware.16
EnlaFigura7semuestraunesquema,msomenosriguroso,aunquenodetallado,delospasosytareasa
seguirpararealizarlacaptura,anlisisyespecificacinderequisitossoftware.Tambinallseobservaqu
artefactoodocumentoseobtieneencadaetapadelproceso.Eneldiagramanoseexplicitametodologao
modeloautilizar,sencillamentesepautanlastareasquedebencumplirse,dealgunamanera.
Una
posible
lista,
general y ordenada, de
tareas
recomendadas
para
obtener
la
definicin de lo que se
debe
realizar,
los
productosaobtenerylas
tcnicas a emplear
durante la actividad de
elicitacin de requisitos,
en
fase
de
Especificacin
de
RequisitosSoftwarees:
1.Obtener
informacin sobre
Figura7:Diagramadetareasparacapturayanlisisderequisitos.
el dominio del
problema y el
sistema
actual
(UdeD).
2.Prepararyrealizarlasreunionesparaelicitacin/negociacin.
3.Identificar/revisarlosobjetivosdelusuario.
4.Identificar/revisarlosobjetivosdelsistema.
5.Identificar/revisarlosrequisitosdeinformacin.
6.Identificar/revisarlosrequisitosfuncionales.
7.Identificar/revisarlosrequisitosnofuncionales.
8.Priorizarobjetivosyrequisitos.
Algunosprincipiosbsicosatenerencuenta:
Presentaryentendercabalmenteeldominiodelainformacindelproblema.
DefinircorrectamentelasfuncionesquedeberealizarelSoftware.
Representar el comportamiento del software a consecuencias de acontecimientos externos,
particulares,inclusoinesperados.

Reconocerrequisitosincompletos,ambiguosocontradictorios.
Dividir claramente los modelos que representan la informacin, las funciones y comportamiento y
caractersticasnofuncionales.
Clasificacineidentificacinderequisitos

Sepuedenidentificardosformasderequisitos:
Requisitosdeusuario:Losrequisitosdeusuariosonfrasesenlenguajenaturaljuntoadiagramascon
losserviciosqueelsistemadebeproporcionar,ascomolasrestriccionesbajolasquedebeoperar.
Requisitosdesistema:Losrequisitosdesistemadeterminanlosserviciosdelsistemayperoconlas
restriccionesendetalle.Sirvencomocontrato.
Esdecir,ambossonlomismo,perocondistintoniveldedetalle.
Ejemploderequisitodeusuario:ElsistemadebehacerprstamosEjemploderequisitodesistema:Funcin
prstamo:entradacdigosocio,cdigoejemplarsalida:fechadevolucinetc.
Seclasificanentreslostiposderequisitosdesistema:
Requisitosfuncionales
Losrequisitosfuncionalesdescriben:
Losserviciosqueproporcionaelsistema(funciones).
Larespuestadelsistemaantedeterminadasentradas.
Elcomportamientodelsistemaensituacionesparticulares.
Requisitosnofuncionales
Losrequisitosnofuncionalessonrestriccionesdelosserviciosofuncionesqueofreceelsistema(ej.cotas
detiempo,procesodedesarrollo,rendimiento,etc.)
Ejemplo 1. La biblioteca Central debe ser capaz de atender simultneamente a todas las
bibliotecasdelaUniversidad
Ejemplo2.Eltiempoderespuestaaunaconsultaremotanodebesersuperiora1/2s
Asuvez,haytrestiposderequisitosnofuncionales:
Requisitosdelproducto.Especificanelcomportamientodelproducto(Ej.prestaciones,memoria,tasa
defallos,etc.)
Requisitos organizativos. Se derivan de las polticas y procedimientos de las organizaciones de los
clientesydesarrolladores(Ej.estndaresdeproceso,lenguajesdeprogramacin,etc.)
Requisitos externos. Se derivan de factores externos al sistema y al proceso de desarrollo (Ej.
requisitoslegislativos,ticos,etc.)
Requisitosdeldominio.
Los requisitos del dominio se derivan del dominio de la aplicacin y reflejan caractersticas de dicho
dominio.

Puedenserfuncionalesonofuncionales.
Ej. El sistema de biblioteca de la Universidad debe ser capaz de exportar datos mediante el Lenguaje de
Intercomunicacin de Bibliotecas de Espaa (LIBE). Ej. El sistema de biblioteca no podr acceder a
bibliotecasconmaterialcensurado.
Diseodelsistema
Eningenieradesoftware,eldiseoesunafasedeciclodevidadelsoftware.Sebasaenlaespecificacin
de requisitos producido por el anlisis de los requisitos (fase de anlisis), el diseo define cmo estos
requisitossecumplirn,laestructuraquedebedarsealsistemadesoftwareparaquesehagarealidad.
Eldiseosiguesiendounafaseseparadadellaprogramacinocodificacin,estaltimacorrespondeala
traduccinenundeterminadolenguajedeprogramacindelaspremisasadoptadaseneldiseo.
Lasdistincionesentrelasactividadesmencionadashastaahoranosiempresonclarascmosequisieraen
las teoras clsicas de ingeniera de software. El diseo, en particular, puede describir el funcionamiento
interno de un sistema en diferentes niveles de detalle, cada una de ellos se coloca en una posicin
intermediaentreelanlisisycodificacin.
Normalmenteseentiendepor"diseodelaarquitectura"aldiseode"muyaltonivel",queslodefinela
estructura del sistema en trminos de la mdulos de software de que se compone y las relaciones
macroscpicas entre ellos. A este nivel de diseo pertenecen frmulas como clienteservidor o tres
niveles, o, ms generalmente, las decisiones sobre el uso de la arquitectura de hardware especial que se
utilice,elsistemaoperativo,DBMS,Protocolosdered,etc.
Unnivelintermediodedetallepuededefinirladescomposicindelsistemaenmdulos,peroestavezcon
una referencia ms o menos explcita al modo de descomposicin que ofrece el particular lenguaje de
programacin con el que el desarrollo se va a implementar, por ejemplo, en un diseo realizado con la
tecnologadeobjetos,elproyectopodradescribiralsistemaentrminosdeclasesysusinterrelaciones.
Eldiseodetallado,porltimo,esunadescripcindelsistemamuycercanaalacodificacin(porejemplo,
describirnoslolasclasesenabstracto,sinotambinsusatributosylosmtodosconsustipos).
Debidoalanaturaleza"intangible"delsoftware,ydependiendodelasherramientasqueseutilizanenel
proceso, la frontera entre el diseo y la codificacin tambin puede ser virtualmente imposible de
identificar.Porejemplo,algunasherramientasCASEsoncapacesdegenerarcdigoapartirdediagramas
UML,losquedescribengrficamentelaestructuradeunsistemasoftware.
Codificacindelsoftware
Durante esta etapa se realizan las tareas que comnmente se conocen como programacin que consiste,
esencialmente, en llevar a cdigo fuente, en el lenguaje de programacin elegido, todo lo diseado en la
faseanterior.Estatarealarealizaelprogramador,siguiendoporcompletoloslineamientosimpuestosenel
diseoyenconsideracinsiemprealosrequisitosfuncionalesynofuncionales(ERS)especificadosenla
primeraetapa.

Escomnpensarquelaetapadeprogramacinocodificacin(algunoslallamanimplementacin)eslaque
insume la mayor parte del trabajo de desarrollo del software sin embargo, esto puede ser relativo (y
generalmente aplicable a sistemas de pequeo porte) ya que las etapas previas son cruciales, crticas y
puedenllevarbastantemstiempo.Sesuelehacerestimacionesdeun30%deltiempototalinsumidoenla
programacin, pero esta cifra no es consistente ya que depende en gran medida de las caractersticas del
sistema,sucriticidadyellenguajedeprogramacinelegido.7Entantomenoreselniveldellenguajemayor
sereltiempodeprogramacinrequerido,asporejemplosetardaramstiempoencodificarunalgoritmo
enlenguajeensambladorqueelmismoprogramadoenlenguajeC.
Mientras se programa la aplicacin, sistema, o software en general, se realizan tambin tareas de
depuracin,estoeslalabordeirliberandoalcdigodeloserroresfactiblesdeserhalladosenestafase(de
semntica,sintcticaylgica).Hayunasuertedesolapamientoconlafasesiguiente,yaqueparadepurarla
lgicaesnecesariorealizarpruebasunitarias,normalmentecondatosdepruebaclaroesquenotodoslos
errores sern encontrados slo en la etapa de programacin, habrn otros que se encontrarn durante las
etapassubsiguientes.Laaparicindealgnerrorfuncional(malarespuestaalosrequisitos)eventualmente
puedellevararetornaralafasedediseoantesdecontinuarlacodificacin.
Durante la fase de programacin, el cdigo puede adoptar varios estados, dependiendo de la forma de
trabajoydellenguajeelegido,asaber:
Cdigofuente:eselescritodirectamenteporlosprogramadoreseneditoresdetexto,locualgenerael
programa.Contieneelconjuntodeinstruccionescodificadasenalgnlenguajedealtonivel.Puede
estardistribuidoenpaquetes,procedimientos,bibliotecasfuente,etc.
Cdigoobjeto:eselcdigobinarioointermedioresultantedeprocesarconuncompiladorelcdigo
fuente.Consisteenunatraduccincompletaydeunasolavezdesteltimo.Elcdigoobjetonoes
inteligible por el ser humano (normalmente es formato binario) pero tampoco es directamente
ejecutableporlacomputadora.Setratadeunarepresentacinintermediaentreelcdigofuenteyel
cdigoejecutable,alosfinesdeunenlacefinalconlasrutinasdebibliotecayentreprocedimientoso
bien para su uso con un pequeo intrprete intermedio [a modo de distintos ejemplos vase
EUPHORIA, (intrprete intermedio), FORTRAN (compilador puro) MSIL (Microsoft Intermediate
Language) (intrprete) y BASIC (intrprete puro, intrprete intermedio, compilador intermedio o
compiladorpuro,dependedelaversinutilizada)].
El cdigo objeto noexiste si el programador trabaja con un lenguaje a modo de intrprete
puro, en este caso el mismo intrprete se encarga de traducir y ejecutar lnea por lnea el
cdigo fuente (de acuerdo al flujo del programa), en tiempo de ejecucin. En este caso
tampocoexiste el o los archivos de cdigoejecutable. Una desventaja de esta modalidad es
que la ejecucin del programa o sistema es un poco ms lenta que si se hiciera con un
intrpreteintermedio,ybastantemslentaquesiexisteelolosarchivosdecdigoejecutable.
Es decir no favorece el rendimiento en velocidad de ejecucin. Pero una gran ventaja de la
modalidad intrprete puro, es que l est forma de trabajo facilita enormemente la tarea de
depuracin del cdigo fuente (frente a la alternativa de hacerlo con un compilador puro).
Frecuentemente se suele usar una forma mixta de trabajo (si el lenguaje de programacin
elegido lo permite), es decir inicialmente trabajar a modo de intrprete puro, y una vez
depurado el cdigo fuente (liberado de errores) se utiliza un compilador del mismo lenguaje
paraobtenerelcdigoejecutablecompleto,conlocualseagilizaladepuracinylavelocidad
deejecucinseoptimiza.
Cdigoejecutable:Eselcdigobinarioresultadodeenlazarunoomsfragmentosdecdigoobjeto
conlasrutinasybibliotecasnecesarias.Constituyeunoomsarchivosbinariosconunformatotal

queelsistemaoperativoescapazdecargarloenlamemoriaRAM(eventualmentetambinparteen
una memoria virtual), y proceder a su ejecucin directa. Por lo anterior se dice que el cdigo
ejecutableesdirectamenteinteligibleporlacomputadora.Elcdigoejecutable,tambinconocido
comocdigomquina,noexistesiseprogramaconmodalidaddeintrpretepuro.
Pruebas(unitariasydeintegracin)
Entrelasdiversaspruebasqueseleefectanalsoftwaresepuedendistinguirprincipalmente:
Prueba unitarias: Consisten en probar o testear piezas de software pequeas a nivel de secciones,
procedimientos, funciones y mdulos aquellas que tengan funcionalidades especficas. Dichas
pruebas se utilizan para asegurar el correcto funcionamiento de secciones de cdigo, mucho ms
reducidasqueelconjunto,yquetienenfuncionesconcretasconciertogradodeindependencia.
Pruebasdeintegracin:Serealizanunavezquelaspruebasunitariasfueronconcluidasexitosamente
con stas se intenta asegurar que el sistema completo, incluso los subsistemas que componen las
piezasindividualesgrandesdelsoftwarefuncionencorrectamentealoperareinteoperarenconjunto.
Laspruebasnormalmenteseefectanconlosllamadosdatosdeprueba,queesunconjuntoseleccionadode
datostpicosalosquepuedeversesometidoelsistema,losmdulosolosbloquesdecdigo.Tambinse
escogen:Datosquellevanacondicioneslmitesalsoftwareafindeprobarsutoleranciayrobustezdatos
deutilidadparamedicionesderendimientodatosqueprovocancondicioneseventualesoparticularespoco
comunesyalasqueelsoftwarenormalmentenoestarsometidoperopuedenocurriretc.Losdatosde
pruebanonecesariamentesonficticiosocreados,peronormalmenteslosonlosdepocaprobabilidad
deocurrencia.
Generalmente,existeunfaseprobatoriafinalycompletadelsoftware,llamadaBetaTest,durantelacualel
sistema instalado en condiciones normales de operacin y trabajo es probado exhaustivamente a fin de
encontrar errores, inestabilidades, respuestas errneas, etc. que hayan pasado los previos controles. Estas
sonnormalmenterealizadasporpersonalidneocontratadooafectadoespecficamenteaello.Losposibles
errores encontrados se transmiten a los desarrolladores para su depuracin. En el caso de software de
desarrolloapedido,elusuariofinal(cliente)eselquerealizaelBetaTest,teniendoparaellounperodo
depruebapactadoconeldesarrollador.
Instalacinypasoaproduccin
La instalacin del software es el proceso por el cual los programas desarrollados son transferidos
apropiadamente al computador destino, inicializados, y, eventualmente, configurados todo ello con el
propsito de ser ya utilizados por el usuario final. Constituye la etapa final en el desarrollo propiamente
dichodelsoftware.Luegodestaelproductoentrarenlafasedefuncionamientoyproduccin,parael
quefueradiseado.
La instalacin, dependiendo del sistema desarrollado, puede consistir en una simple copia al discorgido
destino(casosrarosactualmente)obien,mscomnmente,conunadecomplejidadintermediaenlaque
los distintos archivos componentes del software (ejecutables, bibliotecas, datos propios, etc.) son
descomprimidosycopiadosalugaresespecficospreestablecidosdeldiscoinclusosecreanvnculoscon
otrosproductos,ademsdelpropiosistemaoperativo.Esteltimocaso,comnmenteesunprocesobastante
automtico que es creado y guiado con heramientas software especficas (empaquetado y distribucin,
instaladores).

Enproductosdemayorcomplejidad,lasegundaalternativaeslautilizada,peroesrealizadaoguiadapor
especialistas puede incluso requerirse la instalacin en varios y distintos computadores (instalacin
distribuida).
Tambin, en software de mediana y alta complejidad normalmente es requerido un proceso de
configuracin y chequeo, por el cual se asignan adecuados parmetros de funcionamiento y se testea la
operatividadfuncionaldelproducto.
En productos de venta masiva las instalaciones completas, si son relativamente simples, suelen ser
realizadasporlospropiosusuariosfinales(talescomosistemasoperativos,paquetesdeoficina,utilitarios,
etc.) con herramientas propias de instalacin guiada incluso la configuracin suele ser automtica. En
productos de diseo especfico o a medida la instalacin queda restringida, normalmente, a personas
especialistasinvolucradaseneldesarrollodelsoftwareencuestin.
Una vez realizada exitosamente la instalacin del software, el mismo pasa a la fase de produccin
(operatividad),durantelacualcumplelasfuncionesparalasquefuedesarrollado,esdecir,esfinalmente
utilizadoporel(olos)usuariofinal,produciendolosresultadosesperados.
Mantenimiento
Elmantenimientodesoftwareeselprocesodecontrol,mejorayoptimizacindelsoftwareyadesarrollado
einstalado,quetambinincluyedepuracindeerroresydefectosquepuedanhabersefiltradodelafasede
pruebas de control y beta test. Esta fase es la ltima (antes de iterar, segn el modelo empleado) que se
aplicaalciclodevidadeldesarrollodesoftware.Lafasedemantenimientoeslaquevienedespusdeque
elsoftwareestoperativoyenproduccin.
Deunbuendiseoydocumentacindeldesarrollodependercmoserlafasedemantenimiento,tantoen
costo temporal como monetario. Modificaciones realizadas a un software que fue elaborado con una
documentacin indebida o pobre y mal diseo puede llegar a ser tanto o ms costosa que desarrollar el
softwaredesdeelinicio.Porello,esdefundamentalimportanciarespetardebidamentetodaslastareasde
lasfasesdeldesarrolloymanteneradecuadaycompletaladocumentacin.
El perodo de la fase de mantenimiento es normalmente el mayor en todo el ciclo de vida.7 Esta fase
involucra tambin actualizaciones y evoluciones del software no necesariamente implica que el sistema
tuvo errores. Uno o ms cambios en el software, por ejemplo de adaptacin o evolutivos, puede llevar
inclusoareveryadaptardesdepartedelasprimerasfasesdeldesarrolloinicial,alterandotodaslasdems
dependiendodecunprofundosseanloscambios.Elmodelocascadacomnesparticularmentecostosoen
mantenimiento, ya que su rigidez implica que cualquier cambio provoca regreso a fase inicial y fuertes
alteracionesenlasdemsfasesdelciclodevida.
Duranteelperododemantenimiento,escomnquesurjannuevasrevisionesyversionesdelproductoque
loliberanmsdepurado,conmayorymejorfuncionalidad,mejorrendimiento,etc.Variassonlasfacetas
que pueden ser alteradas para provocar cambios deseables, evolutivos, adaptaciones o ampliaciones y
mejoras.
Bsicamentesetienenlossiguientestiposdecambios:
Perfectivos:Aquellosquellevanaunamejoradelacalidadinternadelsoftwareencualquieraspecto:
Reestructuracindelcdigo,definicinmsclaradelsistemaysudocumentacinoptimizacindel

rendimientoyeficiencia.
Evolutivos:Agregados,modificaciones,inclusoeliminaciones,necesariasenelsoftwareparacubrir
suexpansinocambio,segnlasnecesidadesdelusuario.
Adaptivos: Modificaciones que afectan a los entornos en los que el sistema opera, tales como:
Cambios de configuracin del hardware (por actualizacin o mejora de componentes electrnicos),
cambiosenelsoftwaredebase,engestoresdebasededatos,encomunicaciones,etc.
Correctivos:Alteracionesnecesariasparacorregirerroresdecualquiertipoenelproductosoftware
desarrollado.

Carcterevolutivodelsoftware
El software es el producto derivado del proceso de desarrollo, segn la ingeniera de software. Este
producto es intrnsecamente evolutivo durante su ciclo de vida. El software evoluciona, en general,
generando versiones cada vez ms completas, complejas, mejoradas, optimizadas en algn aspecto,
adecuadasanuevasplataformas(seandehardwareosistemasoperativos),etc.17
Cuando un sistema deja de evolucionar, eventualmente cumplir con su ciclo de vida, entrar en
obsolescenciaeinevitablemente,tardeotemprano,serreemplazadoporunproductonuevo.
Elsoftwareevolucionasencillamenteporquesedebeadaptaraloscambiosdelentorno,seanfuncionales
(exigenciasdeusuarios),operativos,deplataformaoarquitecturahardware.
Ladinmicadeevolucindelsoftwareeselestudiodeloscambiosdelsistema.Lamayorcontribucinen
estareafuerealizadaporMeirM.LehmanyBelady,comenzandoenlosaos70y80.Sutrabajocontinu
en la dcada de 1990, con Lehman y otros investigadores18 de relevancia en la realimentacin en los
procesosdeevolucin(Lehman,1996Lehmanetal.,1998lehmanetal.,2001).Apartirdeesosestudios
propusieronunconjuntodeleyes(conocidascomoleyesdeLehman)9respectodeloscambiosproducidos
enlossistemas.Estasleyes(enrealidadsonhiptesis)soninvariantesyampliamenteaplicables.
Lehman y Belady analizaron el crecimiento y la evolucin de varios sistemas software de gran porte
derivandofinalmente,segnsusmedidas,lassiguientesocholeyes:
1.Cambio continuo: Un programa que se usa en un entorno real necesariamente debe cambiar o se
volverprogresivamentemenostileneseentorno.
2.Complejidadcreciente:Amedidaqueunprogramaenevolucincambia,suestructuratiendeaser
cadavezmscompleja.Sedebendedicarrecursosextrasparapreservarysimplificarlaestrucutura.
3.Evolucinprolongadadelprograma:Laevolucindelosprogramasesunprocesoautorregulativo.
Los atributos de los sistemas, tales como tamao, tiempo entre entregas y la cantidad de errores
documentadossonaproximadamenteinvariantesparacadaentregadelsistema.
4.Estabilidadorganizacional:Duranteeltiempodevidadeunprograma,suvelocidaddedesarrolloes
aproximadamenteconstanteeindependientedelosrecursosdedicadosaldesarrollodelsistema.
5.Conservacindelafamiliaridad:Duranteeltiempodevidadeunsistema,elcambioincrementalen
cadaentregaesaproximadamenteconstante.
6.Crecimientocontinuado:Lafuncionalidadofrecidaporlossistemastienequecrecercontinuamente
paramantenerlasatisfaccindelosusuarios.
7.Decrementodelacalidad:Lacalidaddelossistemassoftwarecomenzaradisminuiramenosque
dichossistemasseadaptenaloscambiosdesuentornodefuncionamiento.
8.Realimentacin del sistema: Los procesos de evolucin incorporan sistemas de realimentacin
multiagenteymultibucleyestosdebensertratadoscomosistemasderealimentacinparalograruna

mejorasignificativadelproducto.

Referencias
1.Diccionariodelalenguaespaola2005(2010).wordreference.com,ed.software(http://www.wordreference.co
m/definicion/software)(diccionario).EspasaCalpe.Consultadoel1defebrerode2010.
2.Real Academia Espaola. Significado de la palabra Software (http://lema.rae.es/drae/?val=software).
DiccionariodelaLenguaEspaola,XXIIEdicin.Consultadoel14demarzode2008.
3.Real Academia Espaola. Uso de la palabra Software (http://lema.rae.es/dpd/?key=software). Diccionario
panhispnicodedudas,1.Edicin(octubrede2005).Consultadoel8defebrerode2009.
4.Pressman,RogerS.(2003).Elproducto.Ingenieradelsoftware,unenfoqueprctico,Quintaedicinedicin.
Mxico:McGrawHill.
5.IEEE Std, IEEE Software Engineering Standard: Glossary of Software Engineering Terminology. IEEE
ComputerSocietyPress,1993
6.Ciclo deVida del Software(http://web.archive.org/web/http://alarcos.infcr.uclm.es/doc/ISOFTWAREI/Tema0
3.pdf).GrupoAlarcosEscuelaSuperiordeInformticadeCiudadReal.Archivadodesde eloriginal(http://alarc
os.infcr.uclm.es/doc/ISOFTWAREI/Tema03.pdf)el29denoviembrede2015.
7.Pressman,RogerS.(2003).Elproceso.IngenieradelSoftware,unenfoquePrctico,Quintaedicinedicin.
Mxico:McGrawHill.
8.Trmino "Elicitar" (http://es.wiktionary.org/wiki/elicitar). 1ra. acepcin Wiktionary. Consultado el 15 de
diciembrede2008.
9.Leyes de evolucin del Software (http://cnx.org/content/m17406/latest/). Connexions Educational content
repository.
10.CiclodevidadelSoftwareyModelosdedesarrollo(http://web.archive.org/web/http://www.cepeu.edu.py/LIBR
OS_ELECTRONICOS_3/lpcu097%20%2001.pdf). Instituto de Formacin Profesional Libros Digitales.
Archivado desde el original (http://www.cepeu.edu.py/LIBROS_ELECTRONICOS_3/lpcu097%20%2001.pdf)
el29denoviembrede2015.Textolugar:AsuncindelParaguayignorado(ayuda)
11.EvolucindelSoftware(http://cnx.org/content/m17405/latest/).ConnexionsEducationalcontentrepository.
12.Software Requirements Engineering, 2nd Edition, IEEE Computer Society. Los Alamitos, CA, 1997
(Compendiodepapersyartculoseningenieraderequisitos)
13.III Workshop de Engenharia de Requisitos(http://www.informatik.unitrier.de/~ley/db/conf/wer/wer2000.htm
l).WER2000,RodeJaneiro,2000.
14.RecommendedPracticeforSoftwareRequirementsSpecification(http://code.google.com/p/changecontrol/down
loads/detail?name=IEEE%208301998%20Recommended%20Practice%20for%20Software%20Requirements%20
Specifications.pdf&can=2&q=).IEEESAStandardsBoard.
15.LELyEscenarioscomometodologaenIngenieradeRequisitos(http://ficcte.unimoron.edu.ar/wicc/Trabajos/I
II%20%20isbd/673Ridao_Doorn_wicc06.pdf).Univ.deMorn,BuenosAires.
16.MetodologaparaelanlisisdeRequisitosdeSistemasSoftware(http://www.infor.uva.es/~mlaguna/is1/materi
ales/metodologia_analisis.pdf).Univ.deSevilla,2001.
17.Sommerville,Ian(2005).21Evolucindelsoftware.IngenieradelSoftware.Espaa:PearsonEducacinS.A.
18.ACM Fellow Profile for Meir M. (Manny) Lehman(http://www.sigsoft.org/SEN/lehman.html).ACM. 31 de
mayode2007.Consultadoel27denoviembrede2011.

Bibliografa
Libros
JACOBSON, Ivar BOOCH, Grady RUMBAUGH, James (2000). El Proceso Unificado de
DesarrollodeSoftware.PearsonAddissonWesley.
Pressman,RogerS.(2003).Ingeniera del Software,un enfoquePrctico (Quinta edicin edicin).

McGrawHill.ISBN8448132149.
JACOBSONBOOCHRUMBAUGH(1999).UMLElLenguajeUnificadodeModelado.Pearson
AddissonWesley.RationalSoftwareCorporation,AddisonWesleyIberoamericana. ISBN847829028
1.
Haeberer, A. M. P. A. S. Veloso, G. Baum (1988). Formalizacin del proceso de desarrollo de
software(Ed.preliminaredicin).BuenosAires:Kapelusz.ISBN9501398803.
Fowler,MartinKendallSccott(1999).UMLGotaaGota.AddisonWesley.ISBN9789684443648.
Loucopoulos,PericlesKarakostas,V.(1995).SystemRequirementsEngineering(eningls).London:
McGrawHillCompanies.pp.160p.ISBN9780077078430.
Sommerville,IanP.Sawyer(1997).RequirementsEngineering:AGoodPracticeGuide(en ingls)
(1ra.editionedicin).Wiley&Sons.pp.404p.ISBN9780471974444.
Gottesdiener, Ellen P. Sawyer (2002). Requirements by Collaboration: Workshops for Defining
Needs(eningls).AddisonWesleyProfessional.pp.368p.ISBN9780201786064.
Sommerville, Ian (2005). Ingeniera del software (7ma. edicin). Madrid: Pearson Educacin S.A.
ISBN8478290745.

Artculosyrevistas
WeitzenfeldElProcesoparaDesarrollodeSoftware2002
CarlosReynosoMtodosHeterodoxosenDesarrollodeSoftware2004
GrupoISSIUniv.PolitcnicadeValenciaMetodologasgilesenelDesarrollodeSoftware
2003
MartinFowlerLaNuevaMetodologa2003
Cutter IT Journal Requirements Engineering and Management. August 25, 2000. Cutter
Consortium.
Software Requirements Engineering, 2nd Edition, IEEE Computer Society. Los Alamitos, CA,
1997(Compendiodepapersyartculoseningenieraderequisitos).
Lehman,M.M.LawsofSoftwareEvolutionRevisited,pos.pap.,EWSPT96,Oct.1996,LNCS
1149,SpringerVerlag,1997,pp.108124

Vasetambin
Portal:Software.ContenidorelacionadoconSoftware.
Ingenieradesoftware
Programainformtico
Aplicacininformtica
Programacin
Fasesdeldesarrollodesoftware
Softwarecolaborativo
Softwarelibre
Ingenierainformtica
Hediondezdelcdigo

Modelosdeciclodevida
Modeloencascadaosecuencial
Modeloiterativoincremental
Modeloevolutivoespiral
Modelodeprototipos
Modelodedesarrollorpido

Enlacesexternos
WikimediaCommonsalbergacontenidomultimediasobreSoftware.
Wikcionariotienedefinicionesyotrainformacinsobresoftware.
Obtenidodehttps://es.wikipedia.org/w/index.php?title=Software&oldid=90998151
Categoras: Software Palabrasyfraseseningls
Estapginafuemodificadaporltimavezel11may2016alas16:49.
EltextoestdisponiblebajolaLicenciaCreativeCommonsAtribucinCompartirIgual3.0podran
seraplicablesclusulasadicionales.Alusarestesitio,ustedaceptanuestrostrminosdeusoynuestra
polticadeprivacidad.
WikipediaesunamarcaregistradadelaFundacinWikimedia,Inc.,unaorganizacinsinnimode
lucro.