Software

Software El anglicismo software es el más ampliamente difundido

al referirse a este concepto, especialmente en la jerga téc-
nica; en tanto que el término sinónimo «logicial», deriva-
do del término francés logiciel, es utilizado mayormente
en países y zonas de influencia francesa. Su abreviatura
es Sw.

1 Etimología
Software (pronunciación AFI:[ˈsɒftwɛəʳ]) es una palabra
proveniente del inglés, que en español no posee una tra-
ducción adecuada al contexto, por lo cual se la utiliza asi-
duamente sin traducir y así fue admitida por la Real Aca-
demia Española (RAE).[2] Aunque puede no ser estric-
tamente lo mismo, suele sustituirse por expresiones
Dentro tales
de la categoría de software de aplicación están incluidos como programas (informáticos) o aplicaciones (informá-
[3]
los procesadores de texto como LibreOffice Writer ticas) o soportes lógicos.
(arriba) y los editores gráficos rasterizados como Krita Software es lo que se denomina producto en Ingeniería de
(abajo). software.[4]
[1]
Se conoce como software al equipo lógico o soporte

2 Definición de software
Existen varias definiciones similares aceptadas para soft-
ware, pero probablemente la más formal sea la siguiente:

Es el conjunto de los programas de cómpu-

to, procedimientos, reglas, documentación y
datos asociados, que forman parte de las ope-
raciones de un sistema de computación.
Extraído del estándar 729 del IEEE[5]
Buscador de Programas en Ubuntu 13.10

lógico de un sistema informático, que comprende el Considerando esta definición, el concepto de software va
conjunto de los componentes lógicos necesarios que más allá de los programas de computación en sus distin-
hacen posible la realización de tareas específicas, en tos estados: código fuente, binario o ejecutable; también
contraposición a los componentes físicos que son su documentación, los datos a procesar e incluso la in-
llamados hardware. formación de usuario forman parte del software: es decir,
abarca todo lo intangible, todo lo «no físico» relacionado.
Los componentes lógicos incluyen, entre muchos otros,
las aplicaciones informáticas, tales como el procesador de El término «software» fue usado por primera vez en este
texto, que permite al usuario realizar todas las tareas con- sentido por John W. Tukey en 1957. En la ingeniería de
cernientes a la edición de textos; el llamado software de software y las ciencias de la computación, el software es
sistema, tal como el sistema operativo, que básicamente toda la información procesada por los sistemas informá-
permite al resto de los programas funcionar adecuada- ticos: programas y datos.
mente, facilitando también la interacción entre los com- El concepto de leer diferentes secuencias de instrucciones
ponentes físicos y el resto de las aplicaciones, y propor- (programa) desde la memoria de un dispositivo para con-
cionando una interfaz con el usuario. trolar los cálculos fue introducido por Charles Babbage

1
2 4 PROCESO DE CREACIÓN DEL SOFTWARE

como parte de su máquina diferencial. La teoría que for- • Aplicaciones para Control de sistemas y
ma la base de la mayor parte del software moderno fue automatización industrial
propuesta por Alan Turing en su ensayo de 1936, «Los • Aplicaciones ofimáticas
números computables», con una aplicación al problema
de decisión. • Software educativo
• Software empresarial
• Bases de datos
3 Clasificación del software
• Telecomunicaciones (por ejemplo Internet y
toda su estructura lógica)
Si bien esta distinción es, en cierto modo, arbitraria, y a
veces confusa, a los fines prácticos se puede clasificar al • Videojuegos
software en tres grandes tipos: • Software médico
• Software de cálculo numérico y simbólico.
• Software de sistema: Su objetivo es desvincular
adecuadamente al usuario y al programador de los • Software de diseño asistido (CAD)
detalles del sistema informático en particular que • Software de control numérico (CAM)
se use, aislándolo especialmente del procesamien-
to referido a las características internas de: memo-
ria, discos, puertos y dispositivos de comunicacio-
nes, impresoras, pantallas, teclados, etc. El softwa-
4 Proceso de creación del software
re de sistema le procura al usuario y programador
adecuadas interfaces de alto nivel, controladores, Se define como proceso al conjunto ordenado de pasos a
herramientas y utilidades de apoyo que permiten seguir para llegar a la solución de un problema u obten-
el mantenimiento del sistema global. Incluye entre ción de un producto, en este caso particular, para lograr
otros: un producto software que resuelva un problema específi-
co.
• Sistemas operativos
El proceso de creación de software puede llegar a ser muy
• Controladores de dispositivos complejo, dependiendo de su porte, características y cri-
• Herramientas de diagnóstico ticidad del mismo. Por ejemplo la creación de un sistema
• Herramientas de Corrección y Optimización operativo es una tarea que requiere proyecto, gestión, nu-
merosos recursos y todo un equipo disciplinado de traba-
• Servidores
jo. En el otro extremo, si se trata de un sencillo programa
• Utilidades (por ejemplo, la resolución de una ecuación de segundo
• Software de programación: Es el conjunto de he- orden), éste puede ser realizado por un solo programador
rramientas que permiten al programador desarrollar (incluso aficionado) fácilmente. Es así que normalmente
programas informáticos, usando diferentes alterna- se dividen en tres categorías según su tamaño (líneas de
tivas y lenguajes de programación, de una manera código) o costo: de «pequeño», «mediano» y «gran porte».
práctica. Incluyen básicamente: Existen varias metodologías para estimarlo, una de las
más populares es el sistema COCOMO que provee mé-
• Editores de texto todos y un software (programa) que calcula y provee una
• Compiladores aproximación de todos los costos de producción en un
«proyecto software» (relación horas/hombre, costo mo-
• Intérpretes
netario, cantidad de líneas fuente de acuerdo a lenguaje
• Enlazadores usado, etc.).
• Depuradores
Considerando los de gran porte, es necesario realizar
• Entornos de Desarrollo Integrados (IDE): complejas tareas, tanto técnicas como de gerencia, una
Agrupan las anteriores herramientas, usual- fuerte gestión y análisis diversos (entre otras cosas), la
mente en un entorno visual, de forma tal que el complejidad de ello ha llevado a que desarrolle una in-
programador no necesite introducir múltiples geniería específica para tratar su estudio y realización: es
comandos para compilar, interpretar, depurar, conocida como Ingeniería de Software.
etc. Habitualmente cuentan con una avanzada
interfaz gráfica de usuario (GUI). En tanto que en los de mediano porte, pequeños equipos
de trabajo (incluso un avezado analista-programador soli-
• Software de aplicación: Es aquel que permite a los tario) pueden realizar la tarea. Aunque, siempre en casos
usuarios llevar a cabo una o varias tareas específicas, de mediano y gran porte (y a veces también en algunos de
en cualquier campo de actividad susceptible de ser pequeño porte, según su complejidad), se deben seguir
automatizado o asistido, con especial énfasis en los ciertas etapas que son necesarias para la construcción del
negocios. Incluye entre muchos otros: software. Tales etapas, si bien deben existir, son flexibles
4.1 Modelos de proceso o ciclo de vida 3

en su forma de aplicación, de acuerdo a la metodología o • Diseño

proceso de desarrollo escogido y utilizado por el equipo
de desarrollo o por el analista-programador solitario (si • Codificación
fuere el caso). • Pruebas (unitarias y de integración)
Los «procesos de desarrollo de software» poseen re-
• Instalación y paso a producción
glas preestablecidas, y deben ser aplicados en la creación
del software de mediano y gran porte, ya que en caso con- • Mantenimiento
trario lo más seguro es que el proyecto no logre concluir
o termine sin cumplir los objetivos previstos, y con varie-
En las anteriores etapas pueden variar ligeramente sus
dad de fallos inaceptables (fracasan, en pocas palabras).
nombres, o ser más globales, o contrariamente, ser más
Entre tales «procesos» los hay ágiles o livianos (ejemplo
refinadas; por ejemplo indicar como una única fase (a los
XP), pesados y lentos (ejemplo RUP), y variantes inter-
fines documentales e interpretativos) de «análisis y dise-
medias. Normalmente se aplican de acuerdo al tipo y por-
ño»; o indicar como «implementación» lo que está dicho
te del software a desarrollar, a criterio del líder (si lo hay)
como «codificación»; pero en rigor, todas existen e inclu-
del equipo de desarrollo. Algunos de esos procesos son
yen, básicamente, las mismas tareas específicas.
Programación Extrema (en inglés eXtreme Programming
o XP), Proceso Unificado de Rational (en inglés Rational En el apartado 4 del presente artículo se brindan mayores
Unified Process o RUP), Feature Driven Development detalles de cada una de las etapas indicadas.
(FDD), etc.
Cualquiera sea el «proceso» utilizado y aplicado al desa- 4.1 Modelos de proceso o ciclo de vida
rrollo del software (RUP, FDD, XP, etc), y casi indepen-
dientemente de él, siempre se debe aplicar un «modelo Para cada una de las fases o etapas listadas en el ítem an-
de ciclo de vida».[6] terior, existen sub-etapas (o tareas). El modelo de proceso
Se estima que, del total de proyectos software grandes o modelo de ciclo de vida utilizado para el desarrollo, de-
[6]
emprendidos, un 28 % fracasan, un 46 % caen en severas fine el orden de las tareas o actividades involucradas,
modificaciones que lo retrasan y un 26 % son totalmente también define la coordinación entre ellas, y su enlace y
exitosos.[7] realimentación. Entre los más conocidos se puede men-
cionar: modelo en cascada o secuencial, modelo espiral,
Cuando un proyecto fracasa, rara vez es debido a fallas
modelo iterativo incremental. De los antedichos hay a su
técnicas, la principal causa de fallos y fracasos es la fal-
vez algunas variantes o alternativas, más o menos atrac-
ta de aplicación de una buena metodología o proceso de
tivas según sea la aplicación requerida y sus requisitos.[7]
desarrollo. Entre otras, una fuerte tendencia, desde hace
pocas décadas, es mejorar las metodologías o procesos de
desarrollo, o crear nuevas y concientizar a los profesiona- 4.1.1 Modelo cascada
les de la informática a su utilización adecuada. Normal-
mente los especialistas en el estudio y desarrollo de estas Este, aunque es más comúnmente conocido como modelo
áreas (metodologías) y afines (tales como modelos y has- en cascada es también llamado «modelo clásico», «mo-
ta la gestión misma de los proyectos) son los ingenieros delo tradicional» o «modelo lineal secuencial».
en software, es su orientación. Los especialistas en cual-
El modelo en cascada puro difícilmente se utiliza tal cual,
quier otra área de desarrollo informático (analista, pro-
pues esto implicaría un previo y absoluto conocimiento de
gramador, Lic. en informática, ingeniero en informática,
los requisitos, la no volatilidad de los mismos (o rigidez)
ingeniero de sistemas, etc.) normalmente aplican sus co-
y etapas subsiguientes libres de errores; ello sólo podría
nocimientos especializados pero utilizando modelos, pa-
ser aplicable a escasos y pequeños sistemas a desarrollar.
radigmas y procesos ya elaborados.
En estas circunstancias, el paso de una etapa a otra de las
Es común para el desarrollo de software de mediano por- mencionadas sería sin retorno, por ejemplo pasar del di-
te que los equipos humanos involucrados apliquen «me- seño a la codificación implicaría un diseño exacto y sin
todologías propias», normalmente un híbrido de los pro- errores ni probable modificación o evolución: «codifique
cesos anteriores y a veces con criterios propios. lo diseñado sin errores, no habrá en absoluto variantes
El proceso de desarrollo puede involucrar numerosas y futuras». Esto es utópico; ya [9] que intrínsecamente el soft-
[6]
variadas tareas, desde lo administrativo, pasando por ware es de carácter evolutivo, cambiante y difícilmente
lo técnico y hasta la gestión y el gerenciamiento. Pero, libre de errores, tanto durante su desarrollo como durante
[6]
casi rigurosamente, siempre se cumplen ciertas etapas su vida operativa.
mínimas; las que se pueden resumir como sigue: Algún cambio durante la ejecución de una cualquiera de
las etapas en este modelo secuencial implicaría reiniciar
desde el principio todo el ciclo completo, lo cual redun-
• Captura, elicitación[8] , especificación y análisis de daría en altos costos de tiempo y desarrollo. La Figura 2
requisitos (ERS) muestra un posible esquema de el modelo en cuestión.[6]
4 4 PROCESO DE CREACIÓN DEL SOFTWARE

ideal, si el proyecto presenta alta rigidez (pocos cambios,

previsto no evolutivo), los requisitos son muy claros y es-
tán correctamente especificados.[10]
Hay más variantes similares al modelo: refino de etapas
(más etapas, menores y más específicas) o incluso mos-
trar menos etapas de las indicadas, aunque en tal caso la
faltante estará dentro de alguna otra. El orden de esas fa-
ses indicadas en el ítem previo es el lógico y adecuado,
pero adviértase, como se dijo, que normalmente habrá
realimentación hacia atrás.
El modelo lineal o en cascada es el paradigma más anti-
Figura 2: Modelo cascada puro o secuencial para el ciclo de vida
del software. guo y extensamente utilizado, sin embargo las críticas a
él (ver desventajas) han puesto en duda su eficacia. Pese
a todo, tiene un lugar muy importante en la Ingeniería de
Sin embargo, el modelo cascada en algunas de sus va- software y continúa siendo el más utilizado; y siempre es
riantes es uno de los actualmente más utilizados,[10] por mejor que un enfoque al azar.[10]
su eficacia y simplicidad, más que nada en software de Desventajas del modelo cascada:[6]
pequeño y algunos de mediano porte; pero nunca (o muy
rara vez) se lo usa en su “forma pura”, como se dijo an-
• Los cambios introducidos durante el desarrollo pue-
teriormente. En lugar de ello, siempre se produce algu-
den confundir al equipo profesional en las etapas
na realimentación entre etapas, que no es completamente
tempranas del proyecto. Si los cambios se producen
predecible ni rígida; esto da oportunidad al desarrollo de
en etapa madura (codificación o prueba) pueden ser
productos software en los cuales hay ciertas incertezas,
catastróficos para un proyecto grande.
cambios o evoluciones durante el ciclo de vida. Así por
ejemplo, una vez capturados y especificados los requisitos • No es frecuente que el cliente o usuario final expli-
(primera etapa) se puede pasar al diseño del sistema, pero cite clara y completamente los requisitos (etapa de
durante esta última fase lo más probable es que se deban inicio); y el modelo lineal lo requiere. La incerti-
realizar ajustes en los requisitos (aunque sean mínimos), dumbre natural en los comienzos es luego difícil de
ya sea por fallas detectadas, ambigüedades o bien por que acomodar.[10]
los propios requisitos han cambiado o evolucionado; con
lo cual se debe retornar a la primera o previa etapa, hacer • El cliente debe tener paciencia ya que el software no
los reajuste pertinentes y luego continuar nuevamente con estará disponible hasta muy avanzado el proyecto.
el diseño; esto último se conoce como realimentación. Lo Un error detectado por el cliente (en fase de opera-
normal en el modelo cascada será entonces la aplicación ción) puede ser desastroso, implicando reinicio del
del mismo con sus etapas realimentadas de alguna forma, proyecto, con altos costos.
permitiendo retroceder de una a la anterior (e incluso po-
der saltar a varias anteriores) si es requerido.
4.1.2 Modelos evolutivos
De esta manera se obtiene el «modelo cascada realimen-
tado», que puede ser esquematizado como lo ilustra la El software evoluciona con el tiempo.[11][9] Los requisi-
Figura 3. tos del usuario y del producto suelen cambiar conforme
se desarrolla el mismo. Las fechas de mercado y la com-
petencia hacen que no sea posible esperar a poner en el
mercado un producto absolutamente completo, por lo que
se aconsejable introducir una versión funcional limitada
de alguna forma para aliviar las presiones competitivas.
En esas u otras situaciones similares los desarrolladores
necesitan modelos de progreso que estén diseñados para
acomodarse a una evolución temporal o progresiva, don-
de los requisitos centrales son conocidos de antemano,
aunque no estén bien definidos a nivel detalle.
En el modelo cascada y cascada realimentado no se
tiene demasiado en cuenta la naturaleza evolutiva del
Figura 3: Modelo cascada realimentado para el ciclo de vida.
software,[11] se plantea como estático, con requisitos bien
[6]
Lo dicho es, a grandes rasgos, la forma y utilización de conocidos y definidos desde el inicio.
este modelo, uno de los más usados y populares.[6] El mo- Los evolutivos son modelos iterativos, permiten desarro-
delo cascada realimentado resulta muy atractivo, hasta llar versiones cada vez más completas y complejas, hasta
4.1 Modelos de proceso o ciclo de vida 5

llegar al objetivo final deseado; incluso evolucionar más

allá, durante la fase de operación.
Los modelos «iterativo incremental» y «espiral» (entre
otros) son dos de los más conocidos y utilizados del tipo
evolutivo.[10]

Modelo iterativo incremental En términos 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 identifi- Figura 5: Modelo iterativo incremental para el ciclo de vida del
can claramente dichos pasos. La descripción del sistema software.
es esencial para especificar y confeccionar los distintos
incrementos hasta llegar al producto global y final. Las
actividades concurrentes (especificación, desarrollo y va- (incluso antes), en cualquier tiempo de la etapa previa.
lidación) sintetizan el desarrollo pormenorizado de los in- Cada incremento concluye con la actividad de «opera-
crementos, que se hará posteriormente. ción y mantenimiento» (indicada como «Operación» en
la figura), que es donde se produce la entrega del produc-
to parcial al cliente. El momento de inicio de cada in-
cremento es dependiente de varios factores: tipo de siste-
ma; independencia o dependencia entre incrementos (dos
de ellos totalmente independientes pueden ser fácilmen-
te iniciados al mismo tiempo si se dispone de personal
suficiente); capacidad y cantidad de profesionales involu-
crados en el desarrollo; etc.
Bajo este modelo se entrega software «por partes funcio-
nales más pequeñas», pero reutilizables, llamadas incre-
mentos. En general cada incremento se construye sobre
Figura 4: Diagrama genérico del desarrollo evolutivo incremen-
tal.
aquel que ya fue entregado.[6]
Como se muestra en la Figura 5, se aplican secuencias
El diagrama de la Figura 4 muestra en forma muy esque- Cascada en forma escalonada, mientras progresa el tiem-
mática, el funcionamiento de un ciclo iterativo incremen- po calendario. Cada secuencia lineal o Cascada produ-
tal, el cual permite la entrega de versiones parciales a me- ce un incremento y a menudo el primer incremento es
dida que se va construyendo el producto final.[6] Es decir, un sistema básico, con muchas funciones suplementarias
a medida que cada incremento definido llega a su etapa (conocidas o no) sin entregar.
de operación y mantenimiento. Cada versión emitida in-
corpora a los anteriores incrementos las funcionalidades El cliente utiliza inicialmente ese sistema básico, inter-
y requisitos que fueron analizados como necesarios. tanto, el resultado de su uso y evaluación puede aportar
al plan para el desarrollo del/los siguientes incrementos
El incremental es un modelo de tipo evolutivo que está ba- (o versiones). Además también aportan a ese plan otros
sado en varios ciclos Cascada Realimentados aplicados re- factores, como lo es la priorización (mayor o menor ur-
petidamente, con una filosofía iterativa.[10] En la Figura gencia en la necesidad de cada incremento en particular)
5 se muestra un refino del diagrama previo, bajo un es- y la dependencia entre incrementos (o independencia).
quema temporal, para obtener finalmente el esquema del
modelo de ciclo de vida Iterativo Incremental, con sus ac- Luego de cada integración se entrega un producto con
tividades genéricas asociadas. Aquí se observa claramen- mayor funcionalidad que el previo. El proceso se repite
te cada ciclo cascada que es aplicado para la obtención de hasta alcanzar el software final completo.
un incremento; estos últimos se van integrando para ob- Siendo iterativo, con el modelo incremental se entrega un
tener el producto final completo. Cada incremento es un producto parcial pero completamente operacional en cada
ciclo Cascada Realimentado, aunque, por simplicidad, en incremento, y no una parte que sea usada para reajustar los
la Figura 5 se muestra como secuencial puro. requisitos (como si ocurre en el modelo de construcción
Se observa que existen actividades de desarrollo (para ca- de prototipos).[10]
da incremento) que son realizadas en paralelo o concu- El enfoque incremental resulta muy útil cuando se dispo-
rrentemente, así por ejemplo, en la Figura, mientras se ne de baja dotación de personal para el desarrollo; tam-
realiza el diseño detalle del primer incremento ya se está bién si no hay disponible fecha límite del proyecto por lo
realizando en análisis del segundo. La Figura 5 es sólo es- que se entregan versiones incompletas pero que propor-
quemática, un incremento no necesariamente se iniciará cionan al usuario funcionalidad básica (y cada vez ma-
durante la fase de diseño del anterior, puede ser posterior yor). También es un modelo útil a los fines de versiones
6 4 PROCESO DE CREACIÓN DEL SOFTWARE

de evaluación. ducto software denominados «incrementos» del sistema,

Nota: Puede ser considerado y útil, en cualquier momen- que son escogidos según prioridades predefinidas de al-
to o incremento incorporar temporalmente el paradigma gún modo. El modelo permite una implementación con
MCP como complemento, teniendo así una mixtura de refinamientos sucesivos (ampliación o mejora). Con ca-
modelos que mejoran el esquema y desarrollo general. da incremento se agrega nueva funcionalidad o se cubren
nuevos requisitos o bien se mejora la versión previamente
Ejemplo: implementada del producto software.
Este modelo brinda cierta flexibilidad para que duran-
Un procesador de texto que sea desarrollado te el desarrollo se incluyan cambios en los requisitos
bajo el paradigma Incremental podría aportar, por parte del usuario, un cambio de requisitos propues-
en principio, funciones básicas de edición de to y aprobado puede analizarse e implementarse como
archivos y producción de documentos (algo co- un nuevo incremento o, eventualmente, podrá constituir
mo un editor simple). En un segundo incre- una mejora/adecuación de uno ya planeado. Aunque si
mento se le podría agregar edición más sofisti- se produce un cambio de requisitos por parte del clien-
cada, y de generación y mezcla de documentos. te que afecte incrementos previos ya terminados (detec-
En un tercer incremento podría considerarse el ción/incorporación tardía) se debe evaluar la factibilidad
agregado de funciones de corrección ortográfi- y realizar un acuerdo con el cliente, ya que puede impactar
ca, esquemas de paginado y plantillas; en un fuertemente en los costos.
cuarto capacidades de dibujo propias y ecua-
ciones matemáticas. Así sucesivamente hasta La selección de este modelo permite realizar entregas
llegar al procesador final requerido. Así, el pro- funcionales tempranas al cliente (lo cual es beneficioso
ducto va creciendo, acercándose a su meta fi- tanto para él como para el grupo de desarrollo). Se prio-
nal, pero desde la entrega del primer incremen- rizan las entregas de aquellos módulos o incrementos en
to ya es útil y funcional para el cliente, el cual que surja la necesidad operativa de hacerlo, por ejemplo
observa una respuesta rápida en cuanto a en- para cargas previas de información, indispensable para
trega temprana; sin notar que la fecha límite los incrementos siguientes.[10]
del proyecto puede no estar acotada ni tan de- El modelo iterativo incremental no obliga a especificar
finida, lo que da margen de operación y alivia con precisión y detalle absolutamente todo lo que el siste-
presiones al equipo de desarrollo. ma debe hacer, (y cómo), antes de ser construido (como
el caso del cascada, con requisitos congelados). Sólo se
Como se dijo, el Iterativo Incremental es un modelo del hace en el incremento en desarrollo. Esto torna más ma-
tipo evolutivo, es decir donde se permiten y esperan pro- nejable el proceso y reduce el impacto en los costos. Esto
bables cambios en los requisitos en tiempo de desarro- es así, porque en caso de alterar o rehacer los requisitos,
llo; se admite cierto margen para que el software pueda solo afecta una parte del sistema. Aunque, lógicamente,
evolucionar.[9] Aplicable cuando los requisitos son me- esta situación se agrava si se presenta en estado avanzado,
dianamente bien conocidos pero no son completamente es decir en los últimos incrementos. En definitiva, el mo-
estáticos y definidos, cuestión esa que si es indispensable delo facilita la incorporación de nuevos requisitos durante
para poder utilizar un modelo Cascada. el desarrollo.
El modelo es aconsejable para el desarrollo de software Con un paradigma incremental se reduce el tiempo de
en el cual se observe, en su etapa inicial de análisis, que desarrollo inicial, ya que se implementa funcionalidad
posee áreas bastante bien definidas a cubrir, con suficien- parcial. También provee un impacto ventajoso frente al
te independencia como para ser desarrolladas en etapas cliente, que es la entrega temprana de partes operativas
sucesivas. Tales áreas a cubrir suelen tener distintos gra- del software.
dos de apremio por lo cual las mismas se deben priorizar El modelo proporciona todas las ventajas del modelo en
en un análisis previo, es decir, definir cual será la prime- cascada realimentado, reduciendo sus desventajas sólo al
ra, la segunda, y así sucesivamente; esto se conoce como ámbito de cada incremento.
«definición de los incrementos» con base en la prioriza-
ción. Pueden no existir prioridades funcionales por parte El modelo incremental no es recomendable para casos de
del cliente, pero el desarrollador debe fijarlas de todos sistemas de tiempo real, de alto nivel de seguridad, de
modos y con algún criterio, ya que basándose en ellas se procesamiento distribuido, o de alto índice de riesgos.
desarrollarán y entregarán los distintos incrementos.
El hecho de que existan incrementos funcionales del soft-
Modelo espiral El modelo espiral fue propuesto ini-
ware lleva inmediatamente a pensar en un esquema de cialmente por Barry Boehm. Es un modelo evolutivo que
desarrollo modular, por tanto este modelo facilita tal pa-
conjuga la naturaleza iterativa del modelo MCP con los
radigma de diseño. aspectos controlados y sistemáticos del Modelo Cascada.
En resumen, un modelo incremental lleva a pensar en Proporciona potencial para desarrollo rápido de versio-
un desarrollo modular, con entregas parciales del pro- nes incrementales. En el modelo Espiral el software se
4.1 Modelos de proceso o ciclo de vida 7

construye en una serie de versiones incrementales. En las esas actividades comprenden un «conjunto de tareas» del
primeras iteraciones la versión incremental podría ser un trabajo: ese conjunto sí se debe adaptar a las caracterís-
modelo en papel o bien un prototipo. En las últimas ite- ticas del proyecto en particular a emprender. Nótese que
raciones se producen versiones cada vez más completas lo listado en los ítems de 1 a 6 son conjuntos de tareas,
del sistema diseñado.[6][10] algunas de las ellas normalmente dependen del proyecto
El modelo se divide en un número de Actividades de mar- o desarrollo en si.
co de trabajo, llamadas «regiones de tareas». En general Proyectos pequeños requieren baja cantidad de tareas y
existen entre tres y seis regiones de tareas (hay variantes también de formalidad. En proyectos mayores o críticos
del modelo). En la Figura 6 se muestra el esquema de un cada región de tareas contiene labores de más alto nivel
Modelo Espiral con 6 regiones. En este caso se explica de formalidad. En cualquier caso se aplican actividades
una variante del modelo original de Boehm, expuesto en de protección (por ejemplo, gestión de configuración del
su tratado de 1988; en 1998 expuso un tratado más re- software, garantía de calidad, etc.).
ciente. Al inicio del ciclo, o proceso evolutivo, el equipo de in-
geniería gira alrededor del espiral (metafóricamente ha-
blando) 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 especificación
del producto; los pasos siguientes podrían generar un
prototipo y progresivamente versiones más sofisticadas
del software.
Cada paso por la región de planificación provoca ajustes
en el plan del proyecto; el coste y planificación se reali-
mentan en función de la evaluación del cliente. El gestor
de proyectos debe ajustar el número de iteraciones reque-
ridas para completar el desarrollo.
El modelo espiral puede ir adaptándose y aplicarse a lo
largo de todo el Ciclo de vida del software (en el mode-
lo clásico, o cascada, el proceso termina a la entrega del
software).
Una visión alternativa del modelo puede observarse exa-
Figura 6: Modelo espiral para el ciclo de vida del software.
minando el «eje de punto de entrada de proyectos». Cada
uno de los circulitos (๏) fijados a lo largo del eje repre-
Las regiones definidas en el modelo de la figura son: sentan puntos de arranque de los distintos proyectos (re-
lacionados); a saber:
• Región 1 - Tareas requeridas para establecer la co-
municación entre el cliente y el desarrollador.
• Un proyecto de «desarrollo de conceptos» comien-
• Región 2 - Tareas inherentes a la definición de los za al inicio de la espiral, hace múltiples iteraciones
recursos, tiempo y otra información relacionada con hasta que se completa, es la zona marcada con verde.
el proyecto.
• Si lo anterior se va a desarrollar como producto real,
• Región 3 - Tareas necesarias para evaluar los riesgos se inicia otro proyecto: «Desarrollo de nuevo Pro-
técnicos y de gestión del proyecto. ducto». Que evolucionará con iteraciones hasta cul-
minar; es la zona marcada en color azul.
• Región 4 - Tareas para construir una o más repre-
sentaciones de la aplicación software. • Eventual y análogamente se generarán proyectos de
«mejoras de productos» y de «mantenimiento de
• Región 5 - Tareas para construir la aplicación, ins- productos», con las iteraciones necesarias en cada
talarla, probarla y proporcionar soporte al usuario o área (zonas roja y gris, respectivamente).
cliente (Ej. documentación y práctica).

• Región 6 - Tareas para obtener la reacción del clien- Cuando la espiral se caracteriza de esta forma, está ope-
te, según la evaluación de lo creado e instalado en rativa hasta que el software se retira, eventualmente
los ciclos anteriores. puede estar inactiva (el proceso), pero cuando se produ-
ce un cambio el proceso arranca nuevamente en el punto
Las actividades enunciadas para el marco de trabajo son de entrada apropiado (por ejemplo, en «mejora del pro-
generales y se aplican a cualquier proyecto, grande, me- ducto»).
diano o pequeño, complejo o no. Las regiones que definen El modelo espiral da un enfoque realista, que evoluciona
8 4 PROCESO DE CREACIÓN DEL SOFTWARE

igual que el software;[11] se adapta muy bien para desa- 3. Negociación de las condiciones «victoria» de los di-
rrollos a gran escala. rectivos para obtener condiciones «Victoria & Vic-
El Espiral utiliza el MCP para reducir riesgos y permi- toria» (negociar para que ambos ganen).
te aplicarlo en cualquier etapa de la evolución. Mantiene
el enfoque clásico (cascada) pero incorpora un marco de (*) Directivo: Cliente escogido con interés directo en el
trabajo iterativo que refleja mejor la realidad. producto, que puede ser premiado por la organización si
tiene éxito o criticado si no.
Este modelo requiere considerar riesgos técnicos en todas
las etapas del proyecto; aplicado adecuadamente debe re- El modelo Win & Win hace énfasis en la negociación
ducirlos antes de que sean un verdadero problema. inicial, también introduce 3 hitos en el proceso llamados
«puntos de fijación», que ayudan a establecer la comple-
El Modelo evolutivo como el Espiral es particularmen-
titud de un ciclo de la espiral, y proporcionan hitos de
te apto para el desarrollo de Sistemas Operativos (com-
decisión antes de continuar el proyecto de desarrollo del
plejos); también en sistemas de altos riesgos o críticos
software.
(Ej. navegadores y controladores aeronáuticos) y en to-
dos aquellos en que sea necesaria una fuerte gestión del
proyecto y sus riesgos, técnicos o de gestión. 4.2 Etapas en el desarrollo del software
Desventajas importantes:
4.2.1 Captura, análisis y especificación de requisi-
• Requiere mucha experiencia y habilidad para la eva- tos
luación de los riesgos, lo cual es requisito para el
éxito del proyecto. Al inicio de un desarrollo (no de un proyecto), esta es la
primera fase que se realiza, y, según el modelo de proceso
• Es difícil convencer a los grandes clientes que se po- adoptado, puede casi terminar para pasar a la próxima
drá controlar este enfoque evolutivo. etapa (caso de Modelo Cascada Realimentado) o puede
hacerse parcialmente para luego retomarla (caso Modelo
Este modelo no se ha usado tanto, como el Cascada (In- Iterativo Incremental u otros de carácter evolutivo).
cremental) o MCP, por lo que no se tiene bien medida su
eficacia, es un paradigma relativamente nuevo y difícil de En simple palabras y básicamente, durante esta fase, se
implementar y controlar. adquieren, reúnen y especifican las características fun-
cionales y no funcionales que deberá cumplir el futuro
programa o sistema a desarrollar.
Modelo espiral Win & Win Una variante interesan-
Las bondades de las características, tanto del sistema o
te del Modelo Espiral previamente visto (Figura 6) es el
[7] programa a desarrollar, como de su entorno, parámetros
«Modelo espiral Win-Win» (Barry Boehm). El Mode-
no funcionales y arquitectura dependen enormemente de
lo Espiral previo (clásico) sugiere la comunicación con
lo bien lograda que esté esta etapa. Esta es, probablemen-
el cliente para fijar los requisitos, en que simplemente se
te, la de mayor importancia y una de las fases más difíci-
pregunta al cliente qué necesita y él proporciona la infor-
les de lograr certeramente, pues no es automatizable, no
mación para continuar; pero esto es en un contexto ideal
es muy técnica y depende en gran medida de la habilidad
que rara vez ocurre. Normalmente cliente y desarrolla-
y experiencia del analista que la realice.
dor entran en una negociación, se negocia coste frente a
funcionalidad, rendimiento, calidad, etc. Involucra fuertemente al usuario o cliente del sistema, por
tanto tiene matices muy subjetivos y es difícil de modelar
«Es así que la obtención de requisitos requiere una nego-
con certeza o aplicar una técnica que sea «la más cerca-
ciación, que tiene éxito cuando ambas partes ganan».
na a la adecuada» (de hecho no existe «la estrictamente
Las mejores negociaciones se fuerzan en obtener «Vic- adecuada»). Si bien se han ideado varias metodologías,
toria & Victoria» (Win & Win), es decir que el cliente incluso software de apoyo, para captura, elicitación y re-
gane obteniendo el producto que lo satisfaga, y el desa- gistro de requisitos, no existe una forma infalible o ab-
rrollador también gane consiguiendo presupuesto y fecha solutamente confiable, y deben aplicarse conjuntamente
de entrega realista. Evidentemente, este modelo requiere buenos criterios y mucho sentido común por parte del o
fuertes habilidades de negociación. los analistas encargados de la tarea; es fundamental tam-
El modelo Win-Win define un conjunto de actividades bién lograr una fluida y adecuada comunicación y com-
de negociación al principio de cada paso alrededor de la prensión con el usuario final o cliente del sistema.
espiral; se definen las siguientes actividades: El artefacto más importante resultado de la culminación
de esta etapa es lo que se conoce como especificación de
1. Identificación del sistema o subsistemas clave de los requisitos software o simplemente documento ERS.
directivos(*) (saber qué quieren).
Como se dijo, la habilidad del analista para interactuar
2. Determinación de «condiciones de victoria» de los con el cliente es fundamental; lo común es que el clien-
directivos (saber qué necesitan y los satisface) te tenga un objetivo general o problema que resolver, no
4.2 Etapas en el desarrollo del software 9

conoce en absoluto el área (informática), ni su jerga, ni si el sistema a desarrollar será para gestionar información
siquiera sabe con precisión qué debería hacer el produc- de una aseguradora y sus sucursales remotas, el analista
to software (qué y cuantas funciones) ni, mucho menos, se debe compenetrar en cómo ella trabaja y maneja su
cómo debe operar. En otros casos menos frecuentes, el información, desde niveles muy bajos e incluso llegando
cliente «piensa» que sabe precisamente lo que el software hasta los gerenciales. Dada a gran diversidad de campos a
tiene que hacer, y generalmente acierta muy parcialmen- cubrir, los analistas suelen ser asistidos por especialistas,
te, pero su empecinamiento entorpece la tarea de elicita- es decir gente que conoce profundamente el área para la
ción. El analista debe tener la capacidad para lidiar con cual se desarrollará el software; evidentemente una única
este tipo de problemas, que incluyen relaciones humanas; persona (el analista) no puede abarcar tan vasta cantidad
tiene que saber ponerse al nivel del usuario para permitir de áreas del conocimiento. En empresas grandes de desa-
una adecuada comunicación y comprensión. rrollo de productos software, es común tener analistas es-
Escasas son las situaciones en que el cliente sabe con cer- pecializados en ciertas áreas de trabajo.
teza e incluso con completitud lo que requiere de su futuro Contrariamente, no es problema del cliente, es decir él
sistema, este es el caso más sencillo para el analista. no tiene por qué saber nada de software, ni de diseños,
Las tareas relativas a captura, elicitación, modelado y re- ni otras cosas relacionadas; sólo se debe limitar a aportar
gistro de requisitos, además de ser sumamente importan- objetivos, datos e información (de mano propia o de sus
te, puede llegar a ser dificultosa de lograr acertadamente registros, equipos, empleados, etc) al analista, y guiado
y llevar bastante tiempo relativo al proceso total del desa- por él, para que, en primera instancia, defina el «Universo
rrollo; al proceso y metodologías para llevar a cabo este de Discurso», y con posterior trabajo logre confeccionar
conjunto de actividades normalmente se las asume parte el adecuado documento ERS.
propia de la Ingeniería de Software, pero dada la antedi- Es bien conocida la presión que sufren los desarrolladores
cha complejidad, actualmente se habla de una Ingeniería de sistemas informáticos para comprender y rescatar las
de requisitos[12] , aunque ella aún no existe formalmente. necesidades de los clientes/usuarios. Cuanto más comple-
jo es el contexto del problema más difícil es lograrlo, a
Hay grupos de estudio e investigación, en todo el mun-
do, que están exclusivamente abocados a idear modelos, veces se fuerza a los desarrolladores a tener que conver-
tirse en casi expertos de los dominios que analizan.
técnicas y procesos para intentar lograr la correcta captu-
ra, análisis y registro de requisitos. Estos grupos son los Cuando esto no sucede es muy probable que se genere un
que normalmente hablan de la Ingeniería de requisitos; conjunto de requisitos[13] erróneos o incompletos y por
es decir se plantea ésta como un área o disciplina pero no lo tanto un producto de software con alto grado de des-
como una carrera universitaria en si misma. aprobación por parte de los clientes/usuarios y un altísi-
Algunos requisitos no necesitan la presencia del cliente, mo costo de reingeniería y mantenimiento. Todo aque-
para ser capturados o analizados; en ciertos casos los pue- llo que no se detecte, o resulte mal entendido en la etapa
de proponer el mismo analista o, incluso, adoptar uni- inicial provocará un fuerte impacto negativo en los requi-
lateralmente decisiones que considera adecuadas (tanto sitos, propagando esta corriente degradante a lo largo de
en requisitos funcionales como no funcionales). Por citar todo el proceso de desarrollo e incrementando su perjui-
ejemplos probables: Algunos requisitos sobre la arquitec- cio cuanto más tardía sea su detección (Bell y Thayer
tura del sistema, requisitos no funcionales tales como los 1976)(Davis 1993).
relativos al rendimiento, nivel de soporte a errores ope-
rativos, plataformas de desarrollo, relaciones internas o
ligas entre la información (entre registros o tablas de da- Procesos, modelado y formas de elicitación de requi-
tos) a almacenar en caso de bases o bancos de datos, etc. sitos Siendo que la captura, elicitación y especificación
Algunos funcionales tales como opciones secundarias o de requisitos, es una parte crucial en el proceso de desa-
de soporte necesarias para una mejor o más sencilla ope- rrollo de software, ya que de esta etapa depende el logro
ratividad; etc. de los objetivos finales previstos, se han ideado modelos
La obtención de especificaciones a partir del cliente (u y diversas metodologías de trabajo para estos fines. Tam-
otros actores intervinientes) es un proceso humano muy bién 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 información, se la analiza y realimenta con el clien- El estándar IEEE 830-1998 brinda una normalización de
te, refinándola, puliéndola y corrigiendo si es necesario; las «Prácticas Recomendadas para la Especificación de
cualquiera sea el método de ERS utilizado. EL analista Requisitos Software».[14]
siempre debe llegar a conocer la temática y el problema
A medida que se obtienen los requisitos, normalmente se
que resolver, dominarlo, hasta cierto punto, hasta el ám-
los va analizando, el resultado de este análisis, con o sin
bito que el futuro sistema a desarrollar lo abarque. Por
el cliente, se plasma en un documento, conocido como
ello el analista debe tener alta capacidad para compren-
ERS o Especificación de Requisitos Software, cuya es-
der problemas de muy diversas áreas o disciplinas de tra-
tructura puede venir definida por varios estándares, tales
bajo (que no son específicamente suyas); así por ejemplo,
como CMMI.
10 4 PROCESO DE CREACIÓN DEL SOFTWARE

Un primer paso para realizar el relevamiento de informa- sencillamente se pautan las tareas que deben cumplirse,
ción es el conocimiento y definición acertada lo que se de alguna manera.
conoce como «Universo de Discurso» del problema, que
se define y entiende por:
Universo de Discurso (UdeD): es el contexto general en
el cual el software deberá ser desarrollado y deberá ope-
rar. El UdeD incluye todas las fuentes de información y
todas las personas relacionadas con el software. Esas per-
sonas son conocidas también como actores de ese univer-
so. El UdeD es la realidad circunstanciada por el conjunto
de objetivos definidos por quienes demandaron el softwa-
re.
A partir de la extracción y análisis de información en su
ámbito se obtienen todas las especificaciones necesarias Figura 7: Diagrama de tareas para captura y análisis de requi-
y tipos de requisitos para el futuro producto software. sitos.
El objetivo de la Ingeniería de requisitos (IR) es siste-
Una posible lista, general y ordenada, de tareas recomen-
matizar el proceso de definición de requisitos permitien-
dadas para obtener la definición de lo que se debe reali-
do elicitar, modelar y analizar el problema, generando un
zar, los productos a obtener y las técnicas a emplear du-
compromiso entre los ingenieros de requisitos y los clien-
rante la actividad de elicitación de requisitos, en fase de
tes/usuarios, ya que ambos participan en la generación y
Especificación de Requisitos Software es:
definición de los requisitos del sistema. La IR aporta un
conjunto de métodos, técnicas y herramientas que asisten
a los ingenieros de requisitos (analistas) para obtener re- 1. Obtener información sobre el dominio del problema
quisitos lo más seguros, veraces, completos y oportunos y el sistema actual (UdeD).
posibles, permitiendo básicamente:
2. Preparar y realizar las reuniones para elicita-
ción/negociación.
• Comprender el problema
3. Identificar/revisar los objetivos del usuario.
• Facilitar la obtención de las necesidades del clien-
te/usuario
4. Identificar/revisar los objetivos del sistema.
• Validar con el cliente/usuario
5. Identificar/revisar los requisitos de información.
• Garantizar las especificaciones de requisitos
6. Identificar/revisar los requisitos funcionales.
Si bien existen diversas formas, modelos y metodologías 7. Identificar/revisar los requisitos no funcionales.
para elicitar, definir y documentar requisitos, no se pue-
de decir que alguna de ellas sea mejor o peor que la otra, 8. Priorizar objetivos y requisitos.
suelen tener muchísimo en común, y todas cumplen el
mismo objetivo. Sin embargo, lo que si se puede decir
Algunos principios básicos a tener en cuenta:
sin dudas es que es indispensable utilizar alguna de ellas
para documentar las especificaciones del futuro producto
software. Así por ejemplo, hay un grupo de investigación • Presentar y entender cabalmente el dominio de la
argentino que desde hace varios años ha propuesto y es- información del problema.
tudia el uso del LEL (Léxico Extendido del Lenguaje) y
Escenarios como metodología, aquí[15] se presenta una de • Definir correctamente las funciones que debe reali-
las tantas referencias y bibliografía sobre ello. Otra for- zar el Software.
ma, más ortodoxa, de capturar y documentar requisitos
se puede obtener en detalle, por ejemplo, en el trabajo • Representar el comportamiento del software a con-
de la Universidad de Sevilla sobre «Metodología para el secuencias de acontecimientos externos, particula-
Análisis de Requisitos de Sistemas Software». [16] res, incluso inesperados.

En la Figura 7 se muestra un esquema, más o menos rigu- • Reconocer requisitos incompletos, ambiguos o con-
roso, aunque no detallado, de los pasos y tareas a seguir tradictorios.
para realizar la captura, análisis y especificación de re-
quisitos software. También allí se observa qué artefacto • Dividir claramente los modelos que representan la
o documento se obtiene en cada etapa del proceso. En el información, las funciones y comportamiento y ca-
diagrama no se explicita metodología o modelo a utilizar, racterísticas no funcionales.
4.2 Etapas en el desarrollo del software 11

Clasificación e identificación de requisitos Se pue- • Requisitos externos. Se derivan de factores externos

den identificar dos formas de requisitos: al sistema y al proceso de desarrollo (Ej. requisitos
legislativos, éticos, etc.)
• Requisitos de usuario: Los requisitos de usuario son
frases en lenguaje natural junto a diagramas con los • Requisitos del dominio.
servicios que el sistema debe proporcionar, así co-
mo las restricciones bajo las que debe operar. Los requisitos del dominio se derivan del dominio de la
aplicación y reflejan características de dicho dominio.
• Requisitos de sistema: Los requisitos de sistema de-
terminan 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 Inter-
Es decir, ambos son lo mismo, pero con distinto nivel de comunicación de Bibliotecas de España (LIBE). Ej. El
detalle. sistema de biblioteca no podrá acceder a bibliotecas con
material censurado.
Ejemplo de requisito de usuario: El sistema debe hacer
préstamos Ejemplo de requisito de sistema: Función prés-
tamo: entrada código socio, código ejemplar; salida: fe- 4.2.2 Diseño del sistema
cha devolución; etc.
Se clasifican en tres los tipos de requisitos de sistema: En ingeniería de software, el diseño es una fase de ciclo
de vida del software. Se basa en la especificación de re-
quisitos producido por el análisis de los requisitos (fase de
• Requisitos funcionales análisis), el diseño define cómo estos requisitos se cum-
plirán, la estructura que debe darse al sistema de software
Los requisitos funcionales describen: para que se haga realidad.
El diseño sigue siendo una fase separada del la programa-
• Los servicios que proporciona el sistema (funcio- ción o codificación, esta última corresponde a la traduc-
nes). ción en un determinado lenguaje de programación de las
• La respuesta del sistema ante determinadas entradas. premisas adoptadas en el diseño.
Las distinciones entre las actividades mencionadas has-
• El comportamiento del sistema en situaciones parti-
ta ahora no siempre son claras cómo se quisiera en las
culares.
teorías clásicas de ingeniería de software. El diseño, 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 posición intermedia entre el análisis
Los requisitos no funcionales son restricciones de los ser- y codificación.
vicios o funciones que ofrece el sistema (ej. cotas de tiem-
Normalmente se entiende por “diseño de la arquitectura”
po, proceso de desarrollo, rendimiento, etc.)
al diseño de “muy alto nivel”, que sólo define la estructura
del sistema en términos de la módulos de software de que
Ejemplo 1. La biblioteca Central se compone y las relaciones macroscópicas entre ellos. A
debe ser capaz de atender simultá- este nivel de diseño pertenecen fórmulas como cliente-
neamente a todas las bibliotecas de servidor o “tres niveles”, o, más generalmente, las deci-
la 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 definir la descom-
posición del sistema en módulos, pero esta vez con una
A su vez, hay tres tipos de requisitos no funcio-
referencia más o menos explícita al modo de descompo-
nales:
sición que ofrece el particular lenguaje de programación
con el que el desarrollo se va a implementar, por ejem-
• Requisitos del producto. Especifican el comporta- plo, en un diseño realizado con la tecnología de objetos, el
miento del producto (Ej. prestaciones, memoria, ta- proyecto podría describir al sistema en términos de clases
sa de fallos, etc.) y sus interrelaciones.
• Requisitos organizativos. Se derivan de las políticas El diseño detallado, por último, es una descripción del
y procedimientos de las organizaciones de los clien- sistema muy cercana a la codificación (por ejemplo, des-
tes y desarrolladores (Ej. estándares de proceso, len- cribir no sólo las clases en abstracto, sino también sus
guajes de programación, etc.) atributos y los métodos con sus tipos).
12 4 PROCESO DE CREACIÓN DEL SOFTWARE

Debido a la naturaleza “intangible” del software, y depen- • Código objeto: es el código binario o intermedio re-
diendo de las herramientas que se utilizan en el proceso, sultante de procesar con un compilador el código
la frontera entre el diseño y la codificación también pue- fuente. Consiste en una traducción completa y de
de ser virtualmente imposible de identificar. Por ejemplo, una sola vez de éste último. El código objeto no es
algunas herramientas CASE son capaces de generar có- inteligible por el ser humano (normalmente es for-
digo a partir de diagramas UML, los que describen grá- mato binario) pero tampoco es directamente ejecu-
ficamente la estructura de un sistema software. table por la computadora. Se trata de una represen-
tación intermedia entre el código fuente y el códi-
go ejecutable, a los fines de un enlace final con las
4.2.3 Codificación del software rutinas de biblioteca y entre procedimientos o bien
para su uso con un pequeño intérprete intermedio [a
Durante esta etapa se realizan las tareas que comúnmen- modo de distintos ejemplos véase EUPHORIA, (in-
te se conocen como programación; que consiste, esencial- térprete intermedio), FORTRAN (compilador pu-
mente, en llevar a código fuente, en el lenguaje de progra- ro) MSIL (Microsoft Intermediate Language) (intér-
mación elegido, todo lo diseñado en la fase anterior. Esta prete) y BASIC (intérprete puro, intérprete interme-
tarea la realiza el programador, siguiendo por completo dio, compilador intermedio o compilador puro, de-
los lineamientos impuestos en el diseño y en considera- pende de la versión utilizada)].
ción siempre a los requisitos funcionales y no funcionales
(ERS) especificados en la primera etapa. • El código objeto no existe si el programador
Es común pensar que la etapa de programación o codifi- trabaja con un lenguaje a modo de intérpre-
cación (algunos la llaman implementación) es la que in- te puro, en este caso el mismo intérprete se
sume la mayor parte del trabajo de desarrollo del softwa- encarga de traducir y ejecutar línea por línea
re; sin embargo, esto puede ser relativo (y generalmen- el código fuente (de acuerdo al flujo del pro-
te aplicable a sistemas de pequeño porte) ya que las eta- grama), en tiempo de ejecución. En este ca-
pas previas son cruciales, críticas y pueden llevar bastante so tampoco existe el o los archivos de código
más tiempo. Se suele hacer estimaciones de un 30% del ejecutable. Una desventaja de esta modalidad
tiempo total insumido en la programación, pero esta ci- es que la ejecución del programa o sistema es
fra no es consistente ya que depende en gran medida de un poco más lenta que si se hiciera con un in-
las características del sistema, su criticidad y el lenguaje térprete intermedio, y bastante más lenta que
de programación elegido.[7] En tanto menor es el nivel del si existe el o los archivos de código ejecutable.
lenguaje mayor será el tiempo de programación requeri- Es decir no favorece el rendimiento en veloci-
do, así por ejemplo se tardaría más tiempo en codificar dad de ejecución. Pero una gran ventaja de la
un algoritmo en lenguaje ensamblador que el mismo pro- modalidad intérprete puro, es que él está for-
gramado en lenguaje C. ma de trabajo facilita enormemente la tarea de
depuración del código fuente (frente a la al-
Mientras se programa la aplicación, sistema, o software ternativa de hacerlo con un compilador puro).
en general, se realizan también tareas de depuración, esto Frecuentemente se suele usar una forma mixta
es la labor de ir liberando al código de los errores facti- de trabajo (si el lenguaje de programación ele-
bles de ser hallados en esta fase (de semántica, sintáctica gido lo permite), es decir inicialmente trabajar
y lógica). Hay una suerte de solapamiento con la fase si- a modo de intérprete puro, y una vez depurado
guiente, ya que para depurar la lógica es necesario reali- el código fuente (liberado de errores) se utiliza
zar pruebas unitarias, normalmente con datos de prueba; un compilador del mismo lenguaje para obte-
claro es que no todos los errores serán encontrados só- ner el código ejecutable completo, con lo cual
lo en la etapa de programación, habrán otros que se en- se agiliza la depuración y la velocidad de eje-
contrarán durante las etapas subsiguientes. La aparición cución se optimiza.
de algún error funcional (mala respuesta a los requisitos)
eventualmente puede llevar a retornar a la fase de diseño
antes de continuar la codificación. • Código ejecutable: Es el código binario resultado de
enlazar uno o más fragmentos de código objeto con
Durante la fase de programación, el código puede adoptar las rutinas y bibliotecas necesarias. Constituye uno
varios estados, dependiendo de la forma de trabajo y del o más archivos binarios con un formato tal que el
lenguaje elegido, a saber: sistema operativo es capaz de cargarlo en la me-
moria RAM (eventualmente también parte en una
• Código fuente: es el escrito directamente por los memoria virtual), y proceder a su ejecución directa.
programadores en editores de texto, lo cual genera el Por lo anterior se dice que el código ejecutable es
programa. Contiene el conjunto de instrucciones co- directamente «inteligible por la computadora». El
dificadas en algún lenguaje de alto nivel. Puede estar código ejecutable, también conocido como código
distribuido en paquetes, procedimientos, bibliotecas máquina, no existe si se programa con modalidad
fuente, etc. de «intérprete puro».
4.2 Etapas en el desarrollo del software 13

4.2.4 Pruebas (unitarias y de integración) La instalación, dependiendo del sistema desarrollado,

puede consistir en una simple copia al disco rígido des-
Entre las diversas pruebas que se le efectúan al software tino (casos raros actualmente); o bien, más comúnmen-
se pueden distinguir principalmente: te, con una de complejidad intermedia en la que los dis-
tintos archivos componentes del software (ejecutables,
bibliotecas, datos propios, etc.) son descomprimidos y
• Prueba unitarias: Consisten en probar o testear pie-
copiados a lugares específicos preestablecidos del disco;
zas de software pequeñas; a nivel de secciones, pro-
incluso se crean vínculos con otros productos, además del
cedimientos, funciones y módulos; aquellas que ten-
propio sistema operativo. Este último caso, comúnmente
gan funcionalidades específicas. Dichas pruebas se
es un proceso bastante automático que es creado y guia-
utilizan para asegurar el correcto funcionamiento de
do con heramientas software específicas (empaquetado y
secciones de código, mucho más reducidas que el
distribución, instaladores).
conjunto, y que tienen funciones concretas con cier-
to grado de independencia. En productos de mayor complejidad, la segunda alterna-
tiva es la utilizada, pero es realizada o guiada por espe-
• Pruebas de integración: Se realizan una vez que las cialistas; puede incluso requerirse la instalación en varios
pruebas unitarias fueron concluidas exitosamente; y distintos computadores (instalación distribuida).
con éstas se intenta asegurar que el sistema comple- También, en software de mediana y alta complejidad nor-
to, incluso los subsistemas que componen las piezas malmente es requerido un proceso de configuración y
individuales grandes del software funcionen correc- chequeo, por el cual se asignan adecuados parámetros de
tamente al operar e inteoperar en conjunto. funcionamiento y se testea la operatividad funcional del
producto.
Las pruebas normalmente se efectúan con los llamados En productos de venta masiva las instalaciones comple-
datos de prueba, que es un conjunto seleccionado de da- tas, si son relativamente simples, suelen ser realizadas por
tos típicos a los que puede verse sometido el sistema, los los propios usuarios finales (tales como sistemas operati-
módulos o los bloques de código. También se escogen: vos, paquetes de oficina, utilitarios, etc.) con herramien-
Datos que llevan a condiciones límites al software a fin tas propias de instalación guiada; incluso la configuración
de probar su tolerancia y robustez; datos de utilidad pa- suele ser automática. En productos de diseño específico o
ra mediciones de rendimiento; datos que provocan condi- «a medida» la instalación queda restringida, normalmen-
ciones eventuales o particulares poco comunes y a las que te, a personas especialistas involucradas en el desarrollo
el software normalmente no estará sometido pero pueden del software en cuestión.
ocurrir; etc. Los «datos de prueba» no necesariamente
son ficticios o «creados», pero normalmente sí lo son los Una vez realizada exitosamente la instalación del softwa-
de poca probabilidad de ocurrencia. re, el mismo pasa a la fase de producción (operatividad),
durante la cual cumple las funciones para las que fue desa-
Generalmente, existe un fase probatoria final y completa rrollado, es decir, es finalmente utilizado por el (o los)
del software, llamada Beta Test, durante la cual el sis- usuario final, produciendo los resultados esperados.
tema instalado en condiciones normales de operación y
trabajo es probado exhaustivamente a fin de encontrar
errores, inestabilidades, respuestas erróneas, etc. que ha-
4.2.6 Mantenimiento
yan pasado los previos controles. Estas son normalmente
realizadas por personal idóneo contratado o afectado es-
pecíficamente a ello. Los posibles errores encontrados se El mantenimiento de software es el proceso de control,
transmiten a los desarrolladores para su depuración. En mejora y optimización del software ya desarrollado e ins-
el caso de software de desarrollo «a pedido», el usuario talado, que también incluye depuración de errores y de-
final (cliente) es el que realiza el Beta Test, teniendo para fectos que puedan haberse filtrado de la fase de pruebas
ello un período de prueba pactado con el desarrollador. de control y beta test. Esta fase es la última (antes de ite-
rar, según el modelo empleado) que se aplica al ciclo de
vida del desarrollo de software. La fase de mantenimiento
4.2.5 Instalación y paso a producción es la que viene después de que el software está operativo
y en producción.
La instalación del software es el proceso por el cual los De un buen diseño y documentación del desarrollo de-
programas desarrollados son transferidos apropiadamen- penderá cómo será la fase de mantenimiento, tanto en
te al computador destino, inicializados, y, eventualmente, costo temporal como monetario. Modificaciones realiza-
configurados; todo ello con el propósito de ser ya utiliza- das a un software que fue elaborado con una documen-
dos por el usuario final. Constituye la etapa final en el tación indebida o pobre y mal diseño puede llegar a ser
desarrollo propiamente dicho del software. Luego de ésta tanto o más costosa que desarrollar el software desde el
el producto entrará en la fase de funcionamiento y pro- inicio. Por ello, es de fundamental importancia respetar
ducción, para el que fuera diseñado. debidamente todas las tareas de las fases del desarrollo y
14 5 CARÁCTER EVOLUTIVO DEL SOFTWARE

mantener adecuada y completa la documentación. El software evoluciona sencillamente por que se debe
El período de la fase de mantenimiento es normalmente adaptar a los cambios del entorno, sean funcionales (exi-
el mayor en todo el ciclo de vida.[7] Esta fase involucra gencias de usuarios), operativos, de plataforma o arqui-
también actualizaciones y evoluciones del software; no tectura hardware.
necesariamente implica que el sistema tuvo errores. Uno La dinámica de evolución del software es el estudio de
o más cambios en el software, por ejemplo de adaptación los cambios del sistema. La mayor contribución en es-
o evolutivos, puede llevar incluso a rever y adaptar desde ta área fue realizada por Meir M. Lehman y Belady, co-
parte de las primeras fases del desarrollo inicial, alterando menzando en los años 70 y 80. Su trabajo continuó en la
todas las demás; dependiendo de cuán profundos sean los década de 1990, con Lehman y otros investigadores[18] de
cambios. El modelo cascada común es particularmente relevancia en la realimentación en los procesos de evolu-
costoso en mantenimiento, ya que su rigidez implica que ción (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 conjun-
alteraciones en las demás fases del ciclo de vida. to de leyes (conocidas como leyes de Lehman)[9] respec-
Durante el período de mantenimiento, es común 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 hipótesis) son invariantes y ampliamente
beran más depurado, con mayor y mejor funcionalidad, aplicables.
mejor rendimiento, etc. Varias son las facetas que pue- Lehman y Belady analizaron el crecimiento y la evolu-
den ser alteradas para provocar cambios deseables, evo- ción de varios sistemas software de gran porte; derivando
lutivos, adaptaciones o ampliaciones y mejoras. finalmente, según sus medidas, las siguientes ocho leyes:
Básicamente se tienen los siguientes tipos de cambios:
1. Cambio continuo: Un programa que se usa en un en-
• Perfectivos: Aquellos que llevan a una mejora de torno real necesariamente debe cambiar o se volverá
la calidad interna del software en cualquier aspec- progresivamente menos útil en ese entorno.
to: Reestructuración del código, definición más cla- 2. Complejidad creciente: A medida que un programa
ra del sistema y su documentación; optimización del en evolución cambia, su estructura tiende a ser cada
rendimiento y eficiencia. vez más compleja. Se deben dedicar recursos extras
• Evolutivos: Agregados, modificaciones, incluso eli- para preservar y simplificar la estrucutura.
minaciones, necesarias en el software para cubrir su
3. Evolución prolongada del programa: La evolución
expansión o cambio, según las necesidades del usua-
de los programas es un proceso autorregulativo. Los
rio.
atributos de los sistemas, tales como tamaño, tiempo
• Adaptivos: Modificaciones que afectan a los entor- entre entregas y la cantidad de errores documenta-
nos en los que el sistema opera, tales como: Cambios dos son aproximadamente invariantes para cada en-
de configuración del hardware (por actualización o trega del sistema.
mejora de componentes electrónicos), cambios en
4. Estabilidad organizacional: Durante el tiempo de vi-
el software de base, en gestores de base de datos, en
da de un programa, su velocidad de desarrollo es
comunicaciones, etc.
aproximadamente constante e independiente de los
• Correctivos: Alteraciones necesarias para corregir recursos dedicados al desarrollo del sistema.
errores de cualquier tipo en el producto software
desarrollado. 5. Conservación de la familiaridad: Durante el tiempo
de vida de un sistema, el cambio incremental en cada
entrega es aproximadamente constante.
5 Carácter evolutivo del software 6. Crecimiento continuado: La funcionalidad ofrecida
por los sistemas tiene que crecer continuamente para
El software es el producto derivado del proceso de desa- mantener la satisfacción de los usuarios.
rrollo, según la ingeniería de software. Este producto es
intrínsecamente evolutivo durante su ciclo de vida. El 7. Decremento de la calidad: La calidad de los sistemas
software evoluciona, en general, generando versiones ca- software comenzará a disminuir a menos que dichos
da vez más completas, complejas, mejoradas, optimiza- sistemas se adapten a los cambios de su entorno de
das en algún aspecto, adecuadas a nuevas plataformas funcionamiento.
(sean de hardware o sistemas operativos), etc.[17] 8. Realimentación del sistema: Los procesos de evolu-
Cuando un sistema deja de evolucionar, eventualmente ción incorporan sistemas de realimentación multi-
cumplirá con su ciclo de vida, entrará en obsolescencia e agente y multibucle y estos deben ser tratados como
inevitablemente, tarde o temprano, será reemplazado por sistemas de realimentación para lograr una mejora
un producto nuevo. significativa del producto.
 15

6 Referencias 7 Bibliografía
[1] Diccionario de la lengua española 2005 (2010). wordre- 7.1 Libros
[Link], ed. «software» (diccionario). Espasa-Calpe.
Consultado el 1 de febrero de 2010. • JACOBSON, Ivar; BOOCH, Grady; RUM-
[2] Real Academia Española. «Significado de la palabra Soft- BAUGH, James (2000). El Proceso Unificado de
ware». Diccionario de la Lengua Española, XXIIº Edición. Desarrollo de Software. Pearson Addisson-Wesley.
Consultado el 14 de marzo de 2008.
• Pressman, Roger S. (2003). Ingeniería del Software,
[3] Real Academia Española. «Uso de la palabra Software».
un enfoque Práctico (Quinta edición edición). Mc
Diccionario panhispánico de dudas, 1.° Edición (octubre
Graw Hill. ISBN 84-481-3214-9.
de 2005). Consultado el 8 de febrero de 2009.

[4] Pressman, Roger S. (2003). «El producto». Ingeniería del • JACOBSON; BOOCH; RUMBAUGH (1999).
software, un enfoque práctico, Quinta edición edición. Mé- UML - El Lenguaje Unificado de Modelado.
xico: Mc Graw Hill. Pearson Addisson-Wesley. Rational Software Cor-
[5] IEEE Std, IEEE Software Engineering Standard: Glossary
poration, Addison Wesley Iberoamericana. ISBN
of Software Engineering Terminology. IEEE Computer 84-7829-028-1.
Society Press, 1993
• Haeberer, A. M.; P. A. S. Veloso, G. Baum (1988).
[6] «Ciclo de Vida del Software». Grupo Alarcos - Escuela Formalización del proceso de desarrollo de software
Superior de Informática de Ciudad Real. Archivado desde
(Ed. preliminar edición). Buenos Aires: Kapelusz.
el original el 29 de noviembre de 2015.
ISBN 950-13-9880-3.
[7] Pressman, Roger S. (2003). «El proceso». Ingeniería del
Software, un enfoque Práctico, Quinta edición edición. Mé- • Fowler, Martin; Kendall Sccott (1999). UML Gota a
xico: Mc Graw Hill. Gota. Addison Wesley. ISBN 9789684443648.
[8] «Término “Elicitar"». 1ra. acepción - Wiktionary. Con-
sultado el 15 de diciembre de 2008. • Loucopoulos, Pericles; Karakostas, V. (1995). Sys-
tem Requirements Engineering (en inglés). London:
[9] «Leyes de evolución del Software». Connexions - Educa- McGraw-Hill Companies. pp. 160 p. ISBN 978-
tional content repository. 0077078430.
[10] «Ciclo de vida del Software y Modelos de desarrollo». Ins-
tituto de Formación Profesional - Libros Digitales. Archi- • Sommerville, Ian; P. Sawyer (1997). Requirements
vado desde el original el 29 de noviembre de 2015. Texto Engineering: A Good Practice Guide (en inglés) (1ra.
« lugar: Asunción del Paraguay» ignorado (ayuda) edition edición). Wiley & Sons. pp. 404 p. ISBN 978-
0471974444.
[11] «Evolución del Software». Connexions - Educational con-
tent repository.
• Gottesdiener, Ellen; P. Sawyer (2002). Require-
[12] Software Requirements Engineering, 2nd Edition, IEEE ments by Collaboration: Workshops for Defining
Computer Society. Los Alamitos, CA, 1997 (Compendio Needs (en inglés). Addison-Wesley Professional. pp.
de papers y artículos en ingeniería de requisitos) 368 p. ISBN 978-0201786064.
[13] «III Workshop de Engenharia de Requisitos». WER 2000,
Río de Janeiro, 2000. • Sommerville, Ian (2005). Ingeniería del software
(7ma. edición). Madrid: Pearson Educación S.A.
[14] «Recommended Practice for Software Requirements ISBN 84-7829-074-5.
Specification». IEEE-SA Standards Board.

[15] «LEL y Escenarios como metodología en Ingeniería de

7.2 Artículos y revistas
Requisitos». Univ. de Morón, Buenos Aires.

[16] «Metodología para el análisis de Requisitos de Sistemas • Weitzenfeld - «El Proceso para Desarrollo de Soft-
Software». Univ. de Sevilla, 2001. ware» - 2002

[17] Sommerville, Ian (2005). «21-Evolución del software». • Carlos Reynoso - «Métodos Heterodoxos en Desa-
Ingeniería del Software. España: Pearson Educación S.A. rrollo de Software» - 2004

[18] «ACM Fellow Profile for Meir M. (Manny) Lehman». • Grupo ISSI - Univ. Politécnica de Valencia - «Me-
ACM. 31 de mayo de 2007. Consultado el 27 de noviem- todologías Ágiles en el Desarrollo de Software» -
bre de 2011. 2003
16 9 ENLACES EXTERNOS

• Martin Fowler - «La Nueva Metodología» - 2003

• Cutter IT Journal – «Requirements Engineering and

Management». August 25, 2000. Cutter Consor-
tium.
• «Software Requirements Engineering», 2nd Edi-
tion, IEEE Computer Society. Los Alamitos, CA,
1997 (Compendio de papers y artículos en ingenie-
ría de requisitos).
• Lehman, M.M. - «Laws of Software Evolution Re-
visited», pos. pap., EWSPT96, Oct. 1996, LNCS
1149, Springer Verlag, 1997, pp. 108-124

8 Véase también

• Portal:Software. Contenido relacionado con

Software.

• Ingeniería de software
• Programa informático

• Aplicación informática
• Programación

• Fases del desarrollo de software

• Software colaborativo

• Software libre
• Ingeniería informática

• Hediondez del código

8.1 Modelos de ciclo de vida

• Modelo en cascada o secuencial

• Modelo iterativo incremental

• Modelo evolutivo espiral

• Modelo de prototipos
• Modelo de desarrollo rápido

9 Enlaces externos

• Wikimedia Commons alberga contenido multi-

media sobre SoftwareCommons.

• Wikcionario tiene definiciones y otra informa-

ción sobre [Link]
 17

10 Origen del texto y las imágenes, colaboradores y licencias

10.1 Texto
• Software Fuente: [Link] Colaboradores: Youssefsan, Macar~eswiki, Mac, Oblongo, Sab-
but, Sauron, JorgeGG, Pieter, Lourdes Cardenal, Julie, Angus, Rumpelstiltskin, Comae, Aloriel, Dodo, Ejmeza, Faustito, Ejrrjs, Jynus,
SimónK, 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 Mathema-
ticae, 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, Banfield, Muramasa, Kepler Oort, Maldoror, Tabeissan, Er Komandan-
te, 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 Acquis-
tapace, Renebeto, -jem-, Alexav8, [Link], 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, And-
ya, PhJ, Rafadose, Cratón, Isha, Bernard, Chuck es dios, Gusgus, Góngora, Mpeinadopa, Jabrahamdc, JAnDbot, Jugones55, JuanPaBJ16,
VanKleinen, Kved, Mansoncc, Muro de Aguas, Vladimirdlc, Gaius iulius caesar, Iulius1973, Zufs, Gsrdzl, Beaire1, Museobichoxp, Com-
monsDelinker, TXiKiBoT, Lovecat1024, Izzues, Gustronico, Gacq, Elisardojm, Humberto, Netito777, Jlinfante, Warcraft~eswiki, Xpel1,
ZrzlKing, Amanuense, Chabbot, MotherForker, Idioma-bot, Qoan, Software~eswiki, Pólux, Biasoli, Bucephala, Cipión, Cinevoro, Ale-
ja 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 Germán Guglielmetti, Ctrl Z, PaintBot, Ensada, Yiyi3, Carmin, Vi-
llasephiroth, Drinibot, Bigsus-bot, Marcelo, Mel 23, OboeCrack, [Link], Manwë, Greek, Lobo, BuenaGente, Mafores, Chico512,
Tirithel, Mutari, Prietoquilmes, Jarisleif, Javierito92, Marcecoro, UsuarioRafaelgarcia, HUB, Nicop, DragonBot, Farisori, EDGARNI-
CE1, McMalamute, Eduardosalg, Paquete, Leonpolanco, Petruss, Walter closser, Poco a poco, BetoCG, CestBOT, Takashi kurita, Papo-
rrubio, Açipni-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, Diegusjai-
mes, DumZiBoT, MelancholieBot, Laisladelsol, Wikijens, Sdepares, Arjuno3, Saloca, Madalberta, Andreasmperu, Luckas-bot, Dalton2,
Wesker J, Nallimbot, Ptbotgourou, Jotterbot, Cainite, Letuño, Vic Fede, Angelsaracho, Cfga, Dangelin5, Jorge 2701, ANAYSNARK,
Monkey in Your Tank, Nixón, ArthurBot, RadiX, Inventionary, SuperBraulio13, Manuelt15, Xqbot, Jkbw, Dreitmen, Dossier2, Cally
Berry, Savig, Carol1221, Ricardogpn, Kismalac, Igna, Torrente, Botarel, MauritsBot, Panderine!, MAfotBOT, Hprmedina, TobeBot, Ca-
ritdf, RedBot, Fidelleandro, DixonDBot, Jesuscc29, Alfredalva, AnselmiJuan, Born2bgratis, TorQue Astur, Emporio2012, KamikazeBot,
Dinamik-bot, Tarawa1943, Jorge c2010, Wikiléptico, Axvolution, Edslov, Franco Slad, EmausBot, Savh, HRoestBot, ChessBOT, Sergio
Andres Segovia, LeafGreen, Cornelhac1, Grillitus, KLBot, Eder589, Rubpe19, MercurioMT, Emiduronte, Jcaraballo, Bpk, Cedecomsa,
MadriCR, Waka Waka, Laurauda, Lauratomsig, Tokvo, Alexander20102010, Peterkingalexander, Arezitopedia, Cesar fuente, Marly ya-
neth, Antonorsi, Abián, Herny gay, MerlIwBot, Gara4514, KLBot2, Talkahe, UAwiki, Sebrev, Ginés90, Invadibot, Kbronson, DerKrieger,
Allan Aguilar, Chico del Pantano, Acratta, Ihernandezsa, Vetranio, Elvisor, Alexanderrojas1, Helmy oved, Makecat-bot, Armonizador,
2rombos, Brianrock97, MaKiNeoH, Neptunia, Legobot, Mininogatito, Lautaro 97, Jean70000, Addbot, AnonymousCmc, Balles2601,
Diegogalicia27, XVRT, ConnieGB, JacobRodrigues, Anonymus2013, Gazpachero, Monicagdl, Troloman777, Higuita02, Zzzzzzzz1710,
Jarould, Bruno Rene Vargas, Crystallizedcarbon, BenjaBot, 4lextintor, Sfr570, Aramiza, Analiac03, Andresmoreno234, Rolando Hedec-
kel, Fernando2812l, Carlosebastian, Ks-M9, JUAN TUS MUERTOS, Trevorzx34, Nikolei Falkon, Saraliceth, Grupouoc, Thegaimer27 y
Anónimos: 1093

10.2 Imágenes
• Archivo:Buscador_de_Programas_en_Ubuntu_13.[Link] Fuente: [Link]
de_Programas_en_Ubuntu_13.[Link] Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Julian Andres
• Archivo:Commons-emblem-question_book_yellow.svg Fuente: [Link]
Commons-emblem-question_book_yellow.svg Licencia: CC BY-SA 3.0 Colaboradores: <a href='//[Link]/wiki/File:
[Link]' class='image'><img alt='[Link]' src='[Link]
commons/thumb/c/c5/[Link]/[Link]' width='25' height='25' srcset='https:
//[Link]/wikipedia/commons/thumb/c/c5/[Link]/[Link] 1.5x,
[Link]
2x' data-file-width='48' data-file-height='48' /></a> + <a href='//[Link]/wiki/File:Question_book.svg'
class='image'><img alt='Question [Link]' src='[Link]
svg/25px-Question_book.[Link]' width='25' height='20' srcset='[Link]
Question_book.svg/38px-Question_book.[Link] 1.5x, [Link]
svg/50px-Question_book.[Link] 2x' data-file-width='252' data-file-height='199' /></a> Artista original: GNOME icon artists, Linfocito
B
• Archivo:[Link] Fuente: [Link] Licencia: Public do-
main 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:[Link] Fuente: [Link]
[Link] Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Happy Mr Me-
mebot
• Archivo:LibreOffice_Writer_4.[Link] Fuente: [Link]
[Link] Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio, The Document Foundation para la imagen del programa, texto y foto
del artículo “Nebulosa del Cangrejo” de la Wikipedia en español Artista original: German
18 10 ORIGEN DEL TEXTO Y LAS IMÁGENES, COLABORADORES Y LICENCIAS

• Archivo:[Link] Fuente: [Link]

[Link] Licencia: GFDL Colaboradores: ? Artista original: ?
• Archivo:Modelo_Cascada_Secuencial.jpg Fuente: [Link]
[Link] Licencia: CC-BY-SA-3.0 Colaboradores: ? Artista original: ?
• Archivo:Modelo_Espiral_Boehm.jpg Fuente: [Link] Li-
cencia: CC-BY-SA-3.0 Colaboradores: Trabajo propio Artista original: SergioN
• Archivo:Modelo_Gral_Evolutivo_Incremental.jpg Fuente: [Link]
Evolutivo_Incremental.jpg Licencia: CC-BY-SA-3.0 Colaboradores: Trabajo propio Artista original: SergioN
• Archivo:Modelo_Iterativo_Incremental.jpg Fuente: [Link]
[Link] Licencia: CC BY 3.0 Colaboradores: Trabajo propio Artista original: SergioN
• Archivo:Nuvola_devices_cdrom_unmount.png Fuente: [Link]
cdrom_unmount.png Licencia: LGPL Colaboradores: [Link] Artista original: David Vignoni / ICON KING
• Archivo:Proceso_Ing_Requisitos.jpg Fuente: [Link] Li-
cencia: 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:[Link] Fuente: [Link] Licencia: CC
BY-SA 3.0 Colaboradores: originally uploaded there by author, self-made by author Artista original: es:Usuario:Pybalo

10.3 Licencia del contenido

• Creative Commons Attribution-Share Alike 3.0