Software

Se conoce como software al equipamiento o soporte lógico de un sistema informático, que comprende el conjunto de los componentes ' 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 llamado 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 con el usuario.

El anglicismo "software" es el más amplia mente difundido al referirse a este concepto, especialmente en la jerga técnica; en tanto que el término sinónimo «logia», derivado del término francés logiciel, es utilizado mayormente en países y zonas de influencia francesa. Su abreviatura es Sw.

Software (pronunciación AFI:[ˈsɒftwɛəʳ]) es una palabra proveniente del inglés (literalmente: partes blandas o suaves), que en español no posee una traducción adecuada al contexto, por lo cual se la utiliza asidua mente sin traducir y así fue admitida por la Real Academia Española (RAE). Aunque puede no ser estrictamente lo mismo, suele sustituirse por expresiones tales como programas (informáticos) o aplicaciones (informáticas) o soportes lógicos.

Software es lo que se denomina producto en Ingeniería de Software.

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 del sistema informático 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, controladores, herramientas y utilidades de apoyo que permiten el mantenimiento del sistema global. Incluye entre otros:
  • Sistemas operativos
  • Controladores de dispositivos
  • Herramientas de diagnóstico
  • Herramientas de Corrección y Optimizan
  • 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. Incluyen básicamente:
  • 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 coman dos 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 muchos 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)

• Vídeo juegos

• 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 un producto software que resuelva un problema específico.

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 aproximació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), la complejidad de ello ha llevado a que desarrolle una ingeniería específica para tratar 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 no logre concluir o termine sin cumplir los objetivos previstos, y con variedad de fallos inaceptables (fracasan, en pocas palabras). Entre tales «procesos» los hay ágiles o livianos (ejemplo XP), pesados y lentos (ejemplo RUP), y variantes intermedias. Normalmente se aplican de acuerdo al tipo y porte del software a desarrollar, a criterio del 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, XP, 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. 

• Captura, e licitació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

Modelos de proceso o ciclo de vida.

Modelo cascada

El modelo en cascada puro difícilmente se utiliza 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 sistemas a desarrollar. 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 sin errores, no habrá en absoluto variantes futuras». 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

• 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 aconsejable introducir una versión funcional limitada de alguna forma para aliviar las presiones competitivas.

En esas u otras situaciones similares los des arrolladores 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 re alimentado no se tiene demasiado en cuenta la naturaleza evolutiva del software, se plantea como estático, con requisitos bien conocidos y definidos desde el inicio.

Modelo iterativo incrementa

En términos generales, se puede distinguir, en la Figura 4, los pasos generales que sigue el proceso de desarrollo de un producto software. En el modelo de ciclo de vida seleccionado, se 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.

El diagrama de la Figura 4 muestra en forma muy esquemática, el funcionamiento de un ciclo iterativo incrementa, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto final.⁶ 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.

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 incrementa les. En el modelo Espiral el software se construye en una serie de versiones incrementares. En las primeras interacciones la versión incrementa podría ser un modelo en papel o bien un prototipo. En las últimas interacciones se producen versiones cada vez más completas del sistema diseñado.

• Región 1 - Tareas requeridas para establecer la comunicación entre el cliente y el desarrollado.
• 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.
• Un proyecto de «desarrollo de conceptos» comienza al inicio de la espiral, hace múltiples interacciones 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 interacciones 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 interacciones necesarias en cada área (zonas roja y gris, respectivamente).

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 (Incrementa) o MCP, por lo que no se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difícil de implementar y controlar.

Carácter evolutivo del software.

El software es el producto derivado del proceso de desarrollo, según la ingeniería de software. Este producto es intrínsecamente evolutivo durante su ciclo de vida. El software evoluciona, en general, generando versiones cada vez más completas, complejas, mejoradas, optimizadas en algún aspecto, adecuadas a nuevas plataformas (sean de hardware o sistemas operativos), etc.

Cuando un sistema deja de evolucionar, eventualmente cumplirá con su ciclo de vida, entrará en obsolescencia e inevitablemente, tarde o temprano, será reemplazado por un producto nuevo.

El software evoluciona sencillamente por que se debe adaptar a los cambios del entorno, sean funcionales (exigencias de usuarios), operativos, de plataforma o arquitectura hardware.

La dinámica de evolución del software es el estudio de los cambios del sistema. La mayor contribución en esta área fue realizada por Meir M. Lehman y Belady, comenzando en los años 70 y 80. Su trabajo continuó en la década de 1990, con Lehman y otros investigadores de relevancia en la re alimentación en los procesos de evolución (Lehman, 1996; Lehman et al., 1998; lehman et al., 2001). A partir de esos estudios propusieron un conjunto de leyes (conocidas como leyes de Lehman) respecto de los cambios producidos en los sistemas. Estas leyes (en realidad son hipótesis) son invariantes y amplia mente aplicables.