Antecedentes de UML e Historia Evolucin del Software y su Ingeniera

Historia de UML
El lenguaje UML comenz a gestarse en octubre de 1994, cuando Rumbaugh se uni a la
compaa Rational fundada por Booch (dos reputados investigadores en el rea de metodologa
del software).
El objetivo de ambos era unificar dos mtodos que haban desarrollado: el mtodo Booch y el
OMT (Object Modelling Tool ). El primer borrador apareci en octubre de 1995. En esa misma
poca otro reputado investigador, Jacobson, se uni a Rational y se incluyeron ideas suyas. Estas
tres personas son conocidas como los tres amigos. Adems, este lenguaje se abri a la
colaboracin de otras empresas para que aportaran sus ideas. Todas estas colaboraciones
condujeron a la definicin de la primera versin de UML.
Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar
artefactos de un sistema de software. Se usa para entender, disear, configurar, mantener y
controlar la informacin sobre los sistemas a construir.
UML capta la informacin sobre la estructura esttica y el comportamiento dinmico de un
sistema. Un sistema se modela como una coleccin de objetos discretos que interactan para
realizar un trabajo que finalmente beneficia a un usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre tcnicas de modelado e
incorporar las mejores prcticas actuales en un acercamiento estndar.
UML no es un lenguaje de programacin. Las herramientas pueden ofrecer generadores de
cdigo de UML para una gran variedad de lenguaje de programacin, as como construir modelos
por ingeniera inversa a partir de programas existentes.
La notacin UML se deriva y unifica las tres metodologas de anlisis y diseos ms extendidas.
Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus relaciones.
Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object - Modelling
Technique).
Aproximacin de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la
metodologa de casos de uso (use case).
El desarrollo de UML comenz a finales de 1994 cuando Grady Booch y Jim Rumbaugh de
Rational Software Corporation empezaron a unificar sus mtodos. A finales de 1995, Ivar Jacob
son y su compaa Objectory se incorporaron a Rational en su unificacin, aportando el mtodo
OOSE.

De las tres metodologas de partida, las de Bco. y Rumbaugh pueden ser descritas como
centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos
que componen el sistema, su relacin y colaboracin.
Por otro lado, la metodologa de Jacobson es ms centrada a usuario, ya que todo en su mtodo
se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estndar desde
el OMG, que es tambin el origen de CORBA, el estndar lder en la industria para la
programacin de objetos distribuidos.

En 1997 UML 1.1 fue aprobada por la OMG convirtindose en la notacin estndar de facto para
el anlisis y el diseo orientado a objetos.
UML es el primer mtodo en publicar un meta-modelo en su propia notacin, incluyendo la
notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata pues de un
meta-modelo auto-referencial (cualquier lenguaje de modelado de propsito general debera ser

capaz de modelarse a s mismo).

Objetivos
Durante el desarrollo del UML sus autores tuvieron en cuenta:
Proporcionar una notacin y semnticas suficientes para poder alcanzar una gran cantidad de
aspectos del modelado contemporneo de una forma directa y econmica.
Proporcionar las semnticas suficientes para alcanzar aspectos del modelado que son de esperar
en un futuro, como por ejemplo aspectos relacionados con la tecnologa de componentes, el
cmputo distribuido, etc.
Proporcionar mecanismos de extensin de forma que proyectos concretos puedan extender el
meta-modelo a un coste bajo.
Proporcionar mecanismos de extensin de forma que aproximaciones de modelado futuras
podran desarrollarse encima del UML.
Permitir el intercambio del modelos entre una gran variedad de herramientas.
Proporcionar semnticas suficientes para especificar las interfaces a bibliotecas para la
comparicin y el almacenamiento de componentes del modelo.
Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de
sistemas que se necesita construir.
UML es un lenguaje de modelado de propsito general que pueden usar todos los modeladores.
UML no pretende ser un mtodo de desarrollo completo.
Debe ser un lenguaje universal, como cualquier lenguaje de propsito general.
Imponer un estndar mundial.
Mediante el fomento del uso de UML OMG pretende alcanzar los siguientes objetivos:
Proporcionar a los usuarios un lenguaje de modelado visual expresivo y utilizable para el
desarrollo e intercambio de modelos significativos.
Proporcionar mecanismos de extensin y especializacin.
Ser independiente del proceso de desarrollo y de los lenguajes de programacin.
Proporcionar una base formal para entender el lenguaje de modelado.
Fomentar el crecimiento del mercado de las herramientas OO.
Soportar conceptos de desarrollo de alto nivel como pueden ser colaboraciones, frameworks,
patterns, y componentes.
Integrar las mejores prcticas utilizadas hasta el momento.
El UML debe entenderse como un estndar para modelado y no como un estndar de proceso
software. Aunque UML debe ser aplicado en el contexto de un proceso, la experiencia ha
mostrado que organizaciones diferentes y dominios del problema diferentes requieren diferentes
procesos. Por ello se han centrado los esfuerzos en un meta-modelo comn (que unifica las
semnticas) y una notacin comn que proporcione una representacin de esas semnticas. De
todas formas, los autores de UML fomentan un proceso guiado por casos de uso, centrado en la
arquitectura, iterativo e incremental. Bajo estas lneas genricas proponen el proceso software
definido en una de las extensiones del UML (Objectory Extension for Software Enginnering) , pero
en general el proceso software es fuertemente dependiente de la organizacin y del dominio de
aplicacin

Los conceptos y modelos de UML pueden agruparse en las siguientes reas conceptuales:
Estructura esttica:

Cualquier modelo preciso debe primero definir su universo, esto es, los conceptos clave de la
aplicacin, sus propiedades internas, y las relaciones entre cada una de ellas. Este conjunto de
construcciones es la estructura esttica. Los conceptos de la aplicacin son modelados como
clases, cada una de las cuales describe un conjunto de objetos que almacenan informacin y se
comunican para implementar un comportamiento. La informacin que almacena es modelada
como atributos; La estructura esttica se expresa con diagramas de clases y puede usarse para
generar la mayora de las declaraciones de estructuras de datos en un programa.
Comportamiento dinmico:
Hay dos formas de modelar el comportamiento, una es la historia de la vida de un objeto y la
forma como interacta con el resto del mundo y la otra es por los patrones de comunicacin de un
conjunto de objetos conectados, es decir la forma en que interactan entre s. La visin de un
objeto aislado es una maquina de estados, muestra la forma en que el objeto responde a los
eventos en funcin de su estado actual. La visin de la interaccin de los objetos se representa
con los enlaces entre objetos junto con el flujo de mensajes y los enlaces entre ellos. Este punto
de vista unifica la estructura de los datos, el control de flujo y el flujo de datos.
Construcciones de implementacin:
Los modelos UML tienen significado para el anlisis lgico y para la implementacin fsica. Un
componente es una parte fsica reemplazable de un sistema y es capaz de responder a las
peticiones descritas por un conjunto de interfaces. Un nodo es un recurso computacional que
define una localizacin durante la ejecucin de un sistema. Puede contener componentes y
objetos.
Mecanismos de extensin:
UML tiene una limitada capacidad de extensin pero que es suficiente para la mayora de las
extensiones que requiere el da a da sin la necesidad de un cambio en el lenguaje bsico. Un
estereotipo es una nueva clase de elemento de modelado con la misma estructura que un
elemento existente pero con restricciones adicionales.
Organizacin del modelo:
La informacin del modelo debe ser dividida en piezas coherentes, para que los equipos puedan
trabajar en las diferentes partes de forma concurrente. El conocimiento humano requiere que se
organice el contenido del modelo en paquetes de tamao modesto. Los paquetes son unidades
organizativas, jerrquicas y de propsito general de los modelos de UML. Pueden usarse para
almacenamiento, control de acceso, gestin de la configuracin y construccin de bibliotecas que
contengan fragmentos de cdigo reutilizable.
Elementos de anotacin
Los elementos de anotacin son las partes explicativas de los modelos UML. Son comentarios
que se pueden aplicar para describir, clasificar y hacer observaciones sobre cualquier elemento de
un modelo.
El tipo principal de anotacin es la nota que simplemente es un smbolo para mostrar restricciones
y comentarios junto a un elemento o un conjunto de elementos
Relaciones
Existen cuatro tipos de relaciones entre los elementos de un modelo UML. Dependencia,
asociacin, generalizacin y realizacin, estas se describen a continuacin
Dependencia
Es una relacin semntica entre dos elementos en la cual un cambio a un elemento (el elemento
independiente) puede afectar a la semntica del otro elemento (elemento dependiente). Se
representa como una lnea discontinua, posiblemente dirigida, que a veces incluye una etiqueta.
Asociacin

Es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones entre
objetos. La agregacin es un tipo especial de asociacin y representa una relacin estructural
entre un todo y sus partes. La asociacin se representa con una lnea continua, posiblemente
dirigida, que a veces incluye una etiqueta. A menudo se incluyen otros adornos para indicar la
multiplicidad y roles de los objetos involucrados
Generalizacin
Es una relacin de especializacin / generalizacin en la cual los objetos del elemento
especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta
forma, el hijo comparte la estructura y el comportamiento del padre. Grficamente, la
generalizacin se representa con una lnea con punta de flecha vaca.
Realizacin
Es una relacin semntica entre clasificadores, donde un clasificador especifica un contrato que
otro clasificador garantiza que cumplir. Se pueden encontrar relaciones de realizacin en dos
sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de uso y las
colaboraciones que los realizan. La realizacin se representa como una mezcla entre la
generalizacin y la dependencia, esto es, una lnea discontinua con una punta de flecha vaca .
Diagramas
Diagramas
Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma que un
diagrama es una proyeccin del mismo. UML proporciona un amplio conjunto de diagramas que
normalmente se usan en pequeos subconjuntos para poder representar las cinco vistas
principales de la arquitectura de un sistema.
Diagramas de Clases
Muestran un conjunto de clases, interfaces y colaboraciones, as como sus relaciones. Estos
diagramas son los ms comunes en el modelado de sistemas orientados a objetos y cubren la
vista de diseo esttica o la vista de procesos esttica (s incluyen clases activas).
Diagramas de Objetos
Muestran un conjunto de objetos y sus relaciones, son como fotos instantneas de los diagramas
de clases y cubren la vista de diseo esttica o la vista de procesos esttica desde la perspectiva
de casos reales o prototpicos.
Diagramas de Casos de Usos
Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones.
Cubren la vista esttica de los casos de uso y son especialmente importantes para el modelado y
organizacin del comportamiento.
Diagramas de Secuencia y de Colaboracin
Tanto los diagramas de secuencia como los diagramas de colaboracin son un tipo de diagramas
de interaccin. Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que
se pueden enviar unos objetos a otros. Cubren la vista dinmica del sistema. Los diagramas de
secuencia enfatizan el ordenamiento temporal de los mensajes mientras que los diagramas de
colaboracin muestran la organizacin estructural de los objetos que envan y reciben mensajes.
Los diagramas de secuencia se pueden convertir en diagramas de colaboracin sin perdida de
informacin, lo mismo ocurren en sentido opuesto.
Diagramas de Estados
Muestran una maquina de estados compuesta por estados, transiciones, eventos y actividades.
Estos diagramas cubren la vista dinmica de un sistema y son muy importantes a la hora de
modelar el comportamiento de una interfaz, clase o colaboracin.
Diagramas de Actividades

Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades
dentro de un sistema. Los diagramas de actividades cubren la parte dinmica de un sistema y se
utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre objetos.
Diagramas de Componentes
Muestra la organizacin y las dependencias entre un conjunto de componentes. Cubren la vista de
la implementacin esttica y se relacionan con los diagramas de clases ya que en un componente
suele tener una o ms clases, interfaces o colaboraciones
Diagramas de Despliegue
Representan la configuracin de los nodos de procesamiento en tiempo de ejecucin y los
componentes que residen en ellos. Muestran la vista de despliegue esttica de una arquitectura y
se relacionan con los componentes ya que, por lo comn, los nodos contienen uno o ms
componentes.

Es el equipamiento lgico o soporte lgico de una computadora digital;

comprende el conjunto de los componentes necesarios que hacen posible la
realizacin de tareas especficas, en contraposicin a los componentes fsicos
(hardware). Desde los comienzos del software hasta hoy en da se puede
decir que se divide en cuatro eras:
3. 1950 1965 Se trabajaba con la idea de Codificar y Corregir. No
exista un planteamiento previo. No exista documentacin de ningn tipo.
Existencia de pocos mtodos formales y pocos creyentes en ellos. Desarrollo
a base de prueba y error.
4. 1965 1972 Se busca simplificar cdigo. Aparicin de Multiprogramacin
y Sistemas Multiusuarios. Sistemas de Tiempo Real apoyan la toma de
decisiones. Aparicin de Software como producto. (Casas de Software).
INICIO DE LA CRISIS DEL SOFTWARE. Se buscan procedimientos para el
desarrollo del Software.
5. 1972 1985 Nuevo Concepto: Sistemas Distribuidos. Complejidad en los
Sistemas de Informacin. Aparecen: Redes de rea local y global, y
Comunicadores Digitales. Amplio Uso de Microprocesadores.
6. 1985 - 1995 aprox. Impacto Colectivo de Software. Aparecen: Redes de
Informacin, Tecnologas Orientadas a Objetos. Aparecen: Redes Neuronales,
Sistemas Expertos y SW de Inteligencia Artificial. La informacin como valor
preponderante dentro de las Organizaciones.
7. 2000 hasta hoy en da Utiliza algunos requisitos de las eras anteriores solo
que aumenta la omnipresencia de la web, la reutilizacin de informacin y
componentes de software
8. Codificar: Transformar mediante las reglas de un cdigo la formulacin de
un mensaje. Hardware: Componente fsico de la computadora. Por ejemplo:
el monitor, la impresora o el disco rgido. El hardware por s mismo no hace que
una mquina funcione. Es necesario, adems, instalar un Software adecuado.
Microprocesador: Es la parte ms importante del ordenador, se encarga de

realizar todos los clculos y controla su funcionamiento. La velocidad de este

"cerebro" determina la del ordenador
9. Multiprogramacin: Se denomina multiprogramacin a la tcnica que
permite que dos o ms procesos ocupen la misma unidad de memoria principal
y que sean ejecutados al "mismo tiempo. Multiusuario: Capacidad de
algunos sistemas para ofrecer sus recursos a diversos usuarios conectados a
travs de terminales. Preponderante:Que prepondera, prevalece o tiene
cualquier tipo de superioridad respecto a aquello con lo que es comparado

Ingeniera del Software

Publicado en 28 diciembre, 2010 por patponto

INTRODUCCIN
La ingeniera del software, segn la definicin de la IEEE en 1993, es la aplicacin
de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y
mantenimiento del software. La ingeniera del software ofrece mtodos o tcnicas
para desarrollar y mantener software de calidad que resuelven problemas de todo
tipo, y trata reas muy diversas de la informtica y de las ciencias
computacionales.

ORGEN
El concepto de ingeniera del software surgi en 1968, tras una conferencia en
Garmisch (Alemania) que tuvo como objetivo resolver los problemas de la crisis del
software. El trmino crisis del software se us desde finales de 1960 hasta
mediados de 1980 para describir los frecuentes problemas que aparecan durante
el proceso de desarrollo de nuevo software. Tras la aparicin de nuevo hardware
basado en circuitos integrados, comenzaron a desarrollarse sistemas y aplicaciones
mucho ms complejos que hasta entonces no era posible construir puesto que el
hardware disponible no lo permita. Estos nuevos proyectos de desarrollo de
software, en la mayora de ocasiones, no se terminaban a tiempo, lo cual tambin
provocaba que el presupuesto final del software excediera de aquel que se haba
pactado. Algunos de estos proyectos eran tan crticos (sistemas de control de
aeropuertos, equipos para medicina, etc) que sus implicaciones iban ms all de
las prdidas millonarias que causaban. Adems, en muchos casos el software no
daba respuesta a las verdaderas necesidades del cliente o haba que ser un

usuario experto para poder utilizarlo, todo ello sumado a que el mantenimiento de
los productos era complejo y muy costoso.

El software no se produca como el hardware, que tena un proceso de fabricacin

definido y dividido en fases. El resultado eran productos de psima calidad en los
que se haban invertido mucho tiempo y dinero pero que o bien no llegaban a
terminarse o bien a la larga no daban el resultado que se esperaba. Se detect que
los mtodos de desarrollo de software informales que hasta entonces haban
bastado para proyectos pequeos no eran suficientes para los nuevos y grandes
proyectos, y que se necesitaban profesionales especializados en esta nueva
disciplina que fueran capaces de lidiar con la creciente complejidad de los nuevos
sistemas.
Una de las primeras y ms conocidas referencias a los conceptos crisis el software
e ingeniera del software fue hecha por Edsger Dijkstra, durante la presentacin de
1972 titulada The Humble Programmer en la Association for Computing
Machinery, cuando se le hizo entrega de un Premio Turing.

NO SILVER BULLET
Durante dcadas, resolver la crisis del software desencaden en que compaas e
investigadores produjeran ms y ms herramientas software. Cada nueva
tecnologa o prctica que apareci entre 1970 y 1990 fue tratada como una bala
de plata (en ingls, silver bullet) que solucionara la crisis del software.

En 1986, Fred Brooks public el artculo No Silver Bullet, argumentando que

ninguna tecnologa o prctica por s misma podra mejorar en un diez por ciento la
productividad en los siguientes diez aos. El debate sobre las balas de
plata continu durante la siguiente dcada, dando lugar a numerosas
interpretaciones sobre el artculo de Brooks.
Los defensores de lenguajes como Ada, o de los procesos software continuaron
apostando por que su tecnologa sera la que solucionara la crisis. Sin embargo,
hubo gente que interpret el hecho de que no se encontrara una solucin nica y
efectiva al cien por cien como un fracaso de la ingeniera del software.
Si bien es cierto que la bsqueda de una nica solucin no funcion, tambin haba
que ser consciente de que tampoco existan balas de plata en ninguna otra
profesin. As, con el transcurso de los aos, casi todo el mundo acept que no se
encontrara ninguna bala de plata, pero se tom esto como una prueba de que la
ingeniera del software finalmente haba madurado y que los proyectos deban
tener xito gracias al trabajo duro y al esfuerzo. El campo de la ingeniera del
software es demasiado complejo y diverso para que una nica solucin resuelva
todos los problemas, pero el conjunto de todas las prcticas que surgieron y de las
que surgen hoy en da son las que, bien aplicadas, permiten que la ingeniera del
software desarrolle productos de calidad.

EVOLUCIN DE LA INGENIERA DEL

SOFTWARE
Con el transcurso de los aos se han desarrollado recursos que conforman la
ingeniera del software, es decir, herramientas y tcnicas de especificacin, diseo
e implementacin del software: la programacin estructurada, la programacin
orientada a objetos, las herramientas CASE, la documentacin, los estndares,
CORBA, los servicios web, el lenguaje UML, etc.
En combinacin con las herramientas, tambin se han hecho esfuerzos por
incorporar los mtodos formales al desarrollo de software, argumentando que si se
probaba formalmente que los productos software hacan lo que se les requera, la
industria del software sera tan predecible como lo son otras ramas de la
ingeniera.

La utilizacin de determinados recursos depende de la magnitud del proyecto, de

la empresa a cargo, la experiencia de los desarrolladores, el presupuesto con el
que se cuenta, etc.
La ingeniera del software comprende:

Proceso de desarrollo de software (especificacin, implementacin y

diseo, etc).
Metodologas para el desarrollo de software (RUP, patrones,

framework).
Herramientas de desarrollo de software.

PROCESO SOFTWARE
El proceso de ingeniera de software se define como un conjunto de etapas
parcialmente ordenadas con la intencin de lograr un objetivo, en este caso, la
obtencin de un producto de software de calidad. El proceso de desarrollo de
software es aquel en que las necesidades del usuario son traducidas en
requerimientos de software, estos requerimientos transformados en diseo y el
diseo implementado en cdigo, el cdigo es probado, documentado y certificado
para su uso operativo. Concretamente define quin est haciendo qu, cundo
hacerlo y cmo alcanzar un cierto objetivo [Jacobson 1998].
El proceso de desarrollo de software requiere por un lado un conjunto de
conceptos, una metodologa y un lenguaje propio. A este proceso tambin se le
llama el ciclo de vida del software, que comprende las etapas por las que pasa un
proyecto software desde que es concebido, hasta que est listo para usarse.

Hay cuatro actividades fundamentales comunes a todo proceso software:

Especificacin: usuarios e ingenieros definen el software a producir y

las restricciones en su funcionalidad.

Desarrollo: fase en la cual el software se disea y se programa.
Validacin: el software debe ser probado para asegurar que cumple con

las necesidades del cliente.

Evolucin: el software debe poder ser modificado para adaptarse a
cambios en el mercado y en las necesidades de los usuarios.

Cada producto software necesita un proceso diferente. Por tanto, estas etapas
genricas deben organizarse de diferente manera y en diferentes niveles segn el
tipo de software para el que se aplique el proceso. Un uso inapropiado del proceso
software puede reducir la calidad o la usabilidad del producto a ser desarrollado, e
incluso incrementar los costes de desarrollo.
Los enfoques ms generales son los siguientes:

Modelo en cascada: ordena rigurosamente las etapas del

ciclo de vida del software, de tal forma que el inicio de cada
etapa debe esperar a la finalizacin de la inmediatamente
anterior. La primera descripcin formal la realiz en 1970
Winston W. Royce, en uno de sus artculos.

Prototipado: pertenece a los modelos de desarrollo evolutivo.

El prototipo debe ser construido en poco tiempo, usando los
programas adecuados y no se deben utilizar muchos recursos,
pues a partir de que ste sea aprobado se puede iniciar el
verdadero desarrollo del software.

Incremental e iterativo: Divide la funcionalidad del sistema

en partes. En cada incremento, una parte de la funcionalidad
es desarrollada, desde el anlisis hasta las pruebas.

Espiral: Combinacin de procesos en cascada y prototipado.

Fue definido por Barry Boehm en 1986 en el artculo A Spiral
Model of Software Development and Enhancement.

RAD (Rapid Application Development): emplea tcnicas iterativas y

de prototipado. Lo introdujo James Martin en 1991.

RUP (Rationa Unified Process): El Rational Unified Process en ingls
es un proceso de desarrollo de software iterativo y junto con el Lenguaje
Unificado de Modelado (UML), constituye la metodologa estndar ms
utilizada para el anlisis, implementacin y documentacin de sistemas
orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un
conjunto de metodologas adaptables al contexto y necesidades de cada
organizacin.

En 1987, Ivar Jacobson fund la compaa Objectory AB, que desarroll

Objetory, un mtodo de desarrollo orientado a objetos, extensin de lo
que se conoca como aproximacin Ericsson. En 1995, Rational Software
compr Objectory AB, y en los siguientes aos desarrollaron y lanzaron
el estndar UML (Unified Modeling Language), as como el Rational
Unified Process (RUP), que aunaba los esfuerzos y la experiencia de
todas las compaas adquiridas por Rational Software. En diciembre de
2002, IBM adquiri Rational Software.

MTODOS
Un mtodo de ingeniera de software es un enfoque estructurado para desarrollar
software cuyo objetivo es facilitar la produccin de productos software de alta
calidad a un coste razonable. Indican cmo construir tcnicamente el software. Los
mtodos abarcan un amplio espectro de tareas que incluyen: planificacin y
estimacin de proyectos, anlisis de los requerimientos del sistema y del software,
diseo de procedimientos algortmicos, codificacin, prueba y mantenimiento.
Los mtodos de la ingeniera de software introducen frecuentemente una notacin
especial orientada al lenguaje o grfica y a un conjunto de criterios para la calidad
del software.
A lo largo de los aos se han ido desarrollando una gran cantidad de metodologas
para desarrollar software, a menudo vinculadas a algn tipo de organizacin, que
adems desarrolla, apoya el uso y promueve la metodologa. La metodologa es a
menudo documentada en algn tipo de documentacin formal.
Algunas de las metodologas ms conocidas se explican a continuacin.

Programacin estructurada
Tcnica en la cual la estructura de un programa tan solo emplea tres estructuras
lgicas de control: secuencia, seleccin e iteracin. La programacin estructurada
se basa en el teorema del programa estructurado demostrado por Bhm-Jacopini,
el cual establece que cualquier programa con una entrada y una salida
exclusivamente es equivalente a un programa que contiene solamente las
estructuras lgicas mencionadas anteriormente.

Esta nueva forma de programar que dio lugar a programas fiables y eficientes, que
adems estaban escritos de manera que facilitaba su comprensin posterior.

Programacin orientada a objetos o POO

Los conceptos de la programacin orientada a objetos tienen origen en Simula 67,
un lenguaje diseado en 1967 para hacer simulaciones de eventos discretos,
creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cmputo Noruego en
Oslo. Simula introdujo la nocin de clases e instancias como parte de un paradigma
de programacin explcito. Las ideas de Simula 67 influenciaron muchos lenguajes
posteriores, incluyendo Smalltalk, CLOS, Object Pascal, C++
Smalltalk fue desarrollado en Xerox PARC por Alan Kay, entre otros, en la dcada de
los 70. Smalltalk introdujo el trmino POO para representar el uso de objetos y
mensajes como la base de la computacin. Smalltalk fue diseado para ser un
sistema completamente dinmico en el cual las clases se podran crear y modificar
en tiempo de ejecucin en lugar de estticamente.
La programacin orientada a objetos fue el estilo de programacin dominante a
principio y mediados de los aos noventa, en gran parte debido a la influencia de
lenguajes como C++. Su predominio fue consolidado gracias al auge de las
interfaces grficas de usuario, para las cuales la programacin orientada a objetos
est particularmente bien adaptada. En este caso, se habla tambin de
programacin dirigida por eventos.
Las caractersticas de orientacin a objetos han sido agregadas a muchos
lenguajes a lo largo de los aos, incluyendo Ada, BASIC, Fortran, Pascal, entre
otros. La adicin de estas caractersticas a los lenguajes que no fueron diseados
inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la
capacidad de mantenimiento del cdigo.
As como la programacin procedural introdujo tcnicas de mejora como la
programacin estructurada, los mtodos modernos de diseo de software
orientados a objetos incluyen mejoras como el uso de patrones de diseo o
lenguajes de modelado como UML.

Extreme Programming

Enfoque formulado por Kent Beck en 1999, que se diferencia de las metodologas
tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la
previsibilidad. Sus defensores consideran que ser capaz de adaptarse a los
cambios de requisitos en cualquier punto de la vida del proyecto es una
aproximacin mejor y ms realista que definir todos los requisitos al comienzo e
invertir esfuerzos despus en controlar los cambios.

HERRAMIENTAS
Suministran un soporte automtico o semiautomtico para los mtodos. Cuando se
integran las herramientas de forma que la informacin creada por una herramienta
pueda ser usada por otra, se establece un sistema para el soporte del desarrollo
del software llamado ingeniera de software asistido por computadora (Computer
Aided Software Engineering o CASE).
Ya en los aos 70 un proyecto llamado ISDOS (Information System Design and
Optimization System) dise un lenguaje, y por lo tanto un producto, que analizaba
la relacin existente entre los requisitos de un problema y las necesidades que
stos generaban, el lenguaje en cuestin se denominaba PSL (Problem Statement
Language) y la aplicacin que ayudaba a buscar las necesidades de los
diseadores PSA (Problem Statement Analyzer). PSL se empleaba para expresar
requisitos de un sistema mediante un lenguaje formal. El lenguaje se expresaba
empleando objetos y relaciones entre ellos. Una vez compilado y sin errores, el
fichero generado era recibido por la aplicacin PSA, que generaba una base de
datos con la informacin obtenida y permita manipular el contenido y generar
informes, entre otras cosas.
Aunque sos son los inicios de las herramientas informticas que ayudan a crear
nuevos proyectos informticos, la primera herramienta CASE fue Excelerator que
sali a la luz en el ao 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la
poca en la que IBM haba conseguido una alianza con la empresa de software
AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con
herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a
poco los mainframes han ido siendo menos utilizados y actualmente el mercado de
las Big CASE ha muerto completamente abriendo el mercado de diversas
herramientas ms especficas para cada fase del ciclo de vida del software. Por

ejemplo, algunas herramientas CASE son MagicDraw (diseo), ArchE (arquitectura)

o MetaEdit (desarrollo).
Aunque no es fcil y no existe una forma nica de clasificarlas, las herramientas
CASE se pueden clasificar teniendo en cuenta los siguientes parmetros:
1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.
La siguiente clasificacin es la ms habitual basada en las fases del ciclo de
desarrollo que cubren:

Upper CASE (U-CASE), herramientas que ayudan en las fases de

planificacin, anlisis de requisitos y estrategia del desarrollo, usando,

entre otros diagramas UML.
Middle CASE (M-CASE), herramientas para automatizar tareas en el

anlisis y diseo de la aplicacin.

Lower CASE (L-CASE), herramientas que semi-automatizan la generacin
de cdigo, crean programas de deteccin de errores, soportan la
depuracin de programas y pruebas. Adems automatizan la
documentacin completa de la aplicacin.

TENDENCIA ACTUAL
Las direcciones en las que evoluciona la ingeniera del software hoy en da pueden
agruparse de la siguiente manera:

Metodologas giles: mtodos de desarrollo de software basados en

procesos iterativos e incrementales, donde los requisitos y soluciones
evolucionan durante la colaboracin.
Metodologas como Scrum (1995), Extreme Programming (1999) o DSDM
(1995) fueron evolucionando hasta que en Febrero del 2001 se public
Manifesto for Agile Software Development para definir la aproximacin

ahora conocida como metodologas giles.

Experimentacin: es una rama de la ingeniera del software interesada
en realizar experimentos sobre software, recolectar datos y deducir leyes
y teoras de los mismos.

Desarrollo dirigido por modelos: primero se desarrollan modelos

textuales grficos del software a construir, y posteriormente se

construye el software.
Lneas de productos software, en lugar de productos individuales.

A lo largo de los aos han surgido numerosas organizaciones y estndares que

apoyan la ingeniera del software y que dan ms fuerza y potencia a este mbito.
Por ejemplo, el Software Engineering Institute (http://www.sei.cmu.edu/index.cfm),
la IEEE Computer Society (http://www.computer.org/portal/web/guest/home), o
documentos como el Software Engineering Body of Knowledge (SWEBOK).
En 2006, Money Magazine and Salary.com determine que la ingeniera del software
era el mejor trabajo en Amrica en trminos de crecimiento, remuneracin, nivel
de estrs, flexibilidad horaria, creatividad, entorno de trabajo y capacidad de
ascenso.
A su vez, la conferencia Future of Software Engineering (FOSE) del 2000
document el estado de la ingeniera del software y redact una lista con varios
problemas para ser solucionados durante la prxima dcada.
Hoy en da, contamos con carreras universitarias, msteres, y una gran oferta
formativa para profesionales del software. A pesar de ser una disciplina joven y
que sigue evolucionando, los resultados de todos los esfuerzos y mtodos
desarrollados con el paso de los aos, as como de la experiencia, permiten
desarrollar productos de calidad al nivel de cualquier otra ingeniera.

REFERENCIAS
http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html
http://aprendeenlinea.udea.edu.co/lms/moodle/mod/resource/view.php?id=14273
http://www.experiencefestival.com/a/History_of_software_engineering__1985_to_present_No_silver_bullet/id/5134751
http://es.wikipedia.org/wiki/Herramienta_CASE
http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software
http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos
http://es.wikipedia.org/wiki/Extreme_Programming
http://es.wikipedia.org/wiki/Rational_Unified_Process#Un_poco_de_historia
http://media.wiley.com/product_data/excerpt/94/08186760/0818676094.pdf
http://en.wikipedia.org/wiki/History_of_software_engineering
http://www.dagstuhl.de/Reports/96/9635.pdf