TRABAJO PRÁCTICO INGENIERIA DE SOFTWARE II Profesor Luis Baraldi

TRABAJO PRÁCTICO INGENIERIA DE SOFTWARE II
Profesor Luis Baraldi
Trabajo realizado por: Andrés Yacopino
1−
Evolución de los lenguajes de Programación.
Generaciones de los lenguajes de programación
Primera Generación:
La primera generación de lenguajes se remonta a los días en que se codificaba a nivel de máquina. Todavía
continúan llevándose a cabo bastantes trabajos con lenguajes de primera generación. El código máquina y su
equivalente más humanamente legible, el lenguaje ensamblador, representan la primera generación de
lenguajes. Estos lenguajes dependientes de la máquina muestran el menor nivel de abstracción con el que se
puede representar un programa.El lenguaje de máquina está formado por cadenas de ceros y unos por lo tanto
para realizar un programa se necesita de programadores altamente entrenados.
Algunos ejemplos de lenguajes de esta generación son el FORTRAN y el ALGOL que presentaban las
características de abstracción matemática, estructura física plana y consistían únicamente de datos globales y
subrutinas o subprogramas.
Como consecuencia de esto un error podía tener un gran efecto e influía en todo el programa, gracias a que las
estructuras globales de datos eran accesibles por todas las subrutinas.
Existen tantos lenguajes ensambladores como arquitecturas de procesadores con sus correspondientes
conjuntos de instrucciones. Desde un punto de vista de la ingeniería del software, esos lenguajes sólo se deben
usar cuando un lenguaje de alto nivel no satisfaga los requisitos o no esté disponible.
Segunda Generación:
La segunda generación de lenguajes fue desarrollada a finales de los años 50 y principios de los 60 y ha
servido como base para todos los lenguajes de programación modernos (tercera generación). La segunda
generación de lenguajes está caracterizada por su amplio uso, la enorme cantidad de bibliotecas de software y
la gran familiaridad y aceptación. Prácticamente nadie pone en duda que FORTRAN, COBOL, ALGOL y (de
alguna forma) BASIC son lenguajes de base, debido a su madurez y su aceptación. FORTRAN ha subsistido a
30 años de criticas y sigue siendo el primer lenguaje de programación en el ambiente científico y de ingeniería
.La versión estandarizada original de FORTRAN (denominada FORTRAN−66) resultó ser una potente
herramienta para la resolución de problemas computacionales; aunque le faltaba el soporte directo de
estructuras de control, tenia una tipificación de datos pobre, no facilitaba un soporte a la manipulación de
cadenas y tenía algunas otras deficiencias. El último estándar ANSI (denominado FORT−RAN−77} y el
próximo estándar corrigen algunas de las deficiencias encontradas en versiones anteriores del lenguaje. En
muchos casos, FORTRAN ha sido forzado a ajustarse a áreas de aplicación para las que no fue nunca
diseñado, por lo que muchas de las criticas que ha recibido el lenguaje han sido injustas. Para las aplicaciones
de cálculo numérico, FORTRAN sigue siendo el lenguaje elegido, pero para aplicaciones de software de
sistemas, de tiempo real o de productos empotrados, otros lenguajes tienen ventajas más significativas.
COBOL, al igual que FORTRAN, ha alcanzado la madurez y es el lenguaje aceptado como estándar para
1
aplicaciones de procesamiento de datos comerciales. Aunque el lenguaje ha sido a veces criticado por su falta
de unidad. tiene excelentes posibilidades de definición de datos, es muy auto−documentado y proporciona
soporte para un gran rango de técnicas algorítmicas relativas al procesamiento de datos en los negocios.
ALGOL es el predecesor de muchos de los lenguajes de tercera generación y ofrece un repertorio
extremadamente rico de construcciones procedimentales y de tipificación de datos. ALGOL ha sido
extensamente usado en Europa, pero ha encontrado poca aceptación en Estados Unidos (exceptuando el
entorno académico). La versión más comúnmente usada del lenguaje, denominada correctamente
ALGOL−60, ha sido extendida a una implementación más potente, ALGOL−68. Ambas versiones del
lenguaje soportan el concepto de estructuración en bloques. de asignación dinámica de memoria, de
recursividad y otras características con gran influencia en los lenguajes modernos que le precedieron.
BASIC es un lenguaje que fue originalmente diseñado para enseñar programación en modo de tiempo
compartido. El lenguaje parecía destinado a quedarse obsoleto a principios de los anos 70, pero con el
advenimiento de las computadoras personales ha renacido. Existen cientos de versiones de BASIC. lo que
hace difícil discutir las ventajas y las deficiencias del lenguaje. Sin embargo, se seguirá usando ampliamente
FORTRAN durante el siglo XXI.
Tercera Generación:
Los lenguajes de tercera generación (también denominados lenguajes de programación moderna o
estructurada) están caracterizados por sus potentes posibilidades procedimentales ,abstracción de datos,
compilación de módulos en forma separada, orientación a objetos y estructuración de datos. Los lenguajes de
esta clase se pueden dividir en tres amplias categorías, lenguajes de alto nivel de propósito general, lenguajes
de alto nivel orientados a los objetos y lenguajes especializados. Los lenguajes especializados, han sido
diseñados para satisfacer requisitos especiales y, a menudo, tienen una formulación y una sintaxis únicas.
Lenguajes de alto nivel de propósito general.
El lenguaje de alto nivel de propósito general más antiguo (también un lenguaje de base) ,ALGOL, ha servido
como modelo para otros lenguajes de esta categoría. Sus descendientes, PL/l, PASCAL. Modula−2, C ,y Ada ,
han sido adoptados como lenguajes con potencial para un gran espectro de aplicaciones (p. ej.: para uso en
áreas de ciencia e ingeniería, de productos empotrados, comerciales y/o aplicaciones de sistemas).
PL/1 debería clasificarse más apropiadamente como lenguaje de generación 2,5. Fue el primer lenguaje de
amplio espectro, desarrollado con un amplio rango de posibilidades que le permiten ser usado en muchas
áreas de aplicación diferentes. PL/1 da soporte a aplicaciones convencionales de ciencia e ingeniería y de
negocios, permitiendo la especificación de sofisticadas estructuras de datos, la multitarea, una compleja E/S,
el procesamiento de listas y muchas otras posibilidades. Se han desarrollado subconjuntos del lenguaje para
enseñar programación (PL/C), para su uso en aplicaciones de microprocesadores (PL/M) y para programación
de sistemas (PL/S).
PASCAL es un moderno lenguaje de programación desarrollado a principios de los años 70 para enseñar
técnicas modernas de desarrollo de software (p. ej.: programación estructurada). Desde su introducción,
PASCAL ha encontrado mucho apoyo en grandes audiencias de personal dedicado al desarrollo de software y
es usado ampliamente en aplicaciones de ciencia e ingeniería y de programación de sistemas (el lenguaje ha
sido llamado el FORTRAN de los 80). PASCAL es un descendiente directo de ALGOL y contiene muchas de
sus propias características: estructuración en bloques, fuerte triplicación de datos, soporte directo de la
recursividad y otras características suplementarias. Ha sido implementado en computadoras de todo tipo.
Modula−2 es un descendiente evolucionado de PASCAL y (como dirían algunos) una posible alternativa para
el lenguaje de programación Ada. Modula2 junta las posibilidades de implementación directa del diseño,
como el ocultamiento de información, la abstracción y la fuerte tipificación de datos, con las estructuras de
2
control que soportan la recursividad y la concurrencia. Hasta ahora, el uso de Modula−2 en aplicaciones
industriales ha estado muy limitado.
El lenguaje de programación C fue originalmente desarrollado como lenguaje para implementaciones de
sistemas operativos. El sistema operativo UNIX está implementado en C. Sin embargo, actualmente se ha
construido una gran cantidad de productos de software, de aplicaciones empotradas y de software de sistemas,
usando e1 lenguaje C. El lenguaje C fue desarrollado para el ingeniero de software sofisticado y contiene
potentes posibilidades que le dan una considerable flexibilidad. En las manos de un artesano habilidoso es
capaz de trabajar de forma potente pero delicada. Su posibilidad de causar un serio daño es tan obvia que ese
peligro proporciona el único mecanismo de seguridad; ¡un sano respeto por lo que puede hacer su uso
despreocupado!
Como otros lenguajes de esta categoría, C soporta estructuras de datos sofisticadas y tiene características de
tipificación, hace un uso intensivo de los punteros y tiene un rico conjunto de operadores para el cálculo y la
manipulación de datos. Además, permite al programador acercarse a la máquina al suministrar posibilidades
similares al lenguaje ensamblador.
Ada es un lenguaje desarrollado bajo contrato del Departamento de Defensa de EE UU como un nuevo
estándar para sistemas de computadora de tiempo real y empotrados. Similar a PASCAL en notación y
estructura (aunque más potente y complejo), Ada soporta un rico conjunto de posibilidades que incluyen la
multitarea, el manejo de interrupciones, la sincronización y comunicación entre tareas, así como un conjunto
de características únicas como el paquete. Ada ha creado mucha controversia y continúa generándola. Sus
adictos alaban su rica estructura de lenguaje y su enfoque de entorno Ada para la ingeniería del software en
lugar de toda una parafernalia orientada al lenguaje. Sus detractores se preocupan por la complejidad del
lenguaje, la actual ineficiencia de los compiladores operativos y la larga curva de aprendizaje. Parece, sin
embargo, que son más los beneficios del lenguaje y que Ada bien puede dominar durante los años 90 ciertos
ámbitos de aplicación.
Lenguajes orientados a los objetos.
Los lenguajes de programación orientados a los objetos permiten al ingeniero de software implementar los
modelos de análisis y diseño creados mediante AOO y DOO también La orientación a objetos produce
mejoras de amplio alcance en la forma de diseño, desarrollo y mantenimiento del software ofreciendo una
solución a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo
de software: la falta de portabilidad del código y reusabilidad, código que es difícil de modificar, ciclos de
desarrollo largos y técnicas de codificación no intuituvas.
Un lenguaje orientado a objetos ataca estos problemas. Tiene tres características básicas: debe estar basado en
objetos, basado en clases y capaz de tener herencia de clases. Muchos lenguajes cumplen uno o dos de estos
puntos; muchos menos cumplen los tres. La barrera más difícil de sortear es usualmente la herencia.
El concepto de programación orientada a objetos (OOP) no es nuevo, lenguajes clásicos como SmallTalk se
basan en ella. Dado que la OOP. se basa en la idea natural de la existencia de un mundo lleno de objetos y que
la resolución del problema se realiza en términos de objetos, un lenguaje se dice que está basado en objetos si
soporta objetos como una característica fundamental del mismo.
El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como
un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización.
Esta definición especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un
dato simple, sino que contiene en su interior cierto número de componentes bien estructurados. En segundo
lugar, cada objeto no es un ente aislado, sino que forma parte de una organización jerárquica o de otro tipo.
3
ESTRUCTURA DE UN OBJETO
Un objeto puede considerarse como una especie de cápsula dividida en tres partes relaciones, propiedades y
métodos.
Cada uno de estos componentes desempeña un papel totalmente independiente:
Las relaciones permiten que el objeto se inserte en la organización y están formadas esencialmente por
punteros a otros objetos.
Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma
organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto
pueden ser heredadas a sus descendientes en la organización.
Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán
incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a
disposición de sus descendientes a través de la herencia.
Aunque han aparecido docenas de lenguajes orientados a los objetos durante la pasada década, sólo unos
pocos han tenido éxito y fama en el mercado: dialectos de C (p. ej.: C++ y Objective−C), Smalltalk y Eiffel.
Smalltalk. un lenguaje "fundador" orientado a los objetos, se desarrolló originalmente a principio de los años
70 para explorar los conceptos de la orientación a los objetos. Hoy en día, hay disponibles versiones de
Smalltalk para computadoras de todo tipo, aunque el uso del lenguaje para el desarrollo de productos y
sistemas de calidad industrial está limitado. El uso de los dialectos de C orientados a los objetos se ha
difundido mucho en la comunidad de usuarios de UNIX y entre los nuevos desarrolladores de sistemas
orientados a los objetos. Basados en la fortaleza del propio C, los dialectos orientados a los objetos permiten
llevar a cabo una suave transición a partir de este lenguaje de alto nivel, de propósito general y ampliamente
usado. Eiffel es uno de los nuevos lenguajes orientados a los objetos que es suficientemente robusto como
para su aplicación en la industria. Al igual que Smalltalk y los dialectos de C. Eiffel proporciona soporte
directo para las definiciones de clases, la herencia, la encapsulación y el paso de mensajes.
Lenguajes especializados
Los lenguajes especializados están caracterizados por su inusual formulación sintáctica que ha sido
especialmente diseñada para una aplicación particular. Actualmente se usan cientos de lenguajes
especializados. En general, estos lenguajes tienen una base de usuarios mucho menor que los lenguajes de
propósito general. Entre los lenguajes que han encontrado aplicación en la comunidad de la ingeniería del
software están LISP, PROLOG, APL y FORTH.
LISP es un lenguaje especialmente adecuado para la manipulación de símbolos y el procesamiento de listas en
problemas combinatorios. Usado casi exclusivamente por la comunidad de la inteligencia artificial, el
lenguaje es especialmente adecuado para la prueba de teoremas, las búsquedas en árboles y otras actividades
de resolución de problemas. Los subprogramas están implementados como funciones que hacen un gran uso
de la recursividad. Debido a que cada función de LISP es una unidad independiente, se puede conseguir una
gran reusabilidad mediante la creación de bibliotecas de funciones primitivas. En estos últimos años, LISP ha
sido usado para el desarrollo de una gran cantidad de sistemas expertos y de compiladores de sistemas
expertos. LISP hace que sea relativamente fácil especificar hechos, reglas y sus correspondientes inferencias
(implementadas como funciones LISP), lo que constituye la base de los sistemas basados en el conocimiento.
PROLOG es otro lenguaje de programación que se ha usado mucho en la construcción de sistemas expertos.
Al igual que LISP, PROLOG proporciona medios de soporte para la representación del conocimiento. Dentro
del lenguaje, se usa una estructura de datos uniforme, denominada término, para construir todos los datos y
4
todos los programas. Cada programa consiste en un conjunto de cláusulas que representan hechos, reglas e
inferencias. Tanto LISP como PROLOG son especialmente adecuados para los problemas que tratan objetos y
sus relaciones. Por esta razón, alguna gente se refiere a LISP y PRO−LOG como lenguajes orientados a los
objetos. Además, la naturaleza de orientación a los objetos de LISP y PROLOG permite que sean aplicados en
el contexto del paradigma de construcción de prototipos de la ingeniería del software.
APL es un lenguaje extremadamente conciso y potente para la manipulación de vectores y matrices. El
lenguaje contiene poco soporte para la tipificación de datos y las construcciones estructuradas. Lo que APL
proporciona es un rico conjunto de operadores computacionales, habiendo ganado pocos pero entusiastas
seguidores en la resolución de problemas matemáticos.
FORTH es un lenguaje diseñado para el desarrollo de software de microprocesadores. El lenguaje soporta la
definición de funciones de usuario (implementadas con notación postfija (polaca inversa)) que se ejecutan de
forma orientada a pila proporcionando una gran eficiencia en velocidad y utilización de memoria.
Desde un punto de vista de ingeniería del software, los lenguajes especializados tienen tantas ventajas como
desventajas. Debido a que cada lenguaje especializado se ha diseñado para una aplicación específica, se puede
facilitar la traducción de los requisitos del diseño a la implementación en código. Por otro lado, la mayoría de
los lenguajes especializados son apenas portables y, normal mente, son menos fáciles de mantener que los
lenguajes de propósito general.
Cuarta Generación:
A lo largo de la historia del desarrollo de software, siempre hemos intentado generar programas de
computadora con cada vez mayores niveles de abstracción. Los lenguajes de la primera generación trabajaban
a nivel de instrucciones máquina, el menor nivel de abstracción posible. Los lenguajes de segunda y tercer
generación han subido el nivel de representación de los programas de computadora, pero aún hay que
especificar distintos procedimientos algorítmicos per fectamente detallados. Durante la pasada década, los
lenguajes de cuarta generación (L4G) han elevado aún más el nivel de abstracción.
Los lenguajes 4GL o lenguajes de cuarta generación fueron proyectados para estar más cerca del lenguaje
natural. Los lenguajes para acceder a las bases de datos son generalmente descriptos como 4GL.
Los lenguajes de esta generación, al igual que los lenguajes de inteligencia artificial, contienen una sintaxis
distinta para la representación del control y para la representación de las estructuras de datos. Sin embargo, un
L4G representa a estas estructuras en un mayor nivel de abstracción, eliminando la necesidad de especificar
los detalles algorítmicos. Por ejemplo, la sentencia:
COMPUTE NET PRESENT VALUE AND RETURN ON INVESTMENT FOR EXPENDITURES 45 AND
49
es típica de un L4G. El sistema del L4G sabe cómo calcular los datos financieros deseados y lo hace sin que el
programador tenga que especificar los algoritmos adecuados. Claramente, el conocimiento que se ha descrito
anteriormente es específico del dominio. O sea, que ese mismo L4G inevitablemente no entenderá:
COMPUTE THE ROOTS OF TRANSCENDENTAL EQUATION C 3 AND APPLY THEM TO
PHYSICAL MODEL.
Aunque otro 4GL, diseñado específicamente para el dominio de aplicación necesario, pudiera hacer
correctamente el trabajo.
Los lenguajes de cuarta generación combinan características procedimentales
5
y no procedimentales. Es decir, el lenguaje permite al usuario especificar condiciones con sus
correspondientes acciones (componente procedimental), mientras que, al mismo tiempo, se pide al usuario que
indique el resultado deseado (componente no procedimental), encontrando los detalles procedimentales
mediante la aplicación de su conocimiento del dominio específico.
Los lenguajes de cuarta generación pueden ser divididos en las siguientes categorías:
Lenguaje de Petición
Hasta ahora, la gran mayoría de los 4GL se han desarrollado para ser usados conjuntamente con aplicaciones
de bases de datos. Tales lenguajes de petición permiten al usuario manipular de forma sofisticada la
información contenida en una base de datos previamente creada. Algunos lenguajes de petición tienen una
sintaxis compleja que no es más sencilla (en algunos casos peor) que la de los lenguajes de tercera generación.
Por ejemplo:
list by region (87.act.sep.sales)
sum (87.est.sep.sales) , (sum (sum (87.act.sep.sales)
Sin embargo, otros lenguajes de petición actualmente disponibles ofrecen una interfaz en lenguaje natural que
permite al usuario expresar:
For the eastern and western regions, how did actual sales for last month compare with forecast?
(Para las regiones del este y del oeste, Cómo se parecen las ventas reales con las previsiones?)
No hace falta decir que la segunda alternativa será elegida por la mayoría de los usuarios.
Generadores de Programas
Los generadores de programas son otra clase de 4GL, aunque algo más sofisticada. Más que basarse en una
base de datos previamente definida, un generador de programas permite al usuario crear programas en un
lenguaje de tercera generación usando notablemente menos sentencias. Estos lenguajes de programación de
muy alto nivel hacen un gran uso de la abstracción de datos y de procedimientos. Desafortunadamente para los
que trabajan en el campo de sistemas y de productos de ingeniería, la mayoría de los generadores de
programas se centran exclusivamente en aplicaciones de sistemas de información de negocios y generan
programas en COBOL. Sin embargo, la nueva generación de herramientas CASE permiten al ingeniero de
software modelizar gráficamente una aplicación de ingeniería y después generar el código fuente en C ó Ada a
partir del modelo gráfico.
Otros L4G.
Aunque los lenguajes de petición y los generadores de programas son los L4G más comunes, existen otras
categorías. Los lenguajes de soporte a la toma de decisiones permiten que los no programadores lleven a cabo
una gran variedad de análisis qué pasa si, que van desde los simples modelos de hojas de cálculo
bidimensionales hasta los sofisticados sistemas de modelos estadísticos y de investigación operativa. Los
lenguajes de prototipos se han desarrollado para asistir en la creación de prototipos facilitando la creación de
interfaces de usuario y de diálogos, además de proporcionar medios para la modelización de datos. Los
lenguajes de especificación formal se pueden considerar L4G cuando producen código máquina ejecutable.
Por último, las herramientas utilizadas en entornos de computadoras personales (p. ej.: hojas de cálculo,
sistemas de bases de datos, Hypercard para el Macintosh) permiten al usuario programar a un nivel más alto
de abstracción del que se disponía previamente.
6
Quinta Generación:
El lenguaje de quinta generación es programación que utiliza una interface de desarrollo gráfica para crear
código fuente que es usualmente compilado usando un compilador de 3era o 4ta generación.
Microsoft, Borland, IBM, y otras compañías hacen productos de programación visual para desarrollar
aplicaciones por ejemplo en Java. La programación visual le permite a uno fácilmente visualizar las jerarquías
de las clases orientadas a objetos y arrastrar iconos para ensamblar componentes del programa. Microbrew
AppWare e IBM VisualAge para Java son ejemplos de 5GL.
Herramientas Case
Evolución de la automatización de la Ingeniería de Software.
En 1955, los ingenieros mecánicos y eléctricos trabajaban con herramientas manuales muy rudimentarias:
libros y tablas que contenían las fórmulas y los algoritmos que necesitaban para el análisis de un problema de
ingeniería; calculadoras (mecánicas, no electrónicas) para realizar los cálculos necesarios y asegurar que el
producto iba a funcionar; bolígrafos y lápices, mesas de dibujo, reglas y otra parafernalia que permitía al
ingeniero crear modelos del producto que iba a construir. Se hizo mucho trabajo bueno, pero se hizo a mano.
Pasó una década y el mismo grupo de ingeniería comenzó a experimentar con la ingeniería basada en
computadora. Muchos empleados se resistieron a utilizar computadoras. Una excusa habitual era: no me fío de
los resultados. Sin embargo, otros se lanzaron hacia delante. El proceso de ingeniería estaba cambiando.
Pasamos a 1975. Las fórmulas y los algoritmos que el ingeniero necesitaba se incorporaron a programas de
computadora que se utilizaban para analizar una gran variedad de problemas de ingeniería. La gente confiaba
en los resultados de estos programas. De hecho, la mayoría de su trabajo no podía realizarse sin ellos. Las
estaciones de trabajo gráficas, conectadas a potentes computadoras, estuvieron en uso en algunas compañías y
sustituyeron a las mesas de dibujo y otras herramientas para la creación de modelos de ingeniería. Se estaba
construyendo un puente entre la ingeniería y el trabajo de manufactura, creando el primer enlace entre el
diseño asistido por computadora (CAD) y la fabricación asistida por computadora (CAM).
Se continuaron realizando progresos, pero ahora dependían del software. La informática y la ingeniería se
habían unido para siempre.
Volviendo al presente, encontramos ingeniería asistida por computadora (CAE), diseño asistido por
computadora y fabricación integrada por computadora (CIM, sucesor de CAM) como actividades usuales en
la mayoría de las empresas. La automatización de la ingeniería no sólo ha llegado sino que se ha convertido en
una parte integral del proceso.
Los ingenieros del software tienen la oportunidad de moldear el futuro del CASE aprendiendo de la evolución
del CAE, del CAD y del CIM.
Un taller de ingeniería del software
Los mejores talleres tienen tres características: (1) un conjunto de herramientas útiles que ayudan en cada paso
de la construcción de un producto; (2) un panel organizado que permite encontrar las herramientas
rápidamente; (3) una persona cualificada que sabe cómo utilizar de forma efectiva las herramientas. Los
ingenieros del software reconocen que necesitan herramientas más variadas (las herramientas manuales por si
mismas, no satisfacen los requisitos de los sistemas basados en computadora modernos). También ellos
necesitan un taller organizado y eficiente en el cual situar sus herramientas.
7
El taller de ingeniería del software se denomina entorno de soporte de proyectos integrado y el conjunto de
herramientas que llena este taller es el CASE.
Una analogía
Es justo decir que la ingeniería del software asistida por computadora tiene el potencial de llegar a ser el
avance tecnológico más importante en la historia del desarrollo de software. La palabra clave en la frase
anterior es potencial.
Hoy en día, las herramientas CASE se añaden a la caja de herramientas del ingeniero de software. El CASE
proporciona al ingeniero la capacidad de automatizar las actividades manuales y de mejorar su enfoque de
trabajo. Aún así, para llegar a ser el avance tecnológico más importante, el CASE debe hacer mucho más.
Debe constituir las piezas que construyan un taller para el desarrollo de software.
Hoy en día, el CASE está donde estaban CAD/CAE/CIM en 1975. Algunas compañías utilizan herramientas
individuales; el uso en la industria se está extendiendo rápidamente y se está llevando a cabo un serio esfuerzo
para integrar las herramientas individuales en un entorno consistente.
No hay duda de que e1 CASE afectará a la ingeniería del software de la misma forma que el CAE/CAD/CIM
han afectado a otras ramas de la ingeniería. Sin embargo, hay algunas diferencias importantes. En sus
primeros días de evolución, el CAD/CAE/CIM desarrolló prácticas de ingeniería que habían sido probadas
durante los 100 últimos años. El CASE, sin embargo, proporciona un conjunto de herramientas
semiautomatizadas y automatizadas que están desarrollando una cultura de ingeniería nueva para muchas
empresas. Existe una diferencia importante en la aceptación y el impacto.
El CAD/CAE se centra casi exclusivamente en la resolución de problemas y el diseño. El CIM constituye su
continuación hacia los procesos de fabricación. El objetivo más importante del CASE (a largo plazo) es
conseguir la generación automática de programas desde una especificación a nivel de diseño. A diferencia del
CAD/CAE, mucha gente cree que el análisis y el diseño no son suficientes para el CASE, sino que deben
conducir a la generación directa del producto final − el software −. Este hecho hace que el reto sea
significativamente más difícil, pero el resultado final, de conseguirse, será mucho más potente.
BLOQUES QUE COMPONEN EL CASE
La ingeniería del software asistida por computadora puede ser tan simple como una única herramienta que
permita desarrollar una actividad especifica, o tan compleja como un entorno que integre distintas
herramientas, una base de datos, gente, hardware, una red, sistemas operativos, estándares y muchos otros
componentes. En esta sección, se presenta una revisión de los bloques que componen un entorno CASE.
8
En la fig. se representan los bloques que componen el CASE. Cada bloque constituye la base del siguiente,
con las herramientas situadas en la cima de la pila. Es interesante ver que el fundamento para un CASE
efectivo tiene poco que ver con las herramientas de ingeniería del software en sí mismas. Los buenos entornos
de ingeniería del software se construyen sobre una arquitectura de entorno que engloba los correspondientes
sistemas de software y de hardware. Además, la arquitectura de entorno debe considerar los patrones de
trabajo humanos que se aplican durante el proceso de ingeniería del software.
Durante los años 60, 70 y 80, el desarrollo de software era una actividad para grandes máquinas'. Los
terminales estaban unidos a computadoras centrales y cada programador compartía los recursos de ésta. Las
herramientas de software disponibles (y había muy pocas) estaban diseñadas para operar en un entorno con
terminales de tiempo compartido.
Hoy en día, la tendencia en el desarrollo de software está lejos de las grandes computadoras y enfocada hacia
las estaciones de trabajo como plataformas de ingeniería del software. Las estaciones de trabajo individuales
se interconectanse mediante redes para que los ingenieros de software puedan comunicarse de forma efectiva.
La base de datos de proyectos está disponible a través de un servidor de archivos en red que es accesible desde
todas las estaciones de trabajo. Un sistema operativo que gestiona el hardware, la red y las herramientas
mantiene todo el entorno unido.
La arquitectura de entorno, compuesta por la plataforma hardware y el soporte del sistema operativo (incluida
la red y la gestión de la base de datos) constituye la base del CASE. Pero el entorno CASE, en sí mismo,
necesita otros componentes. Un conjunto de servicios de portabilidad constituyen un puente entre las
herramientas CASE y su marco de integración y la arquitectura de entorno. El marco de integración es un
conjunto de programas especializados que permiten a cada herramienta CASE comunicarse con las demás,
para crear una base de datos de proyectos y mostrar una apariencia homogénea al usuario final (el ingeniero
de software). Los servicios de portabilidad permiten que las herramientas CASE y su marco de integración
puedan migrar a través de diferentes plataformas hardware y sistemas operativos sin grandes esfuerzos de
adaptación.
Los bloques representados en la Figura 22.1 representan una base para la integración de las herramientas
CASE. Sin embargo, la mayoría no han sido construidas utilizando todos los bloques componentes
comentados anteriormente. De hecho, muchas de éstas son soluciones puntuales. Esto es, una herramienta se
utiliza como ayuda en una actividad concreta de ingeniería del software (p. ej.: modelización del análisis),
pero no se comunica directamente con otras herramientas; no está unida a una base de datos de proyectos y no
se parte de un entorno CASE integrado (I−CASE). Aunque esta situación no es la ideal, una herramienta
CASE puede ser utilizada eficientemente, aun siendo una solución puntual.
9
En el nivel más bajo del espectro de integración está la herramienta individual (solución puntual). Cuando las
herramientas proporcionan facilidades para el intercambio de datos (lo mayoría lo hacen) el nivel de
integración aumenta ligeramente. Estas herramientas generan una salida en un formato estándar compatible
con otras herramientas que puedan leer ese formato. En algunos casos, los que construyen herramientas CASE
complementarias trabajan juntos para establecer un puente entre ellas (p. ej.: una herramienta de diseño y
análisis que se une a un generador de código). Utilizando este enfoque, la compatibilidad entre herramientas
puede generar productos finales que serían difíciles de desarrollar utilizando cada herramienta por separado.
La integración por fuente única se da cuando un constructor de herramientas CASE integra diferentes
herramientas y las vende como un único paquete. Aunque este enfoque es bastante efectivo, la mayoría de los
entornos provenientes de una misma fuente tienen una arquitectura cerrada que hace difícil añadir nuevas
herramientas de otros vendedores.
Al final del espectro de integración está el entorno de soporte de proyectos integrado (del inglés, IPSE). Se
crean estándares para cada uno de los bloques componentes. Los vendedores de herramientas CASE utilizan
estos estándares IPSE para construir herramientas compatibles entre sí.
Clasificación de las herramientas CASE.
Las herramientas CASE pueden ser clasificadas de acuerdo a varios criterios como los siguientes: por su
función,por su papel como instrumentos para el personal técnico o los directivos, por la arquitectura del
entorno (hardware y software) que las soportan o por su origen y coste.
Uno de los más tenidos en cuenta es el de funcionalidad y es el que determina la siguiente clasificación:
• Herramientas de planificación de sistemas de gestión: mediante la modelización de los requisitos
de información estratégica de una organización, estás herramientas proporcionan un "metamodelo"
del cual se pueden obtener sistemas de información específicos. En lugar de centrarse en los requisitos
de una aplicación especifica, la información de gestión se modeliza según va pasando a través de las
distintas entidades organizativas de una compañía. El objetivo principal de las herramientas de esta
categoría es ayudar a comprender mejor como se mueve la información entre las distintas unidades
organizativas.
Las herramientas de planificación no son adecuadas para todas las organizaciones; estas requieren un
compromiso importante en cuanto a recursos y un compromiso filosófico en la gestión, para producir un
modelo completo y actuar después según la información obtenida de este.
• Herramientas de gestión de proyectos: La mayoría de las herramientas CASE de gestión de
proyectos se centran en un elemento específico de la gestión del proyecto, en lugar de proporcionar un
soporte global para la actividad de gestión. Utilizando un conjunto seleccionado de herramientas
CASE, el director del proyecto puede hacer estimaciones útiles de esfuerzo, coste y duración de un
proyecto, definir una estructura de partición del trabajo (EPT) , hacer una planificación realista del
mismo y hacer el seguimiento de proyectos en forma continua. Además el director puede utilizar estas
herram. para recoger datos que le permitan una estimación de la productividad del desarrollo y de la
calidad del producto. Para aquellos directores que dirigen proyectos de desarrollo de software bajo
contrato existen herramientas CASE para hacer un seguimiento que va desde los requisitos de la
petición de propuesta inicial del cliente, hasta el trabajo de desarrollo que convierte estos requisitos en
un producto final.
• Herramientas de planificación de proyectos: las herramientas que caen en esta categoría se centran
en dos áreas principales, el esfuerzo y coste de un proyecto de software; y la planificación del
proyecto. La estimación del coste permite al director del mismo estimar su tamaño utilizando una
medida indirecta ( Ej. líneas de código y puntos de función) y describir las características globales del
10
proyecto. Las herramientas de estimación calculan el esfuerzo estimado, la duración del proyecto y el
número de gente recomendado.
Las herramientas de planificación permiten al director definir todas las tareas (estructura de partición del
proyecto), crear una red de tareas (entrada gráfica), representar las interdependencias entre tareas y modelizar
la cantidad de paralelismo posible dentro del proyecto. La mayoría de las herramientas utilizan el método de
planificación del camino crítico para determinar la repercusión de un retraso en la fecha de entrega.
• Herramientas de seguimiento de requisitos: El objetivo de las herramientas de seguimiento de
requisitos es proporcionar un enfoque sistemático para aislar requisitos, comenzando con las
especificaciones del cliente. La herramienta típica de seguimiento combina la evaluación interactiva
de texto con un sistema de gestión de base de datos que almacena y categoriza cada requisito del
sistema extraído de las especificaciones originales. La extracción de requisitos puede ser tan sencilla
como encontrar cada ocurrencia del verbo "deber" (indicativo del requisito) que resalta en la pantalla
la frase y lo introduce en la base de datos. El trabajo de desarrollo posterior puede referenciarse en la
base de datos, de tal forma que se asegure la satisfacción de cada requisito.
• Herramientas de gestión y medida: Las métricas del software permiten aumentar el control y la
coordinación del proceso de ingeniería del software producido. Las herramientas de medida actuales
se centran en las características del producto y del proceso. Las herramientas orientadas a la gestión
parten de medidas especificas del proyecto (LDC, hombre/mes, etc.) que proporcionan una indicación
global de la productividad y de la calidad. Las herramientas con orientación técnica determinan
medidas técnicas que proporcionan una visión más amplia de la calidad del diseño y del código. La
mayoría de las herramientas mantienen una base de datos de medidas de la "media del mercado.
Basándose en las características del producto y del proyecto proporcionadas por el usuario
"comparan" las medidas obtenidas frente a las medidas del mercado para sugerir mejoras en el
proyecto.
• Herramientas de soporte: La categoría de herramientas de soporte engloba las herramientas de
aplicación y de sistemas que complementan el proceso de ingeniería del software.
Estas incluyen herramientas de documentación, herramientas para gestión de redes y software de sistema,
herramientas de control de calidad y herramientas de gestión de bases de datos y configuración del software.
• Herramientas de análisis y diseño: las herramientas de análisis y diseño permiten al ingeniero de
software crear un modelo del sistema que se va a construir y determinar la calidad del mismo.El
modelo contiene una representación de los datos y del flujo de control, del contenido de los datos,
representaciones de los procesos, especificaciones de control y otras representaciones del modelo.
Estas herramientas proporcionan al ingeniero cierto grado de confianza en la representación del
análisis y ayudan a eliminar errores antes que se propaguen al diseño, o lo que es peor , al código
mismo.
Estas herramientas están representas por las herramientas:
• AE/DE ,análisis y diseño estructurado, técnicas de modelización, notación científica, heurísticas de
análisis y diseño.
• PRO/SIM ,prototipos y simulación, predicción de comportamientos, sistemas de tiempo real,
modelos funcionales, generación de código.
• Herramientas para el diseño y el desarrollo de interfaces: Son en realidad un conjunto de
componentes de software, tales como menús, botones, estructuras, etc. Sin embargo están siendo
reemplazados por desarrollo de prototipos que permiten la creación rápida en pantalla de interfaces
11
sofisticadas ajustadas al entorno del sistema operativo. Los sistemas de desarrollo de interfaces de
usuario proporcionan componentes de programa que gestionan los dispositivos de entrada, validan las
entradas del usuario, manejan las condiciones de error, etc.
• Máquinas de análisis y diseño: utilizan una arquitectura basada en reglas que permite que la
herramienta sea adaptada a cualquier método de análisis y diseño. Soportan AE/DE, DSJ, DSED,
SADT, HOOD.
• Herramientas de programación: Engloba compiladores, editores y depuradores que se utilizan con
los lenguajes de programación comunes como así también los entornos orientados a objetos.
• Herramientas de integración y prueba: comprenden las herramientas de adquisición de datos,
medida estática, medida dinámica, simulación, gestión de pruebas, herramientas de funcionalidad
cruzada.
• Herramientas de creación de prototipos: herramientas de dibujo PRO/SIM, prototipo en papel,
diseñadores de pantallas, case con generación de códigos.
• Herramientas de mantenimiento: Herramientas de ingeniería inversa a especificaciones,
herramientas de reestructuración y análisis de código, herramientas interactivas de reingeniería del
sistema.
• CASE E IA: Algunos herramientas CASE incorporan sistemas expertos, pero la gran mayoría hace
un uso muy reducido de las técnicas de inteligencia artificial. Muchas de las que sí lo hacen utilizan
esta tecnología para la validación gráfica de modelos de diseño y análisis, aplicando reglas de diseño
específicas de un método a los modelos creados por el ingeniero de software.
• I − CASE: los beneficios del case integrado son: transferencia fluida de información, reducción de
esfuerzo para realizar actividades de soporte, aumento en el control de los proyectos, mejora de la
coordinación entre los miembros del equipo que trabajan en un proyecto grande de software.Sin
embargo el I−CASE presenta retos significativos como representaciones consistentes de la
información, interfaces estandarizadas entre las herramientas, y un enfoque efectivo que permita la
I−CASE ejecutarse sobre distintas plataformas de hardware y sistemas operativos.
Perspectivas Futuras
Los cambios que afectarán a la ingeniería del software en la próxima década estarán influenciadas por cuatro
aspectos simultáneamente:
• La gente que trabaja.
• El proceso que aplican.
• La naturaleza de la información.
• La tecnología de computadoras subyacente.
El problema que se produce al aumentar la cantidad de gente que trabaja en un programa (debido a que cada
vez los programas son más grandes) se resuelve creando varios equipos de trabajo pero al aumentar la
cantidad de estos también crecen los problemas de comunicación entre ellos, de manera que si se quiere
resolver este dilema, las perspectivas futuras deben incluir cambios radicales en la forma en que los
individuos y los equipos se comunican entre sí. El correo electrónico y las redes de computadoras pueden
ayudar a resolver estos problemas.
Al avanzar las tecnologías de hardware y de software, cambia la estructura de lugar de trabajo y por lo tanto
12
cambiará los patrones de un ingeniero de software, en lugar de utilizar una estación de trabajo como una
herramienta, el hardware y el software se convierten en un ayudante, realizando tareas auxiliares, coordinando
la comunicación hombre−hombre y en algunos casos, aplicando conocimiento específico del campo para
potenciar la capacidad del ingeniero.
Se irá cambiando el punto de vista secuencial por el evolutivo y los usuarios se involucrarán mucho más en el
proceso de ingeniería del software, esto hará que el usuario final esté mucho más satisfecho y habrá una
mayor calidad global del software.
Hasta la fecha, la gran mayoría del software ha sido construido para procesar datos o información. Los
ingenieros del siglo 21 trabajarán también con sistemas que procesen conocimiento. El conocimiento es
bidimensional, información recogida sobre temas relacionados y no relacionados se interconectan para formar
un cuerpo que llamaremos conocimiento. La clave está en nuestra habilidad para asociar elementos de
información provenientes de varias fuentes diferentes sin una conexión obvia y combinarlos de tal forma que
nos proporcionen un beneficio distinto.
Las perspectivas para la ingeniería del software estarán regidas por las tecnologías del software. A medida que
el software adquiera más fuerza en los problemas "borrosos"(Ia, redes neuronales artificiales, sistemas
expertos), es muy probable que el enfoque evolutivo se imponga al resto de los paradigmas
La ingeniería del software cambiará, pero a pesar de lo radicales que sean los cambios, podemos estar seguros
de que la calidad nunca perderá su importancia y de que el diseño y el análisis efectivo así como la validación
competente siempre tendrán un lugar en el desarrollo de sistemas basados en computadoras.
2−
BASES DE DATOS.
Definición:
Base de Datos es un conjunto exhaustivo no redundante de datos estructurados organizados
independientemente de su utilización y su implementación en máquina accesibles en tiempo real y
compatibles con usuarios concurrentes con necesidad de información diferente y no predicable en tiempo.
Las bases de datos siempre jugaron un papel fundamental en el manejo de la información de negocios de las
empresas, desde el momento en que el volumen de esa información excedió los límites de la capacidad
humana para hacer búsquedas, consultas y cruces entre los datos. A partir de ese momento , las herramientas
de administración de bases de datos comenzaron un crecimiento incesante, hasta convertirse en poderosos
motores capaces de procesar enormes volúmenes de información en cuestión de segundos.
En virtud de su poder, las bases de datos se han afianzado en dos áreas clave para el desarrollo de los
negocios: el procesamiento de transacciones, por un lado, y el análisis minucioso de la información
recolectada en la operatoria diaria para obtener verdades no visibles a simple vista(o datawarehousing), por el
otro.
Para cubrir estas áreas, las bases de datos deben proveer altísima perfomance, escalabilidad, tolerancia a fallas
y la posibilidad de aprovechar al máximo el hardware instalado.
Justificación de las Bases de datos
Sistemas tradicionales:
13
• Sistemas orientados al tratamiento en los que se fija el proceso y luego se gestionan los datos
apocados a existir en ficheros.
• Se desarrollan aplicaciones independientes entendidas como programas y datos (repetición de datos).
• La primera situación problemática seria se plantea con el coste del almacenamiento.
• Podría existir un problema de actualización de datos, al existir datos duplicados en los ficheros.
• Peticiones sorpresivas, que se han de resolver en poco tiempo.
Desventajas de sistemas tradicionales.−
• Redundancia (copia innecesaria). Implica desperdicio de almacenamiento.
• Dificultad de mantenimiento (Actualización).
• Consistencia de datos (Actualización).
• Excesiva dependencia del soporte y los datos.− Un cambio sutil en los datos acarreará el cambio total
del programa.
• Peticiones inesperadas.− Tendencia a utilizar sistemas orientados a la toma de decisión.
• Aumento del tiempo de CPU
El sistema tradicional se define como un esquema horizontal y en cada estrato se encuentra cada aplicación
con todos los ficheros que necesita, aunque estos estarán duplicados.
Nuevo enfoque.
El error del enfoque antiguo consistía en un enfoque al programa. El enfoque nuevo esta orientado a los datos.
• Estos serán un conjunto estructurado independiente de aplicaciones.
• Objetivo de satisfacer necesidades de información de la aplicación.
Bases de datos relacionales.
Algunos ejemplos de sistemas de administración de bases de datos relacionales son:
IBM
DB2 UDB:
Características generales:
El origen del DB2 se remonta al año 1970, cuenta con apróx. 40 millones de usuarios a nivel mundial y
pertenece a la firma IBM.
Permite el manejo de objetos grandes( hasta 2 GB),la definición de datos y funciones por parte del usuario, el
chequeo de integridad referencial, SQL recursivo, soporte multimedia :texto, imágenes, video, audio;queries
paralelos, commit de dos fases, backup/recuperación on−line y offline.
Además cuenta con un monitor gráfico de performance el cual posibilita observar el tiempo de ejecución de
una sentencia SQL y corregir detalles para aumentar el rendimiento.
14
Mediante los extensores se realiza el manejo de los datos no tradicionales, por ejemplo si tengo un campo en
donde tengo almacenados los curriculums de varias personas, mediante este puedo realizar búsquedas en los
documentos con los datos que me interesen sin tener que ver los CV uno por uno.
Esta capacidad se utiliza en sistemas de búsqueda de personas por huellas digitales, en sistemas de
información geográfica, etc.
Plataformas host:
OS/390(MVS), VM & VSE, OS/400
Plataformas de servidor:
OS/2 Warp Server, Sinix, SCO Openserver, Windows NT, Aix, HP Ux, Solaris.
Plataformas Cliente:
OS/2, DOS, Sinix, SCO OpenServer, Windows 3.1/95/NT, Macintosh System 7, Aix, HP Ux, Solaris.
Principales usuarios en la Argentina:
Gobernaciones de Mendoza, San Juan, Neuquén, Bank of Boston, Edenor, Uade.
INFORMIX
Dynamic Server:
Características Generales
Arquitectura multithreaded, ejecución sobre arquitecturas de hardware monoprocesadores, SMP, clusters,
MPP, memoria compartida de alocación dinámica, procesamiento escalable y paralelo: carga de datos,
creación de índices, consultas, agregaciones, backup, recuperaciones paralelas; optimizador basado en costos,
reglas de negocio: constraints, integridad referencial, integridad de entidad, stored procedures, triggers;
utilización de disco crudos, particionamiento inteligente de datos, AIO asincrónico, lecturas avanzadas,
espejado de discos, replicación bidireccional entre múltiples nodos, soporte de arquitectura de 64 bits, soporte
multimedia, administración dinámica (en línea), administración gráfica.
Combina la tecnología relacional con la tecnología de objetos, a cada tipo de dato se le puede agregar
imágenes, sonidos, videos, espacios virtuales, hipertexto, etc.
Esto permite a su vez, la utilización de funciones para trabajar esos objetos: comparación de imágenes, la
búsqueda en un documento Word, la búsqueda en una pagina html.
Los "extensores" de Informix se llaman Datablade, hay un datablade para sonido, para imágenes, etc.
Mediante los datablade se termina haciendo lo que se conoce como Sistema de manejo de base de datos
relacionales orientado a objetos.
Plataformas de Servidor:
Todas las versiones del sistema operativo Unix, y microsoft Windows NT.
15
Plataformas Cliente:
Microsoft Windows95, Microsoft Windows NT, Microsoft Windows 3.1, o centralizado en el equipo
Servidor.
Principales usuarios en la Argentina:
Edesur, Telecom, Clarín, La Nación, Telintar.
MICROSOFT
SQL Server 6.5
Características Generales:
Arquitectura paralela simétrica con balanceo automático de carga, optimizador basado en costos, soporte de
I/O asincrónica para acceso paralelo a múltiples discos, resolución automática de deadlocks, procedimientos
almacenados remotos (server to server RPC), replicación continua y asincrónica con cualquier suscriptor
ODBC (incluyendo IBM DB2, Oracle, Sybase y Microsoft Access), ejecución paralela de transacciones,
indexación y chequeo de integridad, backup para restore paralelo de alta velocidad extensiones para OLAP
(cube y Rollup), integración con MAPI para workflow (notificación automática de cambios en los datos),
commit de dos fases, procedimientos almacenados extendidos con C/C++.
El lenguaje nativo de programación de que dispone es el Transact SQL, es potente y eficaz pero puede parecer
duro y áspero sobre todo para los acostumbrados a lenguajes visuales. Sin embargo puede ser potenciado por
la instalación de componentes en el servidor, o sea, es posible generar clases de objetos en Visual Basic,
Visual Foxpro, etc, instalarlos en el servidor y utilizarlos con facilidad, permitiendo dotar al back end de
funcionalidades extraordinarias.
La gran desventaja que tiene este sistema es que corren únicamente bajo plataforma NT.
Plataforma de Servidor:
Windows NT (486 o superior, 32 MB de RAM, 95 MB en disco rígido y lectora de CD−ROM)
Plataforma de Cliente:
Windows 95, Windows 3.1, Windows for Workgroups, Windows NT Workstations, MS−DOS.
Principal cliente en la Argentina:
Máxima Afjp.
ORACLE
Oracle 8 Enterprise Server
Características Generales:
Indices Bitmap, optimización de consultas en estrella (star joins), backup/recuperación on−line incremental y
en paralelo administrada por el servidor, recuperación de tablespaces con puntos de tiempos, paralelismo
aplicado a consultas, actualizaciones, creación de índices, búsquedas, análisis y carga, consultas y
16
transacciones distribuidas, replicación con detección y resolución de conflictos, propagación en paralelo y
comunicación minimizada, conectividad multiprotocolo.
Soporta procedimientos almacenados, incluye extensiones procedurales en PL/SQL al SQL estandar
3−
Ingeniería del software: una definición
Una de las primeras definiciones de ingeniería del software fue la propuesta por Fritz Bauer en la primera
conferencia importante [NAU69] dedicada al tema:
El establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que
sea fiable y funcione de manera eficiente sobre máquinas reales.
Aunque se han propuesto muchas más definiciones generales, todas refuerzan la importancia de una disciplina
de ingeniería para el desarrollo del software.
La ingeniería del software surge de la ingenieria de sistemas y de hardware. Abarca un conjunto de tres
elementos clave − métodos, herramientas y procedimientos − que facilitan al gestor controlar el proceso del
desarrollo del software y suministrar a los que practiquen dicha ingeniería las bases para construir software de
alta calidad de una forma productiva.
Los métodos de la ingeniería del software indican cómo construir técnicamente el software. Los métodos
abarcan un amplio espectro de tareas que in−cluyen: planificación y estimación de proyectos, análisis de los
requisitos del sistema y del software, diseño de estructuras de datos, arquitectura de programas y
procedimientos algorítmicos, codificación, prueba y mantenimiento. Los métodos de la ingeniería del
software introducen frecuentemente una notación especial orientada a un lenguaje o gráfica y un conjunto de
criterios para la calidad del software.
Las herramientas de la ingeniería del software suministran un soporte automático o semiautomático para los
métodos. Hoy existen herramientas para soportar cada uno de los métodos mencionados anteriormente.
Cuando se integran las herramientas de forma que la información creada por una herramienta pueda ser usada
por otra, se establece un sistema para el soporte del de−sarrollo del sofware, llamado ingeniería del software
asistida por computadora (del inglés, CASE). CASE combina software, hardware y bases de datos sobre
ingenieria del software (una estructura de datos que contenga la información relevante sobre el análisis,
diseño, codificación y prueba) para crear un entorno de ingeniería del software análogo al diseño/ingeniería
asistido por computadora, CAD/CAE (de las siglas en inglés) para el hardware.
Los procedimientos de la ingeniería del software son el pegamento que junta los métodos y las herramientas y
facilita un desarrollo racional y oportuno del software de computadora. Los procedimientos definen la
secuencia en la que se aplican los métodos, las entregas (documentos, informes, formas, etc.) que se requieren,
los controles que ayudan a asegurar la calidad y coordinar los cambios, y las directrices que ayudan a los
gestores del software a evaluar el progreso.
La ingeniería del software está compuesta por una serie de pasos que abarcan los métodos, las herramientas y
los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniería
del software. La elección de un paradigma para la ingeniería del software se lleva a cabo de acuerdo con la
naturaleza del proyecto y de la aplicación, los métodos y herramientas a usar y los controles y entregas
requeridos. Tres son los paradigmas que se han tratado (y debatido) ampliamente; son los que se describen en
las siguientes secciones.
17
Paradigmas de la Ingeniería de Software.
El ciclo de vida clásico
La Figura ilustra el paradigma del ciclo de vida clásico para la ingeniería del software. Algunas veces llamado
modelo en cascada, el paradigma del ciclo de vida exige un enfoque sistemático y secuencial del desarrollo
del software que comienza en el nivel del sistema y progresa a través del análisis, diseño, codificación, prueba
y mantenimiento. Modelizado a partir del ciclo convencional de una ingeniería, el paradigma del ciclo de vida
abarca las siguientes actividades:
Ingeniería y análisis del sistema. Debido a que el software es siempre parte de un sistema mayor, el trabajo
comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún
subconjunto de estos requisitos al software. Este planteamiento del sistema es esencial cuando el software
debe interrelacionarse con otros elementos, tales como hardware, personas y bases de datos. La ingeniería y el
análisis del sistema abarca los requisitos globales a nivel del sistema con una pequeña cantidad de análisis y
de diseño a un nivel superior.
Análisis de los requisitos del sofiware. El proceso de recopilación de los re−quisitos se centra e intensifica
especialmente para el software. Para eom−prender la naturaleza de los programas que hay que construir, el
ingenierc de software (analista) debe comprender el ámbito de la información de software , así como la
función, el rendimiento y la, interfaces requeridos. Los requisitos, tanto del sistema como del software, si
documentan y se revisan con el cliente.
Diseño. El diseño del software es realmente un proceso multipaso que s enfoca sobre cuatro atributos distintos
del programa: la estructura de los da tos, la arquitectura del software, el detalle procedimental y la
caracterizació de la interfaz. El proceso de diseño traduce los requisitos en una represer tación del software
que pueda ser establecida de forma que obtenga la calidad requerida antes de que comience la codificación. Al
igual que los requisitos, el diseño se documenta y forma parte de la configuración del software Codificación.
El diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Si
el diseño se realiza ( una manera detallada, la codificación puede realizarse mecánicamente. Prueba. Una vez
que se ha generado el código, comienza la prueba d programa. La prueba se centra en la lógica interna del
software, asegurando que todas las sentencias se han probado, y en las funciones externas, realizando pruebas
que aseguren que la entrada definida produce los resultados que realmente se requieren.
Mantenimiento. El software, indudablemente, sufrirá cambios después que se entregue al cliente (una posible
excepción es el software empotrado) Los cambios ocurrirán debido a que se hayan encontrado errores, a que
18
software deba adaptarse a cambios del entorno externo (por ejemplo, cambio solicitado debido a que se tiene
un nuevo sistema operativo o un dispositivo periférico), o debido a que el cliente requiera ampliaciones
funcionales o del rendimiento. El mantenimiento del software aplica cada uno los pasos precedentes del ciclo
de vida a un programa existente en vez de a uno nuevo.
El ciclo de vida clásico es el paradigma más antiguo y más ampliamente usado en la ingeniería del software.
Sin embargo, con el paso de unos cuantos años, se han producido criticas al paradigma, incluso por seguidores
activos, que cuestionan su aplicabilidad a todas las situaciones. Entre los problemas que se presentan algunas
veces, cuando se aplica el pardigma del ciclo de vida clásico, se encuentran:
1− Los proyectos reales raramente siguen el flujo secuencial que propone modelo. Siempre hay iteraciones y
se crean problemas en la aplicación del paradigma.
2− Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. El ciclo
de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al
comienzo de muchos proyectos.
3− El cliente debe tener paciencia. Hasta llegar a las etapas finales del desarro−llo del proyecto, no estará
disponible una versión operativa del programa. Un error importante no detectado hasta que el programa esté
funcionando puede ser desastroso.
Cada uno de estos problemas es real. Sin embargo, el paradigma clásico del ciclo de vida tiene un lugar
definido e importante dentro del trabajo realizado en ingeniería del software. Suministra una plantilla en la
que pueden colocarse los métodos para el análisis, diseño, codificación, prueba y mantenimiento. Ademas,
veremos que los pasos del paradigma clásico del ciclo de vida son muy similares a los pasos genéricos
(sección 1.6) aplicables a todos los paradigmas de ingeniería del software. El ciclo de vida clásico sigue
siendo el modelo procedimental más ampliamente usado por los ingenieros del software. A pesar de sus
inconvenientes, es significativamente mejor que desarrollar el sofbvare sin guías.
Construcción de prototipos
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 programador puede no estar seguro de la
eficiencia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma en que debe realizarse la
interacción hombre−máquina. En estas y muchas otras situaciones, puede ser mejor método de ingeniería del
software la construcción de un prototipo.
19
La construcción de prototipos es un proceso que facilita al programador la creación de un modelo del software
a construir. El modelo tomará una de las tres formas siguientes: (1) un prototipo en papel o un modelo basado
en PC que describa la interacción hombre−máquina, de forma que facilite al usuario la comprensión de cómo
se producirá tal interacción; (2) un prototipo que implemente algunos subconjuntos de la función requerida del
programa deseado, o (3) un programa existente que ejecute parte o toda la función deseada, pero que tenga
otras características que deban ser mejoradas en el nuevo trabajo de de−Sarrollo.
La Figura muestra la secuencia de sucesos del paradigma de construc−ción de prototipos. Como en todos los
métodos de desarro]lo de software, la −onstrucción de prototipos comienza con la recolección de los
requisitos. El téc−nico y el cliente se reunen y definen los objetivos globales para el software, iden−tifican
todos los requisitos conocidos y perfilan las áreas en donde será necesa−rio una mayor definición. Luego se
produce un diseño rápido. El diseño rápido '~e enfoca sobre la representación de los aspectos del software
visibles al usuario ;por ejemplo, métodos de entrada y formatos de salida). El diseño rápido con−~uce a la
construcción de un prototipo. El prototipo es evaluado por el cliente/usuario y se utiliza para refinar los
requisitos del software a desarrollar. Sc pro−duce un proceso interactivo en el que el prototipo es afinado para
que satis−faga las necesidades del cliente, al mismo tiempo que facilita al que lo desarrolla una mejor
comprensión de lo que hay que hacer.
Idealmente, el prototipo sirve como mecanismo para identificar los requisi−tos del software. Si se va a
construir un prototipa que funcione, el realizador intenta hacer uso de fragmentos de programas existentes o
aplica herramientas (por ejemplo, generadores de informes, gestores de ventanas, etc.) que faciliten la rápida
generación de programas que funcionen.
Pero, ¿qué debemos hacer con el prototipo cuando ya ha servido para el pro−pósito establecido? Brooks
[BRO75, pág. l l6] nos da una respuesta:
En la mayoría de los proyectos, el primer sistema construido apenas es utilizable. Puede ser demasiado lento,
demasiado grande, difícil de usar o las tres cosas. No hay más alternativa que comenzar de nuevo y construir
una versión rediseñada que re−suelva los problemas que se presenten... Cuando se utiliza un nuevo concepto
de sis−tema o de tecnología, hay que construir un sistema para desecharlo, porque incluso la mejor
planificación no puede asegurar que vaya a ser bueno la primera vez. Por tanto, la cuestión no es si hay que
construir un sistema piloto y tirarlo. Se tirara. La única cuestión es si planificar de antemano la construcción
de algo que se va a de−sechar, o prometer entregar el desecho a los clientes...
20
El prototipo puede servir como primer sistema − aquél que Brooks reco−mienda que tiremos. Pero esto puede
ser una visión idealizada. Al igual que en el ciclo de vida clásico, la construcción de prototipos como
paradigma para la ingeniería del software, puede ser problemática por las siguientes razones:
l. El cliente ve funcionando lo que parece ser una primera versión del soft− ware, ignorando que el prototipo
se ha hecho con plastilina y alambres, ignorando que, por las prisas en hacer que funcione, no hemos
considerado los aspectos de calidad o de mantenimiento del software a largo plazo. Cuando se le informa de
que el producto debe ser reconstruido, el cliente se vuelve loco y solicita que se apliquen cuantas mejoras sean
necesarias para hacer del prototipo un producto final que funcione. El gestor del de− sarrollo del software
cede demasiado a menudo. 2. El técnico de desarrollo, frecuentemente, impone ciertos compromisos de
implementación con el fin de obtener un prototipo que funcione rápida− mente. Puede que utilice un sistema
operativo o un lenguaje de programa− ción inapropiados, simpleménte porque ya está disponible y es
conocido; puede que implemente ineficientemente un algoritmo, sencillamente para demostrar su capacidad.
Después de algún tiempo, el técnico puede haberse familiarizado con esas elecciones y haber olvidado las
razones por las que eran inapropiadas. La elección menos ideal forma ahora parte integral del sistema.
Aunque pueden aparecer problemas, la construcción de prototipos es un pa−radigma efectivo para la
ingeniería del software. La clave está en definir al co−mienzo las reglas del juego; esto es, el cliente y el
técnico deben estar de acuerdo en que el prototipo se construya para servir sólo como un mecanismo de
defi−nición de los requisitos. Posteriormente. ha de ser descartado (al menos en parte) y debe construirse el
software real, con los ojos puestos en la calidad y en el mantenimiento.
El modelo en espiral
El modelo en espiral para la ingeniería del software ha sido desarrollado para cubrir las mejores características
tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo
elemento: el análisis de riesgo, que falta en esos paradigmas. El modelo, define cuatro actividades principales,
representadas por :
• Planificación: determinación de objetivos, alternativas y restricciones.
• Análisis de riesgo: análisis de alternativas e identificación/resolución de riesgos .
• Ingeniería: desarrollo del producto de siguiente nivel.
• Evaluación del cliente: valoración de los resultados de la ingeniería
Un aspecto intrigante del modelo en espiral se hace evidente cuando consi−deramos la dimensión radial. Con
cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen
sucesivas versiones del software, cada vez más completas. Durante la primera vuelta alrededor de la espiral se
definen los objetivos, las alternativas y las restricciones, y se analizan e identifican los riesgos. Si el análisis
de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el
cuadrante de ingenieria para dar asistencia tanto al encargado del desarrollo como al cliente. Se pueden usar
simulaciones y otros modelos para definir más el problema y refinar los requisitos.
El cliente evalúa el trabajo de ingenieria (cuadrante de evaluación del cliente) y sugiere modificaciones. En
base a los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada
bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de seguir o no
seguir. Si los riesgos son demasiado grandes, se puede dar por terminado el proyecto.
Sin embargo, en la mayoría de los casos, se sigue avanzando alrededor del camino de la espiral, y ese camino
lleva a los desarrolladores hacia fuera, hacia un modelo más completo del sistema, y, al final, al propio
sistema operacional. Cada vuelta alrededor de la espiral requiere ingeniería (cuadrante inferior derecho), que
se puede llevar a cabo mediante el enfoque del ciclo de vida clásico o de la creación de prototipos. Debe
tenerse en cuenta que el número de actividades de desarrollo que ocurren en el cuadrante inferior derecho
21
aumenta al alejarse del centro de la espiral.
El paradigma del modelo en espiral para la ingeniería del software es actualmente el enfoque más realista para
el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniería del
software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo.
Utiliza la creación de prototipos como un mecanismo de reducción del riesgo, pero, lo que es más importante,
permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evo−lución
del producto. Mantiene el enfoque sistemático correspondiente a los pasos sugeridos por el ciclo de vida
clásico, pero incorporándola dentro de un marco de trabajo interactivo que refleja de forma más realista el
mundo real. El modelo en espiral demanda una consideración directa de riesgos técnicos en todas las etapas
del proyecto y, si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en
problemáticos. Pero, al igual que otros paradigmas, el modelo en espiral no es la panacea. Puede ser difícil
convencer a grandes clientes (particularmente en situaciones bajo contrato) de que el enfoque evolutivo es
controlable. Requiere una considerable habilidad para la valoración del riesgo, y cuenta con esta habilidad
para el éxito. Si no se descubre un riesgo importante, indudablemente surgirán problemas. Por último, el
modelo en sí mismo es relativamente nuevo y no se ha usado tanto como el ciclo de vida o la creación de
prototipos. Pasarán unos cuantos años antes de que se pueda determinar eon absoluta certeza la eficacia de
este importante nuevo paradigma.
Técnicas de cuarta generación
El término técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software que
tienen algo en común: todas facilitan, al que desarrolla el software, la especificación de algunas caracteristicas
del software a alto nivel. Luego, la herramienta genera automáticamente el código fuente basándose en la
especificación del técnico. Cada vez parece más evidente que cuanto mayor sea el nivel en el que se
especifique el software, más rápido se podrá construir el programa. El paradigma T4G para la ingeniería del
software se orienta hacia la posibilidad de especificar el software a un nivel más próximo al lenguaje natural o
en una notación que proporcione funciones significativas. Actualmente, un entorno para el desarrollo de
software que soporte el paradigma T4G puede incluir todas o algunas de las siguientes herramientas:
lenguajes no procedimentales para consulta a bases de datos, generación de infor−mes, manipulación de datos,
interacción y definición de pantallas, generación de código, facilidades gráficas de alto nivel y facilidades de
hoja de cálculo. Todas estas herramientas están disponibles, pero sólo para ámbitos de aplicación muy
especificos. Actualmente, no existe un entorno T4G que pueda aplicarse con igual facilidad a todas las
categorías de aplicaciones del software. Al igual que otros paradigmas, T4G comienza con el paso de
recolección de requisitos. Idealmente, el cliente describe los requisitos, que son, a continuación, traducidos
directamente a un prototipo operativo. Sin embargo, en la práctica no se puede hacer eso. El cliente puede no
estar seguro de lo que necesita; puede ser ambiguo en la especificación de hechos que le son conocidos y
puede no desear o ser incapaz de especificar la información en la forma en que una herramienta T4G puede
aceptarla. Además, las herramientas actuales de T46 no son lo suficientemente sofisticadas como para
entender el lenguaje nátural, y no lo serán por algún tiempo. En este momento el diálogo cliente−técnico
descrito por los otros paradigmas sigue siendo una parte esencial del enfoque T4G.Para aplicaciones
pequeñas, se puede ir directamente desde el paso de recolección de requisitos al paso de implementación,
usando un lenguaje de cuarta generación no procedimental (L4G). Sin embargo, es necesario un mayor
esfuerzo para desarrollar una estrategia de diseño para el sistema, incluso si se utiliza un L4G. El uso de T4G
sin diseño (para grandes proyectos) causará las mismas dificultades (poca calidad, mantenimiento pobre, mala
aceptación por el cliente) que se encuentran cuando se desarrolla software mediante los enfoques
convencionales.
La implementación mediante un L4G permite, al que desarrolla el software, centrarse en la representación de
los resultados deseados, que es lo que se tra−duce automáticamente en un código fuente que produce dichos
resultados. Obviamente, debe existir una estructura de datos con información relevante y a la que el L4G
pueda acceder rápidamente.
22
Para transformar una implementación T4G en un producto, el que lo desarrolla debe dirigir una prueba
completa, desarrollar una documentación con sentido y ejecutar el resto de actividades de transición
requeridas en los otros paradigmas de ingeniería del software. Además, el software desarrollado con T4G
deber ser construido de forma que facilite la realización del mantenimiento de forma expeditiva.
Ha habido mucha controversia y un considerable debate sobre el uso del paradigma T4G . Los defensores
aducen reducciones drásticas en el tiempo de desarrollo del software y una mejora significativa en la
productividad de la gente que construye el software. Los detractores aducen
que las herramientas actuales de T4G no son más fáciles de utilizar que los lenguajes de programación, que el
código fuente producido por tales herramientas es ineficiente y que el mantenimiento de grandes sistemas de
software desarrollados mediante T4G, es cuestionable.
Ambas posturas tienen su parte de razón. Aunque es difícil separar los hechos de las suposiciones (existen
pocos estudios controlados hasta el momento),
Es posible resumir el estado actual de los métodos de T4G:
Con muy pocas excepciones, el ámbito de aplicación actual de las T4G está limitado a las aplicaciones de
sistemas de información de gestión, concre−tamente al análisis de información y la obtención de informes
relativos a grandes bases de datos. Sin embargo, las nuevas herramientas CASE soportan ahora el uso de T4G
para la generación automática de esquemas de código para aplicaciones de ingeniería y de tiempo real.
Los datos preliminares recogidos en compañías que usan T4G parecen in−dicar que el tiempo requerido para
producir software se reduce mucho para aplicaciones pequeñas y de tamaño medio, y que la cantidad de
análisis y diseño para las aplicaciones pequeñas, también se reduce.
Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de
análisis, diseño y prueba (actividades de ingeniería del software), perdiéndose así un tiempo sustancial que se
ahorra mediante la eliminación de la codificación.
Resumiendo, las técnicas de cuarta generación ya se han convertido en una parte importante del desarrollo de
software en el área de aplicaciones de siste−mas de información y probablemente llegarán a usarse bastante en
aplicaciones e ingeniería y de tiempo real durante la segunda mitad de la década de los noventa. La demanda
de software continuará creciendo durante el resto de este siglo, pero los métodos y los paradigmas
convencionales contribuirán probablemente cada vez menos al desarrollo del mismo. Las técnicas de cuarta
generación llenarán el hueco existente.
Combinación de paradigmas
Frecuentemente, se describen los paradigmas de la ingeniería del software, como métodos alternativos para la
ingeniería del software en lugar de como métodos complementarios. En muchos casos, los paradigmas pueden
y deben combinarse de forma que puedan utilizarse las venttajas de cada uno en un único proyecto. El
paradigma del modelo en espiral lo hace directamente, combinando la creación de prototipos y algunos
elementos del ciclo de vida clásico, en un enfoque evolutivo para la ingeniería del software. Pero ninguno de
los paradigmas puede servir como base en la cual se integren los demás.En todos los casos, el trabajo
comienza con la determinación de objetivos, alternativas y restricciones − paso que a veces se llama
recolección preliminar de requisitos. A partir de ese punto, se puede tomar cualquiera de los caminos Por
ejemplo, se pueden seguir los pasos del ciclo de vida clásico , si se puede especificar completamente el
sistema al principio de todo. Si los requisitos son inciertos, se puede usar un prototipo para definir mejor los
requisitos. Usando el prototipo como guía, el que desarrolla puede después volver a los pasos del ciclo de vida
clásico (diseño, codificación y prueba). Alternativamente, el prototipo puede evolucionar hacia el sistema a
23
producir, con una vuelta al paradigma del ciclo de vida en el momento de la etapa de prueba. Se pueden usar
las técnicas de cuarta generación para implementar el prototipo o para implementar el sistema durante el paso
de codificación del ciclo de vida. También se puede usar un L4G junto con el modelo en espiral en los pasos
de creación de prototipos o de codificación.
No hay necesidad de ser dogmático en la elección de los paradigmas para la ingeniería del software; la
naturaleza de la aplicación debe dictar el método a elegir. Mediante la combinación de paradigmas, el todo
puede ser mejor que la suma de las partes.
El proceso de desarrollo del software contiene tres fases genéricas, independientemente del paradigma de
ingeniería elegido. Las tres fases, definición, desarrollo y mantenimiento, se encuentran en todos los
desarrollos de software, independientemente del área de aplicación, del tamaño del proyecto o de la
complejidad.
La fase de definición se centra sobre el qué. Esto es, durante la definición, el que desarrolla el software intenta
identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué interfaces han de
establecerse, qué restricciones de diseño existen y qué criterios de validación se necesitan para definir un
sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software. Aunque los
métodos aplicados durante la fase de definición variarán dependiendo del paradigma de ingeniería del
software aplicado (o combinación de paradigmas), de alguna forma se producirán tres pasos específicos:
Análisis del sistema. Aunque descrito ya en nuestra discusión del ciclo de vida clásico el análisis del sistema
define el papel de cada elemento de un sistema informático, asignando finalmente al software el papel que va
a desempeñar.
Planificación del proyecto de software. Una vez establecido el ámbito del software, se analizan los riesgos, se
asignan los recursos, se estiman los cos−tes, se definen las tareas y se planifica el trabajo.
Análisis de requisitos. El ámbito establecido para el software proporciona la dirección a seguir, pero antes de
comenzar a trabajar es necesario dispo−ner de una información más detallada del ámbito de información y de
fun−ción del software.
La fase de desarrollo se centra en el cómo. Esto es, durante esta fase, el que desarrolla el software intenta
descubrir cómo han de diseñarse las estructuras de datos y la arquitectura del software, cómo han de
implementarse los detalles procedimentales, cómo ha de traducirse el diseño a un lenguaje de programa−ción
(o lenguaje no procedimental) y cómo ha de realizarse la prueba. Los métodos aplicados durante la fase de
desarrollo variarán, pero de alguna forma se producirán tres pasos concretos:
Diseno del software. EI diseño traduce los requisitos del software a un con−junto de representaciones (algunas
gráficas y otras tabulares o basadas en lenguajes) que describen la estructura de los datos, la arquitectura, el
pro−cedimiento algoritmico y las características de la interfaz.
Codificación. Las representaciones del diseño deben ser traducidas a un lenguaje artificial (un lenguaje de
programación convencional o un lenguaje no procedimental usado en el contexto del paradigma T46), dando
como resultado unas instrucciones ejecutables por la computadora. El paso de la codificación es el que lleva a
cabo esa traducción.
Prueba del software. Una vez que el software ha sido implementado en una forma ejecutable por la máquina,
debe ser probado para descubrir los defec−tos que puedan existir en la función, en la lógica y en la
implementación.
La fase de mantenimiento se centra en el cambio que va asociado a la co rrección de errores, a las
24
adaptaciones requeridas por la evolución del entornc del software y a las modificaciones debidas a los
cambios de los requisitos de cliente dirigidos a reforzar o a ampliar el sistema. La fase de mantenimientc
vuelve a aplicar los pasos de las fases de definición y de desarrollo, pero en e contexto del software ya
existente. Durante la fase de mantenimiento se en cuentran tres tipos de cambios:
Corrección. Incluso llevando a cabo las mejores actividades de garantía d< calidad, es muy probable que el
cliente descubra defectos en el software. E mantenimiento correctivo cambia el software para corregir los
defectos.
Adaptación. Con el paso del tiempo es probable que cambie el entorno ori ginal (p. ej., la UCP, el sistema
operativo, los periféricos) para el que se de sarrolló el software. El mantenimiento adaptativo consiste en
modificar e software para acomodarlo a los cambios de su entorno externo.
Mejora. Conforme utilice el software, el cliente/usuario puede descubri. funciones adicionales que podría
interesar que estuvieran incorporadas en el
software. El mantenimiento perfectivo amplia el software más allá de sus re−quisitos funcionales originales.
Además de estas actividades de mantenimiento básico, la fábrica de software que envejece está forzando a
algunas em−presas a considerar la ingeniería inversa. Mediante un conjunto de herramientas CASE
especializadas se hace ingeniería a la inversa con el software para entender y mejorar su funcionamiento
interno . Las fases y sus pasos relacionados descritos en nuestra visión genérica de la ingeniería del software,
se complementan con varias actividades protectoras: las revisiones que se realizan durante cada paso para
asegurar que se mantiene la calidad. La documentación que se desarrolla y controla para asegurar que toda la
información sobre el sistema y el software estará disponible para un uso pos−terior. El control de los cambios
que se instituye de forma que los cambios pue−dan ser mejorados y registrados. En el paradigma del ciclo de
vida clásico, las fases y pasos descritos en esta sección quedan definidos explícitamente. En los paradigmas de
construcción de prototipos y de T4G, están implicados algunos de los pasos, aunque no estén explícitamente
identificados. El método para cada paso puede variar de un paradigma a otro, pero el enfoque global que exige
la definición, el desarrollo y el mantenimiento, permanece invariable. Uno puede realizar cada fase con
disciplina y métodos bien definidos o de forma comple−tamente desordenada. Pero habrá que realizarlos de
alguna forma.
El software se ha convertido en el elemento clave de la evolución de los sistemas y productos informáticos.
En las pasadas cuatro décadas, el software ha pasado de ser una resolución de problemas especializada y una
herramienta de análisis de información, a ser una industria por sí misma. Pero la temprana cultura e historia de
la "programación ha creado un conjunto de problemas que persis−ten todavía hoy. El software se ha
convertido en un factor que limita la evolu−ción de los sistemas informáticos. La ingeniería del software es
una disciplina que integra métodos, herramientas y procedimientos para el desarrollo del software de
computadora. Se han propuesto varios paradigmas diferentes, cada uno exhibiendo ventajas y desventajas,
pero todos tienen una serie de fases genéricas en común.
4− Las dos alternativas principales en la necesidad de implementar un sistema informatico en una
organización son: implementar un sistema enlatado o un sistema a medida.
Ambos sistemas ofrecen ventajas e incovenientes de la siguiente manera:
Sistemas enlatados: ofrecen la tranquilidad de haber sido probados e implementados en varias empresas, y
estar relativamente libres de errores y optimizados para el trabajo a realizar.
Gracias a esto, el tiempo de implementación en la empresa se reduce energicamente, y por lo tanto también se
reduce su costo.
25
Otra ventaja es que este sistema es accesible en todo momento, no es necesario esperar un tiempo de
desarrollo para poder disponer de el.
Las desventajas que presenta es que puede no ser todo lo que la empresa necesita de él, al no ser diseñado
especificamente para esta, de manera tal que se tendrán que agregar módulos o programas externos para
satisfacer todos los requisitos.
Sistemas a medida: presentan la ventaja de que al estar diseñados de acuerdo a nuestras necesidades, tienen
todas las características de administración que necesita nuestra empresa o estas pueden ser agregadas cuando
sean necesarias después de haber puesto en marcha el sistema.
El costo de acceder a este producto no es muy distinto al de un sistema a medida.
Las desventajas son: el tiempo de implementación es más elevado que el de un sistema enlatado, ya que este
sistema debe ser diseñado desde cero pasando por todas las etapas de la Ingeniería de software.
Además pueden surgir problemas en el programa, luego de haber sido instalado este en las computadoras de la
empresa, de manera que el sistema deba ser corregido sobre la marcha.
5−
Las organizaciones enfrentan un grave problema conocido como "Y2K", "Year 2000" o "Millennium Bug".
El problema del año 2000 surge porqueq la mayoría de las aplicaciones de software de negocios (mainframe,
cliente/servidor y computadoras personales) escritas durante los 20 ultimos años, usan solamente dos digitos
para especificar el año en vez de cuatro. Por lo tanto a menos que el software sea corregido, en enero del
2000, la mayoría de las computadoras con programas de software sensibles al tiempo, reconocerán el año
como "00" y muchas asumirán que el año es 1900.
Esto podría forzar a la computadora a apagarse ( resetearse o "hard crash") o llevar a calculos incorrectos
("soft crash"). Dos dígitos fueron usados por los programadores en vez de cuatro para designar al año, para
ahorrar espacio de almacenamiento durante el procesamiento.
El problema del año 2000 también puede afectar a microcontroladores
en equipos no computarizados como ascensores, HVAC y sistemas de seguridad.
Como ejemplo de un tipo de calculo incorrecto, que puede ser producido gracias a este problema puede ser el
siguiente:
cuando la computadora ordena datos por año el "00"(para el año 2000) puede ser identificado como un año
anterior al 99 (para el año 1999).
Una proyección u hoja financiera puede mostrar la perspectiva financiera para el periodo 1999−2000
corriendo para atrás en vez de hacia delante. Las companias de seguros pueden reportar polizas de seguros
vencidas en el año 1901.
Un calculo de banco no compatible con el año 2000, podría calcular los intereses desde el año 1995 al 2000
como el interes desde el período que comprende desde 1900 a 1995, un período de 95 en vez de 6.
El Gartner Group, una firma de desarrollo de tecnología de la información, ha estimado que el costo para
corregir el problema del año 2000 será de entre 300 y 600 billones de dolares en todo el mundo.
26
El trabajo de corrección de software consume mucho tiempo, requiriendo muchos esfuerzos de programación
para examinar millones de sentencias de programa, con el objetivo de localizar campos de seis dígitos y
corregirlos.
Modificación de los sistemas existentes vs la migración a los nuevos sistemas.
En muchos casos, una empresa tendrá que tomar la decisión inicial de modificar el sistema
(hardware/software) o migrar hacia una nueva arquitectura. Se dice que detrás de cada crisis hay una
oportunidad. Por ejemplo una empresa con un mainframe puede decidir migrar a un sistema descentralizado
cliente/servidor, con redes de área local y redes de área amplia. Alternativamente, una empresa con un
ambiente cliente/servidor puede decidir crear una intranet donde sus computadoras se comunican entre sí
utilizando el protocolo de la WWW. Para una organización con un sitio en Internet, la creación de una intranet
puede servir para agregar escalabilidad a la empresa.
Sin embargo, parecer ser que cualquier compania puede convertirse en 2000K , si comienza una acción
correctiva en forma temprana y pone disposición suficientes recursos para lograrlo.
Muchas empresas pueden enfrentarse a retrasos técnicos inesperados, cuando descubran que porciones de
codigo de su viejo sistema de administración no estén lo suficientemente documentados y los programadores
originales hayan fallecido, también pueden presentarse retrasos de aspecto legal.
27
Diseño
rápido
Const prot.
Eval. del prot. P/cliente.
Ref. de
Protot..
Producto
De Ing.
Recolección y
Ref. de requisitos
28
29