Software

Software

ponentes fsicos y el resto de las aplicaciones, y proporcionando una interfaz con el usuario.
El anglicismo software es el ms ampliamente difundido al referirse a este concepto, especialmente en la jerga
tcnica; en tanto que el trmino sinnimo logicial, derivado del trmino francs logiciel, es utilizado mayormente en pases y zonas de inuencia francesa. Su abreviatura
es Sw.

1 Etimologa
Software (pronunciacin AFI:[sftw]) es una palabra
proveniente del ingls (literalmente: partes blandas o suaves), que en espaol no posee una traduccin adecuada
al contexto, por lo cual se la utiliza asiduamente sin traducir y as fue admitida por la Real Academia Espaola
(RAE).[2] Aunque puede no ser estrictamente lo mismo,
suele sustituirse por expresiones tales como programas
(informticos) o aplicaciones (informticas) o soportes lgicos.[3]
Software es lo que se denomina producto en Ingeniera de
Software.[4]

2 Denicin de software
Existen varias deniciones 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, que forman parte de las
operaciones de un sistema de computacin.
Extrado del estndar 729 del IEEE[5]

Dentro de la categora de software de aplicacin estn

incluidos los procesadores de texto como LibreOce
Writer (arriba) y los editores grcos rasterizados como
Krita (abajo).

Se conoce como software[1] al equipo lgico o soporte lgico de un sistema informtico, que comprende el conjunto de los componentes lgicos necesarios que hacen posi- Considerando esta denicin, el concepto de software va
ble la realizacin de tareas especcas, en contraposicin ms all de los programas de computacin en sus distintos estados: cdigo fuente, binario o ejecutable; tambin
a los componentes fsicos que son llamados hardware.
su documentacin, los datos a procesar e incluso la inLos componentes lgicos incluyen, entre muchos otros, formacin de usuario forman parte del software: es decir,
las aplicaciones informticas; tales como el procesador de abarca todo lo intangible, todo lo no fsico relacionado.
texto, que permite al usuario realizar todas las tareas concernientes a la edicin de textos; el llamado software de El trmino software fue usado por primera vez en este
sistema, tal como el sistema operativo, que bsicamente sentido por John W. Tukey en 1957. En la ingeniera de
permite al resto de los programas funcionar adecuada- software y las ciencias de la computacin, el software es
mente, facilitando tambin la interaccin entre los com- toda la informacin procesada por los sistemas informticos: programas y datos.
1

El concepto de leer diferentes secuencias de instrucciones

(programa) desde la memoria de un dispositivo para controlar los clculos fue introducido por Charles Babbage
como parte de su mquina diferencial. La teora que forma la base de la mayor parte del software moderno fue
propuesta por Alan Turing en su ensayo de 1936, Los
nmeros computables, con una aplicacin al problema
de decisin.

Clasicacin del software

Si bien esta distincin es, en cierto modo, arbitraria, y a

veces confusa, a los nes prcticos se puede clasicar al
software en tres grandes tipos:
Software de sistema: Su objetivo es desvincular
adecuadamente al usuario y al programador de los
detalles del sistema informtico en particular que
se use, aislndolo especialmente del procesamiento referido a las caractersticas internas de: memoria, discos, puertos y dispositivos de comunicaciones, impresoras, pantallas, teclados, etc. El software de sistema le procura al usuario y programador
adecuadas interfaces de alto nivel, controladores,
herramientas y utilidades de apoyo que permiten
el mantenimiento del sistema global. Incluye entre
otros:
Sistemas operativos
Controladores de dispositivos
Herramientas de diagnstico
Herramientas de Correccin y Optimizacin
Servidores
Utilidades
Software de programacin: Es el conjunto de herramientas que permiten al programador desarrollar
programas informticos, usando diferentes alternativas y lenguajes de programacin, de una manera
prctica. Incluyen bsicamente:
Editores de texto
Compiladores
Intrpretes
Enlazadores
Depuradores

PROCESO DE CREACIN DEL SOFTWARE

Software de aplicacin: Es aquel que permite a los

usuarios llevar a cabo una o varias tareas especcas,
en cualquier campo de actividad susceptible de ser
automatizado o asistido, con especial nfasis en los
negocios. Incluye entre muchos otros:
Aplicaciones para Control de sistemas y
automatizacin industrial
Aplicaciones omticas
Software educativo
Software empresarial
Bases de datos
Telecomunicaciones (por ejemplo Internet y
toda su estructura lgica)
Videojuegos
Software mdico
Software de clculo numrico y simblico.
Software de diseo asistido (CAD)
Software de control numrico (CAM)

4 Proceso de creacin del software

Se dene como proceso al conjunto 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 que resuelva un problema especco.
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, si se trata de un sencillo programa
(por ejemplo, la resolucin de una ecuacin de segundo
orden), ste puede ser realizado por un solo programador
(incluso acionado) fcilmente. Es as que normalmente
se dividen en tres categoras segn su tamao (lneas de
cdigo) o costo: de pequeo, mediano y gran porte.
Existen varias metodologas para estimarlo, una de las
ms populares es el sistema COCOMO que provee mtodos y un software (programa) que calcula y provee una
aproximacin de todos los costos de produccin en un
proyecto software (relacin horas/hombre, costo monetario, cantidad de lneas fuente de acuerdo a lenguaje
usado, etc.).
Considerando los de gran porte, es necesario realizar
complejas tareas, tanto tcnicas como de gerencia, una
fuerte gestin y anlisis diversos (entre otras cosas), la
complejidad de ello ha llevado a que desarrolle una ingeniera especca para tratar su estudio y realizacin: es
conocida como Ingeniera de Software.

Entornos de Desarrollo Integrados (IDE):

Agrupan las anteriores herramientas, usualmente en un entorno visual, de forma tal que el
programador no necesite introducir mltiples
comandos para compilar, interpretar, depurar, En tanto que en los de mediano porte, pequeos equipos
etc. Habitualmente cuentan con una avanzada de trabajo (incluso un avezado analista-programador soliinterfaz grca de usuario (GUI).
tario) pueden realizar la tarea. Aunque, siempre en casos

4.1

Modelos de proceso o ciclo de vida

de mediano y gran porte (y a veces tambin en algunos de

pequeo porte, segn su complejidad), se deben seguir
ciertas etapas que son necesarias para la construccin del
software. Tales etapas, si bien deben existir, son exibles
en su forma de aplicacin, de acuerdo a la metodologa o
proceso de desarrollo escogido y utilizado por el equipo
de desarrollo o por el analista-programador solitario (si
fuere el caso).
Los procesos de desarrollo de software poseen reglas preestablecidas, y deben ser aplicados en la creacin
del software de mediano y gran porte, ya que en caso contrario lo ms seguro es que el proyecto no logre concluir
o termine sin cumplir los objetivos previstos, y con variedad de fallos inaceptables (fracasan, en pocas palabras).
Entre tales procesos los hay giles o livianos (ejemplo
XP), pesados y lentos (ejemplo RUP), y variantes intermedias. Normalmente se aplican de acuerdo al tipo y porte del software a desarrollar, a criterio del lder (si lo hay)
del equipo de desarrollo. Algunos de esos procesos son
Programacin Extrema (en ingls eXtreme Programming
o XP), Proceso Unicado de Rational (en ingls Rational
Unied Process o RUP), Feature Driven Development
(FDD), etc.

3
Captura, elicitacin[8] , especicacin y anlisis de
requisitos (ERS)
Diseo
Codicacin
Pruebas (unitarias y de integracin)
Instalacin y paso a produccin
Mantenimiento
En las anteriores etapas pueden variar ligeramente sus
nombres, o ser ms globales, o contrariamente, ser ms
renadas; por ejemplo indicar como una nica fase (a los
nes documentales e interpretativos) de anlisis y diseo; o indicar como implementacin lo que est dicho
como codicacin; pero en rigor, todas existen e incluyen, bsicamente, las mismas tareas especcas.
En el apartado 4 del presente artculo se brindan mayores
detalles de cada una de las etapas indicadas.

4.1 Modelos de proceso o ciclo de vida

Cualquiera sea el proceso utilizado y aplicado al desarrollo del software (RUP, FDD, XP, etc), y casi indepen- Para cada una de las fases o etapas listadas en el tem andientemente de l, siempre se debe aplicar un modelo terior, existen sub-etapas (o tareas). El modelo de proceso
de ciclo de vida.[6]
o modelo de ciclo de vida utilizado para el desarrollo, de[6]
Se estima que, del total de proyectos software grandes ne el orden de las tareas o actividades involucradas,
emprendidos, un 28% fracasan, un 46% caen en severas tambin dene la coordinacin entre ellas, y su enlace y
modicaciones que lo retrasan y un 26% son totalmente realimentacin. Entre los ms conocidos se puede mencionar: modelo en cascada o secuencial, modelo espiral,
exitosos. [7]
modelo iterativo incremental. De los antedichos hay a su
Cuando un proyecto fracasa, rara vez es debido a fallas vez algunas variantes o alternativas, ms o menos atractcnicas, la principal causa de fallos y fracasos es la fal- tivas segn sea la aplicacin requerida y sus requisitos.[7]
ta 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 4.1.1 Modelo cascada
desarrollo, o crear nuevas y concientizar a los profesionales de la informtica a su utilizacin adecuada. Normal- Este, aunque es ms comnmente conocido como modelo
mente los especialistas en el estudio y desarrollo de estas en cascada es tambin llamado modelo clsico, moreas (metodologas) y anes (tales como modelos y has- delo tradicional o modelo lineal secuencial.
ta la gestin misma de los proyectos) son los ingenieros
El modelo en cascada puro difcilmente se utiliza tal cual,
en software, es su orientacin. Los especialistas en cualpues esto implicara un previo y absoluto conocimiento de
quier otra rea de desarrollo informtico (analista, prolos requisitos, la no volatilidad de los mismos (o rigidez)
gramador, Lic. en informtica, ingeniero en informtica,
y etapas subsiguientes libres de errores; ello slo podra
ingeniero de sistemas, etc.) normalmente aplican sus coser aplicable a escasos y pequeos sistemas a desarrollar.
nocimientos especializados pero utilizando modelos, paEn estas circunstancias, el paso de una etapa a otra de las
radigmas y procesos ya elaborados.
mencionadas sera sin retorno, por ejemplo pasar del diEs comn para el desarrollo de software de mediano por- seo a la codicacin implicara un diseo exacto y sin
te que los equipos humanos involucrados apliquen me- errores ni probable modicacin o evolucin: codique
todologas propias, normalmente un hbrido de los pro- lo diseado sin errores, no habr en absoluto variantes
cesos anteriores y a veces con criterios propios.
futuras. Esto es utpico; ya que intrnsecamente el soft[9]
El proceso de desarrollo puede involucrar numerosas y ware es de carcter evolutivo, cambiante y difcilmente
durante su desarrollo como durante
variadas tareas,[6] desde lo administrativo, pasando por libre de errores, tanto
[6]
su
vida
operativa.
lo tcnico y hasta la gestin y el gerenciamiento. Pero,
casi rigurosamente, siempre se cumplen ciertas etapas Algn cambio durante la ejecucin de una cualquiera de
mnimas; las que se pueden resumir como sigue:
las etapas en este modelo secuencial implicara reiniciar

PROCESO DE CREACIN DEL SOFTWARE

Lo dicho es, a grandes rasgos, la forma y utilizacin de

este modelo, uno de los ms usados y populares.[6] El modelo cascada realimentado resulta muy atractivo, hasta
ideal, si el proyecto presenta alta rigidez (pocos cambios,
previsto no evolutivo), los requisitos son muy claros y estn correctamente especicados.[10]

Figura 2: Modelo cascada puro o secuencial para el ciclo de vida

del software.

Hay ms variantes similares al modelo: reno de etapas

(ms etapas, menores y ms especcas) o incluso mostrar menos etapas de las indicadas, aunque en tal caso la
faltante estar dentro de alguna otra. El orden de esas fases indicadas en el tem previo es el lgico y adecuado,
pero advirtase, como se dijo, que normalmente habr
realimentacin hacia atrs.

El modelo lineal o en cascada es el paradigma ms antidesde el principio todo el ciclo completo, lo cual redun- guo y extensamente utilizado, sin embargo las crticas a
dara en altos costos de tiempo y desarrollo. La Figura 2 l (ver desventajas) han puesto en duda su ecacia. Pese
muestra un posible esquema de el modelo en cuestin.[6] a todo, tiene un lugar muy importante en la Ingeniera de
software y contina siendo el ms utilizado; y siempre es
Sin embargo, el modelo cascada en algunas de sus va- mejor que un enfoque al azar.[10]
riantes es uno de los actualmente ms utilizados,[10] por
[6]
su ecacia y simplicidad, ms que nada en software de Desventajas del modelo cascada:
pequeo y algunos de mediano porte; pero nunca (o muy
Los cambios introducidos durante el desarrollo puerara vez) se lo usa en su forma pura, como se dijo anden confundir al equipo profesional en las etapas
teriormente. En lugar de ello, siempre se produce algutempranas del proyecto. Si los cambios se producen
na realimentacin entre etapas, que no es completamente
en etapa madura (codicacin o prueba) pueden ser
predecible ni rgida; esto da oportunidad al desarrollo de
catastrcos para un proyecto grande.
productos software en los cuales hay ciertas incertezas,
cambios o evoluciones durante el ciclo de vida. As por
No es frecuente que el cliente o usuario nal expliejemplo, una vez capturados y especicados los requisitos
cite clara y completamente los requisitos (etapa de
(primera etapa) se puede pasar al diseo del sistema, pero
inicio); y el modelo lineal lo requiere. La incertidurante esta ltima fase lo ms probable es que se deban
dumbre natural en los comienzos es luego difcil de
realizar ajustes en los requisitos (aunque sean mnimos),
acomodar.[10]
ya sea por fallas detectadas, ambigedades o bien por que
El cliente debe tener paciencia ya que el software no
los propios requisitos han cambiado o evolucionado; con
estar disponible hasta muy avanzado el proyecto.
lo cual se debe retornar a la primera o previa etapa, hacer
Un error detectado por el cliente (en fase de operalos reajuste pertinentes y luego continuar nuevamente con
cin) puede ser desastroso, implicando reinicio del
el diseo; esto ltimo se conoce como realimentacin. Lo
proyecto, con altos costos.
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 po- 4.1.2 Modelos evolutivos
der saltar a varias anteriores) si es requerido.
[11][9]
Los requisiDe esta manera se obtiene el modelo cascada realimen- El software evoluciona con el tiempo.
tado, que puede ser esquematizado como lo ilustra la tos del usuario y del producto suelen cambiar conforme
se desarrolla el mismo. Las fechas de mercado y la comFigura 3.
petencia hacen que no sea posible esperar a poner en el
mercado un producto absolutamente completo, por lo que
se aconsejable introducir una versin funcional limitada
de alguna forma para aliviar las presiones competitivas.
En esas u otras situaciones similares los desarrolladores
necesitan modelos de progreso que estn diseados para
acomodarse a una evolucin temporal o progresiva, donde los requisitos centrales son conocidos de antemano,
aunque no estn bien denidos a nivel detalle.

Figura 3: Modelo cascada realimentado para el ciclo de vida.

En el modelo cascada y cascada realimentado no se

tiene demasiado en cuenta la naturaleza evolutiva del
software,[11] se plantea como esttico, con requisitos bien
conocidos y denidos desde el inicio.[6]

4.1

Modelos de proceso o ciclo de vida

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez ms completas y complejas, hasta
llegar al objetivo nal deseado; incluso evolucionar ms
all, durante la fase de operacin.
Los modelos iterativo incremental y espiral (entre
otros) son dos de los ms conocidos y utilizados del tipo
evolutivo.[10]
Modelo iterativo incremental En trminos generales,
se puede distinguir, en la Figura 4, los pasos generales que
sigue el proceso de desarrollo de un producto software.
En el modelo de ciclo de vida seleccionado, se identican claramente dichos pasos. La descripcin del sistema
es esencial para especicar y confeccionar los distintos
incrementos hasta llegar al producto global y nal. Las
actividades concurrentes (especicacin, desarrollo y validacin) sintetizan el desarrollo pormenorizado de los incrementos, que se har posteriormente.

Figura 4: Diagrama genrico del desarrollo evolutivo incremental.

El diagrama de la Figura 4 muestra en forma muy esquemtica, el funcionamiento de un ciclo iterativo incremental, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto nal.[6] Es decir,
a medida que cada incremento denido llega a su etapa
de operacin y mantenimiento. Cada versin emitida incorpora a los anteriores incrementos las funcionalidades
y requisitos que fueron analizados como necesarios.
El incremental es un modelo de tipo evolutivo que est basado en varios ciclos Cascada Realimentados aplicados repetidamente, con una losofa iterativa.[10] En la Figura
5 se muestra un reno del diagrama previo, bajo un esquema temporal, para obtener nalmente el esquema del
modelo de ciclo de vida Iterativo Incremental, con sus actividades genricas asociadas. Aqu se observa claramente cada ciclo cascada que es aplicado para la obtencin de
un incremento; estos ltimos se van integrando para obtener el producto nal completo. Cada incremento es un
ciclo Cascada Realimentado, aunque, por simplicidad, en
la Figura 5 se muestra como secuencial puro.

Figura 5: Modelo iterativo incremental para el ciclo de vida del

software.

quemtica, un incremento no necesariamente se iniciar

durante la fase de diseo del anterior, puede ser posterior
(incluso antes), en cualquier tiempo de la etapa previa.
Cada incremento concluye con la actividad de operacin y mantenimiento (indicada como Operacin en
la gura), que es donde se produce la entrega del producto parcial al cliente. El momento de inicio de cada incremento es dependiente de varios factores: 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
suciente); capacidad y cantidad de profesionales involucrados en el desarrollo; etc.
Bajo este modelo se entrega software por partes funcionales ms pequeas, pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre
aquel que ya fue entregado.[6]
Como se muestra en la Figura 5, se aplican secuencias
Cascada en forma escalonada, mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y a menudo el primer incremento es
un sistema bsico, con muchas funciones suplementarias
(conocidas o no) sin entregar.
El cliente utiliza inicialmente ese sistema bsico, intertanto, el resultado de su uso y evaluacin puede aportar
al plan para el desarrollo del/los siguientes incrementos
(o versiones). Adems tambin aportan a ese plan otros
factores, como lo es la priorizacin (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 que el previo. El proceso se repite
hasta alcanzar el software nal completo.

Siendo iterativo, con el modelo incremental se entrega un

producto parcial pero completamente operacional en cada
incremento, y no una parte que sea usada para reajustar los
requisitos (como si ocurre en el modelo de construccin
de
prototipos).[10]
Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o concu- El enfoque incremental resulta muy til cuando se disporrentemente, as por ejemplo, en la Figura, mientras se ne de baja dotacin de personal para el desarrollo; tamrealiza el diseo detalle del primer incremento ya se est bin si no hay disponible fecha lmite del proyecto por lo
realizando en anlisis del segundo. La Figura 5 es slo es- que se entregan versiones incompletas pero que propor-

PROCESO DE CREACIN DEL SOFTWARE

cionan al usuario funcionalidad bsica (y cada vez ma- En resumen, un modelo incremental lleva a pensar en
yor). Tambin es un modelo til a los nes de versiones un desarrollo modular, con entregas parciales del prode evaluacin.
ducto software denominados incrementos del sistema,
Nota: Puede ser considerado y til, en cualquier momen- que son escogidos segn prioridades predenidas de alto o incremento incorporar temporalmente el paradigma gn modo. El modelo permite una implementacin con
MCP como complemento, teniendo as una mixtura de renamientos sucesivos (ampliacin o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren
modelos que mejoran el esquema y desarrollo general.
nuevos requisitos o bien se mejora la versin previamente
Ejemplo:
implementada del producto software.
Un procesador de texto que sea desarrollado
bajo el paradigma Incremental podra aportar,
en principio, funciones bsicas de edicin de
archivos y produccin de documentos (algo como un editor simple). En un segundo incremento se le podra agregar edicin ms sosticada, y de generacin y mezcla de documentos.
En un tercer incremento podra considerarse el
agregado de funciones de correccin ortogrca, esquemas de paginado y plantillas; en un
cuarto capacidades de dibujo propias y ecuaciones matemticas. As sucesivamente hasta
llegar al procesador nal requerido. As, el producto va creciendo, acercndose a su meta nal, pero desde la entrega del primer incremento ya es til y funcional para el cliente, el cual
observa una respuesta rpida en cuanto a entrega temprana; sin notar que la fecha lmite
del proyecto puede no estar acotada ni tan denida, lo que da margen de operacin y alivia
presiones al equipo de desarrollo.
Como se dijo, el Iterativo Incremental es un modelo del
tipo evolutivo, es decir donde se permiten y esperan probables cambios en los requisitos en tiempo de desarrollo; se admite cierto margen para que el software pueda
evolucionar.[9] Aplicable cuando los requisitos son medianamente bien conocidos pero no son completamente
estticos y denidos, cuestin esa que si es indispensable
para poder utilizar un modelo Cascada.
El modelo es aconsejable para el desarrollo de software
en el cual se observe, en su etapa inicial de anlisis, que
posee reas bastante bien denidas a cubrir, con suciente independencia como para ser desarrolladas en etapas
sucesivas. Tales reas a cubrir suelen tener distintos grados de apremio por lo cual las mismas se deben priorizar
en un anlisis previo, es decir, denir cual ser la primera, la segunda, y as sucesivamente; esto se conoce como
denicin de los incrementos con base en la priorizacin. Pueden no existir prioridades funcionales por parte
del cliente, pero el desarrollador debe jarlas de todos
modos y con algn criterio, ya que basndose en ellas se
desarrollarn y entregarn los distintos incrementos.
El hecho de que existan incrementos funcionales del software lleva inmediatamente a pensar en un esquema de
desarrollo modular, por tanto este modelo facilita tal paradigma de diseo.

Este modelo brinda cierta exibilidad para que durante el desarrollo se incluyan cambios en los requisitos
por parte del usuario, un cambio de requisitos propuesto y aprobado puede analizarse e implementarse como
un nuevo incremento o, eventualmente, podr constituir
una mejora/adecuacin de uno ya planeado. 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, ya que puede impactar
fuertemente en los costos.
La seleccin de este modelo permite realizar entregas
funcionales tempranas al cliente (lo cual es benecioso
tanto para l como para el grupo de desarrollo). Se priorizan las entregas de aquellos mdulos o incrementos en
que surja la necesidad operativa de hacerlo, por ejemplo
para cargas previas de informacin, indispensable para
los incrementos siguientes.[10]
El modelo iterativo incremental no obliga a especicar
con precisin y detalle absolutamente todo lo que el sistema debe hacer, (y cmo), antes de ser construido (como
el caso del cascada, con requisitos congelados). Slo se
hace en el incremento en desarrollo. Esto torna ms manejable el proceso y reduce el impacto en los costos. Esto
es as, porque en caso de alterar o rehacer los requisitos,
solo afecta una parte del sistema. Aunque, lgicamente,
esta situacin se agrava si se presenta en estado avanzado,
es decir en los ltimos incrementos. En denitiva, 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 funcionalidad
parcial. Tambin provee un impacto ventajoso frente al
cliente, que es la entrega temprana de partes operativas
del software.
El modelo proporciona todas las ventajas del modelo en
cascada realimentado, reduciendo sus desventajas slo al
mbito de cada incremento.
El modelo incremental no es recomendable para casos de
sistemas de tiempo real, de alto nivel de seguridad, de
procesamiento distribuido, o de alto ndice de riesgos.

Modelo espiral 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.

4.1

Modelos de proceso o ciclo de vida

Proporciona potencial para desarrollo rpido de versiones incrementales. En el modelo Espiral el software se
construye en una serie de versiones incrementales. En las
primeras iteraciones la versin incremental podra ser un
modelo en papel o bien un prototipo. En las ltimas iteraciones se producen versiones cada vez ms completas
del sistema diseado.[6][10]

Las actividades enunciadas para el marco de trabajo son

generales y se aplican a cualquier proyecto, grande, mediano o pequeo, complejo o no. Las regiones que denen
esas actividades comprenden un conjunto de 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,
El modelo se divide en un nmero de Actividades de mar- algunas de las ellas normalmente dependen del proyecto
o desarrollo en si.
co de trabajo, llamadas regiones de tareas. En general
existen entre tres y seis regiones de tareas (hay variantes Proyectos pequeos requieren baja cantidad de tareas y
del modelo). En la Figura 6 se muestra el esquema de un tambin de formalidad. En proyectos mayores o crticos
Modelo Espiral con 6 regiones. En este caso se explica cada regin de tareas contiene labores de ms alto nivel
una variante del modelo original de Boehm, expuesto en de formalidad. En cualquier caso se aplican actividades
su tratado de 1988; en 1998 expuso un tratado ms re- de proteccin (por ejemplo, gestin de conguracin del
ciente.
software, garanta de calidad, etc.).
Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniera gira alrededor del espiral (metafricamente hablando) comenzando por el centro (marcado con en la
Figura 6) y en el sentido indicado; el primer circuito de la
espiral puede producir el desarrollo de una especicacin
del producto; los pasos siguientes podran generar un
prototipo y progresivamente versiones ms sosticadas
del software.
Cada paso por la regin de planicacin provoca ajustes
en el plan del proyecto; el coste y planicacin se realimentan en funcin de la evaluacin del cliente. El gestor
de proyectos debe ajustar el nmero de iteraciones requeridas para completar el desarrollo.
El modelo espiral puede ir adaptndose y aplicarse a lo
largo de todo el Ciclo de vida del software (en el modelo clsico, o cascada, el proceso termina a la entrega del
software).
Figura 6: Modelo espiral para el ciclo de vida del software.

Las regiones denidas en el modelo de la gura son:

Regin 1 - Tareas requeridas para establecer la comunicacin entre el cliente y el desarrollador.
Regin 2 - Tareas inherentes a la denicin de los
recursos, tiempo y otra informacin relacionada con
el proyecto.
Regin 3 - Tareas necesarias para evaluar 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. documentacin y prctica).

Una visin alternativa del modelo puede observarse examinando el eje de punto de entrada de proyectos. Cada
uno de los circulitos () jados a lo largo del eje representan puntos de arranque de los distintos proyectos (relacionados); a saber:
Un proyecto de desarrollo de conceptos comienza al inicio de la espiral, hace mltiples iteraciones
hasta que se completa, es la zona marcada con verde.
Si lo anterior se va a desarrollar como producto real,
se inicia otro proyecto: Desarrollo de nuevo Producto. Que evolucionar con iteraciones hasta culminar; es la zona marcada en color azul.
Eventual y anlogamente se generarn proyectos de
mejoras de productos y de mantenimiento de
productos, con las iteraciones necesarias en cada
rea (zonas roja y gris, respectivamente).

Cuando la espiral se caracteriza de esta forma, est ope Regin 6 - Tareas para obtener la reaccin del clien- rativa hasta que el software se retira, eventualmente
te, segn la evaluacin de lo creado e instalado en puede estar inactiva (el proceso), pero cuando se produlos ciclos anteriores.
ce un cambio el proceso arranca nuevamente en el punto

PROCESO DE CREACIN DEL SOFTWARE

de entrada apropiado (por ejemplo, en mejora del producto).

1. Identicacin del sistema o subsistemas clave de los

directivos(*) (saber qu quieren).

El modelo espiral da un enfoque realista, que evoluciona

igual que el software;[11] se adapta muy bien para desarrollos a gran escala.

2. Determinacin de condiciones de victoria de los

directivos (saber qu necesitan y los satisface)

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 reeja mejor la realidad.

3. Negociacin de las condiciones victoria de los directivos para obtener condiciones Victoria & Victoria (negociar para que ambos ganen).

Este modelo requiere considerar riesgos tcnicos en todas (*) Directivo: Cliente escogido con inters directo en el
las etapas del proyecto; aplicado adecuadamente debe re- producto, que puede ser premiado por la organizacin si
ducirlos antes de que sean un verdadero problema.
tiene xito o criticado si no.
El Modelo evolutivo como el Espiral es particularmen- El modelo Win & Win hace nfasis en la negociacin
te apto para el desarrollo de Sistemas Operativos (com- inicial, tambin introduce 3 hitos en el proceso llamados
plejos); tambin en sistemas de altos riesgos o crticos puntos de jacin, que ayudan a establecer la comple(Ej. navegadores y controladores aeronuticos) y en to- titud de un ciclo de la espiral, y proporcionan hitos de
dos aquellos en que sea necesaria una fuerte gestin del decisin antes de continuar el proyecto de desarrollo del
proyecto y sus riesgos, tcnicos o de gestin.
software.
Desventajas importantes:

4.2 Etapas en el desarrollo del software

Requiere mucha experiencia y habilidad para la evaluacin de los riesgos, lo cual es requisito para el
4.2.1 Captura, anlisis y especicacin de requisixito del proyecto.
tos
Es difcil convencer a los grandes clientes que se podr controlar este enfoque evolutivo.

Al inicio de un desarrollo (no de un proyecto), esta es la

primera fase que se realiza, y, segn el modelo de proceso
adoptado, puede casi terminar para pasar a la prxima
Este modelo no se ha usado tanto, como el Cascada (In- etapa (caso de Modelo Cascada Realimentado) o puede
cremental) o MCP, por lo que no se tiene bien medida su hacerse parcialmente para luego retomarla (caso Modelo
ecacia, es un paradigma relativamente nuevo y difcil de Iterativo Incremental u otros de carcter evolutivo).
implementar y controlar.
En simple palabras y bsicamente, durante esta fase, se
adquieren, renen y especican las caractersticas funcionales y no funcionales que deber cumplir el futuro
Modelo espiral Win & Win Una variante interesan- programa o sistema a desarrollar.
te del Modelo Espiral previamente visto (Figura 6) es el
Modelo espiral Win-Win[7] (Barry Boehm). El Mode- Las bondades de las caractersticas, tanto del sistema o
lo Espiral previo (clsico) sugiere la comunicacin con programa a desarrollar, como de su entorno, parmetros
el cliente para jar los requisitos, en que simplemente se no funcionales y arquitectura dependen enormemente de
pregunta al cliente qu necesita y l proporciona la infor- lo bien lograda que est esta etapa. Esta es, probablemenmacin para continuar; pero esto es en un contexto ideal te, la de mayor importancia y una de las fases ms difcique rara vez ocurre. Normalmente cliente y desarrolla- les de lograr certeramente, pues no es automatizable, no
dor entran en una negociacin, se negocia coste frente a es muy tcnica y depende en gran medida de la habilidad
y experiencia del analista que la realice.
funcionalidad, rendimiento, calidad, etc.
Es as que la obtencin de requisitos requiere una nego- Involucra fuertemente al usuario o cliente del sistema, por
tanto tiene matices muy subjetivos y es difcil de modelar
ciacin, que tiene xito cuando ambas partes ganan.
con certeza o aplicar una tcnica que sea la ms cercaLas mejores negociaciones se fuerzan en obtener Vic- na a la adecuada (de hecho no existe la estrictamente
toria & Victoria (Win & Win), es decir que el cliente adecuada). Si bien se han ideado varias metodologas,
gane obteniendo el producto que lo satisfaga, y el desa- incluso software de apoyo, para captura, elicitacin y rerrollador tambin gane consiguiendo presupuesto y fecha gistro de requisitos, no existe una forma infalible o abde entrega realista. Evidentemente, este modelo requiere solutamente conable, y deben aplicarse conjuntamente
fuertes habilidades de negociacin.
buenos criterios y mucho sentido comn por parte del o
El modelo Win-Win dene un conjunto de actividades los analistas encargados de la tarea; es fundamental tamde negociacin al principio de cada paso alrededor de la bin lograr una uida y adecuada comunicacin y comprensin con el usuario nal o cliente del sistema.
espiral; se denen las siguientes actividades:

4.2

Etapas en el desarrollo del software

El artefacto ms importante resultado de la culminacin siempre debe llegar a conocer la temtica y el problema
de esta etapa es lo que se conoce como especicacin de que resolver, dominarlo, hasta cierto punto, hasta el mrequisitos software o simplemente documento ERS.
bito que el futuro sistema a desarrollar lo abarque. Por
Como se dijo, la habilidad del analista para interactuar ello el analista debe tener alta capacidad para comprencon el cliente es fundamental; lo comn es que el clien- der problemas de muy diversas reas o disciplinas de trate tenga un objetivo general o problema que resolver, no bajo (que no son especcamente suyas); as por ejemplo,
conoce en absoluto el rea (informtica), ni su jerga, ni si el sistema a desarrollar ser para gestionar informacin
siquiera sabe con precisin qu debera hacer el produc- de una aseguradora y sus sucursales remotas, el analista
se debe compenetrar en cmo ella trabaja y maneja su
to software (qu y cuantas funciones) ni, mucho menos,
cmo debe operar. En otros casos menos frecuentes, el informacin, desde niveles muy bajos e incluso llegando
hasta los gerenciales. Dada a gran diversidad de campos a
cliente piensa que sabe precisamente lo que el software
tiene que hacer, y generalmente acierta muy parcialmen- cubrir, los analistas suelen ser asistidos por especialistas,
es decir gente que conoce profundamente el rea para la
te, pero su empecinamiento entorpece la tarea de elicitacin. El analista debe tener la capacidad para lidiar con cual se desarrollar el software; evidentemente una nica
persona (el analista) no puede abarcar tan vasta cantidad
este tipo de problemas, que incluyen relaciones humanas;
tiene que saber ponerse al nivel del usuario para permitir de reas del conocimiento. En empresas grandes de desarrollo de productos software, es comn tener analistas esuna adecuada comunicacin y comprensin.
pecializados en ciertas reas de trabajo.
Escasas son las situaciones en que el cliente sabe con certeza e incluso con completitud lo que requiere de su futuro Contrariamente, no es problema del cliente, es decir l
no tiene por qu saber nada de software, ni de diseos,
sistema, este es el caso ms sencillo para el analista.
ni otras cosas relacionadas; slo se debe limitar a aportar
Las tareas relativas a captura, elicitacin, modelado y re- objetivos, datos e informacin (de mano propia o de sus
gistro de requisitos, adems de ser sumamente importan- registros, equipos, empleados, etc) al analista, y guiado
te, puede llegar a ser dicultosa de lograr acertadamente por l, para que, en primera instancia, dena el Universo
y llevar bastante tiempo relativo al proceso total del desa- de Discurso, y con posterior trabajo logre confeccionar
rrollo; al proceso y metodologas para llevar a cabo este el adecuado documento ERS.
conjunto de actividades normalmente se las asume parte
propia de la Ingeniera de Software, pero dada la antedi- Es bien conocida la presin que sufren los desarrolladores
de sistemas informticos para comprender y rescatar las
cha complejidad, actualmente se habla de una Ingeniera
de requisitos[12] , aunque ella an no existe formalmente. necesidades de los clientes/usuarios. Cuanto ms complejo es el contexto del problema ms difcil es lograrlo, a
Hay grupos de estudio e investigacin, en todo el mun- veces se fuerza a los desarrolladores a tener que converdo, que estn exclusivamente abocados a idear modelos, tirse en casi expertos de los dominios que analizan.
tcnicas y procesos para intentar lograr la correcta captues muy probable que se genere un
ra, anlisis y registro de requisitos. Estos grupos son los Cuando esto no sucede[13]
conjunto
de
requisitos
errneos o incompletos y por
que normalmente hablan de la Ingeniera de requisitos;
lo
tanto
un
producto
de
software
con alto grado de deses decir se plantea sta como un rea o disciplina pero no
aprobacin
por
parte
de
los
clientes/usuarios
y un altsicomo una carrera universitaria en si misma.
mo costo de reingeniera y mantenimiento. Todo aqueAlgunos requisitos no necesitan la presencia del cliente, llo que no se detecte, o resulte mal entendido en la etapa
para ser capturados o analizados; en ciertos casos los pue- inicial provocar un fuerte impacto negativo en los requide proponer el mismo analista o, incluso, adoptar uni- sitos, propagando esta corriente degradante a lo largo de
lateralmente decisiones que considera adecuadas (tanto todo el proceso de desarrollo e incrementando su perjuien requisitos funcionales como no funcionales). Por citar cio cuanto ms tarda sea su deteccin (Bell y Thayer
ejemplos probables: Algunos requisitos sobre la arquitec- 1976)(Davis 1993).
tura del sistema, requisitos no funcionales tales como los
relativos al rendimiento, nivel de soporte a errores operativos, plataformas de desarrollo, relaciones internas o
ligas entre la informacin (entre registros o tablas de da- Procesos, modelado y formas de elicitacin de requitos) a almacenar en caso de bases o bancos de datos, etc. sitos Siendo que la captura, elicitacin y especicacin
Algunos funcionales tales como opciones secundarias o de requisitos, es una parte crucial en el proceso de desade soporte necesarias para una mejor o ms sencilla ope- rrollo de software, ya que de esta etapa depende el logro
ratividad; etc.
de los objetivos nales previstos, se han ideado modelos
La obtencin de especicaciones a partir del cliente (u y diversas metodologas de trabajo para estos nes. Tamotros actores intervinientes) es un proceso humano muy bin existen herramientas software que apoyan las tareas
interactivo e iterativo; normalmente a medida que se cap- relativas realizadas por el ingeniero en requisitos.
tura la informacin, se la analiza y realimenta con el clien- El estndar IEEE 830-1998 brinda una normalizacin de
te, renndola, pulindola y corrigiendo si es necesario; las Prcticas Recomendadas para la Especicacin de
cualquiera sea el mtodo de ERS utilizado. EL analista Requisitos Software.[14]

10

PROCESO DE CREACIN DEL SOFTWARE

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 Especicacin de Requisitos Software, cuya estructura puede venir denida por varios estndares, tales
como CMMI.

En la Figura 7 se muestra un esquema, ms o menos riguroso, aunque no detallado, de los pasos y tareas a seguir
para realizar la captura, anlisis y especicacin de requisitos software. Tambin all se observa qu artefacto
o documento se obtiene en cada etapa del proceso. En el
diagrama no se explicita metodologa o modelo a utilizar,
Un primer paso para realizar el relevamiento de informa- sencillamente se pautan las tareas que deben cumplirse,
cin es el conocimiento y denicin acertada lo que se de alguna manera.
conoce como Universo de Discurso del problema, que
se dene y entiende por:
Universo de Discurso (UdeD): es el contexto general en
el cual el software deber ser desarrollado y deber operar. El UdeD incluye todas las fuentes de informacin y
todas las personas relacionadas con el software. Esas personas son conocidas tambin como actores de ese universo. El UdeD es la realidad circunstanciada por el conjunto
de objetivos denidos por quienes demandaron el software.
A partir de la extraccin y anlisis de informacin en su Figura 7: Diagrama de tareas para captura y anlisis de requimbito se obtienen todas las especicaciones necesarias sitos.
y tipos de requisitos para el futuro producto software.
Una posible lista, general y ordenada, de tareas recomenEl objetivo de la Ingeniera de requisitos (IR) es sistedadas para obtener la denicin de lo que se debe realimatizar el proceso de denicin de requisitos permitienzar, los productos a obtener y las tcnicas a emplear dudo elicitar, modelar y analizar el problema, generando un
rante la actividad de elicitacin de requisitos, en fase de
compromiso entre los ingenieros de requisitos y los clienEspecicacin de Requisitos Software es:
tes/usuarios, ya que ambos participan en la generacin y
denicin de los requisitos del sistema. La IR aporta un
1. Obtener informacin sobre el dominio del problema
conjunto de mtodos, tcnicas y herramientas que asisten
y el sistema actual (UdeD).
a los ingenieros de requisitos (analistas) para obtener re2. Preparar y realizar las reuniones para elicitaquisitos lo ms seguros, veraces, completos y oportunos
cin/negociacin.
posibles, permitiendo bsicamente:
Comprender el problema
Facilitar la obtencin de las necesidades del cliente/usuario
Validar con el cliente/usuario
Garantizar las especicaciones de requisitos

3. Identicar/revisar los objetivos del usuario.

4. Identicar/revisar los objetivos del sistema.
5. Identicar/revisar los requisitos de informacin.
6. Identicar/revisar los requisitos funcionales.
7. Identicar/revisar los requisitos no funcionales.
8. Priorizar objetivos y requisitos.

Si bien existen diversas formas, modelos y metodologas Algunos principios bsicos a tener en cuenta:
para elicitar, denir y documentar requisitos, no se pue Presentar y entender cabalmente el dominio de la
de decir que alguna de ellas sea mejor o peor que la otra,
informacin del problema.
suelen tener muchsimo en comn, y todas cumplen el
mismo objetivo. Sin embargo, lo que si se puede decir
Denir correctamente las funciones que debe realisin dudas es que es indispensable utilizar alguna de ellas
zar el Software.
para documentar las especicaciones del futuro producto
Representar el comportamiento del software a consoftware. As por ejemplo, hay un grupo de investigacin
secuencias de acontecimientos externos, particulaargentino que desde hace varios aos ha propuesto y esres, incluso inesperados.
tudia el uso del LEL (Lxico Extendido del Lenguaje) y
Escenarios como metodologa, aqu[15] se presenta una de
Reconocer requisitos incompletos, ambiguos o conlas tantas referencias y bibliografa sobre ello. Otra fortradictorios.
ma, ms ortodoxa, de capturar y documentar requisitos
Dividir claramente los modelos que representan la
se puede obtener en detalle, por ejemplo, en el trabajo
informacin, las funciones y comportamiento y cade la Universidad de Sevilla sobre Metodologa para el
ractersticas no funcionales.
Anlisis de Requisitos de Sistemas Software.[16]

4.2

Etapas en el desarrollo del software

Clasicacin e identicacin de requisitos

den identicar dos formas de requisitos:

11
Se pue-

Requisitos externos. Se derivan de factores externos

al sistema y al proceso de desarrollo (Ej. requisitos
legislativos, ticos, etc.)

Requisitos de usuario: Los requisitos de usuario son

Requisitos del dominio.
frases en lenguaje natural junto a diagramas con los
servicios que el sistema debe proporcionar, as coLos requisitos del dominio se derivan del dominio de la
mo las restricciones bajo las que debe operar.
aplicacin y reejan caractersticas de dicho dominio.
Requisitos de sistema: Los requisitos de sistema determinan los servicios del sistema y pero con las Pueden ser funcionales o no funcionales.
restricciones en detalle. Sirven como contrato.
Ej. El sistema de biblioteca de la Universidad debe ser
capaz de exportar datos mediante el Lenguaje de InterEs decir, ambos son lo mismo, pero con distinto nivel de comunicacin de Bibliotecas de Espaa (LIBE). Ej. El
sistema de biblioteca no podr acceder a bibliotecas con
detalle.
material censurado.
Ejemplo de requisito de usuario: El sistema debe hacer
prstamos Ejemplo de requisito de sistema: Funcin prstamo: entrada cdigo socio, cdigo ejemplar; salida: fe- 4.2.2 Diseo del sistema
cha devolucin; etc.
En ingeniera de software, el diseo es una fase de ciclo
Se clasican en tres los tipos de requisitos de sistema:
de vida del software. Se basa en la especicacin de requisitos producido por el anlisis de los requisitos (fase de
Requisitos funcionales
anlisis), el diseo dene cmo estos requisitos se cumplirn, la estructura que debe darse al sistema de software
Los requisitos funcionales describen:
para que se haga realidad.
El diseo sigue siendo una fase separada del la programa Los servicios que proporciona el sistema (funcio- cin o codicacin, esta ltima corresponde a la traducnes).
cin en un determinado lenguaje de programacin de las
La respuesta del sistema ante determinadas entradas. premisas adoptadas en el diseo.
Las distinciones entre las actividades mencionadas has El comportamiento del sistema en situaciones partita ahora no siempre son claras cmo se quisiera en las
culares.
teoras clsicas de ingeniera de software. El diseo, en
particular, puede describir el funcionamiento interno de
Requisitos no funcionales
un sistema en diferentes niveles de detalle, cada una de
ellos se coloca en una posicin intermedia entre el anlisis
Los requisitos no funcionales son restricciones de los ser- y codicacin.
vicios o funciones que ofrece el sistema (ej. cotas de tiemNormalmente se entiende por diseo de la arquitectura
po, proceso de desarrollo, rendimiento, etc.)
al diseo de muy alto nivel, que slo dene la estructura
del sistema en trminos de la mdulos de software de que
Ejemplo 1. La biblioteca Central
se compone y las relaciones macroscpicas entre ellos. A
debe ser capaz de atender simulteste nivel de diseo pertenecen frmulas como clienteneamente a todas las bibliotecas de
servidor o tres niveles, o, ms generalmente, las decila Universidad
siones sobre el uso de la arquitectura de hardware especial
Ejemplo 2. El tiempo de respuesta
que se utilice, el sistema operativo, DBMS, Protocolos de
a una consulta remota no debe ser
red, etc.
superior a 1/2 s
Un nivel intermedio de detalle puede denir la descomposicin del sistema en mdulos, pero esta vez con una
A su vez, hay tres tipos de requisitos no funcioreferencia ms o menos explcita al modo de descomponales:
sicin que ofrece el particular lenguaje de programacin
con el que el desarrollo se va a implementar, por ejem Requisitos del producto. Especican el comporta- plo, en un diseo realizado con la tecnologa de objetos, el
miento del producto (Ej. prestaciones, memoria, ta- proyecto podra describir al sistema en trminos de clases
sa de fallos, etc.)
y sus interrelaciones.
Requisitos organizativos. Se derivan de las polticas
y procedimientos de las organizaciones de los clientes y desarrolladores (Ej. estndares de proceso, lenguajes de programacin, etc.)

El diseo detallado, por ltimo, es una descripcin del

sistema muy cercana a la codicacin (por ejemplo, describir no slo las clases en abstracto, sino tambin sus
atributos y los mtodos con sus tipos).

12

Debido a la naturaleza intangible del software, y dependiendo de las herramientas que se utilizan en el proceso,
la frontera entre el diseo y la codicacin tambin puede ser virtualmente imposible de identicar. Por ejemplo,
algunas herramientas CASE son capaces de generar cdigo a partir de diagramas UML, los que describen grcamente la estructura de un sistema software.
4.2.3

Codicacin del software

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 fase anterior. Esta
tarea la realiza el programador, siguiendo por completo
los lineamientos impuestos en el diseo y en consideracin siempre a los requisitos funcionales y no funcionales
(ERS) especicados en la primera etapa.
Es comn pensar que la etapa de programacin o codicacin (algunos la llaman implementacin) es la que 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 pueden llevar bastante
ms tiempo. Se suele hacer estimaciones de un 30% del
tiempo total insumido en la programacin, pero esta cifra no es consistente ya que depende en gran medida de
las caractersticas del sistema, su criticidad y el lenguaje
de programacin elegido.[7] En tanto menor es el nivel del
lenguaje mayor ser el tiempo de programacin requerido, as por ejemplo se tardara ms tiempo en codicar
un algoritmo en lenguaje ensamblador que el mismo programado en lenguaje C.
Mientras se programa la aplicacin, sistema, o software
en general, se realizan tambin tareas de depuracin, esto
es la labor de ir liberando al cdigo de los errores factibles de ser hallados en esta fase (de semntica, sintctica
y lgica). Hay una suerte de solapamiento con la fase siguiente, ya que para depurar la lgica es necesario realizar pruebas unitarias, normalmente con datos de prueba;
claro es que no todos los errores sern encontrados slo en la etapa de programacin, habrn otros que se encontrarn durante las etapas subsiguientes. La aparicin
de algn error funcional (mala respuesta a los requisitos)
eventualmente puede llevar a retornar a la fase de diseo
antes de continuar la codicacin.
Durante la fase de programacin, el cdigo puede adoptar
varios estados, dependiendo de la forma de trabajo y del
lenguaje elegido, a saber:
Cdigo fuente: es el escrito directamente por los
programadores en editores de texto, lo cual genera el
programa. Contiene el conjunto de instrucciones codicadas en algn lenguaje de alto nivel. Puede estar
distribuido en paquetes, procedimientos, bibliotecas
fuente, etc.

PROCESO DE CREACIN DEL SOFTWARE

Cdigo objeto: es el cdigo binario o intermedio resultante de procesar con un compilador el cdigo
fuente. Consiste en una traduccin completa y de
una sola vez de ste ltimo. El cdigo objeto no es
inteligible por el ser humano (normalmente es formato binario) pero tampoco es directamente ejecutable por la computadora. Se trata de una representacin intermedia entre el cdigo fuente y el cdigo ejecutable, a los nes de un enlace nal con las
rutinas de biblioteca y entre procedimientos o 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 compilador puro, depende de la versin utilizada)].
El cdigo objeto no existe 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 ujo del programa), en tiempo de ejecucin. En este caso tampoco existe el o los archivos de cdigo
ejecutable. Una desventaja de esta modalidad
es que la ejecucin del programa o sistema es
un poco ms lenta que si se hiciera con un intrprete intermedio, y bastante ms lenta que
si existe el o los archivos de cdigo ejecutable.
Es decir no favorece el rendimiento en velocidad de ejecucin. Pero una gran ventaja de la
modalidad intrprete puro, es que el esta 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 para obtener el cdigo ejecutable completo, con lo cual
se agiliza la depuracin y la velocidad de ejecucin se optimiza.
Cdigo ejecutable: Es el cdigo binario resultado de
enlazar uno o ms fragmentos de cdigo objeto con
las rutinas y bibliotecas necesarias. Constituye uno
o ms archivos binarios con un formato tal que el
sistema operativo es capaz de cargarlo en la memoria RAM (eventualmente tambin parte en una
memoria virtual), y proceder a su ejecucin directa.
Por lo anterior se dice que el cdigo ejecutable es
directamente inteligible por la computadora. El
cdigo ejecutable, tambin conocido como cdigo
mquina, no existe si se programa con modalidad
de intrprete puro.

4.2
4.2.4

Etapas en el desarrollo del software

Pruebas (unitarias y de integracin)

Entre las diversas pruebas que se le efectan al software

se pueden distinguir principalmente:

13
La instalacin, dependiendo del sistema desarrollado,
puede consistir en una simple copia al disco rgido destino (casos raros actualmente); o bien, ms comnmente, con una de complejidad intermedia en la que los distintos archivos componentes del software (ejecutables,
bibliotecas, datos propios, etc.) son descomprimidos y
copiados a lugares especcos preestablecidos del disco;
incluso se crean vnculos con otros productos, adems del
propio sistema operativo. Este ltimo caso, comnmente
es un proceso bastante automtico que es creado y guiado con heramientas software especcas (empaquetado y
distribucin, instaladores).

Prueba unitarias: Consisten en probar o testear piezas de software pequeas; a nivel de secciones, procedimientos, funciones y mdulos; aquellas que tengan funcionalidades especcas. Dichas pruebas se
utilizan para asegurar el correcto funcionamiento de
secciones de cdigo, mucho ms reducidas que el
conjunto, y que tienen funciones concretas con cierEn productos de mayor complejidad, la segunda alternato grado de independencia.
tiva es la utilizada, pero es realizada o guiada por espe Pruebas de integracin: Se realizan una vez que las cialistas; puede incluso requerirse la instalacin en varios
pruebas unitarias fueron concluidas exitosamente; y distintos computadores (instalacin distribuida).
con stas se intenta asegurar que el sistema comple- Tambin, en software de mediana y alta complejidad norto, incluso los subsistemas que componen las piezas malmente es requerido un proceso de conguracin y
individuales grandes del software funcionen correc- chequeo, por el cual se asignan adecuados parmetros de
tamente al operar e inteoperar en conjunto.
funcionamiento y se testea la operatividad funcional del
producto.
Las pruebas normalmente se efectan con los llamados
datos de prueba, que es un conjunto seleccionado de datos tpicos a los que puede verse sometido el sistema, los
mdulos o los bloques de cdigo. Tambin se escogen:
Datos que llevan a condiciones lmites al software a n
de probar su tolerancia y robustez; datos de utilidad para mediciones de rendimiento; datos que provocan condiciones eventuales o particulares poco comunes y a las que
el software normalmente no estar sometido pero pueden
ocurrir; etc. Los datos de prueba no necesariamente
son cticios o creados, pero normalmente s lo son los
de poca probabilidad de ocurrencia.

En productos de venta masiva las instalaciones completas, si son relativamente simples, suelen ser realizadas por
los propios usuarios nales (tales como sistemas operativos, paquetes de ocina, utilitarios, etc.) con herramientas propias de instalacin guiada; incluso la conguracin
suele ser automtica. En productos de diseo especco o
a medida la instalacin queda restringida, normalmente, a personas especialistas involucradas en el desarrollo
del software en cuestin.

La instalacin del software es el proceso por el cual los

programas desarrollados son transferidos apropiadamente al computador destino, inicializados, y, eventualmente,
congurados; todo ello con el propsito de ser ya utilizados por el usuario nal. Constituye la etapa nal en el
desarrollo propiamente dicho del software. Luego de sta
el producto entrar en la fase de funcionamiento y produccin, para el que fuera diseado.

De un buen diseo y documentacin del desarrollo depender cmo ser la fase de mantenimiento, tanto en
costo temporal como monetario. Modicaciones 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 software desde el
inicio. Por ello, es de fundamental importancia respetar
debidamente todas las tareas de las fases del desarrollo y

Una vez realizada exitosamente la instalacin del software, el mismo pasa a la fase de produccin (operatividad),
durante la cual cumple las funciones para las que fue desaGeneralmente, existe un fase probatoria nal y completa rrollado, es decir, es nalmente utilizado por el (o los)
del software, llamada Beta Test, durante la cual el sis- usuario nal, produciendo los resultados esperados.
tema instalado en condiciones normales de operacin y
trabajo es probado exhaustivamente a n de encontrar
errores, inestabilidades, respuestas errneas, etc. que ha4.2.6 Mantenimiento
yan pasado los previos controles. Estas son normalmente
realizadas por personal idneo contratado o afectado especcamente a ello. Los posibles errores encontrados se El mantenimiento de software es el proceso de control,
transmiten a los desarrolladores para su depuracin. En mejora y optimizacin del software ya desarrollado e insel caso de software de desarrollo a pedido, el usuario talado, que tambin incluye depuracin de errores y denal (cliente) es el que realiza el Beta Test, teniendo para fectos que puedan haberse ltrado de la fase de pruebas
de control y beta test. Esta fase es la ltima (antes de iteello un perodo de prueba pactado con el desarrollador.
rar, segn el modelo empleado) que se aplica al ciclo de
vida del desarrollo de software. La fase de mantenimiento
es la que viene despus de que el software est operativo
4.2.5 Instalacin y paso a produccin
y en produccin.

14

5 CARCTER EVOLUTIVO DEL SOFTWARE

mantener adecuada y completa la documentacin.

El software evoluciona sencillamente por que se debe

El perodo de la fase de mantenimiento es normalmente adaptar a los cambios del entorno, sean funcionales (exiel mayor en todo el ciclo de vida.[7] Esta fase involucra gencias de usuarios), operativos, de plataforma o arquitambin actualizaciones y evoluciones del software; no tectura hardware.
necesariamente implica que el sistema tuvo errores. Uno La dinmica de evolucin del software es el estudio de
o ms cambios en el software, por ejemplo de adaptacin los cambios del sistema. La mayor contribucin en eso evolutivos, puede llevar incluso a rever y adaptar desde ta rea fue realizada por Meir M. Lehman y Belady, coparte de las primeras fases del desarrollo inicial, alterando menzando en los aos 70 y 80. Su trabajo continu en la
todas las dems; dependiendo de cun profundos sean los dcada de 1990, con Lehman y otros investigadores[18] de
cambios. El modelo cascada comn es particularmente relevancia en la realimentacin en los procesos de evolucostoso en mantenimiento, ya que su rigidez implica que cin (Lehman, 1996; Lehman et al., 1998; lehman et al.,
cualquier cambio provoca regreso a fase inicial y fuertes 2001). A partir de esos estudios propusieron un conjunalteraciones en las dems fases del ciclo de vida.
to de leyes (conocidas como leyes de Lehman)[9] respecDurante el perodo de mantenimiento, es comn que sur- to de los cambios producidos en los sistemas. Estas leyes
jan nuevas revisiones y versiones del producto; que lo li- (en realidad son hiptesis) son invariantes y ampliamente
beran ms depurado, con mayor y mejor funcionalidad, aplicables.
mejor rendimiento, etc. Varias son las facetas que pue- Lehman y Belady analizaron el crecimiento y la evoluden ser alteradas para provocar cambios deseables, evo- cin de varios sistemas software de gran porte; derivando
lutivos, adaptaciones o ampliaciones y mejoras.
nalmente, segn sus medidas, las siguientes ocho leyes:
Bsicamente se tienen los siguientes tipos de cambios:
Perfectivos: Aquellos que llevan a una mejora de
la calidad interna del software en cualquier aspecto: Reestructuracin del cdigo, denicin ms clara del sistema y su documentacin; optimizacin del
rendimiento y eciencia.
Evolutivos: Agregados, modicaciones, incluso eliminaciones, necesarias en el software para cubrir su
expansin o cambio, segn las necesidades del usuario.
Adaptivos: Modicaciones que afectan a los entornos en los que el sistema opera, tales como: Cambios
de conguracin del hardware (por actualizacin o
mejora de componentes electrnicos), cambios en
el software de base, en gestores de base de datos, en
comunicaciones, etc.
Correctivos: Alteraciones necesarias para corregir
errores de cualquier tipo en el producto software
desarrollado.

Carcter evolutivo del software

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, adecuadas a nuevas plataformas
(sean de hardware o sistemas operativos), etc.[17]
Cuando un sistema deja de evolucionar, eventualmente
cumplir con su ciclo de vida, entrar en obsolescencia e
inevitablemente, tarde o temprano, ser reemplazado por
un producto nuevo.

1. Cambio continuo: Un programa que se usa en un entorno real necesariamente debe cambiar o se volver
progresivamente menos til en ese entorno.
2. Complejidad creciente: A medida que un programa
en evolucin cambia, su estructura tiende a ser cada
vez ms compleja. Se deben dedicar recursos extras
para preservar y simplicar la estrucutura.
3. Evolucin prolongada del programa: La evolucin
de los programas es un proceso autorregulativo. Los
atributos de los sistemas, tales como tamao, tiempo
entre entregas y la cantidad de errores documentados son aproximadamente invariantes para cada entrega del sistema.
4. Estabilidad organizacional: Durante el tiempo de vida de un programa, su velocidad de desarrollo es
aproximadamente constante e independiente de los
recursos dedicados al desarrollo del sistema.
5. Conservacin de la familiaridad: Durante el tiempo
de vida de un sistema, el cambio incremental en cada
entrega es aproximadamente constante.
6. Crecimiento continuado: La funcionalidad ofrecida
por los sistemas tiene que crecer continuamente para
mantener la satisfaccin de los usuarios.
7. Decremento de la calidad: La calidad de los sistemas
software comenzar a disminuir a menos que dichos
sistemas se adapten a los cambios de su entorno de
funcionamiento.
8. Realimentacin del sistema: Los procesos de evolucin incorporan sistemas de realimentacin multiagente y multibucle y estos deben ser tratados como
sistemas de realimentacin para lograr una mejora
signicativa del producto.

15

Referencias

[1] Diccionario de la lengua espaola 2005 (2010). wordreference.com, ed. software (diccionario). Espasa-Calpe.
Consultado el 1 de febrero de 2010.
[2] Real Academia Espaola. Signicado de la palabra Software. Diccionario de la Lengua Espaola, XXII Edicin.
Consultado el 14 de marzo de 2008.
[3] Real Academia Espaola. Uso de la palabra Software.
Diccionario panhispnico de dudas, 1. Edicin (octubre
2005). Consultado el 8 de febrero de 2009.
[4] Pressman, Roger S. (2003). El producto. Ingeniera del
Software, un enfoque Prctico, Quinta edicin edicin. Mxico: Mc Graw Hill.
[5] IEEE Std, IEEE Software Engineering Standard: Glossary
of Software Engineering Terminology. IEEE Computer
Society Press, 1993
[6] Ciclo de Vida del Software. Grupo Alarcos - Escuela
Superior de Informtica de Ciudad Real.
[7] Pressman, Roger S. (2003). El proceso. Ingeniera del
Software, un enfoque Prctico, Quinta edicin edicin. Mxico: Mc Graw Hill.
[8] Trmino Elicitar". 1ra. acepcin - Wiktionary. Consultado el 15 de diciembre de 2008.
[9] Leyes de evolucin del Software. Connexions - Educational content repository.
[10] Ciclo de vida del Software y Modelos de desarrollo. Instituto de Formacin Profesional - Libros Digitales. Texto
lugar: Asuncin del Paraguay ignorado (ayuda)
[11] Evolucin del Software. Connexions - Educational content repository.
[12] Software Requirements Engineering, 2nd Edition, IEEE
Computer Society. Los Alamitos, CA, 1997 (Compendio
de papers y artculos en ingeniera de requisitos)
[13] III Workshop de Engenharia de Requisitos. WER 2000,
Ro de Janeiro, 2000.
[14] Recommended Practice for Software Requirements
Specication. IEEE-SA Standards Board.
[15] LEL y Escenarios como metodologa en Ingeniera de
Requisitos. Univ. de Morn, Buenos Aires.

7 Bibliografa
7.1 Libros
JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James (2000). El Proceso Unicado de
Desarrollo de Software. Pearson Addisson-Wesley.
Pressman, Roger S. (2003). Ingeniera del Software,
un enfoque Prctico (Quinta edicin edicin). Mc
Graw Hill. ISBN 84-481-3214-9.
JACOBSON; BOOCH; RUMBAUGH (1999).
UML - El Lenguaje Unicado de Modelado.
Pearson Addisson-Wesley. Rational Software Corporation, Addison Wesley Iberoamericana. ISBN
84-7829-028-1.
Haeberer, A. M.; P. A. S. Veloso, G. Baum (1988).
Formalizacin del proceso de desarrollo de software
(Ed. preliminar edicin). Buenos Aires: Kapelusz.
ISBN 950-13-9880-3.
Fowler, Martin; Kendall Sccott (1999). UML Gota a
Gota. Addison Wesley. ISBN 9789684443648.
Loucopoulos, Pericles; Karakostas, V. (1995). System Requirements Engineering (en ingls). London:
McGraw-Hill Companies. pp. 160 p. ISBN 9780077078430.
Sommerville, Ian; P. Sawyer (1997). Requirements
Engineering: A Good Practice Guide (en ingls) (1ra.
edition edicin). Wiley & Sons. pp. 404 p. ISBN 9780471974444.
Gottesdiener, Ellen; P. Sawyer (2002). Requirements by Collaboration: Workshops for Dening
Needs (en ingls). Addison-Wesley Professional. pp.
368 p. ISBN 978-0201786064.
Sommerville, Ian (2005). Ingeniera del software
(7ma. edicin). Madrid: Pearson Educacin S.A.
ISBN 84-7829-074-5.

7.2 Artculos y revistas

[16] Metodologa para el anlisis de Requisitos de Sistemas

Software. Univ. de Sevilla, 2001.

Weitzenfeld - El Proceso para Desarrollo de Software - 2002

[17] Sommerville, Ian (2005). 21-Evolucin del software.

Ingeniera del Software. Espaa: Pearson Educacin S.A.

Carlos Reynoso - Mtodos Heterodoxos en Desarrollo de Software - 2004

[18] ACM Fellow Prole for Meir M. (Manny) Lehman.

ACM. 31 de mayo de 2007. Consultado el 27 de noviembre de 2011.

Grupo ISSI - Univ. Politcnica de Valencia - Metodologas giles en el Desarrollo de Software 2003

16

Martin Fowler - La Nueva Metodologa - 2003

Cutter IT Journal Requirements Engineering and
Management. August 25, 2000. Cutter Consortium.
Software Requirements Engineering, 2nd Edition, IEEE Computer Society. Los Alamitos, CA,
1997 (Compendio de papers y artculos en ingeniera de requisitos).
Lehman, M.M. - Laws of Software Evolution Revisited, pos. pap., EWSPT96, Oct. 1996, LNCS
1149, Springer Verlag, 1997, pp. 108-124

Vase tambin

Portal:Software. Contenido relacionado con

Software.

Ingeniera de software
Programa informtico
Aplicacin informtica
Programacin
Fases del desarrollo de software
Software colaborativo
Software libre
Ingeniera informtica
Hediondez del cdigo

8.1

Modelos de ciclo de vida

Modelo en cascada o secuencial

Modelo iterativo incremental
Modelo evolutivo espiral
Modelo de prototipos
Modelo de desarrollo rpido

Enlaces externos

Wikimedia Commons alberga contenido multimedia sobre SoftwareCommons.

Wikcionario tiene deniciones y otra informacin sobre software.Wikcionario

ENLACES EXTERNOS

17

10
10.1

Origen del texto y las imgenes, colaboradores y licencias

Texto

Software Fuente: https://es.wikipedia.org/wiki/Software?oldid=85697056 Colaboradores: Youssefsan, Macar~eswiki, Mac, Oblongo, Sabbut, Sauron, JorgeGG, Pieter, Lourdes Cardenal, Julie, Angus, Rumpelstiltskin, Comae, Aloriel, Dodo, Ejmeza, Faustito, Ejrrjs, Jynus,
SimnK, Rsg, Tostadora, Tano4595, Yakoo, PeiT, Dianai, Loco085, Robotico, Balderai, DamianFinol, Elsenyor, FAR, Digigalos, Alexan,
Boticario, Soulreaper, Orgullomoore, Javierchiclana, Hispa, Airunp, JMPerez, Edub, Yrithinnd, Taichi, Gussisaurio, Magister Mathematicae, Dem, Kokoo, Viko~eswiki, Platonides, Alhen, Superzerocool, Neok deck, Yrbot, Seanver, BOT-Superzerocool, Oscar ., Vitamine,
.Sergio, Mortadelo2005, Gaeddal, Museo8bits, Icvav, GermanX, Ferbr1, Equi, Unaiaia, Beto29, Robespierre, Lobillo, Gaijin, Davidam,
Carutsu, Eloy, Santiperez, FedericoMP, Sonia Rod, Bichologo, Baneld, Muramasa, Kepler Oort, Maldoror, Tabeissan, Er Komandante, Ciencia Al Poder, Cheveri, Arturus, Chlewbot, Tomatejc, Jarke, Filipo, Siabef, Folkvanger, Carlosblh, The worst user, Garygillmore,
Paintman, Jorgechp, Dropzink, BOTpolicia, Qwertyytrewqqwerty, JEDIKNIGHT1970, CEM-bot, Jorgelrm, Ebnz~eswiki, Gabriel Acquistapace, Renebeto, -jem-, Alexav8, X.Cyclop, Durero, Jjvaca, Retama, Baiji, Acastro, Eamezaga, Rastrojo, Rosarinagazo, Antur, Jjafjjaf,
Dorieo, Montgomery, FrancoGG, Ingenioso Hidalgo, Un Mercenario, P.o.l.o., Roberto Fiadone, Diosa, Yeza, RoyFocker, Juan25, Andya, PhJ, Rafadose, Cratn, Isha, Bernard, Chuck es dios, Gusgus, Gngora, Mpeinadopa, Jabrahamdc, JAnDbot, Jugones55, JuanPaBJ16,
VanKleinen, Kved, Mansoncc, Muro de Aguas, Vladimirdlc, Gaius iulius caesar, Iulius1973, Zufs, Gsrdzl, Beaire1, Museobichoxp, CommonsDelinker, TXiKiBoT, Lovecat1024, Izzues, Gustronico, Gacq, Elisardojm, Humberto, Netito777, Jlinfante, Warcraft~eswiki, Xpel1,
ZrzlKing, Amanuense, Chabbot, MotherForker, Idioma-bot, Qoan, Software~eswiki, Plux, Biasoli, Bucephala, Cipin, Cinevoro, Aleja bri3, VolkovBot, Snakeyes, Technopat, Tiernuchin, Queninosta, Libertad y Saber, Dbarbagallo, Matdrodes, Autonomia, Synthebot,
DJ Nietzsche, BlackBeast, Shooke, Goinza, JavierPajon, Lucien leGrey, Luis1970, Muro Bot, Edmenb, MiguelAngel fotografo, Racso,
Adriglezmunera, Mjollnir1984, Gerakibot, SieBot, Mushii, Marcos Germn Guglielmetti, Ctrl Z, PaintBot, Ensada, Yiyi3, Carmin, Villasephiroth, Drinibot, Bigsus-bot, Marcelo, Mel 23, OboeCrack, Abel.orian, Manw, Greek, Lobo, BuenaGente, Mafores, Chico512,
Tirithel, Mutari, Prietoquilmes, Jarisleif, Javierito92, Marcecoro, UsuarioRafaelgarcia, HUB, Nicop, DragonBot, Farisori, EDGARNICE1, McMalamute, Eduardosalg, Paquete, Leonpolanco, Petruss, Walter closser, Poco a poco, BetoCG, CestBOT, Takashi kurita, Paporrubio, Aipni-Lovrij, Kintaro, Osado, Ravave, Jmha1914, SilvonenBot, Camilo, UA31, SergioN, AVBOT, JAQG, DayL6, David0811,
Oliver-INJUD-PETEN, LucienBOT, MastiBot, Adelpine, Cristiangy, MarcoAurelio, CHICHENEITOR, Ezarate, Mayra 7sp, Diegusjaimes, DumZiBoT, MelancholieBot, Laisladelsol, Wikijens, Sdepares, Arjuno3, Saloca, Madalberta, Andreasmperu, Luckas-bot, Dalton2,
Wesker J, Nallimbot, Ptbotgourou, Jotterbot, Cainite, Letuo, Vic Fede, Angelsaracho, Cfga, Dangelin5, Jorge 2701, ANAYSNARK,
Monkey in Your Tank, Nixn, ArthurBot, Ruy Pugliesi, Inventionary, SuperBraulio13, Manuelt15, Xqbot, Jkbw, Dreitmen, Dossier2, Cally
Berry, Savig, Carol1221, Ricardogpn, Kismalac, Igna, Torrente, Botarel, MauritsBot, Panderine!, MAfotBOT, Hprmedina, TobeBot, Caritdf, RedBot, Fidelleandro, DixonDBot, Jesuscc29, Alfredalva, AnselmiJuan, Born2bgratis, TorQue Astur, Emporio2012, KamikazeBot,
Dinamik-bot, Jorge c2010, Wikilptico, Axvolution, Edslov, Franco Slad, EmausBot, Savh, HRoestBot, ChessBOT, Sergio Andres Segovia,
LeafGreen, Iwr, Grillitus, KLBot, Eder589, Rubpe19, MercurioMT, Emiduronte, Jcaraballo, Bpk, Cedecomsa, MadriCR, Waka Waka,
Laurauda, Lauratomsig, Tokvo, Alexander20102010, Arezitopedia, Cesar fuente, Marly yaneth, Antonorsi, Abin, Herny gay, MerlIwBot,
Gara4514, KLBot2, UAwiki, Sebrev, Gins90, Invadibot, Kbronson, DerKrieger, Chico del Pantano, Acratta, Ihernandezsa, Vetranio, Alexanderrojas1, Helmy oved, Makecat-bot, Armonizador, 2rombos, Brianrock97, MaKiNeoH, Neptunia, Legobot, Mininogatito, Lautaro 97,
Jean70000, Addbot, AnonymousCmc, Balles2601, Diegogalicia27, ConnieGB, JacobRodrigues, Anonymus2013, Gazpachero, Monicagdl,
Troloman777, Higuita02, Zzzzzzzz1710, Jarould, Crystallizedcarbon, Sfr570, Aramiza, Analiac03, Andresmoreno234, Rolando Hedeckel,
Carlosebastian y Annimos: 1022

10.2

Imgenes

Archivo:Commons-logo.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/4/4a/Commons-logo.svg Licencia: Public domain Colaboradores: This version created by Pumbaa, using a proper partial circle and SVG geometry features. (Former versions used
to be slightly warped.) Artista original: SVG version was created by User:Grunt and cleaned up by 3247, based on the earlier PNG version,
created by Reidab.
Archivo:Krita2-2alpha1-with-Dungeon-Girl.png
Fuente:
https://upload.wikimedia.org/wikipedia/commons/e/ef/
Krita2-2alpha1-with-Dungeon-Girl.png Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Happy Mr Memebot
Archivo:LibreOffice_Writer_4.0.1.2.png Fuente: https://upload.wikimedia.org/wikipedia/commons/0/07/LibreOffice_Writer_4.0.1.
2.png Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio, The Document Foundation para la imagen del programa, texto y foto
del artculo Nebulosa del Cangrejo de la Wikipedia en espaol Artista original: German
Archivo:ModeloCascadaRealimentado.jpg
Fuente:
https://upload.wikimedia.org/wikipedia/commons/4/4a/
ModeloCascadaRealimentado.jpg Licencia: GFDL Colaboradores: ? Artista original: ?
Archivo:Modelo_Cascada_Secuencial.jpg
Fuente:
https://upload.wikimedia.org/wikipedia/commons/0/01/Modelo_Cascada_
Secuencial.jpg Licencia: CC-BY-SA-3.0 Colaboradores: ? Artista original: ?
Archivo:Modelo_Espiral_Boehm.jpg Fuente: https://upload.wikimedia.org/wikipedia/commons/8/84/Modelo_Espiral_Boehm.jpg Licencia: CC-BY-SA-3.0 Colaboradores: Trabajo propio Artista original: SergioN
Archivo:Modelo_Gral_Evolutivo_Incremental.jpg Fuente: https://upload.wikimedia.org/wikipedia/commons/f/fe/Modelo_Gral_
Evolutivo_Incremental.jpg Licencia: CC-BY-SA-3.0 Colaboradores: Trabajo propio Artista original: SergioN
Archivo:Modelo_Iterativo_Incremental.jpg
Fuente:
https://upload.wikimedia.org/wikipedia/commons/c/c4/Modelo_Iterativo_
Incremental.jpg Licencia: CC BY 3.0 Colaboradores: Trabajo propio Artista original: SergioN
Archivo:Nuvola_devices_cdrom_unmount.png Fuente: https://upload.wikimedia.org/wikipedia/commons/9/9d/Nuvola_devices_
cdrom_unmount.png Licencia: LGPL Colaboradores: http://icon-king.com Artista original: David Vignoni / ICON KING
Archivo:Proceso_Ing_Requisitos.jpg Fuente: https://upload.wikimedia.org/wikipedia/commons/b/bb/Proceso_Ing_Requisitos.jpg Licencia: GFDL Colaboradores: No machine-readable source provided. Own work assumed (based on copyright claims). Artista original: No
machine-readable author provided. SergioN assumed (based on copyright claims).
Archivo:Wiktionary-logo-es.png Fuente: https://upload.wikimedia.org/wikipedia/commons/0/06/Wiktionary-logo-es.png Licencia: CC
BY-SA 3.0 Colaboradores: originally uploaded there by author, self-made by author Artista original: es:Usuario:Pybalo

18

10 ORIGEN DEL TEXTO Y LAS IMGENES, COLABORADORES Y LICENCIAS

10.3

Licencia del contenido

Creative Commons Attribution-Share Alike 3.0