Unidad I

Fundamentos de ingeniera de Software
Unidad I Fundamentos de Ingeniera de software

1.1 Conceptos bsicos 1.1.1 Software Es una palabra que proviene del idioma ingls, pero que gracias a la masificacin de uso, ha sido aceptada por la Real Academia Espaola. Segn la RAE, el software es un conjunto de programas, instrucciones y reglas informticas que permiten ejecutar distintas tareas en una computadora. Se considera que el software es el equipamiento lgico e intangible de un ordenador. En otras palabras, el concepto de software abarca a todas las aplicaciones informticas, como los procesadores de textos, las planillas de clculo y los editores de imgenes El software es desarrollado mediante distintos lenguajes de programacin, que permiten controlar el comportamiento de una mquina. Estos lenguajes consisten en un conjunto de smbolos y reglas sintcticas y semnticas, que definen el significado de sus elementos y expresiones. Un lenguaje de programacin permite a los programadores. 1.1.1.1 Caractersticas Algunas caractersticas del SW que dificultan su administracin y desarrollo son: El SW se desarrolla (no se fabrica en el sentido convencional). Por lo que el costo del SW est en la ingeniera, no en la produccin. El SW no se estropea (si el SW falla, no puede ser cambiado por uno igual, pero "nuevo"). Las fallas en el SW se detectan durante la prueba y puesta en operacin y una vez solucionadas, permiten tener un perodo estable, mismo que termina cuando se le da mantenimiento al SW y se presentan los efectos laterales y/o secundarios o cuando se hace evidente un error oculto hasta ese momento. Generalmente el SW se construye a la medida, con un ndice muy reducido de reus o ensamble de componentes, salvo en la interfaz (normalmente se utiliza la del ambiente de desarrollo y/o la del sistema operativo).
1.1.1.2 Aplicaciones de Software Software de sistemas: conjunto de programas que sirve a otro software. Tiene una fuerte interaccin con el hardware y en general, programacin de bajo nivel, con requerimientos de alta confiabilidad.
Instituto Tecnolgico de Chihuahua II
Software de tiempo real: se utiliza para medir, analizar y controlar sucesos del mundo real en la medida que estos ocurren. Requiere de una etapa de adquisicin de datos, en la que bsicamente se les cambia de formato, tiene un sistema de control y otro de monitoreo; todo lo anterior en un entorno de respuesta rpida. Software de gestin: procesamiento de informacin. Software de ingeniera y/o cientfico: algoritmos para manejar nmeros, diseo asistido por computadora, simulacin, etc. Software empotrado en memoria de "solo lectura", para el control de productos y/o sistemas de control domstico. Software de PC: procesador de textos, hojas de clculo, etc. Software de IA: algoritmos no numricos. Destacan entre estos sistemas, las redes neuronales, la lgica difusa y los sistema expertos.
Sin embargo, desde la perspectiva del desarrollador, es til simplificar el esquema de clasificacin en las tres categoras bsicas siguientes:
Software del sistema (sistema operativo). Software de utilera (editores, compactadores, etctera). Software de aplicacin (sistemas de informacin, nminas, contabilidades, inventarios, etctera).
Las que se distinguen entre s por el grado de complejidad que sugiere su desarrollo e implementacin. 1.1.2 Ingeniera La ingeniera es el estudio y la aplicacin de las distintas ramas de la tecnologa. El profesional en este mbito recibe el nombre de ingeniero. La actividad del ingeniero supone la concrecin de una idea en la realidad. Esto quiere decir que, a travs de tcnicas, diseos y modelos, y con el conocimiento proveniente de las ciencias, la ingeniera puede resolver problemas y satisfacer necesidades humanas. La ingeniera tambin supone la aplicacin de la inventiva y del ingenio para desarrollar una cierta actividad. Esto, por supuesto, no implica que no se utilice el mtodo cientfico para llevar a cabo los planes. Entre las distintas tareas que puede llevar a cabo un ingeniero, se encuentra:
La investigacin (la bsqueda de nuevas tcnicas) El diseo El desarrollo La produccin La construccin
La operacin.
1.1.3 Ingeniera de software Ingeniera del Software es la aplicacin prctica del conocimiento cientfico en el diseo y construccin de programas de computadora y la documentacin asociada requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce tambin como desarrollo de software o produccin de software [BOE81] La IEEE seala: "Ingeniera del software es el enfoque sistemtico para el desarrollo, operacin, mantenimiento y eliminacin de SW". Mientras que "Software es el conjunto de aquellos programas, procedimientos, reglas y documentacin posible asociada con la computacin, as como los datos pertenecientes a la operacin de un sistema de cmputo".
Cul es la diferencia entre ingeniera de software e ingeniera de sistemas? La ingeniera de sistemas se refiere a todos los aspectos del desarrollo de sistemas basados en computadora, incluyendo hardware, software e ingeniera de procesos. La ingeniera de software es parte de este proceso. El proceso de software Son el conjunto de actividades y resultados asociados que producen un producto de software. Existen cuatro actividades principales: 1. Especificacin del software: la funcionabilidad del software y las restricciones sobre su operacin deben quedar definidas 2. Desarrollo de software: debe producirse software que cumpla con la especificacin. 3. Validacin del software: el software debe validarse para asegurar que es lo que se requiere 4. Evolucin del software: el software debe evolucionar para cumplir con los cambios requeridos por el cliente
Cules son los costos de la ingeniera de software? Agrandes rasgos, el 60% de los costos son de desarrollo, el 40% restante son pruebas. En el caso del software personalizado, los costos de evolucin a menudo exceden los de desarrollo
Qu son los mtodos de Ingeniera de Software? Enfoques estructurados para el desarrollo de software que incluye: Descripciones del modelo, descripciones de modelos grficos que deben ser producidos Reglas, restricciones aplicadas a los modelos de sistemas Recomendaciones, para realizar un diseo efectivo Administracin del proceso, que actividades deben realizarse y en qu orden
Cules son los atributos del software de calidad? El software debe proveer la funcionalidad y desempeo requeridos por el usuario y debe ser: Mantenible, el software debe poder evolucionar para continuar cumpliendo con las especificaciones Confiable, el software no debe causar daos fsicoso econmicos en el caso de que falle Eficiente, el software no debe desperdiciar los recursos del sistema Aceptable, el software debe ser aceptado por los usuarios para los que fue diseado. Debe ser entendible, utilizable y compatible con otros sistemas
1.1.4 Crisis del Software La Crisis del Software ha generado fallas en los sistemas que se estn produciendo, debido a problemas de comunicaciones, elevados costos del producir y dar mantenimiento al software Una proporcin muy grande de productos de software se envan tarde, excedidos en presupuesto y con fallas de ltimo momento. Segn Johnson, Boucher, Connors y Robinson [2000]:
23% 49%
Cancelados Exitosos
28%
Tarde, presupuesto excedido o con fallos
Figura 1.1.1 Porcentajes de proyectos de software
Como consecuencia: 78% de las compaas de TI han entrado en disputas 67% de los casos el software entregado no cubri lo ofrecido 56% se entregaron despus de la fecha prometida 45% Tenan fallas operativas crticas que impedan su utilizacin
1.1.5 Problemas relacionados con el desarrollo de software: Sistemas que no cumplen los requerimientos de los usuarios y/o tienen fallas tcnicas. Generalmente, los sistemas no estn actualizados ni cundo se estn diseando. An existe el error de la computadora como excusa a un mal servicio a los clientes. La mayora de los usuarios esperan sistema se caiga o congele de vez en cuando (software de aplicacin y/o SO). El software no siempre es utilizable, til, confiable o disponible La falta de flexibilidad tambin resulta evidente, como lo muestran el problema del milenio y la adecuacin de todos los sistemas viejos (legacy) a procesos de negocios cambiantes. La COSTEABILIDAD se relaciona mucho con la confiabilidad y la flexibilidad debido a que el costo de corregir y mantener es el ms alto costo asociado con el software
1.1.5.1 Costos del Software El mito del Hombre-Mes hace creer que basta con agregar personal a un proyecto de software para acelerar su terminacin. Puede resultar muy costoso agregar dicho personal. La curva de aprendizaje y los costos de introduccin de nuevas tecnologas de software, impiden obtener resultados inmediatos. Los costos a largo plazo en el mantenimiento del software al usar tcnicas incorrectas, puede resultar ms grande que su costo de adquisicin
1.1.5.2 Mantenimiento del Software
El mantenimiento pos entrega del software son todos los cambios al producto una vez que se ha entregado e instalado en la computadora del cliente y pasa su prueba de aceptacin. Categoras de mantenimiento de software: Correcciones: Eliminar las fallas de ltimo momento dejando sin cambio las especificaciones Perfeccionamiento: Cambios que mejorarn la eficacia del producto, como funcionalidad adicional o menor tiempo de respuesta. Adaptaciones: Cambios en respuesta a los cambios en el entorno en el que opera el producto (SO, HDW, Regulaciones)
1.1.5.3 Costo del Mantenimiento del Software
De acuerdo a Yourdon y Hatton (1998):
25% 75%
Desarrollo Mantenimiento pos entrega
Figura 1.1.2 Porcentaje de costo de mantenimiento del software
1.1.5.5 Problemas de comunicacin
Cualquier mejora en la forma de dar mantenimiento al Software tendr una incidencia positiva directa en los gastos de las compaas en software El costo relativo para detectar y corregir una falla en la etapa de mantenimiento pos entrega es de 5 a 10 veces ms grande que en las etapas iniciales del ciclo de desarrollo de software
La dificultad en el desarrollo de un proyecto de software no radica en lo tcnico si no en lo sociolgico, y ms concretamente en la comunicacin. La mayor parte de los proyectos de software que fracasan lo hacen por cuestiones de comunicacin. Voy a poner un ejemplo sacado de " The Mythical Man-month", Por qu fall la construccin de la Torre de Babel? Analicemos el problema. Tenan unos requisitos concretos y claros. Su objetivo era crear una torre para llegar al cielo. No deja de ser una idea un estpida pero la idea era clara. Tenan suficiente mano de obra. Parece ser que mucha gente estaba dispuesta a trabajar en ello. Tenan suficientes materiales. Bueno, no se nos dice lo contrario as que parece que s.
Figura 1.1.3 torre de babel
Tiempo. No tenan restricciones de tiempo. Tecnologa adecuada. Parece que empezaron con una torre cnica, as que en principio no era mala idea, adems el proyecto fall antes de que llegasen a limitaciones tcnicas
Con todo esto parece ser que el proyecto iba para adelante a buen ritmo, pero a Dios no le gustaba la idea de que hicieran una torre que llegara al cielo, as que hizo que cada uno de ellos hablase un idioma distinto. Hablando cada uno un idioma diferente no se podan comunicar los unos con los otros, como consecuencia de esto se cre una completa desorganizacin y el proyecto fracas.
Por eso una de las ms importantes tareas del director de equipo y del gestor del proyecto es que la informacin fluya en todas las direcciones. No solo que la comunicacin se produzca de arriba hacia abajo si no, que tambin se produzca de abajo hacia arriba. Es muy frecuente que los programadores identifiquen problemas o indicios de problemas que ms tarde pueden revelarse como crticos. Una correcta gestin de la informacin puede provocar que los incipientes problemas se solucionen antes de que estos se conviertan en decisivos y tengamos que lamentarnos por ello. Por eso si ests a cargo de una serie de programadores debes estar muy atento a los problemas que te planteen. No debes cerrar los ojos ante ellos o ignorarlos porque no los consideras importantes. Hay que tener mucho cuidado antes de desechar un problema porque piensas que no es importante, una de las razones que por la cual la informacin no fluye correctamente es porque alguien en la cadena de la informacin desestim errneamente un problema. Un actitud tpica es el sndrome "No-problem" cuando uno est afectado por este sndrome tiende a desestimar los problemas, normalmente porque no lo ha escuchado o le da mucha pereza el esfuerzo necesario para entenderlo. Si quieres saber si alguien o t mismo ests afectado por el sndrome del "No-problem" has la siguiente prueba: 1. Plantea un problema complicado. 2. Tu interlocutor te responde "No problem !!" 3. Dile que te describa el problema que le acabas de plantear. En este punto hay dos opciones: a) Si te describe el problema, aunque sea errneamente, no est afectado por el sndrome del "No-problem". Solo es un optimista. b) Si directamente te da una supuesta solucin a lo que ests planteando, entonces ests perdido, est afectado. El sndrome del "No-problem" est directamente relacionado con la capacidad de escuchar. Lamentablemente tambin se produce el fenmeno que cuanto ms alto se est en la jerarqua menos se escuchan los problemas y ms frecuente es el sndrome del "No-problem". Recuerda esto para cuando ests arriba, escucha los problemas de los dems. Una vez preparado para escuchar debes fomentar la comunicacin del grupo, piensa que cada miembro del equipo es una fuente de informacin. Los miembros del grupo no son iguales, unos son ms expertos en una cosa y otros en otra.
Dedica tiempo a todos los miembros del equipo, escchalos a todos y no dejes aislado a nadie, fomenta la participacin, de esta forma consigues que se sientan responsables de parte del proyecto porque algunas de sus ideas suyas son aceptadas. Se generoso con esto, se muy generoso, es muy fcil y se obtiene grandes recompensas en cuanto a participacin, haz saber a todos que la idea ha sido de esta persona o de aquella, eso la motivar para que participe mucho ms, porque ests alimentando su ego dndole el reconocimiento dentro del grupo. Por otra parte, tambin tienen entender que no todas sus ideas van a ser adoptadas o que no es el momento adecuado para ellas. Desde el punto de vista del director de equipo es muy importante tener claro que no siempre lo mejor es lo mejor, quiero decir, que a veces hay que ceder o adoptar una idea aunque sepas que no es la mejor, pero con ello consigues que alguien obtenga reconocimiento, eso es bueno para el equipo. Si el equipo funciona el proyecto saldr adelante. [GAR04]
Figura 1.1.4 Problemas de comunicacin en el desarrollo de software
1.2 El papel evolutivo del software En este contexto, es interesante analizar cmo han evolucionado los procesos de produccin del software. La Tabla 1.1, ubica tal evolucin, sealando las premisas fundamentales en las que se ha sustentado cada etapa; en cada una de ellas se describen las principales caractersticas del correspondiente proceso de desarrollo.
Al principio Qu funcione! Se obtiene el resultado deseado. Se procede con imaginacin, ingenio, creatividad, etc. Despus del principio...
Qu funcione y que est bien construido! Obtener el resultado deseado (eficacia).
Se procede con imaginacin, ingenio, creatividad, etc. Se aplican tcnicas para el anlisis, el diseo y la construccin; por ejemplo, el diseo modular y la programacin estructurada. Ahora... (ayer?) Qu funcione, que est bien construido y que represente interna y externamente- de manera fiel a la realidad. Obtener el resultado deseado (eficacia). Se procede con imaginacin, ingenio, creatividad, etc. Se aplican tcnicas para el anlisis, el diseo y la construccin; por ejemplo, el diseo modular y la programacin estructurada. Concepto de "modelo objeto" Maana...(hoy?) Qu funcione, que est bien construido, que represente interna y externamente- de manera fiel a la realidad., que sea fcil de construir y de mantener evolucionar-. Obtener el resultado deseado (eficacia). Se procede con imaginacin, ingenio, creatividad, etc. Se aplican tcnicas para el anlisis, el diseo y la construccin; por ejemplo, el diseo modular efectivo y la programacin estructurada. Concepto de "modelo objeto" Reus, CASE. Hoy...(hoy?) Qu funcione, que est bien construido, que represente interna y externamente- de manera fiel a la realidad., que sea fcil de construir y de mantener evolucionar-, que tenga el reconocimiento de terceros. Obtener el resultado deseado (eficacia). Se procede con imaginacin, ingenio, creatividad, etc. Se aplican tcnicas para el anlisis, el diseo y la construccin; por ejemplo, el diseo modular efectivo y la programacin estructurada. Concepto de "modelo objeto" Reus, CASE. CMM, ISO, Moprosoft, etc.
Tabla 1.2.1. Evolucin de los procesos de produccin del SW.
La evolucin del SW ha sido regulada por la evolucin en el HW. Es un hecho irrefutable saber que las capacidades de HW no son explotadas totalmente por el SW, y esto es, a fin de cuentas una ventaja: Qu sucedera en el caso contrario? Lo que ha hecho la ingeniera del software, es sistematizar los procesos de produccin y mantenimiento del software, partiendo del reconocimiento de un
proceso genrico, que el autor denomina Proceso bsico de solucin de problemas utilizando un sistema computacional. Este proceso se compone de las siguientes etapas: Definicin del problema (anlisis preliminar). Establecimiento de fronteras, alcances y/o responsabilidades. Abstraccin (anlisis detallado). Deteccin de las caractersticas fundamentales del dominio del problema. Modelacin (diseo). Especificacin de un modelo esttico de la realidad. Animacin y/o simulacin (construccin). Construccin mecanismos necesarios que soporten la dinmica del sistema. de los
La Figura 1.2.1 describe el proceso bsico, a la vez que introduce la relacin proceso-producto en la ingeniera de software.
Figura 1.2.1. Proceso bsico
Es posible advertir dos caractersticas en este proceso de solucin de problemas: Independencia de la naturaleza del problema. Independencia de la tecnologa de implementacin y/o desarrollo que est disponible.
Estas caractersticas hacen que tenga una aplicacin general.
1.3 Etapas del desarrollo de software
El proceso de desarrollo de software contiene tres fases genricas, independientemente del paradigma de ingeniera elegido. Las tres fases, definicin, desarrollo, y mantenimiento, se encuentran en todos los desarrollos de software independientemente del rea de aplicacin, del tamao del proyecto o de la complejidad.
Figura. El Proceso como Solucin de Problemas
1.3.1 Fase de definicin del Software La fase de definicin se centra sobre el qu. Esto es, durante la definicin, el que desarrolla el software intenta identificar qu informacin debe ser proporcionada, qu funcin y rendimiento se desea, qu interfaces deben establecerse, qu restricciones de diseo existen y qu criterios de validacin se necesitan para definir un sistema correcto. Aunque los mtodos aplicados durante la fase de definicin variarn dependiendo del paradigma de ingeniera del software aplicado, de alguna forma se producirn tres pasos especficos: Anlisis del sistema: Define el papel de cada elemento del sistema informtico, asignando finalmente al software el papel que va a desempear. Planificacin del proyecto de software: Una vez establecido el mbito del software, se analizan los riesgos, se asignan los recursos, se estiman los costos, se definen las tareas y se planifica el trabajo. Anlisis de Requerimientos: El mbito establecido para el software proporciona la direccin a seguir, pero antes de comenzar a trabajar es necesario disponer de una informacin ms detallada del mbito de informacin y de funcin del software.
1.3.2 Fase de desarrollo del Software La fase de desarrollo se centra en el cmo. Esto es, durante esta fase. El que desarrolla el software intenta descubrir cmo han de disearse las estructuras
de datos y la arquitectura del software, cmo han de implementarse los detalles procedimentales, cmo ha de traducirse el diseo a un lenguaje de programacin y cmo ha de realizarse la prueba. Los mtodos aplicados durante la fase de desarrollo varan, pero de alguna forma se aplicarn tres pasos concretos: Diseo de software: El diseo traduce los requisitos de software a un conjunto de representaciones (algunas grficas y otras tabulares o basadas en lenguajes) que describen las estructuras de bases de datos, la arquitectura, el procedimiento algortmico y las caractersticas de la interfaz. Codificacin: Las representaciones del diseo debern ser traducidas a un lenguaje artificial (un lenguaje de programacin convencional o un lenguaje 1 no procedimental T4G ), dando como resultado unas instrucciones ejecutables en la computadora. Prueba del software: Una vez que el software ha sido implementado en una forma ejecutable por la mquina, debe ser probado para descubrir los defectos que puedan existir, en la funcin, en la lgica y en la implementacin.
1.3.3 Fase de mantenimiento del Software La fase de mantenimiento se centra en el cambio que va asociado a la correccin de errores, a las adaptaciones requeridas por la evolucin del entorno del software y a las modificaciones debidas a los cambios de requisitos del usuario dirigidos a reforzar o ampliar el sistema. La fase de mantenimiento vuelve a aplicar las fases de definicin y de desarrollo, pero en el contexto del software ya existente. Durante la fase de desarrollo se encuentran tres tipos de cambio: Correccin: Incluso llevando a cabo las mejores actividades de garanta de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos. Adaptacin: Con el paso del tiempo es probable que cambie el entorno original (sistemas operativos, equipos perifricos, etc.) para los que se desarroll el software. El mantenimiento adaptivo consiste en modificar el software para acomodarlo a los cambios de su entorno externo. Mejora: Conforme utilice el software, el usuario puede descubrir funciones adicionales que podran interesar que estuvieran incorporadas en el software. El mantenimiento perfectivo amplia el software ms all de sus requisitos funcionales originales.
1.4. Clasificacin de la tecnologa en el desarrollo de software (Tecnologa Estructurada y Orientada a Objetos) 1.4.1 Desarrollo Estructuradas
El desarrollo de las tcnicas estructuradas se puede considerar un punto de partida en el que se pasa de la construccin de programas de manera artesanal a una que sigue unos mtodos de ingeniara. Estas tcnicas estn dirigidas a aspectos tanto tcnicos como de gestin en la construccin de software. Programacin estructurada: En el enfoque de desarrollo estructurado comenz con la programacin, para determinar cmo se deba ver un programa tanto de forma esttica como dinmica, de forma que fuera lo ms comprensible.
Diseo estructurado: En los 70s el enfoque estructurado se extiende al diseo, en este se define el nivel de abstraccin, utilizando el mdulo de programa como componente bsico de la construccin. (Modularidad, normalizacin de mdulos de programas y restringiendo las relacione). Anlisis Estructurado: En este se los proyectos se hacan una especificacin narrativa de los requisitos, tal como los perciba el analista, estas especificaciones estaban afectadas por diversas problemticas: A) Eran monolticas: haba que leer la especificacin de requisitos completamente para poder entenderla B) Eran redundantes: frecuentemente se repeta la informacin en partes diferentes del documento, esto implicaba que s si cambiaba algn requisito del usuario, se deba modificar en varios lugares del documento para eviar inconsistencias C) Eran ambiguas: Un informe detallado de los requisitos se interpretaba de formas diferentes por usuarios, analistas y diseadores D) Imposible de mantener: cuando se llegaba al final del proceso de desarrollo, la especificacin funcional era casi obsoleta.
Las metodologas estructuradas proponen la creacin de modelos de sistemas que representen los procesos, los flujos y la estructura de los datos de una manera descendente (top-down). Esta visin, se puede enfocar a las funciones(o proceso) del sistema, en la estructura de los datos, o en ambos aspectos, dando lugar los siguientes tipos de metodologas: Metodologas Orientadas al proceso: Se basa en el modelo entrada/proceso/salida de un sistema. Los datos se introducen en el sistema y el sistema responde ante ellos, transformndolos para obtener una salida.
Una es pesificacin estructurada es un modelo grfico, particionado, descendente y jerrquico de los procesos del sistema y de los datos utilizados por el proceso. Se compone de: Diagramas de flujo: representan los procesos que debe llevar a cabo un sistema a distintos niveles de abstraccin y los datos que fluyen entre las funciones. Los procesos ms complejos se descomponen en nuevos diagramas hasta llegar a procesos ms simples.(empleada en el anlisis y diseo) Diccionario de datos: Es el conjunto de las definiciones de todos los datos que aparecen en el diagrama de flujo de datos, tanto almacenados como en los flujos. Especificaciones de procesos: describe con ms detalle lo que ocurre dentro de un proceso, es decir, define como se obtienen las salidas del proceso a partir de sus entradas. de Marco, de Gane/Sarson, y la de
Ejemplos son: la metodologa Yourdon/Constantine
Metodologas Orientadas a datos jerrquicos: Dentro del modelo bsico entrada/proceso/salida de un sistema, estas se orientan ms a la E/S. Primero definen las estructuras de datos y, a partir de estas, se derivan los componentes procedimentales. En este enfoque es destacable: La estructura de control del programa debe ser jerrquica y se debe derivar de la estructura del programa. El proceso de diseo consiste en definir primero las estructuras de datos de E/S, mezclarlas todas en una estructura jerrquica de programa y despus
ordenar detalladamente la lgica procedimental para que se ajuste a esta estructura El diseo lgico de be preceder y estar separado del diseo fsico.
Ejemplos: mtodos JSP y JSD de Jackson/Cameron, la construccin lgica de programas (LCP) de Warnier y el desarrollo de sistemas estructurados da datos (LCS) Metodologas Orientadas a datos no jerrquicos: Esta se centra en la creencia de que los datos (tipos) son el corazn del sistema de informacin, ya que son ms estables que los procesos que actan sobre ellos La metodologa queda dividida en cuatro etapas, con los siguientes objetivos: Planeacin: construir una arquitectura de la informacin y una estrategia que soporte los objetivos de la organizacin. Anlisis: Comprender la reas del negocio y determinar los requerimientos del sistema Diseo: establecer el comportamiento del sistema deseado por el usuario yque sea alcanzable por la tecnologa Construccin: construir el sistema que cumplan los tres niveles anteriores
Ejemplo: la metodologa ingeniera de la informacin de Martin y Finkelstein
1.4.2 Orientadas a Objetos
Las tecnologas de desarrollo estructurado han de mostrado sus limitaciones a la hora de organizar y facilitar la evolucin de sistemas de software complejos. La descomposicin en funciones hace difcil al diseador mantener la relacin con los objetos del mundo real sobre los que se modifican generalmente los requisitos del usuario. Los mtodos de descomposicin orientada a objetos constituyen la tendencia ms influyente observada en la ingeniera de sistemas de software en los ltimos aos. Con ellos nos referimos a un conjunto de mtodos (an en fase de desarrollo o evolucin) que permiten al analista y diseador concebir su sistema identificando clases de objetos, operaciones permitidas y relaciones entre ellos como base para la estructura del sistema a disear. En ellas, un objeto es un conjunto de datos y funciones de manipulacin de los mismos encapsulados en una unidad que es posible tratar como un todo (crear, copiar, destruir, etc.). Un objeto posee unas operaciones visibles a otros objetos aunque stos no conocen cmo estn implementadas. El diseador reconoce inicialmente clases de objetos de las que se derivan los objetos concretos que utilizar en el diseo. Un objeto puede construirse jerrquicamente empleando, a su vez, a otros objetos ms simples. Una clase implica una generalizacin del concepto de objeto (identificando similitudes entre objetos similares)y constituye la base a partir de las cuales se construye el sistema. Existen varias tecnologas orientadas a objetos que, aunque similares en su potencia expresiva, ofrecen algunas diferencias que las hacen ms adecuadas para algn tipo concreto de sistemas. Podemos mencionar como una de las ms representativas a OMT. OMT est soportada por muchas herramientas CASE comerciales. Corresponde a una notacin grfica que permite representarlas clases de objetos, sus relaciones y la creacin de ejemplares delos mismos. Aunque bsicamente empleada para la fase de anlisis de requisitos del sistema puede tambin emplearse para las primeras fases del diseo. La descripcin del comportamiento se realiza generalmente asociando a los objetos diagramas de transicin de estados similares a los empleados en las tecnologas de software estructuradas (con los mismos problemas de la explosin de estados). En Booch puede verse una idea general de su tecnologa orientada a objetos [16].Los mtodos de diseo orientados a objetos suelen facilitar el desarrollo de una implementacin en un lenguaje de programacin orientado a objetos (C++, Ada95 o Eiffel). No obstante, la eleccin del lenguaje de implementacin no es realmente importante y esta eleccin est condicionada por muchas otras razones. Justo es reconocer, sin embargo, que ha sido la Programacin Orientada a Objetos la que ha impulsado tambin la difusin de estas tcnicas. Las herramientas que acompaan a las tecnologas orientadas a objetos y disponibles en sistemas CASE comerciales no se diferencian en esencia
de las que aparecen en las tecnologas estructuradas. El nico aspecto destacable es la proliferacin de catlogos de clases para aplicaciones determinadas y los mecanismos de recuperacin y personalizacin asociados.
Figura 1.4.2 Componentes de una tecnologa orientada a objetos
El anlisis efectuado en este Captulo por cada uno de los componentes de una tecnologa de software nos ha permitido obtener una idea global del estado en el que se encuentra cada una de ellas. Estos componentes, obviamente, no son independientes. La situacin puede describirse de la siguiente manera:
A. Las notaciones empleadas comnmente (lenguajes de especificacin, diseo, codificacin, prueba, etc.) no permiten describir el sistema de manera progresiva a lo largo del ciclo de vida. En la prctica, es necesario combinar varias de ellas, con el inconveniente de tener que trasladar las decisiones y conceptos de una a otra. B. Toda tecnologa requiere que exista una forma de refinar el sistema y llegar desde la definicin de requisitos hasta la implementacin. Existen muchos mtodos posibles con variada penetracin en el mercado. La eleccin del ms adecuado depende de mltiples factores no exclusivamente tcnicos. C. En el proceso de refinamiento con un mtodo concreto es necesario comprobar que las decisiones tomadas no vulneran las propiedades
deseadas del sistema. La capacidad de razonar sobre el sistema (a travs de las descripciones del mismo) es la base del modelo de razonamiento empleado. Solo los mtodos formales pueden realmente asegurar un nivel alto de confianza. D. Las herramientas no son ms que un vehculo para soportarla descripcin y el razonamiento sobre un sistema. De poco sirve que sean muy agradables de usar, robustas o eficientes si soportan notaciones poco claras o desligadas entre s, marcos de razonamiento pobres o muy difciles de usar. E. Su principal rol es, justamente, posibilitar que pueda aprovecharse toda la potencialidad de las notaciones y la capacidad de razonamiento sobre un sistema. Si, adems, las herramientas estn integradas se puede soportar el desarrollo de un sistema complejo por un equipo de trabajo. Es interesante destacar que las mismas notaciones y herramientas pueden usarse de muchas maneras.... y unas son ms eficientes que otras. F. Finalmente, como parte de la tecnologa de software hemos desgajado el conocimiento relativo a un dominio de aplicacin. Esto implica que, en cierta forma, los problemas y los esquemas de soluciones ligados a un dominio concreto son independientes de la notacin utilizada (no evidentemente su formulacin, que depende de los otros componentes). Generalmente, el desarrollo de un mtodo no se hace a espaldas de los dems componentes. En la prctica es el desarrollo de sistemas reales el que alimenta los propios heursticos del mtodo y las mejores notaciones y herramientas. Esta realimentacin es la base del progreso de la tecnologa de software. Buscar una solucin genrica asociada a un problema tipo, expresarla en las notaciones empleadas, comprobar que satisface las propiedades deseadas, emplear las herramientas para ello, y utilizarla de forma consistente con un mtodo de desarrollo que gue el proceso de refinamiento de la descripcin del sistema desde los requisitos hasta la implementacin es la manera en la que los componentes dela tecnologa interaccionan.
Consiste en recrear el mundo real. No se trata de construir "modelos ideales", sino de representarlo directamente. Por ello, en este enfoque, primero se identifican las caractersticas de los elementos del mundo real, los que se organizan en las denominadas estructuras de datos. Luego se captan los comportamientos u operaciones, los cuales se imitan o simulan mediante pequeos programas (procedimientos) a los que en adelante denominaremos mtodos. Y as como en la vida real conceptualizamos en una sola unidad (datos y comportamiento), en TO simulamos este hecho colocando en una especie de "cpsula" las estructuras de datos y los mtodos, a esta unidad denominamos OBJETO.
Tambin se simula la manera en que los entes del mundo real se comunican entre s, envindose seales o "mensajes" a los que responden con una conducta o comportamiento especfico, de la misma manera se simulan las clasificaciones, ordenamiento, organizacin, e incluso la herencia de los seres vivos. En sntesis, se trata de actuar de la misma manera en que los humanos, a los que en informtica, en general, se nos denomina usuarios, "manejamos" y operamos el mundo real.
Encapsulamiento. Utilizacin del concepto de "Caja Negra" a una potencia mucho mayor. Empaquetar datos y operaciones en forma conjunta se llama encapsulamiento. La encapsulacin es el resultado (o acto) de ocultar, al usuario, los detalles de la implementacin de un objeto. El objeto oculta sus datos a otros objetos y slo permite accesar a sus datos va sus propios mtodos mediante mensajes especficos, es decir, se crea una "Caja Negra" que solo el constructor del objeto conoce. A esto se llama ocultamiento de informacin. La encapsulacin protege los datos de un objeto de la corrupcin. Si todos los programas pudieran accesar a los datos (como actualmente sucede con la tecnologa estructurada), fcilmente puede corromperse o perderse. La encapsulacin protege los datos del objeto del uso arbitrario y no intencionado. As la creacin est protegida y la competencia garantizada. La encapsulacin tiene dos beneficios primordiales: 1. Modularidad. El cdigo de un objeto puede ser escrito y se puede mantener independiente del cdigo de otros objetos. Un objeto se puede mover de sistema en sistema, se puede quitar, modificar y volver a colocar sin alterar el sistema general. 2. Esconder la informacin (Information Hiding). Un objeto tiene una interfaz con la que otros objetos se pueden comunicar, pero puede mantener informacin privada para s misma que puede cambiar en cualquier momento, sin afectar a los objetos que dependen de sta. Reutilizacin. Capacidad de reutilizar cdigo sin alterarlo, programando solo lo adicional o diferente. Base de la Herencia Durante la vida de un sistema, las estructuras de datos se mantienen relativamente estables, mientras que las operaciones sobre dichas estructuras cambian, dependiendo de situaciones. Por ello en el Anlisis y
Diseo Orientado a Objetos, se da nfasis primordial a los datos y al comportamiento de los objetos y tipos de objetos (modelos).Los datos, como son relativamente estables, pueden ser utilizados muchas veces, modificando nicamente aquello que sea necesario para tal o cual situacin, en la misma forma se procede con los comportamientos. En cambio, en el Anlisis y Diseo Estructurado, se da nfasis a la descomposicin funcional orientada al proceso, en consecuencia, cualquier modificacin requiere de una reconstruccin, normalmente, a partir de cero.
1.5. Definicin e historia de las herramientas CASE

1.5.1 Introduccin Durante las ltimas dcadas se ha trabajado en el rea de desarrollo de sistemas para encontrar tcnicas que permitan incrementar la productividad y el control de calidad en cualquier proceso de elaboracin de software, y hoy en da la tecnologa CASE (Computer Aided Software Engineering) reemplaza al papel y al lpiz por el ordenador para transformar la actividad de desarrollar software en un proceso automatizado. La tecnologa CASE supone la informatizacin de la informtica es decir la automatizacin del desarrollo del software , contribuyendo as a elevar la productividad y la calidad en el desarrollo de los sistemas de informacin de forma anloga a lo que suponen las tcnicas CAD/CAM en el rea de manufactura. 1.5.1 Que es CASE? Carma MacClure "CASE es la automatizacin del software" Michael Lucas Gibson "CASE es una filosofa que se orienta a la mejor comprensin de los modelos de empresa, sus actividades y el desarrollo de los sistemas de informacin. Esta filosofa involucra adems el uso de programas que permiten: Construir los modelos que describen la empresa, Describir el medio en el que se realizan las actividades, Llevar a cabo la planificacin, El desarrollo del Sistema Informtico, desde la planificacin, pasando por el anlisis y diseo de sistemas, hasta la generacin del cdigo de los programas y la documentacin."
Jos M. de las Heras
"La creacin de software utilizando tcnicas de diseo y metodologas de desarrollo bien definidas, soportadas por herramientas automatizadas operativas en el ordenador" M.C. Blanca Maricela Ibarra Murrieta Software que automatiza una fase o una actividad del desarrollo de software
1.5.2 Objetivos del CASE 1. Aumentar la productividad de las reas de desarrollo y mantenimiento de los sistemas informticos. 2. Mejorar la calidad del software desarrollado. 3. Reducir tiempos y costes de desarrollo y mantenimiento del software. 4. Mejorar la gestin y dominio sobre el proyecto en cuanto a su planificacin, ejecucin y control. 5. Mejorar el archivo de datos (enciclopedia) de conocimientos (know-how) y sus facilidades de uso, reduciendo la dependencia de analistas y programadores. 6. Automatizar : El desarrollo del software La documentacin La generacin del cdigo El chequeo de errores La gestin del proyecto 7. Permitir La reutilizacin (reusabilidad) del software La portabilidad del software La estandarizacin de la documentacin 8. Integrar las fases de desarrollo (ingeniera del software) con las herramientas CASE 9. Facilitar la utilizacin de las distintas metodologas que desarrollan la propia ingeniera del software. 1.5.3 Historia de las Herramientas CASE Las Herramientas CASE tienen su inicio con el simple procesador de palabras que fue usado para crear y manipular documentacin. Los setentas vieron la introduccin de tcnicas grficas y diagramas de flujo de estructuras de datos. Sobre este punto, el diseo y especificaciones en forma pictrica han sido extremadamente complejos y consuman mucho tiempo para realizar cambios.
La entrada de las herramientas CASE para ayudar en este proceso ha permitido que los diagramas puedan ser fcilmente creados y modificados, mejorando la calidad de los diseos de software. Los diccionarios de datos, un documento muy usado que mantiene los detalles de cada tipo de dato y los procesos dentro de un sistema, son el resultado directo de la llegada del diseo de flujo de datos y anlisis estructural, hecho posible a travs de las mejoras en las Herramientas CASE Los paquetes grficos son remplazados por paquetes especializados que habilitan la edicin, actualizacin e impresin en mltiples versiones de diseo. Eventualmente, las herramientas grficas integradas con diccionarios de base de datos para producir poderosos diseos y desarrollar herramientas, podran sostener ciclos completos de diseo de documentos. El paso final, es la verificacin de errores y generadores de casos de pruebas fueron incluidos para validar el diseo del software. Todos estos procesos pueden saberse integrados en una simple herramienta CASE que soporta todo el ciclo de desarrollo.
La primera herramienta comercial se remonta a 1982, aunque algunos especialistas indican que algunos ejemplos de herramientas para diagramacin ya existan. No fue sino hasta 1985 en que las herramientas CASE se volvieron realmente importantes en el proceso de desarrollo de software. Los proveedores prometieron a la Industria que muchas actividades seran beneficiadas por la ayuda de las CASE. Estos beneficios consistan, por ejemplo, en el aumento en la productividad. El objetivo en 1985 para muchos vendedores era producir software ms rpidamente. Las herramientas del CASE seran una familia de mtodos favorablemente estructurados para planeamiento, anlisis y diseo. Esto llevara a la generacin automtica de cdigo para desarrollo de software va una especificacin formalmente diseada. Esto traera como beneficio: Una mejora en la calidad, fiabilidad, utilidad y rendimiento. El entorno de produccin de documentacin para software mejora la comunicacin, mantenimiento y actualizacin. Hace el trabajo de diseo de software ms fcil y agradable.
La promesa futura de reemplazar realmente a los ingenieros de software especializados. Reduccin del costo de produccin de software.
Con estos objetivos en mente, la industria destin millones en produccin de Herramientas CASE. As como esta enorme suma de dinero fue gastada en Herramientas CASE, hubo tambin trabajo de investigacin a nivel mundial en diferentes instituciones como Universidades, Instituciones Gubernamentales y de Defensa. La industria de Herramientas CASE est creciendo y est tomando cada vez mayor importancia. 1.5.3.1 Evolucin de las Herramientas CASE
A inicios de los 80s : o Ayuda en la documentacin por computadora. o Diagramacin asistida por computadora. o Herramientas de anlisis y diseo.
A mediados de los 80s :
o Diseo automtico de anlisis y pruebas. o Repositorios automticos de informacin de sistemas.

Al final de los 80s : A inicio de los 90:
o Generacin automtica de cdigo desde especificaciones de diseo.
o Generacin automtica del cdigo a partir de las especificaciones del diseo.

A finales de los 90:
o Conductor de metodologa inteligente o Interfaz amigable con el usuario.
1.6. Clasificacin de las herramientas CASE

No existe una nica clasificacin de herramientas CASE y, en ocasiones, es difcil incluirlas en una clase determinada. Podran clasificarse atendiendo a: Las plataformas que soportan. Las fases del ciclo de vida del desarrollo de sistemas que cubren. La arquitectura de las aplicaciones que producen. Su funcionalidad.
Las herramientas CASE, en funcin de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente:
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas tambin CASE workbench. 2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end, orientadas a la automatizacin y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: anlisis y diseo. 3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) o back-end, dirigidas a las ltimas fases del desarrollo: construccin e implantacin. 4. Juegos de herramientas o Tools-Case, son el tipo ms simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontraran las herramientas de reingeniera, orientadas a la fase de mantenimiento
I - CASE
Se concibe como el conjunto de cuatro herramientas que tocan las disciplinas que van desde la estrategia de la empresa, y la concepcin del sistema de informacin, hasta el anlisis, diseo y la generacin de los mismos programas.
Las herramientas I-CASE se basan en una metodologa. Tienen un repositorio y aportan tcnicas estructuradas para todas las fases del ciclo de vida. Estas son las caractersticas que les confieren su mayor ventaja: una mejora de la calidad de los desarrollos. Beneficios de las I-CASE
Tools Case Estn formadas por un conjunto de herramientas orientadas cada una de ellas a resolver una determinada fase del desarrollo. El ensamblaje de las mismas se efecta por medio de una serie de interfaces que adaptan las salidas producidas por cada una de ellas de forma que sirva como entrada en la siguiente. En el mercado actual se pueden citar, entre otras, algunas herramientas distribuidas por fases de desarrollo como para: Anlisis y Diseo Prokit Workbench de McDonnell-Douglas Desing Aid Nastec Analyst/Designer Tolkit de Yourdon Excelerator de Index Technology
Pose de Computer System Advisers
Diseo de Archivos y Base de Datos Chen Toolkit de Chen & Associates IDMS/Architec de Cullinet Software Autmate Plus de LBMS Case Designer de Oracle Synon Oracle Informix Programacin APS de Sage Software Tranforms de Transform Logic Telon Pansophic System Decase de DEC COBOL 2/ Worbench de Micro Focus Snap CASE para AS/400
Otra posible clasificacin, utilizando la funcionalidad como criterio principal, es la siguiente: Herramientas de planificacin de sistemas de gestin: Sirven para modelizar los requisitos de informacin estratgica de una organizacin. Proporcionan un "metamodelo" del cual se pueden obtener sistemas de informacin especficos. Su objetivo principal es ayudar a comprender mejor cmo se mueve la informacin entre las distintas unidades organizativas. Estas herramientas proporcionan una ayuda importante cuando se disean nuevas estrategias para los sistemas de informacin y cuando los mtodos y sistemas actuales no satisfacen las necesidades de la organizacin. Herramientas de Anlisis y Diseo: Permiten al desarrollador crear un modelo del sistema que se va a construir y tambin la evaluacin de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la representacin del anlisis y ayudan a eliminar errores con anticipacin. Entre ellas podemos encontrar: Herramientas de anlisis y diseo (Modelado). Herramientas de creacin de prototipos y de simulacin. Herramientas para el diseo y desarrollo de interfaces.
Herramientas de programacin: Se engloban aqu los compiladores, los editores y los depuradores de los lenguajes de programacin convencionales. Ejemplos de estas herramientas son: Herramientas de codificacin convencionales. Herramientas de codificacin de cuarta generacin (asociadas a SGBD) Herramientas de programacin orientadas a objetos. Herramientas de integracin y prueba: Sirven de ayuda a la adquisicin, medicin, simulacin y prueba de los equipos lgicos desarrollados. Entre las ms utilizadas estn: Herramientas de anlisis esttico. Herramientas de generacin de casos de prueba.
Herramientas de gestin de prototipos: Los prototipos son utilizados ampliamente en el desarrollo de aplicaciones, para la evaluacin de especificaciones de un sistema de informacin, o para un mejor entendimiento de cmo los requisitos de un sistema de informacin se ajustan a los objetivos perseguidos. Herramientas de mantenimiento: La categora de herramientas de mantenimiento se puede subdividir en: Herramientas de Ingeniera Inversa. Herramientas de reestructuracin y anlisis de cdigo. Herramientas de reingeniera.
Herramientas de gestin de proyectos: La mayora de las herramientas CASE de gestin de proyectos, se centran en un elemento especfico de la gestin del proyecto, en lugar de proporcionar un soporte global para la actividad de gestin. Utilizando un conjunto seleccionado de las mismas se puede: realizar estimaciones de esfuerzo, coste y duracin, hacer un seguimiento continuo del proyecto, estimar la productividad y la calidad, etc. Existen tambin herramientas que permiten al comprador del desarrollo de un sistema, hacer un seguimiento que va desde los requisitos del pliego de condiciones tcnicas inicial, hasta el trabajo de desarrollo que convierte estos requisitos en un producto final. Se incluyen dentro de las herramientas de control de proyectos las siguientes:
Herramientas de planificacin de proyectos. Herramientas de seguimiento de requisitos. Herramientas de gestin y medida.
Herramientas de soporte: Se engloban en esta categora las herramientas que recogen las actividades aplicables en todo el proceso de desarrollo, como las que se relacionan a continuacin: Herramientas de documentacin. Herramientas para software de sistemas. Herramientas de control de calidad. Herramientas de bases de datos
Otra clasificacin, diferencia las funciones CASE en cinco grupos:

Repositorio.
Funcionan en torno a un repositorio central, siendo ste el ncleo fundamental que contiene todas las definiciones de objeto y sus relaciones. Los objetos pueden ser especificaciones del sistema en forma de diagramas de flujo de datos, diagramas entidad-relacin, esquemas de bases de datos, diseos de pantallas, etc. El repositorio es un concepto ms amplio que el de diccionario de datos y soporta a los dems grupos de funciones. No es fcil encontrar en el mercado productos Case con funcionalidades estrictamente a las de repositorio, ya que, a pesar de su innegable importancia, tienen un carcter auxiliar de los dems grupos de funciones. Cualquier sistema Case poseer un repositorio propio o bien, trabajar sobre un repositorio suministrado por otro fabricante o vendedor.
Re-ingeniera.
Los sistemas Case permiten establecer una relacin estrecha y fuertemente formalizada entre los productos generados a lo largo de distintas fases del ciclo de vida, permitiendo actuar en el sentido especificaciones-cdigo (ingeniera "directa") y tambin en el contrario (ingeniera "inversa"). Ello facilita la realizacin de modificaciones en la fase ms adecuada en cada caso y su traslado a las dems. Al conjunto de facilidades proporcionadas or la ingeniera directa e "inversa" se le denomina "re-ingeniera".
Soporte del ciclo de vida.

El ciclo de vida de una aplicacin o de un sistema de informacin se compone de varias etapas, que van desde la planificacin de su desarrollo hasta su implantacin, mantenimiento y actualizacin. Aunque el nmero de fases puede ser variable en funcin del nivel de detalle que se adopte, pueden de modo simplificado, identificarse las siguientes: Planeamiento. Anlisis y Diseo. Implantacin (programacin y pruebas). Mantenimiento y actualizacin.
Los sistemas Case pueden cubrir la totalidad de estas fases o bien especializarse en algunas de ellas. En este ltimo caso se pueden distinguir sistemas de "alto nivel" ("Upper Case"), orientados a la autonoma y soporte de las actividades correspondientes a las dos primeras fases y, sistemas de "bajo nivel" ("Lower Case"), dirigidos hacia las dos ltimas. Los sistemas de "alto nivel" pueden soportar un nmero ms o menos amplio de metodologas de desarrollo.
Soporte de proyecto.
Este tipo de funciones hace referencia al soporte de actividades que se producen durante el desarrollo, derivadas fundamentalmente del trabajo en grupos, tales como facilidades de comunicacin, soporte a la creacin, modificacin e intercambio de documentacin, herramientas personales, controles de seguridad, etc. Los sistemas Case pueden conceder a estas cuestiones una importancia variable por lo cual el soporte de proyecto constituye un factor de diferenciacin.
Mejora continua de calidad.

Aunque frecuentemente se asocia a los sistemas Case con la mejora de la productividad en el desarrollo de aplicaciones, debe tenerse en cuenta que una de las principales ventajas estriba tambin, en la mejora de la calidad de los desarrollos realizados. Determinados sistemas Case enfatizan ms sobre este punto que sobre el anterior, introduciendo herramientas que permiten ejercer un control intenso de garanta de calidad del software desarrollado desde las primeras fases de su ciclo de vida.
Ejemplos de Herramientas Case ms utilizadas
Erwin
PLATINUM ERwin es una herramienta de diseo de base de datos. Brinda productividad en diseo, generacin, y mantenimiento de aplicaciones. Desde un modelo lgico de los requerimientos de informacin, hasta el modelo fsico perfeccionado para las caractersticas especficas de la base de datos diseada, ERwin permite visualizar la estructura, los elementos importantes, y optimizar el diseo de la base de datos. Genera automticamente las tablas y miles de lneas de stored procedure y triggers para los principales tipos de base de datos.
EasyCASE
Esta herramienta permite automatizar las fases de anlisis y diseo dentro del desarrollo de una aplicacin, para poder crear las aplicaciones eficazmente
desde procesamiento de transacciones a la aplicacin de bases de datos de cliente/servidor, as como sistemas de tiempo real. EasyCASE permite capturar los detalles de diseo de un sistema y comunicar las ideas grficamente, para que sean fciles de ver y entender. Para un diseo legtimo y modelamiento de datos, procesos y eventos, permite crear y mantener diagramas de flujo de datos, diagramas de entidad-relacin, mapas de estructura y ms
Oracle Designer
Oracle Designer es un juego de herramientas para guardar las definiciones que necesita el usuario y automatizar la construccin rpida de aplicaciones cliente/servidor flexibles y grficas. Integrado con Oracle Developer, Oracle Designer provee una solucin para desarrollar sistemas empresariales cliente/servidor de segunda generacin. Sofisticadas aplicaciones cliente/servidor pueden ser 100% generadas usando la lgica de la aplicacin y el mdulo de componentes reusables. Oracle Designer tambin habilita la captura del diseo de sistemas existentes, salvaguardando la versin actual
PowerDesigner
PowerDesigner es una suite de aplicaciones de Powersoft para la construccin, diseo y modelado de datos a travs de diversas aplicaciones. Es la herramienta para el anlisis, diseo inteligente y construccin slida de una base de datos y un desarrollo orientado a modelos de datos a nivel fsico y conceptual, que dan a los desarrolladores Cliente/Servidor la ms firme base para aplicaciones de alto rendimiento. Siglas ms comunes en Ingeniera de software SW (Software) HW (Hardware)
IA (Inteligencia artificial) PC (Computadora personal) TI (Tecnologas de informacin)
WEP (Privacidad equivalente a cable) SO (sistema operativo) IEEE (Glosario estndar de terminologa de ingeniera de software) T4G (Tcnicas de cuarta generacin)
Referencias: http://www.ingenierosoftware.com/equipos/comunicacion.php http://definicion.de http://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5040/TECN02.HTM http://es.scribd.com/doc/454427/39/Tecnologias-de-desarrollo-estructurado El Analista de Sistemas, Grupo de http://members.xoom.com/analista/portada.htm Estudios AS
Revista, Tecnologa de Punta, Ing. Vctor Castaeda Guzmn, Herramientas para el Desarrollo de Sistemas de Informacin, Instituto Nacional de Estadstica e Informtica Power Designer, http://www.sybase.com/products/powerdesigner Oracle Designer, http://www.oracle.com/tools/designer/quicktour/contents.htm#features Erwin, http://www.platinum.com/products/brochure/als/b_erwin.htm System Architect http://www.popkin.com/products/sa2001/product.htm The Case Tool Home Page, http://osiris.sunderland.ac.uk/sst/case2/ Herramientas http://www.geocities.com/SiliconValley/Bit/6238/index.htm CASE,
Bibliografa: 1. [BOE81] Boehm, B., SofrYt9ar-e Engineering Economics, Prentice-Hall, 1981. 2. [PRE98] Pressman, Roger S. (1998). Ingeniera del Software: un enfoque prctico. Cuarta Edicin. McGraw-Hill. 3. [SOM02]Sommerville, I., Ingenieria de Software, Addison Wesley, 2002. 4. [LEO96] Len, G, S., Ingenieria de Sistemas de Software, Isdefe,1996. 5. [PIA04] Piatti, M. G., Calvo, J. M., Cervera, J. y Fernandez L., Analisis y dieo de aplicaciones de gestin una perspectiva de ingeniria de software, Alfaomega, 2004.
6. [GAR04] Garca, J., Comunicacin en equipos de software, Julio 2004
http://es.scribd.com/doc/94026206/un idad-I

Unidad I

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Unidad I

Enviado por

Direitos autorais:

Formatos disponíveis

Fundamentos de ingeniera de Software

Unidad I Fundamentos de Ingeniera de software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Figura 1.1.1 Porcentajes de proyectos de software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

1.1.5.2 Mantenimiento del Software

1.1.5.3 Costo del Mantenimiento del Software

De acuerdo a Yourdon y Hatton (1998):

Desarrollo Mantenimiento pos entrega

Figura 1.1.2 Porcentaje de costo de mantenimiento del software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

1.1.5.5 Problemas de comunicacin

Figura 1.1.3 torre de babel

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Figura 1.1.4 Problemas de comunicacin en el desarrollo de software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Tabla 1.2.1. Evolucin de los procesos de produccin del SW.

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Figura 1.2.1. Proceso bsico

Estas caractersticas hacen que tenga una aplicacin general.

1.3 Etapas del desarrollo de software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Figura. El Proceso como Solucin de Problemas

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Ejemplos son: la metodologa Yourdon/Constantine

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Ejemplo: la metodologa ingeniera de la informacin de Martin y Finkelstein

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

1.4.2 Orientadas a Objetos

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Figura 1.4.2 Componentes de una tecnologa orientada a objetos

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

Instituto Tecnolgico de Chihuahua II

Fundamentos de ingeniera de Software

1.5. Definicin e historia de las herramientas CASE

Jos M. de las Heras

Instituto Tecnolgico de Chihuahua II