ING DE SOFTWARE

EVOLUCION HISTORICA

1. De 1955 a 1965: Los orígenes

El término ingeniería del software apareció por primera vez en la década de 1950 y
principios de los años 1960. Los programadores siempre habían sabido sobre ingenieros
civiles, eléctricos y de computadores y debatían qué podría significar la ingeniería para el
software.

El Comité de ciencia de la OTAN patrocinó dos conferencias3 sobre ingeniería del software
en 1968 (Garmisch, Alemania — ver informe|de la Conferencia) y en 1969, que dio al campo
su impulso inicial. Muchos creen que estas conferencias marcaron el inicio oficial de la
profesión de la ingeniería de software.

2. De 1960 a 1980: La crisis del software

La ingeniería de software fue estimulada por la llamada crisis del software de la década de
1960, 1970 y 1980, que identifica muchos de los problemas de desarrollo de software.
Muchos proyectos de software sobrepasaron el presupuesto y el tiempo estimados.
Algunos proyectos causaron daños a la propiedad otros proyectos causaron pérdidas de
vidas.4 La crisis del software originalmente fue definida en términos de productividad, pero
evolucionó para enfatizar la calidad. Algunos utilizan el término de crisis del software para
referirse a su incapacidad de contratar programadores suficientemente calificados.

Costo y desbordamiento de presupuesto: el sistema operativo OS/360 fue un ejemplo

clásico. Este proyecto que duró una década desde los años 1960 finalmente produjo uno de
los más complejos sistemas de software de ese tiempo. El OS/360 fue uno de los primeros
de grandes proyectos de software (1000 programadores).[cita requerida] En el libro The
Mythical Man-Month, Fred Brooks afirma que cometió un error multimillonario por no
desarrollar una coherente arquitectura de software antes de iniciar el desarrollo.
Daños a la propiedad: Defectos de software pueden causar daños a la propiedad. Escasa
seguridad de software permite a hackers robar identidades, costando tiempo, dinero y
reputaciones.
Vida y muerte: Defectos de software pueden matar. Algunos sistemas embebidos en
máquinas de radioterapia fallaron de una manera tan catastrófica que administraron dosis
letales de radiación a pacientes. La más famosa de estas fallas es el incidente de Therac 25.

3. De 1985 a 1989: No hay balas de plata

Durante décadas, solucionar la crisis del software fue de suprema importancia para
investigadores y empresas productoras de herramientas de software. El costo de propiedad
y mantenimiento del software en la década de 1980 fue dos veces más caro que el propio
desarrollo del software. Durante la década de 1990, el costo de propiedad y mantenimiento
aumentó en un 30% con respecto a la década anterior. En 1995, las estadísticas mostraron
que la mitad de los proyectos de desarrollo encuestados estaban operacionales, pero no
eran considerado exitoso. El proyecto de software medio sobrepasa su estimación en
 tiempo en el 50%. Las tres cuartas partes de todos los grandes productos de software son
entregados al cliente con tales fallas que no son usados en absoluto, o no cumplen con los
requerimientos del cliente.

4. Proyectos de software
Aparentemente, cada nueva tecnología y práctica de la década de 1970 a la de 1990 fue
pregonada como una bala de plata para resolver la crisis del software. Herramientas,
disciplina, métodos formales, proceso, y profesionalismo fueron promocionados como
balas de plata:

Herramientas: Especialmente enfatizaba que las herramientas: programación estructurada,

programación orientada a objetos, herramientas CASE, el lenguaje de programación Ada,
documentación y estándares eran promocionados como balas de plata.
Disciplina: Algunos expertos argumentaron que la crisis del software era debido a la falta
de disciplina de los programadores.
Métodos formales: Algunos creían que, si las metodologías de ingeniería formal fueran
aplicadas al desarrollo de software, entonces la producción de software sería una industria
tan predecible como otras ramas de la ingeniería. Abogaron que había que demostrar que
todos los programas eran correctos.
Proceso: Muchos abogaron el uso de procesos definidos y metodologías como el Modelo
de Capacidad y Madurez.
Profesionalismo: Esto llevó a trabajar en un código de ética, licencias y profesionalismo.
En 1986, Fred Brooks publicó su artículo No hay balas de plata, argumentando que ninguna
tecnología individual o práctica jamás haría una mejora de 10 veces en la productividad
dentro de 10 años.

5. De 1990 a 1999: Prominencia de Internet

El auge de la Internet condujo a un rápido crecimiento en la demanda de sistemas
internacionales de despliegue de información y correo electrónico en la World Wide Web.
Los programadores debían manejar ilustraciones, mapas, fotografías y otras imágenes, más
animación sencilla, a un ritmo nunca antes visto, con pocos métodos conocidos para
optimizar la visualización/almacenamiento de imágenes (como el uso de imágenes en
miniatura).

El crecimiento del uso del navegador, corriendo en el lenguaje HTML, cambió la manera en
que estaba organizada la visualización y la recuperación de la información. Las amplias
conexiones de red condujeron al crecimiento y la prevención de virus informáticos
internacionales en computadores con MS Windows, y la gran proliferación de correo basura
se convirtió en una cuestión de diseño importante en sistemas de correo electrónico,
inundando canales de comunicación y requiriendo de precalificación semiautomatizada.
Sistemas de búsqueda de palabra clave evolucionaron en buscadores web, y muchos
sistemas de software tuvieron que ser rediseñados, para la búsqueda internacional,
dependiendo de las técnicas de posicionamiento en buscadores (SEO). Fueron necesarios
sistemas de traducción de lenguaje natural humano para intentar traducir el flujo de
información en múltiples idiomas extranjeros, con muchos sistemas de software siendo
 diseñados para uso multilenguaje, basado en conceptos de diseño de traductores humanos.
Típicas bases de usuarios de computadora con frecuencia pasaron de cientos o miles de
usuarios a muchos millones de usuarios internacionales.

6. De 2000 al presente: Metodologías ligeras

Con la creciente demanda de software en muchas organizaciones pequeñas, la necesidad
de soluciones de software de bajo costo llevó al crecimiento de metodologías más simples
y rápidas que desarrollaran software funcional, de los requisitos de implementación, más
rápidos y más fáciles. El uso de prototipos rápidos evolucionó a metodologías ligeras
completas como la programación extrema (XP), que intentó simplificar muchas de las áreas
de la ingeniería de software, incluyendo la recopilación de requerimientos y las pruebas de
confiabilidad para el creciente y gran número de pequeños sistemas de software. Sistemas
de software muy grandes todavía utilizan metodologías muy documentadas, con muchos
volúmenes en el conjunto de documentación; Sin embargo, sistemas más pequeños tenían
un enfoque alternativo más simple y rápido para administrar el desarrollo y mantenimiento
de cálculos y algoritmos de software, almacenamiento y recuperación de información y
visualización.

TENDENCIAS DEL MERCADO

1. Aspectos: Los aspectos ayudan a los ingenieros de software a lidiar con los atributos de
calidad al proporcionar herramientas para añadir o quitar código repetitivo de muchas áreas
en el código fuente. Los aspectos describen cómo todos los objetos o funciones deben
comportarse en circunstancias particulares. Por ejemplo, los aspectos puede agregar
control de depuración, registro o bloqueo en todos los objetos de un tipo particular. Los
investigadores actualmente están trabajando para comprender cómo utilizar aspectos para
diseñar el código de propósito general. Conceptos relacionados incluyen programación
generativa y plantillas.

2. Ágil: El desarrollo ágil de software guía a los proyectos de desarrollo de software que
evolucionan rápidamente con cambiantes expectativas y mercados competitivos. Los
proponentes de este método creen que procesos pesados, dirigidos por documentos (como
TickIT, CMM e ISO 9000) están desapareciendo en importancia. Algunas personas creen
que las empresas y agencias exportan muchos de los puestos de trabajo que pueden ser
guiados por procesos pesados. Conceptos relacionados incluyen la programación extrema,
scrum y lean software development.

3. Experimental: la ingeniería de software experimental es una rama de la ingeniería de

software interesada en la elaboración de experimentos sobre el software, en la recolección
de datos de los experimentos y en la elaboración de leyes y teorías desde estos datos. Los
proponentes de este método defienden que la naturaleza del software es tal que podemos
hacer avanzar el conocimiento en software a través de solo experimentos.

4. Model-driven: El diseño manejado por modelos desarrolla modelos textuales y gráficos

como artefactos primarios de diseño. Hay disponibles herramientas de desarrollo que usan
 transformación de modelo y generación de código para generar fragmentos de código bien
organizado que sirven como base para producir aplicaciones completas.

5. Líneas de productos de software: Las líneas de producción de software es una forma

sistemática para producir familias de sistemas de software, en lugar de crear una sucesión
de productos completamente individuales. Este método destaca una extensiva, sistemática,
reutilización de código formal, para intentar industrializar el proceso de desarrollo de
software.

El futuro de la Conferencia de ingeniería de Software (FOSE),6 celebrada en ICSE 2000,

documenta el estado del arte de SE en 2000 y lista muchos problemas a resolver en la
próxima década. El FOSE sigue la pista de las conferencias ICSE 20007 y el ICSE 20078 y
también ayudar a identificar el estado del arte en ingeniería de software.

PROCESO PARA EL DESARROLLO DE UN SOFTWARE

El proceso de ingeniería de software se define como «un conjunto de etapas parcialmente

ordenadas con la intención de lograr un objetivo, en este caso, la obtención 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 diseño y el diseño implementado en código, el código es
probado, documentado y certificado para su uso operativo». Concretamente «define quién
está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo» [Jacobson 1998].

El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una

metodología y un lenguaje propio. A este proceso también 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:

Especificación: usuarios e ingenieros definen el software a producir y las restricciones en su

funcionalidad.

Desarrollo: fase en la cual el software se diseña y se programa.

Validación: el software debe ser probado para asegurar que cumple con las necesidades del
cliente.

Evolución: 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 genéricas
deben organizarse de diferente manera y en diferentes niveles según 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 más 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 finalización de la inmediatamente
anterior. La primera descripción formal la realizó en 1970 Winston W. Royce, en uno de sus
artículos.

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 análisis hasta las pruebas.

Espiral: Combinación de procesos en cascada y prototipado. Fue definido por Barry Boehm
en 1986 en el artículo “A Spiral Model of Software Development and Enhancement”.

RAD (Rapid Application Development): emplea técnicas iterativas y de prototipado. Lo

introdujo James Martin en 1991.

RUP (Rationa Unified Process): El Rational Unified Process en inglés es un proceso de

desarrollo de software iterativo y junto con el Lenguaje Unificado de Modelado (UML),
constituye la metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de

metodologías adaptables al contexto y necesidades de cada organización.

En 1987, Ivar Jacobson fundó la compañía Objectory AB, que desarrolló Objetory, un
método de desarrollo orientado a objetos, extensión de lo que se conocía como
aproximación Ericsson. En 1995, Rational Software compró Objectory AB, y en los siguientes
años desarrollaron y lanzaron el estándar UML (Unified Modeling Language), así como el
Rational Unified Process (RUP), que aunaba los esfuerzos y la experiencia de todas las
compañías adquiridas por Rational Software. En diciembre de 2002, IBM adquirió Rational
Software.

PRINCIPIO KISS

El principio KISS (del inglés Keep It Simple, Stupid!:1 «¡Mantenlo sencillo, estúpido!») es un
acrónimo usado como principio de diseño.

El principio KISS establece que la mayoría de sistemas funcionan mejor si se mantienen

simples que si se hacen complejos; por ello, la simplicidad debe ser mantenida como un
objetivo clave del diseño, y cualquier complejidad innecesaria debe ser evitada.

Este término es idéntico a la banda estadounidense KISS.

 Este principio se registra por primera vez en la Marina de los Estados Unidos en 1960,2 y se
atribuye principalmente a Kelly Johnson, ingeniero jefe en Lockheed Skunk Works.

Según FOLDOC, el diccionario en línea del Imperial College Department of Computing,

posiblemente tiene su origen en el marketing y las presentaciones de ventas, para ser
utilizado después en el desarrollo de sistemas, sobre todo para evitar que los sucesivos
desarrollos en los diseños se complicaran.

LENGUAJE UNIFICADO DE MODELADO

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de modelado
visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la
implementación de sistemas de software complejos, tanto en estructura como en
comportamiento. UML tiene aplicaciones más allá del desarrollo de software, p. ej., en el
flujo de procesos en la fabricación.

Es comparable a los planos usados en otros campos y consiste en diferentes tipos de

diagramas. En general, los diagramas UML describen los límites, la estructura y el
comportamiento del sistema y los objetos que contiene.

UML no es un lenguaje de programación, pero existen herramientas que se pueden usar

para generar código en diversos lenguajes usando los diagramas UML. UML guarda una
relación directa con el análisis y el diseño orientados a objetos.

UML es una combinación de varias notaciones orientadas a objetos: diseño orientado a

objetos, técnica de modelado de objetos e ingeniería de software orientada a objetos.

UML usa las fortalezas de estos tres enfoques para presentar una metodología más
uniforme que sea más sencilla de usar. UML representa buenas prácticas para la
construcción y documentación de diferentes aspectos del modelado de sistemas de
software y de negocios.

RE INGENIERIA

Reingeniería en un concepto simple es el rediseño de un proceso en un negocio o un cambio

drástico de un proceso. A pesar que este concepto resume la idea principal de la reingeniería
esta frase no envuelve todo lo que implica la reingeniería.

Reingeniería es comenzar de cero, es un cambio de todo o nada, además ordena la empresa

alrededor de los procesos. La reingeniería requiere que los procesos fundamentales de los
negocios sean observados desde una perspectiva transfuncional y en base a la satisfacción
del cliente.

Para que una empresa adopte el concepto de reingeniería, tiene que ser capaz de
deshacerse de las reglas y políticas convencionales que aplicaba con anterioridad y estar
abierta a los cambios por medio de los cuales sus negocios puedan llegar a ser más
productivos
Una definición rápida de reingeniería es "comenzar de nuevo". Reingeniería también
significa el abandono de viejos procedimientos y la búsqueda de trabajo que agregue valor
hacia el consumidor.

Las actividades de valor agregado tienen dos características, es algo que el cliente aprecia y
es importante que se ejecuten correctamente desde la primera vez. La reingeniería se basa
en crear procesos que agreguen el mayor valor a la empresa.

La definición más aceptada actualmente es la siguiente "La Reingeniería es el

replanteamiento fundamental y el rediseño radical de los procesos del negocio para lograr
mejoras dramáticas dentro de medidas críticas y contemporáneas de desempeño, tales
como costo, calidad, servicio y rapidez". (Hammer 1994)

En la definición anterior planteada por Hammer y Champy existen cuatro palabras claves:
Fundamental, Radical, dramáticas y Procesos.

Estas palabras son claves debido a que:

1. Una reingeniería buscará por qué se está realizando algo fundamental.

2. Los cambios en el diseño deberán ser radicales (desde la raíz y no superficiales).

3. Las mejoras esperadas deben ser dramáticas (no de unos pocos porcentajes).

4. Los cambios se deben enfocarse únicamente sobre los procesos.

Se puede decir que una reingeniería es un cambio dramático en el proceso y que como
efecto de esto se tendrá un rompimiento en la estructura y la cultura de trabajo.

La base fundamental de la reingeniería es el servicio al cliente, a pesar del énfasis en esto,

en general las empresas no logran la satisfacción del cliente y una de las razones es que los
métodos y los procesos han dejado de ser inadecuados en tal grado que el reordenamiento
no es suficiente, lo que se necesita es elaborar de nuevo la "ingeniería" del proceso.