PARADIGMAS DE INGENIERÍA DE SOFTWARE

Esta ingeniería 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 Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de Sistema de Información y aplicables a infinidad de áreas (negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet Intranet, etc.).

Una definición precisa aun no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores:

• 1 - Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978) 

• 2 - Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software ( Bohem, 1976). 

• 3 - Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972). 

• 4 - Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993). 

La ingeniería de software abarca un conjunto de tres elementos que facilitan el control sobre el proceso de desarrollo de software y suministran las bases para construir software de calidad de una forma productiva: 

     
      2. Herramientas: (automáticas y semiautomáticas) que apoyan a la aplicación de los métodos. Cuando se integran las herramientas de forma que la información creada por una herramienta puede ser usada por otra, se establece un sistema para el soporte del desarrollo de software, llamado Ingeniería de Software Asistida por Computadora (CASE).
      3. Procedimientos: Definen la secuencia en la que se aplican los métodos, las entregas, los controles de calidad y guías para evaluación del progreso.
La Ingeniería de Software está compuesta por una serie de pasos que abarcan los métodos, herramientas y procedimientos mencionados, a los que se denominan Paradigmas de la Ingeniería de Software. 

 1. Métodos: Indican cómo construir el software técnicamente e incluyen un amplio espectro de métodos para la planificación, la estimación, el análisis, el diseño, codificación, prueba y mantenimiento.

ENFOQUE ESTRUCTURADO

ANÁLISIS ESTRUCTURADO

El Análisis Estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada.

Componentes:

-          Símbolos gráficos: Son los iconos y convenciones para identificar y describir los componentes de un sistema y las relaciones entre estos.

-          Diccionarios de datos: Descripciones de todos los datos utilizados en el sistema. Puede ser manual o automatizado.

-          Descripciones de procesos y procedimientos: Declaraciones formales que emplean técnicas y lenguajes que permiten describir actividades importantes que forman parte del sistema.

-          Reglas: Estándares par describir y documentar el sistema en forma correcta y completa.

DISEÑO ESTRUCTURADO

El Diseño Estructurado es una técnica específica que busca crear programas formados por módulos independientes unos de otros desde el punto de vista funcional y no mostrar la lógica de los programas.

La herramienta fundamental del diseño estructurado es el diagrama estructurado, el cual describe la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.

EL ENFOQUE ESTRUCTURADO A OBJETOS 

ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

La Orientación a Objetos puede describirse como el conjunto de disciplinas que desarrollan y modelizan software que facilitan la construcción de sistemas complejos a partir de componentes.

El atractivo intuitivo de la orientación a objetos es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible.

Las técnicas orientadas a objetos proporcionan mejoras y metodologías para construir sistemas de software complejos a partir de unidades de software modularizado y reutilizable. La orientación a objetos trata de cubrir las necesidades de los usuarios finales, así como las propias de los desarrolladores de productos software. Estas tareas se realizan mediante la modelización del mundo real. El soporte fundamental es el modelo objeto.

El Análisis Orientado a Objetos y su Diseño se enfoca en los objetos. Los objetos tienen ciertos comportamientos y atributos que determinan la manera en que interactúan y funcionan. No se intenta proporcionar un orden para las acciones al momento del diseño debido a que los objetos funcionan basados en la manera en que funcionan otros objetos.

Características Principales del Enfoque Orientado a Objetos

-          Identidad: Los datos se organizan en entidades discretas y distinguibles llamadas objetos. Estos objetos pueden ser concretos o abstractos, pero cada objeto tiene su propia identidad.

-          Clasificación: Los objetos que tengan los mismos atributos y comportamiento se agrupan en clases. Una clase es una abstracción que describe propiedades (atributos y comportamiento) relevantes para una aplicación determinada, ignorando el resto.

-          Polimorfismo: El polimorfismo permite que una misma operación pueda llevarse a cabo de forma diferente en clases diferentes.

-          Herencia: El concepto de herencia se refiere al compartir de atributos y operaciones basadas en una relación jerárquica entre varias clases. Una clase puede definirse de forma general y luego refinarse en sucesivas subclases. Cada clase hereda todas las propiedades (atributos y operaciones) de su superclase y añade sus propiedades particulares.

DIFERENCIAS

Análisis y Diseño Estructurado	Análisis y diseño Orientado a Objetos
El análisis estructurado se basa fundamentalmente en la descomposición funcional del sistema que se desea construir, lo cual requiere comprender primero el dominio del problema y a continuación documentar las funciones y subfunciones que debe proporcionar el sistema.	El enfoque Orientado a Objetos invierte el método estructurado, se centra en primer lugar en identificar los objetos del dominio de aplicación y después en establecer procedimientos que los manejen.
El software desarrollado con métodos estructurados suele ser más frágil ante los cambios de requisitos; pues si estos cambian, un sistema basado en descomposición funcional puede requerir una reestructuración masiva.	El software Orientado a Objetos se mantiene mejor ante los cambios de requisitos, porque se basa en la estructura subyacente del dominio de aplicación por lo que las modificaciones necesarias pueden ser más fácilmente localizables.
El Análisis Estructurado modela los sistemas desde un punto de vista más próximo a su implementación en un ordenador (entrada/proceso/salida).	El Análisis Orientado a Objetos se basa en modelar el sistema mediante los objetos que forman parte de él y las relaciones estáticas (herencia y composición) o dinámicas (uso) entre estos objetos. Este enfoque pretende conseguir modelos que se ajusten mejor al problema real.
El análisis estructurado incorpora modelos de datos, de procesos y de comportamiento.	El enfoque Orientado a Objetos, utiliza los mismos modelos que el análisis estructurado. Las diferencias principales consisten en la mayor importancia que se da al modelo de datos, por encima de los otros dos, y en el enfoque orientado a objetos de este modelo.
El modelado de datos mediante el enfoque estructurado, está más orientado al diseño de bases de datos y se centra exclusivamente en la identificación de los datos que maneja un sistema y en las relaciones estáticas que se establecen entre esos datos.	En el AOO, los objetos encapsulan tanto atributos como procedimientos (operaciones que se realizan sobre los objetos), e incorpora además conceptos como el polimorfismo o la herencia que facilitan la reutilización de código. El uso de AOO puede facilitar mucho la creación de prototipos, y las técnicas de desarrollo evolutivo de software.

               

GESTION DE PROYECTOS DE SISTEMAS DE INFORMACION.

Proyecto se refiere a todas las acciones que deben realizarse para cumplir con una necesidad definida dentro de los plazos. Así, ya que el proyecto es una acción temporaria que tiene principio y fin, que utiliza recursos identificados (humanos y materiales) durante su ejecución, y que tiene un costo, deberá tener recursos presupuestados y una hoja de balance independiente a la de la compañía. "Productos finales" se refiere a los resultados esperados del proyecto.

En un sistema de información con calidad está desarrollado con una adecuada organización; es por eso que es necesario dar importancia a la administración de proyectos de sistemas información como herramienta dentro de las empresas para el desarrollo de sistemas de información.

Las empresas con sistemas de información de calidad son aquellas que tiene una cultura organizacional flexible y no ortodoxa, es decir, hacen cambios en su forma de hacer las cosas, hacen uso de la tecnología para el bien de la empresa.

Dentro de unos pocos años aquellas empresas que no cambien sus viejos sistemas por sistemas de información computacionales, sean capaces de desarrollar dentro de ellas sistemas de información de calidad con la ayuda de una buena administración de proyectos de sistemas de información, hagan uso adecuado de la información y tengan una apertura hacia nuevas ideas y uso de nuevas tecnologías simplemente serán aplastadas por la tecnologías y por su misma ignorancia al cambio.

IMPORTANCIA DE LA GESTION DE PROYECTOS DE SISTEMAS DE INFORMACION.

Antes que nada debemos de definir que es administración y que es un proyecto: "Administración es el proceso de planear, organizar, dirigir y controlar el uso de recursos para lograr objetivos".

Otra definición es la de koontz "La administración es el proceso de diseñar y mantener un ambiente en el cual las personas, trabajando juntas en grupos, alcanzan con eficiencia metas seleccionadas".

Entonces podemos definir a la administración como el proceso de organizar, planear,

Dirigir y controlar; actividades y recursos con el fin de lograr un objetivo.

Ahora definimos que es un proyecto "un proyecto es una organización de gente dedicada a un propósito u objetivo específico".

Habiendo definido los conceptos de administración y de proyecto podemos decir que "La administración de proyectos es la aplicación del enfoque de sistemas para la administración de tareas tecnológicas complejas o de proyectos cuyos objetivos se establecen explícitamente en términos de tiempo, costos y parámetros de realización".

Después de haber visto la definición de administración de proyectos podemos dar nuestro punto de vista acerca de que es la administración de proyectos; La administración de proyectos es la forma de planear, organizar, dirigir y controlar una serie de actividades realizadas por un grupo de personas que tienen un objetivo específico; el cual puede ser (crear, diseñar, elaborar, mejorar, analizar, etc.) un problema o cosa.

MÉTODOS DEL DESARROLLO DE SISTEMA DE INFORMACIÓN

METODO ESPIRAL

Es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en mini-proyectos.

Cada mini proyecto se centra en uno o más riesgos importantes hasta que todos estén controlados.

Después de controlar todos los riesgos más importantes, el modelo en espiral finaliza del mismo modo que el ciclo de vida en cascada.

Método Desarrollo en Espiral

Funcionamiento:

Se parte de una escala pequeña en medio de la espiral, se localizan los riesgos, se genera un plan para manejar los riesgos, y a continuación se establece una aproximación a la siguiente interacción.

Cada iteración supone que el proyecto pasa a una escala superior. Se avanza un nivel en el Espiral, se comprueba que se tiene lo que se desea, y después se comienza a trabajar en el siguiente nivel:

Con cada iteración a través del espiral se construye sucesivas versiones de software cada vez más completas. En cada bucle alrededor del espiral, la culminación del análisis de riesgo resulta una decisión de “seguir” o “no seguir”.

Cada interacción en el método espiral lleva consigo los seis pasos que a continuación se nombran: Determinar objetivos, alternativas y límites, Identificar y resolver riesgos, Evaluar alternativas,

Generar las entregas de esa iteración, y comprobar que son correctas.

En el modelo en espiral, las primeras iteraciones son las menos costosas.

Supone menos gasto desarrollar el concepto de operación que realizar el desarrollo de los requerimientos, y también es menos costoso desarrollar los requerimientos que llevar a cabo el desarrollo del diseño, la implementación del producto y la prueba del mismo.

En cada Cuadrante del Método espiral se realiza las siguientes actividades:

Planificación:

Determinación de objetivos, alternativas, restricciones, y elaboración del plan de desarrollo para el ciclo actual.

Análisis de Riesgos:

Evaluación de las alternativas, identificación y resolución de riesgos. Se decide si se sigue o no con el proyecto

Ingeniería:

Desarrollo del producto siguiendo un modelo: del ciclo de vida o cascada, prototipo, etc. Evaluación por el cliente, Valoración de resultados.

Modelo iterativo incremental

Fig. 4 - Diagrama genérico del desarrollo evolutivo incremental.

Fig. 5 - Modelo iterativo incremental para el ciclo de vida del software,.

Un procesador de texto que sea desarrollado bajo el paradigma Incremental podría aportar, en principio, funciones básicas de edición de archivos y producción de documentos (algo como un editor simple). En un segundo incremento se le podría agregar edición más sofisticada, y de generación y mezcla de documentos. En un tercer incremento podría considerarse el agregado de funciones de corrección ortográfica, esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y ecuaciones matemáticas. Así sucesivamente hasta llegar al procesador final requerido. Así, el producto va creciendo, acercándose a su meta final, pero desde la entrega del primer incremento ya es útil y funcional para el cliente, el cual observa una respuesta rápida en cuanto a entrega temprana; sin notar que la fecha límite del proyecto puede no estar acotada ni tan definida, lo que da margen de operación y alivia presiones al equipo de desarrollo.

En términos generales, se puede distinguir, en la Figura 4, los pasos generales que sigue el proceso de desarrollo de un producto software. En el modelo de ciclo de vida seleccionado, se identifican claramente dichos pasos. La descripción del sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al producto global y final. Las actividades concurrentes (especificación, desarrollo y validación) sintetizan el desarrollo pormenorizado de los incrementos, que se hará posteriormente.

El diagrama de la Figura 4 muestra en forma muy esquemática, el funcionamiento de un ciclo iterativo incremental, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto final.⁶ Es decir, a medida que cada incremento definido llega a su etapa de operación y mantenimiento. Cada versión emitida incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron analizados como necesarios.

El incremental es un modelo de tipo evolutivo que está basado en varios ciclos Cascada Realimentados aplicados repetidamente, con una filosofía iterativa.¹⁰ En la Figura 5 se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener finalmente el esquema del modelo de ciclo de vida Iterativo Incremental, con sus actividades genéricas asociadas. Aquí se observa claramente cada ciclo cascada que es aplicado para la obtención de un incremento; estos últimos se van integrando para obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por simplicidad, en la Figura 5 se muestra como secuencial puro.

Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o concurrentemente, así por ejemplo, en la Figura, mientras se realiza el diseño detalle del primer incremento ya se está realizando en análisis del segundo. La Figura 5 es sólo esquemática, un incremento no necesariamente se iniciará durante la fase de diseño del anterior, puede ser posterior (incluso antes), en cualquier tiempo de la etapa previa. Cada incremento concluye con la actividad de «operación y mantenimiento» (indicada como «Operación» en la figura), que es donde se produce la entrega del producto parcial al cliente. El momento de inicio de cada incremento es dependiente de varios factores: tipo de sistema; independencia o dependencia entre incrementos (dos de ellos totalmente independientes pueden ser fácilmente iniciados al mismo tiempo si se dispone de personal suficiente); capacidad y cantidad de profesionales involucrados en el desarrollo; etc.

Bajo este modelo se entrega software «por partes funcionales más pequeñas», pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.⁶

Como se muestra en la Figura 5, se aplican secuencias Cascada en forma escalonada, mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y a menudo el primer incremento es un sistema básico, con muchas funciones suplementarias (conocidas o no) sin entregar.

El cliente utiliza inicialmente ese sistema básico, intertanto, el resultado de su uso y evaluación puede aportar al plan para el desarrollo del/los siguientes incrementos (o versiones). Además también aportan a ese plan otros factores, como lo es la priorización (mayor o menor urgencia en la necesidad de cada incremento en particular) y la dependencia entre incrementos (o independencia).

Luego de cada integración se entrega un producto con mayor funcionalidad que el previo. El proceso se repite hasta alcanzar el software final completo.

Siendo iterativo, con el modelo incremental se entrega un producto parcial pero completamente operacional en cada incremento, y no una parte que sea usada para reajustar los requerimientos (como si ocurre en el modelo de construcción de prototipos).¹⁰

El enfoque incremental resulta muy útil cuando se dispone de baja dotación de personal para el desarrollo; también si no hay disponible fecha límite del proyecto por lo que se entregan versiones incompletas pero que proporcionan al usuario funcionalidad básica (y cada vez mayor). También es un modelo útil a los fines de versiones de evaluación.

Nota: Puede ser considerado y útil, en cualquier momento o incremento incorporar temporalmente el paradigma MCP como complemento, teniendo así una mixtura de modelos que mejoran el esquema y desarrollo general.

Ejemplo:

Como se dijo, el Iterativo Incremental es un modelo del tipo evolutivo, es decir donde se permiten y esperan probables cambios en los requisitos en tiempo de desarrollo; se admite cierto margen para que el software pueda evolucionar⁹ . Aplicable cuando los requisitos son medianamente bien conocidos pero no son completamente estáticos y definidos, cuestión esa que si es indispensable para poder utilizar un modelo Cascada.

El modelo es aconsejable para el desarrollo de software en el cual se observe, en su etapa inicial de análisis, que posee áreas bastante bien definidas a cubrir, con suficiente independencia como para ser desarrolladas en etapas sucesivas. Tales áreas a cubrir suelen tener distintos grados de apremio por lo cual las mismas se deben priorizar en un análisis previo, es decir, definir cual será la primera, la segunda, y así sucesivamente; esto se conoce como «definición de los incrementos» con base en la priorización. Pueden no existir prioridades funcionales por parte del cliente, pero el desarrollador debe fijarlas de todos modos y con algún criterio, ya que basándose en ellas se desarrollarán y entregarán los distintos incrementos.

El hecho de que existan incrementos funcionales del software lleva inmediatamente a pensar en un esquema de desarrollo modular, por tanto este modelo facilita tal paradigma de diseño.

En resumen, un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del producto software denominados «incrementos» del sistema, que son escogidos según prioridades predefinidas de algún modo. El modelo permite una implementación con refinamientos sucesivos (ampliación o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión previamente implementada del producto software.

Este modelo brinda cierta flexibilidad para que durante el desarrollo se incluyan cambios en los requisitos por parte del usuario, un cambio de requisitos propuesto y aprobado puede analizarse e implementarse como un nuevo incremento o, eventualmente, podrá constituir una mejora/adecuación de uno ya planeado. Aunque si se produce un cambio de requisitos por parte del cliente que afecte incrementos previos ya terminados (detección/incorporación tardía) se debe evaluar la factibilidad y realizar un acuerdo con el cliente, ya que puede impactar fuertemente en los costos.

La selección de este modelo permite realizar entregas funcionales tempranas al cliente (lo cual es beneficioso tanto para él como para el grupo de desarrollo). Se priorizan las entregas de aquellos módulos o incrementos en que surja la necesidad operativa de hacerlo, por ejemplo para cargas previas de información, indispensable para los incrementos siguientes.¹⁰

El modelo iterativo incremental no obliga a especificar con precisión y detalle absolutamente todo lo que el sistema debe hacer, (y cómo), antes de ser construido (como el caso del cascada, con requisitos congelados). Sólo se hace en el incremento en desarrollo. Esto torna más manejable el proceso y reduce el impacto en los costos. Esto es así, porque en caso de alterar o rehacer los requisitos, solo afecta una parte del sistema. Aunque, lógicamente, esta situación se agrava si se presenta en estado avanzado, es decir en los últimos incrementos. En definitiva, el modelo facilita la incorporación de nuevos requisitos durante el desarrollo.

Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa funcionalidad parcial. También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software.

El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.

El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, o de alto índice de riesgos.

http://www.youtube.com/watch?v=0ve3CHxuMK0

Tendencia en la Ingeniera de Software

TENDENCIA EN LA INGENIERÍA DE SOFTWARE 

Especificación Orientada a Objetos

Esta investigación persigue como objetivo primordial el desarrollo de una metodología de análisis que combine las conceptos inherentes a la orientación a objetos con los métodos formales. Con ello pretendemos aprovechar el aspecto intuitivo de metodologías semiformales (OMT, FUSION, SYNTROPY) con el rigor de las técnicas formales (especificaciones algebraicas de datos y procesos).

Como primer paso en el desarrollo de esta metodología hemos diseñado el lenguaje de especificación TESORO, las principales características de este lenguaje son:

• La homogeneidad en el tratamiento de los aspectos estáticos y dinámicos del sistema
• La utilización de diversos tipos de restricciones, como método declarativo de descripción
• La definición de una semántica precisa para los operadores entre clases (asociación, agregación, relación y herencia)

Como siguiente paso, nos hemos marcado el desarrollo de herramientas de prototipado para nuestro lenguaje. En la actualidad está definido el proceso de prototipado hacia el lenguaje LOTOS, y está prevista la definición del mismo proceso para un lenguaje lógico (PROLOG) y para lenguajes imperativos (C++, JAVA).

Implementación de TESORO

Ya hemos trabajado en desarrollo de compiladores que transforman una especificación de un sistema realizada en TESORO en un prototipo en PROLOG o LOTOS. Desgraciadamente los prototipos que se obtienen al compilar TESORO a estos lenguajes no son lo suficientemente eficientes como para ser utilizados en aplicaciones prácticas.

En la actualidad se esta trabajando en un nuevo compilador que producirá código IP, un nuevo enfoque para la implementación de sistemas reactivos distribuidos que, al contrario de otros lenguajes similares, resulta también adecuado para realizar razonamiento formal, una propiedad realmente interesante si tratamos de compilar lenguajes de especificación como TESORO.

En la actualidad se está trabajando en mejoras del mecanismo de sincronización y comunicación entre procesos que presenta IP así como en la adaptación a entornos de tipo distribuidos de algunas de las técnicas tradicionales de resolución de restricciones.

Gestión de Proyectos

Desde 1991, con la publicación por parte de Abdel-Hamid y Madnick de un modelo dinámico para la gestión de proyectos de desarrollo de software, surge un campo de trabajo que está permitiendo una mayor comprensión de las diferentes variables a considerar y las complejas relaciones que se producen entra las mismas durante el proceso de desarrollo de software.

Actualmente, apoyándonos en el modelo de Abdel-Hamid y Madnick estamos atrabajando en dos áreas, por un lado profundizar en el análisis de los resultados de dicho modelo, y por otro lado hemos creado un modelo dinámico reducido que permita realizar estimaciones en etapas tempranas, cuando aún se tiene poca información sobre el proyecto.

Sistemas Multiagentes

Un agente es cualquier ente capaz de alcanzar unos objetivos prefijados interactuando con el entorno en el que se desarrolla y relacionándose con otros agentes para la consecución de dichos objetivos.

A partir de esta idea de agente, analizaremos los sistemas multiagente, contemplando:

• La creación y destrucción de agentes
• La interfaces existente entre ellos
• Los lenguajes que implementan estas características

Desde el punto de vista de la implementación, se estudia la teoría de agentes en red

Desarrollo de plataformas multiagente tomando como base el concepto de programación distribuida y las herramientas existentes que la implementan. Por último se analizan las tendencias que sobre el tema se van derivando en la actualidad.

Generación de prototipos

El uso de métodos formales dentro de la Ingeniería del Software no están centrados solamente en aspectos de especificación, podríamos aplicarlos también en la obtención de programas que resuelvan los problemas especificados.

De esta forma, el interés se centra en explotar los formalismos de especifición junto con mecanismos que automaticen la construcción de programas a partir de las especificaciones. Estos mecanismos de refinamiento nos permitirían no sólo obtener programas correctos sino también cubrir aspectos no funcionales (p.e. rendimiento).

Con este planteamiento, tareas de interés son:

• Soporte en la validación de especificaciones.
• Automatización en derivación de programas.
• Transformaciones horizontales: los programas se transforman en programas semánticamente equivalente usando un lenguaje común con vistas a mejorar el rendimiento.
• Transformaciones verticales: posibilidad de transformar programas en un lenguaje a programas en otro lenguaje preservando la semántica con multiples objetivos (rendimiento, portabilidad, etc).

Registrar diferentes versiones de una misma entidad: especificación y programas en diferentes estados de implementación (programas iniciales, programas finales más eficientes, etc). Aspectos necesarios como documentación de diseño en el desarrollo del software.

Enfoque de la Ingeniería dentro de la Informática

Enfoque de la Ingeniería dentro de la Informática

En la actualidad, son muchos los procesos de desarrollo de software que existen. Con el pasar de los años, la Ingeniería de Software ha introducido y popularizado una serie de estándares para medir y certificar la calidad, tanto del sistema a desarrollar, como del proceso de desarrollo en sí. Se han publicado muchos libros y artículos relacionados con este tema, con el modelado de procesos del negocio y la reingeniería. Un número creciente de herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso de desarrollo de software efectivo. Hoy en día la economía global depende más de sistemas automatizados que en épocas pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva década de procesos y estándares de calidad.

Sin embargo, ¿cómo explicamos la alta incidencia de fallos en los proyectos de software? ¿Por qué existen tantos proyectos de software víctimas de retrasos, presupuestos sobregirados y con problemas de calidad? ¿Cómo podemos tener una producción o una economía de calidad, cuando nuestras actividades diarias dependen de la calidad del sistema?

Tal vez suene ilógico pero, a pesar de los avances que ha dado la tecnología, aún existen procesos de producción informales, parciales y en algunos casos no confiables.

La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas.

La razón principal para escoger este tema se fundamentó en la gran cantidad de proyectos de software que no llegan a cumplir sus objetivos. En nuestro país somos partícipes de este problema a diario, en donde se ha vuelto común la compra de sistemas extranjeros, para luego “personalizarlos” supuestamente a la medida de las empresas.

Tal “personalización”, la mayoría de las veces, termina retrasando el proyecto en meses, o incluso en años. La problemática del año 2000 trajo como consecuencia una serie de cambios apresurados en los sistemas existentes; cambios que, desde mi punto de vista, no fueron bien planificados.

El reemplazo de plataformas y tecnologías obsoletas, la compra de sistemas completamente nuevos, las modificaciones de todos o de casi todos los programas que forman un sistema, entre otras razones, llevan a desarrollar proyectos en calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que se omitan muchos pasos importantes en el ciclo de vida de desarrollo, entre estos, la definición de los requerimientos.

Estudios realizados muestran que más del 53% de los proyectos de software fracasan por no realizar un estudio previo de requisitos. Otros factores como falta de participación del usuario, requerimientos incompletos y el cambio a los requerimientos, también ocupan sitiales altos en los motivos de fracasos.

Con este trabajo se pretende alcanzar los siguientes objetivos:

•  Resaltar la importancia que tiene la Ingeniería de Requerimientos dentro del ciclo de desarrollo.

•  Dar a conocer las diferentes alternativas que existen para identificar requerimientos.

•  Ayudar a comprender la diferencia que existe entre las diferentes técnicas utilizadas en la IR.

•  Minimizar las dudas que se tiene sobre los casos de uso.

•  Mostrar la utilización de herramientas CASE dentro de la administración de requisitos.

CAPAS DE LA ING. DE SOFTWARE

La ingeniería de software es una tecnología multicapa, cualquier enfoque de ingeniería debe apoyarse sobre un compromiso de organización de calidad.

 El fundamento de la ingeniería de software es la capa del proceso. el proceso de ingeniería de software es la unión que mantiene juntas las capas dela tecnología y que permiten un desarrollo racional y oportuno de la ingeniería de software.

El proceso de fine un marco de trabajo para un conjunto de áreas clave de proceso que deben establecer para la entrega de la tecnología de la ingeniería de software. Los métodos de la ingeniería de software indican como construir técnicamente el software. Los métodos abarcan una gama de tareas que influyen análisis de requisito, diseño, construcción de programas, pruebas y mantenimiento.

La ingeniería de software se divide en 4 capas que son:

HERRAMIENTAS: proporciona un enfoque automático o semiautomático para el proceso y para los métodos  cuando se integran herramientas para la información creada por una herramienta la puede utilizar otra, se establece un sistema de soporte para el desarrollo de software llamado Ingeniería de Software asistida por computadora.

MÉTODO: Los métodos de la ingeniería de software indican como se debe construir técnicamente el software. abarcan una gran gama de tareas, que incluyen:

- Análisis de requisitos.

- Diseño

- Construcción de programas

- Pruebas

- Mantenimiento.

Dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades del modelado. otras técnicas descriptivas.

PROCESO: Define un marco del trabajo para un conjunto de áreas claves de proceso que se deben establecer para la entrega efectiva de la tecnología de la ingeniería de software. las áreas claves forman la base del control del proyecto.

MODELOS DE DESARROLLO DE SOFTWARE

La ingeniería de software tiene varios modelos, paradigmas o filosofías de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos:

• Desarrollo en cascada

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos

2. Diseño del Sistema

3. Diseño del Programa

4. Codificación

5. Pruebas

6. Implantación

7. Mantenimiento

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.

• Desarrollo en espiral

  

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1988, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

La Ingeniería de software, se vale y establece a partir de una serie de modelos que establecen y muestran las distintas etapas y estados por lo que pasa un producto software, desde su concepción inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les denomina «modelos de ciclo de vida del software». El primer modelo concebido fue el de Royce, más comunmente conocido como desarrollo en cascada o desarrollo lineal secuencial. Este modelo establece que las diversas actividades que se van realizando al desarrollar un producto software se suceden de forma lineal.

• Desarrollo por etapas 

El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código.

Pueden distinguirse las siguientes fases:Especificación conceptualAnálisis de requerimientosDiseño inicialDiseño detallado, codificación, depuración y liberaciónEstas diferentes fases se van repitiendo en cada etapa del diseño.Desarrollo iterativo y crecienteDesarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada.

Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de los cuales los dos más famosos son el Rational Unified Process y el Dynamic Systems Development Method. El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworks de desarrollo rápido de software.

• Ciclo de vida

La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior, incrementando, versiones entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso (mientras sea posible). Los pasos claves en el proceso son comenzar con una implementación simple de los requerimientos del sistema, e iterativa mente mejorar la secuencia evolutiva de versiones hasta que el sistema completo esté implementado. En cada interacción  se realizan cambios en el diseño y se agregan nuevas funcionalidades y capacidades al sistema.

• Desarrollo rápido de aplicaciones

  

El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering).

Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas son Visual Studio, Delphi, Foxpro o Anjuta.

EL MODELO DE DESARROLLO CONCURRENTE

Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.

Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, de la siguiente forma:

Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. Por ejemplo,...el personal esta escribiendo requisitos diseñando, codificando, haciendo pruebas y probando la integración (todo al mismo tiempo). Los modelos de proceso de ingeniería del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase.

El trabajo más reciente de Kellner utiliza diagramas de estado para representar la relación concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestión del software en mi proyecto...La mayoría de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto más tarde sea, mas atrás se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) esta dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.

El Proceso Unificado de Rational

El Proceso Unificado de Racional (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.

• Proceso Unificado

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

EL SOFTWARE COMO PRODUCTO

Hoy en día el software tiene un doble papel. Es un producto, al mismo tiempo, un vehículo para entregarlo.

Como producto, hace entrega de la potencia que incorpora el hardware informativo, o más ampliamente, una red de computadoras que es accesible por hardware local. Si reside dentro de un teléfono celular o opera dentro de una computadora central, el software es un transformador de información, produciendo, gestionando, modificando, mostrando, adquiriendo o transmitiendo información que puede ser tan simple como un solo bit, o tan complejo como una presentación en multimedia. Como vehículo utilizado para hacer entrega del producto, el software actúa como la base de control de la computadora (sistemas operativos), la comunicación de información (redes) y la creación y control de otros programas (herramientas de software y entornos).La sostificacion y la complejidad pueden producir resultados deslumbrantes cuando un sistema tiene éxito, pero también pueden suponer grandes problemas para aquellos que deben construir sistemas complejos.

EL SOFTWARE COMO PROCESO

Construir software de computadora es un proceso de aprendizaje iterativo, y el resultado, algo que Baetjer podría llamar “capital de software”, es el conjunto de software reunido, depurado y organizado mientras se desarrolla el proceso.Pero, ¿Qué es exactamente el proceso del software desde un punto de vista técnico? Un proceso de software como un marco de trabajo de las tareas que se requieren para construir software de calidad. ¿Es “proceso” sinónimo de ingeniería de software? La respuesta es sí y no. Un proceso de software define el enfoque que se toma cuando el software es tratado por la ingeniería.Pero la ingeniería de software también comprende las tecnologías que tienen el proceso, métodos técnicos y herramientas automatizadas.Aun más importante es que la ingeniería de software la realizan personas creativas, con conocimiento, que deberían trabajar dentro de un proceso del software definido y avanzado que es apropiado para los productos que construyan y para las demandas de su mercado.

Marco de trabajo

DefiniciónSerie de tareas relacionadas que produce un producto de trabajo en la ingeniería de software .

Actividades del marco de trabajo

Comunicación : intensa colaboración y comunicacion de los clientes. Incluye la investigacion de requisitos.

Planeación: Establece un plan de trabajo de ingeniería de software incluye tareas tecnicas, riesgos y recursos.

Modelado: Creacón de modelos que permiten al desarrollador y al clente entender mejor los requisitos del software.

Construcción: Combina la generación de código y realizacion de pruebas necesarias para descubrir errores.

Despliegue: Al entregar el software al clente este lo evalua y proporciona información a partir de su evaluación.

Actividades Sombrias: Se aplican durante el proceso de software.entre ellas estan:Seguimiento y control del proyecto de software,Gestón de riesgo,Aseguramiento de la calidad del software,Medición,Gestión de configuración,Gestión de reteutilización.