Actualizado 2006/12/16

Bajo licencia Creative Commons 3.0

¿Qué son los sistemas informáticos?

Ingeniería del Software
Ciclo de desarrollo

1.1 ¿Qué son los sistemas informáticos?

Un sistema informático utiliza ordenadores para almacenar datos, procesarlos y

ponerlos a disposición de quien se considere oportuno. Un sistema
puede ser tan simple como: una persona tiene un microordenador y le
introduce datos tan elementales, como por ejemplo las ventas diarias de
una pequeña empresa, se produce una entrada por cada venta y en ella
se declara el elemento vendido, por ejemplo un yogur, la cantidad de
elementos vendidos, por ejemplo cuatro y el precio de venta unitario, por
ejemplo 0.15 euros. Cada entrada se almacena como un registro de un
fichero en el disco. Al finalizar el día se puede obtener un informe de las
ventas y las tendencias. El usuario puede utilizar esta información para
la gestión de almacén o planificar campañas publicitarias. Habitualmente
una empresa tiene más de un ordenador, por ejemplo uno para la
gestión de ventas y otro para la contabilidad y procesos asociados. Sin
embargo la mayor parte de los sistemas son más complejos.

Los sistemas de información tienen muchas cosas en común, la mayoría

de ellos están formados por:

- Personas son un componente esencial en

cualquier sistema de información,
producen y utilizan la información de
sus actividades diarias para decidir lo
que se debe hacer. Las decisiones
pueden ser rutinarias o complejas.

- Procedimientos, los sistemas de

información deben soportar diversas
clases de actividades del usuario, por
eso han de establecerse procedimientos que aseguren que los datos
correctos llegan a las personas adecuadas en su momento justo.

- Equipo, es decir los ordenadores y todos los dispositivos necesarios.

1.2 Ingeniería del software

Según la definición del IEEE, "software es la suma total de los programas de

ordenador, procedimientos, reglas, la documentación asociada y los
 datos que pertenecen a un sistema de cómputo" y "un producto de
software es un producto diseñado para un usuario". En este contexto, la
Ingeniería de Software (SE del inglés "Software Engineering") es un
enfoque sistemático del desarrollo, operación, mantenimiento y retiro del
software.

Su origen se debe a que el entorno actual de desarrollo de sistemas

software viene adoleciendo de:

• Retrasos considerables en la planificación

• Poca productividad
• Elevadas cargas de mantenimiento
• Demandas cada vez más desfasadas con las ofertas
• Baja calidad y fiabilidad del producto
• Dependencia de los realizadores

esto es lo que se ha denominado comunmente "crisis del software", que se ha

originado históricamente en los siguientes pasos:

- Primera Fase. Los albores (1945-1955)

Programar no es una tarea diferenciada del diseño de una máquina

Uso de lenguaje máquina y ensamblador

- Segunda Fase. El florecimiento (1955-1965)

Aparecen multitud de lenguajes

Era posible hacer casi todo

- Tercera Fase. La crisis (1965-1970)

Desarrollo inacabable de grandes programas

Ineficiencia, errores, coste impredecible
Nada es posible

- Cuarta Fase. Innovación conceptual (1970-1980)

Fundamentos de programación
Verificación de programas
Metodologías de diseño

- Quinta Fase. El diseño es el problema (1980-?)

Entornos de programación
Especificación formal
Programación automática

¿Cómo se define crisis?

La palabra crisis se define en el diccionario como "un punto decisivo

 en el curso de algo; momento, etapa, o evento decisivo o crucial". Sin
embargo para el software no ha habido ningún punto crucial, sólo una
lenta evolución.

La crisis en la industria del software ha permanecido durante muchos

años, lo cual parece una contradicción para el término. Lo que si se
podría decir es que hay un problema crónico en el desarrollo de
software.

Ello ha venido originado por una falta de:

• Formalismo y metodología
• Herramientas de soporte
• Administración eficaz

Actualmente está surgiendo una gran expectativa ante la evolución de la

Ingeniería del Software, al ir apareciendo nuevos métodos y
herramientas formales que van a permitir en el futuro un planteamiento
de ingeniería en el proceso de elaboración de software. Dicho
planteamiento vendrá a paliar la demanda creciente por parte de los
usuarios, permitiendo dar respuesta a los problemas de:

• Administración
• Calidad
• Productividad
• Fácil mantenimiento

Este último es uno de los grandes problemas, pues puede llegar a suponer un
importe superior al 60% del total del coste del software.

Las nuevas metodologías suponen un enfoque integral del problema,

abarcando todas las fases, que en su mayoría no se consideraba en los
desarrollos tradicionales. En particular son fundamentales la reducción
de costes y plazos, así como la calidad del producto final. Estas
tecnologías constituyen la denominada "Ingeniería del Software", que se
puede definir como "el tratamiento sistemático de todas las fases del
ciclo de vida del software". Hay otras definiciones, pero todas inciden en
la importancia de una disciplina de ingeniería para el desarrollo de
software.

Definición del término "Ingeniería del Software"

El término Ingeniería, se define en el Diccionario de la Real

Academia Española de la Lengua, como:

1. "Conjunto de conocimientos y técnicas que permiten aplicar el

saber científico a la utilización de la materia y de las fuentes de
energía.

2. Profesión y ejercicio del ingeniero" y el término ingeniero se define

 como " Persona que profesa o ejerce la ingeniería"

La Real Academia de Ciencias Exactas, Físicas y Naturales de

España, define el término Ingeniería como "Conjunto de
conocimientos y técnicas cuya aplicación permite la utilización
racional de los materiales y de los recursos naturales, mediante
invenciones, construcciones u otras realizaciones provechosas para
el hombre"

Evidentemente, al ser una nueva ingeniería, no está incluida su

definición en las referencias citadas, aunque si reúne sus
propiedades.

Revisando definciones, a nivel internacional, se pueden citar como

adecuadas, las siguientes:

Definición 1:

Es el estudio de los principios y metodologías para desarrollo de

sistemas de software.

Definición 2:

Es la aplicación práctica del conocimiento científico en el diseño y

construcción de programas de ordenador y la documentación
adecuada para desarrollar, operar y mantenerlos.

Definición 3:

Se trata del establecimiento de los principios y métodos de la

ingeniería a fin de obtener software de modo rentable.

Definición 4:

La aplicación de un enfoque sistemático, disciplinado y cuantificable

al desarrollo, operación y mantenimiento de software.

Seguidamente se dan algunas definiciones ampliamente aceptadas dentro de

la informática:

DEFINICIONES DE BOEHM

- Software es el conjunto de programas, procedimientos y documentación

asociados a un sistema, y particularmente a un sistema computacional.

- Ingeniería es la aplicación de la ciencia y las matemáticas mediante lo cual las

propiedades de la materia y las fuentes de energía de la naturaleza se hacen
útiles al hombre en estructuras, máquinas, productos, sistemas y procesos.

- Ingeniería de software es la aplicación de la ciencia y las matemáticas

mediante la cual la capacidad de los equipos computacionales se hacen útiles
al hombre a través de programas de computador, procedimientos y la
documentación asociada.

DEFINICION DE BAUER

Ingeniería del Software es el establecimiento y uso de firmes principios y

métodos de ingeniería para la obtención económica de software fiable y que
funcione en máquinas reales.

Durante los primeros años de la informática, el software se consideraba como

un añadido. La programación era un "arte", para el que no existían
metodologías, era un proceso que se realizaba sin ninguna planificación.
En esta época toda la programación se desarrollaba a medida para cada
aplicación, y en consecuencia tenía muy poca difusión, habitualmente
quien lo escribía era porque lo necesitaba, y era quien lo mantenía.

En una segunda época (a partir de mitad de la década de 1960) se

estableció el software como producto y aparecieron las empresas
dedicadas al desarrollo y distribución masiva del mismo. El origen del
término Ingeniería del Software, se atribuye a dos conferencias
organizadas por la OTAN en 1967 y 1968

La tercera era comenzó a mediados de la década de 1970, época en la

que los sistemas informáticos aumentaron mucho en su complejidad, y
nacieron las redes de ordenadores. Esto supuso mucha presión para los
desarrolladores, aunque los ordenadores para uso personal, apenas
estaban difundidos. Esta época acabó con la aparición de los
microprocesadores.

La cuarta era de la evolución de los sistemas informáticos, comienza

hacia 1990 y se dirige al impacto colectivo de los ordenadores y el
software, en todos los entornos. La industria del software tiene un gran
peso en la economía mundial. Aparecen las técnicas de redes
neuronales, junto con la lógica difusa.

Hoy en día el software tiene un doble papel. Es un producto, pero

simultáneamente es el vehículo para hacer entrega de un producto.
Como producto permite el uso del hardware, ya sea, por ejemplo, un
ordenador personal, un teléfono móvil. Como vehículo utilizado para
hacer entrega del producto, actúa como base de control, por ejemplo un
sistema operativo, o un sistema gestor de redes. El software hace
entrega de lo que se considera como el producto más importante del
siglo veintiuno, la información. El software transforma datos personales
para que sean más útiles en un entorno local, gestiona información
comercial para mejorar la competitividad, proporciona el acceso a redes
a nivel mundial, y ofrece el medio de adquirir información en todas sus
formas.

Actualmente se considera la Ingeniería del Software como una nueva

 área de la ingeniería, y la profesión de ingeniero informático es una de
las más demandadas. La palabra ingeniería tiene una connotación de
prestigio que provoca que muchas ramas del conocimiento tiendan a
autodenominarse así.

La ingeniería del software trata áreas muy diversas de la informática y

de las ciencias de la computación, aplicables a un amplio espectro de
campos, tales como negocios, investigación científica, medicina,
producción, logística, banca, meteorología, derecho, redes, entre otras
muchas.

Sin embargo, es frecuente que en la práctica diaria profesional no se

incluya prácticamente ninguna de las recomendaciones más
elementales de la ingeniería del software. Es habitual que el desarrollo
de software se parezca más al descontrol del cuento de «si los
programadores fueran albañiles...» que a una idílica y bien organizada
"factoría de software" (concepto de gran vigencia a finales de los
ochenta).

De hecho, las evaluaciones de los procesos productivos de software

realizadas a raíz de los modelos de procesos de software confirman que
el desarrollo de software suele estar básicamente en estado caótico. Y
no sólo en pequeñas empresas de países como España, sino en
grandes proyectos en naciones como EE UU y Japón.

Como ejemplo de que la ingeniería del software es en la actualidad

imprescindible, la revista satírica inglesa Private Eye dio detalles sobre
importantes proyectos de software que han dado resultados malos.
Entre ellos destacan los del servicio de ambulancias Asinfor de Londres,
el servicio de sanidad regional de Wessex, la Sociedad para los
derechos de autor y el sistema de manejo de equipajes del aeropuerto
de Denver.

De una forma humorística se hace la siguiente comparación con otras

ingenierías:

- Ingeniería mecánica como buscar un gato negro en una habitación

iluminada.

- Ingeniería química como buscar un gato negro en una habitación

oscura.

- Ingeniería software como buscar un gato negro en una habitación

oscura donde no hay ningún gato.

- Ingeniería de sistemas como buscar un gato negro en una habitación oscura

donde no hay gato y alguien dice !!!lo encontré!!!.

La industria envejece
En los años 50 y 60 del siglo XX, muchos comentaristas especializados
criticaban a la industria del metal en EE.UU. por la falta de inversión
en las fábricas. Las fábricas habían comenzado a deteriorarse, no se
aplicaban los métodos de producción modernos, la calidad quedaba
en entredicho, y sin embargo el coste del producto final subía, como
consecuencia la competencia externa ganó una cuota de mercado
considerable.

La dirección de esas industrias no decidió invertir capital para

mantenerse competitivas en el entorno industrial. Como
consecuencia, la industria del metal perdió una parte de mercado muy
significativa, beneficiando a las industrias extranjeras, que tenían
fábricas más modernas en todos sus aspectos.

Actualmente la industria del software está en una situación análoga. A

todos los niveles se tiene una "fábrica de software" que envejece, hay
miles de aplicaciones basadas en software en una situación crítica y
necesitan su renovación urgente, aunque con la llegada del año 2000
y sus temidos efectos, parte del software se puso al día.

El futuro no pasa por "reparar" lo que está mal, y cambiar la imagen de las
aplicaciones, se necesita una reingeniería o reestructuración, de lo
contrario no serán competitivos en este nuevo siglo.
Desafortunadamente, muchos directores de empresas no están
dispuestos a comprometer los recursos, pues piensan que en
funcionando una aplicación, no es necesario nada más.

1.3 Ciclo de desarrollo

El software es un elemento lógico, por lo que tiene unas características muy

diferentes a las del hardware:

El software se desarrolla, no se fabrica en el sentido clásico de la palabra.

Ambas actividades se dirigen a la construcción de un "producto", pero los
métodos son diferentes. Los costes del software se encuentran en la ingeniería,
esto implica que los proyectos no se pueden gestionar como si lo fueran de
fabricación. A mediados de la década de 1980, se introdujo el concepto de
"fábrica de software", que recomienda el uso de herramientas para el desarrollo
automático del software.

Si se representa gráficamente la proporción de fallos en función del tiempo,

para el hardware se tiene la figura conocida como "curva de bañera". Al
principio de su vida hay bastantes fallos (normalmente por defectos de diseño
y/o fabricación), una vez corregidos se llega a un nivel estacionario (bastante
bajo). Sin embargo conforme pasa el tiempo, aparecen de nuevo, por efecto
de: mala calidad, suciedad, malos tratos, temperaturas extremas y otras
causas. El hardware empieza a estropearse.
El software no se estropea. La gráfica de fallos en función del tiempo, tendría
forma de caída desde el principio, hasta mantenerse estable por tiempo casi
indefinido. El software no es susceptible a los males del entorno que provocan
el deterioro del hardware. Los efectos no detectados harán que falle el
programa durante las primeras etapas de su vida, sin embargo una vez
corregidas, no se producen nuevos errores. Aunque no se estropea, si puede
deteriorarse. Esto sucede debido a los cambios que se efectúan durante su
vida.

Cuando un componente hardware se estropea, se cambia por otro que actúa

como una "pieza de repuesto", mientras que para el software, no es habitual
este proceso, lo cual significa que el mantenimiento de los programas es muy
complejo.

La mayoría del software se construye a medida, en vez de ensamblar

componentes previamente creados. Por contra en el hardware se dispone de
todo tipo de circuítos integrados, para fabricar de manera rápida un equipo
completo. Los ingenieros de software no disponen de esta comodidad, aunque
ya se están dando los primeros pasos en esta dirección, que facilitaria tanto el
desarrollo de aplicaciones informáticas.

La formalización del proceso de desarrollo se define como un marco de

referencia denominado ciclo de desarrollo del software o ciclo de vida
del desarrollo del software o ciclo de vida del desarrollo. Se puede
describir como, "el período de tiempo que comienza con la decisión de
desarrollar un producto software y finaliza cuando se ha entregado éste".
Este ciclo, por lo general incluye las fases:

requisitos
diseño
implantación
prueba
instalación
aceptación

El ciclo de desarrollo software se utiliza para estructurar las actividades que se

llevan a cabo en el desarrollo de un producto software. A pesar de que
no hay acuerdo acerca del uso y la forma del modelo, este sigue siendo
útil para la comprensión y el control del proceso.

Seguidamente se exponen las distintas aproximaciones de desarrollo de

software, en función del tipo de ciclo de vida:

A) Aproximación convencional

Se introdujo por Winston Royce en la década de 1970, como una técnica rígida
para mejorar la calidad y reducir los costos del desarrollo de software.
Tradicionalmente es conocido como "modelo en cascada", porque su
filosofía es completar cada paso con un alto grado de exactitud, antes de
 iniciar el siguiente.

Esquemáticamente se puede representar de la siguiente forma:

Donde:

FACTIBILIDAD: Definir un concepto preferente para el producto de software y

determinar su factibilidad de ciclo de vida y superioridad frente a otros
conceptos.

REQUERIMIENTOS: Elaborar una especificación completa y validada de las

funciones requeridas, sus interfaces y el rendimiento del producto de software.

DISEÑO: Elaborar una especificación completa y validada de la arquitectura

global hardware-software, de la estructura de control y de la estructura de datos
del producto, así como un esquema de los manuales de usuarios y planes de
test.

DISEÑO DETALLADO: Elaborar una especificación completa y verificada de la

estructura de control, de la estructura de datos, de las interfaces de relación,
dimensionamiento y algoritmos claves de cada componente de programa
(rutina con un máximo de 100 instrucciones fuentes).

CODIFICACION: Construir un conjunto completo y verificado de componentes

de programas.

INTEGRACION: Hacer funcionar el producto de software compuesto de

componentes de programa.

IMPLEMENTACION: Hacer funcionar el sistema global hardware-software

incluyendo conversión de programas y datos, instalación y capacitación.

OPERACION Y MANTENCION: Hacer funcionar una nueva versión del sistema

global.

TRANSICION: Realizar una sucesión limpia de este a otros eventuales

productos.

En cada caso, "verificación" tienen la acepción: establecer la verdad de la

correspondencia entre un producto de software y su especificación. Es decir:
¿ESTAMOS CONSTRUYENDO CORRECTAMENTE EL PRODUCTO?

Los principales problemas que se han detectado en esta aproximación son

debidos a que se comienza estableciendo todos los requisitos del
sistema:

o En muchas ocasiones no es posible disponer de unas

especificaciones correctas desde el primer momento, porque
puede ser difícil para el usuario establecer al inicio todos los
requisitos.

o En otras hay cambio de parecer de los usuarios sobre las

necesidades reales cuando ya se ha comenzado el proyecto,
siendo probables los verdaderos requisitos no se reflejen en el
producto final

o Otro de los problemas de esta aproximación es que los resultados

no se ven hasta muy avanzado el proyecto, por lo tanto la
realización de modificaciones, si ha habido un error, es muy
costosa.

Esta aproximación es la más empleada por los ingenieros informáticos, aunque

ha sido muy criticada, y de hecho se ha puesto en duda su eficacia.
Entre los problemas que se pueden encontrar con este modelo, se
tienen:
 o Los proyectos raras veces siguen el modelo secuencial que se
supone. Los cambios pueden causar confusión.

o Es difícil disponer en principio de todos los requisitos. Este

modelo presenta dificultades en el momento de acomodar estas
incertidumbres.

o La versión operativa de los programas no está disponible hasta

que el proyecto está muy avanzado. Un error importante puede
ser desastroso, si se descubre al final del proceso.

o Los responsables del desarrollo siempre se retrasan

innecesariamente. Algunos integrantes del equipo de desarrollo
han de esperar a otros para completar tareas pendientes.

B) Aproximación prototipo

Es habitual que en un proyecto software no se identifiquen los requisitos

detallados de entrada, procesamiento o salida. En otros casos no se
está seguro de la eficiencia de un algoritmo, o de la forma en que se ha
de implantar la interface hombre-máquina.

En casos así, lo habitual es construir un prototipo, que idealmente sirviera

como mecanismo para identificar los requisitos del software. Esta
aproximación consiste en realizar la fase de definición de requisitos del
sistema en base a estos tres factores:

o Un alto grado de iteración

o Un muy alto grado de participación del usuario

o Un uso extensivo de prototipos

Las premisas clave de esta aproximación son:

o Que los prototipos constituyen un medio mejor de comunicación

que los modelos en papel

o Que la iteración es necesaria para canalizar, en la dirección

correcta, el proceso de aprendizaje. Esta aproximación se enfoca
a mejorar la efectividad del proceso de desarrollo y no a mejorar
la eficacia de ese proceso.

o El problema, es que los usuarios finales, ven lo que parece ser

una versión de trabajo del software, sin considerar que no es la
versión definitiva y por lo tanto no se han considerado aspectos
de calidad o facilidad de mantenimiento. Cuando se les dice, que
el producto es a partir de entonces cuando se debe de empezar a
"fabricar", no lo entiende y empieza de nuevo con ajustes, lo cual
hace este proceso muy lento.
C) Aproximación evolutiva

En esta aproximación el énfasis está en lograr un sistema flexible y que se

pueda expandir de forma que se pueda realizar muy rápidamente una
versión modificada del sistema cuando los requisitos cambien.

Se diferencia de la aproximación anterior, en que en esta los requisitos

cambian continuamente, lo cual implicaría en el caso previo que las
iteraciones no tendrían fin.

D) Aproximación incremental

Es un concepto muy parecido al de desarrollo evolutivo, y frecuentemente

comprendido en la aproximación del desarrollo evolutivo. Se comienza el
desarrollo del sistema para satisfacer un subconjunto de requisitos
especificados. Las últimas versiones prevén los requisitos que faltan. De
esta forma se logra una rápida disponibilidad del sistema, que aunque
incompleto, es utilizable y satisface algunas de las necesidades básicas
de información.

La diferencia con la aproximación anterior es que en este caso cada

versión parte de una previa sin cambios pero con nuevas funciones,
mientras que la aproximación evolutiva cada vez se desarrolla una
nueva versión de todo el sistema.

Un ejemplo de este paradigma se tiene en el desarrollo de una

aplicación sencilla, como es un editor de textos. En el primer incremento
se podría desarrollar con un reducido conjunto de funciones, como las
funciones básicas de gestión de archivos. En un segundo incremento, se
puede incluir la gestión avanzada de textos. Y en un tercer incremento
se pondría la corrección ortográfica.

E) Aproximación espiral

Nace con el objetivo de captar lo mejor de la aproximación convencional y

de la de prototipo, añadiendo un nuevo componente, el análisis de
riesgos. Esquemáticamente se puede ilustrar mediante una espiral, con
cuatro cuadrantes que definen actividades.

En la primera vuelta de la espiral se definen los objetivos, las alternativas y las

restricciones y se analizan y se identifican los riesgos. Si como
consecuencia del análisis de riesgo se observa que hay incertidumbre
sobre el problema entonces en la actividad correspondiente a la
ingeniería se aplicará la aproximación prototipo cuyo beneficio principal
es el de reducir la incertidumbre de la naturaleza del problema de
información y los requerimientos que los usuarios establecen para la
solución a ese problema.
Al final de esta primera vuelta alrededor de la espiral el usuario evalúa los
productos obtenidos y puede sugerir modificaciones. Se comenzaría
avanzando alrededor del camino de la espiral realizando las cuatro
actividades indicadas a continuación. En cada vuelta de la espiral, la
actividad de ingeniería se desarrolla mediante la aproximación
convencional o ciclo de desarrollo en cascada o mediante la
aproximación de prototipos.

o Actividades

o Acciones

o Planificación Determinación de alternativas, identificación y

resolución de riesgos

o Ingeniería

o Desarrollo y verificación del producto de siguiente nivel

o Evaluación del cliente

o Valoración de los resultados del proceso de desarrollo

F) Aproximación basada en transformaciones

Con la aparición de las herramientas CASE junto con los generadores de

código, el ciclo de desarrollo software en cascada ha cambiado a un
ciclo de vida basado en transformaciones.

CASE (Computer Aided Software Engineering), en castellano "Ingeniería de

software Asistida por Computadora", es un conjunto de métodos,
utilidades y técnicas que facilitan la automatización del ciclo de vida del
desarrollo de sistemas de información.

La utilización de herramientas CASE afecta a todas las fases del ciclo de vida
del software. Este ciclo de vida se puede considerar como una serie de
transformaciones. Primero se definen los requisitos del sistema,
seguidamente existe un proceso de transformación que hace que la
especificación se convierta en un diseño lógico del sistema.
Posteriormente, este sufre otro proceso de transformación para lograr un
diseño físico, es decir que responda a la tecnología destino.

La tecnología CASE propone que estos procesos de transformación sean lo

más automatizables posible. Sus ventajas son:

o Posibilidad de comprobación de errores en etapas iniciales de

desarrollo

o Posibilidad de realizar el mantenimiento en el ámbito de

especificación
 o Soporte de rastreabilidad de los requisitos

o Soporte de reusabilidad

o Potencia la especificación orientada al problema

G) Programación extrema

La Programación Extrema (PX), mejor conocida por su nombre en inglés

"Extreme Programming" (XP), es una de las llamadas Metodologias
Agiles de desarrollo de software más exitosas de los tiempos recientes.
Cada día se genera incontable información sobre el tema, generalmente
en inglés; fue formulada por Kent Beck, autor del primer libro sobre la
materia,"Extreme Programming Explained: Embrace Chang".

Las fundamentales del método son:

Desarrollo iterativo e incremental

Pruebas unitarias continuas,
Programación por parejas de personas
Frecuente interacción del equipo de programación con el cliente
Corrección de todos los errores antes de añadir nueva funcionalidad.
Refactorización del código
Propiedad del código compartida
Simplicidad en el código

Un ejemplo de un caso en el que se aplicó esta metodología fue en la

identificación mediante el ADN de las víctimas del atentado del 11 de
septiembre de 2001 en Nueva York (EE.UU.)

El siguiente enlace ofrece una relación de tipos de herramientas CASE.

Bibliografía de ampliación:

Alonso Amo, F y Segovia Pérez, F. "Entornos y metodologías de

programación". Paraninfo, Madrid 1995

Amescua Seco, Antonio de y otros "Ingeniería del software de gestión. Análisis

y diseño de aplicaciones" Paraninfo, Madrid 1995

McClure, Carma "CASE, la automatización del software". Ra-ma. Madrid 1992

Piattini, M. y otros "Análisis y diseño de aplicaciones informáticas de gestión".

RA-MA, Madrid 2004

Pressman, Roge S. "Ingeniería del software. Un enfoque práctico". 3ª ed.

McGraw Hill, Madrid 1993
Roda, José Luis y Brito, Julio. "Introducción a la ingeniería del software".
Gobierno de Canarias, 2001

Somerville, Ian, "Ingeniería del software". Addison Wesley Iberoamericana,

Wilnington (EE.UU.) 1998

Toval, Ambrosio y Nicolás, Joaquín. "Ingeniería del software. Gestión de

requisitos". DM-ICE, Murcia 1999

Yourdon, E. "Análisis estructurado modeno". Prentice Hall, EE.UU. 1995

Enlaces de interés:

- Cornegie Mellon University. Software Engineering Institute

- Guide to the Software Engineering Body of Knowledge

- ICTnet Comunidades. Ingeniería del software

- Rational software. IBM

- Secretaría del Consejo Superior de Informática y para el impulso

de la administración electrónica