I. Ingeniería de Software. Conceptos Básicos
1. Naturaleza y Cualidades del Software
El software muchas veces se confunde con el concepto de un programa. Pero de hecho
el software es la combinación del programa ejecutable para una plataforma específica,
la documentación asociada, su configuración, código ejecutable, pruebas a las que
debe someterse y la descripción de su arquitectura.
El software siempre se espera que tenga las siguientes cualidades principales:
+) Mantenibilidad. Debe poder evolucionarse para cumplir con las necesidades de
cambios en requerimientos.
+) Confiabilidad. Debe ser fiable, seguro e integro, con el fin de que no dañe
la información o cause pérdidas económicas.
+) Eficiencia. Debe utilizar los recursos de una manera óptima
+) Usabilidad. Debe proporcionar facilidad de uso; con una interfaz de usuario y
una documentación adecuada.
De manera detallada, tiene las siguientes cualidades:
Correcto. Producto refleja especificaciones iniciales.
Confiable. Libre de defectos o bugs
Robusto. Ante problemas externos (en hardware o software)
reaccionar correctamente.
Eficiente. Aprovechar de manera óptima los recursos de cómputo.
Amigable. Claro de usar por el usuario (o programador en caso
de bibliotecas)
Verificable. Debe estar listo a ser probado en cualquier momento
y sin menores modificaciones.
Mantenible. Facil de adaptar a nuevos requerimientos.
Reparable. Facilmente modificable ante errores en especificacion
o desarrollo.
Evolucionable. Adapatable a nuevas tecnologías de cómputo.
Reusable. El esfuerzo de desarrollo se puede utilizar para
construir nuevos proyectos o ampliarlos.
Portable. Se adapate a cualquier plataforma de Hardware y Software.
Interoperable. Comunicación con otras aplicaciones.
Entendible. Claro como utilizar el software y que no sea
abstracto su funcionamiento.
Productivo. Permita ser automatizado
Entregable a tiempo. Se cumplan con el tiempo de entrega
del software.
Visible.Se puede identificar el estado de desarrollo del software.
El software se dice que tiene calidad si cumple con las cualidades anteriores y además
cada una de las partes que le componen está disponible.
La ingeniería de software es el estudio de las metodología para lograr producir software
de calidad.
2. Historia sobre metodologías de desarrollo del software
Cuando la necesidad construir software comenzo, estuvo en manos de gente muy especilizada.
El software resolvia tareas no genéricas y que no eran muy tendientes a evolucionar. Durante
esa epoca, la tecnología presentaba limitantes en recuros de hardware y los lenguajes de
programación eran basados en lenguaje máquina y ensamblador. El reutilizar el código era
algo impensable.
Las personas de sistemas empezaron a utilizar lenguajes de alto nivel (Algol, Cobol, Fortran)
que permitian abstraer el problema. Sin embargo la tradición de la generación anterior muchas
veces llevaban a obtener software que no era reutilizable, dado que era pensado como
lenguaje ensamblador. De hecho, era típico el uso de sentencias "GOTO" para construir
programas. Esto llevaba a programas poco eficientes y dificiles de leer y mantener. Surgió
la idea de programación estructurada y de ahí nacieron lenguajes como Pascal, que fueron
inspirados en apoyar los conceptos de la programación estructurada.
En esta época los sistemas de almacenamiento de datos fueron evolucionando, donde primero
se utilizaron algoritmos para manipular archivos; de ahí la gente generalizo las ideas y
llegaron a la conclusión de construir sistemas de base de datos, jeràrquicos, de redes y
al final relacionales. Las aplicaciones eran ejecutadas en computadoras-mainframes que
daban atención a miles de usuarios, dando orígen al cómputo centralizado.
Las metodologías de desarrollo eran diversas, pero muchas de ellas basadas en diagramas
de flujos de datos, modelos entidad/relacion y metodologías estructuradas, como la de Yourdon.
En paralelo, los sistemas de cómputo empezaron a necesitar un lenguaje que permitiera
construir aplicaciones portables y al mismo tiempo con una complejidad menor a los lenguajes
de alto nivel. De hecho, era necesario algo similar a ensamblador pero que aprovechara las
ideas dadas por los lenguajes de alto nivel. Y ese lenguaje fue C. El exito de C fue reflejado
cuando se pudo construir un sistema operativo portable a varias computadoras, Unix, que
transformo la visión de varios ingenieros de software. De hecho, el software que se construyo
con este tipo de filosofía era generado por cientos de usuarios, en ambitos de universidad
o computación. El enfoque de desarrollo, mas que seguir una metodología, era mas orientado
a que las personas tomaran interés por el proyecto y colaboraran de manera libre y sin
intereses. Esto origino a que se construyeran módulos de software para muchos tipos de
aplicaciones, comunicaciones, sistemas operativos, ambientes gráficos, bases de datos,
software de oficina, herramientas de desarrolladores. Este modelo, conocido como el de
la catedral y el bazar ayudo a que la industria de cómputo empezara a evolucionar y romper
los monopolios de las grandes compañías como IBM.
Y también se presentó otra revolución en el hardware. Era factible que una computadora
puediera usarse con pocos recuros, habia llegado la era de la computadora personal. El
software que se necesito para cada caso específico, empezó a volverse mas grande, y
las computadoras se empezaron a utilizar para cualquier tipo de aplicaciones. Microsoft
vio esta oportunidad y construyo software para hacer que la PC fuera fácil de manejar, y
ofrecio un sistema operativo muy simple, MSDOS, acompañado de un lenguaje de programación
muy facil de aprender, BASIC. El desarrollo de software salió de las manos de los computologos
y fue fácil que personas de distintas disciplinas desarrollaran aplicaciones; pero con
la contraparte de que no adoptaban ninguna metodología de desarrollo. La programación
estructurada alcanzó su cuspide y de hecho se impulsaron la creacion de bibliotecas de
software, para evitar que los programadores tuvieran que reescribir software desde cero;
llego el momento en el que software necesitaba compartirse. Esto llevo a muchas maneras
de compartir y modularizar el software, muy pocas estandarizadas.
Ante la necesidad de reutilizar, la programación estructurada no pudo responder de una
manera eficiente. Era típico que los programadores copiaran segmentos de código y
reescribieran los segmentos que tenían que redefinir, heradando código. Y por cada caso
particular, se empezaban a disparar muchos programas específicos. Esto sólo se podía
superar con lenguajes que usaran conceptos muy elaborados,como apuntadores, pero era
bastante dificil de entender. Ante esta problemàtica surgió un nuevo enfoque, la programación
orientada a objetos, que permitió escribir el software como pequeños bloques que se podían
ensamblar y reutilizar por medio de técnicas como encapsulamiento, herencia y polimorfismo.
Los desarrolladores vieron las bondades de este enfoque y lo adoptaron; el lenguaje mas
utilizado era C++. El uso de ambientes gráficos, ante el éxito de Microsoft con Windows
y en plataformas mas serias como UNIX para construir sistemas cliente/servidor; impulso
a la generación de bibliotecas de objetos que permitían a los programadores a adoptar
tecnologías hechas y personalizarlas. El punto final de esto han sido los marcos de trabajo
o frameworks, que es software que proporciona el esqueleto de la aplicación, con funcionalidad
muy elaborada y al cual se le pueden integrar nuevos objetos de acuerdo a las necesidades
del sistema de información.
Surgieron metodologías de desarrollo orientadas a objetos, de Jacobson con sus casos de uso,
de Booch con su OMT y otros métodos. Muchos tomaban un modelo de cascada o espiral para
la construcción del software, pero si empezó a volverse un problema el crear software, dado
que su complejidad crecía, ante la complejidad de recursos que se tenían que manejar.
Y el mundo del cómputo se vio revolucionado de nuevo, dado que era posible el conectar
cualquier sistema de información a otro sistema remoto, gracias a la tecnología con la que
se apoyo Internet. Esto llevo a que se tenían que crear aplicaciones portables a cualquier
plataforma y de fácil acceso; principalmente desde el navegador de Internet. Lenguajes como
Java surgieron ante esta necesidad, donde aprovecho los conceptos de la programación
orientada a objetos. Y el software se enfocó al desarrollo de componentes de software, los
cuales cubrían problemas muy específicos y que podían ser integrados a cualquier lenguaje.
Además, el mundo cliente/servidor se convirtió a objetos y surgieron protocolos para comunicar
objetos, uno de ellos CORBA, otro DCOM. Microsoft se enfocó a dos lenguajes, Visual Basic
para construir aplicaciones y Visual C++ para aplicaciones mas elaboradas y que necesitaran
servicios del sistema operativo o frameworks.
Y las aplicaciones de Internet fueron creciendo y apoyandose mas en el modelo del cliente
ligero, donde se construye software que corre en un servidor, bajo modelos en los cuales
las aplicaciones se conectan entre sí. Enfoques como ASP y JSP son comunes para solucionar
estas aplicaciones, y componentes transaccionales fueron implantados.
Las metodologías de objetos se unificaron, acabando en un solo estandar, UML; y los
desarrolladores se preocupan por seguir patrones de diseño o "recetas" para construir sistemas
reutilizables, flexibles, confiables y fáciles de usar.
Sin embargo, se llego al punto en el cual los servidores de Internet han empezado a ser
muy pesados y dificiles de mantaner y están surgiendo nuevos enfoques, donde el hardware
de los clientes tiene potencia de cómputo pequeña, pero que puede colaborar en el
procesamiento de información. El software ahora requerido, debe liberarse de esquemas
cliente/servidor y debe tolerar fallas de cualquier tipo. Es el enfoque de Peer-To-Peer y
que está llevando a nuevos enfoques de desarrollo.
Y el software está en un momento donde existen dos filosofías, una de ellas es el
construirlo pero sin dejar a la vista muchos de sus componentes, principalmente el código,
lo cual lo hace software propietario y bajo el dominio de una empresa o grupo. Y el otro
enfoque es proveer el software de una manera abierta donde inclusive el código es entregado.
Es la filosofía del código abierto. Y las metodologías que se han utilizado para desarrollarlo
han desafiado a las tradicionales, ya que implica integración de personas que no se conocen
mas que electrónicamente y tienen distintos enfoques. Pero quiza la utilización del
filosofía de código abierto es el impulso que necesita la ingeniería de software para madurar
y que debe ser estudiada formalmente.
3. Areas de cómputo donde la ingeniería de software se utiliza
Aunque la cantidad de aplicaciones que existen y disciplinas de computación harian concluir
que es aplicable a todo, es factible clasificar el desarrollo de software en las siguientes
areas:
+ Sistemas de informacion. Sistemas de bases de datos, de Internet
+ Sistemas Cliente/Servidor. El proceso se divide en dos módulos, cliente y servidor
+ Sistemas Incrustados. Son sistemas que están incluídos en otro tipo de hardware
(autos, barcos) y que no tiene una interfaz de usuario, sino que son el cerebro
del hardware
+ Tiempo real. En estos sistemas, el tiempo de respuesta es el factor de diseño
+ Sistema Peer-To-Peer. Cada sistema de información por pequeño que sea, es capaz
de colaborar en la concetración de la información de una manera distribuída
4. Principios de la ingeniería de software
Rigor y Formalidad.
Separación de problemas
Modularidad.
Abstracción
Anticipación al cambio.
Generalidad.
Incrementable
5. Las cuatro dimensiones de la Ingeniería de Software.
Producto. El software a producir
Personas. Los integrantes que desarrollan el software en todos sus componentes.
Proceso. Los pasos o metodologías que deben seguir las personas para desarrollar el
producto con calidad
Proyecto. Es la adaptación que se hace de un proceso a las circunstancias del desarrollo
del software. Involucra planificar el tiempo, recursos económicos y personas para
obtener el producto.
6. Enfoques fundamentales sobre el proceso de software
En la historia han existido varios enfoques:
+ Sin metodología. A veces el mas utilizado
+ Cascada. El software tiene requerimientos, los cuales se analizan para generar
una abstracción plasmada en un diseño que se convierte en codificación que al final
es probado y entragado una sola vez.
+ Espiral. El software no puede entregarse una sola vez, debe evolucionar en pequeños
pasos, que van creciendo en complejidad conforme avanza el tiempo, donde se experimenta
cada fase del modelo de cascada, pero con mayor elaboración
+ Iterativo e Incremental. El sistema tiene varias funcionalidades, no todas se pueden
atacar de manera inmediata, se divide el proceso de software en varias iteraciones,
donde se tiene un proceso completo en una iteración, con entregables bien definidos
y que lleva a obtener un producto con funcionalidades y deficiencias bien definidas,
las cuales son atacadas en la siguiente iteración. La diferencia entre cada iteración
arroja incrementos en las funcionalidades.
7. El proceso unificado de desarrollo de Software
Inventado por los mismos autores que UML, el proceso unificado de desarrollo de
software permite definir un conjunto de tareas, ciclo de vida, fases e iteraciones para
construir software.
La diferencia que tiene, con respecto a los procesos anteriores, es que trata de adoptar una
visión en la cual el proceso:
+) Está basado en casos de uso o requerimientos de usuario
+) Está basado en una arquitectura de software
+) El desarrollo es iterativo e incremental
El proceso supone que el software tien varios ciclos de vida. De hecho, empieza por nacer (como idea o
necesidad), tiene una serie de evoluciones y llega un momento en el cual muere, cuando ya no es utilizado.
Por cada ciclo de vida, supone que está dividido en cuatro fases:
(ver http://www.geocities.com/gusdelact/ingsoft/ProcesoUnificado.html)
Inicio (Inception) que es cuando se desarrolla una descripción del producto final a partir de
una idea y se presenta el análisis del negocio. En esta fase se contestan las siguientes preguntas:
Cuáles son las principales funciones del sistema para sus usuarios más importantes ?
Cómo podria ser la arquitectura del sistema ?
Cuál es el plan del proyecto y cuánto costará desarrollar el producto
Elaboración. Aquí se especifican en detalle la mayoría de los casos de uso del producto y se
diseña la arquitectura del sistema. La pregunta a resolver es:
Es suficiente y estable el conjunto de casos de uso, arquitectura, plan del proyecto; y están
los riesgos lo suficientemente controlados para poder iniciar un desarrollo con compromisos ??
Construcción Aquí se crea el producto; la arquitectura se crece con implantaciones y se abarcan
las funcionalidades requeridas. Aqui se contesta la pregunta: Cubre el producto las necesidades
de algunos usuarios de manera suficiente como para realizar una entrega ?
Transición. El producto se libera para pruebas con usuarios, para que lo asimilen, se corrigan
problemas y se incorporen mejoras; detectando correciones que impactan al avance del siguiente ciclo.
Por cada fase, existen flujos de trabajo fundamentales que se dividen en:
Requisitos
Análisis
Diseño
Implantación
Prueba
Dependiendo de la fase, la cantidad de esfuerzo que se aplica a cada flujo varía. Es común que
en la fase de inicio, el punto importante sean los requisitos; en la fase de elaboración el
análisis y diseño es mas elaborado, en la fase de construcción la implantación es el punto mas
fuerte y en la de transición, las pruebas. Pero este modelo, a diferencia del modelo de cascada o
espiral, considera la existencia de cada flujo de trabajo y admite trabajo en ellos (es posible que
un caso de uso se replantee en la fase transición)
Además en cada fase, es posible realizar iteraciones, donde se puede aplicar una filosofía donde se
empieza por pequeños puntos que se evolucionan hasta llegar a funciones completas, entre cada
iteración existe un incremento de funcionalidades.
8. Desarrollo iterativo e incremental.
La filosofía que lleva al proceso unificado es un desarrollo iterativo e incremental. Este consiste en:
+ Planificar un poco
+ Especificar, diseñar e implantar un poco
+ Integrar, probar y ejecutar un poco en cada iteración
Esto permite que se pueda validar en cada paso el avance del proyecto, con retroalimentación de
los usuarios y correccion de errores o problemas, o decisiones mal tomadas sobre diseño o arquitectura
o tecnología
Así que el desarrollo iterativo e incremental se puede ver como un desarrollo en pequeños pasos y
por ende en pequeños alcances.
El objetivo del desarrollo iterativo e incremental tiene las siguientes justificaciones:
+ Detectar riesgos críticos desde el principio
+ Poner en marcha una arquitectura guía
+ Establecer una manera de reaccionar ante cambios en requisitos
+ Construir el sistema a lo largo del tiempo, en lugar de hacerlo una sola vez y hasta el final
+ Para establecer un proceso de desarrollo que permita a las Personas trabajar de una manera eficaz
9. Fundamentos de administración de proyectos de Ingeniería de Software.
El proyecto es una dimensión mas de la ingeniería de software. Permite adoptar el proceso seleccionado
para la construcción del producto, al contexto de costos, tiempo, personas, organizaciones, tecnología
y otros aspectos.
Un proyecto implica administración correcta, para evitar que se desperdicien los recursos que se
tengan a la mano.
La adminstración del proyecto de ingeniería de software tiene la característica de que administra
algo que es dificil de entender o innovador, el software
La actividad de los administradores de proyectos es planear, estimar, calendarizar el proyecto y
manipular los distintos recursos para su correcta asignación.
Uno de los puntos mas importantes al administrar el proyecto, es reconocer los riesgos a los cuales
está sometido. Los riesgos pueden darse en varias dimensiones, por tecnología, por personas, por
la organización, por las herramientas, por los requerimientos o por la estimación del tiempo.
Un administrador debe planear un proyecto, donde deben existir planes para calidad, validación,
administración de la configuración, mantenimiento y desarrollo del personal.
10.Roles de las personas en la ingeniería de software.
En la ingeniería de software, el grupo puede componerse de varias personas que puede aplicar distintas
tareas.
Un rol es el conjunto de tareas que una persona tiene como responsabilidad.
Según el proceso unificado, existen los siguientes roles:
Analista del sistema
Especificador del casos de uso
Diseñador de interfaces de usuario
Arquitecto de software
Ingeniero de casos de uso
Ingeniero de componentes
Integrador de sistemas
Diseñador de pruebas
Ingeniero de pruebas de integración y de pruebas del sistema
11. Herramientas para automatización de las tareas de ingeniería de software.
La ingeniería de software puede ser automatizada. Las herramientas que ayudan a la automatización
del proceso de software son denominadas herramientas CASE (Ingeniería de Software Asistida por Computadora)
Existen varios de tipos herramientas CASE, acorde a su función:
De planeacion. Hojas de cálculo, de estimiación, redes o PERT
De Edición. Editores de texto, editores de diagramsa
De administración del cambio. Rastreo de requerimientos, sistemas de control de cambios
De Administración de la configuración. Sistemas de administración de versions,
herramientas de construcción de sistemas
De construcción de prototipos. Lenguajes de alto nivel, generadores de interfz de usuario
De ayuda a los métodos. Editores de diseño, diccionarios de datos, generadores de código
De procesamiento de lenguajes. Compiladores, interpretes
De análisis de progamas. Referencias Cruzadas, Analizadores estáticos y dinámicos
Para Pruebas. Generadores de datos de prueba, comparadores de archivos
Para Depuración. Sistemas de depuración interactiva
De Documentación. Para generar documentos sobre el código
Es importante notar que las herramientas CASE NO SON LA PANACEA de la ingeniería de software, solo auxilian
y hacen eficientes algunas tareas que pueden ser repetitivas.
12. UML como herramienta de comunicación, documentación y automatización.
El lenguaje unificado de modelado (Unified Modeling Language, UML) es un lenguaje estándar
para escribir diagramas de software, que puede utilizarse para visualizar, especificar,
construir y documentar los diferentes componentes de un sistema.
UML proporciona un lenguaje gráfico que permite combinar sus distintos símbolos para
construir o documentar una especificación de software.
Se basó en los modelos de de análisis y diseño orientado a objetos de OMT (Object Modeling
Technique de Rumbaugh), OOSE (Object Oriented Software Engineering de Jacobson) y el
método de Booch. Cada uno de dichos modelos tenía una ventaja. Por esta razón se formó
un estándar que concentrara las tres maneras de modelar, que se conoce como UML. La
especificación está bajo el control del consorcio OMG (Object Management Group) y
la empresa que se formó para proporcionar herramientas, consultoría, documentación
sobre el uso de UML.
UML se puede utilizar para modelar cualquier tipo de sistema de información.
En http://www.geocities.com/gusdelact/ingsoft/UMLIntro.html se explica brevemente UML
junto con un repaso de la teoría de objetos.
12. El proceso unificado de software. Artefactos, trabajadores y flujos de trabajo.
Para el Procesóo Unificado, un artefacto es un termino general para cualquier tipo de
descripción o información creada, producidad, cambiada o utilizada en el flujo del
proceso de desarrollo de software.
Un artefacto es utilizado por un trabajador. Un trabajador representa un puesto o rol
que puede ser asignado a una persona o grupo y especifica las responsabilidades y habilidades
requeridas para manipular un artefacto.
Cada trabajador es responsable de un conjunto de artefactos.
Un flujo de trabajo es la manera como colaboran los trabajadores y las actividades que llevan
para manipular a los artefactos.
Durante cada fase del Proceso Unificado se describen artefactos, trabajadores y flujos de
trabajo.
En el diagrama UML http://www.geocities.com/gusdelact/ingsoft/puds.png se puede encontar
una breve explicacion de cada fase que compone al proceso unificado de desarrollo de software.
(
geocities.com/gusdelact)