Unidad 1
Software como producto y como proceso
La computadora es un dispositivo electrónico capaz de realizar cálculos y procesar
información a velocidades muy superiores a las que podría hacerlo un humano y
consta de dos partes fundamentales: el hardware (HW), que hace referencia a la
parte tangible o física de la computadora, y el software (SW), que comprende
todos los programas que hacen posible el tratamiento de la información.
En computación, el software es todo programa o aplicación para realizar tareas
específicas inteligentes. Es un conjunto de instrucciones que las computadoras
utilizan para manipular datos; una colección de programas, documentos,
procedimientos y rutinas asociadas con la operación de un sistema de cómputo.
En los primeros años de software, los programas eran realizados por una sola
persona utilizando lenguajes de bajo nivel y ajustado a una sola computadora, lo
que generaba programas difíciles de entender incluso para su creador (pasado
algún tiempo). Si se requería el mismo SW en otras computadoras, se repetía el
mismo proceso para desarrollarlo.
La productividad de este tipo de software era muy baja dado que no garantizaba
confiabilidad ni facilidad de mantenimiento, apartados que poco a poco mejoraron
con base en las experiencias de los programadores y con la aparición de técnicas
estructuradas; sin embargo, seguían teniendo fallas a causas de documentación
inadecuada y la dificultad para su correcto funcionamiento, entre otros.
Conforme incrementaba la tecnología a nivel de HW también crecía la demanda
de SW, solo que más lentamente, de modo que hacia 1990 se decía que el SW
estaba retrasado respecto a las del HW en un mínimo de dos generaciones de
procesadores. En la actualidad muchos de estos problemas subsisten, debido a la
dificultad de satisfacer totalmente las demandas de los clientes.
El software se clasifica en:
Software de sistema. – Se basa en el conjunto de programas que sirve
para interactuar con el sistema, delegando el control sobre el hardware y dando
soporte a otros programas. Como ejemplo tenemos la Interfaz de usuario,
administrador de recursos y el administrador de tareas. Es el software necesario
para que opere la computadora (sistema operativo) y a su vez se divide en SO
monousuario, multiusuario, etc.
Software de aplicación. - Son programas diseñados para o por los
usuarios para facilitar tareas específicas, como las aplicaciones ofimáticas o
software especializado educativo, medico, etc. También se encuentran los
programas de compresión, edición de fotos, videos, navegadores y demás.
Software de programación. – Es el conjunto de herramientas que
permiten al desarrollador formular programas usando alternativas y lenguaje de
programación. Incluye compiladores, interpretes, ensambladores, enlazadores,
depuradores, editores de texto y una interfaz gráfica (GUI).
Los lenguajes de programación evolucionaron pasando de lenguajes de bajo nivel
y ensambladores a lenguajes de alto nivel como FORTRAN (1957) o COBOL
(1960), siendo estos últimos más amigables con el programador. En los primeros
ordenadores como el ENIAC, las instrucciones se perforaban en una cinta de
papel o se establecían mediante conexiones manuales en un panel eléctrico, pero
muchas instrucciones tenían que repetirse una y otra vez en cada programa, por lo
que pronto se ideó una “maquina” complementaria que aceptara lo que un
programador tecleara en un lenguaje casi algebraico en códigos numéricos. Al
final, todo eso se hizo en la misma maquina en que tenía que ejecutarse el
programa, dando como resultado el nacimiento de Software y los primeros
lenguajes de programación.
Existe tanto SW comercial (propietario) como libre. En el caso del SW comercial,
el usuario debe comprar una licencia para ser utilizado bajo un contrato con el
propietario, esto significa que posee código cerrado que no se puede modificar ni
distribuir (comenzó en los años 1970, donde el principal impulsor de tal software
es Microsoft, propiedad de Bill Gates). En contra parte, el SW libre concede a los
usuarios la posibilidad de usarlo, estudiarlo, modificarlo y hacer una distribución a
toda una comunidad. Su código es abierto, se puede estudiar, modificar y
adaptarlo a sus necesidades.
El software como producto tecnológico posee características muy peculiares,
debido a que el software no se fabrica, sino que se escribe. Además, es un
producto lógico, por lo que la inversión para desarrollarlo no es tan importante
como para la fabricación de otras tecnologías ni se deteriora como estas últimas;
es decir, que solo se puede hacer obsoleto desde la perspectiva de enfrentarlo a
otros desarrollos más rápidos o modernos, de modo que mantiene su
funcionalidad si no se modifican sustancialmente los dispositivos de hardware en
los que se implementa.
Mitos del desarrollo de software
La evolución en las disciplinas de desarrollo de software, junto a sus
características particulares como lo es la inmaterialidad del mismo, hacen que sea
difícil obtener una versión serena y justa del software, provocando opiniones
infundadas sobre la importancia de determinados factores en el éxito o calidad de
un producto de software y se da tanto de lado de los profesionales como de los
clientes. Así, tenemos los siguientes mitos:
El hardware es más importante que el software. - Totalmente
falso. Al usar la computadora la interacción se hace
fundamentalmente mediante el software y solo de manera muy
limitada el usuario accede directamente al hardware.
El software es fácil de desarrollar. – Esto es falso para cualquier
aplicación de cierta importancia. El desarrollo es muy complejo y
costoso, tanto así que exige una mayor proporción de mano de obra
frente al empleo de maquinaria, llevando a un aumento del coste de
productos software.
El software consiste exclusivamente en programas ejecutables.
– Falso. Al concebir un software de manera global hay que pensar en
todos los elementos que intervienen: Hardware, Software y
personas. Igualmente, la documentación necesaria para mantener el
producto después de implementarlo.
El desarrollo de software es solo una labor de programación. –
No se puede limitar el trabajo de desarrollo solo a la fase de
codificación. Las tareas de análisis y diseño son el fundamento para
todo el resto del desarrollo del proyecto, del mismo modo en que un
arquitecto o ingeniero es necesario para la construcción de un
edificio, que no consiste únicamente en colocar materiales uno sobre
otro.
Es natural que el software contenga errores. – No exactamente.
Si bien es cierto que el desarrollo de software es susceptible de
errores como cualquier actividad humana, no es admisible que los
productos software contengan errores, ya que este no puede
simplemente sustituirse por otro sin defecto, ya que todas las copias
de software son exactamente las mismas.
El software como proceso
Para llevar a cabo la realización del software, es necesario abordar de manera
homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto
de desarrollo; una metodología es un conjunto integrado de técnicas y métodos
que permiten llevar a cabo tal tarea. Es un modo sistemático para realizar,
gestionar y administrar un proyecto, y comprende procesos para idear,
implementar y mantener un producto de software.
Podemos destacar de una metodología lo siguiente:
Optimiza el proceso y producto software.
Métodos que guían en la planificación y el desarrollo de software.
Define que hacer, como y cuando durante todo el desarrollo y
mantenimiento de un proyecto.
Una metodología define una estrategia global para enfrentarse al proyecto.
Considera las fases o etapas del mismo, la documentación, E/S de cada fase,
procedimientos y herramientas y los criterios de evaluación. Es importante
conocer que una metodología de desarrollo de sistemas no tiene que ser
necesariamente adecuada para usarla en todos los proyectos. Cada una de las
metodologías es más adecuada para tipos específicos e proyectos,
dependiendo de la necesidad de cada uno.
La metodología tradicional es denominada, a veces, metodología pesada.
Centran su atención en llevar una documentación exhaustiva de todo el
proyecto, la planificación y control del mismo. Imponen una disciplina rigurosa
de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir
el software más eficiente. Son metodologías que no se adaptan
adecuadamente a los cambios, por lo que no son adecuadas cuando se trabaja
en un entorno donde los requisitos no pueden predecirse o bien pueden variar.
Posee altos costes al implementar un cambio y falta de flexibilidad en
proyectos donde el entorno es volátil.
Las metodologías agiles, por el contrario, se basa en retrasar las decisiones y
la planificación adaptativa. Basan su fundamento en la adaptabilidad de los
procesos de desarrollo. Es un proceso Incremental, Cooperativo, Sencillo y
Adaptativo. Proporcionan una serie de pautas y principios que hacen que la
entrega de proyecto sea menos complicada y más satisfactoria para los
clientes como para los equipos de trabajo.
Tipos de metodologías
Modelo Lineal secuencial (cascada)
Es denominada así por la posición de las fases de desarrollo de esta, que
parecen caer en cascada “por gravedad” hacia las siguientes fases. Ordena
rigurosamente las etapas del proceso, de tal forma que el inicio de cada etapa
debe esperar a que finalice la etapa anterior. Al final de cada una de ellas, se
realiza una revisión final para determinar si el proyecto está listo para avanzar
a la siguiente fase. Este modelo comenzó a diseñarse en 1966 y se terminó
alrededor de 1970. El principal problema de esta aproximación es el que no
podemos esperar que las especificaciones iníciales sean correctas y completas
y que el usuario puede cambiar de opinión sobre una u otra característica. Si
esto ocurre, tendremos que volver hacia atrás en el ciclo de vida.
Ingeniería y Análisis de Sistema. – El trabajo comienza estableciendo los
requisitos de todos los elementos del sistema.
Análisis de los requisitos de software. - El ingeniero del software debe
comprender el ámbito de la información del software, la función, rendimiento y las
interfaces requeridas.
Diseño. - Se enfoca en la estructura de datos, arquitectura de SW, el detalle
procedimental y la interfaz.
Codificación. - El diseño debe traducirse en una forma legible para la máquina.
Prueba. – Se centra en la lógica interna del software y en las funciones externas,
realizando pruebas que aseguren los resultados que realmente se requieren.
Mantenimiento. – Los cambios ocurrirán debido a que se han encontrado errores,
a que el software deba adaptarse o debido a los requerimientos del cliente.
Las desventajas que posee este modelo es que raramente se sigue el flujo
secuencial que propone, sumado a que es difícil para el cliente establecer
explícitamente al principio todos los requisitos, además debe tener paciencia dado
que hasta llegar a las etapas finales del proyecto estará disponible una versión
operativa del sistema. Un error importante no detectado hasta este punto puede
ser desastroso.
Modelo Prototipo
Es la creación de una implementación parcial de un sistema, para así poder
aprender sobre los requerimientos del mismo, y es construido de una manera
rápida como sea posible. Es dado a los usuarios, clientes o representantes de
ellos, posibilitando que experimenten con el prototipo; después, proveen la
retroalimentación sobre lo que les gusto y lo que no acerca del mismo, capturando
en la documentación la especificación de requerimientos para el desarrollo del
sistema real.
El prototipo ha sido usado frecuentemente en los 90 porque la especificación de
requerimientos para sistemas complejos tiende a ser relativamente dificultoso de
cursar. Es un método menos formal de desarrollo y sirve para comprender las
especificaciones. Puede ser eliminado o llegar a ser parte del producto final.
Son útiles cuando los requerimientos son cambiantes, cuando no se conoce bien
la aplicación, cuando el cliente no se compromete con los requerimientos o se
requiere rapidez en el desarrollo. En cuanto a sus desventajas, no se sabe
cuándo será un producto aceptable, da falsa ilusión sobre la velocidad de
desarrollo y puede ser producto aun cuando no está con los estándares.
Modelo Espiral
Toma las ventajas de los modelos anteriores y añade el concepto de análisis de
riesgo.
En este modelo se definen 4 actividades:
Planificación. – Se recolectan requisitos iniciales o nuevos a añadir
Análisis de riesgo. – Basados en los requisitos decidimos si somos capaces de
desarrollar el software o no.
Ingeniería. – Se desarrolla un prototipo basado en los requisitos de la primera
fase.
Evaluación del cliente. - El cliente comenta el prototipo. Si está conforme termina
el proceso, si no, se añaden los nuevos requisitos.
En cada fase el producto gana “madurez” hasta que se logre el objetivo deseado y
sea aprobado.
Modelo Espiral WIN WIN
Es una variante del modelo espiral previamente visto. El modelo espiral clásico
sugiere una comunicación con el cliente para fijar requisitos, pero es un contexto
que rara vez ocurre. Por lo general, cliente y desarrollador entran en una
negociación que da el coste frente a funcionalidad, rendimiento, calidad, etc.
Las mejores negociaciones se fuerzan en obtener <<Ganar y Ganar>>, es decir
que el cliente gane un producto que los satisfaga y el desarrollador gane
consiguiendo presupuesto y fecha de entrega.
Este modelo define un conjunto de negociación al principio de cada paso
alrededor de la espiral:
Identificación de sistema o subsistema clave de los directivos.
Determinación de condiciones de victoria de los directivos. (conocer que
necesitan y que los satisface)
Negociación de las condiciones de <<victoria>> para que ambos ganen.
Modelo Incremental
Permite construir el proyecto en etapas incrementales (requerimientos, diseño,
codificación, pruebas y entrega) en donde cada etapa agrega funcionalidad.
Reduce los riesgos al proveer visibilidad sobre nuevas versiones, así como
retroalimentación a través de la funcionalidad mostrada. Las pruebas e integración
son constantes. Se puede planear en base a la funcionalidad que se quiere
entregar primero.
Ventajas:
La solución va mejorando en forma progresiva a través de las iteraciones.
Los clientes no esperan hasta el fin del desarrollo para probar el sistema, y
pueden aclarar los requisitos que no tengan claros conforme ven las
entregas del mismo.
Se disminuye el riesgo de fracaso de todo el proyecto.
Las partes más importantes del sistema son entregadas primero.
Desventajas:
Requiere mucha planeación y metas claras para conocer el estado del
proyecto.
Es un proceso de desarrollo de software, creado en respuesta a las
debilidades del modelo de cascada.
RAD (Rapid Application development)
Está metodología ha tomado gran auge debido a la necesidad que tienen las
instituciones de crear aplicaciones funcionales en corto tiempo. Es un ciclo de
desarrollo para crear aplicaciones de alta calidad. Comprende el desarrollo
iterativo, prototipos y uso de utilidades CASE (Computer Aided Software
Engineering). Se suele utilizar para referirnos al desarrollo rápido de interfaces
gráficas. Algunas de las plataformas más conocidas son Visual estudio y Game
Maker.
Las fases con las que cuenta son las siguientes:
Modelado de gestión. – El flujo de información se modela e forma que
responda a las siguientes preguntas: ¿Qué información conduce el proceso
de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va
la información? ¿Quién la procesó?
Modelado de datos. – Se definen las características (llamadas atributos)
de cada uno de los objetos necesarios para apoyar a la empresa y las
relaciones entre estos.
Modelado de proceso. – Los objetos definidos queda transformados para
lograr el flujo de información necesario para implementar una función de
datos. Es la comunicación entre los objetos.
Generación de aplicaciones. – El DRA asume la utilización de técnicas de
cuarta generación. En lugar de crear software, el proceso trabaja para
utilizar componentes de programas ya existentes (cuando es posible) o
crear componentes reutilizables.
Pruebas de entrega. – Se deben probar todos los componentes nuevos y
ejercitar las interfaces de fondo.
En este modelo existen equipos compuestos por alrededor de 6 personas,
incluyendo desarrolladores y usuarios de tiempo completo del sistema, así como
personas involucradas con los requisitos.
Ventajas:
Comprar puede ahorrar dinero en comparación con construir.
Visibilidad temprana.
Mayor flexibilidad.
Menor codificación manual.
Mayor involucramiento de los usuarios.
Desventajas:
Comprar puede ser más caro que construir.
Equipo necesario.
Menos eficiente
Menor precisión científica.
Mas fallas.
Prototipos pueden no escalar.