|
Ingeniería del software es una disciplina o área de la informática o ciencias de la computación, que ofrece metodos y técnicas para desarrollar y mantener software de calidad que resuelvan problemas de todo tipo. Hoy dia es cada vez mas frecuente la consideración de la ingeniería del software como una nueva area de la ingeniería y el ingeniero del software comienza a ser una profesión implantada en el mundo laboral internacional.
La ingeniería del software trata con áreas muy diversas de la informática y de las ciencias de la computación, tales como construcción de compiladores, sistemas operativos o desarrollos de internet abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a una infinidad de áreas tales como negocios, investigación científica, producción, logística, banca, medicina, la red de redes de internet, redes intranet y extranet, etc. Presentamos tres herramientas muy útilis a considerar en el diseño y análisis de sistemas:
|
|
Son un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.
El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:
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 permite 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. La mayoría de las herramientas Case no han sido construidas utilizando todos los bloques componentes. Muchas de éstas son soluciones puntuales, esto es, una herramienta se utiliza como ayuda en una actividad concreta de ingeniería de software (por ejem.: modelización del análisis), pero no se comunica directamente con otras herramientas, porque no está unida a una base de datos de proyectos. Aunque esta situación no es la ideal, una herramienta Case puede ser utilizada eficientemente, aún 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 (la mayoría lo hace), 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 análisis y diseño 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 entre sí. La principal ventaja de la utilización de una herramienta CASE, es la mejora de la calidad de los desarrollos realizados y, en segundo término, el aumento de la productividad. Para conseguir estos dos objetivos es conveniente contar con una organización y una metodología de trabajo además de la propia herramienta. La mejora de calidad se consigue reduciendo sustancialmente muchos de los problemas de análisis y diseño, inherentes a los proyectos de mediano y gran tamaño (lógica del diseño, coherencia, consolidación, etc.). La mejora de productividad se consigue a través de la automatización de determinadas tareas como la generación de código y la reutilización de objetos o módulos.
|
|
El termino "ingeniería inversa" tiene sus orígenes en el mundo del hardware. Una cierta compañía desensambla un producto del hardware competitivo en un esfuerzo por comprender los "secretos" de diseño y fabricación de su competidor. Estos secretos se podrían comprender fácilmente si se obtuvieran las especificaciones de diseño y fabricación del competidor. Pero estos documentos son privados, y no están disponibles para la compañía que efectúa la ingeniería inversa. En esencia, una ingeniería inversa con éxito de lugar a una o más especificaciones de diseño y fabricación para el producto, mediante el examen de ejemplos reales de ese producto.
La ingeniería inversa del software es algo bastante parecido. Sin embargo, en muchos casos, el programa del cal hay que hacer una ingeniería inversa no es un competidor, mas bien, es el propio trabajo de la compañía (con frecuencia, efectuado hace muchos años). Los "secretos" que hay que comprender resultan incomprensibles porque no se llego a desarrollar nunca una especificación. Consiguientemente, la ingeniería inversa del software es el proceso consistente en analizar un programa en un esfuerzo por crear una representación del programa con un nivel de abstracción mas elevado que el código fuente. La ingeniería inversa es un proceso de recuperación de diseño. Las herramientas de ingeniería inversa extraen información acerca de los datos, arquitectura y diseño de procedimientos de un programa ya existente. La ingeniería inversa invoca una imagen de "ranura mágica". Se inserta un listado de código no estructurado y no documentado por la ranura, y por el otro lado sale la documentación completa del programa de computadora. Lamentablemente, la ranura mágica no existe. La ingeniería inversa puede extraer la información de diseño aparte del código fuente, pero el nivel de abstracción, la completitud de la documentación, el grado con el cual trabajan al mismo tiempo las herramientas y el analista humano, y la direccionalidad del proceso son sumamente variables. El nivel de abstracción de un proceso de ingeniería inversa y las herramientas que se utilicen para realizarlo aluden a la sofisticación de la información de diseño que se puede extraer el código fuente. Idealmente, el nivel de abstracción seria lo mas alto posible. Esto es, el proceso de ingeniería inversa debería de ser capaz de derivar sus representaciones de diseño de procedimientos (con un bajo nivel de abstracción); y la información de programas de estructuras de datos (un nivel de abstracción ligeramente mas elevado); modelos de flujos de datos y de control (un nivel de abstracción relativamente alto); y modelos de entidades y de relaciones (un elevado nivel de abstracción). A medida que crece el nivel de abstracción se proporciona al ingeniero del software información que le permitirá una comprensión más sencilla de estos programas. La completitud de un proceso de ingeniería inversa alude al nivel de detalle que se proporciona en un determinado nivel de abstracción. En la mayoría de los casos, la completitud decrece a medida que aumente el nivel de abstracción. Por ejemplo, dado un listado del código fuente, es relativamente sencillo desarrollar una representación de diseño de procedimientos completo. También se pueden derivar sencillas representaciones del flujo de datos o un programa de transición de estados. La completitud mejora en proporción directa con la cantidad de análisis efectuado por la persona que efectúe la ingeniería inversa. La interactividad alude al grado con el cual el ser humano "se integra" con unas herramientas automatizadas para crear un proceso de ingeniería inversa efectivo. En la mayoría de los casos, a medida que crece el nivel de abstracción, la interactividad debe de incrementarse o bien la complejidad se vera reducida. Si la direccionalidad del proceso de ingeniería inversa es monodireccional, toda la información extraída del código fuente se proporcionara a la ingeniería del software que podrá entonces utilizarla durante la actividad de mantenimiento. Si la direccionalidad es bidireccional, entonces la información que se suministrara a una herramienta de la reingenieria que intentara reestructurar o regenerar el viejo programa. El núcleo de la ingeniería inversa es una actividad denominada extracción de abstracciones. El ingeniero tiene que evaluar el viejo programa y a partir del código fuente (que suele no estar documentado) tiene que extraer una especificación significativa del procesamiento que se realiza, la interfaz de usuario que se aplica, y las estructuras de datos de programa o de la base de datos que se utiliza Ingeniería Inversa para comprender el procesamiento". La primera actividad real de la ingeniería inversa comienza con un intento de comprender y después extraer abstracciones de procedimientos representadas por el código fuente. Para comprender las abstracciones de procedimientos, se analiza el código en distintos niveles de abstracción, sistema, programa, modulo, trama y sentencia. La funcinalidad general de todo el sistema debe de ser algo perfectamente comprendido antes de que se produzca un trabajo de ingeniería inversa mas detallado. Así se establece un contexto para su posterior análisis, y se proporcionan ideas generales acerca de los problemas de interoperabilidad entre aplicaciones dentro del sistema. Cada uno de los programas de que consta el sistema de aplicaciones representara una abstracción funcional con un elevado nivel de detalle. Un diagrama de bloques, que represente la iteración entre estas abstracciones funcionales, se creara también. Los módulos efectúan cada uno de ellos una subfunción, y representan una abstracción de procedimientos definida. Se crean alternativas de procesamiento para cada uno de los modelos. En algunos casos, ya existen especificaciones de sistema, programa, y modulo. Cuando tal cosa ocurre, se revisan las especificaciones para apreciar si se ajustan al código existente. Las cosas se vuelven mas complicadas cuando se considera el código que reside en el interior de un modulo. El ingeniero busca secciones de código que representen tramas de procedimientos genéricos. En casi todos los módulos, existe una sección de código que prepara los datos para su procesamiento, una sección diferente de código que efectúa el procesamiento, y otra sección de código que prepara los resultados del procesamiento para exportarlos de ese modulo. En el interior de cada una de estas secciones, se encuentran tramas más pequeñas(p. ej.: suele producirse una verificación de los datos y una comprobación de alcances dentro de la sección de código que prepara los datos para su procesamiento). Se ha sugerido una técnica denominada segmentación de programas[NIN94] como forma de identificar tramas de procedimientos de un modelo, y para después volver a empaquetar estas tramas en una función significativa. Mediante el uso de una herramienta de exploración automatizada, el ingeniero del software aísla las operaciones de enfoque – segmentos discontinuos de código que están relacionados funcionalmente(semánticamente)-. Una vez que se han aislado las operaciones de enfoque, se aplican operaciones de factorización. Los segmentos de código ya enfocados se extraen del código existente y se vuelven a empaquetar en un nuevo modelo. Para grandes sistemas, la ingeniería inversa suele efectuarse mediante el uso de un enfoque semiautomático. Se utilizan herramientas CASE (p. ej. :[MAR94] para "analizar" la semántica del código existente. La salida de este proceso se pasa entonces a unas herramientas de reestructuración y de ingeniería progresiva que complementaran el proceso de reingeniería. Ingeniería Inversa para comprender los datos". La ingeniería inversa de datos suele producirse en distintos niveles de abstracción. En el nivel de programa, es frecuente que sea preciso realizar una ingeniería inversa de las estructuras de datos de programa internas, como parte de un esfuerzo global de reingenieria. En el nivel del sistema, es frecuente que se efectúe una reingenieria. En el nivel del sistema, es frecuente que se efectúe una reingenieria de las estructuras globales de datos (p. ej.: archivos, bases de datos) para ajustarlas a los nuevos paradigmas de gestión de bases de datos (p. ej.: el paso de unos archivos planos a unos sistemas de bases de datos relacionales u orientados a objetos). La ingeniería inversa de las estructuras de datos globales actuales establecen el escenario para la introducción de una nueva base de datos que abarque todo el sistema.
|
|
La reingenieria se produce en dos niveles distintos de abstracción. En el nivel de negocios, la reingenieria se concentra en el proceso de negocios con la intención de efectuar cambios que mejoren la competitividad en algún aspecto de los negocios. En el nivel del software la reingenieria examina los sistemas y aplicaciones de información con la intención de reestructurarlos o reconstruirlos de tal modo que muestren una mayor calidad.
La reingenieria de procesos de negocios (BPR) define los objetivos de negocios, identifica y evalúa los procesos de negocio ya existentes (en el contexto de los objetivos definidos), especifica y diseña los procesos revisados, y construye prototipos, refina e instancia esos procesos en el seno de un negocio. Al igual que la ingeniería de la información, BPR tiene un objetivo que va mas allá del software. El resultado de BPR suele ser la definición de formas en que las tecnologías de la información puedan prestar un mejor apoyo a los negocios.
|