UNIDAD III MODELOS PRESCRIPTIVOS DEL DESARROLLO DE SISTEMAS DE INFORMACIN3.1 MODELO EN CASCADAEl modelo en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.Un ejemplo de una metodologa de desarrollo en cascada es:1. Anlisis de requisitos.2. Diseo del Sistema.3. Diseo del Programa.4. Codificacin.5. Pruebas.6. Implantacin.7. Mantenimiento.De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto.Anlisis de requisitosEn esta fase se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificacin de requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos.Diseo del SistemaDescompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseo del Software), que contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se combinan unas con otras.Diseo del ProgramaEs la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la etapa de Codificacin.CodificacinEs la fase en donde se implementa elcdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregirerrores.Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms rpido.PruebasLos elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.VerificacinEs la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle.MantenimientoUna de las etapas mas criticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

VariantesExisten variantes de este modelo; especialmente destacamos la que hace uso deprototiposy en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de fallos.DesventajasEn la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso.El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no est completo no se opera. Esto es la base para que funcione bien.

3.2. MODELOS EVOLUTIVOS

El software evoluciona con el tiempo, los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el mercado un producto absolutamente completo, por lo que se aconsejable introducir una versin funcional limitada de alguna forma para aliviar las presiones competitivas.En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estn diseados para acomodarse a una evolucin temporal o progresiva, donde los requisitos centrales son conocidos de antemano, aunque no estn bien definidos a nivel detalle.En el modelo cascada y cascada realimentado no se tiene demasiado en cuenta la naturaleza evolutiva del software, se plantea como esttico, con requisitos bien conocidos y definidos desde el inicio.Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez ms completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar ms all, durante la fase de operacin.Los modelos iterativo incremental y espiral (entre otros) son dos de los ms conocidos y utilizados del tipo evolutivo.3.3. MODELOS ESPECIALESModelo iterativo incremental:En trminos 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 descripcin del sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al producto global y final. Las actividades concurrentes (especificacin, desarrollo y validacin) sintetizan el desarrollo pormenorizado de los incrementos, que se har posteriormente.

Diagrama genrico del desarrollo evolutivo incremental.Muestra en forma muy esquemtica, el funcionamiento de un ciclo iterativo incremental, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto final.6Es decir, a medida que cada incremento definido llega a su etapa de operacin y mantenimiento. Cada versin emitida incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron analizados como necesarios.

El incrementales un modelo de tipo evolutivo que est basado en varios ciclos Cascada Realimentados aplicados repetidamente, con una filosofa iterativa.En la figura 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 genricas asociadas. Aqu se observa claramente cada ciclo cascada que es aplicado para la obtencin 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 se muestra como secuencial puro.Nota: Puede ser considerado y til, en cualquier momento o incremento incorporar temporalmente el paradigmaMCPcomo complemento, teniendo as una mixtura de modelos que mejoran el esquema y El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento.El modelo incremental no es recomendable para casos de sistemas detiempo real, de alto nivel de seguridad, deprocesamiento distribuido, o de alto ndice de riesgos.

Modelo espiral:El modelo espiral fue propuesto inicialmente porBarry Boehm. Es un modelo evolutivo que conjuga la naturaleza iterativa del modeloMCPcon los aspectos controlados y sistemticos del Modelo Cascada. Proporciona potencial para desarrollo rpido de versiones incrementales. En el modelo Espiral el software se construye en una serie de versiones incrementales. En las primeras iteraciones la versin incremental podra ser un modelo en papel o bien un prototipo. En las ltimas iteraciones se producen versiones cada vez ms completas del sistema diseado.El modelo se divide en un nmero de Actividades de marco de trabajo, llamadas regiones de tareas. En general existen entre tres y seis regiones de tareas (hay variantes del modelo). En la figura se muestra el esquema de un Modelo Espiral con 6 regiones. En este caso se explica una variante del modelo original de Boehm, expuesto en su tratado de 1988; en 1998 expuso un tratado ms reciente.

Fig. - Modelo espiral para el ciclo de vida del software.Las regiones definidas en el modelo de la figura son: Regin 1 - Tareas requeridas para establecer la comunicacin entre el cliente y el desarrollador. Regin 2 - Tareas inherentes a la definicin de los recursos, tiempo y otra informacin relacionada con el proyecto. Regin 3 - Tareas necesarias para evaluar los riesgos tcnicos y de gestin del proyecto. Regin 4 - Tareas para construir una o ms representaciones de la aplicacin software. Regin 5 - Tareas para construir la aplicacin, instalarla, probarla y proporcionar soporte al usuario o cliente (Ej. documentacin y prctica). Regin 6 - Tareas para obtener la reaccin del cliente, segn la evaluacin de lo creado e instalado en los ciclos anteriores.Una visin alternativa del modelo puede observarse examinando el eje de punto de entrada de proyectos. Cada uno de los circulitos () fijados a lo largo del eje representan puntos de arranque de los distintos proyectos (relacionados); a saber: Un proyecto de desarrollo de conceptos comienza al inicio de la espiral, hace mltiples iteraciones hasta que se completa, es la zona marcada con verde. Si lo anterior se va a desarrollar como producto real, se inicia otro proyecto: Desarrollo de nuevo Producto. Que evolucionar con iteraciones hasta culminar; es la zona marcada en color azul. Eventual y anlogamente se generarn proyectos de mejoras de productos y de mantenimiento de productos, con las iteraciones necesarias en cada rea (zonas roja y gris, respectivamente).Cuando la espiral se caracteriza de esta forma, est operativahasta que el software se retira, eventualmente puede estar inactiva (el proceso), pero cuando se produce un cambio el proceso arranca nuevamente en el punto de entrada apropiado (por ejemplo, en mejora del producto).El modelo espiral da un enfoque realista, que evoluciona igual que el software; se adapta muy bien para desarrollos a gran escala.El Espiral utiliza elMCPpara reducir riesgos y permite aplicarlo en cualquier etapa de la evolucin. Mantiene el enfoque clsico (cascada) pero incorpora un marco de trabajo iterativo que refleja mejor la realidad.Este modelo requiere considerar riesgos tcnicos en todas las etapas del proyecto; aplicado adecuadamente debe reducirlos antes de que sean un verdadero problema.El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de Sistemas Operativos (complejos); tambin en sistemas de altos riesgos o crticos (Ej. navegadores y controladores aeronuticos) y en todos aquellos en que sea necesaria una fuerte gestin del proyecto y sus riesgos, tcnicos o de gestin.Desventajas importantes: Requiere mucha experiencia y habilidad para la evaluacin de los riesgos, lo cual es requisito para el xito del proyecto. Es difcil convencer a los grandes clientes que se podr controlar este enfoque evolutivo.Este modelo no se ha usado tanto, como el Cascada (Incremental) oMCP, por lo que no se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difcil de implementar y controlar.Modelo espiral Win & WinUna variante interesante del Modelo Espiral previamente visto en la Figura es el Modelo espiral Win-Win (Barry Boehm). El Modelo Espiral previo (clsico) sugiere la comunicacin con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qu necesita y l proporciona la informacin para continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y desarrollador entran en una negociacin, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.Es as que la obtencin de requisitos requiere una negociacin, que tiene xito cuando ambas partes ganan.Las mejores negociaciones se fuerzan en obtener Victoria & Victoria (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador tambin gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes habilidades de negociacin.El modelo Win-Win define un conjunto de actividades de negociacin al principio de cada paso alrededor de la espiral; se definen las siguientes actividades:1. Identificacin del sistema o subsistemas clave de los directivos(*) (saber qu quieren).2. Determinacin de condiciones de victoria de los directivos (saber qu necesitan y los satisface)3. Negociacin de las condiciones victoria de los directivos para obtener condiciones Victoria & Victoria (negociar para que ambos ganen).3.4. EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE.ElProceso Unificado de Desarrollo Softwareo simplementeProceso Unificadoes unmarco de desarrollo de softwareque se caracteriza por estar dirigido porcasos de uso, centrado en la arquitectura y por seriterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es elProceso Unificado de Rationalo simplementeRUP.El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso Unificado de Rational, tambin 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.-CARACTERISTICASIterativo e IncrementalEl Proceso Unificado es un marco de desarrolloiterativo e incrementalcompuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o encascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto.

Diagrama ilustrando como el nfasis relativo en las distintas disciplinas cambia a lo largo del proyecto.Dirigido por los casos de usoEn el Proceso Unificado loscasos de usose utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso oescenariosy desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. el proceso dirigido por casos de uso es el rup. Nota: en UP se estDirigido por requisitos y riesgosde acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.Centrado en la arquitecturaEl Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc.Enfocado en los riesgosEl Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.El Lenguaje unificado de modelado no es el sucesor de la oleada de mtodos de anlisis y diseo orientados a objetos que surgi a finales de la dcada de los 1980 y principios de la siguiente. El UML unifica, sobre todo, los mtodos de Booch, Rumbaugh, Brhl (OMT) y Jacobson, pero su alcance ha llegado a formar parte fundamental de la Ingeniera de Software tras su estandarizacin en 1997 con el OMG (Object Management Group o Grupo de administracin de objetos).Por qu analizar y disear?En resumidas cuentas, la cuestin fundamental del desarrollo del software es la escritura del cdigo. Despus de todo, los diagramas son solo imgenes bonitas. Ningn usuario va a agradecer la belleza de los dibujos; lo que el usuario quiere es software que funcione (UML Gota a Gota, Addison Wesley, Pag 7). Por lo tanto, cuando considere usar el UML es importante preguntarse por qu lo har y como le ayudara a usted cuando llegue el momento de escribir el cdigo. No existe una evidencia emprica adecuada que demuestre si estas tcnicas son buenas o malas.3.5. Modelo de Proceso de Software IEEE.Anlisis de requerimientosExtraer los requisitos y requerimientos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniera de software para reconocer requerimientos incompletos, ambiguos o contradictorios. El resultado del anlisis de requerimientos con el cliente se plasma en el documento ERS, Especificacin de Requerimientos del Sistema, cuya estructura puede venir definida por varios estndares, tales comoCMMI. Asimismo, se define undiagrama de Entidad/Relacin, en el que se plasman las principales entidades que participarn en el desarrollo del software.La IEEE Std. 830-1998 normaliza la creacin de las especificaciones de requerimientos de software (Software Requirements Specification).EspecificacinLa especificacin de requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del xito de un proyecto de software radicar en la identificacin de las necesidades del negocio (definidas por la alta direccin), as como la interaccin con los usuarios funcionales para la recoleccin, clasificacin, identificacin, priorizacin y especificacin de los requisitos del software.Entre las tcnicas utilizadas para la especificacin de requisitos se encuentran: Caso de uso, Historias de usuario,Siendo los primeros ms rigurosos y formales, los segundas ms giles e informales.ArquitecturaLa integracin de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto.El arquitecto de software es la persona que aade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnolgicas.La arquitectura de sistemas en general, es una actividad de planeacin, ya sea a nivel de infraestructura de red y hardware, o de software.La arquitectura de software consiste en el diseo de componentes de una aplicacin (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseo arquitectnico debe permitir visualizar la interaccin entre las entidades del negocio y adems poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseo arquitectnico describe en general el cmo se construir una aplicacin de software. Para ello se documenta utilizando diagramas, por ejemplo: Diagramas de clases Diagramas de base de datos Diagrama de despliegue Diagrama de secuenciaSiendo los dos primeros los mnimos necesarios para describir la arquitectura de un proyecto que iniciar a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qu diagramas elaborar.Las herramientas para el diseo y modelado de software se denominanCASE, (Computer Aided Software Engineering) entre las cuales se encuentran: Enterprise Architect Microsoft Visio for Enterprise ArchitectsProgramacinReducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de software, pero no necesariamente es la que demanda mayor trabajo y ni la ms complicada. La complejidad y la duracin de esta etapa est ntimamente relacionada al o a los lenguajes de programacin utilizados, as como al diseo previamente realizado.

PruebaConsiste en comprobar que el software realice correctamente las tareas indicadas en la especificacin del problema. Una tcnica de prueba es probar por separado cada mdulo del software, y luego probarlo de forma integral, para as llegar al objetivo. Se considera una buena prctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la program, idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un rea de pruebas, la primera es que est compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evala que la documentacin entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como estn descritas. El segundo enfoque es tener un rea de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qu condiciones puede fallar una aplicacin y que pueden poner atencin en detalles que personal inexperto no considerara.DocumentacinTodo lo concerniente a la documentacin del propio desarrollo del software y de la gestin del proyecto, pasando por modelaciones (UML),diagramas de casos de uso, pruebas, manuales de usuario, manuales tcnicos, etc. todo con el propsito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.MantenimientoFase dedicada a mantener y mejorar el software para corregir errores descubiertos e incorporar nuevos requisitos. Esto puede llevar ms tiempo incluso que el desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un proyecto2est dedicado a su mantenimiento. Una pequea parte de este trabajo consiste eliminar errores (bugs); siendo que la mayor parte reside en extender el sistema para incorporarle nuevas funcionalidades y hacer frente a suevolucin.Modelos y filosofas de desarrollo de softwareLa ingeniera de softwaredispone de varios modelos,paradigmasyfilosofasde desarrollo, en los cuales se apoya para la construccin del software, entre ellos se puede citar: Modelo en cascadao Clsico (modelo tradicional) Modelo de prototipos Modelo en espiral Desarrollo por etapas Desarrollo iterativo y crecienteo Iterativo e Incremental RAD(Rapid Application Development) Desarrollo concurrente Proceso Unificado RUP(Proceso Unificado de Rational)Naturaleza de la ISLa ingeniera de software tiene que ver con varios campos en diferentes formas:MatemticasLos programas tienen muchas propiedades matemticas. Por ejemplo la correccin y lacomplejidadde muchos algoritmos son conceptos matemticos que pueden ser rigurosamente probados. El uso de matemticas en la IS es llamado mtodos formales.CreacinLos programas son construidos en una secuencia de pasos. El hecho de definir propiamente y llevar a cabo estos pasos, como en una lnea de ensamblaje, es necesario para mejorar la productividad de los desarrolladores y la calidad final de los programas. Este punto de vista inspira los diferentes procesos y metodologas que se encuentran en la IS.Gestin de ProyectosEl desarrollo de software de gran porte requiere una adecuada gestin del proyecto. Hay presupuestos, establecimiento de tiempos de entrega, un equipo de profesionales que liderar. Recursos (espacio de oficina, insumos, equipamiento) por adquirir. Para su administracin se debe tener una clara visin y capacitacin en Gestin de Proyectos.ArteLos programas contienen muchos elementos artsticos. Las interfaces de usuario, la codificacin, etc. Incluso la decisin para un nombre de una variable o una clase.Donald Knuthes famoso por argumentar a la programacin como un arte.3.6. HERRAMIENTAS CASE.

Lasherramientas CASE(ComputerAidedSoftwareEngineering,Ingeniera de SoftwareAsistida porComputadora) son diversasaplicaciones informticasdestinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en trminos detiempoy dedinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar undiseodel proyecto, clculo de costos, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras, que analizaba la relacin existente entre los requisitos de un problema y las necesidades que stos generaban, el lenguaje en cuestin se denominaba PSL (Problem Statement Language) y la aplicacin que ayudaba a buscar las necesidades de los diseadores PSA (Problem Statement Analyzer).Objetivos1. Mejorar la productividad en el desarrollo y mantenimiento del software.2. Aumentar la calidad del software.3. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informticos.4. Mejorar la planificacin de un proyecto5. Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la bsqueda de soluciones para los requisitos.6. Automatizar el desarrollo del software, la documentacin, la generacin de cdigo, las pruebas de errores y la gestin del proyecto.7. Ayuda a la reutilizacin del software, portabilidad y estandarizacin de la documentacin8. Gestin global en todas las fases de desarrollo de software con una misma herramienta.9. Facilitar el uso de las distintas metodologas propias de la ingeniera del software.ClasificacinAunque no es fcil y no existe una forma nica de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parmetros:1. Las plataformas que soportan.2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.3. La arquitectura de las aplicaciones que producen.4. Su funcionalidad.La siguiente clasificacin es la ms habitual basada en las fases del ciclo de desarrollo que cubren: Upper CASE (U-CASE), herramientas que ayudan en las fases deplanificacin,anlisis de requisitosy estrategia del desarrollo, usando, entre otrosdiagramas UML. Middle CASE (M-CASE), herramientas para automatizar tareas en elanlisisydiseode la aplicacin. Lower CASE (L-CASE), herramientas que semi-automatizan la generacin de cdigo, crean programas de deteccin de errores, soportan ladepuracin de programasy pruebas. Adems automatizan la documentacin completa de la aplicacin. Aqu pueden incluirse las herramientas deDesarrollo rpido de aplicaciones.Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificacin excluyente entre s, ni con la anterior: Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde anlisis hasta implementacin. MetaCASE, herramientas que permiten la definicin de nuestra propia tcnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles. CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software. IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestin de proyectos y gestin de la configuracin activa.Por funcionalidad podramos diferenciar algunas como: Herramientas de generacin semiautomtica de cdigo. EditoresUML. Herramientas deRefactorizacinde cdigo.Herramientas de mantenimiento como lossistemas de control de versiones.