domingo, 3 de julio de 2011

Internet, redes y comunicación:

Internet: es un conjunto descentralizado de redes de comunicación interconectadas que utilizan la familia de protocolos TCP/IP, garantizando que las redes físicas heterogéneas que la componen funcionen como una red lógica única, de alcance mundial. Sus orígenes se remontan a 1969, cuando se estableció la primera conexión de computadoras, conocida como ARPANET, entre tres universidades en California y una en Utah, Estados Unidos.
Uno de los servicios que más éxito ha tenido en Internet ha sido la World Wide Web (WWW, o "la Web"), hasta tal punto que es habitual la confusión entre ambos términos. La WWW es un conjunto de protocolos que permite, de forma sencilla, la consulta remota de archivos de hipertexto. Ésta fue un desarrollo posterior (1990) y utiliza Internet como medio de transmisión.
Existen, por tanto, muchos otros servicios y protocolos en Internet, aparte de la Web: el envío de correo electrónico (SMTP), la transmisión de archivos (FTP y P2P), las conversaciones en línea (IRC), la mensajería instantánea y presencia, la transmisión de contenido y comunicación multimedia -telefonía (VoIP), televisión (IPTV)-, los boletines electrónicos (NNTP), el acceso remoto a otros dispositivos (SSH y Telnet) o los juegos en línea.


Redes: Una red de computadoras, también llamada red de ordenadores o red informática, es un conjunto de equipos informáticos conectados entre sí por medio de dispositivos físicos que envían y reciben impulsos eléctricos, ondas electromagnéticas o cualquier otro medio para el transporte de datos para compartir información y recursos. Este término también engloba aquellos medios técnicos que permiten compartir la información. [cita requerida]
La finalidad principal para la creación de una red de computadoras es compartir los recursos y la información en la distancia, asegurar la confiabilidad y la disponibilidad de la información, aumentar la velocidad de transmisión de los datos y reducir el coste general de estas acciones.
La estructura y el modo de funcionamiento de las redes informáticas actuales están definidos en varios estándares, siendo el más importante y extendido de todos ellos el modelo TCP/IP basado en el modelo de referencia OSI. Este último, estructura cada red en 7 capas con funciones concretas pero relacionadas entre sí; en TCP/IP se reducen a 4 capas. Existen multitud de protocolos repartidos por cada capa, los cuales también están regidos por sus respectivos estándares.




Comunicación: La comunicación es el proceso mediante el cual se puede transmitir información de una entidad a otra. Los procesos de comunicación son interacciones mediadas por signos entre al menos dos agentes que comparten un mismo repertorio de signos y tienen unas reglas semióticas comunes.
Tradicionalmente, la comunicación se ha definido como "el intercambio de sentimientos, opiniones, o cualquier otro tipo de información mediante habla, escritura u otro tipo de señales". Todas las formas de comunicación requieren un emisor, un mensaje y un receptor destinado, pero el receptor no necesita estar presente ni consciente del intento comunicativo por parte del emisor para que el acto de comunicación se realice. En el proceso comunicativo, la información es incluida por el emisor en un paquete y canalizada hacia el receptor a través del medio. Una vez recibido, el receptor decodifica el mensaje y proporciona una respuesta.
El funcionamiento de las sociedades humanas es posible gracias a la comunicación. Esta consiste en el intercambio de mensajes entre los individuos.
Desde un punto de vista técnico se entiende por comunicación el hecho que un determinado mensaje originado en el punto A llegue a otro punto determinado B, distante del anterior en el espacio o en el tiempo. La comunicación implica la transmisión de una determinada información. La información como la comunicación supone un proceso; los elementos que aparecen en el mismo son:
  • Código. El código es un sistema de signos y reglas para combinarlos, que por un lado es arbitrario y por otra parte debe de estar organizado de antemano.
  • Canal. El proceso de comunicación que emplea ese código precisa de un canal para la transmisión de las señales. El Canal sería el medio físico a través del cual se transmite la comunicación.
Ej: El aire en el caso de la voz y las ondas
Hertzianas* en el caso de la televisión.
  • La radiocomunicación es un sistema de telecomunicación que se realiza a través de ondas de radio u ondas hertzianas*,
  • En tercer lugar debemos considerar el Emisor. Es la persona que se encarga de transmitir el mensaje. Esta persona elige y selecciona los signos que le convienen, es decir, realiza un proceso de codificación; codifica el mensaje.
  • El Receptor será aquella persona a quien va dirigida la comunicación; realiza un proceso inverso al del emisor, ya que descifra e interpreta los signos elegidos por el emisor; es decir, descodifica el mensaje.
  • Naturalmente tiene que haber algo que comunicar, un contenido y un proceso que con sus aspectos previos y sus consecuencias motive el Mensaje.
  • Las circunstancias que rodean un hecho de comunicación se denominan Contexto situacional (situación), es el contexto en que se transmite el mensaje y que contribuye a su significado.

Administración de Base de Datos:

El administrador de base de datos (DBA) es la persona responsable de los aspectos ambientales de una base de datos. En general esto incluye lo siguiente:
  • Recuperabilidad - Crear y probar Respaldos
  • Integridad - Verificar o ayudar a la verificación en la integridad de datos
  • Seguridad - Definir o implementar controles de acceso a los datos
  • Disponibilidad - Asegurarse del mayor tiempo de encendido
  • Desempeño - Asegurarse del máximo desempeño incluso con las limitaciones
  • Desarrollo y soporte a pruebas - Ayudar a los programadores e ingenieros a utilizar eficientemente la base de datos.
El diseño lógico y físico de las bases de datos a pesar de no ser obligaciones de un administrador de bases de datos, es a veces parte del trabajo. Esas funciones por lo general están asignadas a los analistas de bases de datos o a los diseñadores de bases de datos.

Deberes

Los deberes de un administrador de bases de datos dependen de la descripción del puesto, corporación y políticas de Tecnologías de Información (TI). Por lo general se incluye recuperación de desastres (respaldos y pruebas de respaldos), análisis de rendimiento y optimización, y cierta asistencia en el diseño de la base de datos.

Debe incorporarse una metodología basada en calidad y administración de riesgos al proceso de la administración de bases de datos.
Definición de base de datos.

Disponibilidad

La disponibilidad significa que los usuarios autorizados tengan acceso a los datos cuando lo necesiten para atender a las necesidades del negocio. De manera incremental los negocios han ido requiriendo que su información esté disponible todo el tiempo (7x24", o siete días a la semana, 24 horas del día). La industria de TI ha respondido a estas necesidades con redundancia de red y hardware para incrementar las capacidades administrativas en línea. siempre y cuando estes en la administracion de la TI.

Recuperabilidad

La recuperabilidad significa que, si se da algún error en los datos, hay un bug de programa ó de hardware, el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el daño se causara. Las actividades de recuperación incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de daño o pérdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del área en antelación a un desastre anticipado. La recuperación es una de las tareas más importantes de los DBA's.
La recuperabilidad, frecuentemente denominada "recuperación de desastres", tiene dos formas primarias. La primera son los respaldos y después las pruebas de recuperación.
La recuperación de las bases de datos consisten en información y estampas de tiempo junto con bitácoras los cuales se cambian de manera tal que sean consistentes en un momento y fecha en particular. Es posible hacer respaldos de la base de datos que no incluyan las estampas de tiempo y las bitácoras, la diferencia reside en que el DBA debe sacar de línea la base de datos en caso de llevar a cabo una recuperación.
Las pruebas de recuperación consisten en la restauración de los datos, después se aplican las bitácoras a esos datos para restaurar la base de datos y llevarla a un estado consistente en un tiempo y momento determinados. Alternativamente se puede restaurar una base de datos que se encuentra fuera de línea sustituyendo con una copia de la base de datos.
Si el DBA (o el administrador) intentan implementar un plan de recuperación de bases de datos sin pruebas de recuperación, no existe la certeza de que los respaldos sean del todo válidos. En la práctica, los respaldos de la mayoría de los RDBMSs son raramente válidos si no se hacen pruebas exhaustivas que aseguren que no ha habido errores humanos o bugs que pudieran haber corrompido los respaldos.

Integridad

La integridad de una base de datos significa que, la base de datos o los programas que generaron su contenido, incorporen métodos que aseguren que el contenido de los datos del sistema no se rompan así como las reglas del negocio. Por ejemplo, un distribuidor puede tener una regla la cual permita que sólo los clientes individuales puedan solicitar órdenes; a su vez cada orden identifique a uno y sólo un proveedor. El servidor Oracle y otros DBMSs relacionales hacen cumplir este tipo de reglas del negocio con limitantes, las cuales pueden ser configuradas implícitamente a través de consultas. Para continuar con este ejemplo, en el proceso de inserción de una nueva orden a la base de datos, esta a su vez tendría que cerciorarse de que el cliente identificado existen en su tabla para que la orden pueda darse.

Seguridad

Seguridad significa la capacidad de los usuarios para acceder y cambiar los datos de acuerdo a las políticas del negocio, así como, las decisiones de los encargados. Al igual que otros metadatos, una DBMS relacional maneja la seguridad en forma de tablas. Estas tablas son las "llaves del reino" por lo cual se deben proteger de posibles intrusos.

Rendimiento

El rendimiento significa que la base de datos no cause tiempos de respuesta poco razonables. En sistemas muy complejos cliente/servidor y de tres capas, la base de datos es sólo uno de los elementos que determinan la experiencia de los usuarios en línea y los programas desatendidos. El rendimiento es una de las mayores motivaciones de los DBA para coordinarse con los especialistas de otras áreas del sistema fuera de las líneas burocráticas tradicionales.

Desarrollo/Soporte a pruebas

Uno de los deberes menos respetados por el administrador de base de datos es el desarrollo y soporte a pruebas, mientras que algunos otros encargados lo consideran como la responsabilidad más importante de un DBA. Las actividades de soporte incluyen la colecta de datos de producción para llevar a cabo pruebas con ellos; consultar a los programadores respecto al desempeño; y hacer cambios a los diseños de tablas de manera que se puedan proporcionar nuevos tipos de almacenamientos para las funciones de los programas.
Algunos roles del personal de TI relacionados con la administración de base de datos:



Programación y desarrollo del Software:

La programación es el proceso de diseñar, escribir, probar, depurar y mantener el código fuente de programas computacionales. El código fuente es escrito en un lenguaje de programación. El propósito de la programación es crear programas que exhiban un comportamiento deseado. El proceso de escribir código requiere frecuentemente conocimientos en varias áreas distintas, además del dominio del lenguaje a utilizar, algoritmos especializados y lógica formal. Programar no involucra necesariamente otras tareas tales como el análisis y diseño de la aplicación (pero sí el diseño del código), aunque sí suelen estar fusionadas en el desarrollo de pequeñas aplicaciones.

Historia

Para crear un programa, y que la computadora interprete y ejecute las instrucciones escritas en él, debe usarse un Lenguaje de programación.
En sus inicios las computadoras interpretaban sólo instrucciones en un lenguaje específico, del más bajo nivel, conocido como código máquina, siendo éste excesivamente complicado para programar. De hecho sólo consiste en cadenas de números 1 y 0 (Sistema binario).
Para facilitar el trabajo de programación, los primeros científicos que trabajaban en el área decidieron reemplazar las instrucciones, secuencias de unos y ceros, por palabras o letras provenientes del inglés; codificándolas así y creando un lenguaje de mayor nivel, que se conoce como Assembly o lenguaje ensamblador. Por ejemplo, para sumar se usa la letra A de la palabra inglesa add (sumar). En realidad escribir en lenguaje ensamblador es básicamente lo mismo que hacerlo en lenguaje máquina, pero las letras y palabras son bastante más fáciles de recordar y entender que secuencias de números binarios.
A medida que la complejidad de las tareas que realizaban las computadoras aumentaba, se hizo necesario disponer de un método sencillo para programar. Entonces, se crearon los lenguajes de alto nivel. Mientras que una tarea tan trivial como multiplicar dos números puede necesitar un conjunto de instrucciones en lenguaje ensamblador, en un lenguaje de alto nivel bastará con solo una.
Una vez que se termina de escribir un programa, sea en ensamblador o en un lenguaje de alto nivel, es necesario compilarlo, es decir, traducirlo a lenguaje máquina.

Léxico y programación

La programación se rige por reglas y un conjunto más o menos reducido de órdenes, expresiones, instrucciones y comandos que tienden a asemejarse a una lengua natural acotada (en inglés); y que además tienen la particularidad de una reducida ambigüedad. Cuanto menos ambiguo es un lenguaje de programación, se dice, es más potente. Bajo esta premisa, y en el extremo, el lenguaje más potente existente es el binario, con ambigüedad nula (lo cual lleva a pensar así del lenguaje ensamblador).
En los lenguajes de programación de alto nivel se distinguen diversos elementos entre los que se incluyen el léxico propio del lenguaje y las reglas semánticas y sintácticas.

[editar] Programas y algoritmos

Un algoritmo es una secuencia no ambigua, finita y ordenada de instrucciones que han de seguirse para resolver un problema. Un programa normalmente implementa (traduce a un lenguaje de programación concreto) uno o más algoritmos. Un algoritmo puede expresarse de distintas maneras: en forma gráfica, como un diagrama de flujo, en forma de código como en pseudocódigo o un lenguaje de programación, en forma explicativa, etc.
Los programas suelen subdividirse en partes menores, llamadas módulos, de modo que la complejidad algorítmica de cada una de las partes sea menor que la del programa completo, lo cual ayuda al desarrollo del programa. Esta es una práctica muy utilizada y se conoce como "refino progresivo".
Según Niklaus Wirth, un programa está formado por los algoritmos y la estructura de datos.
Se han propuesto diversas técnicas de programación cuyo objetivo es mejorar tanto el proceso de creación de software como su mantenimiento. Entre ellas, se pueden mencionar las siguientes:

Compilación

El programa escrito en un lenguaje de programación (fácilmente comprensible por el programador) es llamado programa fuente y no se puede ejecutar directamente en una computadora. La opción más común es compilar el programa obteniendo un módulo objeto, aunque también puede ejecutarse en forma más directa a través de un intérprete informático.
El código fuente del programa se debe someter a un proceso de traducción para convertirlo en lenguaje máquina, código éste directamente ejecutable por el procesador. A este proceso se le llama compilación.
Normalmente la creación de un programa ejecutable (un típico.exe para Microsoft Windows o DOS) conlleva dos pasos. El primer paso se llama compilación (propiamente dicho) y traduce el código fuente escrito en un lenguaje de programación almacenado en un archivo a código en bajo nivel (normalmente en código objeto, no directamente a lenguaje máquina). El segundo paso se llama enlazado en el cual se enlaza el código de bajo nivel generado de todos los ficheros y subprogramas que se han mandado compilar y se añade el código de las funciones que hay en las bibliotecas del compilador para que el ejecutable pueda comunicarse directamente con el sistema operativo, traduciendo así finalmente el código objeto a código máquina, y generando un módulo ejecutable.
Estos dos pasos se pueden hacer por separado, almacenando el resultado de la fase de compilación en archivos objetos (un típico.obj para Microsoft Windows, DOS o para Unix); para enlazarlos en fases posteriores, o crear directamente el ejecutable; con lo que la fase de compilación se almacena sólo temporalmente. Un programa podría tener partes escritas en varios lenguajes (por ejemplo C, C++ y ensamblador), que se podrían compilar de forma independiente y luego enlazar juntas para formar un único módulo ejecutable.

Programación e ingeniería del software

Existe una tendencia a identificar el proceso de creación de un programa informático con la programación, que es cierta cuando se trata de programas pequeños para uso personal, y que dista de la realidad cuando se trata de grandes proyectos.
El proceso de creación de software, desde el punto de vista de la ingeniería, incluye los siguientes pasos:
  1. Reconocer la necesidad de un programa para solucionar un problema o identificar la posibilidad de automatización de una tarea.
  2. Recoger los requisitos del programa. Debe quedar claro qué es lo que debe hacer el programa y para qué se necesita.
  3. Realizar el análisis de los requisitos del programa. Debe quedar claro cómo debe realizar el programa las cosas que debe hacer. Las pruebas que comprueben la validez del programa se pueden especificar en esta fase.
  4. Diseñar la arquitectura del programa. Se debe descomponer el programa en partes de complejidad abordable.
  5. Implementar el programa. Consiste en realizar un diseño detallado, especificando completamente todo el funcionamiento del programa, tras lo cual la codificación debería resultar inmediata.
  6. Implantar (instalar) el programa. Consiste en poner el programa en funcionamiento junto con los componentes que pueda necesitar (bases de datos, redes de comunicaciones, etc.).
La ingeniería del software se centra en los pasos de planificación y diseño del programa, mientras que antiguamente (programación artesanal) la realización de un programa consistía únicamente en escribir el código.

Referencias históricas

La primera programadora de computadora conocida fue Ada Lovelace, hija de Anabella Milbanke Byron y Lord Byron. Anabella introdujo en las matemáticas a Ada quien, después de conocer a Charles Babbage, tradujo y amplió una descripción de su máquina analítica. Incluso aunque Babbage nunca completó la construcción de cualquiera de sus máquinas, el trabajo que Ada realizó con éstas le hizo ganarse el título de primera programadora de computadoras del mundo. El nombre del lenguaje de programación Ada fue escogido como homenaje a esta programadora.
No olvidemos que este proceso está aplicado a todos los métodos científicos que actualmente se practican.

Objetivos de la programación

La programación debe perseguir la obtención de programas de calidad. Para ello se establece una serie de factores que determinan la calidad de un programa. Algunos de los factores de calidad más importantes son los siguientes:
  • Corrección. Un programa es correcto si hace lo que debe hacer tal y como se estableció en las fases previas a su desarrollo. Para determinar si un programa hace lo que debe, es muy importante especificar claramente qué debe hacer el programa antes de desarrollarlo y, una vez acabado, compararlo con lo que realmente hace.
  • Claridad. Es muy importante que el programa sea lo más claro y legible posible, para facilitar así su desarrollo y posterior mantenimiento. Al elaborar un programa se debe intentar que su estructura sea sencilla y coherente, así como cuidar el estilo en la edición; de esta forma se ve facilitado el trabajo del programador, tanto en la fase de creación como en las fases posteriores de corrección de errores, ampliaciones, modificaciones, etc. Fases que pueden ser realizadas incluso por otro programador, con lo cual la claridad es aún más necesaria para que otros programadores puedan continuar el trabajo fácilmente. Algunos programadores llegan incluso a utilizar Arte ASCII para delimitar secciones de código. Otros, por diversión o para impedir un análisis cómodo a otros programadores, recurren al uso de código ofuscado.
  • Eficiencia. Se trata de que el programa, además de realizar aquello para lo que fue creado (es decir, que sea correcto), lo haga gestionando de la mejor forma posible los recursos que utiliza. Normalmente, al hablar de eficiencia de un programa, se suele hacer referencia al tiempo que tarda en realizar la tarea para la que ha sido creado y a la cantidad de memoria que necesita, pero hay otros recursos que también pueden ser de consideración al obtener la eficiencia de un programa, dependiendo de su naturaleza (espacio en disco que utiliza, tráfico de red que genera, etc.).
  • Portabilidad. Un programa es portable cuando tiene la capacidad de poder ejecutarse en una plataforma, ya sea hardware o software, diferente a aquélla en la que se elaboró. La portabilidad es una característica muy deseable para un programa, ya que permite, por ejemplo, a un programa que se ha desarrollado para sistemas GNU/Linux ejecutarse también en la familia de sistemas operativos Windows. Esto permite que el programa pueda llegar a más usuarios más fácilmente.

Procesamiento de Datos:

Hasta el momento hemos supuesto que los datos que maneja una aplicación no son tan voluminosos y por lo tanto caben en memoria. Cuando recurrimos a archivos se debe a la necesidad de conservar datos después de que termina un programa, por ejemplo para apagar el computador.
Sin embargo, existen problemas en donde el volumen de datos es tan grande que es imposible mantenerlos en memoria. Entonces, los datos se almacenan en un conjunto de archivos, los que forman una base de datos. Una base de datos es por lo tanto un conjunto de archivos que almacenan, por ejemplo, datos con respecto al negocio de una empresa.
Cada archivo se forma en base a un conjunto de líneas y cada línea esta formada por campos de información. Todas las líneas de un mismo archivo tienen la misma estructura, es decir los mismos campos de información. Diferentes archivos poseen estructuras distintas, i.e. campos de información.
Por ejemplo, el archivo de postulantes post.dat, visto en capítulos anteriores, tiene la siguiente información:
  • ci: carnet de identidad de la persona.
  • nombre.
En lo que sigue supondremos que ambos archivos son lo suficientemente grandes como para que no quepan en la memoria del computador. A continuación resolveremos eficientemente el problema de generar un archivo con los tres campos de información, sin colocar previamente el contenido de un archivo en un arreglo.
Algunas definiciones
Recolección de datos:
Provee un vínculo para obtener la información interoperacionables racional y las parametrizaciones.
Almacenamiento de datos:

Las unidades de disco de la computadora y otros medios de almacenamiento externo permiten almacenar los datos a más largo plazo, manteniéndolos disponibles pero separados del circuito principal hasta que el microprocesador los necesita. Una computadora dispone también de otros tipos de almacenamiento.
La memoria de sólo lectura (ROM) es un medio permanente de almacenamiento de información básica, como las instrucciones de inicio y los procedimientos de entrada/salida. Asimismo, una computadora utiliza varios buffers (áreas reservadas de la memoria) como zonas de almacenamiento temporal de información específica, como por ejemplo los caracteres a enviar a la impresora o los caracteres leídos desde el teclado.
Procesamiento de datos:
  1. El objetivo es graficar el Procesamiento de Datos, elaborando un Diagrama que permita identificar las Entradas, Archivos, Programas y Salidas de cada uno de los Procesos.

  2. Su antecedente es el Diagrama de Flujo.
  3. Los elementos claves son los Programas.
  4. Se confecciona el Diagrama de Procesamiento de Datos
  5. Este Diagrama no se podrá elaborar por completo desde un primer momento ya que depende del Flujo de Información.
  6. En este primer paso sólo se identifican las Salidas y Programas. Los elementos restantes se identifican en forma genérica.
Validación de datos:
Consiste en asegurar la veracidad e integridad de los datos que ingresan a un archivo. Existen numerosas técnicas de validación tales como: Digito verificador, chequeo de tipo, chequeo de rango.
5. Concepto de Procesamiento Distribuido y Centralizado
Procesamiento Centralizado:
En la década de los años 50’s las computadoras eran máquinas del tamaño de todo un cuarto con las siguientes características:
• Un CPU
• Pequeña cantidad de RAM
• Dispositivos DC almacenamiento secundario (cintas)
• Dispositivos d salida (perforadoras de tarjetas)
• Dispositivos de entrada (lectores de tarjeta perforada)
Con el paso del tiempo, las computadoras fueron reduciendo su tamaño y creciendo en sofisticación,
• Aunque la industria continuaba siendo dominada por las computadoras grandes "mainframes". A medida que la computación evolucionaba, las computadoras, fueron capaces de manejar aplicaciones múltiples simultáneamente, convirtiéndose en procesadores centrales "hosts" a los que se les
Conectaban muchos periféricos y terminales tontas que consistían solamente de dispositivos de entrada/salida (monitor y teclado) y quizá poco espacio de almacenamiento, pero que no podían procesar por sí mismas. Las terminales locales se conectaban con el procesador central a través de interfaces seriales ordinarias de baja velocidad, mientras que las terminales remotas se enlazaban con
• El "host" usando módems y líneas telefónicas conmutadas. En este ambiente, se ofrecían velocidades de transmisión de 1200, 2400, o 9600 bps. Un ambiente como el descrito es lo que se conoce como procesamiento centralizado en su forma más pura "host/terminal". Aplicaciones características de este tipo de ambiente son:
Administración de grandes tuses de datos integradas
Algoritmos científicos de alta velocidad
Control de inventarios centralizado
Al continuar la evolución de los "mainframes", estos se comenzaron a conectar a enlaces de alta velocidad donde algunas tareas relacionadas con las comunicaciones se delegaban a otros dispositivos llamados procesadores comunicaciones "Front End Procesos" (I7EP’s) y controladores de grupo "Cluster Controllers" (CC’s).
Procesamiento Distribuido:
El procesamiento centralizado tenía varios inconvenientes, entre los que podemos mencionar que un número limitado de personas controlaba el acceso a la información y a los reportes, se requería un grupo muy caro de desarrolladores de sistemas para crear las aplicaciones, y los costos de mantenimiento y soporte eran extremadamente altos. La evolución natural de la computación fue en el sentido del procesamiento distribuido, así las minicomputadoras (a pesar de su nombre siguen siendo máquinas potentes) empezaron a tomar parte del procesamiento que tenían los "mainframes".
Ventajas
Existen cuatro ventajas del procesamiento de bases de datos distribuidas. La primera, puede dar como resultado un mejor rendimiento que el que se obtiene por un procesamiento centralizado. Los datos pueden colocarse cerca del punto de su utilización, de forma que el tiempo de comunicación sea mas corto. Varias computadoras operando en forma simultánea pueden entregar más volumen de procesamiento que una sola computadora.
Segundo, los datos duplicados aumentan su confiabilidad. Cuando falla una computadora, se pueden obtener los datos extraídos de otras computadoras. Los usuarios no dependen de la disponibilidad de una sola fuente para sus datos .Una tercera ventaja, es que los sistemas distribuidos pueden variar su tamaño de un modo más sencillo. Se pueden agregar computadoras adicionales a la red conforme aumentan el número de usuarios y su carga de procesamiento. A menudo es más fácil y más barato agregar una nueva computadora más pequeña que actualizar una computadora única y centralizada. Después, si la carga de trabajo se reduce, el tamaño de la red también puede reducirse.
Por último, los sistemas distribuidos se pueden adecuar de una manera más sencilla a las estructuras de la organización de los usuarios.

6. Estructura de Datos utilizados en el proceso electrónico de datos
Arreglos
Son una agrupación de datos homogéneos, es decir, con un mismo tipo de dato básico asociado. Se almacenan en forma contigua en la memoria y son referenciados con un nombre común y una posición relativa.
Ejemplos:
Arreglo Lineal (1 dimensión ó vector)
Vista gráfica
[1]
[2]
[3]
[4]
[5]
Definición de tipo

Type
Linea: Array [1..5] of TipoBasico;
Var
MiArreglo:Linea;
Arreglo Bidimensional (matriz)
Vista gráfica
[1,1]
[1,2]
[1,3]
[1,4]
[2,1]
[2,2]
[2,3]
[2,4]
[3,1]
[3,2]
[3,3]
[3,4]

Definición de tipo
Type
TipoTabla:Array[1..3,1..4] of TipoBasico;
Var
MiTabla: TipoTabla;
Pilas o colas Lifo:
Imagina un montón de platos "apilados" o bien fichas de dominó formando una torre e intenta eliminar una desde el centro, ¿qué ocurre?, naturalmente esta operación no está permitida si queremos mantener intactos a los platos o a la torre construida. Por esta razón, una pila se asocia a una estructura de datos LIFO (LAST IN FIRST OUT). En base a lo anterior, construye la definición de una PILA y discútela con el profesor.
En general, podemos definir para cada una de las estructuras de datos una representación estática y otra dinámica según el método de asignación de memoria utilizado.
Clasificación
a.)Pila estática:
Sin duda tendremos que utilizar arreglos o registros que como ya sabemos son la base para estructuras de datos más complejas. Considerando la siguiente figura:
Vista gráfica

Suponiendo que Dato pertenece a un mismo tipo de datos y Cuenta Dato corresponde a un entero que se incrementa a medida que un nuevo elemento se incorpora a la pila. Intenta construir la definición de tipo para la estructura Pila.
TYPE
______________________________
______________________________
______________________________
END;
b.)Pila
Dinámica:
Sin duda tendremos que utilizar nodos con punteros. Considera la siguiente figura:

Suponiendo que los punteros que aparecen en la figura son capaces de apuntar a un nodo y que Dato pertenece a cualquiera de los tipos básicos o estructurados, la definición de tipo sería:
TYPE
Puntero=^NodoPila;
NodoPila=Record
Info:AlgunTipo;
sgte:Puntero;
End;
Var tope:Puntero;
Un concepto por introducir es el de encapsulamiento, que significa que una vez definida la estructura e implementadas las operaciones básicas, uno se remite a utilizarlas sin importar su codificación interna, es decir, las llamadas a PUSH(pila, x) o POP(pila, y) empilarán a x o desempilarán en y sin importar cómo lo hagan.
c.)Listas Enlazadas:
Corresponde a una estructura lineal compuesta por una colección de datos homogéneos con alguna relación entre ellos. Dicha estructura se crea a través del método dinámico de memoria.
En una lista enlazada el orden de los elementos está determinado por un campo enlace (puntero) explícito en cada elemento, por ejemplo: pilas y filas dinámicas.
La representación de lista enlazada es la más óptima debido a que cualquier proceso de actualización (modificación inserción o eliminación) se realiza en base a reasignación de punteros. En este capítulo trataremos sólo con las listas enlazadas ya que las listas secuénciales ya son bien conocidas por ustedes.
Tipos de Listas Enlazadas
  • Listas lineales simplemente enlazadas
  • Listas Circulares
  • Listas doblemente enlazadas
  • Listas múltiplemente enlazadas
Árboles
Es una estructura de datos no lineal que posee raíz, ramas y hojas, técnicamente constituye un grafo finito y sin ciclos. Un árbol define ciertos niveles jerárquicos precedidos por la raíz (1er. nivel), en donde las hojas constituyen el nivel más bajo.
Componentes
Raíz: Nodo que constituye la única entrada a la estructura (por ello es necesario tener un puntero sobre él).
Ramas o Arcos: Conexión entre dos nodos del árbol que representa una relación de jerarquía.
Hojas: Nodo sin hijos.
Características
Nivel o profundidad de un nodo: Longitud del camino para ir desde la raíz al nodo. Por definición la raíz está en el nivel 0. Por ejemplo: profundidad(Y)=2, profundidad(raíz)=0, profundidad(árbol)= profundidad(hoja más profunda).
Altura de un nodo: Longitud del camino más largo desde el nodo a una hoja. Por ejemplo:
Altura(X)=1, Altura(Y)=0, Altura(arbol)=Altura(raíz)=profundidad(árbol)
Grado de nodo: Cantidad de hijos de un nodo cualquiera.
Grado de árbol: Cantidad máxima de hijos posibles de asociar a un nodo del árbol
Clasificación
a.)Según Número de Hijos:
b.)Según Estructura de Niveles:
Arbol completo: Es un árbol binario en el cual cada nodo es una hoja o posee exactamente 2 hijos.
Arbol lleno: Es un árbol binario con hojas en a lo más dos niveles adyacentes l-1 y l, en las cuales los nodos terminales se encuentran ubicados en las posiciones de más a la izquierda del árbol.
Si un árbol binario es completo, necesariamente es lleno
c.)Según Funcionalidad:
Árbol binario de búsqueda (ABB)
Árbol binario de expresión
Archivos:

Es una es estructura de datos que reside en memoria secundaria o almacenamiento permanente (cinta magnética, disco
magnético, disco óptico, disco láser, etc.). La forma de clasificación más básica se realiza de acuerdo al formato en que residen estos archivos, de esta forma hablamos de archivos ASCII (de texto) y archivos binarios. En este capítulo nos centraremos en estos últimos.
Definición archivo binario:
Estructura de datos permanente compuesto por registros (filas) y éstos a su vez por campos (columnas). Se caracteriza por tener un tipo de dato asociado, el cual define su estructura interna.
Definición archivo texto:
Estructura de datos permanente no estructurado formado por una secuencia de caracteres ASCII.
Tipos de Acceso a los Archivos
a.)Secuencial:
Se accesan uno a uno los registros desde el primero hasta el último o hasta aquel que cumpla con cierta condición de búsqueda. Se permite sobre archivos de Organización secuencial y Secuencial Indexada.
b.)Random:
Se accesan en primera instancia la tabla de índices de manera de recuperar la dirección de inicio de bloque en donde se encuentra el registro buscado. (dentro del  rea primaria o de overflow). Se permite para archivos con Organización Sec.Indexada.
c.)Dinámico:
Se accesan en primera instancia la tabla de índices de manera de recuperar la dirección de inicio de bloque en donde se
encuentra el registro buscado. (dentro del  rea primaria o de overflow). Se permite para archivos con Organización Sec.Indexada.
d.)Directo:
Es aquel que utiliza la función de Hashing para recuperar los registros. Sólo se permite para archivos con Organización Relativa.
Constantes
Las constantes son similares a una variable pero tienen un valor determinado que se mantiene igual en toda la ejecución del programa. El contenido de una variable puede cambiar tantas veces sea necesario. ¿Porque usar una constante si no puede cambiar de valor?. Hacemos esto cuando deseamos usar un mismo número o una palabra (string) varias veces.
Variables
Magnitud que puede tomar diferentes valores y se representa con una letra o letras. La variable real es el conjunto de los números reales, y se puede representar por cualquier letra o conjunto de letras y nos sirve para poder utilizar dicha letra para calculos o para obtener resultados.
7. Conclusión
La tecnología de información está transformando las actividades económicas y cotidianas como uno de los fenómenos sociológicos más importantes del siglo. Por esta razón, los niveles de oportunidades de trabajo se incrementan de una manera acelerada en diferentes áreas del conocimiento.
Indiscutiblemente, las computadoras han invadido ya todos y cada uno de los campos de la actividad humana: ciencia, tecnología, arte, educación, recreación, administración, economía y de acuerdo a la tendencia actual, nuestra civilización y las venideras dependerán cada vez más de estos "cerebros" electrónicos.
Se ha venido acelerando la velocidad de cambio del medio de casi todas las organizaciones, de allí que éstas necesiten ahora más información como soporte a la toma de decisiones.
Aunque las entidades de tipo educativo se han descuidado en este aspecto, en estos momentos se percibe un cierto interés en la implantación de estrategias que logren interesar a estudiantes y profesores en el aprendizaje de técnicas que pretende a corto plazo masificar e implementar el uso de bases de datos, redes de datos e información y tecnología informática de punta como herramientas básicas de los actuales y nuevos profesionales del país.
Para responder a los retos planteados por la nueva situación económica y tecnológica mundial, se impulsa una dinámica tendiente a dar a conocer los elementos necesarios para estar a la vanguardia en este campo.

Software

Se conoce como software al equipamiento lógico o soporte lógico de una computadora digital; comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas, en contraposición a los componentes físicos, que son llamados hardware.

Los componentes lógicos incluyen, entre muchos otros, las aplicaciones informáticas; tales como el procesador de texto, que permite al usuario realizar todas las tareas concernientes a la edición de textos; el software de sistema, tal como el sistema operativo, que, básicamente, permite al resto de los programas funcionar adecuadamente, facilitando también la interacción entre los componentes físicos y el resto de las aplicaciones, y proporcionando una interfaz para el usuario.

Existen varias definiciones similares aceptadas para software, pero probablemente la más formal sea la siguiente:
Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados que forman parte de las operaciones de un sistema de computación.

Considerando esta definición, el concepto de software va más allá de los programas de computación en sus distintos estados: código fuente, binario o ejecutable; también su documentación, los datos a procesar e incluso la información de usuario forman 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 la ingeniería de software y las ciencias de la computación, el software es toda la información procesada por los sistemas informáticos: programas y datos.
El concepto de leer diferentes secuencias de instrucciones (programa) 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 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, a los fines prácticos se puede clasificar al software en tres grandes tipos:
  • Software de sistema: Su objetivo es desvincular adecuadamente al usuario y al programador de los detalles de la computadora 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, herramientas y utilidades de apoyo que permiten su mantenimiento. Incluye entre otros:
    • Sistemas operativos
    • Controladores de dispositivos
    • Herramientas de diagnóstico
    • Herramientas de Corrección y Optimización
    • Servidores
    • 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:
    • Editores de texto
    • Compiladores
    • Intérpretes
    • Enlazadores
    • Depuradores
    • Entornos de Desarrollo Integrados (IDE): Agrupan las anteriores herramientas, usualmente en un entorno visual, de forma tal 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: Es 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:
    • Aplicaciones para Control de sistemas y automatización industrial
    • Aplicaciones ofimáticas
    • Software educativo
    • Software empresarial
    • Bases de datos
    • Telecomunicaciones (por ejemplo Internet y toda su estructura lógica)
    • Videojuegos
    • Software médico
    • Software de Cálculo Numérico y simbólico.
    • Software de Diseño Asistido (CAD)
    • Software de Control Numérico (CAM)


    Proceso de creación del 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.
    El 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 (por ejemplo, la 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) 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 y provee una estimación de 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 complejas tareas, tanto técnicas como de gerencia, una fuerte gestión y análisis diversos (entre otras cosas), por lo cual se ha desarrollado una ingeniería para su estudio y realización: es conocida como Ingeniería de Software.
    En tanto que en los de mediano porte, pequeños equipos de trabajo (incluso un avezado analista-programador solitario) pueden 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 por el 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 del software a desarrollar, a criterio del líder (si lo hay) del equipo de desarrollo. Algunos de esos procesos son Programación Extrema (en inglés eXtreme Programming o XP), Proceso Unificado de Rational (en inglés Rational Unified Process o RUP), Feature Driven Development (FDD), etc.
    Cualquiera sea el «proceso» utilizado y aplicado al desarrollo del 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 retrasan 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, ser 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 de 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

Este, aunque es más comúnmente conocido como modelo en cascada es también llamado «modelo clásico», «modelo tradicional» o «modelo lineal secuencial».
El modelo en cascada puro 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 rigidez) 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ínsecamente el software es de carácter evolutivo, cambiante y difícilmente libre de errores, tanto durante su desarrollo como durante su vida operativa.[
  - Modelo cascada puro o secuencial para el ciclo de vida del software.
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 redundaría en altos costos de tiempo y desarrollo. La figura 2 muestra un posible esquema de el modelo en cuestión.
Sin embargo, el modelo cascada en algunas de sus variantes es uno de los actualmente 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, ambigüedades 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.
De esta manera se obtiene un «modelo cascada realimentado», que puede ser esquematizado como lo ilustra la figura 3.
Fig. 3 - Modelo cascada realimentado para el ciclo de vida.
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 rigidez (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 etapas, menores y más específicas) o incluso mostrar menos etapas de las indicadas, aunque en tal caso la faltante estará dentro de alguna otra. El orden de esas fases indicadas en el ítem previo es el 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 antiguo 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 software y continúa siendo el más utilizado; y siempre es mejor que un enfoque al azar.
Desventajas del modelo cascada:
  • Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba) pueden ser catastróficos para un proyecto grande.
  • No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos es luego difícil de acomodar.
  • El cliente debe tener paciencia ya que el software no estará disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser desastroso, implicando reinicio del proyecto, con altos costos.

Modelos evolutivos

El software evoluciona con el tiempo. Los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el mercado un producto absolutamente completo, por lo que se debe 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, donde 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 en cuenta la naturaleza evolutiva del software, se plantea como estático con requisitos bien conocidos y definidos desde el inicio.
Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y complejas, hasta 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.
Modelo iterativo incremental
En términos generales, podemos 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 identifican claramente dichos pasos. La Descripción del Sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al Producto global y final. Las actividades concurrentes (Especificación, Desarrollo y Validación) sintetizan el desarrollo pormenorizado de los incrementos, que se hará posteriormente.
Fig. 4 - Diagrama genérico del desarrollo evolutivo incremental.
El diagrama 4 nos muestra en forma muy esquemática, el funcionamiento de un ciclo iterativo incremental, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto final.[6] Es decir, a medida que cada incremento definido llega a su etapa de operación y mantenimiento. Cada versión emitida incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron analizados como necesarios.
El incremental es un modelo de tipo evolutivo que está basado en varios ciclos Cascada realimentados aplicados repetidamente, con una filosofía iterativa. En la figura 5 se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener finalmente el esquema del Modelo de ciclo de vida Iterativo Incremental, con sus actividades genéricas asociadas. Aquí se observa claramente cada ciclo cascada que es aplicado para la obtención de un incremento; estos últimos se van integrando para obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por simplicidad, en la figura 5 se muestra como secuencial puro.
Fig. 5 - Modelo iterativo incremental para el ciclo de vida del software,.
Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o concurrentemente, así por ejemplo, en la figura, mientras se realiza el diseño detalle del primer incremento ya se está realizando en análisis del segundo. La figura 5 es sólo esquemática, un incremento no necesariamente se iniciará durante la fase de diseño del anterior, puede ser posterior (incluso antes), en cualquier tiempo de la etapa previa. Cada incremento concluye con la actividad de «operación y mantenimiento» (indicada «Operación» en la figura), que es donde se produce la entrega del producto parcial al cliente. El momento de inicio de cada incremento es dependiente de varios factores: tipo de sistema; independencia o dependencia entre incrementos (dos de ellos totalmente independientes pueden ser fácilmente iniciados al mismo tiempo si se dispone de personal suficiente); capacidad y cantidad de profesionales involucrados en el desarrollo; etc.
Bajo este modelo se entrega software «por partes funcionales más pequeñas», pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.
Como se muestra en la figura 5, se aplican secuencias Cascada en forma escalonada, mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y a menudo el primer incremento es un sistema básico, con muchas funciones suplementarias (conocidas o no) sin entregar.
El cliente utiliza inicialmente ese sistema básico intertanto, el resultado de su uso y evaluación puede aportar al plan para el desarrollo del/los siguientes incrementos (o versiones). Además también aportan a ese plan otros factores, como lo es la priorización (mayor o menor urgencia en la necesidad de cada incremento) y la dependencia entre incrementos (o independencia).
Luego de cada integración se entrega un producto con mayor funcionalidad que el previo. El proceso se repite hasta alcanzar el software final completo.
Siendo iterativo, con el modelo incremental se entrega un producto parcial pero completamente operacional en cada incremento, y no una parte que sea usada para reajustar los requerimientos (como si ocurre en el modelo de construcción de prototipos).
El enfoque incremental resulta muy útil con baja dotación de personal para el desarrollo; también si no hay disponible fecha límite del proyecto por lo que se entregan versiones incompletas pero que proporcionan al usuario funcionalidad básica (y cada vez mayor). También es un modelo útil a los fines de evaluación.
Nota: Puede ser considerado y útil, en cualquier momento o incremento incorporar temporalmente el paradigma MCP como complemento, teniendo así una mixtura de modelos que mejoran el esquema y desarrollo general.
Ejemplo:
Un procesador de texto que sea desarrollado bajo el paradigma Incremental podría aportar, en principio, funciones básicas de edición de archivos y producción de documentos (algo como un editor simple). En un segundo incremento se le podría agregar edición más sofisticada, y de generación y mezcla de documentos. En un tercer incremento podría considerarse el agregado de funciones de corrección ortográfica, esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y ecuaciones matemáticas. Así sucesivamente hasta llegar al procesador final requerido. Así, el producto va creciendo, acercándose a su meta final, pero desde la entrega del primer incremento ya es útil y funcional para el cliente, el cual observa una respuesta rápida en cuanto a entrega temprana; sin notar que la fecha límite del proyecto puede no estar acotada ni tan definida, lo que da margen de operación y alivia presiones al equipo de desarrollo.
Como se dijo, el Iterativo Incremental es un modelo del tipo evolutivo, es decir donde se permiten y esperan probables cambios en los requisitos en tiempo de desarrollo; se admite cierto margen para que el software pueda evolucionar. Aplicable cuando los requisitos son medianamente bien conocidos pero no son completamente estáticos y definidos, cuestión esa que si es indispensable para poder utilizar un modelo Cascada.
El modelo es aconsejable para el desarrollo de software en el cual se observe, en su etapa inicial de análisis, que posee áreas bastante bien definidas a cubrir, con suficiente independencia como para ser desarrolladas en etapas sucesivas. Tales áreas a cubrir suelen tener distintos grados de apremio por lo cual las mismas se deben priorizar en un análisis previo, es decir, definir cual será la primera, la segunda, y así sucesivamente; esto se conoce como «definición de los incrementos» con base en priorización. Pueden no existir prioridades funcionales por parte del cliente, pero el desarrollador debe fijarlas de todos modos y con algún criterio, ya que basándose en ellas se desarrollarán y entregarán los distintos incrementos.
El hecho de que existan incrementos funcionales del software lleva inmediatamente a pensar en un esquema de desarrollo modular, por tanto este modelo facilita tal paradigma de diseño.
En resumen, un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del producto software denominados «incrementos» del sistema, que son escogidos según prioridades predefinidas de algún modo. El modelo permite una implementación con refinamientos sucesivos (ampliación o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión previamente implementada del producto software.
Este modelo brinda cierta flexibilidad para que durante el desarrollo se incluyan cambios en los requisitos por parte del usuario, un cambio de requisitos propuesto y aprobado puede analizarse e implementarse como un nuevo incremento o, eventualmente, podrá constituir una mejora/adecuación de uno ya planeado. Aunque si se produce un cambio de requisitos por parte del cliente que afecte incrementos previos ya terminados (detección/incorporación tardía) se debe evaluar la factibilidad y realizar un acuerdo con el cliente, ya que puede impactar fuertemente en los costos.
La selección de este modelo permite realizar entregas funcionales tempranas al cliente (lo cual es beneficioso tanto para él como para el grupo de desarrollo). Se priorizan las entregas de aquellos módulos o incrementos en que surja la necesidad operativa de hacerlo, por ejemplo para cargas previas de información, indispensable para los incrementos siguientes.
El modelo iterativo incremental no obliga a especificar con precisión y detalle absolutamente todo lo que el sistema debe hacer, (y cómo), antes de ser construido (como el caso del cascada, con requisitos congelados). Sólo se hace en el incremento en desarrollo. Esto torna más manejable el proceso y reduce el impacto en los costos. Esto es así, porque en caso de alterar o rehacer los requisitos, solo afecta una parte del sistema. Aunque, lógicamente, esta situación se agrava si se presenta en estado avanzado, es decir en los últimos incrementos. En definitiva, el modelo facilita la incorporación de nuevos requisitos durante el desarrollo.
Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa funcionalidad parcial. También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software.
El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, o de alto índice de riesgos.
Modelo espiral
El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada. Proporciona potencial para desarrollo rápido de versiones incrementales. En el modelo Espiral el software se construye en una serie de versiones incrementales. En las primeras iteraciones la versión incremental podría ser un modelo en papel o bien un prototipo. En las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.
El modelo se divide en un número de Actividades de marco de trabajo, llamadas «regiones de tareas». En general existen entre tres y seis regiones de tareas (hay variantes del modelo). En la figura 6 se muestra el esquema de un Modelo Espiral con 6 regiones. En este caso se explica una variante del modelo original de Boehm, expuesto en su tratado de 1988; en 1998 expuso un tratado más reciente.
Fig. 6 - Modelo espiral para el ciclo de vida del software.
Las regiones definidas en el modelo de la figura son:
  • Región 1 - Tareas requeridas para establecer la comunicación entre el cliente y el desarrollador.
  • Región 2 - Tareas inherentes a la definición de los recursos, tiempo y otra información relacionada con el proyecto.
  • Región 3 - Tareas necesarias para evaluar los riesgos técnicos y de gestión del proyecto.
  • Región 4 - Tareas para construir una o más representaciones de la aplicación software.
  • Región 5 - Tareas para construir la aplicación, instalarla, probarla y proporcionar soporte al usuario o cliente (Ej. documentación y práctica).
  • Región 6 - Tareas para obtener la reacción del cliente, según la evaluación de lo creado e instalado en los ciclos anteriores.
Las actividades enunciadas para el marco de trabajo son generales y se aplican a cualquier proyecto, grande, mediano o pequeño, complejo o no. Las regiones que definen esas actividades comprenden un «conjunto de tareas» del trabajo: ese conjunto sí se debe adaptar a las características del proyecto en particular a emprender. Nótese que lo listado en los ítems de 1 a 6 son conjuntos de tareas, algunas de las ellas normalmente dependen del proyecto o desarrollo en si.
Proyectos pequeños requieren baja cantidad de tareas y también de formalidad. En proyectos mayores o críticos cada región de tareas contiene labores de más alto nivel de formalidad. En cualquier caso se aplican actividades de protección (por ejemplo, gestión de configuración del software, garantía de calidad, etc.).
Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniería gira alrededor del espiral (metafóricamente hablando) comenzando por el centro (marcado con ๑ en la figura 6) y en el sentido indicado; el primer circuito de la espiral puede producir el desarrollo de una 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 realimentan en función de la evaluación del cliente. El gestor de proyectos debe ajustar el número de iteraciones requeridas 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 modelo clásico, o cascada, el proceso termina a la entrega del software).
Una visión alternativa del modelo puede observarse examinando el «eje de punto de entrada de proyectos». Cada uno de los circulitos (๏) fijados a lo largo del eje representan puntos de arranque de los distintos proyectos (relacionados); a saber:
  • Un proyecto de «desarrollo de conceptos» comienza al inicio de la espiral, hace múltiples iteraciones hasta que se completa, es la zona marcada con verde.
  • Si lo anterior se va a desarrollar como producto real, se inicia otro proyecto: «Desarrollo de nuevo Producto». Que evolucionará con iteraciones hasta culminar; es la zona marcada en color azul.
  • Eventual y análogamente se generarán proyectos de «mejoras de productos» y de «mantenimiento de productos», con las iteraciones necesarias en cada área (zonas roja y gris, respectivamente).
Cuando la espiral se caracteriza de esta forma, está operativa hasta que el software se retira, eventualmente puede estar inactiva (el proceso), pero cuando se produce un cambio el proceso arranca nuevamente en el punto de entrada apropiado (por ejemplo, en «mejora del producto»).
El modelo espiral da un enfoque realista, que evoluciona igual que el software; se adapta muy bien para desarrollos a gran escala.
El Espiral utiliza el MCP para reducir riesgos y permite aplicarlo en cualquier etapa de la evolución. Mantiene el enfoque clásico (cascada) pero incorpora un marco de trabajo iterativo que refleja mejor la realidad.
Este modelo requiere considerar riesgos técnicos en todas las etapas del proyecto; aplicado adecuadamente debe reducirlos antes de que sean un verdadero problema.
El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de Sistemas Operativos (complejos); también en sistemas de altos riesgos o críticos (Ej. navegadores y controladores aeronáuticos) y en todos aquellos en que sea necesaria una fuerte gestión del proyecto y sus riesgos, técnicos o de gestión.
Desventajas importantes:
  • Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto.
  • Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo.
Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por lo que no se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difícil de implementar y controlar.
Modelo espiral Win & Win
Una variante interesante del Modelo Espiral previamente visto (Fig. 6) es el «Modelo espiral Win-Win»[7] (Barry Boehm). El Modelo Espiral previo (clásico) sugiere la comunicación con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él proporciona la información para continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.
«Es así que la obtención de requisitos requiere una negociación, que tiene éxito cuando ambas partes ganan».
Las mejores negociaciones se fuerzan en obtener «Victoria & Victoria» (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes habilidades de negociación.
El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral; se definen las siguientes actividades:
  1. Identificación del sistema o subsistemas clave de los directivos(*) (saber qué quieren).
  2. Determinación de «condiciones de victoria» de los directivos (saber qué necesitan y los satisface)
  3. Negociación de las condiciones «victoria» de los directivos para obtener condiciones «Victoria & Victoria» (negociar para que ambos ganen).
(*) Directivo: Cliente escogido con interés directo en el producto, que puede ser premiado por la organización si tiene éxito o criticado si no.
El modelo Win & Win hace énfasis en la negociación inicial, también introduce 3 hitos en el proceso llamados «puntos de fijación», que ayudan a establecer la completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo del software.

Etapas en el desarrollo del 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 de Modelo 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, probablemente, 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 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 fluida y adecuada comunicación y comprensió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 que resolver, no conoce en absoluto el área (informática), ni su jerga, ni siquiera sabe con precisió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 comprensió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 caso más sencillo para el analista.
Las 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[10] , aunque ella aún 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 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 que 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 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[11] 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, aquí 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. 7 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. También 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. 7 - 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, en fase de Especificación de Requisitos 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 distinto nivel de detalle.
Ejemplo de requisito de usuario: El sistema debe hacer préstamos Ejemplo de requisito de sistema: Función préstamo: entrada código socio, código ejemplar; salida: fecha devolución; etc.
Se clasifican en tres los tipos de requisitos de sistema:
  • 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.
  • 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.)
Ejemplo 1. La biblioteca Central debe ser capaz de atender simultáneamente a todas las bibliotecas de la Universidad
Ejemplo 2. El tiempo de respuesta a una consulta remota no debe ser superior a 1/2 s
A su vez, hay tres tipos de requisitos no funcionales:
  • Requisitos del producto. Especifican el comportamiento del producto (Ej. prestaciones, memoria, tasa de fallos, etc.)
  • 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.)
  • Requisitos externos. Se derivan de factores externos al sistema y al proceso de desarrollo (Ej. requisitos legislativos, éticos, etc.)
  • 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 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 lenguaje ensamblador que el mismo programado en lenguaje C.
Mientras se programa la aplicación, 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 subsiguientes. 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, bibliotecas 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 biblioteca 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érprete puro, intérprete intermedio, compilador intermedio o compilador puro, depende de la versión utilizada)].
    • 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 elegido 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 bibliotecas 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».

Pruebas (unitarias y de integración)

Entre las diversas pruebas que se le efectúan al software se pueden distinguir principalmente:
  • Prueba unitarias: Consisten en probar o testear piezas de software pequeñas; a nivel de secciones, procedimientos, funciones y módulos; aquellas que tengan funcionalidades específicas. Dichas pruebas se utilizan para asegurar el correcto funcionamiento de secciones de código, mucho más reducidas que el conjunto, y que tienen funciones concretas con cierto grado de independencia.
  • Pruebas de integración: Se realizan una vez que las pruebas unitarias fueron concluidas exitosamente; con éstas se intenta asegurar que el sistema completo, incluso los subsistemas que componen las piezas individuales grandes del software funcionen correctamente al operar e inteoperar en conjunto.
Las pruebas normalmente se efectúan con los llamados datos de prueba, que es un conjunto seleccionado de datos típicos a los que puede verse sometido el sistema, los módulos o los bloques de código. También se escogen: Datos que llevan a condiciones límites al software a fin de probar su tolerancia y robustez; datos de utilidad para mediciones de rendimiento; datos que propocan condiciones eventuales o particulares poco comunes y a las que el software normalmente no estará sometido pero pueden ocurrir; etc. Los «datos de prueba» no necesariamente son ficticios o «creados», pero normalmente si lo son los de poca probabilidad de ocurrencia.
Generalmente, existe un fase probatoria final y completa del software, llamada Beta Test, durante la cual el sistema instalado en condiciones normales de operación y trabajo es probado exhaustivamente a fin de encontrar errores, inestabilidades, respuestas erróneas, etc. que hayan pasado los previos controles. Estas son normalmente realizadas por personal idóneo contratado o afectado específicamente a ello. Los posibles errores encontrados se transmiten a los desarrolladores para su depuración. En el caso de software de desarrollo «a pedido», el usuario final (cliente) es el que realiza el Beta Test, teniendo para ello un período de prueba pactado con el desarrollador.

Instalación y paso a producción

La instalación del software es el proceso por el cual los programas desarrollados son transferidos apropiadamente al computador destino, inicializados, y, eventualmente, configurados; todo ello con el propósito de ser ya utilizados por el usuario final. Constituye la etapa final en el desarrollo propiamente dicho del software. Luego de ésta el producto entrará en la fase de funcionamiento y producción, para el que fuera diseñado.
La instalación, dependiendo del sistema desarrollado, puede consistir en una simple copia al disco rígido destino (casos raros actualmente); o bien, más comúnmente, con una de complejidad intermedia en la que los distintos archivos componentes del software (ejecutables, bibliotecas, datos propios, etc.) son descomprimidos y copiados a lugares específicos preestablecidos del disco; incluso se crean vínculos con otros productos, además del propio sistema operativo. Este último caso, comúnmente es un proceso bastante automático que es creado y guiado con heramientas software específicas (empaquetado y distribución, instaladores).
En productos de mayor complejidad, la segunda alternativa es la utilizada, pero es realizada o guiada por especialistas; puede incluso requerirse la instalación en varios y distintos computadores (instalación distribuida).
También, en software de mediana y alta complejidad normalmente es requerido un proceso de configuración y chequeo, por el cual se asignan adecuados parámetros de funcionamiento y se testea la operatividad funcional del producto.
En productos de venta masiva las instalaciones completas, si son relativamente simples, suelen ser realizadas por los propios usuarios finales (tales como sistemas operativos, paquetes de oficina, utilitarios, etc.) con herramientas propias de instalación guiada; incluso la configuración suele ser automática. En productos de diseño específico o «a medida» la instalación queda restringida, normalmente, a personas especialistas involucradas en el desarrollo del software en cuestión.
Una vez realizada exitosamente la instalación del software, el mismo pasa a la fase de producción (operatividad), durante la cual cumple las funciones para las que fue desarrollado, es decir, es finalmente utilizado por el (o los) usuario final, produciendo los resultados esperados.

Mantenimiento

El mantenimiento de software es el proceso de control, mejora y optimización del software ya desarrollado e instalado, que también incluye depuración de errores y defectos que puedan haberse filtrado de la fase de pruebas de control y beta test. Esta fase es la última (antes de iterar, según el modelo empleado) que se aplica al ciclo de vida del desarrollo de software. La fase de mantenimiento es la que viene después de que el software está operativo y en producción.
De un buen diseño y documentación del desarrollo dependerá cómo será la fase de mantenimiento, tanto en costo temporal como monetario. Modificaciones realizadas a un software que fue elaborado con una documentación indebida o pobre y mal diseño puede llegar a ser tanto o más costosa que desarrollar el software desde el inicio. Por ello, es de fundamental importancia respetar debidamente todas las tareas de las fases del desarrollo y mantener adecuada y completa la documentación.
El período de la fase de mantenimiento es normalmente el mayor en todo el ciclo de vida. Esta fase involucra también actualizaciones y evoluciones del software; no necesariamente implica que el sistema tuvo errores. Uno o más cambios en el software, por ejemplo de adaptación o evolutivos, puede llevar incluso a rever y adaptar desde parte de las primeras fases del desarrollo inicial, alterando todas las demás; dependiendo de cuán profundos sean los cambios. El modelo cascada común es particularmente costoso en mantenimiento, ya que su rigidez implica que cualquier cambio provoca regreso a fase inicial y fuertes alteraciones en las demás fases del ciclo de vida.
Durante el período de mantenimiento, es común que surjan nuevas revisiones y versiones del producto; que lo liberan más depurado, con mayor y mejor funcionalidad, mejor rendimiento, etc. Varias son las facetas que pueden ser alteradas para provocar cambios deseables, evolutivos, adaptaciones o ampliaciones y mejoras.
Básicamente se tienen los siguientes tipos de cambios:
  • Perfectivos: Aquellos que llevan a una mejora de la calidad interna del software en cualquier aspecto: Reestructuración del código, definición más clara del sistema y su documentación; optimización del rendimiento y eficiencia.
  • Evolutivos: Agregados, modificaciones, incluso eliminaciones, necesarias en el software para cubrir su expansión o cambio, según las necesidades del usuario.
  • Adaptivos: Modificaciones que afectan a los entornos en los que el sistema opera, tales como: Cambios de configuración del hardware (por actualización o mejora de componentes electrónicos), cambios en el software de base, en gestores de base de datos, en comunicaciones, etc.
  • Correctivos: Alteraciones necesarias para corregir errores de cualquier tipo en el producto software desarrollado.