13. ingeniería del software

Historia del software en computación aplicado a la informática educativa. 139

5. Ingeniería del
software.
Como hemos comentado anteriormente, en 1968 se produjo una crisis del
software, debido a ello surgió el campo de la Ingeniería del software. Éste término se
introdujo por primera vez en 1968 en una conferencia de la ingeniería del software de
la OTAN. Era necesario realizar una gran cantidad de cambios a la hora de desarrollar
software. Con su introducción, el hardware dejó de ser un impedimento para el
desarrollo de la informática; redujo los costes y mejoró la calidad y eficiencia del
software producido.

Actualmente podemos decir que el campo es todavía relativamente joven comparado
con otros campos de la ingeniería, hay todavía mucho trabajo y debate sobre qué es
realmente la ingeniería del software, y si se merece el título de ingeniería. Ha crecido
orgánicamente fuera de las limitaciones de ver el software sólo como programación.

El término ingeniería según la RAE se definiría como:

"Estudio y aplicación, por especialistas, de las diversas ramas de la
tecnología, otra forma sería; actividad profesional del ingeniero" [58].

Ingeniero lo definiríamos como:

"Persona que profesa la ingeniería o alguna de sus ramas" [59].

La definición que dio Bauer en 1972 sobre ingeniería del software es la siguiente:

"Ingeniería del Software trata del establecimiento de los principios y
métodos de la ingeniería a fin de obtener software de modo rentable que sea
fiable y trabaje en máquinas reales" [60].

Según Bohem en 1976, la definió como:

"La aplicación práctica del conocimiento científico al diseño y
construcción de programas de computadora y a la documentación asociada
requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce
también como desarrollo de software o producción de software" [61].

La IEEE, la define como:

"La aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación y mantenimiento del software; es decir, la aplicación de la
ingeniería al software" [62].

Daniel Merchán López. 2013

140 Historia del software en computación aplicado a la informática educativa.

Como hemos visto anteriormente, todas las definiciones de ingeniería del software se
centran en el uso de un enfoque sistemático para la construcción de software. El
objetivo primario de la ingeniería del software es construir un producto de alta calidad
de una manera oportuna. Trata de conseguir este objetivo primario usando un
enfoque de ingeniería.

La ingeniería del software representa un proceso formal que incorpora una serie de
métodos bien definidos para el análisis, diseño, implementación y pruebas del
software y sistemas. Además, abarca una amplia colección de métodos y técnicas de
gestión de proyectos para el aseguramiento de la calidad y la gestión de la
configuración del software.

5.1. Capas en ingeniería del
software.
La ingeniería del software es una tecnología multicapa (Fig. 85), cualquier
enfoque de ingeniería debe apoyarse sobre un compromiso de organización de la
calidad. Un conjunto de componentes estratificados reposan sobre ese enfoque de
calidad.

Fig. 85. Capas en ingeniería del software.

Estos componentes que forman parte de la ingeniería del software son:

 Herramientas: La capa de herramientas proporciona soporte a las capas de
proceso y métodos centrándose en el significado de la automatización de
algunas de las actividades manuales, a estas herramientas se les llama CASE
(Computer Aided Software Engineering).
 Métodos: La capa de métodos se centra en las actividades técnicas que se
deben realizar para conseguir las tareas de ingeniería. Proporciona el “cómo” y



cubre las actividades de ingeniería fundamentales. Los métodos incluyen una
gran cantidad de tareas como el análisis de requisitos, diseño, construcción de
programas, pruebas y mantenimiento. Los métodos de la ingeniería del
software dependen de un conjunto de principios básicos que gobiernan cada
una de las áreas de la tecnología e incluyen actividades de modelado y otras
técnicas descriptivas.
 Proceso: El fundamento de la ingeniería del software es la capa del proceso. El
proceso define un marco de trabajo para un conjunto de áreas clave, las cuales
forman la base del control de gestión de proyectos de software y establecen el
contexto en el cuál: se aplican los métodos técnicos, se producen resultados de
trabajo, se establecen hitos, se gestiona la calidad y el cambio se gestiona
adecuadamente.
 Un enfoque de calidad: Son la base o cimientos de la ingeniería del software.
La gestión total de la calidad y las filosofías similares fomentan una cultura
continua de mejoras de procesos que conduce al desarrollo de enfoques cada
vez más robustos para la ingeniería del software.

5.2. Ciclo de vida del software.
[19][63]

Todo software exige llevar a cabo numerosas tareas antes de ser lanzado por
los desarrolladores. Principalmente hay tres pasos generales: definición, construcción y
mantenimiento.

 En la fase de definición se intenta determinar qué información ha de usar el
sistema, qué funciones ha de realizar, qué condicionantes existen, cuáles han
de ser las interfaces del sistema, y qué criterios de evaluación se usarán.
 En la fase de construcción se diseñan las estructuras de los datos y de los
programas. Posteriormente, se escribe, documenta y prueba el software.
 La fase de mantenimiento comienza cuando el sistema ya está desarrollado y
finaliza cuando el producto ya no se utiliza. El conjunto de información
generada en todas las fases constituye la configuración del software.
Normalmente el esquema anterior se detalla dando lugar a modelos concretos
del ciclo de vida.



Fig. 86.Ciclo de vida en cascada.

El ciclo de vida clásico (Fig. 86) consta de varias fases secuenciales siguiendo un
esquema en cascada con el mismo orden que el esquema general.

 En el pre análisis se establecen los requisitos del sistema, asignando funciones a
los distintos componentes y definiendo las interfaces entre ellos. Se estudia si
lo que pide el cliente es posible hacerlo pues normalmente el software forma
parte de un sistema mayor, compuesto por el hardware, bases de datos,
personas y el software propiamente dicho.
 En el análisis y especificación de los requisitos se definen los requisitos y
requerimientos del sistema software a partir de consultas con los clientes y los
usuarios del futuro sistema software. La captura, análisis y especificación de
requisitos, es una parte crucial; de esta etapa depende en gran medida el logro
de los objetivos finales. Como resultado de este estudio, se elabora un
documento conocido como especificación de requisitos del software (SRS).
 El diseño del software consiste en construir una estructura para el software que
permita cumplir los requisitos, es decir, se establece una arquitectura completa
a la par que se identifican y describen las relaciones fundamentales del sistema
software. En esta etapa, se desarrolla un documento que contiene la
descripción del sistema desde el punto de vista del diseño llamado documento
del diseño del software (SDD).



 En el desarrollo se codifica el software en un lenguaje de programación
siguiendo el diseño que se ha especificado hasta ahora. Se puede decir que se
está traduciendo el diseño en programas, se crean las bibliotecas y se reutilizan
los componentes. Esta parte del trabajo puede ser la más obvia pero no es la
que más esfuerzo necesita. La complejidad está relacionada con el lenguaje de
programación utilizado.
 En las pruebas, los programas se integran y se comprueba que se corresponden
con el diseño, realizan correctamente sus funciones y satisface los requisitos
planteados. Normalmente hay dos tipos de pruebas, las de unidad y las
integrales. En las pruebas por unidad se prueba por separado cada módulo del
software y en las pruebas integrales se prueba el software al completo. Si las
pruebas se realizan satisfactoriamente se entrega el software al cliente.
 El mantenimiento es la fase más larga de todo el proceso. El sistema se instala y
se pone en funcionamiento corrigiendo todos los errores no descubiertos en las
etapas anteriores. También se mejora la implementación añadiendo nuevas
funcionalidades siempre que el usuario los necesite.

No solo existe este modelo de ciclo de vida. Los ciclos de vida normalmente varían en
el alcance del ciclo, dependiendo de hasta dónde llegue el proyecto correspondiente,
las características (contenidos) de las fases en que dividen el ciclo y de la organización,
estructura y sucesión de las etapas, si hay realimentación entre ellas o si tenemos
libertad de repetirlas (iterar). Otros modelos son: modelo en V, iterativo, de desarrollo
incremental, en espiral y de prototipos. Expondremos el modelo de prototipos y en
espiral porque los consideramos de más importancia.

El modelo de prototipos (Fig. 87) surge por la dificultad de establecer los requisitos
del software. Normalmente, un cliente
define un conjunto de objetivos generales
para el software, pero no identifica los
requisitos detallados de entrada, proceso o
salida. En otros casos, el responsable del
desarrollo del software puede no estar
seguro de la eficiencia de un algoritmo, de
la calidad de adaptación de un sistema
operativo, o de la forma en que debería
tomarse la interacción hombre-máquina.
En esencia, este modelo se basa en la
construcción de un prototipo durante las
primeras etapas del ciclo de vida.
Fig. 87. Modelo de prototipos.



El modelo de requisitos requiere de una serie de etapas. Comienza con la recolección
y refinamiento de los requisitos con el cliente. Entre el cliente y el desarrollador
encuentran y definen los objetivos globales para el software, identifican los requisitos
conocidos y las áreas del esquema en donde es obligatoria más definición. En este
modelo, esto es igual de importante que el análisis estructurado en el modelo clásico.

En la segunda etapa se realiza un diseño rápido, con los aspectos que el usuario final
verá. El diseño rápido lleva a la construcción de un prototipo. El usuario lo evalúa y de
esos resultados se sacan las conclusiones para refinar los requisitos del software a
desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las
necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda
mejor lo que se necesita hacer.

El modelo en espiral es un modelo de ciclo de vida de software desarrollado por
Boehm en 1985. Las actividades de este modelo se conforman en una espiral, cada
bucle representa un conjunto de actividades. Las actividades no están fijadas a priori,
sino que las siguientes se eligen en función del análisis de riesgos, comenzando por el
bucle anterior.

El modelo en espiral (Fig. 88) combina los modelos en cascada y de prototipos. El
modelo en espiral está pensado para proyectos largos, caros y complicados como la
creación de un sistema operativo.

Fig. 88. Modelo en espiral.



El modelo de ciclo de vida en espiral tiene muy en cuenta el riesgo que aparece a la
hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas
de desarrollo, se opta por la de riesgos más asumibles y se hace un ciclo de la espiral.
Si el cliente quiere seguir haciendo mejoras en el software, se vuelven a evaluar las
nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue
un momento en el que el producto software desarrollado sea aceptado y no necesite
seguir mejorándose con otro nuevo ciclo.

El proceso empieza en la posición central. Desde allí se mueve en el sentido de las
agujas del reloj. Para cada ciclo habrá cuatro actividades: en la primera se evalúan las
alternativas y se identifican y resuelven los riesgos; en la segunda, se desarrolla y
verifica el producto del siguiente nivel; después se planifican las fases siguientes; y por
último, se determinan los objetivos, las alternativas y las restricciones.

5.3. Metodologías de desarrollo del
software. [19][63]
Una metodología es un conjunto integrado de técnicas y métodos que permite
abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de
un proyecto de desarrollo. Es un proceso de software detallado y completo.

Las metodologías se basan en una combinación de los modelos de proceso genéricos
(cascada, de prototipo, etc.). Definen artefactos, roles y actividades, junto con
prácticas y técnicas recomendadas.

La metodología para el desarrollo de software es un modo sistemático de realizar,
gestionar y administrar un proyecto para llevarlo a cabo con altas posibilidades de
éxito. Una metodología para el desarrollo de software comprende los procesos a
seguir sistemáticamente para idear, implementar y mantener un producto software
desde que surge la necesidad del producto hasta que cumplimos el objetivo por el cual
fue creado.

Una definición estándar de metodología puede ser el conjunto de métodos que se
utilizan en una determinada actividad con el fin de formalizarla y optimizarla.
Determina los pasos a seguir y cómo realizarlos para finalizar una tarea. Una
metodología de desarrollo de software es un marco de trabajo que se usa para
estructurar, planificar y controlar el proceso de desarrollo de sistemas de información.
El marco de trabajo está compuesto por una filosofía de desarrollo de software y
múltiples herramientas, modelos y métodos para ayudar en el proceso de desarrollo
de software.



Hay dos tipos de metodologías: las tradicionales y las ágiles.

 Una metodología tradicional o formal se centra en llevar una documentación
exhaustiva de todo el proyecto y en cumplir con un plan de proyecto, definido
todo esto, en la fase inicial del desarrollo del proyecto. Otra de las
características importantes dentro de este enfoque, son los altos costes al
implementar un cambio y la falta de flexibilidad en proyectos donde el entorno
es volátil.

 Una metodología ágil se basa su en la adaptabilidad de los procesos de
desarrollo. Estas metodologías ponen de relevancia que la capacidad de
respuesta a un cambio es más importante que el seguimiento estricto de un
plan. Se centra en retrasar las decisiones y la planificación adaptativa.

5.4. Desarrollo iterativo e
incremental. [19][63]
El desarrollo iterativo e incremental es un proceso de desarrollo de software
cíclico desarrollado en respuesta a la debilidad del modelo en cascada. Empieza con
una planificación inicial y termina con el despliegue, con la iteración cíclica en el
medio. Para apoyar al desarrollo de proyectos, por medio de este modelo, se han
creado diferentes frameworks, entornos de trabajo, como puede ser el Rational
Unified Process. El desarrollo incremental e iterativo es también una parte esencial de
un tipo de programación conocido como Extreme Programming y los demás
frameworks de desarrollo rápido de software.

Fig. 89. Desarrollo iterativo e incremental.



Los pasos clave en este proceso son: empezar con una implementación simple de un
subconjunto de requisitos del software y mejorar iterativamente la secuencia evolutiva
de versiones hasta que se implementa el sistema entero. En cada iteración, se hacen
modificaciones del diseño y se añaden nuevas capacidades.

El desarrollo incremental es una estrategia programada y en etapas, en la que las
diferentes partes del sistema se desarrollan en diferentes momentos o a diferentes
velocidades, y se integran a medida que se completan.

El desarrollo iterativo es una estrategia de programación de reproceso en la que el
tiempo se separa para revisar y mejorar partes del sistema. Esto no presupone
desarrollo incremental, pero trabaja muy bien con él. Una diferencia típica es que la
salida de un incremento no está necesariamente sujeta a más refinamiento, y sus
pruebas o la realimentación del usuario no se usa como entrada para revisar los planes
o especificaciones de los incrementos sucesivos. Por el contrario, la salida de una
iteración se examina para modificación, y especialmente para revisar los objetivos de
las sucesivas iteraciones.

5.5. Desarrollo ágil. [64][65][63]
La ingeniería del software ágil combina una filosofía y un conjunto de
directrices de desarrollo. La filosofía busca la satisfacción del cliente y la entrega
temprana de software incremental; equipos de proyecto pequeños y con alta
motivación; métodos informales; un mínimo de productos de trabajo de la ingeniería
del software; y una simplicidad general del desarrollo. Las directrices de desarrollo
resaltan la entrega sobre el análisis y el diseño y la comunicación activa y continua
entre los desarrolladores y los clientes. Están especialmente ambientadas para
desarrollar proyectos software pequeños.

El desarrollo ágil de software es un grupo de metodologías de desarrollo de software
que se basan en principios similares. Las metodologías ágiles promueven
generalmente un proceso de gestión de proyectos que fomenta el trabajo en equipo,
la organización y responsabilidad propia, un conjunto de mejores prácticas de
ingeniería que permiten la entrega rápida de software de alta calidad, y un enfoque de
negocio que alinea el desarrollo con las necesidades del cliente y los objetivos de la
compañía.

El desarrollo ágil elige hacer las cosas en incrementos pequeños con una planificación
mínima, más que planificaciones a largo plazo. Las iteraciones son estructuras de
tiempo pequeñas (conocidas como “timeboxes”). De cada iteración se ocupa un
equipo realizando un ciclo de desarrollo completo, incluyendo planificación, análisis de



requisitos, diseño, codificación, pruebas unitarias y pruebas de aceptación. La
documentación se produce a medida que es requerida por los agentes involucrados.

La composición del equipo en un proyecto ágil es normalmente multidisciplinar y de
organización propia sin consideración de cualquier jerarquía corporativa existente o los
roles corporativos de los miembros de los equipos. Los miembros de los equipos
normalmente toman responsabilidades de tareas que consigan la funcionalidad de una
iteración. Deciden ellos mismos cómo realizarán las tareas durante una iteración. Los
métodos ágiles enfatizan la comunicación cara a cara sobre los documentos escritos y
cada equipo ágil contendrá un representante del cliente.

5.6. Reingeniería.[63]
Los conceptos de reingeniería e ingeniería inversa están ligados al desarrollo de
software a gran escala, donde una mejora en proceso de este desarrollo supone un
aumento en la competitividad de la empresa.

Aunque hay que tener en cuenta que esta mejora es, en general a largo plazo
(normalmente de uno a dos años) ambas actividades, están orientadas a automatizar
el mantenimiento de aplicaciones. El mantenimiento del software ocupa casi el 60%
que emplea una organización de desarrollo, y continua elevándose a la par que se
produce más software. Osborne y Chikofsky explica por qué es necesario y requiere
tanto esfuerzo el mantenimiento:

" Gran parte del software del que dependemos en la actualidad tiene en
promedio de 10 a 15 años de antigüedad. Aun cuando dichos programas se crearon
empleando las mejores técnicas de diseño y codificación conocidas en la época (y la
mayoría lo eran), se crearon cuando el tamaño de los programas y el espacio de
almacenamiento eran las principales preocupaciones. Entonces emigraron hacia
nuevas plataformas, se ajustaron para adecuarlos a los cambios en las máquinas y a la
tecnología de los sistemas operativos y aumentaron para satisfacer las necesidades de
nuevos usuarios; todo se hizo sin considerar lo suficiente la arquitectura global. El
resultado es estructuras mal diseñadas, codificación deficiente, lógica inadecuada y
escasa documentación de los sistemas de software por los que ahora se nos llama para
mantenerlos en operación..." [63].

El principal objetivo de la reingeniería es reducir el tiempo y los recursos empleados
en el mantenimiento del software mejorando la productividad del proceso. Dicho de
otro modo se trata de analizar el código o el diseño actual y modificarlo con la ayuda
de herramientas automáticas para traducirlo a códigos mas estructurados, y más
eficientes.



Un modelo de reingeniería (Fig. 90) incluye una estrategia operativa. Define seis
actividades que en algunos casos ocurren en una secuencia lineal, pero no siempre es
así. Es un modelo cíclico, lo que quiere decir que cada una de las actividades
presentadas como parte del paradigma pueden volver a visitarse. En algún ciclo
particular el proceso puede terminar después de cualquiera de dichas actividades.

Fig. 90. Reingeniería del software.

Estas seis actividades son:

 Análisis de inventarios: Todas las organizaciones de software deberían
disponer de un inventario de todas sus aplicaciones. Los candidatos a la
reingeniería aparecen cuando se ordena esta información en función de su
importancia para el negocio, longevidad, mantenibilidad actual y otros criterios
localmente importantes. Es entonces cuando es posible asignar recursos a las
aplicaciones candidatas para el trabajo de reingeniería. El inventario deberá
revisarse con regularidad.
 Reestructuración de documentos: El problema del software es que a menudo
dispone de documentación débil. Para solucionarlo hay tres opciones
dependiendo de cómo sea el software. El primer enfoque consta de no
documentar más el software, esto en algunos casos funciona porque no es
posible recrear la documentación para cientos de programas de computadora.
Otra opción es documentar lo que haga falta para la organización. A veces es
innecesario volver a documentar por completo la aplicación. En la última
opción, el sistema se debe documentar por completo.
 Ingeniería inversa: Es el proceso de construir especificaciones de un mayor
nivel de abstracción partiendo del código fuente de un sistema software o
cualquier otro producto (se puede utilizar como punto de partida cualquier



otro elemento de diseño, etc.). Estas especificaciones pueden volver a ser
utilizadas para construir una nueva implementación del sistema utilizando, por
ejemplo, técnicas de ingeniería directa. Hay diferentes tipos de ingeniería
inversa entre los que se encuentran la ingeniería inversa de datos (se aplica
sobre algún código de bases datos), ingeniería inversa de lógica o de proceso
(se aplica sobre código de un programa para averiguar su lógica o sobre
cualquier documento de diseño para obtener documentos de análisis o de
requisitos) y ingeniería inversa de interfaces de usuario (se aplica con objeto de
mantener la lógica interna del programa para obtener los modelos y
especificaciones que sirvieron de base para la construcción de la misma). Las
herramientas más importantes de la ingeniería inversa son los depuradores, las
herramientas de inyección de fallos, los desensambladores, los compiladores
inversos o descompiladores y las herramientas CASE.
 Reestructuración del código: La reestructuración del código se lleva a cabo
para conseguir un diseño que produzca la misma función pero con mayor
calidad que el programa original. Llevar a cabo esta actividad requiere analizar
el código fuente empleando una herramienta de reestructuración.
 Reestructuración de datos: Se realizan tres actividades. Primero se realiza el
análisis del código. Después se evalúan las definiciones de los datos, archivos,
O/I e Interfaces y por último se extraen elementos y objetos de datos para
obtener información del flujo de datos y comprender la estructura.
 La ingeniería directa o renovación: Recupera la información de diseño de un
software ya existente y utiliza esta información para alterar o reconstruir el
sistema existente en un esfuerzo por mejorar su calidad global. En la mayoría
de los casos, el software procedente de una reingeniería vuelve a implementar
la funcionalidad del sistema existente, y añade además nuevas funciones y/o
mejora el rendimiento global.


13. ingeniería del software

Más contenido relacionado

La actualidad más candente

Similar a 13. ingeniería del software

Más de Daniel Merchan

13. ingeniería del software