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 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 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.

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 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

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.

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.

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.

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.

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 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 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 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:

• 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.

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.

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 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.

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 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.

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...

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 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.

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 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 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.

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.

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.

Diseño

rápido

Const prot.

Eval. del prot. P/cliente.

Ref. de

Protot..

Producto

De Ing.

Recolección y

Ref. de requisitos