UNIDAD III MODELOS

INFORMACIN

PRESCRIPTIVOS

DEL

DESARROLLO

DE

SISTEMAS

DE

3.1 MODELO EN CASCADA

El 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 requisitos
En 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 Sistema
Descompone 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 Programa

Es 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.
Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as
como de pruebas y ensayos para corregir errores.
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.
Pruebas
Los 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.
Verificacin
Es 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.
Mantenimiento
Una 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.

Variantes
Existen variantes de este modelo; especialmente destacamos la que hace uso
de prototiposy en la que se establece un ciclo antes de llegar a la fase de
mantenimiento, verificando que el sistema final este libre de fallos.
Desventajas
En 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 ESPECIALES
Modelo 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.6 Es 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 incremental es 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 paradigma MCP como 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 de tiempo real,
de alto nivel de seguridad, de procesamiento distribuido, o de alto ndice de riesgos.

Modelo espiral: El modelo espiral fue propuesto inicialmente por Barry Boehm. Es
un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con 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 operativa hasta 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 el MCP para 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) o MCP, por lo que
no se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difcil
de implementar y controlar.
Modelo espiral Win & Win
Una 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.

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 ms 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 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.
-CARACTERISTICAS
Iterativo e Incremental
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto
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 en cascada: 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 uso
En el Proceso Unificado los casos de uso se 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 o escenarios y 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 est Dirigido por requisitos y
riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.
Centrado en la arquitectura
El 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 riesgos
El 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 requerimientos
Extraer 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 como CMMI. Asimismo, se define un diagrama
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
requerimientos de software (Software Requirements Specification).

de

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

Arquitectura
La 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 secuencia

Siendo 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 denominan CASE,
(Computer Aided Software Engineering) entre las cuales se encuentran:

Enterprise Architect

Microsoft Visio for Enterprise Architects

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

Prueba
Consiste 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.
Documentacin
Todo 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.
Mantenimiento
Fase 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
proyecto2 est 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 su evolucin.
Modelos y filosofas de desarrollo de software
La ingeniera de software dispone de varios modelos, paradigmas y filosofas de
desarrollo, en los cuales se apoya para la construccin del software, entre ellos se
puede citar:

Modelo en cascada o Clsico (modelo tradicional)

Modelo de prototipos

Modelo en espiral

Desarrollo por etapas

Desarrollo iterativo y creciente o Iterativo e Incremental

RAD (Rapid Application Development)

Desarrollo concurrente

Proceso Unificado

RUP (Proceso Unificado de Rational)

Naturaleza de la IS
La ingeniera de software tiene que ver con varios campos en diferentes formas:
Matemticas
Los programas tienen muchas propiedades matemticas. Por ejemplo la correccin
y lacomplejidad de muchos algoritmos son conceptos matemticos que pueden ser
rigurosamente probados. El uso de matemticas en la IS es llamado mtodos
formales.
Creacin
Los 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 Proyectos
El 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.
Arte
Los 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.

Las herramientas
Software Asistida

CASE (Computer Aided Software Engineering, Ingeniera de

porComputadora)
son
diversas aplicaciones

informticas destinadas a aumentar la productividad en el desarrollo de software

reduciendo el costo de las mismas en trminos de tiempo y de dinero. Estas
herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de
desarrollo del software en tareas como el proceso de realizar un diseo del
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).
Objetivos
1. 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 proyecto
5. 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
documentacin
8. 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.

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

de planificacin, anlisis de requisitos y estrategia del desarrollo, usando,
entre otros diagramas UML.

Middle CASE (M-CASE), herramientas

el anlisis y diseo de la aplicacin.

Lower CASE (L-CASE), herramientas que semi-automatizan la generacin de

cdigo, crean programas de deteccin de errores, soportan la depuracin de
programas y pruebas. Adems automatizan la documentacin completa de la
aplicacin. Aqu pueden incluirse las herramientas de Desarrollo rpido de
aplicaciones.

para

automatizar

tareas

en

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.

Editores UML.

Herramientas de Refactorizacin de cdigo.

Herramientas de mantenimiento como los sistemas de control de versiones.