Software

Palabra proveniente del inglés , que en nuestro idioma no posee una traducción
adecuada al contexto, por lo cual se la utiliza asíduamente sin traducir y fue adoptada
por la Real Academia Española (RAE). Se refiere al equipamiento lógico o soporte
lógico de un computador digital, comprende el conjunto de los componentes lógicos
necesarios para hacer posible la realización de una tarea específica, en
contraposición a los componentes físicos del sistema (hardware). Tales componentes
lógicos incluyen, entre otras, aplicaciones informáticas tales como procesador de
textos, que permite al usuario realizar todas las tareas concernientes a edición de
textos; software de sistema, tal como un sistema operativo, el que, básicamente,
permite al resto de los programas funcionar adecuadamente, facilitando la interacción
con los componentes físicos y el resto de las aplicaciones, también provee una
interface ante el usuario.

Bajo esta definición, el concepto de software va más allá de los programas de cómputo
en sus distintos estados: código fuente, binario o ejecutable; también su
documentación, datos a procesar e información de usuario es parte del software: es
decir, abarca todo lo intangible, todo lo "no físico" relacionado.

El término «software» fue usado por primera vez en este sentido por John W. Tukey
en 1957. En las ciencias de la computación y la ingeniería de software, el software es
toda la información procesada por los sistemas informáticos: programas y datos. El
concepto de leer diferentes secuencias de instrucciones desde la memoria de un
dispositivo para controlar los cálculos fue introducido por Charles Babbage como parte
de su máquina diferencial. La teoría que forma la base de la mayor parte del software
moderno fue propuesta por vez primera por Alan Turing en su ensayo de 1936, "Los
números computables", con una aplicación al problema de decisión.

Clasificación del software

Si bien esta distinción es, en cierto modo, arbitraria, y a veces confusa, se puede
clasificar al software de la siguiente forma:

• Software de sistema: Es aquel que permite que el hardware funcione. Su

objetivo es desvincular adecuadamente al programador de los detalles del
computador en particular que se use, aislándolo especialmente del
procesamiento referido a las características 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 y utilidades de apoyo que permiten su mantenimiento.
Incluye entre otros:
o Sistemas operativos
o Controladores de dispositivo
o Herramientas de diagnóstico
o Herramientas de Corrección y Optimización
o Servidores
o Utilidades
• Software de programación: Es el conjunto de herramientas que permiten al
programador desarrollar programas informáticos, usando diferentes alternativas
y lenguajes de programación, de una manera práctica. Incluye entre otros:
o Editores de texto
o Compiladores
o Intérpretes
 o Enlazadores
o Depuradores
o Entornos de Desarrollo Integrados (IDE): Agrupan las anteriores
herramientas, usualmente en un entorno visual, de forma que el
programador no necesite introducir múltiples comandos para compilar,
interpretar, depurar, etc.. Habitualmente cuentan con una avanzada
interfaz gráfica de usuario (GUI).
• Software de aplicación: Aquel que permite a los usuarios llevar a cabo una o
varias tareas específicas, en cualquier campo de actividad susceptible de ser
automatizado o asistido, con especial énfasis en los negocios. Incluye entre
otros:
o Aplicaciones de Sistema de control y automatización industrial
o Aplicaciones ofimáticas
o Software educativo
o Software médico
o Software de Cálculo Numérico
o Software de Diseño Asistido (CAD)
o Software de Control Numérico (CAM)

Proceso de creación de software

Se define como Proceso al conjunto ordenado de pasos a seguir para llegar a la

solución de un problema u obtención de un producto, en este caso particular, para
lograr la obtención de un producto software que resuelva un problema.

Ese proceso de creación de software puede llegar a ser muy complejo, dependiendo
de su porte, características y criticidad del mismo. Por ejemplo la creación de un
sistema operativo es una tarea que requiere proyecto, gestión, numerosos recursos y
todo un equipo disciplinado de trabajo. En el otro extremo, si se trata de un sencillo
programa (ejemplo: resolución de una ecuación de segundo orden), éste puede ser
realizado por un solo programador (incluso aficionado) fácilmente. Es así que
normalmente se dividen en tres categorías según su tamaño (líneas de código) y/o
costo: de Pequeño, Mediano y Gran porte. Existen varias metodologías para
estimarlo, una de las más populares es el sistema COCOMO que provee métodos y
un software (programa) que calcula estimadamente todos los costos de producción en
un "proyecto software" (relación horas/hombre, costo monetario, cantidad de líneas
fuente de acuerdo a lenguaje usado, etc.).

Considerando los de gran porte, es necesario realizar tantas y tan complejas tareas,
tanto técnicas, de gerenciamiento, fuerte gestión y análisis diversos (entre otras) que
toda una ingeniería hace falta para su estudio y realización: es la Ingeniería de
Software.

En tanto que en los de mediano porte, pequeños equipos de trabajo (incluso un

avesado analista-programador solitario) puede realizar la tarea. Aunque, siempre en
casos de mediano y gran porte (y a veces también en algunos de pequeño porte,
según su complejidad), se deben seguir ciertas etapas que son necesarias para la
construcción del software. Tales etapas, si bien deben existir, son flexibles en su forma
de aplicación, de acuerdo a la metodología o Proceso de Desarrollo escogido y
utilizado por el equipo de desarrollo o analista-programador solitario (si fuere el caso).

Los "procesos de desarrollo de software" poseen reglas preestablecidas, y deben

ser aplicados en la creación del software de mediano y gran porte, ya que en caso
contrario lo más seguro es que el proyecto o 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; y normalmente se aplican de acuerdo al
tipo y porte y tipología del software a desarrollar, a criterio del líder (si lo hay) del
equipo de desarrollo. Algunos de esos procesos son Extreme Programming (XP),
Rational Unified Process (RUP), Feature Driven Development (FDD), etc.

Cualquiera sea el "proceso" utilizado y aplicado en un desarrollo de software (RUP,

FDD, etc), y casi independientemente de él, siempre se debe aplicar un "Modelo de
Ciclo de Vida".

Se estima que, del total de proyectos software grandes emprendidos, un 28%

fracasan, un 46% caen en severas modificaciones que lo retrazan y un 26% son
totalmente exitosos. Cuando un proyecto fracasa, rara vez es debido a fallas técnicas,
la principal causa de fallos y fracasos es la falta de aplicación de una buena
metodología o proceso de 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 profesionales en su utilización adecuada. Normalmente los
especialistas en el estudio y desarrollo de estas áreas (metodologías) y afines (tales
como modelos y hasta la gestión misma de los proyectos) son los Ingenieros en
Software, es su orientación. Los especialistas en cualquier otra área de desarrollo
informático (analista, programador, Lic. en Informática, Ingeniero en Informática,
Ingeniero de Sistemas, etc.) normalmente aplican sus conocimientos especializados
pero utilizando modelos, paradigmas y procesos ya elaborados.

Es común para el desarrollo de software de mediano porte que los equipos humanos
involucrados apliquen sus propias metodologías, normalmente un híbrido de los
procesos anteriores y a veces con criterios propios.

El proceso de desarrollo puede involucrar numerosas y variadas tareas, desde lo

administrativo, pasando por lo técnico y hasta la gestión y el gerenciamiento. Pero
casi rigurosamente siempre se cumplen ciertas etapas mínimas; las que se pueden
resumir como sigue:

• Captura (elicitación), Especificación y Análisis de requisitos (ERS)

• Diseño
• Codificación
• Pruebas (unitarias y de integración)
• Instalación y paso a Producción
• Mantenimiento

En las anteriores etapas pueden variar ligeramente sus nombres, o ser más globales, o
contrariamente más refinadas; por ejemplo indicar como una única fase (a los fines
documentales e interpretativos) de "Análisis y Diseño"; o indicar como
"Implementación" lo que está dicho como "Codificación"; pero en rigor, todas existen e
incluyen, básicamente,las mismas tareas específicas.

En el apartado 4 del presente artículo se brindan mayores detalles de cada una de las
listadas etapas.

Modelos de Proceso o Ciclo de Vida

Para cada una las fases o etapas listadas en el ítem anterior, existen sub-etapas (o
tareas). El Modelo de Proceso o Modelo de Ciclo de Vida utilizado para el desarrollo
define el orden para las tareas o actividades involucradas, también definen la
coordinación entre ellas, enlace y realimentación entre las mencionadas etapas. Entre
los más conocidos se puede mencionar: Modelo en Cascada o secuencial, Modelo
Espiral, Modelo Iterativo Incremental. De los antedichos hay a su vez algunas
variantes o alternativas, más o menos atractivas según sea la aplicación requerida y
sus requisitos.

Modelo Cascada

El Modelo en cascada puro (conocido también como secuencial) difícilmente se

utilice tal cual, pues esto implicaría un previo y absoluto conocimiento de los
requisitos, la no volatilidad de los mismos (o rigidéz) y etapas subsiguientes libres de
errores; ello sólo podría ser aplicable a escasos y pequeños desarrollos de sistemas.
En estas circunstancias, el paso de una etapa a otra de las mencionadas sería sin
retorno, por ejemplo pasar del Diseño a la Codificación implicaría un diseño exacto y
sin errores ni probable modificación o evolución: "codifique lo diseñado que no habrán
en absoluto variantes ni errores". Esto es utópico; ya que intríncecamente el software
es de carácter evolutivo, cambiante y difícilmente libre de errores, tanto durante su
desarrollo como durante su vida operativa.

Algún cambio durante la ejecución de una cualquiera de las etapas en este modelo
secuencial implicaría reinciar desde el principio todo el ciclo completo, lo cual
redundaría en altos costos de tiempo y desarrollo.Sin embargo, el modelo cascada
en algunas de sus variantes es uno de los más utilizados, por su eficacia y
simplicidad, más que nada en software de pequeño y algunos de mediano porte; pero
nunca (o muy rara vez) se lo usa en su forma pura, como se dijo anteriormente. En
lugar de ello, siempre se produce alguna realimentación entre etapas, que no es
completamente predecible ni rígida; esto da oportunidad al desarrollo de productos
software en los cuales hay ciertas incertezas, cambios o evoluciones durante el ciclo
de vida. Así por ejemplo, una vez capturados (elicitados) y especificados los requisitos
(primera etapa) se puede pasar al diseño del sistema, pero durante esta última fase lo
más probable es que se deban realizar ajustes en los requisitos (aunque sean
mínimos), ya sea por fallas detectadas, ambiguedades o bien por que los propios
requisitos han cambiado o evolucionado; con lo cual se debe retornar a la primera o
previa etapa, hacer los pertinentes reajustes y luego continuar nuevamente con el
diseño; esto último se conoce como realimentación. Lo normal en el modelo cascada
será entonces la aplicación del mismo con sus etapas realimentadas de alguna forma,
permitiendo retroceder de una a la anterior (e incluso poder saltar a varias anteriores)
si es requerido.

Lo dicho es, a grandes rasgos, la forma y utilización de este modelo, uno de los más
usados y populares. El modelo Cascada Realimentado resulta muy atractivo, hasta
ideal, si el proyecto presenta alta rigidéz (pocos o ningún cambio, no evolutivo), los
requisitos son muy claros y están correctamente especificados.

Hay más variantes similares al modelo: refino de etapas (más estapas, menores y más
específicas) e 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 lógico y adecuado, pero adviértase, como se dijo, que normalmente habrá
realimentación hacia atrás.

Etapas en el Desarrollo de Software

Captura, Análisis y Especificación de requisitos

Al inicio de un desarrollo (no de un proyecto), esta es la primera fase que se realiza, y,
según el modelo de proceso adoptado, puede casi terminar para pasar a la próxima
etapa (caso Moldelo Cascada Realimentado) o puede hacerse parcialmente para
luego retomarla (caso Modelo Iterativo Incremental u otros de carácter evolutivo).

En simple palabras y básicamente, durante esta fase, se adquieren, reúnen y

especifican las características funcionales y no funcionales que deberá cumplir el futuro
programa o sistema a desarrollar.

Las bondades de las características, tanto del sistema o programa a desarrollar, como
de su entorno, parámetros no funcionales y arquitectura dependen enormemente de lo
bien lograda que esté esta etapa. Esta es, problablemente, la de mayor importancia y
una de las fases más difíciles de lograr certeramente, pues no es automatizable, no es
muy técnica y depende en gran medida de la habilidad y experiencia del analista que
la realice.

Involucra fuertemente al usuario o cliente del sistema, por tanto tiene matices muy
subjetivos y es difícil de modelar con certeza y/o aplicar una técnica que sea "la más
cercana a la adecuada" (de hecho no existe "la estrictamente adecuada"). Si bien se
han ideado varias metodologías, incluso software de apoyo, para captura, elicitación y
registro de requisitos, no existe una forma infalible o absolutamente confiable, y deben
aplicarse conjuntamente buenos criterios y mucho sentido común por parte del o los
analistas encargados de la tarea; es fundamental también lograr una fluída y
adecuada comunicación y comprención con el usuario final o cliente del sistema.

El artefacto más importante resultado de la culminación de esta etapa es lo que se

conoce como Especificación de Requisitos Software o simplemente documento ERS.

Como se dijo, la habilidad del analista para interactuar con el cliente es fundamental; lo
común es que el cliente tenga un objetivo general o problema a resolver, no conoce en
absoluto el área (informática), ni su jerga, ni siquiera sabe con presición qué debería
hacer el producto software (qué y cuantas funciones) ni, mucho menos, cómo debe
operar. En otros casos menos frecuentes, el cliente "piensa" que sabe precisamente lo
que el software tiene que hacer, y generalmente acierta muy parcialmente, pero su
empecinamiento entorpece la tarea de elicitación. El analista debe tener la capacidad
para lidiar con este tipo de problemas, que incluyen relaciones humanas; tiene que
saber ponerse al nivel del usuario para permitir una adecuada comunicación y
comprención.

Escasas son las situaciones en que el cliente sabe con certeza e incluso con
completitud lo que requiere de su futuro sistema, este es el el caso más sencillo para el
analista.

La tareas relativas a captura, elicitación, modelado y registro de requerimientos,

además de ser sumamente importante, puede llegar a ser dificultosa de lograr
acertadamente y llevar bastante tiempo relativo al proceso total del desarrollo; al
proceso y metodologías para llevar a cabo este conjunto de actividades normalmente
se las asume parte propia de la Ingeniería de Software, pero dada la antedicha
complejidad, actualmente se habla de una Ingeniería en Requisitos , aunque ella aun
no existe formalmente.

Hay grupos de estudio e investigación, en todo el mundo, que están exclusivamente

abocados a la idear modelos, técnicas y procesos para intentar lograr la correcta
captura, análisis y registro de requerimientos. Estos grupos son los que normalmente
hablan de la Ingeniería en Requisitos; es decir se plantea ésta como un área o
disciplina pero no como una carrera universitaria en si misma.

Algunos requisitos no necesitan la presencia del cliente, para ser capturados y/o
analizados; en ciertos casos los puede proponer el mismo analista o, incluso, adoptar
unilateralmente decisiones que considera adecuadas (tanto en requerimientos
funcionales como no funcionales). Por citar ejemplos probables: Algunos requisitos
sobre la arquitectura del sistema, requisitos no funcionales tales como los relativos al
rendimiento, nivel de soporte a errores operativos, plataformas de desarrollo,
relaciones internas o ligas entre la información (entre registros o tablas de datos) a
almacenar en caso de bases o bancos de datos, etc. Algunos funcionales tales como
opciones secundarias o de soporte necesarias para una mejor o más sencilla
operatividad; etc.

La obtención de especificaciones a partir del cliente (u otros actores intervinientes) es

un proceso humano muy interactivo e iterativo; normalmente a medida que se captura
la información, se la analiza y realimenta con el cliente, refinándola, puliéndola y
corrigiendo si es necesario; cualquiera sea el método de ERS utilizado. EL analista
siempre debe llegar a conocer la temática y el problema a resolver, dominarlo, hasta
cierto punto, hasta el ámbito que el futuro sistema a desarrollar lo abarque. Por ello el
analista debe tener alta capacidad para comprender problemas de muy diversas áreas
o disciplinas de trabajo (que no son específicamente suyas); así por ejemplo, si el
sistema a desarrollar será para gestionar información de una aseguradora y sus
sucursales remotas, el analista se debe compenetrar en cómo ella trabaja y maneja su
información, desde niveles muy bajos e incluso llegando hasta los gerenciales. Dada a
gran diversidad de campos a cubrir, los analistas suelen ser asistidos por
especialistas, es decir gente que conoce profundamente el área para la cual se
desarrollará el software; evidentemente una única persona (el analista) no puede
abarcar tan vasta cantidad de áreas del conocimiento. En empresas grandes de
desarrollo de productos software, es común tener analistas especializados en ciertas
áreas de trabajo.

Contrariamente, no es problema del cliente, es decir él no tiene por qué saber nada de
software, ni de diseños, ni otras cosas relacionadas; sólo se debe limitar a aportar
objetivos, datos e información (de mano propia o de sus registros, equipos,
empleados, etc) al analista, y guiado por él, para que, en primera instancia, defina el
"Universo de Discurso", y con posterior trabajo logre confeccionar el adecuado
documento ERS.

Es bien conocida la presión que sufren los desarrolladores de sistemas informáticos

para comprender y/o rescatar las necesidades de los clientes/usuarios. Cuanto más
complejo es el contexto del problema más difícil es lograrlo, a veces se fuerza a los
desarrolladores a tener que convertirse en casi expertos de los dominios que analizan.

Cuando esto no sucede es muy probable que se genere un conjunto de requisitos

erróneos o incompletos y por lo tanto un producto de software con alto grado de
desaprobación por parte de los clientes/usuarios y un altísimo costo de reingeniería y
mantenimiento. Todo aquello que no se detecte, o resulte mal entendido en la etapa
inicial provocará un fuerte impacto negativo en los requisitos, propagando esta
corriente degradante a lo largo de todo el proceso de desarrollo e incrementando su
perjuicio cuanto más tardía sea su detección (Bell y Thayer 1976)(Davis 1993).
Procesos, modelado y formas de elicitación de requisitos

Siendo que la captura, elicitación y especificación de requisitos, es una parte crucial

en el proceso de desarrollo de software, ya que de esta etapa depende el logro de los
objetivos finales previstos, se han ideado modelos y diversas metodologías de trabajo
para estos fines. También existen herramientas software que apoyan las tareas
relativas realizadas por el ingeniero en requisitos.

El estándar IEEE 830-1998 brinda una normalización de las "Prácticas Recomendadas

para la Especificación de Requisitos Software" .

A medida que se obtienen los requisitos, normalmente se los va analizando, el

resultado de este análisis, con o sin el cliente, se plasma en un documento, conocido
como ERS o Especificación de Requisitos Software, cuya estructura puede venir
definida por varios estándares, tales como CMM-I.

Un primer paso para realizar el relevamiento de información es el conocimiento y

definición acertada lo que se 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á operar. El UdeD incluye todas las fuentes de
información y todas las personas relacionadas con el software. Esas personas
son conocidas también como actores de ese universo. El UdeD es la realidad
circunstanciada por el conjunto de objetivos definidos por quienes demandaron
el software.

A partir de la extracción y análisis de información en su ámbito se obtienen todas las

especificaciones necesarias y tipos de requisitos para el futuro producto software.

El objetivo de la Ingeniería de Requisitos (IR) es sistematizar el proceso de definición

de requisitos permitiendo elicitar, modelar y analizar el problema, generando un
compromiso entre los Ingenieros de Requisitos y los clientes/usuarios, ya que ambos
participan en la generación y 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 requerimientos lo más seguros, veraces, completos
y oportunos posibles, permitiendo básicamente:

• Comprender el problema
• Facilitar la obtención de las necesidades del cliente/usuario
• Validar con el cliente/usuario
• Garantizar las especificaciones de requisitos

Si bien existen diversas formas, modelos y metodologías para elicitar, definir y

documentar requerimientos, no se puede decir que alguna de ellas sea mejor o peor
que la otra, suelen tener muchísimo en común, y todas cumplen el mismo objetivo. Sin
embargo, lo que si se puede decir 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 argentino que desde hace varios años ha
propuesto y estudia el uso del LEL (Léxico Extendido del Lenguaje) y Escenarios
como metodología, aqui se presenta una de las tantas referencias y bibliografía sobre
ello. Otra forma, más ortodoxa, de capturar y documentar requisitos se puede obtener
en detalle, por ejemplo, en el trabajo de la Universidad de Sevilla sobre "Metodología
para el Análisis de Requisitos de Sistemas Software" .
En la Fig. 6 se muestra un esquema, más o menos riguroso, aunque no detallado, de
los pasos y tareas a seguir para realizar la captura, análisis y especificación de
requerimientos software. Tambien allí se observa qué artefacto o documento se
obtiene en cada etapa del proceso. En el diagrama no se explicita metodología o
modelo a utilizar, sencillamente se pautan las tareas que deben cumplirse, de alguna
manera.

Fig. 6 - Diagrama de tareas para captura y análisis de Requisitos

Una posible lista general y ordenada de tareas recomendadas para obtener la

definición de lo que se debe realizar,los productos a obtener y las técnicas a emplear
durante la actividad de elicitación de requisitos de la fase de ingeniería de requisitos
del desarrollo de software es:

• 1 - Obtener información sobre el dominio del problema y el sistema actual

(UdeD).
• 2 - Preparar y realizar las reuniones para elicitación/negociación.
• 3 - Identificar/revisar los objetivos del usuario.
• 4 - Identificar/revisar los objetivos del sistema.
• 5 - Identificar/revisar los requisitos de información.
• 6 - Identificar/revisar los requisitos funcionales.
• 7 - Identificar/revisar los requisitos no funcionales.
• 8 - Priorizar objetivos y requisitos.

Algunos principios básicos a tener en cuenta:

• Presentar y entender cabalmente el dominio de la información del problema.

• Definir correctamente las funciones que debe realizar el Software.

• Representar el comportamiento del software a consecuencias de

acontecimientos externos, particulares, incluso inesperados.

• Reconocer requisitos incompletos, ambiguos o contradictorios.

 • Dividir claramente los modelos que representan la información, las funciones y
comportamiento y características no funcionales.

Clasificación e identificación de requerimientos

Se pueden identificar dos formas de requisitos:

• Requisitos de usuario.

Los requisitos de usuario son frases en lenguaje natural junto a diagramas con
los servicios que el sistema debe proporcionar, así como las restricciones
bajo las que debe operar.

• Requisitos de sistema.

Los requisitos de sistema determinan los servicios del sistema y pero con las
restricciones en detalle. Sirven como contrato.

Es decir, ambos son lo mismo, pero con indicados con distinto nivel de detalle.

- Ej. req. usuario: El sistema debe hacer préstamos

- Ej. req. sistema: Función préstamo: entrada cód. socio, cód. ejemplar;
salida: fecha devolución; etc.

Se clasifican en tres los tipos de requisitos de sistema:

• 1 - Requisitos funcionales

Los requisitos funcionales describen:

- Los servicios que proporciona el sistema (funciones).
- La respuesta del sistema ante determinadas entradas.
- El comportamiento del sistema en situaciones particulares.

• 2 - Requisitos no funcionales

Los requisitos no funcionales son restricciones de los servicios o funciones que

ofrece el sistema (Ej. cotas de tiempo, proceso de desarrollo, rendimiento, etc.)
Ej1. La biblioteca Central debe ser capaz de atender simultáneamente a todas
las bibliotecas de la Universidad.
Ej2. El tiempo de respuesta a una consulta remota no debe ser superior a 1/2
seg.
A su vez, hay tres tipos de requisitos no funcionales:

o Requisitos del producto. Especifican el comportamiento del producto

(Ej. prestaciones, memoria, tasa de fallos, etc.)
o Requisitos organizativos. Se derivan de las políticas y procedimientos
de las organizaciones de los clientes y desarrolladores (Ej. estándares
de proceso, lenguajes de programación, etc.)
o Requisitos externos. Se derivan de factores externos al sistema y al
proceso de desarrollo (Ej. requisitos legislativos, éticos, etc.)

3 - Requisitos del dominio.

 Los requisitos del dominio se derivan del dominio de la aplicación y reflejan
características de dicho dominio.
Pueden ser funcionales o no funcionales.
Ej. El sistema de biblioteca de la Universidad debe ser capaz de exportar datos
mediante el Lenguaje de Intercomunicación de Bibliotecas de España (LIBE).
Ej. El sistema de biblioteca no podrá acceder a bibliotecas con material
censurado.

Diseño del Sistema

Codificación del software

Durante esta la etapa se realizan las tareas que comúnmente se conocen como
programación; que consiste, esencialmente, en llevar a código fuente, en el lenguaje
de programación elegido, todo lo diseñado en la fase anterior. Esta tarea la realiza el
programador, siguiendo por completo los lineamientos impuestos en el diseño y en
consideración siempre a los requisitos funcionales y no funcionales (ERS)
especificados en la primera etapa.

Es común pensar que la etapa de programación o codificación (algunos la llaman

implementación) 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 pequeño porte) ya que las etapas previas son cruciales, críticas y pueden llevar
bastante más tiempo. Se suele hacer estimaciones de un 30% del tiempo total
insumido en la programación, pero esta cifra no es consistente ya que depende en
gran medida de las características del sistema, su criticidad y el lenguaje de
programación elegido. En tanto menor es el nivel del lenguaje mayor será el tiempo de
programación requerido, así por ejemplo se tardaría más tiempo en codificar un
algoritmo en Assembly que el mismo programado en lenguaje C.

Mientras se programa la aplicacion, sistema, o software en general, se realizan

también tareas de depuración, esto es la labor de ir liberando al código de los errores
factibles de ser hallados en esta fase (de semántica, sintáctica y lógica). Hay una
suerte de solapamiento con la fase siguiente, ya que para depurar la lógica es
necesario realizar pruebas unitarias, normalmente con datos de prueba; claro es que
no todos los errores serán encontrados sólo en la etapa de programación, habrán otros
que se encontrarán durante las etapas sibsiguientes. La aparición de algún error
funcional (mala respuesta a los requerimientos) eventualmente puede llevar a retornar
a la fase de diseño antes de continuar la codificación.

Durante la fase de programación, el código puede adoptar varios estados,

dependiendo de la forma de trabajo y del lenguaje elegido, a saber:

• Código fuente: Es el escrito directamente por los programadores en editores

de texto, lo cual genera el programa. Contiene el conjunto de instrucciones
codificadas en algún lenguaje de alto nivel. Puede estar distribuido en
paquetes, procedimientos, librerías fuente, etc.

• Código objeto: Es el código binario o intermedio resultante de procesar con un

compilador el código fuente. Consiste en una traducción completa y de una
sola vez de éste último. El código objeto no es inteligible por el ser humano
(normalmente es formato binario) pero tampoco es directamente ejecutable por
la computadora. Se trata de una representación intermedia entre el código
fuente y el código ejecutable, a los fines de un enlace final con las rutinas de
 librería y entre procedimientos o bien para su uso con un pequeño intérprete
intermedio [a modo de distintos ejemplos véase EUPHORIA, (intérprete
intermedio), FORTRAN (compilador puro) MSIL (Microsoft Intermediate
Language) (intérprete) y BASIC (intéprete puro, intérprete intermedio,
compilador intermedio o compilador puro, depende de la versión utilizada)].
o El código objeto no existe si el programador trabaja con un lenguaje a
modo de intérprete puro, en este caso el mismo intérprete se encarga
de traducir y ejecutar línea por línea el código fuente (de acuerdo al
flujo del programa), en tiempo de ejecución. En este caso tampoco
existe el o los archivos de código ejecutable. Una desventaja de esta
modalidad es que la ejecución del programa o sistema es un poco más
lenta que si se hiciera con un intérprete intermedio, y bastante más lenta
que si existe el o los archivos de código ejecutable. Es decir no
favorece el rendimiento en velocidad de ejecución. Pero una gran
ventaja de la modalidad intérprete puro, es que el esta forma de trabajo
facilita enormemente la tarea de depuración del código fuente (frente a
la alternativa de hacerlo con un compilador puro). Frecuentemente se
suele usar una forma mixta de trabajo (si el lenguaje de programación
elejido lo permite), es decir inicialmente trabajar a modo de intérprete
puro, y una vez depurado el código fuente (liberado de errores) se
utiliza un compilador del mismo lenguaje para obtener el código
ejecutable completo, con lo cual se agiliza la depuración y la velocidad
de ejecución se optimiza.

Código ejecutable: Es el código binario resultado de enlazar uno o más fragmentos de

código objeto con las rutinas y librerías necesarias. Constituye uno o más archivos
binarios con un formato tal que el sistema operativo es capaz de cargarlo en la
memoria RAM (eventualmente también parte en una memoria virtual), y proceder a su
ejecución directa. Por lo anterior se dice que el código ejecutable es directamente
"inteligible por la computadora". El código ejecutable, también conocido como código
máquina, no existe si se programa con modalidad de "intérprete puro". Software libre
(en inglés free software) es la denominación del software que brinda libertad a los
usuarios sobre su producto adquirido y por tanto, una vez obtenido, puede ser usado,
copiado, estudiado, modificado y redistribuido libremente. Según la Free Software
Foundation, el software libre se refiere a la libertad de los usuarios para ejecutar,
copiar, distribuir, estudiar, cambiar y mejorar el software; de modo más preciso, se
refiere a cuatro libertades de los usuarios del software: la libertad de usar el programa,
con cualquier propósito; de estudiar el funcionamiento del programa, y adaptarlo a las
necesidades; de distribuir copias, con lo que puede ayudar a otros; de mejorar el
programa y hacer públicas las mejoras, de modo que toda la comunidad se beneficie
(para la segunda y última libertad mencionadas, el acceso al código fuente es un
requisito previo).

El software libre suele estar disponible gratuitamente, o al precio de coste de la

distribución a través de otros medios; sin embargo no es obligatorio que sea así, por
ende no hay que asociar software libre a "software gratuito" (denominado usualmente
freeware), ya que, conservando su carácter de libre, puede ser distribuido
comercialmente ("software comercial"). Análogamente, el "software gratis" o "gratuito"
incluye en algunas ocasiones el código fuente; no obstante, este tipo de software no
es libre en el mismo sentido que el software libre, a menos que se garanticen los
derechos de modificación y redistribución de dichas versiones modificadas del
programa.
Tampoco debe confundirse software libre con "software de dominio público". Éste último
es aquél que no requiere de licencia, pues sus derechos de explotación son para toda
la humanidad, porque pertenece a todos por igual. Cualquiera puede hacer uso de él,
siempre con fines legales y consignando su autoría original. Este software sería aquél
cuyo autor lo dona a la humanidad o cuyos derechos de autor han expirado, tras un
plazo contado desde la muerte de éste, habitualmente 70 años. Si un autor
condiciona su uso bajo una licencia, por muy débil que sea, ya no es dominio público.

Definición

Los expertos en el tema han consensuado en que estos dos referentes no son
antagónicos, sino casi sistemas hermanos, complementarios, con distintos énfasis. El
software libre se basa en el trabajo colaborativo, exaltando los lazos solidarios y
comunitarios que unen a la comunidad informática. El nacimiento de los programas se
basa en la puesta en escena de una idea, que es desarrollada anónimamente por la
comunidad informática, devuelta a ella, y a nuevos e imprevistos desarrollos. El trabajo
era gratuito, y los beneficios exclusivamente sociales. El open source, en cambio, nace
de iniciativas que pretenden acomodar o adaptar el free software a la realidad
empresarial. Los programas open source están hechos bajo la óptica de los negocios,
en la cual se otorgan derechos casi iguales a los del software libre, pero se paga por
servicios anexos (lo que en el software libre hace la comunidad, se puede también
encargar libremente a una empresa de expertos, y se paga también libremente un
precio). Mientras el primero es un modelo de negocios, el otro es "casi una ideología",
pero que funciona en su ámbito de acción.

Para unificar la terminología, utilizaremos en adelante la expresión programas de libre

distribución (PLD).

Ventajas de los programas de libre distribución

1.-)Costos: Los costos de una solución tecnológica van mucho más allá de Hardware y
Software Base, como por ejemplo , Infraestructura de Redes, Administración,
Instalación y Configuración, Actualizaciones, Ambiente (Energía, Aire acondicionado,
etc), Capacitación, etc. Los softwares propietarios pueden costar cientos o miles de
dólares. Linux, uno de los más famosos programas de libre distribución, puede
obtenerse, duplicarse e instalarse sin pagar por ningún tipo de licencia. El Software
propietario normalmente cobra por actualizaciones de bajo o medio impacto y exige
nuevas licencias para actualizaciones mayores. En el caso del SoL ninguna de estas
situaciones ocurre Eso si también existen alternativas para los que “quieren” pagar.

2).- Diversidad de soluciones informáticas: Además, existe una amplia flexibilidad de

combinar Software según las necesidades específicas, por lo que no existe el peligro o
la presión de perder soporte por parte un proveedor. Al estar disponible el código
fuente, siempre existen opciones para continuar con el soporte, sea un equipo
informático interno, u otro proveedor (en especial en proyectos importantes, como
Linux o Apache).

3).- Flexibilidad de las soluciones informáticas: Es frecuente que las grandes

organizaciones desarrollen herramientas orientadas a sus necesidades específicas. En
el caso de los programas de libre distribución, el usuario final tiene el control, y las
actualizaciones en los sistemas, se realizan en los términos del usuario final. Además
se realizan en función de los plazos y tiempos requeridos por éste. Se calcula que más
de un 70% de los servidores web del mundo están basados en el sistema operativo
GNU/Linux y demás software de libre distribución. Al mismo tiempo, empresas
multinacionales de ámbito informático, como IBM, Hewlett Packard, Apple y Sun,
ofrecen apoyo técnico, financiero y comercial al software libre.

4).-Los programas de libre distribución no son gratuitos, pero sí mucho más baratos:
Mediante la utilización de SoL se elimina el costo de licenciamiento. Sin embargo,
existen servicios relacionados por los cuales se puede pagar, como por ejemplo:
marca de la distribución, facilidad de Instalación y Configuración, actualizaciones, etc.
No obstante los programas de libre distribución son mucho menos costosos que la
administración de un programa propietario. Además la organización decide cuanto
gastar.

5).-Superioridad técnica de los programas de libre distribución: Se reconoce sin

ambages por la comunidad científica e informática que los prigramas propietarios son
inestables (la típica "caída de sistema es su más grande manifestación), así como
inseguros (se requieren resguardos adicionales contra los códigos espías que violan
la confidencialidad de los usuarios, sin perjuicio de que los programas propietarios,
son además, mucho más suceptibles a ser dañados por virus que los programas de
libre distribución). En el mundo del Software propietario algunos defectos pueden
afectar la disponibilidad o eficiencia del servicio. En general se negocian caros
contratos para minimizar la posibilidad de que esto ocurra. Sin embargo, siempre se
está a merced del proveedor. Si el proveedor no quiere hacer los cambios en el tiempo
que es requerido por el cliente no existen muchas opciones. En el caso de los
programas de libre distribución, la comunidad suele ser extremadamente veloz y
eficiente resolviendo problemas. Además existe la posibilidad de que un equipo externo
resuelva el problema.

6).-Beneficios sociales y comunitarios: Los programas de libre distribución abren una

interesante opción: toman una solución de uso general y la adaptan de forma de
satisfacer las necesidades específicas, permitiendo que esos cambios volverían a la
comunidad, quienes les darían soporte en el tiempo. Estos beneficios hacen que tanto
la cuidadanía como la comunidad científica e informática discuta a nivel mundial la
necesidad de que el Estado, tanto en su funcionamiento interno, como externo, utilice
programas de libre distribución. Es lo que veremos a continuación.

Libertades del software libre

De acuerdo con tal definición, el software es "libre" si garantiza las siguientes

libertades:

Libertad 0 Libertad 1 Libertad 2 Libertad 3

Ejecutar el Estudiar y Copiar el programa Mejorar el

programa con modificar el de manera que se programa y publicar
cualquier programa (para lo pueda ayudar al las mejoras
propósito (privado, cual es necesario vecino o a
educativo, público, poder acceder al cualquiera
comercial, militar, código fuente)
etc.)
 Es importante señalar que las libertades 1 y 3 obligan a que se tenga acceso al
código fuente.

La "libertad 2" hace referencia a la libertad de modificar y redistribuir el software

libremente licenciado bajo algún tipo de licencia de software libre que beneficie a la
comunidad.

Ciertos teóricos usan este cuarto punto (libertad 3) para justificar parcialmente las
limitaciones impuestas por la licencia GNU GPL frente a otras licencias de software
libre (ver Licencias GPL). Sin embargo el sentido original es más libre, abierto y menos
restrictivo que el que le otorga la propia situación de incompatibilidad, que podría ser
resuelta en la próxima versión 3.0 de la licencia GNU GPL, causa en estos momentos
graves perjuicios a la comunidad de programadores de software libre, que muchas
veces no pueden reutilizar o mezclar códigos de dos licencias distintas, pese a que las
libertades teóricamente lo deberían permitir.

En el sitio web oficial de OSI está la lista completa de las licencias de software libre
actualmente aprobadas y tenidas como tales.

El término software no libre se emplea para referirse al software distribuido bajo una
licencia de software más restrictiva que no garantiza estas cuatro libertades. Las leyes
de la propiedad intelectual reservan la mayoría de los derechos de modificación,
duplicación y redistribución para el dueño del copyright; el software dispuesto bajo
una licencia de software libre rescinde específicamente la mayoría de estos derechos
reservados.

La definición de software libre no contempla el asunto del precio; un eslogan

frecuentemente usado es "libre como en libertad, no como en cerveza gratis" o en
inglés "Free as in freedom, not as in free beer" (aludiendo a la ambigüedad del
término inglés "free"), y es habitual ver a la venta CDs de software libre como
distribuciones Linux. Sin embargo, en esta situación, el comprador del CD tiene el
derecho de copiarlo y redistribuirlo. El software gratis puede incluir restricciones que
no se adaptan a la definición de software libre —por ejemplo, puede no incluir el
código fuente, puede prohibir explícitamente a los distribuidores recibir una
compensación a cambio, etc—.

Para evitar la confusión, algunas personas utilizan los términos "libre" (Libre software)
y "gratis" (Gratis software) para evitar la ambigüedad de la palabra inglesa "free". Sin
embargo, estos términos alternativos son usados únicamente dentro del movimiento
del software libre, aunque están extendiéndose lentamente hacia el resto del mundo.
Otros defienden el uso del término open source software (software de código abierto,
también llamado de fuentes abiertas). La principal diferencia entre los términos "open
source" y "free software" es que éste último tiene en cuenta los aspectos éticos y
filosóficos de la libertad, mientras que el "open source" se basa únicamente en los
aspectos técnicos.

En un intento por unir los mencionados términos que se refieren a conceptos

semejantes, se está extendiendo el uso de la palabra "FLOSS" con el significado de
"Free - Libre - Open Source Software" e, indirectamente, también a la comunidad que
lo produce y apoya.
Tipos de Licencias

Una licencia es aquella autorización formal con carácter contractual que un autor de un
software da a un interesado para ejercer "actos de explotación legales". Pueden existir
tantas licencias como acuerdos concretos se den entre el autor y el licenciatario.

Software colaborativo o groupware

se refiere al conjunto de programas informáticos que integran el trabajo en un sólo

proyecto con muchos usuarios concurrentes que se encuentran en diversas estaciones
de trabajo, conectadas a través de una red (internet o intranet).

En su forma moderna, el concepto ha sido propuesto por el programa informático de

Lotus con la aplicación popular Lotus Notes relacionado con un servidor Lotus Domino
(Lotus Domino Server); algunas revisiones históricas argumentan que el concepto fue
anticipado antes por sistemas monolíticos como el NLS. El programa informático que
utiliza Wikipedia es un ejemplo de un programa informático colaborativo que además es
Software libre por lo que ha sido diseñado sin las limitaciones de los programas
informáticos propietarios en cuanto a tratos o sin las limitaciones de jerarquización
social.

Tipos de colaboración

El software colaborativo se puede dividir en tres categorías: herramientas de

colaboración-comunicación, herramientas de conferencia y herramientas de gestión
colaborativa o en grupo.

• Herramientas de comunicación electrónica que envían mensajes, archivos,

datos o documentos entre personas y facilitan la compartición de información
(colaboración asíncrona), como por ejemplo:
o Correo electrónico.
o Correo de voz.
o Publicación en web.
• Herramientas de conferencia que facilitan la compartición de información, de
forma interactiva (colaboración síncrona), como por ejemplo:
o Conferencia de datos - PC en red que comparten un espacio de
presentación compartido que cada usuario puede modificar.
o Conferencias de voz - teléfonos que permiten interactuar a los
participantes.
o Conferencias de video (o audio conferencia) - PC en red que comparten
señales de audio o video.
o Salas de chat o mensajería instantánea - una plataforma de discusión
que facilita el intercambio inmediato de mensajes.
o Sistemas para facilitar reuniones - un sistema de conferencias integrado
en una sala. Estas salas suelen disponer de un avanzado sistema de
sonido y presentación que permite una mejor interacción entre
participantes en una misma sala o entre salas separadas. Ejemplos de
ello son los Sistemas de soporte a decisiones.
• Herramientas de gestión colaborativa que facilitan las actividades del grupo,
como por ejemplo:
o Calendarios electrónicos - para acordar fechas de eventos y
automáticamente y enviar notificaciones y recordatorios a los
participantes.
o Sistemas de gestión de proyectos - para organizar y hacer seguimiento
de las acciones en un proyecto hasta que se finaliza.
o Sistemas de control de flujo de actividad - para gestionar tareas y
documentos en un proceso organizado de forma estructurada
(burocracia).
o Sistemas de gestión del conocimiento - para recoger, organizar,
gestionar y compartir varios tipos de información.
o Sistemas de soporte a redes sociales - para organizar las relaciones de
colectivos.
 LA HISTORIA DE LA COMPUTACIÓN
Primera Generación

(de 1951 a 1958) Las computadoras de la primera Generación emplearon bulbos

para procesar información. Los operadores ingresaban los datos y programas en
código especial por medio de tarjetas perforadas. El almacenamiento interno se
lograba con un tambor que giraba rápida mente, sobre el cual un dispositivo de
lectura/escritura colocaba marcas magnéticas. Esas computadoras de bulbos
eran mucho más grandes y generaban más calor que los modelos
contemporáneos. Eckert y Mauchly contribuyeron al desarrollo de
computadoras de la 1era Generación formando una Cia. privada y construyendo
UNIVAC I, que el Comité del censó utilizó para evaluar el de 1950. La IBM tenía
el monopolio de los equipos de procesamiento de datos a base de tarjetas
perforadas y estaba teniendo un gran auge en productos como rebanadores de
carne, básculas para comestibles, relojes y otros artículos; sin embargo no había
logrado el c ontrato para el Censo de 1950.

Comenzó entonces a construir computadoras electrónicas y su primera entrada

fue con la IBM 701 en 1953. Después de un lento pero exitante comienzo la IBM
701 se conviertió en un producto comercialmente viable. Sin embargo en 1954
fuen introducido e l modelo IBM 650, el cual es la razón por la que IBM disfruta
hoy de una gran parte del mercado de las computadoras. La administración de
la IBM asumió un gran riesgo y estimó una venta de 50 computadoras. Este
número era mayor que la cantidad de computadoras instaladas en esa época en
E.U. De hecho la IBM instaló 1000 computadoras. El resto es historia. Aunque
caras y de uso limitado las computadoras fueron aceptadas rápidamente por las
Compañías privadas y de Gobierno. A la mitad de los años 50 IBM y Remington
Rand se consolidaban como líderes en la fabricación de computadoras.

Segunda Generación

(1959-1964) Transistor Compatibilidad limitada El invento del transistor hizo

posible una nueva generación de computadoras, más rápidas, más pequeñas y
con menores necesidades de ventilación. Sin embargo el costo seguia siendo una
porción significativa del presupuesto de una Compañia. Las computadoras de la
segunda generación también utilizaban redes de nucleos magnéticos en lugar de
tambores giratorios para el almacenamiento primario. Estos núcleos contenían
pequeños anillos de material magnético, enlazados entre sí, en los cuales pod
podrian almacenarse datos e instrucciones.
Los programas de computadoras también mejoraron. El COBOL desarrollado
durante la 1era generación estaba ya disponible comercialmente. Los programas
escritos para una computadora podían transferirse a otra con un mínimo
esfuerzo. El escribir un programa ya no requería entender plenamente el
hardware de la computación. Las computadoras de la 2da Generación eran
substancialmente más pequeñas y rápidas que las de bulbos, y se usaban para
nuevas aplicaciones, como en los sistemas para reservación en líneas aéreas,
control de tráfico aéreo y simulaciones para uso general . Las empresas
comenzaron a aplicar las computadoras a tareas de almacenamiento de
registros, como manejo de inventarios, nómina y contabilidad. La marina de
E.U. utilizó las computadoras de la Segunda Generación para crear el primer
simulador de vuelo (Whirlwind I). HoneyWell se colocó como el primer
competidor durante la segunda generación de computadoras. Burroughs,
Univac, NCR, CDC, HoneyWell, los más grandes competidores de IBM durante
los 60s se conocieron como el grupo BUNCH (siglas).

Tercera Generación

(1964-1971) circuitos integrados Compatibilidad con equipo mayor

Multiprogramación Minicomputadora Las computadoras de la tercera
generación emergieron con el desarrollo de los circuitos integrados (pastillas de
silicio) en las cuales se colocan miles de componentes electrónicos, en una
integración en miniatura. Las computadoras nuevamente se hicieron más
pequeñas, más rápidas, desprendían menos calor y eran energéticamente más
eficientes.
Antes del advenimiento de los circuitos integrados, las computadoras estaban
diseñadas para aplicaciones matemáticas o de negocios, pero no para las dos
cosas. Los circuitos integrados permitieron a los fabricantes de computadoras
incrementar la flexib ilidad de los programas, y estandarizar sus modelos. La
IBM 360 una de las primeras computadoras comerciales que usó circuitos
integrados, podía realizar tanto análisis numéricos como administración ó
procesamiento de archivos. Los clientes podían escalar sus sistemas 360 a
modelos IBM de mayor tamaño y podían todavía correr sus programas actuales.
Las computadoras trabajaban a tal velocidad que proporcionaban la capacidad
de correr más de un programa de manera simultánea (multiprogramación). Por
ejemplo la computadora podía estar calculando la nomina y aceptando pedidos
al mismo tiempo. Minicomputadoras, Con la introducción del modelo 360 IBM
acaparó el 70% del mercado, para evitar competir directamente con IBM la
empresa Digital Equipment Corporation DEC redirigió sus esfuerzos hacia
computadoras pequeñas. Mucho menos costosas de compra r y de operar que
las computadoras grandes, las Minicomputadoras se desarrollaron durante la
segunda generación pero alcanzaron su mayor auge entre 1960 y 70.

Cuarta Generación

(1971 a la fecha)
• Microprocesador
• Chips de memoria.

Microminiaturización
Dos mejoras en la tecnología de las computadoras marcan el inicio de la cuarta
generación: el reemplazo de las memorias con núcleos magnéticos, por las de
Chips de silicio y la colocación de muchos más componentes en un Chic:
producto de la microminiaturi zación de los circuitos electrónicos. El tamaño
reducido del microprocesador de Chips hizo posible la creación de las
computadoras personales. (PC) Hoy en día las tecnologías LSI (Integración a
gran escala) y VLSI (integración a muy gran escala) permiten que cientos de
miles de componentes electrónicos se almacén en un clip. Usando VLSI, un
fabricante puede hacer que una computadora pequeña rivalice con una
computadora de la primera generación que ocupara un cuarto completo.
Clasificación de las computadoras:
• Supercomputadoras
• Macrocomputadoras
• Minicomputadoras
• Microcomputadoras o PC´s

Supercomputadoras :

Una supercomputadora es el tipo de computadora más potente y más rápido

que existe en un momento dado. Estas máquinas están diseñadas para procesar
enormes cantidades de información en poco tiempo y son dedicadas a una tarea
específica. Así mismo son las más caras, sus precios alcanzan los 30 MILLONES
de dólares y más; y cuentan con un control de temperatura especial, ésto para
disipar el calor que algunos componentes alcanzan a tener. Unos ejemplos de
tareas a las que son expuestas las supercomputadoras son los siguientes:
1. Búsqueda y estudio de la energía y armas nucleares.
2. Búsqueda de yacimientos petrolíferos con grandes bases de datos sísmicos.
3. El estudio y predicción de tornados.
4. El estudio y predicción del clima de cualquier parte del mundo.
5. La elaboración de maquetas y proyectos de la creación de aviones,
simuladores de vuelo. Etc.

Debido a su precio, son muy pocas las supercomputadoras que se construyen en

un año. Macrocomputadoras o Mainframes.

Macrocomputadoras :
Las macrocomputadoras son también conocidas como Mainframes. Los
mainframes son grandes, rápidos y caros sistemas que son capaces de controlar
cientos de usuarios simultáneamente, así como cientos de dispositivos de
entrada y salida. Los mainframes tienen un costo que va desde 350,000 dólares
hasta varios millones de dólares. De alguna forma los mainframes son más
poderosos que las supercomputadoras porque soportan más programas
simultáneamente. PERO las sup ercomputadoras pueden ejecutar un sólo
programa más rápido que un mainframe. En el pasado, los Mainframes
ocupaban cuartos completos o hasta pisos enteros de algún edificio, hoy en día,
un Mainframe es parecido a una hilera de archiveros en algún cuarto con piso
falso, ésto para ocultar los cientos de cables d e los periféricos , y su temperatura
tiene que estar controlada.
Quinta Generación
En vista de la acelerada marcha de la microelectrónica, la sociedad industrial se ha
dado a la tarea de poner también a esa altura el desarrollo del software y los sistemas
con que se manejan las computadoras. Surge la competencia internacional por el
dominio del mercado de la computación, en la que se perfilan dos líderes que, sin
embargo, no han podido alcanzar el nivel que se desea: la capacidad de comunicarse
con la computadora en un lenguaje más cotidiano y no a través de códigos o lenguajes
de control especializados.
Japón lanzó en 1983 el llamado "programa de la quinta generación de computadoras",
con los objetivos explícitos de producir máquinas con innovaciones reales en los
criterios mencionados. Y en los Estados Unidos ya está en actividad un programa en
desarrollo que persigue objetivos semejantes, que pueden resumirse de la siguiente
manera:
• Procesamiento en paralelo mediante arquitecturas y diseños especiales y circuitos de
gran velocidad.
• Manejo de lenguaje natural y sistemas de inteligencia artificial.

El futuro previsible de la computación es muy interesante, y se puede esperar que esta

ciencia siga siendo objeto de atención prioritaria de gobiernos y de la sociedad en
conjunto.
MODELO DE VON NEUMANN
Las computadoras digitales actuales se ajustan al modelo propuesto por el matemático
John Von Neumann. De acuerdo con el, una característica importante de este modelo
es que tanto los datos como los programas, se almacenan en la memoria antes de ser
utilizados.

Minincomputadoras :
En 1960 surgió la minicomputadora, una versión más pequeña de la
Macrocomputadora. Al ser orientada a tareas específicas, no necesitaba de todos los
periféricos que necesita un Mainframe, y ésto ayudo a reducir el precio y costos de
mantenimiento . Las Minicomputadoras , en tamaño y poder de procesamiento, se
encuentran entre los mainframes y las estaciones de trabajo. En general, una
minicomputadora, es un sistema multiproceso (varios procesos en paralelo) capaz de
soportar de 10 hasta 200 usuarios simultáneamente. Actualmente se usan para
almacenar grandes bases de datos, automatización industrial y aplicacio nes
multiusuario. Microcomputadoras o PC´s

Microcomputadoras (PC´s):
Las microcomputadoras o Computadoras Personales (PC´s) tuvieron su origen con la
creación de los microprocesadores. Un microprocesador es "una computadora en un
chic", o sea un circuito integrado independiente. Las PC´s son computadoras para uso
personal y relativamente son baratas y actualmente se encuentran en las oficinas,
escuelas y hogares. El término PC se deriva de que para el año de 1981 , IBM®, sacó a
la venta su modelo "IBM PC", la cual se convirtió en un tipo de computadora ideal para
uso "personal", de ahí que el término "PC" se estandarizó y los clones que sacaron
posteriormente otras empresas fueron llamados "PC y compatibles", usando
procesadores del mismo tipo que las IBM , pero a un costo menor y pudiendo ejecutar
el mismo tipo de programas. Existen otros tipos de microcomputadoras , como la
Macintosh®, que no son compatibles con la IBM, pero que en muchos de los casos se
les llaman también "PC´s", por ser de uso personal.
En la actualidad existen variados tipos en el diseño de PC´s: Computadoras personales,
con el gabinete tipo minitorre, separado del monitor. Computadoras personales
portátiles "Laptop" o "Notebook". Computadoras personales más comunes, con el
gabinete horizontal, separado del monitor. Computadoras personales que están en una
sola unidad compacta el monitor y el CPU. Las computadoras "laptops" son aquellas
computadoras que están diseñadas para poder ser transportadas de un lugar a otro. Se
alimentan por medio de baterías recargables , pesan entre 2 y 5 kilos y la mayoría trae
integrado una pantalla de LCD (Liquid Crys tal Display). Estaciones de trabajo o
Workstations Las estaciones de trabajo se encuentran entre las Minicomputadoras y las
macrocomputadoras (por el procesamiento). Las estaciones de trabajo son un tipo de
computadoras que se utilizan para aplicaciones que requieran de poder de procesam
iento moderado y relativamente capacidades de gráficos de alta calidad. Son usadas
para: Aplicaciones de ingeniería CAD (Diseño asistido por computadora) CAM
(manufactura asistida por computadora) Publicidad Creación de Software en redes, la
palabra "workstation" o "estación de trabajo" se utiliza para referirse a cualquier
computadora que está conectada a una red de área local.
BIBLIOGRAFIA:

http://www.monografias.com/trabajos/histocomp/histocomp.shtml
BIBLIOGRAFIA:

http://es.wikipedia.org/wiki/Software_libre

http://es.wikipedia.org/wiki/Software_colaborativo

http://es.wikipedia.org/wiki/Computer_software