Unidad 3

Modelos Prescriptivos del

desarrollo de sistemas de informacin
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.

Modelo en Cascada.
Modelos Evolutivos.
Modelos Especiales.
El Proceso Unificado de Desarrollo de software.
Modelo de Proceso de Software IEEE.
Herramientas CASE.

Competencia a desarrollar :
Comprender los Modelos Prescriptivos del desarrollo de Sistemas de
Informacin.

Generalidades del curso

Forma de evaluacin:

Examen escrito ()

35%

Evidencia (cuadro comparativo)

50%

Actitud

15%

Bibliografa:
Cohen y Asin.; Sistemas de Informacin un enfoque de toma de
decisiones. 3 Edicin. Mc Graw Hill.2000
EDWARDS, CHRIS; JOHN WARD y ANDY BYTHEWAY. Fundamentos
de Sistemas de Informacin. 2da. Edicin. Ed. Prentice Hall.
1998

Preguntas detonantes
Qu es?
Porqu es importante?
Qu elemento los
componen?
Cmo se aplica?

Fuentes de informacin:
a. Significado Dentro del Ciclo de Vida de
Desarrollo de Sistemas.
b. Modelos de Desarrollo de software
i. Modelos de Desarrollo Estructurado

Sommerville. Seccin
4.5.1
Pressman. Seccin 2.10

8.5

1. Modelo en Cascada.

Sommervillle. Seccin 4.1.1.

Pressman. Seccin 2.4.

2. Modelos evolutivos: incremental y

espiral.

Sommervillle. Seccin 4.1.2. y

4.2
Pressman. Seccin 2.7
Sommervillle. Seccin 4.4.
Jacobson, Booch y Rounbahg.
Secciones 1.1 a a 1.5.
Larman lt. Ed. Seccin 37.1.,
37.4 y 37.9

3. RUP

Ciclo de Vida del Software

Un modelo de
ciclo
de
vida
define el estado
de las fases a
travs de las
cuales se mueve
un proyecto de
desarrollo
de
software.

Definicin
de un Modelo de
Ciclo de Vida

Un modelo de
ciclo de vida de
software es una
vista de las
actividades que
ocurren durante
el desarrollo de
software, intenta
determinar el
orden de las
etapas
involucradas y
los criterios de
transicin
asociadas entre

Un modelo de ciclo
de vida del
software:
Describe las fases principales de desarrollo de
software.
Define las fases primarias esperadas de ser ejecutadas
durante esas fases.
Ayuda a administrar el progreso del desarrollo, y
Provee un espacio de trabajo para la definicin de un
detallado proceso de desarrollo de software.

MODELOS EVOLUTIVOS
Qu es un modelo de desarrollo?
Un modelo de desarrollo es una representacin abstracta de un proceso de
software, cada modelo representa el proceso de desarrollo de software de una
manera en particular. A pesar de estar definidos claramente, no representan
necesariamente la realidad de cmo se debe desarrollar el software, sino que
establece un enfoque comn. Un modelo puede ser modificado y adaptado de
acuerdo a las necesidades del software en desarrollo.
En forma general podemos clasificar los modelos de desarrollo en 3 grupos:

Modelo en Cascada (Bennington

1956):
El modelo en cascada. Considera las actividades fundamentales del proceso

de especificacin, desarrollo, validacin y evolucin, y los representa como

fases separadas del proceso, tales como la especificacin de requerimientos,
el diseo del software, la implementacin, las pruebas, etctera.

1. Anlisis y definicin de requerimientos. Los servicios, restricciones y metas del sistema

se definen a partir de las consultas con los usuarios. Entonces, se definen en detalle y sirven
como una especificacin del sistema.
2. Diseo del sistema y del software. El proceso de diseo del sistema divide los
requerimientos en sistemas hardware o software. Establece una arquitectura completa del
sistema. El diseo del software identifica y describe las abstracciones fundamentales del
sistema software y sus relaciones.
3. Implementacin y prueba de unidades. Durante esta etapa, el diseo del software se
lleva a cabo como un conjunto o unidades de programas. La prueba de unidades implica
verificar que cada una cumpla su especificacin.
4. Integracin y prueba del sistema. Los programas o las unidades individuales de
programas se integran y prueban como un sistema completo para asegurar que se cumplan
los requerimientos del software. Despus de las pruebas, el sistema software se entrega al
cliente.
5. Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), sta es la
fase ms larga del ciclo de vida. El sistema se instala y se pone en funcionamiento prctico.
El mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo
de vida, mejorar la implementacin de las unidades del sistema y resaltar los servicios del
sistema una vez que se descubren nuevos requerimientos.

Desventajas:
Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas
en la aplicacin del paradigma.

Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos.
El ciclo de vida clsico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de
muchos productos.

El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estar disponible una versin operativa del
programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.

La Inflexibilidad al dividir el proyecto en distintas etapas hace difcil responder al cambio en los requerimientos del cliente.
Entonces, este modelo slo es apropiado cuando los requerimientos se han entendido bien y los cambios estn bastante
limitados durante el proceso de diseo.

Muy pocos sistemas de negocios tienen requerimientos estables.

El modelo de cascada se usa principalmente para grandes proyectos de ingeniera de sistemas en los que un sistema se
desarrolla en varios sitios.

Entrega incremental
Ian Sommerville, 4.2.1
El modelo de desarrollo en cascada requiere:
1.Obtener los Requerimientos del Sistema antes de
empezar el Diseo.
2.Que el Diseador cumpla estrategias particulares de
Diseo antes de la Implementacin.
3.Los cambios de Requerimientos implican rehacer el
trabajo de captura de Requerimientos, de Diseo e
Implementacin.
4.La separacin de las etapas origina sistemas bien
documentados, slidos, que pueden evolucionar ms
fcilmente.

Modelos Evolutivos: Incremental

y Espiral
Ingeniera del Software, 7 Edicin, por Ian Sommerville, 4.1.2.
Desarrollo Evolutivo: se basa en la idea de
desarrollar una implementacin inicial, exponindola a
los comentarios del usuario y refinndola a travs de
las diferentes versiones hasta que se desarrolla un
sistema adecuado.
Las actividades de especificacin, desarrollo y
validacin se entrelazan, en vez de separarse, con una
rpida retroalimentacin entre stas.

Modelos Evolutivos:
Especificacin

Esbozo de
la
descripcin

Desarrollo

Validacin

Versin Inicial

Versiones
Versiones
Versiones
intermedias
intermedias
intermedias

Versin final

Tipos de Modelos Evolutivos

(Hay 2

tipos de desarrollo evolutivo)

1. Desarrollo exploratorio: Trabaja con el cliente

para explorar sus requerimientos y entregar un
sistema final.
El desarrollo empieza con las partes del sistema que se
comprenden mejor.
El sistema evoluciona agregando nuevos atributos
propuestos por el cliente.

2. Prototipos desechables: Busca comprender los

requerimientos del cliente y desarrollar una
definicin mejorada de los requerimientos.
El prototipo se centra en experimentar con los
requerimientos del cliente que no se comprenden del todo.

Ventajas del Modelo Evolutivo

Es ms efectivo que el enfoque en
cascada, pues satisface las necesidades
inmediatas de los clientes.
La especificacin se puede desarrollar de
forma creciente.
Tan pronto como el usuario entienda mejor
su problema, ste se puede reflejar en el
sistema software.

Desventajas del Modelo

Evolutivo
1. El proceso no es visible. Los administradores deben
hacer entregas regulares para medir el progreso.
Si los sistemas se desarrollan rpidamente, no es rentable
producir documentos que reflejen cada versin del
sistema.

2. Genera sistemas con estructura deficiente. Los

cambios continuos tienden a corromper la estructura
del software.
Incorporar cambios se convierte cada vez ms en una tarea
difcil y costosa.

Iteracin de procesos
Ian Sommerville, 4.2

Los cambios son inevitables en todos los proyectos de

software grandes. Hay cambios cuando:
El negocio cambia por presiones externas.
Las prioridades de gestin cambian.
Cuando se dispone de nuevas tecnologas, cambian
los diseos y la implementacin.

Iteracin de
procesos
El proceso del software no es un
proceso nico. Las actividades del
proceso se repiten regularmente a
medida que el sistema se va
rehaciendo, en respuesta a peticiones
de cambios. Hay dos modelos de
procesosparaapoyarestaiteracin:

1. Entrega incremental. La
especificacin, el diseo y
la
implementacin
del
software se dividen en una
serie de incrementos, que
se desarrollan por turnos.
2. Desarrollo en espiral. El
desarrollo del sistema gira
en espiral hacia fuera,
empezando con un esbozo
inicial y terminando con el
desarrollo final.

Entrega incremental
Desarrollo Evolutivo (caracteres)

Desarrollo Evolutivo
caractersticas:

1. Permite
que
los
Requerimientos
(Anlisis) y las decisiones
de Diseo se retrasen.
2. Origina
un
software
dbilmente estructurado y
difcil de comprender y
mantener.

Entrega incremental
Caractersticas
La Entrega Incremental es un enfoque intermedio
que combina las ventajas de ambos modelos:
Los clientes identifican, a grandes rasgos, los servicios
que proporcionar el sistema.
Identifican qu servicios son ms importantes y cules
menos.
Entonces, se definen varios incrementos en donde cada
uno proporciona una funcionalidad distinta del sistema.

Entrega incremental
Caractersticas
Los incrementos que proporcionen servicios con mayor prioridad
son desarrollados y entregados primero.
Una vez que se identifican los incrementos del sistema, se definen
en detalle los requerimientos para los servicios que se van a
entregar en el primer incremento, que es inmediatamente
desarrollado.
Durante el desarrollo, se puede llevar a cabo un anlisis adicional
de requerimientos para los requerimientos posteriores, pero no se
aceptan cambios en los requerimientos para el incremento actual.
Una vez que un incremento se completa y entrega, los clientes
pueden ponerlo en servicio.

Entrega incremental
Caractersticas
Hay una entrega temprana de partes de la
funcionalidad del sistema.
El cliente puede experimentar con el sistema, lo que
le ayuda a clarificar sus requerimientos para los
incrementos posteriores y para las ltimas versiones
del incremento actual.
Tan pronto como se completan nuevos incrementos,
se integran en los existentes.
La funcionalidad del sistema mejora con cada
incremento entregado.

Entrega incremental
Caractersticas
Los servicios comunes se pueden implementar
al inicio del proceso o de forma incremental tan
pronto como sean requeridos.

Entrega incremental
Ventajas
1. Los clientes no tienen que esperar a que se entregue
el sistema completo para poder sacarle provecho. El
primer incremento satisface los requerimientos ms
crticos y se puede utilizar el software inmediatamente.
2. Los clientes pueden utilizar los incrementos iniciales
como prototipos y obtener experiencia sobre los
requerimientos de los incrementos posteriores.
3. Existe un bajo riesgo de falla total del proyecto.
Aunque se pueden encontrar problemas en algunos
incrementos, lo normal es que el sistema se entregue
de forma satisfactoria.

Entrega incremental
Ventajas
4. Como los servicios ms prioritarios se entregan primero,
y los incrementos posteriores se integran, despus, en ellos;
a esos servicios ms importantes se les hacen ms pruebas.
As, es menos probable que haya fallas en las partes ms
importantes del sistema.

Entrega incremental
Desventajas
Los incrementos deben ser relativamente pequeos (no
ms de 20.000 lneas de cdigo) y cada uno debe
entregar alguna funcionalidad del sistema.
Puede ser difcil adaptar los requerimientos del cliente a
incrementos de tamao apropiado.
Muchos sistemas requieren un conjunto de recursos que
se utilizan en diferentes partes del sistema.
Como los requerimientos no se definen en detalle hasta
que un incremento se implementa, puede ser difcil
identificar los recursos comunes que requieren todos los
incrementos.

Desarrollo en espiral
Ian Sommerville, 4.2.2
El modelo en espiral del proceso del software fue
propuesto por Boehm (1988).
No representa al proceso del software como una
secuencia de actividades, sino como una espiral.
Cada ciclo en la espiral representa una fase del proceso
del software.
As. el ciclo ms interno alude a la Viabilidad del
Sistema, el siguiente ciclo a la Definicin de
Requerimientos, el siguiente ciclo al Diseo del
Sistema, y as sucesivamente.

Desarrollo en espiral
4 Sectores de cada Ciclo
Cada ciclo de la espiral se divide en cuatro sectores:
1. Definicin de objetivos. Para esta fase del
proyecto se definen los objetivos especficos.
Se identifican las restricciones del proceso y el
producto, y se traza un plan detallado de gestin.
Se identifican los riesgos del proyecto.
Dependiendo de estos riesgos, se planean estrategias
alternativas.

Desarrollo en espiral
4 Sectores de cada Ciclo
2. Evaluacin y reduccin de riesgos. Se lleva a
cabo un anlisis detallado para cada uno de los riesgos
del proyecto identificados.
Se definen los pasos para reducir dichos riesgo.
Por ejemplo, si existe el riesgo de tener requerimientos
inapropiados, se puede desarrollar un prototipo del
sistema.

Desarrollo en espiral
4 Sectores de cada Ciclo
3. Desarrollo y validacin. Despus de la evaluacin
de riesgos, se elige un modelo para el desarrollo del
sistema.
Por ejemplo, si hay riesgos en la interfaz de usuario =>
construir prototipos evolutivos.
Si hay riesgos de seguridad => un desarrollo basado en
transformaciones formales.
Si el mayor riesgo es la integracin de los subsistemas
=> Modelo en Cascada.

Desarrollo en espiral
4 Sectores de cada Ciclo
4. Planificacin. El proyecto se revisa y se toma la
decisin de si se debe continuar con un ciclo posterior
de la espiral.
Si se decide continuar, se desarrollan los planes para la
siguiente fase del proyecto.

Desarrollo en espiral
Figura Ilustrativa

Desarrollo en espiral

La consideracin del RIESGO

La diferencia principal entre el modelo en espiral y los
otros modelos es la consideracin explcita del
riesgo en el modelo en espiral.
El riesgo significa sencillamente que algo puede ir mal.
Por ejemplo, si se quiere utilizar un nuevo lenguaje de
programacin, un riesgo es que los compiladores
disponibles sean poco fiables o que no produzcan
cdigo objeto suficientemente eficiente.

Desarrollo en espiral
La consideracin del RIESGO
Los riesgos originan problemas en el proyecto; como
ser: problemas de agendas y excesos en los costos.
Por eso la disminucin de riesgos es una actividad muy
importante en la gestin del proyecto.
Un ciclo de la espiral empieza con la elaboracin de
objetivos, como el rendimiento y la funcionalidad.
Entonces se enumeran alternativas de alcanzar estos
objetivos y las restricciones de cada una.

Desarrollo en espiral
Conclusiones
Cada alternativa se evala contra cada objetivo
Se identifican las fuentes de riesgo del proyecto.
El siguiente paso es resolver estos riesgos, mediante: la
recopilacin de informacin, detallar ms el anlisis, la
construccin de prototipos y la simulacin.
Una vez que se han evaluado los riesgos, se desarrolla,
seguido de una actividad de planificacin para la
siguiente fase del proceso.

 Qu factores influyen a la hora de elegir un modelo de desarrollo para resolver

un problema dado?
Qu modelo de desarrollo elegira para resolver un problema que se comprende
bien desde el principio y est muy estructurado?
Se supone que se va desarrollar una aplicacin relativa a la gestin de pedidos de
una empresa. En este caso el cliente no tiene todava muy claro qu es lo que
quiere. Adems, el personal informtico va a utilizar un tecnologa que le resulta
completamente nueva.

 La ingeniera de software basada en

componentes (CBSE) (tambin conocida como
desarrollo basado en componentes (CBD)) es
una rama de la ingeniera de software que
enfatiza la separacin de asuntos (separation
of concerns (SoC)) por lo que se refiere a la
funcionalidad de amplio rango disponible a
travs de un sistema de software dado.
Es un acercamiento basado en la reutilizacin
para definir, implementar, y componer
componentes
dbilmente
acoplados
en
sistemas. Esta prctica persigue un amplio
grado de beneficios tanto en el corto como el
largo plazo, para el software en s mismo y
para las organizaciones que patrocinan tal
software.

Desarrollo de Software basado en

Componentes
En esencia, un componente es una pieza de
cdigo preelaborado que encapsula alguna
funcionalidad expuesta a travs de interfaces
estndar. Los componentes son los "ingredientes
de las aplicaciones", que se juntan y combinan
para llevar a cabo una tarea. El paradigma de
ensamblar componentes y escribir cdigo para
hacer que estos componentes funcionen se
conoce como Desarrollo de Software Basado en
Componentes.

 El uso de este paradigma posee algunas ventajas:

Reutilizacin del software. Nos lleva a alcanzar un
mayor nivel de reutilizacin de software.
Simplifica las pruebas. Permite que las pruebas sean
ejecutadas probando cada uno de los componentes
antes de probar el conjunto completo de componentes
ensamblados.
Simplifica el mantenimiento del sistema. Cuando
existe un dbil acoplamiento entre componentes, el
desarrollador es libre de actualizar y/o agregar
componentes segn sea necesario, sin afectar otras
partes del sistema.
Mayor calidad. Dado que un componente puede ser
construido y luego mejorado continuamente por un
experto u organizacin, la calidad de una aplicacin
basada en componentes mejorar con el paso del
tiempo.

 De la misma manera, el optar por comprar

componentes de terceros en lugar de
desarrollarlos, posee algunas ventajas:
1.Ciclos de desarrollo ms cortos.La
adicin de una pieza dada de funcionalidad
tomar das en lugar de meses aos.
2.Mejor ROI.Usando correctamente esta
estrategia, el retorno sobre la inversin
puede ser ms favorable que desarrollando
los componentes uno mismo.
3.Funcionalidad mejorada.Para usar un
componente que contenga una pieza de
funcionalidad, solo se necesita entender su
naturaleza, ms no sus detalles internos.
As, una funcionalidad que sera imprctica
de implementar en la empresa, se vuelve
ahora completamente asequible.

El proceso Unificado: Que es ?

Los sistemas son cada da ms grandes, existe una tendencia
generalizada, esto hace que los procesos iterativos e
incrementales sean imprescindibles.
Es necesario un proceso comn, un mtodo que integre:
Gua para ordenar las actividades de un equipo.
Direccin de las tareas de cada desarrollador por separado y del
equipo como un todo.
Especificacin de los artefactos que deben ser desarrollados.
Criterios para el control y la medicin de los productos y
actividades del proyecto.

Pgina 42

El proceso Unificado: Caractersticas

Est basado en componentes e interfaces bien definidas
Utiliza el Lenguaje Unificado de Modelado (UML)
Aspectos caractersticos:
Dirigido por casos de uso
Centrado en la arquitectura
Iterativo e incremental

Pgina 43

El proceso Unificado: Estructura

Pgina 44

45

El Proceso Unificado Dirigido por

casos de uso
Caso de uso: Fragmento de funcionalidad que proporciona al usuario
un resultado importante.

Modelo de casos de uso: Funcionalidad total del sistema

Qu debe hacer el sistema para cada usuario?.
Guan todo el proceso de desarrollo.
En cada iteracin se identifican e implementan unos cuantos casos de
uso.
Los casos de uso sirven para idear la arquitectura.
Se seleccionan los casos de uso ms representativos.
Se utiliza como partida para escribir el manual de usuario.
Pgina 46

Casos de Uso
Qu es un caso de uso?
Un caso de uso es una secuencia de interacciones entre uno o
varios actores y el sistema que tiene lugar bajo ciertas
circunstancias y que:
Es iniciada por un actor.
Se puede describir como una secuencia de actividades.
Produce un resultado de valor observable para algn actor.

Pgina 47

Ejemplo

Cuando el cliente inserta su

tarjeta en el cajero, la
pantalla del cajero le pide
que seleccione un idioma. El
cliente realiza su seleccin. El
cajero pregunta entonces al
cliente cul es su nmero de
identificacin personal ...
... el cliente recoge su dinero
de la ranura del dispensador
y saca su tarjeta de la ranura
de tarjetas.
Pgina 48

Por qu utilizar casos de uso?

Un caso de uso ayuda a contestar las siguientes
preguntas:

Quin hace qu?

Cundo lo hace?
Qu actividades se realizan?
Qu elementos del sistema se utilizan?

Pgina 49

Un proceso dirigido por casos de uso

Modelo de casos
de uso

Sacar dinero

Ingresar dinero

Cliente del
banco
Transferencia

Pgina 50

IEEE/EIA 12207

Tecnologa de la Informacin

Procesos del Ciclo de Vida del Software

Establece un marco comn para el software a travs de
sus ciclo de vida, desde la concepcin hasta el retiro del
mismo.
Enfoca los procesos del software desde el punto de vista
tcnico del sistema y desde el punto de vista comercial
de la empresa.
Es considerado ampliamente como base para el
comercio mundial de software.
Su adopcin es completa o en camino de serla en los
pases mas desarrollados.

Estructura del IEEE/EIA

Procesos Primarios del
Procesos de Soporte al
12207
Ciclo de Vida
Ciclo de Vida
Adquisicin
Suministro

Documentacin
GestindelaConfiguracin
AseguramientodelaCalidad
Verificacin

Operacin

Validacin
RevisinConjunta

Desarrollo

Auditora
Mantenimiento
ResolucindeProblemas
Procesos Organizacionales del Ciclo de Vida

Administracin/Gestin

Infraestructura

Mejoramiento

Capacitacin

Procesos Primarios del Ciclo de

Vida
Proceso de adquisicin. Define las actividades del adquisidor,
organizacin que adquiere un sistema, producto software o
servicio software.
Proceso de suministro. Define las actividades del
suministrador, organizacin que proporciona el sistema,
producto software o servicio software al adquisidor.
Proceso de desarrollo. Define las actividades del
desarrollador, organizacin que define y desarrolla el producto
software.

Procesos Primarios del Ciclo de

Vida (cont.)
Proceso de operacin. Define las actividades del
operador, organizacin que proporciona el servicio de
operar un sistema informtico en su entorno real, para
sus usuarios.
Proceso de mantenimiento. Define las actividades
del mantenedor, organizacin que proporciona el
servicio de mantenimiento del producto software; esto
es, la gestin de las modificaciones al producto software
para mantenerlo actualizado y operativo. Este proceso
incluye la migracin y retirada del producto software

Procesos de soporte al ciclo de vida

Hay ocho procesos de apoyo del ciclo de vida. Un
proceso de apoyo es el que apoya a otro proceso como
parte esencial del mismo, con un propsito bien
definido, y contribuye al xito y calidad del proyecto
software.
Un proceso de apoyo se emplea y ejecuta por otro
proceso segn sus necesidades.

Procesos de soporte al ciclo de vida

Proceso de documentacin. Define las actividades para el registro
de la informacin producida por un proceso del ciclo de vida.
Proceso de gestin de la configuracin. Define las actividades de
gestin de la configuracin.
Proceso de aseguramiento de la calidad. Define las actividades
para asegurar, de una manera objetiva, que los productos software y
los procesos son conformes a sus requisitos especificados y se ajustan
a sus planes establecidos. Se pueden emplear Revisiones Conjuntas,
Auditoras, Verificacin y Validacin como tcnicas de Aseguramiento
de la Calidad.

Procesos de soporte al ciclo de vida

Proceso de verificacin. Define las actividades (para el adquisidor,
suministrador o una parte independiente) para verificar hasta un nivel
de detalle dependiente del proyecto software, los productos software.
Proceso de validacin. Define las actividades (para el adquisidor,
suministrador o parte independiente) para validar los productos
software del proyecto software.
Proceso de revisiones conjuntas. Define las actividades para
evaluar el estado y productos de una actividad. Este proceso puede ser
empleado por dos partes cualesquiera, donde una de las partes (la
revisora) revisa a la otra parte (la revisada), de una manera conjunta.

Procesos de apoyo del ciclo de vida

Proceso de auditora. Define las actividades para determinar
el cumplimiento de los requisitos, planes y contrato. Este proceso
puede ser empleado por dos partes cualesquiera, donde una
parte (la auditora) audita los productos software o actividades de
otra parte (la auditada).
Proceso de solucin de problemas. Define un proceso para
analizar y eliminar los problemas (incluyendo las no
conformidades) que sean descubiertos durante la ejecucin del
proceso de desarrollo, operacin, mantenimiento u otros
procesos, cualesquiera que sea su naturaleza o causa.

Procesos organizativos del ciclo de

vida
Los procesos organizativos del ciclo de vida, son cuatro.
Se emplean por una organizacin para establecer e
implementar una infraestructura constituida por
procesos y personal asociados al ciclo de vida, y para
mejorar continuamente esta estructura y procesos.
Se usan habitualmente fuera del mbito de proyectos y
contratos especficos; sin embargo, la experiencia
adquirida mediante dichos proyectos y contratos
contribuye a la mejora de la organizacin.

Procesos organizativos del ciclo de

vida
Proceso de gestin. Define las actividades bsicas de gestin,
incluyendo la gestin de proyectos, durante un proceso del ciclo de
vida.

Proceso de infraestructura. Define las actividades bsicas para

establecer la infraestructura de un proceso del ciclo de vida.
Proceso de mejora. Define las actividades bsicas que una
organizacin (adquisidor, suministrador, desarrollador, operador,
mantenedor o el gestor de otro proceso) lleva a cabo para establecer,
medir, controlar y mejorar su proceso del ciclo de vida.
Proceso de formacin. Define las actividades para conseguir personal
adecuadamente formado.

Que es la Herramienta CASE?

(Computer Aided Software Engineering, Ingeniera de Software Asistida por
Ordenador)

Son diversas aplicaciones informticas destinadas a

aumentar la productividad en el desarrollo de software
reduciendo el coste 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,
calculo de costes, implementacin de parte del cdigo
automticamente con el diseo dado, compilacin
automtica, documentacin o deteccin de errores entre
otras.

La tecnologa CASE supone la

automatizacin del desarrollo del
software, contribuyendo a mejorar la
calidad y la productividad en el
desarrollo de sistemas de informacin y
se plantean los siguientes objetivos:

Permitir la aplicacin prctica de metodologas

estructuradas, las cuales al ser realizadas con una
herramienta se consigue agilizar el trabajo.
Facilitar la realizacin de prototipos y el desarrollo
conjunto de aplicaciones.

Objetivos
de la
Tecnologa
CASE

Simplificar el mantenimiento de los programas.

Mejorar y estandarizar la documentacin.
Aumentar la portabilidad de las aplicaciones.
Facilitar la reutilizacin de componentes software.
Permitir un desarrollo y un refinamiento visual de
las aplicaciones, mediante la utilizacin de
grficos .

Componentes
de una
Herramienta
CASE

Repositorio (diccionario) donde se almacenan los

elementos definidos o creados por la herramienta, y cuya
gestin se realiza mediante el apoyo de un Sistema de
Gestin de Base de Datos (SGBD) o de un sistema de
gestin de ficheros.
Meta modelo (no siempre visible), que constituye el
marco para la definicin de las tcnicas y metodologas
soportadas por la herramienta.
Carga o descarga de datos, son facilidades que
permiten cargar el repertorio de la herramienta CASE con
datos provenientes de otros sistemas, o bien generar a
partir de la propia herramienta esquemas de base de
datos, programas, etc. que pueden, a su vez, alimentar
otros sistemas. Este elemento proporciona as un medio
de comunicacin con otras herramientas.
Comprobacin de errores, facilidades que permiten
llevar a cabo un anlisis de la exactitud, integridad y
consistencia de los esquemas generados por la
herramienta.
Interfaz de usuario, que constar de editores de texto y
herramientas de diseo grfico que permitan, mediante la
utilizacin de un sistema de ventanas, iconos y mens,
con la ayuda del ratn, definir los diagramas, matrices,
etc. que incluyen las distintas metodologas.

Clasificacin
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 para automatizar tareas en 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.

Herramientas CASE mas 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
EasyCASE Profesional, el centro de productos para procesos, modelamiento de datos y eventos, e Ingeniera de Base de Datos, es un producto para la generacin de esquemas de base de
datos e ingeniera reversa, trabaja para proveer una solucin comprensible para el diseo, consistencia y documentacin del sistema en conjunto.

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.

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 de aplicaciones
Cliente/Servidor la ms firme base para aplicaciones de alto rendimiento.

System Architect
System Architect posee un repositorio nico que integra todas las herramientas, y metodologas usadas. En la elaboracin de los diagramas, el System Architect conecta directamente al
diccionario de datos, los elementos asociados, comentarios,reglas de validaciones, normalizacin, etc. Posee control automtico de diagramas y datos, normalizaciones y balanceo entre
diagramas "Padre e Hijo", adems de balanceo horizontal, que trabaja integrado con el diccionario de datos, asegurando la compatibilidad entre el Modelo de Datos y el Modelo Funcional.

SNAP
SNAP es un CASE para el desarrollo de aplicaciones en Sistemas AS/400 de IBM. Proporciona el ambiente integral de trabajo, brindando la posibilidad de construir sistemas de inmejorable
calidad, adheridos a los estndares S.A.A de IBM., totalmente documentados y ajustados a los requerimientos especficos de la organizacin, en una fraccin del tiempo y coste del que se
invertira, si se utilizaran herramientas tradicionales.