Se Kappa

TESIS DE MASTER
Sistemas Experto de Ayuda para la Seleccin del

Modelo de Ciclo de Vida
Autor: Lic. Bibiana D. Rossi
Dirigida por:
DRA. Almudena Sierra

DR. Ramn Garca Martnez
Madrid, Buenos Aires, Septiembre 2001

SISTEMA EXPERTO: SELECCIN DEL MODELO DE CICLO DE VIDA
A mis hijos
Gastn La Valle y Vernica La Valle
Agradecimientos 01/09/2003 Bibiana D. Rossi 1

AGRADECIMIENTOS
A las actuales autoridades del Instituto Tecnolgico de Buenos Aires, Repblica Argentina,
por llevar adelante una poltica consistente en programas de formacin en RR.HH
A la Universidad Tecnolgica Nacional, Facultad Regional Buenos Aires, Repblica Argentina

por ser mi primer Alma Mater en donde aprend a amar mi profesin
A la Universidad Nacional de Lujn, Repblica Argentina

por ser mi segunda Alma Mater en donde encontr una va de crecimiento formativo
A la Facultad de Informtica de la Universidad Politcnica de Madrid

y al apoyo prestado especialmente por Natalia Juristo Juzgado, directora del Magster
Al Dr. Edmundo No Gramajo

por iniciar el proyecto y por confiar en mi desempeo para participar en l
A mi primer maestro y jefe Lic. Carlos A. Uhalde

que acompa y fortaleci mi crecimiento profesional
A mi directora Dra. Almudena Sierra, por el tiempo dedicado,

la claridad y buena predisposicin ante las consultas realizadas
A mi director Dr. Ramn Garca Martnez, por su especial dedicacin,

con la que permanentemente abona mi crecimiento profesional
Al equipo de expertos del dominio, Prof. Gregorio Perichinsky,

Lic. Carlos Beltrami, Lic. Carlos Leone, Ing. M. Florencia Pollo Cattaneo,
Lic. Laura Lucchini, Ing. Mariano Weschler, Lic. Enrique Fernndez
Por el compromiso que asumieron, para que el proyecto llegara a buen trmino
A mi hermana, amiga, colega y socia Lic. Paola Britos

por su amor, tolerancia, apoyo logstico y continua compaa
A mis alumnos Ing. Alberto Patrn e Ing. Sebastin Corbat

por su afecto y continuo apoyo en el dominio de la herramienta Kappa.
A los alumnos Carlos Coto, Andrea Cribelli y Santiago Gallo, por su colaboracin
A todos mis alumnos del Magster quienes

alentaron, compartieron y enriquecieron mi propio trabajo de tesis
A mis amigos Lic. Adriana Fachal, A.S. Marcelo Castro, Osvaldo Rapetti,
Daniel Castro, Luis Donado
quienes con su cario y aliento acompaaron el avance de este trabajo
A mis compaeras de trabajo Cecilia Cardozo y Carolina Procopio, por su paciencia

y colaboracin permanente en la tarea diaria y en este trabajo en particular
A mi ahijado Maxi, por reglarme sus sonrisas, abrazos, travesuras y amor
A mis hijos Vernica La Valle y Gastn La Valle

por su paciencia, tolerancia, compaa, comprensin, apoyo y su gran amor
Agradecimientos 01/09/2003 Bibiana D. Rossi 3

INDICE
Captulo 1.
1. Introduccin 11
Captulo 2.
2. Dominio de la Aplicacin 17
2.1 Introduccin 17
2.2 Concepto de Ciclo de Vida 19
2.3 Ciclo de vida en Cascada 20
2.4 Ciclo de vida en Espiral 26
2.4.1 Concepto de Riesgo 26
2.4.2 Fases del ciclo de vida en Espiral 28
2.5 Ciclo de vida Orientado a objetos 31
2.5.1 Conceptos bsicos 32
2.5.2 Fases del ciclo de vida Orientado a objetos 35
2.5.3 Modelos bsicos del CV Orientado a objetos 42
2.5.3.1 Modelo de objetos 43
2.5.3.2 Modelo dinmico 44
2.5.3.3 Modelo funcional 45
Captulo 3.
3. Definicin del problema 49
3.1 Planteamiento 49
3.2 Objetivo del trabajo 50
3.3 Alcance 50
3.4 Ambito del proyecto 50
3.5 Metodologa IDEAL 52
3.6 Gestin del Proyecto 56
3.6.1 Planificacin 56
3.6.2 Estimacin de recursos 57
3.6.3 Control de Configuracin 57
3.6.4 Evaluacin del proyecto 57
Captulo 4.
4. Estudio de Viabilidad 65
4.1 Test de Viabilidad 65
INDICE 01/09/2003 Bibiana D. Rossi 5

4.2 Anlisis de Viabilidad para el proyecto 68

4.2.1 Justificacin de la dimensin Plausibilidad 68
4.2.2 Justificacin de la dimensin Justificacin 69
4.2.3 Justificacin de la dimensin Adecuacin 71
4.2.4 Justificacin de la dimensin Exito 73
4.3 Clculo de Viabilidad para el proyecto 77
4.4 Evaluacin de Viabilidad para el proyecto 87
Captulo 5.
5. Adquisicin de Conocimientos 91
5.1 El proceso de Adquisicin de Conocimientos 91
5.2 Adquisicin de Conocimientos del presente trabajo 92
5.3 Tcnicas para Adquisicin de Conocimientos utilizadas en el
presente trabajo 94
5.4 Adquisicin de conocimientos a partir de un Equipo de expertos 95
Sesin C.1 95
Sesin C.2 118
Sesin C.3 128
5.5 Teora de la Construccin Personal o Emparrillado 136
Sesin D.1 136
Sesin A.4 142
5.5 Conclusin de la Fase Primaria de Adquisicin de Conocimientos 145
Captulo 6.
6. Conceptualizacin de Conocimientos 149
6.1 Proceso de Conceptualizacin 149
6.2 Anlisis de Conocimientos 150
6.2.1 Paso 1: Identificacin, comparacin y categorizacin de conceptos 151
6.2.2 Paso 2: Identificacin de las relaciones entre conceptos 166
6.2.3 Paso 3: Identificacin de los conocimientos estratgicos 167
6.2.3.1: Descomposicin funcional modular 167
6.2.3.2: Comprobacin de los conocimientos estratgicos 180
6.2.4: Paso 4: Identificacin de los conocimientos tcticos 180
6.2.4.1: Anlisis de los conocimientos tcticos, seudorreglas 180
6.2.4.2: Comprobacin de los conocimientos tcticos 215

6.2.5 Paso 5: Identificacin de los conocimientos fcticos 215

6.2.5.1: Anlisis de los conocimientos fcticos 216
6.2.5.2: Comprobacin de los conocimientos fcticos 252
6.3 Sntesis de conocimientos 252
6.3.1 Modelo de procesos, modelo dinmico 252
6.3.2 Modelo esttico 253
6.3.3 Mapa de Conocimiento 267
6.4 Comprobacin de la Conceptualizacin 268
Captulo 7.
7. Formalizacin de Conocimientos 281
7.1 Seleccin de Formalismos 281
7.2 Formalizacin de los Conocimientos en Reglas de Produccin 281
7.3 Formalizacin de los Conocimientos en Marcos 281
7.4 Formalizacin de los Conocimientos en Procedimientos 293
Captulo 8.
8. Implementacin del sistema 299
8.1 Seleccin de la Herramienta 299
8.1.1 Los Objetos en Kappa 299
8.1.2 Las Reglas en Kappa 300
8.2 Implementacin en la Herramienta 301
8.2.1 Estructura general de los Objetos 302
8.3 Desarrollo de un caso ejemplo 304
Captulo 9.
9. Evaluacin 325
9.1 Evaluacin de la Adquisicin de Conocimientos 325
9.2 Evaluacin de la Conceptualizacin de Conocimientos 326
9.3 Evaluacin de la Formalizacin de Conocimientos 326
9.4 Evaluacin de la Implementacin de Conocimientos 327
9.4.1 Caso Ejemplo 1.1: Facturacin Telefnica 327
9.4.2 Caso Ejemplo 1.2: Facturacin Telefnica 332
9.4.3 Caso Ejemplo 2: Control de Stock 339

9.4.4 Caso Ejemplo 3: Control de Morosos 344

9.4.5 Caso Ejemplo 4: Tcnica emparrillado 349
9.4.6 Caso Ejemplo 5: Inscripcin Universitaria 355
9.4.7 Caso Ejemplo 6: Organizar Comisiones 364
9.4.8 Caso Ejemplo 7: Administracin Consorcio 370
9.4.9 Caso Ejemplo 8: Registracin Contable 374
9.4.10 Caso Ejemplo 9: Portal Empleos 377
9.4.11 Caso Ejemplo 10: Pedidos Droguera 383
9.5 Resultados de la Evaluacin del Sistema Experto 390
Captulo 10.
10. Conclusiones y Futuras Lneas de Investigacin 395
10.1 Conclusiones de trabajo 395
10.2 Lneas de Investigacin y Desarrollo 396
10.3 Lneas de Investigacin Complementarias 397
Captulo 11
11. Bibliografa 401
11.1 Referencias bibliogrficas 401
11.2 Abreviaturas 403
Captulo 12
12. Anexos 407
12.1 Anexos del captulo 3: Gestin de Configuracin 407
12.2 Anexos del captulo 5: Sesiones de Adquisicin de Conocimientos 419
A.1-A.2-A.3 Sesiones de entrevistas con el experto 419
B.1 Sesin de extraccin de conocimientos 429

Captulo 1
Introduccin
En los ltimos aos el proceso software se ha presentado como el eje

central en la escala de los niveles propuestos por el Modelo de Madurez del SEI
(Software Engineering Institute), [Paulk, M. 1993]. Como punto de partida frente a
la resolucin de problemas reales de software, el ingeniero debe establecer una
estrategia de desarrollo que acompae al proceso. Esta estrategia implica
seleccionar un modelo de proceso (ciclo de vida) segn la naturaleza del
proyecto, de la aplicacin a desarrollar, de los mtodos y herramientas a utilizar y
los controles y entregas que se requieren.
Existen varios modelos de ciclo de vida, entre los que se destacan:

cascada, prototipado de usar y tirar, incremental, emisin gradual, mejora
iterativa, ensamblaje de componentes, espiral, prototipado operativo y prototipado
rpido. No existe un modelo de ciclo de vida que funcione para cualquier
proyecto.
El Ingeniero en software debe estudiar las caractersticas del proyecto y

seleccionar el modelo de ciclo de vida que ms se adapte a ellas. Las bases para
determinar el ciclo de vida ms adecuado son: la cultura de la organizacin, la
disponibilidad para correr riesgos, el dominio de la aplicacin, la volatilidad de los
requisitos y cunto se comprenden dichos requisitos.
Esta seleccin se realiza al inicio del proyecto y se deben considerar un

conjunto de variables de anlisis que requiere en su mayor parte de la experiencia
del ingeniero en software, ya que al inicio del proyecto subyace una gran cuota de
subjetividad en casi todos los aspectos del proyecto.
En este contexto, se ha considerado conveniente disponer de la asistencia

de un Sistema Experto que colabore en la seleccin del modelo de ciclo de vida
ms adecuado para el proyecto. El sistema asistir al Ingeniero en software en la
seleccin del ciclo de vida ms adecuado para un proyecto de desarrollo en
particular, colaborando en el anlisis de las caractersticas ms relevantes a tener
en cuenta.
Se observa que el conocimiento requerido para confeccionar el Sistema

Experto es de laboriosa obtencin. Sin embargo, vista la importancia del tema, se
propone considerar la solucin postulando una clasificacin de ciclos de vida en
familias genricas. Las que fueron consideradas para el presente trabajo son:
cascada, espiral y orientadas a objetos. En este contexto se propone encuadrar el
desarrollo teniendo en cuenta los aspectos ms sobresalientes de cada familia.
INTRODUCCION 01/09/2003 Bibiana D. Rossi 11

Este trabajo esta organizado en captulos cuyo contenido es el siguiente:
En el captulo II, Domino del problema, se describe el dominio de aplicacin

del Proyecto. Se presenta el concepto de Ciclo de Vida (CV), su importancia y
vigencia. Luego se describen los ciclos de vida que se consideran en este
proyecto: el CV en Cascada, el CV en espiral y el CV Orientado a objetos.
Del CV en Cascada se describen sus fases. Del CV en Espiral se explica uno
de los conceptos principales de ese ciclo, que es el riesgo, y se describen las
fases que lo constituyen. Del CV Orientado a objetos se hace una breve
introduccin de los conceptos bsicos, se describen las fases y se presentan
los modelos bsicos que se usan.
En el captulo III, Definicin del problema, se presenta el objetivo y alcance

del proyecto especificando las caractersticas del problema a resolver y los
participantes. Se describe la metodologa IDEAL que es la seleccionada para
desarrollar el sistema. Como cierre del captulo se presenta un plan del
proyecto que es la base sobre la cual se cumplen las actividades de gestin.
En el captulo IV, Estudio de Viabilidad, se describe el Test de Viabilidad que

propone la Metodologa IDEAL. Luego se detalla el anlisis de viabilidad para
el proyecto, justificando los valores definidos en el test. A continuacin se
evala la viabilidad del proyecto.
En el captulo V, Adquisicin del Conocimiento se describe el proceso de

adquisicin de conocimientos y las tcnicas usadas en el mismo. Como inicio
del proceso se presentan las primeras sesiones de entrevistas con el experto
principal para completar el estudio de viabilidad. Luego se documenta el
proceso de extraccin de conocimientos en el cual se utiliz el Anlisis
Estructural de Textos. Se detalla el proceso de educcin de conocimientos
realizado al equipo de expertos para el cual se aplicaron el Mtodo Delphi y la
Tcnica Nominal de Grupo. Y finalmente se presenta la educcin de
conocimientos con el experto principal, el desarrollo de las entrevistas y la
tcnica de Emparrillado.
En el captulo VI, Conceptualizacin de Conocimientos se presenta el

resultado del desarrollo de la fase de Conceptualizacin. En primer lugar se
documenta el resultado del Anlisis de los conocimientos adquiridos
organizados en Conocimientos Estratgicos, Tcticos y Fcticos. Luego se
muestra el resultado de la Sntesis de los conocimientos adquiridos y
analizados documentado en el Modelo esttico, el Modelo dinmico y la
conformacin final en el Mapa de Conocimientos. Como cierre del captulo se
presenta la Comprobacin del proceso de Conceptualizacin.

En el captulo VII, Formalizacin de Conocimientos se especifica cmo los

conocimientos que en la fase de Conceptualizacin fueron expresados en
representaciones externas intermedias: rbol de descomposicin funcional,
seudorreglas y tablas de concepto-atributo-valor son representados en
representaciones compatibles con la tecnologa computacional. Se
seleccionan los formalismos a utilizar. Luego se formalizan los conocimientos
que sern posteriormente implementados en la herramienta seleccionada.
En el captulo VIII, Implementacin del sistema se describen en primer lugar

las caractersticas de la herramienta que se usar para implementar el
sistema experto. Luego usando un caso como ejemplo se presenta el sistema
en s, la interfaz y su operatoria general.
En el captulo IX, Evaluacin, se presentan los casos de prueba con los que se
ha evaluado el sistema. Se documenta la verificacin y validacin que se ha
realizado y se mencionan los tem que documentan la evaluacin realizada a lo
largo del desarrollo del sistema.
El objetivo de la etapa de evaluacin es garantizar la calidad del sistema
experto. La calidad esta asociada con el funcionamiento correcto del sistema y
que el sistema responda a las expectativas del usuario. La evaluacin no es,
una fase concreta de la ingeniera del conocimiento [Gmez, A. y otros 1997]
sino un conjunto de actividades que ser realizan a lo largo de cada fase de
desarrollo del sistema. Cada fase del proceso de desarrollo requiere una
evaluacin diferente aunque es conveniente utilizar los mismos casos de
prueba a lo largo de todas las fases.
En el captulo X, Conclusiones finales y Futuras Lneas de Investigacin, se

consideran tres aspectos importantes en relacin al trabajo realizado y a su
continuidad. En la parte de Conclusiones se detallan los aportes originales que
el trabajo de tesis ha generado en el dominio de conocimiento de la Seleccin
del Modelo de Ciclo de Vida ms adecuado. En la segunda parte se mencionan
aspectos y lneas de investigacin que se pueden considerar para ampliar el
presente desarrollo. En la tercera parte se mencionan temas de investigacin
complementarios.
En el captulo XI, Bibliografa, se presenta la bibliografa que se ha usado en

el presente trabajo y el detalle de las abreviaturas.
En el captulo XII, Anexos, se detallan los anexos. En primer lugar se

presentan los anexos del captulo 3, Definicin del problema: el control de
configuracin. En segundo lugar se presentan los anexos del captulo 5,
Adquisicin de Conocimientos: las sesiones de entrevista realizadas al
experto y las sesiones de extraccin de conocimientos realizadas sobre el

anlisis de la bibliografa del dominio de aplicacin del presente trabajo.

Captulo 2
Dominio de la
Aplicacin
SISTEMA EXPERTO : SELECCIN DEL MODELO DE CICLO DE VIDA
En este captulo se describe brevemente el dominio de aplicacin del

Proyecto. En primer lugar se presenta el concepto de Ciclo de Vida (CV), su
importancia y vigencia. Luego se describen los ciclos de vida que se consideran
en este proyecto el CV en Cascada, el CV en Espiral y el CV Orientado a objetos.
Del CV en Cascada se describen sus fases. Del CV en Espiral se explica

uno de los conceptos principales de ese ciclo, que es el riesgo, y se describen las
fases que lo constituyen. Del CV Orientado a objetos se hace una breve
introduccin de los conceptos bsicos, se describen las fases y se presentan los
modelos bsicos que se usan.
2.1 INTRODUCCION
Todos los sistemas de informacin estn conformados por componentes

estructurales: datos, procesos, controles, entradas, salidas, modelos, tecnologa.
A estos componentes se le suman los requerimientos: de sistemas, de
procesamiento de datos, de integracin, de costo y eficacia, de factibilidad.
Tambin se suman variables del negocio como: capacidad competitiva, calidad y
utilidad de la informacin, factores organizacionales, factores humanos.
Todos estos elementos no hacen un sistema de informacin a menos que

conformen una unidad con un propsito determinado. La tarea de desarrollar un
sistema de informacin es emprendida por los profesionales de sistemas que
emplean una metodologa de desarrollo de sistemas, como el camino para
realizar su trabajo. La metodologa es una gua desde el anlisis hasta el
mantenimiento. El primer paso de la tarea consiste en definir el modelo de ciclo de
vida, es decir, qu camino gua se selecciona.
Existen varios tipos de ciclos de vida entre los cuales seleccionar. Es

natural que existan varios tipos de ciclos de vida ya que existe tambin una gran
variedad de aplicaciones para las cuales se construyen productos software con
diversas caractersticas particulares.
Las tcnicas y metodologas de desarrollo de sistemas se confunden con

frecuencia con el ciclo de vida [Whitten, J. 1996]. El propsito del ciclo de vida es
planear, ejecutar y controlar el proyecto de desarrollo de un sistema. El ciclo de
vida define las fases y las tareas esenciales para el desarrollo de sistemas, sin
importar el tipo o la envergadura del sistema que se intenta construir. Por ejemplo,
siempre se debe estudiar y analizar el sistema actual (en el grado de detalle
adecuado) antes de definir las necesidades de los usuarios y fijar las prioridades.
DOMINIO DE LA APLICACIN 01/09/2003 Bibiana D. Rossi 17
Algunos autores y profesionales presentan el concepto de ciclo de vida

como parte del pasado, que ha perdido vigencia en la actualidad frente a las
nuevas filosofas de anlisis y diseo de sistemas de software. El mito de la
muerte del ciclo de vida se relaciona con la popularidad de las tcnicas y
metodologas [Whitten, J. 1996].
Una tcnica es un mtodo que aplica herramientas y reglas especficas

para completar una o ms actividades del ciclo de vida del desarrollo de sistemas.
Las tcnicas en su mayora son solo aplicables a una parte del ciclo de vida. Por
ejemplo la programacin estructurada es una tcnica aplicable a las fases de
codificacin y soporte de sistemas. No da apoyo a las fases de planificacin,
anlisis o diseo. Por lo tanto es necesario combinar la programacin
estructurada con otras tcnicas de desarrollo para cubrir todas las fases del ciclo
de vida.
Una metodologa es una versin particular e individual de un ciclo de vida

completo para el desarrollo de sistemas [Burch, J. y Grudnitski, G. 1994], que
incluye:
Tareas paso a paso para cada fase. Determina el orden de las fases del
proceso software.
Funciones desempeadas en cada tarea.
Productos resultantes y normas de calidad para cada tarea.
Tcnicas de desarrollo que se utilizarn en cada tarea.
Una autntica metodologa debe acompaar al ciclo de vida completo del

desarrollo de sistemas. La mayor parte de las metodologas modernas incluye el
uso de varias tcnicas de desarrollo con sus herramientas asociadas. Los
trminos tcnica y metodologa suelen utilizarse de forma indistinta tanto en las
publicaciones informticas como en la industria. Con frecuencia se llama
metodologa al anlisis estructurado cuando, en realidad, es una tcnica. Dicha
tcnica forma parte de varias metodologas conocidas [Whitten, J. 1996].
As pues, puede afirmarse que el ciclo de vida sigue vigente. Simplemente

se ha confundido con la forma de populares metodologas disponibles
comercialmente, las cuales contienen tcnicas muy conocidas y aplicadas.
Independientemente del nmero o nombres de las fases del ciclo de vida,

ste racionaliza y asigna una rutina al proceso de construccin de sistemas de
informacin. La meta principal del ciclo de vida de sistemas es reducir los inicios

falsos, reciclamiento indebido y callejones sin salida. Adems aumenta la

probabilidad de que el sistema que se construya e instale finalmente, sea el que
los usuarios desean y necesitan.
2.2 CONCEPTO DE CICLO DE VIDA
El proceso de construccin de software puede verse como una cadena de

tareas. Las cadenas de tareas son planes idealizados de qu acciones deben
realizarse y en qu orden. El software obtenido tras el proceso puede ser visto
como el producto que entra al proceso, se transforma (a lo largo de la cadena de
tareas) y que sale del proceso hasta obtener el producto deseado. Desde esta
perspectiva del producto, se pueden establecer los estados por los que va
pasando el producto en un proceso software: la entrada al proceso es una
necesidad, que una vez estudiada se convierte en una especificacin de
requisitos, que posteriormente se transforma en un diseo del sistema, para pasar
ms adelante a ser un cdigo y finalmente un sistema software completo e
integrado. Este enfoque orientado al producto, focalizado en el producto
transformado (en lugar del proceso que lo transforma) se llama ciclo de vida. Es
decir, el ciclo que el producto software sufre a lo largo de su vida, desde que nace
(o se detecta la necesidad) hasta que muere (o se retira el sistema). [Juristo
Juzgado, N. b 1996].
La figura 2-1 muestra la relacin entre el proceso de construccin del

software y el ciclo de vida.
PROCESO DE
CONSTRUCCION DEFINIR DISEAR PROBAR
PROGRAMAR
REQUISITOS EL SISTEMA EL SISTEMA
CICLO DE
VIDA
DEFINICION SISTEMA
NECESIDAD DISEO CODIGO
DE SOFTWARE
REQUISITOS
FIGURA 2-1: Relacin entre Proceso de construccin de software y el Ciclo de Vida.
El cambio de perspectiva del proceso al producto es muy sutil. Es ms,

proceso y producto, producto y proceso, estn intrnsecamente relacionados, son
inseparables. Cuando la perspectiva se centra en el proceso, el objetivo se

focaliza en resolver un caso del mundo real, el proceso refleja como se usa la
experiencia humana en la construccin de software y cmo se aplica a un dominio
concreto. Cuando la perspectiva se centra en el producto, el objetivo se focaliza
en detallar el conjunto especfico de productos (documentos) que se requieren en
cada paso del proceso de desarrollo de software.
La norma IEEE 1074 (Estndar IEEE del Ciclo de Vida para el Proceso de
Desarrollo de Software) [IEEE, 1991] define ciclo de vida como: una
aproximacin lgica de la adquisicin, el suministro, el desarrollo, la explotacin y
el mantenimiento del software.
La norma ISO 12207-1 (Proceso del Ciclo de Vida del Software) [ISO,
1994], define ciclo de vida como: un marco de referencia, que contiene los
procesos, las actividades y tareas involucradas en el desarrollo, la explotacin y
el mantenimiento de un producto software, abarcando la vida del sistema desde la
definicin de los requisitos hasta la finalizacin de su uso.
2.3 CICLO DE VIDA EN CASCADA
Fue presentado por primera vez por Royce en 1970 [Royce, W.W. 1970].
En este CV la evolucin del producto software procede a travs de una secuencia
ordenada de transiciones de una fase a la siguiente segn un orden lineal. Se
presenta frecuentemente como un simple modelo con forma de cascada como
muestra la Figura 2-2.
A continuacin se presenta una breve descripcin de cada una de sus

fases :
Planificacin de sistemas: el mbito de la planificacin puede ser toda la

empresa, una divisin de la misma o cualquier otro tipo de sus unidades
organizativas. El propsito es identificar y establecer las prioridades sobre
aquellas aplicaciones de los sistemas de informacin cuyo desarrollo
reporte mximos beneficios para la empresa considerada en su conjunto.
Sus entradas son las misiones de la empresa y cualquier tipo de detalle o
limitacin de los sistemas existentes. Sus salidas son los planes de
sistemas de empresa y de informacin y los proyectos planificados de
desarrollo de aplicaciones. Es as como el proyecto planificado avanza
hacia la fase siguiente.

PLANIFICACION
DE SISTEMAS
DEFINICION DE
REQUERIMIENTOS
ANALISIS
DISEO
CODIFICACION
PRUEBA
IMPLEMENTACION
MANTENIMIENTO
FIGURA 2-2: Ciclo de Vida en Cascada
Definicin de Requerimientos: el mbito de la definicin de requisitos es

un nico proyecto de sistemas de informacin. Su propsito es analizar el
problema o la situacin de la empresa y definir las necesidades con
respecto a la creacin o perfeccionamiento de un sistema de informacin.
Las entradas posibles son:
El proyecto planificado de desarrollo de aplicaciones (procedente de la
fase anterior)
Un proyecto no planificado de desarrollo de aplicaciones (que responde
a un problema, una oportunidad o una norma imprevista)
Detalles y limitaciones de los sistemas existentes.
Hechos y necesidades relacionados con la empresa.
El producto de esta fase es un Informe de Requisitos en el que se detalla lo
que precisan los usuarios y no cmo se proyectan, disean o implementan dichas
necesidades.
Anlisis: el dominio de aplicacin es un nico proyecto de desarrollo.
Consiste en el estudio del sistema actual de la empresa y establecer
prioridades en las necesidades de informacin manifestadas por los
usuarios para la construccin del nuevo sistema de informacin. Entre sus
principales actividades est el estudio de la viabilidad del proyecto, el

estudio y modelado del actual sistema en funcionamiento, la definicin de
los requisitos y establecimiento de prioridades y la especificacin de las
posibles alternativas de solucin.
El proceso de anlisis se centra especialmente en el dominio del problema
a resolver. Para comprender la naturaleza del sistema a construir el
analista del software debe comprender el dominio de informacin, la
funcin requerida, el comportamiento, el rendimiento y la interconexin. Los
requisitos, se documentan y se revisan con el cliente.
Las entradas son el Plan del proyecto y el Informe de requerimientos.
Las salidas son el Estudio de viabilidad, y el Informe del sistema actual.
Diseo: el proceso de diseo traduce requisitos en una representacin

centrada en la computadora que se pueda evaluar antes de que comience
la generacin de cdigo. El diseo tambin se documenta y forma parte del
sistema de configuracin.
El diseo de software es un proceso complejo que se centra en:
La estructura de los datos. Se definen archivos y bases de datos. Es
habitual definir un diagrama de estructuras de datos.
Los mtodos y procedimientos de proceso (algoritmos). Es habitual
definir diagramas de flujos.
La arquitectura del software, la estructura de la red informtica.
Representaciones de interfaz. Diseo de entradas, salidas, pantallas.
Codificacin: el diseo se debe traducir en una forma legible por la

mquina. El paso de generacin de cdigo lleva a cabo esta tarea. Si se
lleva a cabo el diseo de una forma detallada, la generacin de cdigo se
realiza con mayor facilidad. Esta fase puede incluir tambin las actividades
de construccin de las redes y bases de datos a usar por el nuevo sistema.
La entrada a esta fase son las Especificaciones de diseo. El resultado de
esta fase son los programas informticos no instalados an para
produccin.
Prueba: generado el cdigo, comienzan las pruebas del programa, para

encontrar errores en el software. El proceso de prueba se centra en los
procesos lgicos internos del software, asegurando que todas las
sentencias estn probadas y en las funciones externas, buscando que la
entrada definida produzca resultados reales de acuerdo con los resultados
requeridos.
Las pruebas de unidades aseguran que los programas de aplicaciones
funcionen de forma adecuada cuando se prueban de forma aislada con

respecto a otros programas de aplicacin. La entrada es la especificacin

de procesos y la especificacin del programa
Las pruebas de sistemas aseguran que los programas de aplicaciones
escritos de forma aislada funcionen adecuadamente cuando se integran en
el sistema global. La entrada es la especificacin de requerimientos del
sistema
La salida de esta fase es el sistema instalado y probado.
Implementacin: se desarrollan todas las actividades necesarias para

poner operativo el sistema desarrollado, retirar el sistema en uso (si lo
hubiera) y capacitar a los usuarios.
Las actividades consisten en procurar una transicin suave entre el antiguo
sistema y el nuevo, ayudar a los usuarios a resolver los problemas
normales de arranque, escribir manuales de operacin, cargar los archivos
y las bases de datos.
Las entradas de esta fase son: el sistema instalado en la fase anterior, la
documentacin para el usuario final, la formacin del usuario final.
La salida es el sistema de informacin en produccin.
Mantenimiento: el software sufrir cambios despus de ser entregado al

cliente. Se producen cambios porque se han encontrado errores, porque el
software debe adaptarse para acoplarse a los cambios en su entorno
externo, porque se requiere un cambio por un software de base o un
hardware nuevo, o porque el cliente requiere de mejoras funcionales o de
rendimiento.
El mantenimiento vuelve a aplicar cada una de las fases a un sistema o
subsistema ya existente o a uno nuevo.
El modelo de ciclo de vida en Cascada, permite iteraciones durante el

desarrollo, ya sea dentro de una misma fase, ya sea de un estado hacia otro
anterior. La mayor iteracin se produce cuando una vez terminado el desarrollo y
cuando se ha visto el software producido se decide comenzar de nuevo y redefinir
los requisitos del usuario. A menudo, durante el desarrollo, se pueden tomar
decisiones que den lugar a diferentes alternativas. El modelo en cascada no
reconoce esta situacin. Por ejemplo, dependiendo del anlisis de requisitos se
puede implementar el sistema desde cero o adoptar uno ya existente, o comprar
un paquete que proporcione las funcionalidades requeridas.
Entre las caractersticas del modelo en Cascada pueden mencionarse:

Cada fase empieza cuando se ha terminado la fase anterior. [Hawryszkiewycz,
I.T. 1990]

Para que un proyecto tenga xito, en cualquier caso, todos las fases
sealados en el modelo en cascada deben ser desarrollados.
Para pasar de una fase a otra es necesario conseguir todos los objetivos de la
etapa previa. [Behm, B.W. 1981]
Cualquier desarrollo en diferente orden de las fases dar un producto de
inferior calidad. Sin embargo, existen ciertos proyectos para los cuales este
orden es inviable. Esta ha sido una de las principales razones para definir
otros modelos.
Las etapas estn organizadas de un modo lgico. Es decir, si una etapa no
puede llevarse a cabo hasta que se hayan tomado ciertas decisiones de ms
alto nivel, debe esperar hasta que esas decisiones estn tomadas. As el
diseo espera a los requisitos, el cdigo espera a que el diseo est
terminado, etc.
Al final de cada fase, tanto los desarrolladores como los usuarios, tienen la
oportunidad de revisar el proyecto.
Cada etapa incluye cierto proceso de revisin y se necesita una aceptacin del
producto antes de que la salida de la etapa pueda usarse. Este ciclo de vida
est organizado de modo que se pase el menor nmero de errores de una
etapa a la siguiente.
Facilita la gestin de control del progreso del desarrollo del sistema, de las
fechas de entrega y de los costos esperados.
El ciclo es iterativo. A pesar de que el flujo bsico es de arriba hacia abajo, el
ciclo de vida en cascada reconoce, qu problemas encontrados en etapas
inferiores afectan a las decisiones de las etapas superiores.
El modelo en cascada asume que los requisitos de un sistema pueden ser
congelados antes de comenzar el diseo. Esto para sistemas totalmente
nuevos, es poco realista. Congelar los requisitos requiere seleccionar el
hardware. La terminacin de un gran proyecto puede llevar aos. Dada la
velocidad de obsolescencia de la tecnologa es bastante probable que el
software final utilice un hardware obsoleto.
No refleja el proceso real de desarrollo de software. Los proyectos rara vez
siguen el flujo secuencial, puesto que siempre hay iteraciones. Aunque en este
modelo la iteracin est permitida en etapas contiguas [Macro, A. 1990], en la
prctica real la iteracin abarca ms de una etapa.
El sistema en funcionamiento no est disponible hasta las fases finales del
proyecto. Esto significa que la mayor parte del feedback del cliente sobre sus
necesidades se obtiene una vez que se han consumido los recursos.
Existe una perspectiva alternativa del modelo de ciclo de vida en cascada,

que enfatiza la validacin de los productos. Ver figura 2-3. Esta variante del
modelo en Cascada presenta una descomposicin en fases, que se visualiza en
la lnea superior, consiste en: la definicin de los requisitos del sistema global y la
especificacin de los requisitos del software. Estos ltimos llevan al diseo
preliminar de mltiples funciones, cada una de las cuales se expande en el
Requisitos
sistema
global
Requisitos
sistema
software
Diseo
preliminar
Diseo
detallado
Codificacin
Pruebas
de unidad
Pruebas
de componente
Pruebas
Integracin
del software
Pruebas
del sistema
Pruebas software
integracin
hardware y
software
FIGURA 2-3: Ciclo de Vida en Cascada, validacin de productos.
diseo detallado, que, a su vez, evoluciona en un nmero mayor de programas

unitarios. El ensamble del producto final se produce en el sentido contrario, dentro
de un proceso de sntesis o composicin. Primero se aceptan los programas
unitarios probados. Entonces estos se agrupan en mdulos que a su vez, deben
ser probados y aceptados. Los mdulos se agrupan para certificar que el grupo
formado por todos ellos incluye las funcionalidades deseadas. Finalmente, el
software es integrado con el hardware hasta formar un nico sistema informtico
que satisface los requisitos globales.
La perspectiva de la figura 2-3 destaca que el producto obtenido en cada

etapa no slo determina qu debe hacerse en la fase siguiente del proceso, sino
que tambin establece los criterios para determinar si el producto compuesto y
ensamblado satisface los objetivos de la etapa.

2.4 CICLO DE VIDA EN ESPIRAL
El modelo en espiral propuesto por Behm [Behm, B.W. 1987], consta de

una serie de ciclos que se recorren por iteraciones sucesivas hasta cumplir cierto
hito o condiciones prefijadas. El modelo surge como un modelo no operativo de
produccin de software que tiende a poner nfasis en el riesgo a asumir en cada
etapa y el control de ese riesgo. Esta caracterstica ha motivado un creciente uso
de este modelo en grandes proyectos, que son, cada vez ms permeables al
riesgo.
Como el riesgo es uno de los fundamentos caractersticos de este modelo

se introduce una breve explicacin del concepto.
2.4.1 CONCEPTO DE RIESGO
Cada vez que se inicia un proyecto de desarrollo de software aparecen

reas de incertidumbre del tipo:
Se entienden realmente las necesidades del cliente?
Se pueden implementar las funciones a desarrollar para la fecha fijada?
Se encontrarn problemas tcnicos de difcil solucin que no son visibles
al inicio del proyecto?
Los cambios que se producen en el proyecto, en cunto afectarn la
planificacin?
En muchas ocasiones las estrategias de riesgo que se implementan en los

proyectos de desarrollo de software son reactivas, es decir, se supervisa el
proyecto en previsin de posibles riesgos. Lo ms frecuente es que no se haga
nada respecto a los riesgos hasta que algo sale mal. El equipo que lleva adelante
el proyecto corre entonces, para corregir el problema rpidamente (estrategia del
bombero). En ese momento cuando se produce el problema, la gestin de
riesgo entra en accin y el proyecto se encuentra en peligro real.
Una estrategia mejor para el control de riesgo es proactiva, es decir,

comienza antes de comenzar los trabajos tcnicos. Se identifican riesgos
potenciales, se valoran su probabilidad y su impacto y se establece una prioridad
segn su importancia. Despus el equipo de desarrollo establece un plan para
controlar el riesgo. El primer objetivo es evitar el riesgo, pero como no se pueden
evitar todos los riesgos, el equipo trabaja para desarrollar un plan de contingencia
que le permita responder de una manera eficaz y controlada.

El riesgo implica dos caractersticas:

Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no ocurrir.
No hay riesgos con un 100 % de probabilidad.
Prdida: si el riesgo se convierte en una realidad ocurrirn consecuencias no
deseadas o prdidas.
Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre
y el grado de prdida asociado con cada riesgo.
El Anlisis del riesgo consta de cuatro actividades:

1. Identificacin del riesgo: es un intento sistemtico para especificar las
amenazas al proyecto. Un mtodo para identificar riesgos es crear una lista de
comprobacin de elementos de riesgo. Esta lista puede organizarse de
diferente manera considerando la categora genrica de los riesgos (del
proyecto, tcnicos, del negocio) o se puede enfocar en las caractersticas ms
relevantes de los siguientes factores: tamao del producto, impacto en el
negocio, caractersticas del cliente, definicin del proceso, entorno de
desarrollo, tecnologa a usar, complejidad del sistema, tamao y experiencia
del equipo de desarrollo.
2. Proyeccin del riesgo: implica estimar dos aspectos del riesgo, la probabilidad
de que el riesgo se concrete y las consecuencias de los problemas asociados
al riesgo, si ocurriera. Para ello se realizan cuatro actividades de proyeccin
de riesgo: establecer una escala que refleje la probabilidad de ocurrencia del
riesgo, definir las consecuencias del riesgo, estimar el impacto del riesgo en el
proyecto y en el producto y documentar la proyeccin del riesgo. Es una
tcnica sencilla que puede implementarse en una hoja de clculo y que facilita
la proyeccin en la tabla de riesgo [Pressman, R.S. 1997].
3. Evaluacin del riesgo: durante la evaluacin del riesgo se contina
examinando la exactitud de las estimaciones que se hicieron en el paso previo,
se priorizan los riesgos que no se haban cubierto y se analizan las formas de
controlar y/o impedir la ocurrencia de los riegos ms probables. Para que esta
evaluacin sea efectiva se debe definir un nivel de referencia de riesgo
[Charette, R.N. 1992], que permite definir el punto de ruptura en el que las
decisiones de seguir el proyecto o dejarlo son igualmente aceptables.
4. Gestin del riesgo: se toma como base el anlisis realizado respecto de los
riegos y se desarrolla un plan que detalla los pasos o actividades a realizar
para gestionar cada riesgo. Estas actividades consumen recursos y por lo
tanto, generan un costo adicional en el proyecto. Una parte de la gestin del
riesgo consiste en la evaluacin de los beneficios conseguidos con los propios
pasos de la gestin de riesgo, comprobando que tengan un mayor peso que
los costos asociados a su implementacin, es decir, se realiza un anlisis
costo-beneficio. La experiencia demuestra que el 80% de los problemas

posibles del proyecto se deben al 20% de los riesgos identificados [Pressman,

R.S. 1997]. El anlisis que se toma como base sirve para determinar qu
riesgos se encuentran en ese 20%. Es posible entonces que algunos de los
riesgos que hayan sido identificados, calculados y evaluados no se encuentren
reflejados en el plan de gestin de riesgos porque no pertenecen al 20%
crtico.
2.4.2 FASES DEL CICLO DE VIDA EN ESPIRAL
El modelo en espiral puede recorrerse de distinta forma segn el caso en

estudio. El recorrido bsico del modelo es por ciclos, sobre las sendas
determinadas por la espiral (ver figura 2-4) siguiendo el sentido de las agujas del
reloj. Sus actividades se agrupan en fases. Una vez completadas las fases del
primer ciclo se vuelve a empezar el ciclo siguiente.
Costos
acumulados
Progreso a travs de pasos

Evaluacin de alternativas,
Identificacin, resolucin
de riesgos
Determinacin de
objetivos,
alternativas, Anlisis
restricciones Anlisis de riesgo
de riesgo
Anlisis
de riesgo
Anlisis
de riesgo Prototipo
Prototipo 1 Prototipo 2 Prototipo 3 operacional
Particin
Revisin
Planificacin
obligatoria de requisitos Simulaciones, modelos, programas de prueba
Planificacin Concepto
del ciclo de vida de operacin
Requisitos
Planificacin del software Diseo del
Validacin producto Diseo
del desarrollo
de requisitos software detallado
Planificacin de Codificacin
Validacin y verificacin Prueba
la integraciny prueba
del diseo de
Planificacin de las prximas fases unidad
Prueba de Integracin
aceptacin y prueba
Implementacin
Desarrollo, verificacin
del producto del prximo nivel
FIGURA 2-4: Ciclo de Vida en Espiral

Primera fase. Consiste en identificar:

Los objetivos del sistema o subsistema a desarrollar. Se considera el
rendimiento, funcionalidad, flexibilidad para los cambios, etc.
Las alternativas significativas para implementar este sistema o subsistema.
Puede considerarse disear A, disear B, reusar, comprar, etc.
Las restricciones impuestas sobre la implementacin de las alternativas. Como
costos, calendarios, interfaces, etc.
Segunda fase. Consiste en:

Evaluar las diferentes alternativas identificadas en el paso previo con relacin
a los objetivos y las restricciones.
Identificar reas de incertidumbre que son causa de riesgos del proyecto. Se
identifican entonces los riesgos del proyecto.
Formular estrategias para resolver las causas de mayor riesgo. Para ello se
utilizan tcnicas de resolucin de riesgos, tales como: prototipado, simulacin,
cuestionarios, modelizacin analtica, o combinaciones de stas u otras
tcnicas.
Determinar cmo se contina con la fase siguiente. Como resultado del paso
previo es posible que algunos riesgos identificados an persistan. El prximo
paso se decide en relacin con los riesgos que an existen. Considerando las
caractersticas de estos riesgos el modelo puede recorrerse de mltiples
formas.
Tercera fase. Consiste en seguir alguna de las siguientes alternativas:

Alternativa 1. Recorrer todas las fases de la espiral en secuencia.
Alternativa 2. Recorrer un subconjunto de todas las fases de la espiral: las
fases encerradas dentro del ngulo que contienen los prototipos y las
simulaciones.
Alternativa 3. Recorrer un subconjunto de todas las fases de la espiral: todas
las fases menos las fases encerradas dentro del ngulo que contiene los
prototipos y las simulaciones.
Alternativa X. Recorrer un subconjunto X de todas las fases de la espiral, que
determinar el lder de proyecto.
Alternativa 1:
Si los riesgos de interfaz de usuario, de estrategia de control o de rendimiento
dominan fuertemente el desarrollo del sistema, el prximo paso puede ser un
desarrollo tipo evolutivo. La espiral se recorre en todas sus fases
secuencialmente: un mnimo esfuerzo para especificar la naturaleza general
del producto (Concepto de operacin); un plan para el prximo nivel de
prototipo (Planificacin de requisitos, Planificacin de ciclo de vida); hasta el
desarrollo de un prototipo de mayor detalle (Prototipo 2) para continuar

resolviendo los principales riesgos emergentes (Simulaciones, modelos...); y
as sucesivamente hasta completar los ciclos de la espiral.
Alternativa 2:
Si el prototipo desarrollado es operacionalmente til y lo suficientemente
robusto como para ser la base, con bajo riesgo, para la evolucin del producto,
los siguientes pasos para el manejo de los riesgos remanentes pueden ser el
desarrollo de series de prototipos evolutivos. La espiral se recorre dirigindose
hacia la derecha de la figura 2-4, completando las fases encerradas dentro del
ngulo de lneas punteadas.
Alternativa 3:
Si los riesgos de rendimiento y de interfaz de usuario fueron resueltos y el
desarrollo del sistema se encuentra dominado por los riesgos de la estrategia
de control, los siguientes pasos pueden resolverse con un modelo semejante
al modelo en cascada. La espiral se recorre completando las fases (Concepto
de Operacin, Requisitos de Software, Diseo del producto Software, etc.) con
excepcin de las fases encerradas dentro del ngulo de lneas punteadas.
Cada fase es seguida por una fase de validacin y de preparacin de planes
para el siguiente ciclo de la espiral.
Alternativa X:
El modelo en espiral permite acomodar cualquier modelo de desarrollo de
software o cualquier combinacin de ellos, considerando las caractersticas de
los riesgos y la efectividad relativa de las diversas tcnicas de resolucin de
riesgos.
En la planificacin de las siguientes fases puede considerarse, por ejemplo,
subdividir el sistema en partes y encarar el desarrollo de esas partes ya sea por
desarrollo incremental o que las partes sean desarrolladas por distintos grupos,
organizaciones o personas individuales.
En ese caso es posible visualizar el modelo en espiral agregando la tercera
dimensin al modelo. Es decir considerar una serie de crculos paralelos de la
espiral, un crculo por cada componente. Por ejemplo, cada espiral individual se
asocia al desarrollo de cada uno de los subsistemas o componentes, siguiendo
su propia forma de evolucin segn las caractersticas de esos subsistemas o
componentes. Cada espiral puede ser asignada, segn el componente a
desarrollar a un programador, diseador, cliente, usuario, etc.
Una caracterstica importante del modelo en espiral es que cada ciclo se

completa con una revisin en la que participan las principales personas u
organizaciones que tienen relacin con el producto. Esta revisin cubre todos los
productos desarrollados durante el ciclo anterior, incluyendo los planes para el

siguiente y los recursos necesarios para llevarlos a cabo. El objetivo principal de
la revisin sirve para asegurar que todas las partes involucradas estn de acuerdo
respecto al mtodo de trabajo para la siguiente fase.
2.5 CICLO DE VIDA ORIENTADO A OBJETOS
El paradigma de Orientacin a Objetos (OO) se caracteriza por

conceptualizar el desarrollo de software empleando modelos cuya unidad bsica
es el objeto que combina las estructuras de datos con los comportamientos en
una entidad nica [Rumbaugh, J. y otros 1996].
En primer lugar, se construye un modelo de anlisis para abstraer los

aspectos esenciales del dominio de la aplicacin sin tener en cuenta la
implementacin. En esta etapa se toman decisiones importantes que despus se
completan para optimizar la implementacin. En segundo lugar, los objetos del
dominio de la aplicacin constituyen el marco de trabajo del modelo de diseo,
pero se implementan en trminos de objetos del dominio de la computadora. Por
ltimo, el modelo de diseo se implementa en algn lenguaje de programacin,
base de datos y hardware.
Los objetos del dominio de la aplicacin y del dominio de la computadora

se pueden modelar, disear e implementar utilizando los mismos conceptos y la
misma notacin orientada a objetos. Esta misma notacin se usa desde el anlisis
hasta la implementacin pasando por el diseo, de forma tal que la informacin
aadida en la fase de desarrollo no necesita perderse, ni ser traducida, para la
prxima fase.
La esencia del desarrollo orientado a objetos es la identificacin y

organizacin de conceptos (objetos) del dominio de la aplicacin. Slo cuando se
han identificado, organizado y comprendido los conceptos inherentes de la
aplicacin se pueden tratar en forma efectiva los detalles de las estructuras de
datos y de las funciones. Es una premisa bsica que los errores de las primeras
fases del proceso de desarrollo tienen mucha influencia sobre el producto final y
tambin sobre el tiempo requerido para finalizar.
El beneficio principal del desarrollo orientado a objetos no es reducir el

tiempo de desarrollo; el desarrollo orientado a objetos puede requerir ms tiempo
que el desarrollo convencional porque se pretende que promueva la reutilizacin
futura y la reduccin de los posteriores errores y el futuro mantenimiento. El
tiempo transcurrido hasta que el cdigo se completa por primera vez es
posiblemente el mismo que el transcurrido en una aproximacin convencional o,

quizs ligeramente mayor. El beneficio del desarrollo orientado a objetos consiste
en que las iteraciones subsiguientes son ms rpidas y ms fciles que
empleando un desarrollo convencional porque las revisiones estn ms
localizadas. La prctica muestra que suelen ser necesarias menos iteraciones
porque se descubren y se corrigen ms problemas durante el desarrollo.
[Rumbaugh, J. y otros 1996].
2.5.1 CONCEPTOS BASICOS
Hay varios conceptos que son propios de la orientacin a objetos y otros

inherentes a la tecnologa. Aunque no todos son exclusivos de los sistemas
orientados a objetos estn bien apoyados por el paradigma.
Orientado a Objetos: significa que el software se organiza como una coleccin

de objetos discretos que contienen tanto estructuras de datos como
comportamiento.
Identidad: los datos estn cuantificados en entidades discretas y distinguibles

denominadas objetos. Cada objeto posee su propia identidad inherente. Pueden
ser ejemplos de objetos, un prrafo de un documento, la reina blanca del juego de
ajedrez, una silla. En otras palabras: dos objetos sern distintos an cuando los
valores de todos sus atributos (tales como el nombre y el tamao) sean idnticos.
Por ejemplo en un conjunto de 6 sillas de un mismo juego, los valores de los
atributos son los mismos y cada una de las sillas tiene su propia identidad.
Identificacin: en el mundo real los objetos se limitan a existir, pero dentro de un

entorno de computacin cada objeto posee una identificacin mediante la cual se
puede hacer alusin a l de modo exclusivo. La identificacin se puede
implementar de distintas maneras que pueden ser como una direccin, un ndice
de una matriz, o un valor exclusivo de un atributo.
Clasificacin: significa que los objetos con la misma estructura de datos

(atributos) y comportamiento (operaciones) se agrupan, bajo alguna condicin,
para formar una clase. Son ejemplos de clases: prrafo, pieza de ajedrez.
Clase: es una abstraccin que describe propiedades importantes para una

aplicacin y que ignora el resto. La seleccin de clases es arbitraria y depende de
la aplicacin. Una clase contiene el molde (estructura, esquema) a partir del cual
se crean los objetos que pertenecen a ella y el cdigo que debe ejecutarse cada
vez que un objeto de la clase recibe un mensaje. Una clase contiene la
descripcin de las caractersticas comunes de todos los objetos que pertenecen a

ella: la especificacin del comportamiento, la definicin de la estructura interna y
la implementacin de los mtodos. Por ejemplo la clase "gato" es diferente si la
aplicacin es para un sistema de gestin de una veterinaria que si es un sistema
de pelculas de dibujos animados.
Instancia: se dice que cada objeto es una instancia de su clase. Toda clase
describe un conjunto posiblemente finito de objetos individuales. Toda instancia
de la clase posee su propio valor para cada uno de los atributos pero comparte
los nombres de los atributos y las operaciones con las dems instancias de la
clase. Todo objeto contiene una referencia implcita a su propia clase: sabe la
clase de cosa que es. Los objetos contienen los valores de los atributos (que lo
distinguen de otros objetos) y una identidad. Si continuamos con el ejemplo del
sistema de pelculas de dibujos animados y de la clase gato, pueden considerarse
como instancias: el gato Tom (Tom & Jerry), el gato Silvestre (amigo de Pioln), el
gato Flix.
Operacin: es una accin o una transformacin que se lleva a cabo, o que se

aplica a un objeto. Maullar, Saltar, Araar son ejemplos de operaciones que se
aplican a un objeto gato, en el marco del sistema pelculas dibujos animados.
Mtodo: es una implementacin especfica de una operacin ejecutable por una

cierta clase. Codificar las operaciones como Maullar, Araar en algn lenguaje.
Polimorfismo: significa que una operacin puede comportarse de modos

distintos en distintas clases teniendo el mismo nombre de mtodo. La operacin
mover se puede comportar distinto en las clases prrafo y pieza de ajedrez. En
trminos prcticos, el polimorfismo permite referirse a objetos de diferentes
clases, por medio del mismo elemento de programa y realizar la misma operacin
de formas diferentes, de acuerdo al objeto a que se hace referencia en cada
momento. En el mundo real una operacin es simplemente, una abstraccin de
comportamiento anlogo entre distintas clases de objetos. Cada objeto sabe llevar
a cabo sus propias operaciones. Sin embargo, en un lenguaje orientado a objetos
es ste el que selecciona automticamente el mtodo correcto para implementar
una operacin basndose en el nombre de la operacin y en la clase del objeto
que est siendo afectado. El usuario de una operacin no necesita ser consciente
del nmero de mtodos que existen para implementar una cierta operacin
polimrfica. Se pueden aadir clases sin modificar el cdigo existente, siempre y
cuando se proporcione mtodos para todas las operaciones aplicables a las
nuevas clases. Por ejemplo para la clase gato, saltar puede diferenciarse de la
operacin saltar para la clase perro.

Herencia es compartir atributos y operaciones entre clases tomando como base

una relacin jerrquica. En trminos generales se puede definir una clase que
despus se ir refinando sucesivamente para producir subclases. Todas las
subclases poseen o heredan todas y cada una de las propiedades de su
superclase y aaden, adems, sus propiedades exclusivas. No es necesario
repetir las propiedades de las superclases en cada subclase. Por ejemplo,
ventana de desplazamiento y ventana fija son subclases de ventana. Ambas
subclases heredan las propiedades de ventana tales como una regin visible en
la pantalla. La ventana de desplazamiento aade una barra de desplazamiento y
un botn ascensor. La capacidad de sacar factor comn a las propiedades de
varias clases en una superclase comn y de heredar las propiedades de la
superclase puede reducir muchsimo la repeticin en el diseo y en los programas
siendo una de las ventajas principales de un sistema orientado a objetos. Otro
ejemplo de subclases puede ser gato siams y gato de angora de la clase gato.
Abstraccin: consiste en centrarse en los aspectos esenciales de una entidad e

ignorar sus propiedades accidentales. En el desarrollo de sistemas esto significa
centrarse en lo que es y lo que hace un objeto antes de decidir cmo debera ser
implementado. La capacidad de utilizar herencia y polimorfismo proporciona una
potencia adicional. El uso de la abstraccin durante el anlisis significa tratar
solamente conceptos del dominio de la aplicacin y no tomar decisiones de
diseo o de implementacin antes de haber comprendido el problema. Un uso
adecuado de la abstraccin permite utilizar el mismo modelo para el anlisis,
diseo de alto nivel, estructura del programa, estructura de una base de datos y
documentacin. Un estilo de diseo independiente del lenguaje pospone los
detalles de programacin hasta la fase final, relativamente mecnica, del
desarrollo.
Encapsulamiento: denominado tambin ocultamiento de informacin consiste en

separar los aspectos externos del objeto, a los cuales pueden acceder otros
objetos, de los detalles internos de implementacin del mismo, que quedan
ocultos para los dems. El encapsulamiento evita que el programa sea tan
interdependiente que un pequeo cambio tenga efectos secundarios masivos. La
implementacin de un objeto se puede modificar sin afectar a las aplicaciones que
la utilizan. Quizs sea necesario modificar la implementacin de un objeto para
mejorar el rendimiento, corregir un error, consolidar el cdigo o para hacer un
transporte a otra plataforma. El encapsulamiento no es exclusivo de los lenguajes
orientados a objetos pero la capacidad de combinar la estructura de datos y el
comportamiento en una nica entidad hace que el encapsulamiento sea ms
potente y claro que en los lenguajes convencionales que separan las estructuras
de datos y el comportamiento.

Combinacin de datos y comportamientos: el enfoque orientado a objetos

tiene una sola jerarqua, jerarqua de clases. Unifica la jerarqua de estructuras de
datos y jerarqua de procedimientos que presentan los enfoques convencionales.
Cuando un objeto invoca una operacin no necesita considerar cuntas
implementaciones existen de una operacin dada. El polimorfismo de operadores
traslada la carga de decidir que implementacin hay que utilizar llevndola, del
cdigo que hace la llamada, a la jerarqua de clases. El mantenimiento es ms
sencillo porque el cdigo que hace la llamada no necesita ser modificado cuando
se aade una clase nueva. En el contexto de un sistema orientado a objetos la
jerarqua de estructuras de datos es idntica a la jerarqua de herencia de
operaciones.
Reutilizacin: la herencia tanto de estructuras de datos como de

comportamientos, permite compartir una estructura comn entre varias subclases
similares sin redundancia. Una de las principales ventajas de los lenguajes
orientados a objetos es compartir cdigo empleando la herencia. Esto reduce el
nmero de clases distintas que es preciso comprender y analizar.
El desarrollo orientado a objetos no slo permite compartir informacin dentro de
una aplicacin sino que, adems, ofrece la perspectiva de volver a utilizar diseos
y cdigos en futuros proyectos. An cuando esta posibilidad se ha hecho resaltar
excesivamente como justificacin de la tecnologa orientada a objetos, el
desarrollo orientado a objetos proporciona herramientas tales como la
abstraccin, encapsulado y herencia para construir bibliotecas de componentes
reutilizables. Se debe tener presente que la reutilizacin no sucede, debe ser
planeada pensando ms all de la aplicacin inmediata y se debe invertir un
esfuerzo adicional en lograr un diseo mas general.
2.5.2 FASES DEL CICLO DE VIDA ORIENTADO A OBJETOS
Los sistemas tienden a evolucionar con el tiempo, por esto, un modelo

evolutivo de proceso acoplado con un enfoque que fomenta la reutilizacin de
componentes es el mejor paradigma para ingeniera de software OO. El proceso
OO se mueve a travs de una espiral evolutiva que puede considerar el desarrollo
incremental e iterativo de prototipos.
Es posible aplicar conceptos orientados a objetos a lo largo del todo el ciclo

de vida de desarrollo del sistema, desde el anlisis hasta la implementacin
pasando por el diseo. Se pueden traspasar las mismas clases de una etapa a
otra sin modificar la notacin aunque ganarn detalles adicionales de
implementacin en las etapas posteriores. Los mismos conceptos orientados a

objetos de identidad, clasificacin, polimorfismo y herencia son aplicables a todo

el ciclo de desarrollo completo.
Existen diversas propuestas de metodologas de desarrollo de sistemas de

informacin basadas en el paradigma de OO. Las metodologas orientadas a
objetos ms conocidas son:
OMT (Object Modelling Technique) de Rumbaugh [Rumbaugh, J. y otros
1996].
El micro y macroproceso de Booch [Booch, G. 1996].
OOSE (Object Oriented Software Engineering) de Jacobson [Jacobson, I.
1992].
Tambin existe el mtodo Proceso Unificado (Unified Software
Development) [Jacobson, I. y otros 1999], nacido de la fusin de los 3
mtodos mencionados.
En la figura 2-5 se muestra el ciclo de vida Orientado a objetos.
DISEO
ANALISIS OO ARQUITECTURA
DISEO OO
DESCRIPCION DEL PROBLEMA
IDENTIFICAR CLASES, OBJETOS Y
RELACIONES
BUSCAR CLASES REUSABLES
COMPLETAR MODELO DE
CREAR NUEVAS CLASES
OBJETOS
MODELIZACION FUNCIONAL
ESPECIFICAR INTERFASES
MODELIZACION DINAMICA
BUSCAR CLASES REUSABLES
REFINAR LOS MODELOS
CREAR NUEVAS CLASES
BALANCEAR LOS MODELOS
MANTENIMIENTO PROGRAMACION
PRUEBA OO
FIGURA 2-5: Ciclo de Vida Orientado a Objetos
Anlisis OO: El anlisis estudia el comportamiento del sistema en su totalidad. El

objetivo de la actividad de anlisis consiste en exponer y comprender el problema
y conceptos del dominio de la aplicacin, dejando de lado conceptos de
implementacin. El modelo de anlisis es una abstraccin de lo que debe hacer el
sistema deseado y no de la forma en que se har. Un buen modelo podr ser
comprendido y revisado por expertos de la aplicacin que no sean programadores

[Rumbaugh, J. y otros 1996]. El modelo de anlisis no debe contener ninguna
decisin de implementacin, los objetos se describirn en trminos de atributos y
operaciones que son visibles para el usuario.
El comienzo de la fase de anlisis es una descripcin inicial del problema que hay
que resolver. La definicin de este problema no suele ser completa ya que es
generada por el cliente y, por lo tanto, no debe tomarse como invariable. No es
ms que un punto de partida que debe servir como base para refinar los requisitos
reales. No existe ninguna razn para esperar que la definicin del problema que
se haya preparado sin un anlisis completo sea la correcta.
El primer paso consiste en establecer los requisitos bsicos. Estos deben ser
comunicados por el cliente al Ingeniero de Software. Es imprescindible la
comprensin en su totalidad del problema de tal forma que el Ingeniero de
Software debe trabajar con el solicitante hasta refinar los requisitos y lograr que
los mismos representen la verdadera intencin del usuario.
El resultado del anlisis es un modelo formal que representa en forma concisa el
problema y permite construir una solucin. Se genera una representacin del
mundo real compuesto por distintos modelos en los que se analizan la estructura
esttica (objetos y sus relaciones), secuencia de acciones (dinmica de las
funciones del sistema) y transformacin de datos (funciones o procesos).
Las actividades de esta fase son:
Definir y revisar las clases, y la jerarqua de clases
Definir y revisar los atributos y las operaciones asociadas a una clase.
Establecer las relaciones entre clases.
Crear y revisar un modelo de comportamiento
Marcar clases reutilizables
Definir los modelos funcionales y dinmicos.
La OO enfatiza la reutilizacin de objetos, por lo tanto, una actividad importante
del anlisis del sistema es buscar clases en una biblioteca (de clases OO
existentes) antes de construir otras.
Es poco probable definir las clases necesarias para un gran sistema o producto
en una sola iteracin. El anlisis OO y los modelos de diseo van evolucionando y
surge la necesidad de clases adicionales. El proceso iterativo de la fase se
muestra en la figura 2-5 dentro de un cuadro de lneas punteadas.
Diseo Arquitectura: El diseo de sistema es la primera fase del diseo donde

se selecciona la aproximacin bsica para resolver el problema decidiendo la
estructura y el estilo global.
Existe un cierto nmero de estilos de arquitectura, cada uno de los cuales es
adecuado para ciertas clases de aplicaciones. La arquitectura del sistema est
constituida por su descomposicin en subsistemas, su concurrencia inherente, la
asignacin de subsistemas a hardware y a software, la administracin de datos, la

coordinacin de recursos globales, la implementacin del control de software, las
condiciones de contorno y las prioridades de compensacin. Cada uno de los
puntos mencionados son caractersticas que el diseador de sistemas deber
decidir.
Un sistema se puede dividir en un pequeo nmero de componentes principales
denominados subsistemas. Los mismos comparten alguna propiedad comn y a
su vez pueden descomponerse en subsistemas propios an ms pequeos. Los
subsistemas de ms bajo nivel se denominan mdulos. Se asignan los
subsistemas a procesadores y a tareas. Cada subsistema debe ser asociado a
una unidad de hardware, a un procesador de propsito general o a una unidad
funcional especializada.
Es posible utilizar almacenes de datos para separar subsistemas distintos dentro
de una arquitectura y para dar a los datos de la aplicacin un cierto grado de
permanencia. Estos almacenes se pueden implementar mediante estructuras de
datos en memoria, archivos y/o bases de datos.
El diseador de sistemas debe identificar los recursos globales y tiene que
determinar mecanismos para controlar el acceso a los mismos. Existen dos clases
de flujos de control: Control externo y Control interno.
El control interno es el flujo de control dentro de un proceso, mientras que el
control externo es el flujo de los sucesos externamente visibles entre los objetos
del sistema. Adems existen 3 clases de control para sucesos externos:
secuencial controlado por procedimientos, secuencial controlado por sucesos y
concurrente.
La mayora del diseo trata del comportamiento estacionario, no obstante es
preciso considerar tambin las condiciones de contorno: Iniciacin, Terminacin y
Fallos.
Un aspecto esencial de la arquitectura del sistema es establecer prioridades de
compensacin entre tiempo y espacio, hardware y software, sencillez y
generalidad y eficiencia y mantenibilidad. Para esto no debe considerarse slo el
software en s mismo sino tambin el proceso de desarrollo.
Diseo OO: El diseador de objetos construye un modelo de diseo basndose

en el modelo de anlisis que lleven incorporados detalles de implementacin; es
decir durante esta fase se elaboran los modelos de anlisis, se refinan y
finalmente se optimizan para producir un diseo prctico.
Durante esta fase existe un desplazamiento del foco de atencin desde los
conceptos de la aplicacin hasta los conceptos de la computadora haciendo
hincapi en las estructuras de datos y los algoritmos necesarios para implementar
cada una de las clases.
No se parte de cero, sino que las operaciones identificadas durante el anlisis
deben expresarse en forma de algoritmos sencillos optimizando as la estructura
del modelo de objetos con el objetivo de lograr una implementacin eficiente y

optimizando medidas importantes de rendimiento.
Tanto los objetos del dominio de la aplicacin como los objetos del dominio de la
computadora se describen utilizando unos mismos conceptos y una misma
notacin orientados a objetos an cuando existan en planos conceptuales
diferentes.
Algunas clases no forman parte del anlisis sino que se presentan como parte del
diseo o de la implementacin. Por ejemplo, las estructuras de datos tales como
rboles, tablas de dispersin y listas enlazadas no suelen estar presentes en el
mundo real. Se presentan para que presten su apoyo a algoritmos concretos
durante el diseo. Estos objetos de estructuras de datos se utilizan para
implementar objetos dentro de la computadora y no derivan directamente sus
propiedades del mundo real.
Los pasos que debe llevar a cabo el diseador son:
El diseador debe transformar las acciones y los procesos del modelo
funcional en operaciones asociadas a las clases del modelo de objetos
haciendo corresponder la estructura lgica del modelo de anlisis en una
organizacin fsica de un programa
Se seleccionan algoritmos que muestran cmo se hace la operacin
especificada durante el anlisis teniendo en cuenta complejidad
computacional, facilidad de implementacin y comprensibilidad, flexibilidad y
ajuste fino del modelo de objetos
Seleccionar estructuras de datos que organicen la informacin del modelo de
anlisis de forma cmoda para los algoritmos que la utilizan. Entre estas
estructuras de datos se cuentan las matrices, listas, colas, pilas, conjuntos,
bolsas, diccionarios, asociaciones, rboles y variaciones de todas ellas
Definir nuevas clases y operaciones internas necesarias y que no fueron
directamente mencionadas en la descripcin del problema por parte del cliente
Aadir asociaciones redundantes para minimizar el tiempo de acceso.
Se implementa el modelo dinmico teniendo en cuenta tres aproximaciones
bsicas: sistema controlado por procedimientos, sistema controlado por
sucesos y utilizacin de tareas concurrentes.
Se ajustan las definiciones de las clases y las operaciones con el objetivo de
incrementar la herencia. Se reorganizan clases y operaciones teniendo en
cuenta que todas las operaciones deben tener la misma interfaz, la misma
semntica y la misma signatura previo a poder utilizar la herencia
Se disea la implementacin de asociaciones. Cada asociacin se implementa
como un objeto por separado o bien aadiendo atributos de enlace cuyos
valores sean objetos a una de las clases de la asociacin (o a las dos)

Se empaquetan las clases y las asociaciones en mdulos. El

empaquetamiento implica ocultar la informacin interna a los ojos del exterior,
coherencia de entidades y construccin de mdulos fsicos.
Es importante considerar que el diseo orientado a objetos es un proceso
iterativo.
La documentacin del diseo de objetos es un conjunto de modelos entre los que
se destacan: el modelado de objetos detallado, el modelado dinmico detallado y
el modelo funcional detallado, tanto en forma grfica (diagrama del modelo de
objetos), como en forma textual (descripcin de clases).
Programacin OO: Las clases de objetos y las relaciones desarrolladas durante

el diseo se traducen finalmente a un lenguaje de programacin concreto, a una
base de datos o a una implementacin en hardware. La programacin debera ser
una parte relativamente pequea del ciclo de desarrollo y fundamentalmente
mecnica porque todas las decisiones importantes debern hacerse durante el
diseo. El lenguaje de destino influye en cierta medida sobre las decisiones de
diseo pero ste no debera depender de la estructura final de un lenguaje de
programacin.
La manera ms directa de implementar un diseo OO es usando un lenguaje
orientado a objetos, pero incluso los lenguajes orientados a objetos ofrecen
distintos grados de apoyo para los conceptos OO. Cada lenguaje supone un
compromiso entre la potencia conceptual, eficiencia y compatibilidad con los
trabajos anteriores. El uso de un lenguaje no orientado a objetos exige mayor
cuidado y disciplina para mantener la estructura de objetos en el programa. Para
implementar un diseo OO en un lenguaje OO deben tenerse en cuenta
[Rumbaugh, J. y otros 1996]:
Definicin de clases
Creacin de objetos
Llamadas a operaciones
Uso de la herencia
Implementacin de asociaciones
Algunos sistemas de bases de datos OO integran un lenguaje OO con una base
de datos como un todo, sin discontinuidades. Se pueden definir operaciones para
cada clase de objetos, pero el programador no necesita leer y escribir
explcitamente en un almacenamiento persistente. Aun cuando los sistemas de
base de datos OO prometen un redimiendo mejor y mas facilidad de uso a largo
plazo todava no son tan maduros como los sistemas convencionales de bases de
datos relacionales y adems pueden plantearse problemas para integrarlos con
aplicaciones convencionales ya existentes.
Durante la codificacin es posible que sea necesario [Booch, G. 1996]:
Aadir una nueva clase o una nueva colaboracin entre clases
Cambiar el diseo de una clase

Cambiar la representacin de una clase
Reorganizar la estructura de clases
Cambiar la interfaz de una clase
La implementacin de un diseo OO en un lenguaje no OO requiere que el
programador haga corresponder los conceptos de objetos con el lenguaje. Los
pasos necesarios son [Rumbaugh, J. y otros 1996]
Traducir las clases a estructuras de datos
Pasar argumentos a los mtodos
Reservar espacio para los objetos
Implementar la herencia en estructuras de datos
Implementar la resolucin de los mtodos
Implementar las asociaciones
Resolver la concurrencia
Encapsular los detalles internos de las clases
Los buenos programas siguen reglas de diseo tienen mayores posibilidades de
ser correctos, reutilizables, extensibles y fciles de corregir. Esas reglas deben
tener en cuenta la Reutilizacin, Extensibilidad, Robustez y la Programacin
Industrial [Rumbaugh, J. y otros 1996].
PRUEBA: La prueba debe ser una actividad continua durante el proceso de

desarrollo. Debe centrarse en el comportamiento externo del sistema. Un
propsito secundario de la prueba es tantear los lmites del sistema con el fin de
comprender como falla bajo ciertas condiciones. Debe abarcar al menos tres
dimensiones:
Prueba unitaria: Implica la prueba de clases y mecanismos individuales.
Prueba del subsistema: Implica probar una categora completa o subsistema.
Pueden utilizarse como pruebas de regresin para cada versin del prototipo,
verificando hasta que grado se satisface los puntos funcionales asignados.
Prueba del sistema: implica probar el sistema como un todo. Tambin se
pueden usar como pruebas de regresin cuando se ensamblan nuevas
versiones.
El control de calidad del software involucra un conjunto de actividades
sistemticas que proporcionan evidencia de la aptitud de uso del producto
completo. El control de calidad busca ofrecer medidas cuantificables de bondad
para la calidad del un sistema software, esas medidas son conocidas como
mtricas. Algunas mtricas tradicionales son aplicables directamente a los
sistemas OO pero otras han tenido que ser particularmente definidas para OO
[Ierache, J. 1999].
Se completa con xito esta fase cuando la funcionalidad y calidad de las
versiones son suficientes para expedir el producto.
MANTENIMIENTO: Es la actividad de gestionar la evolucin del producto. Es en

gran medida una reiniciacin del ciclo de las fases anteriores. Se realizan
cambios localizados en el sistema, se aaden nuevos requisitos y se eliminan
errores persistentes. Inmediatamente tras la entrega del sistema en produccin,
sus desarrolladores y usuarios finales tendrn probablemente una serie de
mejoras o modificaciones que les gustara realizar. A medida que hay mas
usuarios usando el sistema, se descubrirn nuevos errores y patrones de uso que
el control de calidad no pudo anticipar.
Si se ha hecho un buen trabajo previo el aadido de funcionalidad nueva o la
modificacin de algn comportamiento existente se har en forma natural. Las
actividades propias de esta fase son:
Asignar prioridad a las peticiones de mejoras bsicas o informes de errores
que denotan problemas del sistema, y estimar el costo de volver a
desarrollarlo.
Establecer una coleccin significativa de estos cambios y tratarlos como
puntos funcionales para la nueva versin.
Gestionar la siguiente evolucin de la versin. Esto implica versiones de
produccin y de depuracin de errores.
Se reconoce que s esta efectuando el mantenimiento del sistema si la
arquitectura sigue siendo flexible al cambio. Se reconoce que se precisa un nuevo
sistema cuando la respuesta a nuevas mejoras comienza a requerir recursos de
desarrollo excesivo y el costo de continuidad del sistema es mayor que desarrollar
uno nuevo.
2.5.3 MODELOS BASICOS DEL CV ORIENTADO A OBJETOS
Un modelo es una abstraccin de algo, cuyo objetivo es comprenderlo

antes de construirlo. Dado que los modelos omiten los detalles no esenciales es
ms sencillo manipularlos que manipular la entidad original. La abstraccin
permite enfrentarse a la complejidad. Para construir sistemas complejos, el
desarrollador debe abstraer distintas vistas del sistema, construir modelos
utilizando notaciones precisas, verificar que los modelos satisfacen los requisitos
del sistema y aadir, gradualmente, detalles para transformar los modelos en una
implementacin.
El paradigma de objetos [Booch, G. 1996], [Rumbaugh, J. y otros 1996],

[Martin, J. y Odell, J. 1994], emplea bsicamente tres clases de modelos para
describir el sistema: el Modelo de Objetos que describe los objetos del sistema y
sus relaciones; el Modelo Dinmico que describe las interacciones existentes

entre objetos del sistema; y el Modelo Funcional (o Casos de Uso) que describe
las transformaciones de datos del sistema. Todos los modelos son aplicables en
la totalidad de las fases del desarrollo y van adquiriendo detalles de
implementacin a medida que progresa el desarrollo. Un procedimiento tpico de
software contiene estos tres aspectos:
utiliza estructuras de datos (modelo de objetos),
secuencia las operaciones en el tiempo (modelo dinmico) y
transforma valores (modelo funcional).
El enfoque orientado a objetos se centra primordialmente en identificar

objetos procedentes del dominio de la aplicacin ajustndoles despus los
procedimientos porque es necesario describir qu est cambiando o
transformndose, antes de describir cundo y cmo cambia.. Soporta mejor las
evoluciones de los requisitos porque est basado en el entorno subyacente del
dominio de la aplicacin en si, ms que en los requisitos funcionales ad-hoc de un
nico problema.
2.5.3.1 MODELO DE OBJETOS
Describe la estructura esttica (de datos), de los objetos del sistema

(identidad, atributos y operaciones) y tambin sus relaciones. El modelo de
objetos contiene diagramas de objetos. Un diagrama de objetos es un grafo cuyos
nodos son clases de objetos y cuyos arcos son relaciones entre las clases. El
diagrama contiene clases de objetos organizados en jerarquas que comparten
una estructura y comportamiento comunes y que estn asociadas a otras clases.
Estas clases definen los atributos que lleva cada instancia de objeto y las
operaciones que efecta o sufre cada uno. En cada instancia de la clase se
guardan los valores de esos atributos.
Para la construccin del modelo de objetos los pasos pueden ser:
Primer paso Se identifican las clases de objetos relevantes en el dominio de la

aplicacin para lo cual se definen clases de objetos tentativas y luego
con el fin de retener las clases correctas se eliminarn todas aquellas
consideradas triviales y/o errneas.
Segundo paso Se prepara un diccionario de datos, se describe el alcance de la

clase dentro del problema estudiado, las asociaciones (relaciones),
atributos y operaciones (procesos.
Tercer paso Se identifican asociaciones entre clases reteniendo aquellas que

resulten adecuadas.
Se reconocen atributos de los objetos descartando aquellos que

resulten innecesarios e incorrectos.
Cuarto paso Se organizan y simplifican las clases de objetos utilizando la herencia

para compartir una estructura comn.
Quinto paso Se itera y refina el modelo de objetos

En caso de presentarse algn error se debe volver a etapas
anteriores, si es necesario, para poder corregirlo. Es poco comn que
un modelo de objetos sea correcto a la primera pasada.
Sexto paso Se deben agrupar las clases y asociaciones fuertemente acopladas

en mdulos
Un mdulo es un conjunto de clases que captura algn subconjunto
lgico del modelo completo.
2.5.3.2 MODELO DINMICO
Describe los aspectos de comportamiento (de control) de un sistema, que

cambian con el tiempo. El modelo dinmico se utiliza para especificar e
implementar los aspectos del control del sistema. Los modelos dinmicos
contienen diagramas de estados. Un diagrama de estados es un grafo cuyos
nodos son estados y cuyos arcos son transiciones entre estados causadas por
sucesos o eventos.
Se especifican en este modelo la temporizacin y secuencia de

operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados
que definen el contexto para los sucesos), y la organizacin de sucesos y de
estados. El modelo dinmico captura el control, aquel aspecto de un sistema que
describe las secuencias de operaciones que se producen sin tener en cuenta lo
que hagan las operaciones, aquello a lo que afecten o la forma en la que estn
implementadas. Las acciones de los diagramas de estado se corresponden con
funciones procedentes del modelo funcional; los sucesos de un diagrama de
estado pasan a ser operaciones que se aplican a objetos dentro del modelo de
objetos. Para construir un modelo dinmico se deben seguir los siguientes pasos:
Primer paso Se preparan escenarios de sesiones tpicas y excepcionales: Se

comienza preparando escenarios para casos "normales" luego se
consideran los casos "especiales" y por ltimo los casos en los que
el usuario comenta algn error.
Un escenario es una secuencia de sucesos. stos se producen
siempre que se intercambia informacin entre un objeto del
sistema y un agente externo.
Segundo Paso Identificacin de sucesos que acten entre objetos y seguimientos

de sucesos para cada escenario: Entre los sucesos externos

contamos todas las seales, entradas, decisiones, interrupciones,
transacciones y acciones procedentes o destinadas al usuario o a
dispositivos externos.
Se deben agrupar con el mismo nombre aquellos sucesos que
tengan el mismo efecto sobre el flujo de control, an cuando
difieren los valores de sus parmetros.
Un diagrama de flujo de sucesos resume los sucesos habidos entre
clases sin tener en cuenta la secuencia e incluyendo sucesos
procedentes de todos los escenarios y los sucesos de error.
Tercer Paso Construccin de un diagrama de estado: Se construye un diagrama

de estados para cada clase de un objeto que tenga un
comportamiento dinmico no trivial. El mismo deber mostrar las
tramas de sucesos que reciba y enve junto con las acciones que
lleve a cabo.
Cuarto Paso Correspondencia de sucesos entre objetos: Una vez que los
diagramas de estado para todas las clases estn completos hay
que comparar sucesos entre los mismos para comprobar la
congruencia en el nivel del sistema.
Las consideraciones a tener en cuenta son:
Todo suceso debera tener un emisor y un receptor
Son sospechosos los estados sin predecesores o sucesores
Si se produce una entrada en un momento inoportuno se debe
tener cuidado con errores de sincronizacin
"El conjunto de diagramas de estado es lo que constituye el modelo
dinmico".
2.5.3.3 Modelo Funcional
Describe las transformaciones, de valores de datos que ocurren dentro del

sistema, captura lo que hace el sistema, independientemente de cuando se haga
o de la forma en que se haga. El modelo funcional contiene diagramas de flujo de
datos. Un diagrama de flujo de datos es un grafo cuyos nodos son procesos y
cuyos arcos son flujos de datos, se muestra las dependencias entre los valores y
el clculo de valores de salida a partir de los de entrada, sin considerar cundo y
dnde se ejecutan las funciones, ni siquiera si llegan a ejecutarse. Las funciones
se invocan como acciones en el modelo dinmico y se muestran como
operaciones que afectan a objetos en el modelo de objetos.
Para mostrar dependencias funcionales resultan tiles los diagramas de

flujo de datos. En un diagrama de flujo de datos sus procesos se corresponden
con actividades de los diagramas de estado de las clases y sus flujos de datos
con valores de atributos de un diagrama de objetos. Los pasos a seguir para
construir un modelo funcional son:
Primer paso Identificar valores de entrada y de salida: Se comienza por

enumerar los valores de entrada y de salida que son los parmetros
de los sucesos que se intercambian entre el sistema y el mundo
exterior.
Segundo Paso Construir diagramas de flujo de datos que muestren las

dependencias funcionales: Se construye un diagrama de flujo de
datos que muestra la forma en que se calcula cada valor de salida a
partir de los de entrada.
Generalmente los diagramas de flujo de datos suelen construirse
por capas y contienen objetos internos de almacenamiento que
retienen valores entre iteraciones.
Tercer Paso Descripcin de funciones: Una vez que el Diagrama de flujo de

datos se ha refinado lo suficiente se debe describir cada funcin
centrndose en lo que hace y no en la forma de implementarla.
Las descripciones especifican las relaciones entre los valores de
entrada y los de salida. El propsito es especificar el algoritmo de
transformacin.

Captulo 3
Definicin del
problema
En este captulo se presenta una definicin del objetivo y alcance del

proyecto especificando las caractersticas del problema a resolver y los
participantes. Se describe brevemente la metodologa IDEAL que es la
seleccionada para desarrollar el sistema. Como cierre del captulo se presenta un
plan del proyecto que es la base sobre la cual se cumplen las actividades de
gestin.
3.1 PLANTEAMIENTO DEL PROBLEMA
Una de las tareas iniciales de todo proyecto de software consiste en

seleccionar el modelo de ciclo de vida que guiar el desarrollo del proyecto. Esta
tarea presenta una serie de dificultades:
Existen diversos modelos de ciclo de vida: cascada, prototipado de usar

y tirar, incremental, emisin gradual, mejora iterativa, ensamblaje de
componentes, espiral, prototipado operativo, prototipado rpido, etc. No
existe un modelo de ciclo de vida que funcione para cualquier proyecto.
Algunos de estos modelos tienen caractersticas similares.
El ingeniero software debe estudiar las caractersticas del proyecto y
seleccionar el modelo de ciclo de vida que ms se adapte a ellas. Las
bases para determinar el ciclo de vida ms adecuado son: la cultura de
la organizacin, la disponibilidad para correr riesgos, el dominio de
aplicacin, la volatilidad de los requisitos y cunto se comprenden
dichos requisitos.
Esta seleccin se realiza al inicio del proyecto y se deben considerar un
conjunto de variables de anlisis que requiere en su mayor parte de la
experiencia del ingeniero en software, ya que al inicio del proyecto
subyace una gran cuota de subjetividad en casi todos los aspectos del
proyecto.
La bibliografa disponible, con relacin al tema de seleccin de ciclos de
vida, si bien menciona el conjunto de variables a analizar, no presenta
un conocimiento sistemticamente organizado y no especifica cmo
debe realizarse el proceso para seleccionar el ciclo de vida para el
proyecto. [Juristo Juzgado, N. a 1996], [Juristo Juzgado, N. b 1996],
[IEEE, 1991], [ISO, 1994], [Royce, W.W. 1970], [Behm, B.W. 1987],
[Pressman, R.S. 1997], [Rumbaugh, J y otros 1996], [Booch, G. 1996],
[Jacobson, I. 1992], [Jacobson, I. y otros 1999]
DEFINICION DEL PROBLEMA 01/09/2003 Bibiana D. Rossi 49

3.2 OBJETIVO DEL TRABAJO
El objetivo principal de este trabajo consiste en desarrollar un prototipo de

Sistema Experto (SE) que asista al Ingeniero en Software en la seleccin del ciclo
de vida ms adecuado para el desarrollo de un proyecto de software en particular,
colaborando en el anlisis de las caractersticas mas relevantes a tener en
cuenta.
Para alcanzar este objetivo se plantean metas que son:

Usar las tcnicas de Ingeniera del Conocimiento para conocer y
documentar los criterios y experiencia utilizados por un grupo de
expertos para resolver el problema de seleccin del modelo de Ciclo de
Vida.
Iniciar el proceso para establecer un marco ordenado de variables a
tener en cuenta para decidir el ciclo de vida ms conveniente para el
desarrollo de un proyecto.
Utilizar la Metodologa Ideal en el desarrollo del Sistema.
Implementar el sistema usando la herramienta KAPPA-PC.
3.3 ALCANCE
Existen muchos modelos de ciclos de vida disponibles tanto en la

bibliografa como de uso particular de alguna organizacin. Dada la diversa
cantidad de modelos y la falta de sistematizacin y documentacin de las
variables que deben ser consideradas en la eleccin del ciclo de vida ms
adecuado, es necesario fijar una cota en el desarrollo del Sistema Experto, tanto
en los modelos como en las variables a considerar.
Se consideran los siguientes ciclos de vida: Cascada, Modelo en Espiral y

Modelo Orientado a Objetos. Se encuadra el desarrollo del Sistema Experto
teniendo en cuenta los aspectos ms sobresalientes de cada modelo. Respecto
de las variables, se determinarn las ms significativas que resulten del proceso
de Adquisicin de Conocimientos con los expertos.
3.4 AMBITO DEL PROYECTO
El desarrollo del Sistema Experto involucra a los siguientes participantes:

Experto principal: el experto recomendado para el proyecto es el Prof.

Gregorio Perichinsky, Doctor en Ingeniera informtica por la
Universidad de Buenos Aires (UBA), Director del Laboratorio de
Ingeniera de Software y Director del Departamento de Ciencias de la
Computacin de la Facultad de Ingeniera de la UBA.
Grupo de Expertos: son profesionales de sistemas que lideran el

desarrollo de proyectos de software y docentes universitarios que dictan
materias en las cuales uno de los temas es ciclos de vida y
metodologas para anlisis y diseo de sistemas de informacin.
Lic. Carlos Beltrami: Gerente de Sistemas de una fbrica de ropa
con sedes en todo el pas. Titular de la ctedra Sistemas de
Informacin de la Universidad Nacional de Catamarca.
Lic. Carlos Leone: Consultor y asesor en Informtica en el rea
Servicios Profesionales. Titular de la ctedra Diseo de Sistemas de
la Universidad Tecnolgica Nacional.
Ing. Mara Florencia Pollo Cattaneo: Secretaria tcnica del
Departamento de Sistemas. Prof. Asociada de la ctedra de Anlisis
de Sistemas en la Universidad Tecnolgica Nacional.
Lic. Laura Lucchini: Jefe de Divisin Sistemas y Profesora adjunta de
la ctedra Seminario de Sistemas en la Universidad Nacional de
Lujn.
Ing. Mariano Weschler: Socio gerente de una empresa consultora
que desarrolla software para e-bussiness. Docente auxiliar en la
ctedra de Anlisis de Sistemas en la Universidad Tecnolgica
Nacional.
Lic. Enrique Fernndez: Jefe de Programadores en la Gerencia de
Sistemas del Banco de la Ciudad de Buenos Aires. Auxiliar de
ctedra de Seminario de Sistemas en la Universidad Nacional de
Lujn.
Usuarios: los usuarios son los lderes de proyecto de desarrollo de

software. Docentes y alumnos universitarios de las carreras de
Informtica.
Ambito de uso del Sistema Experto: el rea de sistemas de una

empresa, empresas de desarrollo de software, ctedras de la
universidad.
Ambito de desarrollo del Sistema Experto: el plan de tesis de Magister

de CAPIS (Carrera de Posgrado en Ingeniera del Software) por acuerdo

entre el ITBA (Instituto Tecnolgico de Buenos Aires) y la UPM

(Universidad Politcnica de Madrid).
Evaluacin: se har con los usuarios del sistema y con el grupo de

expertos. Se cuenta con casos de prueba que aportan los expertos y los
propios usuarios.
Herramienta: el prototipo se desarrollar para ser usado en

computadoras personales.
3.5 METODOLOGA IDEAL
La metodologa IDEAL, presenta un ciclo de vida troncocnico en tres

dimensiones [Gmez, A. y otros 1997]. Su base es un modelo en espiral [Behm,
B.W. 1987] y la tercera dimensin representa el mantenimiento perfectivo una vez
implementado el SE.
El desarrollo del sistema se basa en la filosofa del modelo en espiral en

donde cada fase finaliza con un prototipo que conduce a la fase siguiente del
ciclo. El mantenimiento perfectivo involucra la incorporacin sistemtica de
nuevos conocimientos (adquiridos por el uso del sistema) tpica cualidad de un
SE. Los ejes de la base del cono representan el costo y el tiempo.
El eje de la calidad se representa de abajo hacia arriba; va de mayor

dimetro, o sea conocimientos menos especficos y de menor calidad, a menor
dimetro, conocimientos ms exactos y de mayor calidad. Al inicio del
funcionamiento del sistema se obtienen grandes cantidades de conocimientos de
distinta calidad pero a medida que el sistema se usa el conocimiento se refina, se
obtienen menos conocimientos, pero de mayor calidad.
La metodologa IDEAL presenta las siguientes fases y etapas [Gmez, A. y

otros 1997]:
FASE I: Identificacin de la tarea.
I.1. Plan de requisitos y adquisicin de conocimientos. Definir con los

usuarios cules son los objetivos cuantitativos, cualitativos y filosficos del
sistema a desarrollar. Definir las limitaciones de costo y tiempo, tecnologa
disponible. Sirve de base para el estudio de viabilidad. Para completar el
Plan de Requisitos es necesario comenzar con la Adquisicin de
conocimientos, entrevistando directivos, expertos y usuarios. La
Adquisicin de conocimientos ms profunda corresponde a la Fase II.
Es
pec
ific
aci
on
es
de
int
egr
on
De aci
fin n
as n c
ici
ny
em aci vali
dac
r
in
s s nteg
de n
ue vas
ist
i
Dis
os
esp
ot de
in ecif
ev
icac
eo
s
ro
nu
to
ion
c
fin
es
isi
de
vali
int
De
qu
De
De
in
egr
Re
ad a
fin
ito
fin
y ap icin
ac
in e
aci
uis
lic
ici
cin
ac
lid
d ac de l
alu n
n
in a
req
va
Ev lecci cin
ny
se plica
dise
d el
Co n d
a
ci cin
nc e
nue
so
o
ep
lu
Plan de
vo
_
requisitos
Adquisicin y
Be
conceptualizacin
nc
del n zacin
del conocimiento
y
n
hm
ici
cin
ar
uevo
Mo
uis
to
ali
ci nto
k
pru menta
de
za
ien
ali imie
eptu
Sim
Adq
Imple
los
m
del p mentaci r c
ocim
Fo ono
ula
ro n
eba
dem totipo d lc
conc
pl
ostra e de
ci
, im
con
cin
n
n
Imple ci
cin
del p mentaci za
ro n ali
inve totipo d rm
gra
stiga
cin
e Fo
Inte
Imple vo
proto menta ue
tipo cin ln
Imp de c
amp de
l
d e ement
o to
pro ien
d u c acin oc
im
c i n prot n
(op o co ion
Tra
nsf e r a tipo tac
ere tivo ep
del ncia ) c
Sis y ea
tem mant ba
d
aC e
om nimien Pr
ue
erc
ial to
FIGURA 3-1 Modelo troncocnico de la metodologa IDEAL- Base
Nivel de acumulacin de conocimiento
Segundo nivel de
acumulacin de conocimiento
Primer nivel de
acumulacin de
conocimiento
Sistema comercial con el

conocimiento disponible en la
actualidad
FIGURA 3-2 Modelo troncocnico de la metodologa IDEAL- Eje de calidad

I.2. Evaluacin y seleccin de la tarea: Se realiza es estudio de viabilidad

del proyecto, desde la perspectiva de la INCO cuantificando la tarea para
determinar el grado de dificultad que presenta.
I.3 Definicin de las caractersticas del sistema: Especificar tcnica y
formalmente los requisitos del usuario, se pasa de una descripcin informal
de los requisitos del usuario a una especificacin tcnica completa hecha
por el IC. Se definen los requisitos Funcionales, Operativos, de Interfaz y
de Soporte. Se definen criterios de xito, casos de prueba o ensayo,
recursos necesarios, anlisis de costo/beneficio, evaluacin de riesgos,
calendario.
FASE II: Desarrollo de los prototipos.
Las especificaciones iniciales de los sistemas suelen ser incompletas,

imprecisas, inconsistentes, contradictorias. Obtener mayor grado de
precisin requiere el desarrollo de prototipos que permiten refinar con
mayor precisin los requerimientos. Se desarrollan paulatinamente los
prototipos de: Demostracin, Investigacin, Campo y Operacin, siendo
cada uno refinamiento del anterior. Para ello es necesario realizar ciertas
actividades existiendo ligeras diferencias entre las etapas del prototipo de
Demostracin y los otros.
II.1. Concepcin de la solucin: Descomposicin en Subproblemas y

Determinacin de analogas. Se produce un diseo general del prototipo.
Engloba dos actividades principales, el desarrollo del DFD (diagrama de
flujo de datos) y el diseo arquitectnico del sistema.
II.2. Adquisicin y Conceptualizacin de los conocimientos: Se alterna
la extraccin de los conocimientos pblicos de sus fuentes (libros,
documentos, manuales de procedimientos, etc.), la educcin de los
conocimientos privados de los expertos y la conceptualizacin para
modelar el comportamiento del experto.
II.3. Formalizacin de los conocimientos y Definicin de la
Arquitectura: Hay dos actividades fundamentales. Una es seleccionar los
formalismos para representar en la mquina los conocimientos que
conforman la conceptualizacin obtenida en la etapa anterior. Esta
formalizacin esta ligada con los tipos de conocimientos mas apropiado y
las herramientas disponibles en su desarrollo.
La otra es realizar un diseo detallado, hay que establecer los mdulos que
definen el motor de inferencias, la base de conocimientos y las interfaces
con el usuario y con otros sistemas.
II.4 Seleccin de la Herramienta e Implementacin: Si la herramienta de

desarrollo previamente seleccionada es adecuada la implementacin es
inmediata y automtica, caso contrario es similar a cualquier
implementacin de software, en donde ser necesario realizar la
programacin.
II.5. Validacin y evaluacin del prototipo: La fiabilidad de los resultados
es una de los puntos principales de un SE. Estos sistemas dependen en
gran medida del contexto y eso dificulta la determinacin de las
validaciones.
Se definen casos de prueba, juegos de ensayo o ensayo en paralelo. Se
examina la interfaz de usuario.
II.6. Definicin de nuevos requisitos y diseo: Es la definicin de los
requisitos, especificaciones y diseo del prototipo siguiente, para ello
deben repetirse las etapas II.1 a II.6.
FASE III: Ejecucin de la construccin del sistema integrado.
Los SE forman parte de sistemas software con los que interactan.
III.1. Requisitos y diseo de la integracin con otros sistemas. Es el

estudio y diseo de interfaces con otros sistemas, tanto en hardware como
en software.
III.2 Implementacin y evaluacin del Sistema Integrado: Se
implementa la integracin del SE con los otros sistemas existentes
hardware y software para conseguir un sistema final.
III.3. Aceptacin del sistema por el usuario: Es la ltima prueba por
parte de los usuarios y expertos, que debe satisfacer todos los
requerimientos, tanto en su fiabilidad como en su eficiencia.
FASE IV: Actuacin para conseguir el mantenimiento perfectivo.
IV.1. Definir el mantenimiento del sistema global: Se emplean las

tcnicas habituales de IS para establecer el mantenimiento correctivo
(correccin de errores) y el mantenimiento perfectivo (aumento de
funcionalidad del sistema).
IV.2. Definir el mantenimiento de las Bases de Conocimientos:
Considera la incorporacin de nuevos conocimientos, que se generan por
el propio uso del sistema. El anlisis de protocolos, como forma de
adquisicin de conocimientos es imprescindible. En consecuencia, es
necesario mentalizar a los expertos y usuarios finales del sistema en el uso
de dicho protocolos.

V.3. Adquisicin de nuevos conocimientos y Actualizacin del

sistema: El mantenimiento perfectivo es esencial ya que adems del
aumento de funcionalidades efecta la incorporacin de nuevos
conocimientos que se generan por el propio uso del SBC. Este
mantenimiento se ve reflejado en la tercera dimensin de la espiral tronco-
cnica. Hay que establecer mtodos para actualizar el sistema
incorporando los conocimientos adquiridos.
FASE V: Lograr una adecuada transferencia tecnolgica.
Esto es especialmente crtico en los SBC en donde se han detectado

diferencias considerables cuando los manejan sus diseadores con
respecto a su uso rutinario por los usuarios finales.
V.1. Organizar la transferencia tecnolgica: Definir sesiones de

entrenamiento de los diseadores con los usuarios, tanto para explicar el
manejo del propio sistema como para manejar y entender la
documentacin.
V.2. Completar la documentacin del sistema: Realizar un manual de

usuario amigable.
3.6 GESTION DEL PROYECTO
La gestin del proyecto implica actividades de planificacin, estimacin de

recursos, control de configuracin y evaluacin del proyecto.
3.6.1 PLANIFICACION
La planificacin consiste en definir las actividades a realizar, la duracin de

las actividades, la concurrencia y solapamiento de las mismas a travs de la red
de actividades.
Se adjunta al final de este captulo el Plan General de Gestin del Proyecto

donde se presentan las actividades a ser desarrolladas a lo largo del proyecto. El
desarrollo del presente trabajo de Tesis de Master abarca todas las Fases de la
metodologa IDEAL, con excepcin de las etapas III.1: Requisitos y diseo de la
integracin con otros sistemas y III.2: Implementacin y evaluacin del Sistema
Integrado, ya que no existe un sistema al que se deba integrar.

3.6.2 ESTIMACION DE RECURSOS
La estimacin es predecir los recursos humanos, tcnicos y econmicos

para cumplir con las actividades planificadas.
Los recursos humanos son:

El Experto principal: Prof. Perichinsky
El Grupo de Expertos: Lic. Beltrami, Lic. Leone, Ing. Pollo Cattaneo, Lic.
Lucchini, Ing. Weschler, Lic. Fernndez
Ingeniero en Conocimiento: Lic. Rossi
Los recursos tcnicos son:

Computador personal: Pentium, Ram 160, Disco Rgido 3Gb, CD 24X,
Impresora Deskjet 680
Software a usar : Kappa PC
Los recursos econmicos son:

Financiamiento parcial del proyecto por el Instituto Tecnolgico de
Buenos Aires, con un monto asignado en horas de trabajo equivalente a
8760 dlares.
3.6.3 CONTROL DE CONFIGURACION
Es una actividad cuya misin es controlar la evolucin de un sistema

software, y por lo tanto se debe realizar a lo largo de todo el ciclo de vida desde la
Identificacin de la tarea, incluyendo el Mantenimiento perfectivo, hasta que el
producto se retira. En el captulo 12 se documenta el Control de configuracin
definido para el presente proyecto.
3.6.4 EVALUACION DEL PROYECTO
La evaluacin del proyecto es un conjunto de actividades que se realizan

conjuntamente a medida que se van completando las fases de desarrollo
establecidas en la Planificacin. El proceso de Evaluacin se encuentra descripto
detalladamente en el captulo 9, Evaluacin.

octubre noviembre diciembre enero
Id Nombre de tarea Duracin 26/09 03/10 10/10 17/10 24/10 31/10 07/11 14/11 21/11 28/11 05/12 12/12 19/12 26/12 02/01 09/01 16/01
1 Desarrollo del Sistema Experto sobre Ciclos de Vida 140,13 das
2 Fase I: Identificacin de la tarea 18,13 das
3 I.1: Plan de requisitos y adquisicin de conocimientos 41 horas 19/10

4 I.2: Evaluacin y seleccin de la tarea 49 horas 09/11
5 I.3: Definicin de las caractersticas del sistema. 55 horas 06/12
6 Fase II: Desarrollo prototipos. 103,75 das
7 II.1: Concepcin de la solucin. 70 horas
8 II.2: Adquisicin y conceptualizacin de conocimientos 330 horas
9 II.3: Formalizacin de los conocimientos 120 horas
10 II.4: Implementacin. 180 horas
11 II.5: Validacin y evaluacin 100 horas
12 II.6: Definicin de nuevos requisitos, especificacin y diseo. 30 horas
13 Fase III: Ejecucin de la construccin del sistema integrado. 2 das
14 III.1. Requisitos y diseo de la integracion con otros sistemas 0 das
15 III.2: Implementacion y evaluacin del sistema integrado 0 das
16 III. 3: Aceptacion del Sistema por el usuario 16 horas
17 Fase IV: Actuacin para conseguir el mantenimiento perfectivo. 6 das
18 IV.1: Definir el mantenimiento del sistema global. 16 horas
19 IV.2: Definir el mantenimiento de las bases de conocimientos. 16 horas
20 IV.3: Adquisicin de nuevos conocimientos 16 horas
21 Fase V: Lograr una adecuada transferencia tecnolgica. 9,5 das
22 V.1: Organizar la transferencia tecnolgica 26 horas
23 V.2: Completar la documentacin del sistema. 50 horas
24 Preparacin de la Tesis de Master: 113,25 das
25 Armado del documento del trabajo de tesis 500 horas
26 Revisin y correccin del trabajo 180 horas
27 Presentacin final 70 horas

febrero marzo abril mayo
Id Nombre de tarea 23/01 30/01 06/02 13/02 20/02 27/02 05/03 12/03 19/03 26/03 02/04 09/04 16/04 23/04 30/04 07/05 14/05 21/05
1 Desarrollo del Sistema Experto sobre Ciclos de Vida
2 Fase I: Identificacin de la tarea
3 I.1: Plan de requisitos y adquisicin de conocimientos
4 I.2: Evaluacin y seleccin de la tarea
5 I.3: Definicin de las caractersticas del sistema.
6 Fase II: Desarrollo prototipos.
7 II.1: Concepcin de la solucin. 10/02

8 II.2: Adquisicin y conceptualizacin de conocimientos
9 II.3: Formalizacin de los conocimientos
10 II.4: Implementacin.
11 II.5: Validacin y evaluacin
12 II.6: Definicin de nuevos requisitos, especificacin y diseo.
13 Fase III: Ejecucin de la construccin del sistema integrado.
14 III.1. Requisitos y diseo de la integracion con otros sistemas
15 III.2: Implementacion y evaluacin del sistema integrado
16 III. 3: Aceptacion del Sistema por el usuario
17 Fase IV: Actuacin para conseguir el mantenimiento perfectivo.
18 IV.1: Definir el mantenimiento del sistema global.
19 IV.2: Definir el mantenimiento de las bases de conocimientos.
20 IV.3: Adquisicin de nuevos conocimientos
21 Fase V: Lograr una adecuada transferencia tecnolgica.
22 V.1: Organizar la transferencia tecnolgica
23 V.2: Completar la documentacin del sistema.
24 Preparacin de la Tesis de Master:
25 Armado del documento del trabajo de tesis
26 Revisin y correccin del trabajo
27 Presentacin final
junio julio agosto septiembre
7 II.1: Concepcin de la solucin.
8 II.2: Adquisicin y conceptualizacin de conocimientos 10/07

9 II.3: Formalizacin de los conocimientos 04/09
25 Armado del documento del trabajo de tesis 25/09

octubre noviembre diciembre enero feb
10 II.4: Implementacin. 21/11

26 Revisin y correccin del trabajo 21/11

ero marzo abril mayo junio
11 II.5: Validacin y evaluacin 13/02

12 II.6: Definicin de nuevos requisitos, especificacin y diseo. 06/03
16 III. 3: Aceptacion del Sistema por el usuario 20/03

18 IV.1: Definir el mantenimiento del sistema global. 20/03

19 IV.2: Definir el mantenimiento de las bases de conocimientos. 03/04
20 IV.3: Adquisicin de nuevos conocimientos 12/04
22 V.1: Organizar la transferencia tecnolgica 27/03

23 V.2: Completar la documentacin del sistema. 03/05
27 Presentacin final 04/06

Captulo 4
Estudio de
Viabilidad
SISTEMA EXPERTO SELECCIN DEL MODELO DE CICLO DE VIDA
En el presente captulo se describe el Test de Viabilidad que propone la

Metodologa IDEAL. Luego se detalla el anlisis de viabilidad para el proyecto,
justificando los valores definidos en el test. A continuacin se evala la viabilidad
del proyecto
4.1 TEST DE VIABILIDAD
El estudio de viabilidad permite determinar si la solucin de un problema es

viable con sistemas informticos basados en conocimiento, o no.
La metodologa IDEAL propone un test de viabilidad en el que se analizan

4 factores de viabilidad. El desarrollo de un SE debe considerar si es posible, est
justificado, es apropiado y si va a tener xito.
Plausibilidad: determina si se cuenta con los medios necesarios para poder

abordar el problema desde la Ingeniera del Conocimiento (INCO). Para ello se
analizan dos aspectos bsicos: las caractersticas del experto y las
caractersticas de la tarea que lleva adelante el experto.
Del experto se analiza si existe, si es reconocido como tal por sus colegas, si
es cooperativo y si es capaz de articular sus mtodos y procedimientos de
trabajo. Es importante que el experto haya resulto el problema con suficiente
frecuencia y que est realmente interesado en el desarrollo del sistema.
De la tarea se analiza su grado de dificultad, si est adecuadamente
estructurada y qu tipo de habilidades se requieren para realizarla.
Justificacin: determina si se justifica utilizar sistemas expertos. Se analizan

los aspectos de la necesidad de la experiencia y de la inversin a realizar.
De la experiencia se analizan las caractersticas del entorno en donde hay que
realizar la tarea (peligrosidad, distancia) y la escasez o posible prdida de la
experiencia.
De la inversin se analizan los costos del sistema, la recuperacin de la
inversin, el valor de la tarea a resolver y si existen soluciones alternativas.
Adecuacin: determina si la INCO permite abordar el problema. Existen

problemas que no son adecuados para ser resueltos por la INCO ya que son
resolubles por algoritmos convencionales o que requieren de sentido comn.
Se analiza la naturaleza de la tarea, la complejidad de la tarea y el tipo de
tarea.
ESTUDIO DE VIABILIDAD 01/09/2003 Bibiana D. Rossi 65

xito: determina si existe colaboracin y predisposicin por parte del experto

para el desarrollo del sistema, conviccin de los directivos para afrontar los
costos del desarrollo y predisposicin de los usuarios en general.
Para estudiar la viabilidad del proyecto se utiliza el mtodo propuesto en la

metodologa IDEAL. El mtodo propuesto consiste en completar una tabla donde
se valoran un conjunto de variables para luego estimar si el sistema experto es
posible, est justificado, es adecuado y tendr xito. El mtodo es de tipo mtrico,
usa ponderaciones, como mtrica utiliza la media armnica e incorpora la
manipulacin de valores lingsticos mediante intervalos difusos.
Los valores que pueden asignarse a las variables son de diferente tipo:
Numricos: Valores discretos en un intervalo [1,10]
Booleanos: Valores: S No. Su representacin mediante intervalos

difusos es:
S 10 10 10 10
No 0 0 0 0
Lingsticos: Valores: Nada, poco, regular, mucho, todo. Son traducidos

a valores difusos para poder realizar los clculos correspondientes, de
acuerdo con la siguiente tabla.
Nada 0 0 1.2 2.2

Poco 1.2 2.2 3.4 4.4
Regular 3.4 4.4 5.6 6.6
Mucho 5.6 6.6 7.8 8.8
Todo 7.8 8.8 10 10
El procedimiento para aplicar la tcnica es el siguiente:
Paso 1: completar la columna VALOR en la tabla.
En las filas se detallan cada una de las caractersticas consideradas

para establecer la viabilidad del proyecto.
Los valores de las columnas, excepto el ltimo (que corresponde a la
columna VALOR), estn predeterminados en funcin de la experiencia
de los autores que proponen el mtodo. Puede modificarse alguno de
ellos si el INCO lo cree necesario. Las columnas se dividen de la

siguiente manera:
9 CATEGORIA: especifica con quien est relacionada la
caracterstica. Valores EXPERTO, TAREA, DIRECTIVO/USUARIO
9 DIMENSION: referencia con qu grupo bsico est relacionada la
caracterstica. Valores Pn (Posible), Jn (Justificado), An (Adecuado),
En (Exitoso)
9 PESO: valora la importancia relativa de esa caracterstica con
relacin al test, valores 1 a 10. Valora si la caracterstica favorece o
disminuye el grado de inters en el desarrollo del SE, valores +, -.
Estos valores los fija el INCO.
9 TIPO: referencia la importancia de la caracterstica en el proyecto.
Valores ESENCIAL, DESEABLE.
9 NATURALEZA: referencia el tipo de valores de la caracterstica.
DIFUSA, NUMRICA, o BOOLEANA.
9 UMBRAL: referencia al valor mnimo que es necesario superar para
esa caracterstica, si es esencial.
9 VALOR: asignado por quien est evaluando el proyecto.
Paso 2: calcular el valor de cada dimensin. Para las dimensiones de

plausibilidad, adecuacin y xito se usa la frmula:
ri ri
1 Pik 1
PikVik
VCi = k =1
ri
+ k =1
2 Pik 2 ri

K =1 Vik
k =1
Pik
VCj : Valor global de la aplicacin para un factor dado.

Vik : Valor de la caracterstica k en la dimensin i.
Pik : Peso de la caracterstica k en la dimensin i.
ri : Numero de la caracterstica en la dimensin i.
Para la dimensin de justificacin se toma el valor mximo de los valores

asignados a cada una de las caractersticas de ese factor al multiplicar por el peso
asociado y luego se calcula la aproximacin numrica de los intervalos difusos y
se toma el mximo.
Paso 3: calcular el valor final. Consiste en el clculo de la media aritmtica

ponderada del resultado obtenido para cada dimensin. Los valores de
ponderacin son:

Plausibilidad 8
Adecuacin 8
Justificacin 3
Exito 5
P Vi i
Vf = i =1
4
P
i =1
i
El desarrollo del Sistema Experto se considera viable si el valor final es

igual o mayor a 6.
4.2 ANALISIS DE VIABILIDAD PARA EL PROYECTO
A continuacin se enumeran todas las caractersticas del test de viabilidad

y se acompaa una breve justificacin del valor asignado a cada una.
4.2.1 JUSTIFICACIN DE LA DIMENSION PLAUSIBILIDAD
P1: Existen expertos, estn disponibles y son cooperativos.

Valor: SI
Existe un grupo de expertos en el mbito empresarial y acadmico, que se
desempean laboralmente, liderando proyectos de desarrollo de sistemas de
informacin y de investigacin aplicada, interesados en la construccin del
sistema, como apoyo en su tarea de gestin al inicio del proyecto.
Existe un grupo de expertos, que se desempean en el mbito universitario, en
las ctedras de anlisis y diseo de sistemas de informacin interesados en la
construccin del sistema, como apoyo para la prctica del tema.
Existe un experto principal Prof. Perichinsky dispuesto a cooperar en forma
directa durante el desarrollo del sistema con quien se ha establecido ya un
cronograma semanal de encuentros.
P2: El experto es capaz de estructurar sus mtodos y procedimientos de trabajo.

Valor: MUCHO
Los expertos han demostrado ser ordenados en sus procedimientos de trabajo, a
lo que se suma la habilidad como docente en la didctica que manifiestan en sus
explicaciones. El grupo de expertos universitarios tiene habilidades para facilitar

las explicaciones. El grupo de expertos empresariales es ordenado en sus

procedimientos de trabajo.
Se ha considerado particularmente en la evaluacin de esta caracterstica el
grado de dificultad que se presenta al ser un grupo de expertos los consultados.
P3: La tarea est bien estructurada y se entiende.

Valor: REGULAR
La tarea es clara, se entiende y est poco estructurada. Existe bastante
informacin disponible de las variables a considerar, pero no estn estructuradas
con precisin. Es justamente uno de los puntos que interesa especialmente al
conjunto de expertos: que el desarrollo del sistema introducir una propuesta para
estructurar con mayor precisin el conjunto de variables a evaluar al seleccionar
un ciclo de vida.
P4: Existen suficientes casos de prueba y sus soluciones asociadas.

Valor: 10
El conjunto de expertos cuenta con suficientes casos de prueba. Por un lado un
amplio conjunto de proyectos de desarrollo que pueden aportar los lderes de
proyecto, tanto aquellos que ya han sido desarrollados, como los que recin estn
en sus inicios. Por otro lado un amplio conjunto de casos de prueba y estudio que
pueden aportar los docentes. En el capitulo 9, Evaluacin del sistema se detallan
los casos de prueba facilitados por los expertos.
P5: La tarea slo depende de los conocimientos y no del sentido comn.

Valor: 8
La tarea depende del anlisis y estimacin de un conjunto de caractersticas que
presenta un proyecto de desarrollo de sistemas, al momento de inicio. Los
conocimientos radican en cules son las variables a analizar y en la estimacin
del valor que se les asigna, que es justamente resultado de la experiencia de
haber realizado la tarea en varias oportunidades y con diferentes proyectos.
4.2.2 JUSTIFICACION DE LA DIMENSION JUSTIFICACION
J1: Resuelve una tarea til y necesaria.

Valor: MUCHO
Los profesionales a cargo de proyectos, deben decidir el ciclo de vida a seguir en
un momento inicial del desarrollo, donde la informacin acerca del proyecto es
incompleta, la herramienta colabora en revisar el conjunto de variables a tener en
cuenta para tomar la decisin.

Los docentes contarn con una herramienta que facilita el entrenamiento y

comprensin del tema por parte de los estudiantes.
J2: Se espera una alta tasa de recuperacin de la inversin.

Valor: 7
La recuperacin de la inversin se espera en trminos de una mejor
productividad, dado que seleccionando el ciclo de vida adecuado de acuerdo con
las caractersticas del proyecto, contribuye a un mejor plan de desarrollo y, por lo
tanto, a un ajuste ms adecuado de plazos y esfuerzos previstos. La herramienta
contribuye a revisar cules son las caractersticas a considerar.
J3: Hay escasez de experiencia humana.

Valor: MUCHO
No es frecuente encontrar expertos en la seleccin de ciclos de vida. Se requiere
personas que hayan trabajado como lderes de proyecto en una gran cantidad de
proyectos de software, que puedan estructurar con precisin las caractersticas a
evaluar.
J4: Hay necesidad de tomar decisiones en situaciones crticas o ambientes

hostiles, penosos y/o poco gratificantes.
Valor: REGULAR
El trabajo se realiza en ambientes adecuados, las situaciones no son hostiles ni
penosas. Puede considerarse situacin crtica ya que la decisin hay que tomarla
en un momento inicial cuando an no se dispone de toda la informacin respecto
del proyecto, o la informacin que se dispone es incompleta.
J5: Hay necesidad de distribuir los conocimientos.

Valor: MUCHO
Se espera que el sistema pueda ser utilizado por la comunidad informtica tanto
empresarial como acadmica.
J6: Los conocimientos pueden perderse de no realizarse el sistema.

Valor: REGULAR
El sistema se basa parte en bibliografa, artculos y sobre la base de la
experiencia de un grupo de expertos. Dado que el conocimiento no se encuentra
precisamente estructurado se pierde la oportunidad de definir con mayor claridad
los conocimientos para realizar la tarea.
J7: No existen soluciones alternativas.

Valor: SI

En la actualidad la tarea se resuelve sobre la base de experiencia humana. Por

las caractersticas de la tarea se intenta emular el comportamiento humano al
tomar una decisin. En este contexto las tcnicas tradicionales de desarrollo de
software son inadecuadas.
4.2.3 JUSTIFICACION DE LA DIMENSION ADECUACION
A1: La transferencia de experiencia entre humanos es factible.

Valor: MUCHO
La transferencia de conocimientos entre humanos es factible. El grupo de
expertos docentes tiene habilidad y experiencia en la transferencia de
conocimientos. El grupo de expertos que se desempea liderando proyectos,
cuenta con habilidad para la transferencia de conocimientos por ser sta una de
las actividades propias de la coordinacin. El experto principal es capaz de
transmitir los conocimientos.
A2: La tarea requiere experiencia.

Valor: TODO
En la actualidad la tarea se resuelve sobre la base de experiencia humana. Se
requieren personas que hayan trabajado como lderes de proyecto en una gran
cantidad de proyectos de software y que puedan estructurar con precisin las
caractersticas a evaluar.
A3: Los efectos de la introduccin del SE no pueden preverse.

Valor: POCO
Se espera que la introduccin del SE no depare efectos no deseados. La tarea
que realizar ser asistir a los profesionales al inicio del proyecto aportando
confiabilidad en su trabajo. No existen impedimentos ticos, ni legales que
impidan el desarrollo del sistema.
A4: La tarea requiere razonamiento simblico.

Valor: MUCHO
La tarea requiere de razonamiento simblico para su realizacin.
A5: La tarea requiere el uso de heursticas para acotar el espacio de bsqueda.

Valor: MUCHO
Los conocimientos necesarios son estimaciones en algunos casos subjetivas, por
lo que se necesitan heursticas para precisar las caractersticas a analizar y evitar
un exhaustivo anlisis que entorpezca o confunda al usuario en el momento de
decidir el ciclo de vida ms adecuado.
A6: La tarea es de carcter prctico y ms tctica que estratgica.

Valor: SI
La tarea es tctica, est orientada a definir los valores estimados de las
caractersticas que presenta un proyecto de desarrollo de sistemas de informacin
en particular.
A7: Se espera que la tarea contine sin cambios significativos durante un largo
perodo de tiempo.
Valor: MUCHO
Se espera que la tarea en su esencia no cambie a corto plazo. El concepto de
ciclo de vida fue presentado en la dcada de los 70. A lo largo de los aos han
aparecido otras propuestas de ciclo de vida, pero la tarea no ha cambiado en
esencia. Los ciclos de vida que se han presentado posteriormente satisfacen
caractersticas relacionadas con el incremento en la variedad de la demanda de
proyectos informticos. Justamente el Sistema Experto desarrollado con la
metodologa IDEAL considera el mantenimiento perfectivo lo que favorece la
incorporacin de nuevas caractersticas a analizar.
A8: Se necesitan varios niveles de abstraccin en la resolucin de la tarea.

Valor: POCO
No son necesarios demasiados niveles de abstraccin para resolver la tarea. Los
conocimientos necesarios no son complejos, los temas son estudiados en los
primeros aos de una carrera universitaria.
A9: El problema es relativamente simple o puede descomponerse en

subproblemas.
Valor: MUCHO
El problema se puede descomponer en subproblemas. Es posible establecer un
agrupamiento de las caractersticas a evaluar y analizar cada subgrupo de
variables. Es justamente una de las primeras metas de la fase de adquisicin del
conocimiento el establecer conjuntos de caractersticas por rea.
A10: El experto no sigue un proceso determinista en la resolucin del problema.

Valor: SI
El proceso de razonamiento implica analizar y evaluar las caractersticas de cada
proyecto en particular. Cada proyecto es un problema diferente y su resolucin
demanda un nuevo anlisis.
A11: La tarea acepta la tcnica de prototipado gradual.

Valor: SI

Dado que el problema puede descomponerse en subproblemas y que los

requisitos iniciales no estn del todo claros es adecuado considerar el desarrollo
del sistema con un prototipo incremental.
A12: El experto resuelve el problema a veces con informacin incompleta o

incierta.
Valor: TODO
El experto suele resolver el problema contando con informacin incompleta o
incierta, puesto que la decisin hay que tomarla al inicio del proyecto, cuando los
requerimientos, lo que se espera del sistema y los recursos, an no se encuentran
definidos con precisin. Es decir, todas las decisiones del proyecto deben
tomarse con posterioridad a la seleccin del ciclo de vida, lo que implica que la
informacin con que cuenta el experto es incompleta o incierta.
A13: Es conveniente justificar las soluciones adoptadas.

Valor: TODO
Es muy importante justificar las soluciones propuestas por el sistema, explicando
al usuario el razonamiento aplicado y el fundamento de la conclusin.
A14: La tarea requiere investigacin bsica.

Valor: NO
La tarea no requiere de investigacin bsica.
A15: El sistema funcionar en tiempo real con otros programas o dispositivos.

Valor: NADA
El sistema no trabajar en tiempo real con otros programas o dispositivos.
4.2.4 JUSTIFICACION DE LA DIMENSION EXITO
E1: Existe una ubicacin idnea para el SE.

Valor: TODO
El sistema estar ubicado en el rea de desarrollo de sistemas de informacin,
particularmente a disposicin de los lderes de proyecto.
En el mbito acadmico el rea son las ctedras de anlisis y diseo de sistemas,
preparacin y evaluacin de proyectos, gestin y control de proyectos
informticos, para ser usados por docentes y alumnos.
E2: Problemas similares se han resuelto mediante INCO.

Valor: SI

Otros problemas similares, de apoyo a la tarea del lder de proyecto en las

primeras actividades del desarrollo de sistemas, estn siendo resueltos por SE.
E3: El problema es similar a otros en los que result imposible aplicar esta
tecnologa.
Valor: NO
Se desconoce la existencia de antecedentes que demuestren haber intentado
resolver problemas similares mediante la INCO y que se haya fracasado.
E4: La continuidad del proyecto est influenciada por vaivenes polticos.

Valor: POCO
No se estima que la continuidad del proyecto est influenciada por cambios
polticos.
E5: La insercin del sistema se efecta sin traumas, es decir, apenas se interfiere
en la rutina cotidiana.
Valor: MUCHO
El sistema no interfiere ni genera cambios en la estructura del trabajo cotidiano.
La herramienta colabora orientando en una de las primeras decisiones por lo que
es considerada como una colaboracin. De todas formas hay que considerar que
alguna adaptacin siempre es necesaria.
E6: Se dispone de experiencia en INCO.

Valor: REGULAR
No existe experiencia previa directa, pero se cuenta con el asesoramiento de los
tutores y con conocimientos en el manejo de las tcnicas y la metodologa de
desarrollo.
E7: Se dispone de los recursos humanos, hardware y software necesarios para el

desarrollo e implementacin del sistema.
Valor: TODO
Se cuenta con recursos de hardware y software adecuados, material bibliogrfico
y la disposicin del personal universitario y de los expertos que colaboran
gustosamente, como as tambin de los tutores asesores. Tambin se cuenta con
la colaboracin de programadores en el uso de la herramienta Kappa.
E8: El experto resuelve el problema en la actualidad.

Valor: TODO
Los expertos tanto del rea acadmica como empresarial resuelven el problema
cotidianamente.

E9: La solucin del problema es prioritaria para la institucin.

Valor: MUCHO
La solucin del problema es parte de una rama de investigacin que se ha
comenzado y se desea continuar con futuros trabajos que asistan a los
desarrolladores de sistemas informticos a lo largo de las actividades del
proyecto.
E10: Las soluciones son explicables.

Valor: MUCHO
El sistema debe explicar cada solucin adoptada ya que un buen nivel de
trazabilidad ayuda al usuario a continuar el proceso y mejorar la calidad del SE.
E11: Los objetivos del sistema son claros y evaluables.

Valor: MUCHO
Los objetivos del sistema estn claramente establecidos y pueden ser evaluados
mientras se desarrolla el sistema y al final del desarrollo. Los objetivos son
profundizados y especificados con mayor precisin a lo largo del desarrollo del
sistema, considerando que se ha optado para su construccin por prototipado
incremental.
E12: Los conocimientos estn repartidos entre un conjunto de individuos.

Valor: REGULAR
Los conocimientos se encuentran repartidos entre un conjunto de expertos, no
porque est parcializado sino porque no est estructurado con precisin y se
necesita justamente de la experiencia conjunta para proponer una estructura
organizativa bsica. Todos los expertos poseen un nivel similar de conocimientos.
Se cuenta adems con un experto principal que tendr la ultima palabra en casos
de discrepancia.
E13: Los directivos, usuarios, expertos e IC estn de acuerdo en las

funcionalidades del SE.
Valor: MUCHO
Todos los integrantes del proyecto estn de acuerdo en las funciones principales
que cumplir el Sistema Experto. La funcionalidad ser definida con mayor
precisin a lo largo del desarrollo del sistema, considerando que se ha optado
para su construccin por prototipado incremental.
E14: La actitud de los expertos ante el desarrollo del sistema es positiva y no se

sienten amenazados por el proyecto.
Valor: TODO

Los expertos esperan con agrado el desarrollo del sistema. Estiman que ser un
aporte para mejorar su tarea. En el mbito educativo el sistema permitir
implementar ms y mejores casos de prctica. No consideran que el Sistema
Experto signifique una amenaza sino por el contrario permitir realizar la tarea con
una base ms estructurada.
E15: Los expertos convergen en sus soluciones y mtodos.

Valor: REGULAR
Los expertos poseen una formacin similar y adoptan soluciones convergentes.
Se espera que existan puntos de diferencia que enriquezcan la estructura bsica
de conocimiento a definir, y todos aceptan la opinin final del experto principal
como vlida en casos de discrepancia.
E16: Se acepta la planificacin del proyecto propuesta por el IC.

Valor: SI
Fue aceptada y consensuada con todos los involucrados.
E17: Existen limitaciones estrictas de tiempo en la realizacin del sistema.

Valor: POCO
No existen limitaciones estrictas y rgidas, pero es deseable finalizarlo en el
tiempo previsto.
E18: La direccin y usuarios apoyan los objetivos y directrices del proyecto.

Valor: MUCHO
La direccin apoya firmemente el proyecto por tratarse de parte de un proyecto de
investigacin en el cual el objetivo es desarrollar Sistemas Expertos que apoyen
la tarea de los profesionales informticos en el desarrollo de sistemas de
informacin. Los usuarios estn interesados en el proyecto porque el SE
introducira una estructura ms ordenada que facilite la decisin a tomar y
permitira mayor calidad de prctica para los estudiantes.
E19: El nivel de formacin requerido por los usuarios del sistema es elevado.
Valor: MUCHO
Est dirigido a ingenieros en software o con experiencia similar.
E20: Las relaciones IC-Experto son fluidas.

Valor: MUCHO
Las relaciones con el grupo de expertos son fluidas, se garantiza al menos un
encuentro semanal. La relacin con el experto principal es directa y continua,
estn previstos encuentros frecuentes, para los momentos ms intensos del
proceso de Adquisicin y Conceptualizacin de Conocimientos.
E21: El proyecto forma parte de un camino crtico con otros sistemas.

Valor: NO
El proyecto no forma parte de un camino crtico con otros sistemas.
E22: Se efectuar una adecuada transferencia tecnolgica.

Valor: MUCHO
Est previsto un plan de capacitacin, los manuales para el uso del sistema, y un
perodo de seguimiento en los primeros meses de uso.
E23: Lo que cuenta en la solucin es la calidad de la respuesta.

Valor: SI
La calidad de la respuesta es muy importante de tal modo que el usuario
encuentre satisfactorios los resultados que el SE le presente.
4.3 CALCULO DE VIABILIDAD PARA EL PROYECTO
Paso 1: completar la columna VALOR en la tablas.
En la tabla 4.3.1 se presentan los valores asignados al Factor Plausibilidad.

En la tabla 4.3.2 se presentan los valores asignados al Factor Justificacin.
En la tabla 4.3.3 se presentan los valores asignados al Factor Adecuacin.
En la tabla 4.3.4 se presentan los valores asignados al Factor xito.
Paso 2: calcular el valor para cada dimensin.
En la tabla 4.3.5 se presenta el clculo del Factor de Plausibilidad.

En la tabla 4.3.6 se presenta el clculo del Factor de Justificacin.
En la tabla 4.3.7 se presenta el clculo del Factor de Adecuacin.
En la tabla 4.3.8 se presenta el clculo del Factor de xito.
Paso 3: calcular el valor final. Consiste en el clculo de la media aritmtica

ponderada del resultado obtenido para cada dimensin.
En la tabla 4.3.9 se presentan el clculo del Valor Final

TABLA 4.3.1 DIMENSION DE PLAUSIBILIDAD

Denominacin de la Caracterstica Categora Dimensin Peso Tipo Naturaleza Umbral Valor
Existen expertos, estn disponibles y son Experto P1 10 Esencial Booleana S (s) SI
cooperativos.
El experto es capaz de estructurar sus Experto P2 7 Deseable Difusa No MUCHO
mtodos y procedimientos de trabajo.
La tarea esta bien estructurada y se entiende. Tarea P3 8 Deseable Difusa No REGULAR
Existen suficientes casos de prueba y sus Tarea P4 10 Esencial Numrica S (8) 10
soluciones asociadas.
La tarea slo depende de los conocimientos y Tarea P5 9 Deseable Numrica No 8
no del sentido comn.
TABLA 4.3.2 DIMENSION DE JUSTIFICACIN

Resuelve una tarea til y necesaria. Tarea J1 8 Deseable Difusa No MUCHO
Se espera una alta tasa de recuperacin de la Directivos / J2 7 Deseable Numrica No 7
inversin Usuarios
Hay escasez de experiencia humana. Experto J3 6 Deseable Difusa No MUCHO
Hay necesidad de tomar decisiones en Tarea J4 10 Deseable Difusa No REGULAR
situaciones criticas o ambientes hostiles,
penosos y/o pocos gratificantes.
Hay necesidad de distribuir los conocimientos. Tarea J5 10 Deseable Difusa No MUCHO
Los conocimientos pueden perderse de no Experto J6 10 Deseable Difusa No REGULAR
realizarse el sistema.
No existen soluciones alternativas. Tarea J7 8 Esencial Booleana S (s) SI

TABLA 4.3.3 DIMENSION DE ADECUACION

La transferencia de conocimientos entre humanos Tarea A1 7 Deseable Difusa No MUCHO
es factible.
La tarea requiere experiencia. Tarea A2 10 Deseable Difusa No TODO
Los efectos de la introduccin del SE no pueden Tarea A3 -2 Deseable Difusa No POCO
preverse.
La tarea requiere razonamiento simblico. Tarea A4 5 Deseable Difusa No MUCHO
La tarea requiere el uso de heurstica para acotar Tarea A5 7 Deseable Difusa No MUCHO
el espacio de bsqueda.
La tarea es de carcter prctico y ms tctica que Tarea A6 8 Deseable Booleana No SI
estratgica.
Se espera que la tarea contine sin cambios Tarea A7 8 Esencial Difusa S MUCHO
significativos durante un largo perodo de tiempo. (mucho)
Se necesitan varios niveles de abstraccin en la Tarea A8 8 Deseable Difusa No POCO
resolucin de la tarea.
El problema es relativamente simple o puede Tarea A9 6 Deseable Difusa No MUCHO
descomponerse en subproblemas.
El experto no sigue un proceso determinista en la Experto A10 3 Deseable Booleana No SI
resolucin del problema.
La tarea acepta la tcnica de prototipado gradual. Tarea A11 8 Deseable Booleana No SI
El experto resuelve el problema a veces con Experto A12 3 Deseable Difusa No TODO
informacin incompleta o incierta.
Es conveniente justificar las soluciones Tarea A13 3 Deseable Difusa No TODO
adoptadas.
La tarea requiere investigacin bsica. Tarea A14 -10 Esencial Booleana S (No) NO
El sistema funcionara en tiempo real con otros Tarea A15 -6 Deseable Difusa No NADA
programas o dispositivos.

TABLA 4.3.4 DIMENSION DE XITO

Existe una ubicacin idnea para el SE. Directivos / E1 7 Deseable Difusa No TODO
Usuarios
Problemas similares se han resuelto con INCO. Tarea E2 8 Deseable Booleana No SI
El problema es similar a otros en lo que resulto Tarea E3 -5 Deseable Booleana No NO
imposible aplicar esta tecnologa.
La continuidad del proyecto est influenciada por Directivos / E4 -9 Esencial Difusa S (poco) POCO
vaivenes polticos. Usuarios
La insercin del sistema se efecta sin traumas, Directivos / E5 8 Deseable Difusa No MUCHO
es decir, apenas se interfiere en la rutina Usuarios
cotidiana.
Se dispone de experiencia en INCO. Tarea E6 7 Deseable Difusa No REGULAR
Se dispone de los recursos humanos, hardware y Tarea E7 4 Deseable Difusa No TODO
software necesarios para el desarrollo e
implementacin del sistema.
El experto resuelve el problema en la actualidad. Experto E8 4 Deseable Difusa No TODO
La solucin del problema es prioridad para la Directivos / E9 8 Esencial Difusa S MUCHO
institucin. Usuarios (mucho)
Las soluciones son explicables. Tarea E10 5 Deseable Difusa No MUCHO
Los objetivos del sistema son claros y evaluables. Tarea E11 6 Deseable Difusa No MUCHO
Los conocimientos estn repartidos entre un Experto E12 -7 Deseable Difusa No REGULAR
conjunto de individuos.
Los directivos, usuarios, experto e IC estn de Directivos / E13 4 Esencial Difusa S MUCHO
acuerdo en las funcionalidades del SE. Usuarios (mucho)
La actitud de los expertos ante el desarrollo del Experto E14 8 Deseable Difusa No TODO
sistema es positiva y no se sienten amenazados
por el proyecto.

TABLA 4.3.4 DIMENSION DE XITO (continuacin)

Los expertos convergen en sus soluciones y Experto E15 5 Deseable Difusa No REGULAR
mtodos.
Se acepta la planificacin del proyecto Directivos / E16 8 Esencial Booleana S (s) SI
propuesta por el IC. Usuarios
Existen limitaciones estrictas de tiempo en la Tarea E17 -6 Deseable Difusa No POCO
realizacin del sistema.
La direccin y usuarios apoyan los objetivos y Directivos / E18 7 Esencial Difusa S MUCHO
directrices del proyecto. Usuarios (mucho)
El nivel de formacin requerido por los Directivos / E19 -2 Deseable Difusa No MUCHO
usuarios del sistema es elevado. Usuarios
Las relaciones IC - Experto son fluidas. Experto E20 4 Deseable Difusa No MUCHO
El proyecto forma parte de un camino critico Tarea E21 -6 Deseable Booleana No NO
con otros sistemas.
Se efectuar una adecuada transferencia Directivos / E22 8 Esencial Difusa S MUCHO
tecnolgica. Usuarios (mucho)
Lo que cuenta en la solucin es la calidad de la Experto E23 5 Deseable Booleana No SI
respuesta.

TABLA 4.3.5 CALCULO DE LA DIMENSION DE PLAUSIBILIDAD

F Peso Valor Valores Difusos Peso / Valor Peso * Valor
P1 10 S 10 10 10 10 1 1 1 1 100 100 100 100
P2 7 Mucho 5,6 6,6 7,8 8,8 1,25 1,06 0,9 0,8 39,2 46,2 54,6 61,6
P3 8 Regular 3,4 4,4 5,6 6,6 2,35 1,82 1,43 1,21 27,2 35,2 44,8 52,8
P4 10 10 10 10 10 10 1 1 1 1 100 100 100 100
P5 9 8 8 8 8 8 1,13 1,13 1,13 1,13 72 72 72 72
44 6,72 6,00 5,45 5,13 338,4 353,4 371,4 386,4
Rtdo 7,12 7,68 8,26 8,67
PLAUSIBILIDAD
NADA POCO REGULAR MUCHO TODO

1,2
1
0,8
0,6
0,4
0,2
0
0 5 10

TABLA 4.3.6 CALCULO DE LA DIMENSION DE JUSTIFICACION

F Peso Valor Valores Difusos Peso * Valor Aprox.Numrica
J1 8 Mucho 5,6 6,6 7,8 8,8 44,8 52,8 62,4 70,4 57,6
J2 7 7 7 7 7 7 49 49 49 49 49
J3 6 Mucho 5,6 6,6 7,8 8,8 33,6 39,6 46,8 52,8 43,2
J4 10 Regular 3,4 4,4 5,6 6,6 34 44 56 66 50
J5 10 Mucho 5,6 6,6 7,8 8,8 56 66 78 88 72
J6 10 Mucho 5,6 6,6 7,8 8,8 56 66 78 88 72
J7 8 S 10 10 10 10 80 80 80 80 80
59 331,4 375,4 428,2 472,2
Valor Mximo: 80 Rtdo 7,8 8,8 10 10 TODO
JUSTIFICACION

1,2
1
0,8
0,6
0,4
0,2
0
0 5 10

TABLA 4.3.7 CALCULO DE LA DIMENSION DE ADECUACION

A1 7 Mucho 5,6 6,6 7,8 8,8 1,25 1,061 0,897 0,795 39,2 46,2 54,6 61,6
A2 10 Todo 7,8 8,8 10 10 1,282 1,136 1 1 78 88 100 100
A3 -(2) (Poco) 5,6 6,6 7,8 8,8 0,357 0,303 0,256 0,227 11,2 13,2 15,6 17,6
A4 5 Mucho 5,6 6,6 7,8 8,8 0,893 0,758 0,641 0,568 28 33 39 44
A5 7 Mucho 5,6 6,6 7,8 8,8 1,25 1,061 0,897 0,795 39,2 46,2 54,6 61,6
A6 8 S 10 10 10 10 0,8 0,8 0,8 0,8 80 80 80 80
A7 8 Mucho 5,6 6,6 7,8 8,8 1,429 1,212 1,026 0,909 44,8 52,8 62,4 70,4
A8 8 Poco 1,2 2,2 3,4 4,4 6,667 3,636 2,353 1,818 9,6 17,6 27,2 35,2
A9 6 Mucho 5,6 6,6 7,8 8,8 1,071 0,909 0,769 0,682 33,6 39,6 46,8 52,8
A10 3 S 10 10 10 10 0,3 0,3 0,3 0,3 30 30 30 30
A11 8 S 10 10 10 10 0,8 0,8 0,8 0,8 80 80 80 80
A12 3 Todo 7,8 8,8 10 10 0,385 0,341 0,3 0,3 23,4 26,4 30 30
A13 3 Todo 7,8 8,8 10 10 0,385 0,341 0,3 0,3 23,4 26,4 30 30
A14 -(10) (No) 10 10 10 10 1 1 1 1 100 100 100 100
A15 -(6) (Nada) 7,8 8,8 10 10 0,769 0,682 0,6 0,6 46,8 52,8 60 60
58 810, 853,
18,64 14,34 11,94 10,9 667,2 732,2 2 2
Rtdo 6,07 7,17 8,25 8,85

TABLA 4.3.8 CALCULO DE LA DIMENSION DE EXITO

E1 7 Todo 7,8 8,8 10 10 0,897 0,795 0,7 0,7 54,6 61,6 70 70
E2 8 S 10 10 10 10 0,8 0,8 0,8 0,8 80 80 80 80
E3 -(5) (No) 10 10 10 10 0,5 0,5 0,5 0,5 50 50 50 50
E4 -(9) (Poco) 5,6 6,6 7,8 8,8 1,067 1,364 1,154 1,023 50,4 59,4 70,2 79,2
E5 8 Mucho 5,6 6,6 7,8 8,8 1,429 1,212 1,026 0,909 44,8 52,8 62,4 70,4
E6 7 Regular 3,4 4,4 5,6 6,6 2,059 1,591 1,25 1,061 23,8 30,8 39,2 46,2
E7 4 Todo 7,8 8,8 10 10 0,513 0,455 0,4 0,4 31,2 35,2 40 40
E8 4 Todo 7,8 8,8 10 10 0,513 0,455 0,4 0,4 31,2 35,2 40 40
E9 8 Mucho 5,6 6,6 7,8 8,8 1,429 1,212 1,026 0,909 44,8 52,8 62,4 70,4
E10 5 Mucho 5,6 6,6 7,8 8,8 0,893 0,758 0,641 0,568 28 33 39 44
E11 6 Mucho 5,6 6,6 7,8 8,8 1,071 0,909 0,769 0,682 33,6 39,6 46,8 52,8
E12 -(7) (Regular) 3,4 4,4 5,6 6,6 23,8 30,8 39,2 46,2 23,8 30,8 39,2 46,2
E13 4 Mucho 5,6 6,6 7,8 8,8 0,714 0,606 0,513 0,455 22,4 26,4 31,2 35,2
E14 8 Todo 7,8 8,8 10 10 1,026 0,909 0,8 0,8 62,4 70,4 80 80
E15 5 Regular 3,4 4,4 5,6 6,6 1,471 1,136 0,893 0,758 17 22 28 33
E16 8 S 10 10 10 10 0,8 0,8 0,8 0,8 80 80 80 80
E17 -(6) (Poco) 5,6 6,6 7,8 8,8 1,071 0,909 0,769 0,682 33,6 39,6 46,8 52,8
E18 7 Mucho 5,6 6,6 7,8 8,8 1,25 1,061 0,897 0,795 39,2 46,2 54,6 61,6
E19 -(2) (Mucho) 1,2 2,2 3,4 4,4 1,667 0,909 0,588 0,455 2,4 4,4 6,8 8,8
E20 4 Mucho 5,6 6,6 7,8 8,8 0,714 0,606 0,513 0,455 22,4 26,4 31,2 35,2
E21 -(6) (No) 10 10 10 10 0,6 0,6 0,6 0,6 60 60 60 60
E22 8 Mucho 5,6 6,6 7,8 8,8 1,429 1,212 1,026 0,909 44,8 52,8 62,4 70,4
E23 5 S 10 10 10 10 0,5 0,5 0,5 0,5 50 50 50 50
71 25,01 20,09 17,81 16,22 930,4 1039 1170 1256
Rtdo. 6,118 7,061 8,107 8,801

ADECUACION EXITO
NADA POCO REGULAR MUCHO TODO NADA POCO REGULAR MUCHO TODO
1,2 1,2
1 1
0,8 0,8
0,6 0,6
0,4 0,4
0,2 0,2
0 0
0 5 10 0 5 10
TABLA 4.3.9 CALCULO DEL VALOR FINAL

Factor Coeficiente Valores Difusos Peso*Valor
Plausibilidad 8 7,12 7,68 8,26 8,63 56,96 61,44 66,08 69,04
Justificacin 3 7,8 8,8 10 10 23,4 26,4 30 30
Adecuacin 8 6,07 7,17 8,25 8,85 48,56 57,36 66 70,8
xito 5 6,12 7,06 8,11 8,8 30,6 35,3 40,55 44
24 159,5 180,5 202,6 213,8
Valor Final 6,65 7,52 8,44 8,91
Media General 7,9

RESULTADO FINAL

1,2
1
0,8
0,6
0,4
0,2
0
0 5 10
4.4 EVALUACION DE VIABILIDAD PARA EL PROYECTO
Los resultados obtenidos en cada dimensin son:

Plausibilidad: 7,12; 7,68; 8,26; 8,67.
Justificacin: 7,8; 8,8; 10; 10.
Adecuacin: 6,07; 7,17; 8,25; 8,85
xito: 6,12; 7,06; 8,11; 8,8
Conclusin Final: 6,65; 7,52;8,44; 8,91
Media General: 7,9
El sistema planteado es viable, la media general es mayor a 6, desde la

perspectiva de la Ingeniera del Conocimiento.

Captulo 5
Adquisicin de
Conocimientos
En este captulo se describe el proceso de adquisicin de conocimientos y

las tcnicas usadas en el mismo. Como inicio del proceso se presentan las
primeras sesiones de entrevistas con el experto principal para completar el
estudio de viabilidad. Luego se documenta el proceso de extraccin de
conocimientos en el cual se utiliz el Anlisis Estructural de Textos. Se detalla el
proceso de educcin de conocimientos realizado al equipo de expertos para el
cual se aplicaron el Mtodo Delphi y la Tcnica Nominal de Grupo. Finalmente se
presenta la educcin de conocimientos con el experto principal, el desarrollo de
las entrevistas y la tcnica de Emparrillado.
5.1. EL PROCESO DE ADQUISICIN DE CONOCIMIENTOS
En las primeras fases del desarrollo de un sistema basado en conocimiento

el proceso de adquisicin de conocimientos consume el 80% del tiempo
disponible. Durante esta etapa la relacin con el experto se intensifica y se
afianza. Si esta etapa est bien lograda tanto en los aspectos tcnicos como as
tambin la empata con el experto, las posibilidades de xito se incrementan.
Se entiende por adquisicin de conocimientos al proceso de recoleccin de

informacin, a partir de cualquier fuente necesaria para construir un SBC. La
adquisicin de conocimientos no es un paso en la metodologa de desarrollo de
un SBC, sino que es una tarea que se produce en paralelo a todas las etapas de
construccin (identificacin, conceptualizacin, formalizacin, validacin,
mantenimiento, etc). [Gmez, A. y otros 1997].
Teniendo en cuenta cul es el tipo de fuente de conocimientos, escrita

(incluye cualquier tipo de documentacin, video, etc. ) o humana, el proceso de
adquisicin se identifica como Extraccin de conocimientos o Educcin de
Conocimientos respectivamente.
En la metodologa IDEAL se propone bsicamente el siguiente esquema

general a seguir en el proceso de adquisicin:
1. Primeras reuniones y evaluacin de viabilidad

2. Extraccin de conocimientos
3. Educcin de conocimientos
3.1. Interrogatorio inicial
3.2. Investigacin profunda.
Primeras reuniones y evaluacin de viabilidad: estas reuniones son con el

experto, los usuarios del SE y los directivos del proyecto. Estas reuniones
ADQUISICIN DE CONOIMIENTOS 02/09/2003 Bibiana D. Rossi 91

permiten conocer las necesidades y expectativas de los usuarios, y realizar el

estudio de viabilidad del proyecto. En estas reuniones se busca lograr familiaridad
con la terminologa del dominio. El objetivo es alcanzar conocimientos generales
(grano grueso).
Extraccin de conocimientos: este paso es para que el IC se familiarice con

el dominio tanto como sea posible antes de comenzar las sesiones con el experto.
El objetivo es tambin informacin de tipo general, tener una visin general del
dominio (grano grueso).
Educcin de conocimientos: este es un ciclo en el que se produce la

interaccin con el experto humano y sus conocimientos. En el Interrogatorio inicial
se explicita y acuerda con el experto cmo se desarrollar el proceso de
educcin. Se logra una visin de alto nivel del dominio, reas de aplicacin,
problemas, conceptos, procedimientos y se bajar gradualmente a detalles del rea
del dominio. En el ciclo de Investigacin profunda se estudian los pasos para la
resolucin de la tarea, los datos para resolverla y se conoce el proceso de
razonamiento del experto.
5.2 ADQUISICIN DE CONOCIMIENTOS DEL PRESENTE TRABAJO
Siguiendo el esquema de adquisicin de conocimientos propuesto por la

metodologa IDEAL el esquema que se aplic en el presente trabajo fue el
siguiente:

3. Educcin de conocimientos a un equipo de expertos
4. Educcin de conocimientos a un nico experto
1. Primeras reuniones y evaluacin de viabilidad: estas reuniones con el

experto (que se encuentran documentadas en el captulo 12, anexo A,
sesiones A.1, A.2 y A.3 ) han permitido:
Determinar los objetivos del SE

Precisar el alcance y mbito del proyecto
Obtener informacin para realizar el estudio de viabilidad del proyecto.
Realizar y revisar el estudio de viabilidad del proyecto
Lograr familiaridad con la terminologa del dominio
Determinar la estrategia para la extraccin de conocimientos
Definir el compromiso de participacin del grupo de expertos

Comprometer la participacin del experto principal en la preparacin y

evaluacin de las sesiones de educcin de conocimientos con el equipo
de expertos
2. Extraccin de conocimientos: las sesiones de extraccin de conocimientos

(que se encuentran documentadas en el captulo 12, anexo B, sesin B.1 del
presente captulo) han permitido:
Revisar sistemticamente la bibliografa sugerida por el experto

Incrementar la familiaridad con la terminologa del dominio
Obtener informacin para preparar las sesiones de educcin de
conocimientos con el equipo de expertos
3. Educcin de conocimientos a un equipo de expertos: estas reuniones con

el grupo de expertos (que se encuentran documentadas en las sesiones C.1,
C.2 y C.3 del presente captulo) han permitido:
Analizar exhaustivamente los resultados obtenidos de la extraccin de

conocimientos
Detallar las caractersticas a evaluar de un proyecto para seleccionar el
ciclo de vida
Definir reas y agrupar las caractersticas en esas reas
Determinar la necesidad de un primer prototipo del SE con la
informacin obtenida hasta el momento
Reconocer reas de ampliacin y refinamiento del SE para futuras
versiones
4. Educcin de conocimientos: este proceso (que se encuentra documentado

en las sesiones D.1, y A.4 del presente captulo) han permitido:
Analizar la consistencia de la informacin obtenida en el proceso de

educcin de conocimientos con el grupo de expertos
Corroborar el grado de correspondencia entre el modelo mental del
experto y la representacin obtenida

5.3 TECNICAS PARA ADQUISICIN DE CONOCIMIENTOS UTILIZADAS EN

EL PRESENTE TRABAJO
Las tcnicas usadas en el proceso de adquisicin del conocimiento del

presente proyecto son:

Entrevistas No Estructuradas
Entrevistas Estructuradas
Anlisis Estructural de Textos
3. Educcin de conocimientos a un equipo de expertos
Mtodo Delphi
Tcnica Nominal del Grupo.
4. Educcin de conocimientos al experto principal
Emparrillado
Entrevistas Estructuradas
Cada una de las sesiones se ha documentado siguiendo el siguiente ciclo

de educcin [Gmez, A. y otros 1997]:
1. Preparacin de la sesin:
Informacin a tratar
Amplitud, profundidad
Tcnica adecuada
Preparacin de preguntas
2. Sesin
Repaso del anlisis de la ultima sesin
Explicacin al experto de los objetivos de la nueva sesin
Educcin
Resumen y comentarios del experto
3. Transcripcin de la sesin
4. Anlisis de la sesin
Lectura para obtencin de una visin general
Extraccin de conocimientos concretos
5. Evaluacin de la sesin
Se han conseguido los objetivos?
Es necesario volver sobre el mismo objetivo?
Nmero y tipo de sesiones necesaria para cubrir el rea

A continuacin se presenta la documentacin de las principales sesiones

de adquisicin de conocimientos. Se han seleccionado las sesiones realizadas al
equipo de expertos utilizando el mtodo Delphi y las sesiones donde se utiliza la
tcnica de Emparrillado para documentar en el presente captulo. El resto de las
sesiones se encuentran en el capitulo 12.
El orden cronolgico en que fueron realizadas las sesiones es el siguiente:
El grupo de sesiones identificadas con A.x se corresponde con las

entrevistas realizadas al experto. Las sesiones A.1, A.2, y A.3 se
encuentran en el capitulo 12, anexo A. La sesin A4 que revisa los
resultados del Emparrillado se encuentra documentada en el presente
captulo.
El grupo de sesiones identificadas con B.x se corresponde con las

sesiones de extraccin de conocimiento, particularmente del anlisis de
la bibliografa. La sesin B.1 se encuentra en el captulo 12, anexo B.
El grupo de sesiones identificadas con C.x se corresponde con las

sesiones realizadas al equipo de expertos. Las sesiones C.1, C.2 y C.3
se encuentran documentadas en el presente captulo.
El grupo de sesiones identificadas con D.x se corresponde con las

sesiones de tcnicas indirectas, particularmente Emparrillado. La sesin
D.1 se encuentra documentada en el presente captulo.
5.4 ADQUISICION DE CONOCIMIENTOS A PARTIR DE UN EQUIPO DE

EXPERTOS
SESION C.1
C.1.1 Preparacin de la Sesin I
Informacin a tratar: Identificar las caractersticas a tener en cuenta en un

proyecto en particular para seleccionar un ciclo de vida en Cascada, Orientado
a objetos y/o Espiral.
Tcnica utilizada: Mtodo Delphi.

Preparacin del cuestionario.

El cuestionario se define con una presentacin en la que se indican los
objetivos y se adjunta al mismo la tabla obtenida como resultado de la
extraccin de conocimientos (solamente con las columnas de Ventajas y
Desventajas) para que se realice la identificacin de las caractersticas sobre
la informacin resultante del anlisis bibliogrfico.
En el diseo de la tabla se presentan todas las ventajas y desventajas
obtenidas del anlisis de textos, pero no se identifican a qu ciclos de vida
estn asociadas, para que los expertos recurran a su propia experiencia en la
seleccin de las caractersticas asociadas con los ciclos de vida a seleccionar.
Se presenta una muestra del cuestionario que se entreg en el tem C.1.5.
C.1.2 Realizacin de la Sesin I
Sesin realizada el: 16 de febrero de 2000.
Expertos asistentes: Prof. Perichinsky, Lic. Beltrami, Lic. Leone, Ing. Pollo
Cattaneo, Lic. Lucchini, Ing. Weschler, Lic. Fernndez.
Ingeniero del conocimiento: Bibiana Rossi.
Lugar: Oficina del experto. Saln de conferencias con mesas de trabajo.
Tiempo: 18 a 21.00hs.
Objetivos: Identificar las caractersticas a tener en cuenta en un proyecto en

particular para seleccionar un ciclo de vida en Cascada, Orientado a objetos
y/o Espiral.
Procedimiento:
El IC explica bsicamente el proyecto. El experto principal ha tenido
reuniones previas de preparacin con el equipo de expertos.
El IC presenta el mtodo Delphi.
El IC presenta el cuestionario y el documento adjunto. Explica el
procedimiento que se sigui para la elaboracin de la tabla.
El IC explica el objetivo de la sesin. Responde preguntas aclaratorias.
Los expertos responden el cuestionario individualmente sin interactuar
entre ellos.

C.1.3 Tabulacin y Anlisis de los Resultados de la Sesin I
Conocimientos extrados y tabulados:

Caractersticas a tener en cuenta en un proyecto en particular para
seleccionar un ciclo de vida en Cascada, Orientado a objetos y/o Espiral.
El documento tabulado resultante de la sntesis de las respuestas individuales
de cada experto, se presenta en el tem C.1.6.
Conocimientos a educir en prximas sesiones:

Revisar los resultados de la primera sesin del mtodo Delphj.
Identificar si existe una forma de agrupar las caractersticas por rea que
facilite el anlisis del proyecto para el cual se desea seleccionar el ciclo de
vida.
C.1.4 Evaluacin de la Sesin I
Se han logrado los objetivos?

Si se han cumplido. Cada experto entreg un documento donde agrupo las
caractersticas ms relevantes a tener en cuenta de un proyecto en particular
para seleccionar los ciclos de vida Cascada, Orientado a objetos y Espiral.
Es necesario volver sobre lo mismo?

Es necesario refinar la informacin obtenida y agruparla en reas.
Nmero y tipo de sesiones para cubrir el rea

Se estima:
3 sesiones con el experto principal para la tabulacin de anlisis y
resultados.
2 sesiones con el grupo de expertos.
3 sesiones con el experto principal para completar la fase de inicial de
adquisicin de los conocimientos.

C.1.5 METODO DELPHI - CUESTIONARIO SISTEMA EXPERTO: SELECCIN DEL MODELO DE CICLO DE VIDA
C.1.5 Cuestionario de la sesin C.1
Acerca del Proyecto
Proyecto: Identificar las caractersticas a tener en cuenta en un proyecto en

particular para seleccionar un ciclo de vida en Cascada, Orientado a objetos y/o
Espiral.
Etapa del Proyecto: Adquisicin de Conocimientos.
Tcnicas Utilizadas:
Tcnica usada Resultado

Entrevistas Estudio de viabilidad
Anlisis de Tabla de Ventajas y Desventajas de los modelos de ciclos de
textos vida
Mtodo Delphi Caractersticas a analizar de un proyecto para seleccionar un
modelo de ciclo de vida entre Cascada, Orientado a objetos y/o
Espiral
Mtodo Delphi - Pasos a seguir:
1. Elaboracin y refinamiento del cuestionario

2. Sesin I - Respuestas al cuestionario
3. Tabulacin y anlisis de los resultados 1er.ciclo
4. Sesin II - Respuestas y refinamiento
5. Tabulacin y anlisis de los resultados 2do. Ciclo
6. Sesin III - Respuestas y refinamiento
7. Tabulacin y anlisis de los resultados finales

Acerca de la Sesin I
Propsito: Tomando como punto de partida la Tabla de ventajas y desventajas de

los modelos de ciclos de vida, identificar las caractersticas a analizar de un
proyecto para seleccionar el ciclo de vida en Cascada, Orientado a objetos y/o
Espiral.
Material que se adjunta:

Informacin acerca del proyecto
Informacin acerca de la Sesin I
Lista a completar para Modelo en Cascada
Lista a completar para Modelo Orientado a objetos
Lista a completar para Modelo en Espiral
Tabla de ventajas y desventajas de los modelos de ciclos de vida
Procedimiento:
1. Leer la Tabla de ventajas y desventajas
2. Identificar todas las caractersticas relevantes de un proyecto para seleccionar
el modelo de ciclo de vida en Cascada (considerando tem 5). Escribirlas en la
lista correspondiente.
el modelo de ciclo de vida en Orientado a objetos (considerando tem 5).
Escribirlas en la lista correspondiente.
el modelo de ciclo de vida en Cascada (considerando tem 5). Escribirlas en la
lista correspondiente.
5. Analizar en cada caso:
9 Es posible modificar algo?
9 Es posible aadir?
9 Es posible eliminar?
9 Es posible sustituir un concepto por otro?
9 Es posible combinar elementos entre s?
9 Se puede tomar la idea en sentido opuesto?
9 Est asociada a uno a dos o a los tres modelos de CV a seleccionar?

Sesin I: 16 de febrero de 2000 Experto:
Lista a completar para Modelo en CASCADA
ITEM CARACTERISTICA DEL PROYECTO

Lista a completar para Modelo en ORIENTADO A OBJETOS

Lista a completar para Modelo en ESPIRAL

TABLA DE VENTAJAS /DESVENTAJAS DE LOS MODELOS DE CICLOS DE VIDA
Modelo Ventajas Desventajas

Modelo No est limitado a proyectos chicos
1 tambin puede manejar proyectos
grandes (1)
Sirve para la formular los
requerimientos de un sistema de
Software cuando los requerimientos
del usuario son vagos, incompletos
o inestables (1)
Puede servir como herramienta para
experimentar con nuevas e
innovadoras ideas de diseo (1)
Puede servir como factor de
seguridad en desarrollos con alto
factor de riesgo (1)
Puede servir como forma de
reaccionar ante potenciales cambios
organizacionales (1)
Puede servir como forma de
promover al cliente a participar del
proceso de desarrollo (1)
Facilita un ambiente de enseanza
para usuarios finales potenciales
durante el desarrollo (1)
Puede facilitar la introduccin
gradual de un sistema de
computacin en una organizacin
(1)
Es usado cuando hay un gran nivel
de incertidumbre (1)
Es usado cuando hay varias
opciones de diseo e
implementacin (1)
Es usado cuando hay dificultades
en formular las especificaciones (1)
Es usado cuando no hay
experiencia previa en el desarrollo
con una tcnica especifica (1)
Cuando se necesita un mtodo para
producir el sistema en forma
gradual (1)


Modelo Sirve para formular los Se puede caer en el error de
2 requerimientos de un sistema de prolongar en el desarrollo final,
Software cuando los requerimientos decisiones ineficientes
del usuario son vagos, incompletos utilizadas en el prototipo (5)
o inestables (5)
Modelo Los incrementos se pueden planear Falta de planificacin a largo

3 para gestionar riesgos tcnicos plazo
Se ajusta a entornos de alta Tentacin de caer en el modelo
incertidumbre, por no tener la de codificar y corregir
necesidad de poseer un conjunto Existe el problema de
exhaustivo de requisitos, determinar si los requisitos
(especificaciones, diseos, etc.), al propuestos son vlidos, se
comenzar el sistema, ya que cada detectan tarde.
refinamiento ampla los requisitos y Puede encomendar demasiados
las especificaciones derivadas de la recursos a una solucin errnea
fase anterior. Es difcil para ms de una
Es particularmente til cuando la persona trabajar en un nico
dotacin de personal no est prototipo
disponible para una Aunque permite el cambio
implementacin completa en continuo de requisitos existe el
cuanto a la fecha lmite de gestin problema de determinar si los
que se ha establecido (5) requisitos propuestos son
vlidos.
Los errores en los requisitos se
detectan tarde y su correccin
resulta tan costosa como en el
modelo en cascada.
Modelo Descuida el anlisis apropiado

4 Recae en la intuicin de los
desarrolladores
Lleva a decisiones de diseo
prematuras
La adquisicin de
conocimientos y el anlisis se
vuelven manejados por la
implementacin
Se hace difcil de mantener ya
que favorece la falta de
documentacin del anlisis y
diseo.


Modelo Ayuda a prevenir que se Enfoque secuencial para construir
5 sobrepasen las fechas de entrega y un producto en el cual la iteracin
los costos esperados. no es evidente.
Al final de cada fase el personal Se tarda mucho tiempo en pasar
tcnico y los usuarios tienen la por todo el ciclo, dado que hasta
oportunidad de revisar el progreso que no se finalice una fase no se
del proyecto. pasa a la siguiente.
Da facilidades a los gestores para El enfoque top-down necesita ser
controlar el progreso de los matizado con un paso de
sistemas. reciclado (vuelta para atrs) para
Reconocimiento de ciclos de cubrir temas como riesgo y reuso
realimentacin entre etapas (2) de mdulos de software (2)
Es mejor que un enfoque hecho al No maneja adecuadamente
azar (5) aspectos concernientes al
desarrollo de familias de
programas y de organizacin de
software para permitir cambios
(2)
Asume progresin relativamente
uniforme en los pasos de
elaboracin (2)
El nfasis en elaborados
documentos como criterio de
finalizacin de las fases de
requerimientos y diseo no
funciona bien para muchas clases
de software, particularmente las
aplicaciones interactivas.
No contempla la clase de
desarrollo evolutivo que presenta
el prototipado rpido y los
lenguajes de 4ta. generacin. (2)
Los proyectos reales rara vez
siguen el modelo secuencial que
propone el modelo (5).
No contempla los posibles modos
de desarrollo de software futuros,
asociados con las capacidades de
la programacin automtica,
transformacin de programas y
asistentes de software basados en
el conocimiento. (2)
A menudo es difcil que el cliente
explicite todos los requisitos (5)
Asume una especificacin de
requisitos perfecta.
Deteccin de errores tarda


No contempla los posibles modos
de desarrollo de software futuros,
asociados con las capacidades de
la programacin automtica,
transformacin de programas y
asistentes de software basados en
el conocimiento. (2)
Una versin de trabajo del
programa no estar disponible
hasta que el proyecto est muy
avanzado (5)
No refleja el proceso real de
desarrollo de software. Los
proyectos reales raramente siguen
este flujo secuencial, puesto que
siempre hay iteraciones. Aunque
en este modelo la iteracin est
permitida en etapas contiguas
(MACRO,1990),en la vida real la
iteracin abarca mas de una etapa.
Un caso tpico es la redefinicin
de los requisitos cuando se est
codificando la aplicacin.
Acenta el fracaso de la industria
del software con el usuario final.
En este caso, el usuario debe tener
paciencia, ya que el sistema en
funcionamiento no estar
disponible hasta las fases finales
del proyecto.
Agravado para KBS (incompleto
y con especificaciones
cambiantes)
Administradores y usuarios tienen
poca idea de como quedar el
sistema cuando se especifican los
requerimientos


Modelo En el desarrollo interno existe Trabaja bien en los desarrollos
6 gran flexibilidad y libertad para internos, pero necesita un ajuste
ajustarse a los acuerdos etapa posterior para adaptarlo a la
por etapa, para aplazar acuerdos subcontratacin de software.
de opciones especficas, para Necesidad de expertos en
establecer miniespirales para evaluacin de riesgos para
resolver caminos crticos, para identificar y manejar las fuentes
ajustar niveles de esfuerzo, o de riesgos de un proyecto.
para acomodar prcticas como Requiere una considerable
prototipado desarrollo evolutivo habilidad para la evaluacin del
y uso de mtodos de diseo riesgo y depende de ella para el
ajustado al costo. xito (5)
Alienta el desarrollo de Deposita una gran cantidad de
especificaciones que no son confianza en la habilidad de los
necesariamente uniformes, desarrolladores de software para
exhaustivas o formales, al diferir identificar y manejar las fuentes
la elaboracin detallada de los de riesgo del proyecto. (5)
elementos de software de bajo En general, los pasos del proceso
riesgo, y evita roturas necesitan una elaboracin
innecesarias en sus diseos, adicional para asegurar que todos
hasta que los elementos de alto los participantes de un desarrollo
riesgo del diseo sean de software estn operando en un
establecidos. contexto consistente. (5)
La revisin de los principales Puede demostrar dificultad para
objetivos sirve para asegurar que ejecutar especificaciones con una
todas las partes involucradas adecuada performance
estn de acuerdo respecto al En el desarrollo de software bajo
mtodo de trabajo para la contrato no existe esta flexibilidad
siguiente fase. y libertad, por lo que es necesario
La identificacin de riesgos mucho tiempo para definir los
asociados con cada una de las contratos, ya que los entregables
alternativas y las diferentes no estn previamente definidos de
maneras de resolverlos son el forma clara.
centro del modelo. Con los Todava no encaja en el mundo de
mtodos tradicionales, es la adquisicin de software por
habitual dejar las partes, difciles contrato.
para el final y empezar con las A no ser que se realice una
ms fciles y de menor riesgo, inspeccin por expertos, en este
obteniendo as la ilusin de un tipo de proyecto se tendr la
gran avance. ilusin de progresar por un
La divisin de los proyectos en perodo, y sin embargo, se
ciclos, cada uno con un acuerdo encuentra dirigido directamente
al final de cada ciclo, implica hacia el desastre.
que existe un acuerdo para los Las personas pueden encontrarlo
cambios a realizar o para difcil para dirigir
terminar el proyecto, en funcin transformaciones
de lo que se ha aprendido desde
el inicio del proyecto.


Contesta la pregunta cunto es
suficiente? para cada una de
las fuentes de la actividad del
proyecto y para el manejo de los
recursos.
Puede aplicarse a lo largo de la
vida del proyecto (5)
Existe un reconocimiento
explcito de las diferentes
alternativas para alcanzar los
objetivos de un proyecto
El modelo se adapta a cualquier
tipo de actividad, incluidas
algunas que no existen en otros
mtodos (por ejemplo, consulta
de asesores expertos o
investigadores ajenos) que son
muy tiles para la consecucin
de los objetivos de un proyecto.
Acomoda una mezcla apropiada
de enfoques orientados a
especificaciones, orientados a
prototipos, orientados a
simulaciones, orientados a
transformacin automtica, y
otros (2)
Es aplicable tanto a esfuerzos de
desarrollo como de mejora
(enhacement). (2)
Promueve el desarrollo de
especificaciones que no son
necesariamente uniformes,
exhaustivas o formales en las
que posterga la elaboracin
detallada de elementos de
software de bajo riesgo, evitando
un corte innecesario en su diseo
(2)
Incorpora prototipado como una
opcin de reduccin de riesgo en
cualquier etapa de desarrollo (2)
Mejora la estimacin y reduce
el costo de corregir
Permite vueltas atrs en etapas
tempranas del espiral al
identificar alternativas ms
atractivas o necesitar la
resolucin de un nuevo riesgo.


Permite explcitamente
estrategias para desarrollar
familias de programas y para
reusar software existente (2)
Permite la evolucin del ciclo de
vida, crecimiento y cambios en
el producto de software. (2)
Provee mecanismos para
incorporar objetivos de calidad
del software en el proceso de
desarrollo del producto de
software. (2)
Se focaliza en eliminar errores y
alternativas poco atractivas en
forma temprana (2)
Permite iteraciones, vueltas atrs
y terminacin prematura de
proyectos no viables (2)
Puede soportar y ser soportado
por ambientes de desarrollo de
software avanzados (2)
No implica procedimientos
separados para desarrollo y
mejoramiento de software. (2)
Provee un marco viable para el
desarrollo de sistemas de soft o
hardware integrados. (2)
Modelo La tecnologa OO pretende Otro aspecto importante en la
7 acelerar el desarrollo de sistemas tecnologa OO es "generalizar"
de una manera iterativa e los componentes para que sean
incremental. reutilizables, lo que incrementa
La ventaja principal de estos los costos de desarrollo entre un
modelos es que permiten fijar 10 y 50%, por lo que resulta
hitos ms frecuentemente, imprescindible un desarrollo que
realizando entregas de sistemas optimice esta inversin.
que son operativos cada dos o El inconveniente que presentan es
tres meses para recibir la dificultad de gestionar de
retroalimentacin del cliente lo manera formal los proyectos que
antes posible e ir adaptando la siguen estos ciclos de vida
aplicacin segn cambien las aunque, como se ha sealado, este
necesidades y se refinen los problema se puede paliar
requisitos diferenciando el "micro" del
"macroproceso".
Modelo Produce un diseo limpio y fcil La distincin entre anlisis y

8 de comprender, que resulta ms diseo podr parecer a veces
fcil de probar , mantener y arbitraria y confusa
extender.


Da al proceso de desarrollo una
base ms estable, y permite
utilizar un nico concepto
unificador de software a lo largo
del proceso: el concepto de
objeto, de tal forma que la
informacin registrada durante
el anlisis no se pierde ni se
transforma cuando se produce el
diseo y la implementacin.
La organizacin de un sistema
en torno de objetos da al proceso
de desarrollo una estabilidad de
la cual carecen las
aproximaciones orientadas a
funciones.
No hay discontinuidad en los
modelos, una notacin de una
fase sea sustituida por otra
notacin distinta en otra fase
Los cambios de funcionalidad se
admiten con facilidad en el
diseo orientado a objetos
El paradigma del mundo real
formado por objetos y relaciones
proporciona el contexto para
comprender el comportamiento
dinmico y funcional
La misma notacin hace ms
sencillo repetir los pasos de
desarrollo con grados de detalle
cada vez ms
finos. Cada iteracin aade o
clarifica caractersticas, en lugar
de modificar un trabajo que ya
se haba hecho. Hay menos
oportunidades para introducir
incongruencias y errores
Es ms flexible al cambio y ms
extensible
Los sistemas son ms fciles de
entender, esto hace que el diseo
sea ms intuitivo y simplifica la
seguibilidad entre los requisitos
y el cdigo de software. El
diseo resulta sea ms coherente
para personas que no fueran
parte del equipo original del
diseo


Se incrementa la reutilizabilidad
de los componentes de un
proyecto para el siguiente
Integra mejor las bases de datos
con el cdigo
La descomposicin de software
orientada a objetos modela ms
de cerca la percepcin que de la
realidad tiene la persona. Por
tanto, no es sorprendente que el
software desarrollado resulte
ms comprensible, extensible y
mantenible.
El diseo resultante es ms
limpio y ms adaptable, los
cambios futuros sern mucho
ms sencillos
Modelo La tecnologa de objetos La tecnologa de objetos pretende
9 pretende acelerar el desarrollo de generalizar los componentes para
sistemas de una manera iterativa que sean reutilizables, lo que
e incremental. incrementa los costos de
Permite fijar hitos ms desarrollo entre un 10 y un 50%,
frecuentemente, realizando por lo que resulta imprescindible
entregas de sistemas que son un desarrollo que optimice esta
operativos cada dos o tres inversin.
meses, para recibir Dificultad de gestionar de manera
retroalimentacin del cliente lo formal los proyectos que siguen
antes posible e ir adaptando la estos ciclos de vida aunque, como
aplicacin segn cambian las se ha sealado, este problema se
necesidades y se refinan los puede paliar diferenciando el
requisitos. micro del macroproceso
El enfoque evolutivo que el En algunos casos tiene un alto
macroproceso adopta para el costo de puesta en marcha (7)
desarrollo significa que hay Tiene problemas de eficacia en
oportunidades para identificar ciertos casos particulares (7)
problemas en momentos El microproceso del desarrollo
tempranos del ciclo de vida y orientado a objetos es inestable de
responder convenientemente a forma innata y requiere una
estos riesgos antes de que direccin activa para forzar su
comprometan el xito del conclusin (7)
proyecto (7)
La gestin de proyectos OO, en
estado estables, provoca una
reduccin en la cantidad total de
recursos que se necesitan y un
desplazamiento en el ritmo de su
despliegue respecto a mtodos
ms tradicionales (7)


Alienta la reutilizacin de
componentes de software (7)
Los costos del ciclo de vida son
con frecuencia menores que los
de un enfoque tradicional porque
el producto resultante tiende a
ser de mucha mejor calidad y
mas flexible ante el cambio (7)
Lleva a sistemas ms flexibles al
cambio (7)
Reduce el riesgo de desarrollo
La integracin incremental
tiende a reducir el riesgo de
desarrollo porque acelera el
descubrimiento de problemas de
arquitectura y eficacia en etapas
tempranas del desarrollo
El macroproceso funciona muy
bien para asegurar la calidad
porque permite una recoleccin
de datos continua sobre la tasa
de descubrimiento de errores. La
integracin sucede
incrementalmente a lo largo de
todo el ciclo de vida en vez de
ocurrir en un evento explosivo
Un desarrollo OO explota la
potencia expresiva de los
lenguajes de programacin
orientados a objetos (7)
El enfoque de desarrollo
incremental es extremadamente
apropiado para el paradigma
orientado a objetos (7)
Modelo Maneja adecuadamente aspectos No ha sido completamente
10 concernientes al desarrollo de elaborado para ver como cubre
familias de programas y a la aspectos tales como prototipado y
organizacin de software para reusabilidad (2)
acomodar cambios (2)
Modelo Contiene procesos de Tiene retos en acomodar

11 abstraccin separados hasta que reusabilidad de software, familias
se obtiene una especificacin de programas .
formal (2)
Modelo Tienen unos lmites del sistema
12 bien definidos, as que puede
resultar difcil extender un diseo
SA/SD hasta unos nuevos lmites


Modelo Facilita el logro de objetivos de No es fcil de aplicar cuando el
13 desarrollo de soft para muchos proyecto es de gran tamao(3)
proyectos (3) Requiere que el problema y su
Es prctico en el uso del enfoque solucin estn bien comprendidos
top-down step-wise.
Modelo Incorpora al ciclo de vida un Tiene problemas en escalar a
14 marco conceptual para sistemas muy grandes (2)
incorporar capacidades de Tiene problemas en acomodar
programacin automtica, familias de programas (2)
transformacin de programas y Tiene problemas en manejar
asistentes basados en opciones entre nuevas y antiguas
conocimiento (2) capacidades (2)
Modelo Los requerimientos en prosa Los requerimientos informales
15 pueden ser ledos y aprobados son notorios por su ambigedad
directamente por los clientes El testeo y la prueba de
El prototipado es posible por correctitud son muy difciles
iteracin del ciclo de desarrollo Es difcil que soporte
entero automatizacin completa (4)
Provee de puntos tiles de La descomposicin top-down es
chequeo (milestones) (4) difcil y riesgosa (4)
Modelo Los requerimientos formales Los requerimientos formales son
16 pueden ser procesados por la inaccesibles para los usuarios
maquina La especificacin finales y otras personas no
ejecutable provee resultados tcnicas (4)
tempranos. (4) Presenta peligro de decisiones de
Dispone prototipado rpido diseo prematuras (4)
automticamente (4) Puede resultar difcil ejecutar
El testing o verificacin es especificaciones con performance
evitado derivando la adecuada
implementacin de la Es una tecnologa nueva y
especificacin usando solo subdesarrollada (4)
transformaciones y mapeos que La implementacin
han sido probados (4) transformacional es nueva y no
Maneja objetos formales, lo que desarrollada tecnolgicamente
implica que se pueden Las personas pueden encontrarlo
desarrollar templetes y difcil para dirigir
herramientas (4) transformaciones
Los usuarios tienen un modelo
del sistema para interiorizarse y
evaluarlo

C.1.6 METODO DELPHI - RESULTADOS SESION I SISTEMA EXPERTO: SELECCIN DEL MODELO DE CICLO DE VIDA
C.1.6 Resultados de la sesin C.1
Resultados Tabulados de la Sesin I

Sesin I: 16 de febrero de 2000 Experto: Equipo de expertos
Modelo en CASCADA

1. C: El usuario ha explcitado la mayora de los requerimientos al comienzo del
proyecto.
2. C: El usuario ha explcitado los requisitos formalmente
3. C: El usuario ha explcitado los requisitos exhaustivamente
4. C: El usuario ha explcitado los requisitos uniformemente
5. C: Se puede asumir una progresin relativamente uniforme y secuencial en las
fases del ciclo de vida
6. C: No ser necesario disponer de una versin temprana del software
desarrollado hasta que el proyecto este avanzado.
7. C: Los lmites del sistema estn claramente definidos
8. C: Se presume la necesidad de retroalimentacin en las fases del desarrollo del
proyecto
Se presume independencia entre las fases del desarrollo del proyecto
Se presume poca dependencia entre las fases de desarrollo del proyecto
9. C: El sistema presenta subsistemas medianamente complejos
Es necesario descomponer el sistema en pocos niveles para su mejor
comprensin
manipulacin
10. C: El sistema presenta subsistemas poco complejos
comprensin
manipulacin
11. C: el sistema tiene componentes de fuerte contenido algortmico
12. C: el tipo de aplicacin presenta un comportamiento predominantemente
BATCH
13. C: Se terceriza el desarrollo y se requiere un ajustado control de la gestin del
proyecto. (cascada, facilita el control del proyecto cuando se terceriza el
desarrollo)
14. C: El proyecto requiere una gestin de proyecto muy formal.
15. C: No se dispone de software para prototipar, ni es factible adquirirlo.
16. C: Se prev la necesidad de usar metodologas ampliamente probadas.

Modelo ORIENTADO A OBJETOS

17. O: No se han definido claramente los lmites del sistema
18. O: No se han definido claramente los requisitos del sistema
19. O: Se puede asumir una progresin NO uniforme y secuencial en las fases del
ciclo de vida
20. O: Se presume la necesidad de retroalimentacin en las fases del desarrollo del
proyecto
Se presume mucha dependencia entre las fases de desarrollo del
proyecto
21. O: El proyecto requiere el descubrimiento de problemas de arquitectura en
etapas tempranas del desarrollo
22. O: El proyecto requiere el descubrimiento de problemas de eficacia en etapas
tempranas del desarrollo
23. O: El sistema a disear es innovador
24. O: El sistema se basa en componentes de fuerte contenido matemtico
25. O: El sistema se basa en componentes de fuerte contenido grfico
26. O: El sistema tiene subsistemas que presentan comportamiento dinmico
27. O: El tipo de aplicacin presenta comportamiento fuertemente interactivo
28. O: El tipo de aplicacin presenta comportamiento en Tiempo Real
29. O: Se prev una alta variabilidad (modificaciones en las funciones) en los
procesos del sistema
30. O: El sistema es explcitamente sensible a cambios, extensiones y/o
ampliaciones.
31. O: El tipo de aplicacin es desarrollo de software de base
32. O: El tipo de aplicacin es un SSBBCC sistema basado en conocimientos
33. O: El sistema presenta subsistemas complejos
Es necesario descomponer el sistema en varios niveles para su mejor
comprensin
manipulacin
34. O: El proyecto requiere una gestin de proyecto medianamente formal.
35. O: El proyecto requiere una gestin de proyecto poco formal.
36. O: Se prev una fuerte necesidad de reutilizar los componentes de un proyecto
para el siguiente
37. O: Es un subsistema de un sistema desarrollado en Objetos
38. O: Es una ampliacin de un sistema desarrollado en Objetos
39. O: Es una modificacin de un sistema desarrollado en Objetos
40. O: Se prev una fuerte necesidad de reutilizar los componentes de un software
ya existente (desarrollado en Objetos)
41. O: Es necesario disponer de una versin temprana del software desarrollado
42. O: Se prev la necesidad de usar metodologas medianamente probadas
43. O: Se presume riesgo en el desarrollo del sistema.

Modelo en ESPIRAL

44. E: El entorno del sistema es de alta incertidumbre
45. E: Hay gran nivel de incertidumbre en la especificacin de los requisitos
El cliente no ha explcitado la mayora de los requisitos
Las especificaciones no son uniformes, exhaustivas o formales
Los lmites del sistema no se definen claramente.
46. E: Se puede asumir una progresin NO uniforme y secuencial en las fases del
ciclo de vida
47. E: Se presume la necesidad de retroalimentacin en las fases del desarrollo del
proyecto
proyecto
48. E: El tipo de aplicacin a disear es innovador
49. E: El sistema a desarrollar puede resolverse por varias opciones de diseo
50. E: El sistema a desarrollar puede resolverse por varias opciones de
implementacin
51. E: El proyecto requiere el descubrimiento de problemas de arquitectura del
sistema en etapas tempranas del desarrollo
52. E: El proyecto requiere el descubrimiento de problemas de eficacia (en la
arquitectura del sistema) en etapas tempranas del desarrollo
53. E: El tipo de aplicacin requiere el desarrollo fuertemente integrado de
hardware y software
54. E: El tipo de sistema a desarrollar es un SSBBCC sistema basado en
conocimientos
55. E: El tipo de sistema a desarrollar es algortmico
56. E: Se prev en el desarrollo del sistema crecimientos y cambios del producto
El tipo de sistema a desarrollar es software de base
57. E: El sistema presenta subsistemas complejos
comprensin
manipulacin
58. E: El tipo de aplicacin presenta caractersticas fuertemente interactivas
59. E: El tipo de aplicacin presenta caractersticas de Tiempo Real
60. E: El tipo de aplicacin a desarrollar es un sistema nuevo totalmente
61. E: Es necesario facilitar la introduccin gradual del sistema para los usuarios
62. E: Es necesario contar con una fuerte participacin del cliente en el Desarrollo
63. E: Se cuenta con habilidad para la evaluacin del riesgo
Se cuenta con mtodos y tcnicas para evaluar el riesgo
64. E: La gestin del proyecto requiere de acuerdos confirmados para los cambios a
efectuarse durante el desarrollo del proyecto
65. E: La gestin del proyecto requiere entregas parciales del sistema con
funciones que se irn completando gradualmente.
66. E: La gestin del proyecto requiere entregas tempranas del sistema con

67. E: La gestin del proyecto prev definir explcitamente estrategias para reusar
software existente.
68. E : No hay experiencia previa en el sistema a desarrollar
69. E: Es necesario disponer de una versin temprana del software desarrollado
70. E: El desarrollo del sistema es responsabilidad de la organizacin, no se
terceriza
71. E: Se dispone de software para prototipar
72. E: Es factible adquirir software para prototipar
73. E: Existen importantes dudas sobre la viabilidad del software
74. E: Se presume alto factor de riesgo en el desarrollo del sistema
Es necesario definir explcitamente estrategias para realizar anlisis de
riesgo
9 Permite vuelta atrs a etapas anteriores cuando se requiere la
resolucin de algn tpico nuevo de riesgo
9 Permite vuelta atrs a etapas anteriores de la espiral cuando son
identificadas mejores alternativas
9 Acomoda iteraciones, vuelta atrs y terminacin prematura de
proyectos no viables
9 Identificar los riesgos asociados con cada una de las alternativas y las
diferentes maneras de resolverlos.
9 Es necesario definir mecanismos explcitos para incorporar objetivos
de calidad en el desarrollo del producto (anlisis de riesgo)
75. E: Se estiman riesgos tcnicos en el desarrollo del sistema
riesgo
identificadas mejores alternativas
76. E: Se prev la necesidad de los mismos procedimientos para desarrollo y
mejoramiento.
77. E: Se prev la conveniencia de los mismos procedimientos para desarrollo y
mejoramiento
78. E: La gestin del proyecto considera la conveniencia de utilizar una
metodologa poco probada.
79. E: La gestin del proyecto considera la factibilidad de utilizar una metodologa
poco probada
80. E: Existe inexperiencia con las tcnicas de ingeniera de software que se usarn
81. E: El usuario es muy exigente con los requerimientos del sistema respecto del
producto final.

SESION C.2
C.2.1 Preparacin de la Sesin II
Informacin a tratar: Agrupar en reas las caractersticas para los ciclos de

vida en Cascada, Orientado a objetos y Espiral.
Tcnica utilizada: Mtodo Delphi.
Preparacin del cuestionario.

Se presenta una muestra del cuestionario que se entreg en el tem C.2.5.
C.2.2 Realizacin de la Sesin II
Sesin realizada el: 23 de febrero de 2000.
Cattaneo, Lic. Lucchini, Ing. Weschler, Lic. Fernndez.
Lugar: Oficina del experto. Saln con mesas de trabajo.
Objetivos:
Refinar y revisar los resultados de la Sesin I.
Agrupar en reas las caractersticas a tener en cuenta en un proyecto en
particular para seleccionar un ciclo de vida en Cascada, Orientado a
objetos y/o Espiral.
Procedimiento:
El IC explica brevemente cmo se realiz la tabulacin y anlisis de los
resultados de la sesin I.
El IC presenta el cuestionario de la sesin II y el documento adjunto. El IC
explica el objetivo de la sesin. Responde preguntas aclaratorias.
Los expertos responden el cuestionario individualmente sin interactuar
entre ellos.

C.2.3 Tabulacin y Anlisis de los Resultados de la Sesin II

Caractersticas agrupadas por rea para seleccionar un ciclo de vida en
Cascada, Orientado a objetos y/o Espiral.
El documento tabulado resultante de la sntesis de las respuestas individuales
de cada experto se presenta en el tem C.2.6

Revisar y refinar los resultados de la primer y segunda sesin.
C.2.4 Evaluacin de la Sesin II

S se han cumplido. Cada experto entreg un documento donde agrup las
caractersticas a tener en cuenta de un proyecto en particular para seleccionar
los ciclos de vida Cascada, Orientado a objetos y Espiral, agrupadas a su vez
en reas.

Es necesario refinar la informacin obtenida.

Se estima
2 sesiones con el experto principal para la tabulacin de anlisis y
resultados.
1 sesin con el grupo de expertos.
2 sesiones con el experto principal para completar la fase de adquisicin de
los conocimientos.

C.2.5 METODO DELPHI - CUESTIONARIO SESION II SISTEMA EXPERTO: SELECCIN DEL MODELO DE CICLO DE VIDA
C.2.5 Cuestionario de la sesin C.2
Acerca del Proyecto
Proyecto: Identificar las caractersticas a tener en cuenta en un proyecto en

particular para seleccionar un ciclo de vida en Cascada, Orientado a objetos y/o
Espiral.
Etapa del Proyecto: Adquisicin de Conocimientos.
Tcnicas Utilizadas:
Tcnica usada Resultado

Entrevistas Estudio de viabilidad
Anlisis de Tabla de Ventajas y Desventajas de los modelos de ciclos de
textos vida
Mtodo Delphi Caractersticas a analizar de un proyecto para seleccionar un
modelo de ciclo de vida entre Cascada, Orientado a objetos
y/o Espiral
Mtodo Delphi - Pasos a seguir:
1. Elaboracin y refinamiento del cuestionario

2. Sesin I - Respuestas al cuestionario
3. Tabulacin y anlisis de los resultados 1er.ciclo
4. Sesin II - Respuestas y refinamiento
5. Tabulacin y anlisis de los resultados 2do. Ciclo
6. Sesin III - Respuestas y refinamiento
7. Tabulacin y anlisis de los resultados finales

Acerca de la Sesin II
Propsito: Tomando como punto de partida los Resultados Tabulados de la Sesin I,

identificar y agrupar las caractersticas en reas para seleccionar el ciclo de vida en
Material que se adjunta:

Informacin acerca del proyecto
Informacin acerca de la Sesin II
Resultados Tabulados de la Sesin I.
Lista a completar para Areas de anlisis
Procedimiento:
1. Leer los Resultados Tabulados de la Sesin I.
2. Refinar los resultados analizando en cada caso:
a. Es posible modificar algo?
b. Es posible aadir?
c. Es posible eliminar?
d. Es posible sustituir un concepto por otro?
e. Es posible combinar elementos entre s?
f. Se puede tomar la idea en sentido opuesto?
g. Est asociada a uno a dos o a los tres modelos de CV a seleccionar?
h. Corresponde efectivamente al modelo propuesto?
3. Definir reas en las que se puedan agrupar las caractersticas.
4. Agrupar todas las caractersticas en las reas definidas para seleccionar el
modelo de ciclo de vida en Cascada (considerando tem 5). Escribirlas en la lista
correspondiente.
modelo de ciclo de vida en Orientado a objetos (considerando tem 5). Escribirlas
en la lista correspondiente.
modelo de ciclo de vida en Cascada (considerando tem 5). Escribirlas en la lista
correspondiente.

Sesin II: 28 de febrero de 2000 Experto:
Lista a completar por AREAS DE ANALISIS
NOMBRE DEL AREA SIGLA BREVE EXPLICACION
MODELO AREA NUMERO IDENTIFICACION DE LAS

CASCADA CARACTERISTICAS ASOCIADAS AL AREA

ORIENTADO A CARACTERISTICAS ASOCIADAS AL AREA
OBJETOS

ESPIRAL CARACTERISTICAS ASOCIADAS AL AREA
Se adjuntan adems los Resultados Tabulados de la Sesin I.

C.2.6 METODO DELPHI - RESULTADOS SESION II SISTEMA EXPERTO: SELECCIN DEL MODELO DE CICLO DE VIDA
RESULTADO TABULADO DE LA SESION II

Sesin II: 28 de febrero de 2000 Experto: Equipo de expertos
MODELOS: CASCADA, ORIENTADO A OBJETOS y ESPIRAL

AREA: ESPECIFICACIN DE REQUERIMIENTOS
1. C: El usuario ha explicitado la mayora de los requerimientos al comienzo del

proyecto.
2. C: El usuario ha explicitado los requisitos formalmente
3. C: El usuario ha explicitado los requisitos exhaustivamente
4. C: El usuario ha explicitado los requisitos uniformemente
6. O: No se han definido claramente los limites del sistema


9. E: hay gran nivel de incertidumbre en la especificacin de los requisitos
El cliente no ha explicitado la mayora de los requisitos
10. E: El usuario es muy exigente con los requerimientos del sistema respecto
del producto final

AREA: CARACTERISTICAS DEL CICLO DE VIDA
11. C: Se puede asumir una progresin relativamente uniforme y secuencial en

las fases del ciclo de vida
12. C: Se presume la necesidad de retroalimentacin en las fases del desarrollo
del proyecto
13. O: Se puede asumir una progresin NO uniforme y secuencial en las fases

del ciclo de vida

14. O: Se presume la necesidad de retroalimentacin en las fases del desarrollo

del proyecto
proyecto
15. E: Se puede asumir una progresin NO uniforme y secuencial en las fases del
ciclo de vida
16. E: Se presume la necesidad de retroalimentacin en las fases del desarrollo
del proyecto
Se presume mucha dependencia entre las fases de desarrollo del proyecto

AREA: CARACTERISTICAS DEL TIPO DE APLICACION

comprensin
manipulacin
comprensin
manipulacin
BATCH

22. O: El proyecto requiere el descubrimiento de problemas de eficacia en


ampliaciones.
comprensin
manipulacin

implementacin
hardware y software
conocimientos
comprensin
manipulacin

AREA: CARACTERISTICAS DE LA GESTION DE PROYECTO

48. C: Se terceriza el desarrollo y se requiere un ajustado control de la gestin
del proyecto. (cascada, facilita el control del proyecto cuando se terceriza el
desarrollo)


54. O: Se prev una fuerte necesidad de reutilizar los componentes de un
software ya existente (desarrollado en Objetos)
63. E: Es necesario contar con una fuerte participacin del cliente en el
Desarrollo
65. E: La gestin del proyecto requiere de acuerdos confirmados para los
cambios a efectuarse durante el desarrollo del proyecto
68. E: La gestin del proyecto prev definir explcitamente estrategias para
reusar software existente.
69. E :No hay experiencia previa en el sistema a desarrollar
terceriza
riesgo
identificadas mejores alternativas.
proyectos no viables.


riesgo
mejoramiento.
mejoramiento
80. E: La gestin del proyecto considera la factibilidad de utilizar una
metodologa poco probada
81. E: Existe inexperiencia con las tcnicas de ingeniera de software que se
usarn

SESION C.3
C.3.1 Preparacin de la Sesin III
Informacin a tratar: Revisar los resultados obtenidos en las sesiones

anteriores. Las caractersticas agrupadas por reas para analizar en un
proyecto para la seleccin entre los ciclos de vida en Cascada, Orientado a
objetos y Espiral.
Tcnica utilizada: Mtodo Delphi - Tcnica Nominal de Grupo
Preparacin de la sesin:.
No se ha preparado un cuestionario. Se presentan los resultados de la sesin
anterior y se solicita que lo revisen.
C.3.2 Realizacin de la Sesin III
Sesin realizada el: 9 de marzo de 2000.
Cattaneo, Lic. Lucchini, Ing. Weschler, Lic. Fernndez
Lugar: Oficina del experto. Saln de conferencias con mesas de trabajo.
Objetivos:
Refinar y revisar los resultados de la Sesin II.
Discutir alguna diferencia de opinin y semntica respecto de los
resultados.
Procedimiento:
El IC presenta el resultado de la sesin II. El IC explica el objetivo de la
sesin.
Los expertos revisan los resultados individualmente y van registrando sus
ideas para discutir.
Se discuten secuencialmente las ideas y se vota.
El IC toma nota del resultado de la votacin.

Sntesis de los temas discutidos:
Se revisaron las reas definidas:

Respecto del rea Caractersticas del Ciclo de Vida, las caractersticas
agrupadas no se correspondan con el ciclo de vida, que es justamente
lo que se desea como respuesta del sistema, sino que se corresponde
con caractersticas que se estiman respecto de la fase de desarrollo del
proyecto.
Se cambia la redaccin de las caractersticas que mencionan ciclo de
vida por fases de desarrollo del proyecto.
Las caractersticas definidas en Caractersticas del Ciclo de Vida se
incorporan al rea Caractersticas del Tipo de Aplicacin.
Desaparece el rea Caractersticas del ciclo de vida.
Las reas tal como quedan definidas: Especificacin de Requerimientos,
Tipo de Aplicacin y Gestin de Proyecto se consideran correctas y el
nombre asignado representativo.
En ampliaciones posteriores sera conveniente agregar ms informacin y

seguramente se encontraran ms reas de anlisis respecto de un
proyecto.
La conveniencia de contar con el prototipo lo antes posible como forma de

motivar la participacin del equipo de expertos.
Considerar la posibilidad de seleccionar un ciclo de vida en espiral pero

usando tcnicas de objetos: se dijo que era posible, que era necesario
considerarlo para prximas ampliaciones del prototipo pero que resultaba
ms conveniente contar con un sistema funcionando antes de pensar en
analizar ms variables y sus combinaciones.
C.3.3 Tabulacin y Anlisis de los Resultados de la Sesin III

Caractersticas agrupadas por rea para seleccionar un ciclo de vida en
El documento tabulado resultante de la presente sesin se presenta en el tem
C3.5.


Realizar el anlisis de la informacin obtenida hasta el momento en la fase de
adquisicin de conocimientos y ver qu otras tcnicas es posible aplicar
(emparrillado, anlisis de protocolo, etc.).
C.3.4 Evaluacin de la Sesin III

S se han cumplido. Se ha refinado la informacin obtenida en las sesiones
con el grupo de expertos.

No parece necesario, slo cuando surjan dudas puntuales ser necesario
consultar al experto principal.

Se estima:
1 sesin con el experto principal para la tabulacin de anlisis y resultados.
2 sesiones con el experto principal para completar la fase de adquisicin de
los conocimientos.

C.3.5 METODO DELPHI - RESULTADOS SESION III SISTEMA EXPERTO SELECCIN DEL MODELO DE CICLO DE VIDA
RESULTADO TABULADOS DE LA SESION III

Sesin III: 9 de marzo de 2000 Experto: Equipo de expertos

AREA: ESPECIFICACIN DE REQUERIMIENTOS
1. C: El usuario ha explicitado la mayora de los requerimientos al comienzo del

proyecto.
2. C: El usuario ha explicitado los requisitos formalmente
3. C: El usuario ha explicitado los requisitos exhaustivamente
4. C: El usuario ha explicitado los requisitos uniformemente
6. O: No se han definido claramente los limites del sistema


9. E: hay gran nivel de incertidumbre en la especificacin de los requisitos
El cliente no ha explicitado la mayora de los requisitos
10. E: El usuario es muy exigente con los requerimientos del sistema respecto
del producto final

AREA: TIPO DE APLICACION

comprensin
manipulacin
comprensin
manipulacin


BATCH
15. C: Se puede asumir una progresin relativamente uniforme y secuencial en
las fases de desarrollo del proyecto
16. C: Se presume la necesidad de retroalimentacin en las fases del desarrollo
del proyecto

18. O: El proyecto requiere el descubrimiento de problemas de eficacia en
ampliaciones.
comprensin
manipulacin
30. O: Se puede asumir una progresin NO uniforme y secuencial en las fases de
desarrollo del proyecto
31. O: Se presume la necesidad de retroalimentacin en las fases del desarrollo
del proyecto
proyecto

implementacin


hardware y software
conocimientos
comprensin
manipulacin
45. E: Se puede asumir una progresin NO uniforme y secuencial en las fases de
desarrollo del proyecto
46. E: Se presume la necesidad de retroalimentacin en las fases del desarrollo
del proyecto
Se presume mucha dependencia entre las fases de desarrollo del proyecto

AREA: GESTION DE PROYECTO

48. C: Se terceriza el desarrollo y se requiere un ajustado control de la gestin
del proyecto. (cascada, facilita el control del proyecto cuando se terceriza el
desarrollo)



software ya existente (desarrollado en Objetos)
63. E: Es necesario contar con una fuerte participacin del cliente en el
Desarrollo
65. E: La gestin del proyecto requiere de acuerdos confirmados para los
cambios a efectuarse durante el desarrollo del proyecto
68. E: La gestin del proyecto prev definir explcitamente estrategias para
reusar software existente.
69. E :No hay experiencia previa en el sistema a desarrollar
terceriza
riesgo
riesgo


mejoramiento.
mejoramiento
80. E: La gestin del proyecto considera la factibilidad de utilizar una
metodologa poco probada
81. E: Existe inexperiencia con las tcnicas de ingeniera de software que se
usarn

5.5 TEORIA DE LA CONSTRUCCION PERSONAL O EMPARRILLADO
SESION D.1
D.1.1 Preparacin de la Sesin I
Informacin a tratar: Revisar la consistencia de los resultados obtenidos de la

sesin III en el proceso de adquisicin de conocimientos a partir de un equipo
de expertos.
Tcnica utilizada: Emparrillado
Pasos a seguir:
Identificacin de los elementos
Identificacin de las caractersticas
Diseo de la parrilla
Formalizacin
Anlisis de resultados
D.1.2 Identificacin de los elementos
El experto ha sealado como elementos los tres ciclos de vida que sern
considerados en el primer prototipo del sistema experto.
E1 Ciclo de vida en Cascada
E2 Ciclo de vida Orientado a Objetos
E3 Ciclo de vida en Espiral
D.1.3 Identificacin de las caractersticas
El experto ha seleccionado las caractersticas para realizar el emparrillado,

tomando como punto de partida los resultados finales obtenidos a partir de un
equipo de expertos. El punto de partida son entonces el conjunto de
caractersticas, organizadas por reas, a tener en cuenta de un proyecto, para la
seleccin del modelo de ciclo de vida ms adecuado entre Cascada, Orientado a
objetos y Espiral.
Dado que los valores de las caractersticas deben ser bipolares, se detalla a
continuacin cada una de ellas:
C1 a- Los requerimientos estn exhaustivamente explicitados al comienzo

b- Los requerimientos estn incompletos al comienzo

C2 a- Existe independencia en las fases de desarrollo

b- Existe dependencia en las fases de desarrollo
C3 a- Los subsistemas componentes son complejos

b- Los subsistemas componentes son simples
C4 a- La aplicacin es predominantemente interactiva

b- La aplicacin es predominantemente "batch"
C5 a- La aplicacin es de fuerte contenido matemtico

b- La aplicacin es de bajo contenido matemtico
C6 a- La aplicacin es de fuerte contenido grfico

b- La aplicacin es de bajo contenido grfico
C7 a- La aplicacin es desarrollo de software de base

b- La aplicacin no es desarrollo de software de base
C8 a- La aplicacin es desarrollo de software basado en conocimiento

b- La aplicacin no es desarrollo de software basado en conocimiento
C9 a- Se dispone de software para prototipar

b- No se dispone de software para prototipar
C10 a- Es necesario disponer de una versin temprana del software

b- No es necesario disponer de una versin temprana del software
C11 a- Se presume alto factor de riesgo durante el desarrollo

b- Se presume bajo factor de riesgo durante el desarrollo
C12 a- El desarrollo del sistema es responsabilidad de terceros

b- El desarrollo del sistema es responsabilidad de la organizacin
D.1.4 Diseo de la parrilla
Para el armado de la parrilla se definen cada uno de los elementos como las
columnas de la parrilla y cada una de las caractersticas polarizadas como las filas
de la parrilla, tal como se muestra en la figura 5-1.
De las tres formas posibles de construccin de la parrilla, dicotmica, clasificatoria

o evaluativa, se ha seleccionado la evaluativa. El experto asigna valores entre 1 y
10 considerando para la caracterstica analizada el grado de relacin con cada
uno de los elementos, tal como se muestra en la figura 5-1.

Los valores se corresponden de la siguiente manera: "la caracterstica Cx se

encuentra n relacionada con el elemento Ey". La relacin es mayor cuanto mayor
es el valor asignado entre 1 y 10, siendo para los valores extremos:
1: no relacionada
10: totalmente relacionada
E1 E2 E3
CASCADA OBJETOS ESPIRAL
C1: 10 6 3 C1:
REQ. EXPLICITADOS REQ. INCOMPLETOS
C2: 8 4 2 C2:
INDEPENDENCIA DEPENDENCIA
C3: 3 8 10 C3:
SUB. COMPLEJOS SUB. SIMPLES
C4: 2 10 6 C4:
APL. INTERACTIVA APL. BATCH
C5: 7 10 5 C5:
FUERTE MATEMATICO BAJO MATEMATICO
C6: 1 10 7 C6:
FUERTE GRAFICO BAJO GRAFICO
C7: 1 10 8 C7:
SOFT. BASE NO SOFT. BASE
C8: 1 6 9 C8:
SOFT. SSBBCC NO SOFT. SSBBCC
C9: 1 8 10 C9:
PROT. DISPONIBLE PROT. NO DISPONIBLE
C10: 1 7 10 C10:
VERSION TEMPRANA NO VERSION TEMPRANA
C11: 1 6 10 C11:
ALTO RIESGO BAJO RIESGO
C12: 9 5 1 C12:
RESP. TERCEROS RESP. ORGANIZACION
FIGURA 5 -1: Parrilla Evaluada
D.1.5 Formalizacin
La parrilla evaluada se estudia en dos direcciones, la clasificacin de los

elementos y la clasificacin de las caractersticas. Se realiza el clculo de la
parrilla siguiendo el desarrollo propuesto por Gmez [Gmez, A. y otros 1997]. En
ambos casos se ha aplicado la convencin de distancia mnima.

D.1.5.1 Clasificacin de los elementos
E1 E2 E3
E1 69 82
E2 37
E3
FIGURA 5 - 2: Parrilla de Distancias entre elementos
E2-E3 E1
E2-E3 69
E1
FIGURA 5 - 2: Matriz obtenida por Distancia Mnima en la Primer Iteracin
69
37
E2 E3 E1
FIGURA 5 - 3: Arbol ordenado de la matriz de Distancias de los Elementos

D.1.5.2 Clasificacin de las caractersticas
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12

C1 5 16 15 9 17 18 15 18 17 16 4
C2 14 17 16 10 18 19 16 19 18 17 3
C3 7 2 7 11 7 6 5 2 3 4 18
C4 8 7 18 6 2 3 8 7 8 9 17
C5 14 11 12 11 8 9 14 13 14 15 11
C6 6 7 20 19 13 1 6 5 6 7 19
C7 5 6 21 20 14 22 5 4 5 6 20
C8 2 3 18 17 11 19 20 3 2 1 17
C9 5 4 21 20 14 22 23 20 1 2 20
C10 4 3 20 19 13 21 22 19 22 1 19
C11 3 4 19 18 12 20 21 18 21 20 18
C12 15 16 3 8 14 8 7 2 3 2 1
FIGURA 5-4: Matriz de Distancias para las Caractersticas
NC1 NC2 C3 C4 C5 C6 C7 C8 C9 C10 C11 NC12

NC1 5 7 8 9 6 5 2 5 4 3 4
NC2 2 7 10 7 6 3 4 3 4 3
C3 7 11 7 6 5 2 3 4 3
C4 6 2 3 8 7 8 9 8
C5 8 9 11 13 13 12 11
C6 1 6 5 6 7 8
C7 5 4 5 6 7
C8 3 2 1 2
C9 1 2 3
C10 1 2
C11 1
NC12
FIGURA 5-5: Matriz Diagonal Superior de Caractersticas en su Primer Iteracin.
C6-C7 C8-C9-C10-C11-NC12 NC1 NC2 C3 C4 C5

C6-C7 4 5 6 6 2 8
C8-C9-C101-C11-NC12 2 3 2 7 11
NC1 5 7 8 9
NC2 2 7 10
C3 7 11
C4 6
C5
FIGURA 5-6: Matriz Diagonal Superior de Caractersticas en su Segunda Iteracin.

[C6-C7] [C4] [C8-C9-C10-C11-NC12] C5

[NC1-NC2-C3]
[C6-C7] [C4] 4 6
[C8-C9-C10-C11-NC12] 9
[NC1-NC2-C3]
C5
FIGURA 5-7: Matriz Diagonal Superior de Caractersticas en su Tercera Iteracin.
[C6-C7] [C4] C5
[C8-C9-C10-C11-NC12]
[NC1-NC2-C3]
[C6-C7] [C4]
[C8-C9-C10-C11-NC12] 6
[NC1-NC2-C3]
C5
FIGURA 5-8: Matriz Diagonal Superior de Caractersticas en su Cuarta Iteracin.
C6 C7 C4 C8 C9 C10 C11 NC12 NC1 NC2 C3 C5
FIGURA 5-9: Arbol ordenado de la matriz de distancias de las caractersticas

D.1.6 Anlisis de los resultados
La lectura e interpretacin de los grficos obtenidos permite encontrar relaciones

entre los elementos y caractersticas que deben ser analizados y corroborados
con el experto. Para ello se concreta una entrevista con el experto con el objetivo
de analizar los resultados.
SESION A.4
A.4.1 Preparacin de la Sesin IV
Informacin a tratar: Evaluacin de los rboles ordenados de elementos y

caractersticas obtenidos durante la etapa de Formalizacin de la tcnica de
emparrillado.
Amplitud y Profundidad: Corroborar el grado de correspondencia que existe

entre el modelo mental del experto y la representacin obtenida durante el
emparrillado.
Tcnica utilizada: Entrevista estructurada.
Preparacin de Preguntas:
Cul de los tres modelos de ciclos de vida seleccionados para este
proyecto es ms rpidamente distinguible frente a las caractersticas
particulares de un proyecto? (E2 - E3)
De los tres modelos de ciclos de vida seleccionados para este proyecto,
cules tienen ms caractersticas comunes? (E2 - E3)
Cul es la relacin entre una aplicacin de fuerte contenido grfico y que
sea software de base? (C6-C7)
Tiene sentido pensar en una aplicacin que sea software de base, de
fuerte contenido grfico, y predominantemente interactiva? (C6-C7-C4)
Es posible que una misma aplicacin rena las siguientes caractersticas:
los requerimientos estn incompletos al comienzo, existe dependencia en
las fases de desarrollo y subsistemas componentes complejos? (NC1-NC2-
C3)
Cmo afecta a una aplicacin si esta es de fuerte contenido matemtico?
(C5)
Cul es la relacin entre que la aplicacin sea un desarrollo de software
basado en conocimiento, disponer de software para prototipar, que sea
necesario disponer de una versin temprana del software, que se presuma

alto factor de riesgo y que el desarrollo del sistema sea responsabilidad de

la organizacin? (C8-C9-C10-C11-NC12)
A.4.2 Realizacin de la Sesin IV
La entrevista se realiza en la oficina del experto, habiendo acordado previamente

la hora de inicio y fin de la entrevista. Se le explica al experto el objetivo de la
entrevista. El entrevistado se muestra muy dispuesto y manifiesta curiosidad por
conocer los resultados obtenidos de la tcnica de emparrillado. Se desarrolla la
sesin de la entrevista.
A.1.3 Transcripcin de la Sesin IV
Entrevista realizada el 23 de febrero de 2000

Experto: Dr. Gregorio Perichinsky
Ingeniero del Conocimiento: Bibiana Rossi
Lugar: oficina del experto
Tiempo: 14 a 15 hs.
Objetivos: Evaluar los resultados obtenidos con la tcnica de emparrillado
IC. Cul de los tres modelos de ciclos de vida seleccionados para este sistema experto
es ms rpidamente distinguible frente a las caractersticas particulares de un proyecto?
E. El modelo en cascada es el que se identifica con mayores diferencias respecto de los
otros dos. Tanto el modelo en espiral como el modelo de objetos prevn el uso de
prototipos, tienen algunas similitudes entre ellos y se diferencian del ciclo en cascada que
es ms rgido en su concepcin.
IC. De los tres modelos de ciclos de vida seleccionados para este proyecto cules
tienen ms caractersticas comunes?
E. Como dije recin el ciclo de vida en espiral y el ciclo de vida orientado a objetos
comparten la filosofa de prototipado.
IC. Cul es la relacin entre una aplicacin de fuerte contenido grfico y que sea
software de base? Todo software de base es de alto contenido grfico?
E. El software de base puede o no ser de alto contenido grfico, pero una aplicacin de
fuerte contenido grfico es altamente probable que sea software de base o que haya sido
desarrollada con software de base de alto contenido grafico. La relacin por lo tanto no es
recproca.
Una aplicacin de alto contenido grafico, es generalmente usada por profesionales que
requieren que vistas y planos de objetos, es una aplicacin de servicio a profesionales y
es software de base. Un ejemplo tpico de esto es por ejemplo el Autocad o el CAD-CAM,
Si la aplicacin a desarrollar es de fuerte contenido grafico requiere de software de base
de fuerte contenido grfico. Por ejemplo el software usado para efectos especiales
cinematogrficos o para dibujos animados.

IC. Tiene sentido pensar en una aplicacin que sea software de base, de fuerte
contenido grfico y predominantemente interactiva?
E. Absolutamente. Por la calidad de servicio que presta el software de base es
justamente predominantemente interactivo. Los ejemplos que recin mencion tienen
claramente esa caracterstica.
IC. Es posible que una misma aplicacin rena las siguientes caractersticas: los
requerimientos estn incompletos al comienzo, existe dependencia en las fases de
desarrollo y los subsistemas componentes son complejos?
E. Los requisitos claramente explcitos estn relacionados fuertemente con el ciclo de
vida en cascada. Pero esto no define que no pueda seleccionarse otro ciclo de vida,
simplemente facilitar ms el desarrollo del sistema. Si los requisitos no estn claramente
definidos entonces se hace necesario el uso de prototipos. Tanto el ciclo de vida en
espiral como objetos consideran el uso de prototipos. En sntesis si los requisitos estn
incompletos puede ser conveniente realizar algunas versiones de prototipo o versiones
tempranas para ayudar a definirlos y explicitarlos. Si los subsistemas son complejos es
muy razonable que los requisitos no se puedan definir con facilidad y por eso estn
incompletos al comienzo.
IC. Cmo afecta una aplicacin si esta es de fuerte contenido matemtico?

E. No mucho, puede o no ser de fuerte o bajo contenido matemtico y eso no incide
respecto de la complejidad de los subsistemas, ni de la necesidad de prototipacin.
IC. Cul es la relacin entre: la aplicacin es un desarrollo de software basado en

conocimiento, se dispone de software para prototipar, es necesario disponer de una versin
temprana del software, que se presuma alto factor de riesgo y que la responsabilidad del
desarrollo sea de la organizacin?
E. Si una organizacin necesita un software basado en conocimiento, el alto factor de
riesgo puede estar asociado a que este tipo de aplicaciones no son masivamente
incluidas en las organizaciones excepto en aquellos casos que un problema no se pueda
resolver por los desarrollos tradicionales y resulte costoso, eso hace que se asocie
intuitivamente con alto factor de riesgo. En estos casos de riesgo una versin temprana
del software que facilite el anlisis de riesgo durante el desarrollo es lo mas aconsejable y
por lo tanto el software para prototipar es necesario. Por otra parte la filosofa de
desarrollo de este tipo de sistemas es justamente por prototipos y hay prototipadores de
software fciles de usar de un costo muy razonable disponibles en el mercado.
En cuanto a si el desarrollo es responsabilidad de la propia organizacin o de terceros,
ambas opciones son aplicables para software basado en conocimiento o para
aplicaciones de software conocidas como tradicionales. Todava no es tradicin que las
empresas que se dedican a desarrollar software tengan sistemas basados en
conocimiento como un posible producto. Suele entonces la empresa contratar
especialistas (ingenieros en conocimiento) para desarrollar el sistema y desde ese punto
de vista se responsabiliza del desarrollo.

A.4.4 Anlisis de la Sesin IV
Conocimientos extrados:
Se ha podido evaluar el modelo conceptual de un subconjunto de
caractersticas, y sus relaciones. Estas relaciones sern tenidas en cuenta en
la definicin de los modelos y de las inferencias del sistema.
A.4.5 Evaluacin de la Sesin IV

S se han cumplido los objetivos.

En el caso del primer prototipo no resulta necesario en este momento. En el
desarrollo de prototipos ms completos puede ser conveniente presentar otros
emparrillados considerando otros subconjuntos de caractersticas para cruzar
contra la informacin obtenida.
5.6 CONCLUSIN DE LA FASE PRIMARIA DE ADQUISICIN DE

CONOCIMIENTOS
Tal como se ha definido en el apartado 5.1 del presente captulo el proceso

de adquisicin de conocimientos es una tarea que se produce en paralelo a todas
las etapas de la construccin del sistema. En cuanto al presente trabajo el
proceso de adquisicin de conocimientos realizado entre el 20 de octubre de 1999
y el 23 de marzo de 2000 (unas 10 sesiones) permite contar con suficiente
informacin para documentar formalmente la etapa de Conceptualizacin. El
experto continu prestando su apoyo a lo largo de todo el proyecto. Para las
sesiones cumplidas con posterioridad a la fase de Adquisicin de Conocimientos
se us la tcnica de entrevistas no estructuradas, siguiendo las necesidades de
informacin surgidas del momento.
La segunda etapa de adquisicin de conocimientos se realiz entre el 27

de marzo del 2000 y el 12 de abril de 2001 (unas 16 sesiones) para la revisin de:
A.4.2, Sesin V: el Glosario de Trminos

A.4.3, Sesin VI y A.4.4, Sesin VII: la Tabla Concepto Atributo Valor
y Diccionario de Conceptos
A.4.5, Sesin VIII: los atributos Factibilidad / Necesidad / Conveniencia
de Metodologas ampliamente probadas- medianamente probadas-
poco probadas

A.4.6, Sesin IX: los atributos Necesidad / Conveniencia de mismos

Procedimientos de Desarrollo y Mantenimiento. Primeros casos de
prueba.
A.4.7, Sesin X: comprobacin de los conocimientos estratgicos
(modelo de descomposicin funcional)
A.4.8, Sesin XI: comprobacin de los conocimientos tcticos (seudo
reglas)
A.4.9, Sesin XII: comprobacin de los conocimientos fcticos
A.4.10, Sesin XIII: el modelo dinmico. Casos de prueba.
A.4.11, Sesin XIV: el modelo esttico
A.4.12, Sesin XV: completar casos de prueba.
A.4.13, Sesin XVI: comprobacin del mapa de conocimientos
A.4.14, Sesin XVII: completar casos de prueba
A.4.15, Sesin XVIII: evaluacin del funcionamiento del sistema
A.4.16, Sesin XIX: evaluacin del funcionamiento del sistema
A.4.17, Sesin XX: revisar conclusiones y futuras lneas de
investigacin
La documentacin de estas sesiones est formalizada en los captulos

siguientes de Conceptualizacin, Formalizacin , Implementacin y Evaluacin del
sistema experto.

Captulo 6
Conceptualizacin
de Conocimientos
En este captulo se presenta el resultado del desarrollo de la fase de

Conceptualizacin. En primer lugar se documenta el resultado del Anlisis de los
conocimientos adquiridos organizados en Conocimientos Estratgicos, Tcticos y
Fcticos. Luego se muestra el resultado de la Sntesis de los conocimientos
adquiridos y analizados documentado en el Modelo esttico, el Modelo dinmico y
la conformacin final en el Mapa de Conocimientos. Como cierre del captulo se
presenta la Comprobacin del proceso de Conceptualizacin.
6.1 PROCESO DE CONCEPTUALIZACION
En el captulo anterior, Adquisicin de conocimientos, se describi y

document el proceso de obtener informacin de los expertos. El resultado de ese
proceso es un complejo paquete de conocimientos sobre el dominio de la
aplicacin, que son el punto de partida para el desarrollo del sistema. Cmo
pasar entonces de este torbellino de informacin a un sistema automatizado?!.
Como en cualquier desarrollo informtico, es necesario definir en primera
instancia modelos conceptuales que luego se traducen en modelos formales y
finalmente se inicia y completa el proceso de implementacin. Primer paso
entonces y objetivo de este captulo es definir el modelo conceptual de este
proyecto.
Segn Gmez et al. [Gmez, A. y otros 1997], la Conceptualizacin

conlleva un proceso de estructuracin de los conocimientos adquiridos que se
representa en la figura 6-1. Este proceso tiene dos etapas, una primera de
Anlisis y un trabajo de Sntesis. La etapa de Anlisis tiene como objetivo
organizar los conocimientos en estratgicos, fcticos y tcticos. La etapa de
Sntesis tiene como objetivo armar los modelos dinmico y esttico en los cuales
los conocimientos forman parte en mayor o menor medida (representado por lnea
llena y por lnea punteada respectivamente) y esos modelos se integran en el
Mapa de Conocimientos conformando as el Modelo Conceptual del sistema. El
modelo esttico y el modelo dinmico integrados en forma de mapa de
conocimientos modelan el comportamiento del experto en la solucin de los
problemas. Estos dos modelos se corresponden respectivamente con la
estructura y la funcionalidad conceptual del sistema.
El proceso de Conceptualizacin no es secuencial ni respecto de la fase de

Adquisicin de conocimientos, ni en s mismo. Mientras el proceso de
Conceptualizacin se est cumpliendo, contina el proceso de adquisicin con el
experto que va revisando y refinando la organizacin de los conocimientos. De la
misma forma el proceso de sntesis avanza junto con el proceso de anlisis
CONCEPTUAIZACIN DE CONOCIMIENTOS 02/09/2003 Bibiana D. Rossi 149

intercalndose las actividades propias de una y otra etapa y retroalimentndose

para su refinamiento.
PROCESO ANALISIS PROCESO SINTESIS
CONOCIMIENTOS
ESTRATEGICOS
MODELO DINAMICO
PROCESOS
CONOCIMIENTOS
TACTICOS MAPA DE
CONOCIMIENTOS
MODELO ESTATICO
CONCEPTOS Y
RELACIONES
CONOCIMIENTOS
FACTICOS
FIGURA 6-1 Proceso de Conceptualizacin
6.2 ANALISIS DE CONOCIMIENTOS
Se identifican y ordenan los conocimientos segn la siguiente clasificacin:
Estratgicos o de control: especifican qu hacer, dnde y porqu

hacerlo. Los conocimientos estratgicos fijan la secuencia de pasos que
el SE debe seguir para ejecutar la tarea.
Tcticos, de accin u operativos: especifican cmo y cundo el SE

puede aadir a sus conocimientos genricos informacin actual acerca
del caso.

Fcticos o declarativos: especifican lo que es, o se cree que es verdad

acerca del mundo en general y acerca del caso particular para el cual se
est ejecutando la tarea.
En el presente trabajo se documenta la etapa de anlisis de conocimientos

en 5 pasos que usualmente se cumplen para completar el proceso de anlisis. Se
ha decidido presentarlos en esta forma porque facilitan la comprensin de la
documentacin ya que representa el proceso que realizan el ingeniero de
conocimientos y el experto conjuntamente.
En cada paso se trabaja en mayor medida con alguno de los tipos de

conocimientos:
Estratgicos se identifican particularmente en el paso 3.
Tcticos se identifican particularmente en el paso 4.
Fcticos se identifican en los pasos 1, 2 y 5 .
6.2.1 PASO 1: IDENTIFICACION, COMPARACIN Y CATEGORIZACIN DE

CONCEPTOS
El primer paso del proceso de Conceptualizacin es identificar los

conceptos y registrar los atributos y valores asociados. En este primer paso se
trabaja fundamentalmente con conocimientos fcticos y se describen
ordenadamente completando:
Glosario de trminos: en la Tabla 6-1 (pg. 152 a 155) se detallan el

significado de los trminos que usa el experto en la resolucin de la tarea. La
definicin de estos trminos se ha ido completando a lo largo de varias
sesiones de conocimiento y el confeccionarlo ha contribuido a un mejor
entendimiento del dominio del problema y a refinar el modelo conceptual.
Diccionario de conceptos: en la Tabla 6-2 (pg. 156 a 158) se identifican

los conceptos funcionales del ms alto nivel, especificando su utilidad o
funcin, sinnimos, acrnimos, los atributos que lo definen y de donde
pueden derivarse los datos.
Tabla de Conceptos-Atributos-Valores: en la Tabla 6-3 (pg. 159 a 165)

se registran los atributos propios de cada concepto. Se entiende por atributo
las propiedades o caractersticas de un concepto que se necesita conocer
para modelar la tarea del experto.

TABLA 6-1: GLOSARIO DE TERMINOS

TERMINO DESCRIPCION
Algortmico Conjunto de operaciones que siguen un proceso
predefinido para la solucin de un problema. Principio
opuesto a la heurstica.
Ampliacin Se refiere a cuando a partir de nuevos requerimientos
es necesario agregar funciones o procesos al sistema
que esta definido e implementado. Se agregan
funciones a las ya existentes, aumenta el nmero de
funciones.
Aplicacin Sistema o parte de un sistema que lleva a cabo un
conjunto de actividades o tareas determinadas. En
sentido mas estricto conjunto de tareas desarrolladas
por un sistema informtico. Se usan como sinnimos
Sistema y Proyecto.
Batch Procesamiento diferido. Modalidad de procesamiento
informtico con carga y control de informacin por lotes
y ejecucin normalmente diferida
Cliente Ver Usuario.
Comienzo del proyecto Conjunto de actividades iniciales de un proyecto donde
se establecen los objetivos, limites, alcances,
informacin a brindar y alguna particularidad especfica
de la aplicacin a desarrollar.
Comportamiento dinmico Forma de procesamiento donde el ordenador recibe y/o
procesa la informacin en el momento inmediatamente
(sin diferir). Usualmente el comportamiento dinmico es
interactivo
Comportamiento interactivo Forma de procesamiento en que el usuario dialoga con
un ordenador. Usualmente el comportamiento interactivo
es dinmico.
Comprensin Proceso de anlisis del dominio de conocimiento de las
partes componentes de un sistema
Emisin gradual Es la nueva edicin de una aplicacin con
modificaciones notables respecto de emisiones
anteriores. Tambin se conoce como una nueva versin
de la aplicacin. Abarca la aplicacin en su totalidad.
Entorno del sistema Se refiere a los sistemas o elementos externos a la
aplicacin que se vinculan con ella recibiendo o
enviando informacin. Ver Lmites del sistema.
Es conveniente Se dice que algo es conveniente cuando es necesario y
factible
Es factible Se dice que algo es factible cuando es una alternativa
posible de aplicar o seleccionar, considerando los
aspectos polticos y de recursos
Es necesario Se dice que algo es necesario cuando existen razones
que justifican, condicionan su aplicacin o seleccin
considerando los recursos disponibles y los aspectos
polticos
Extensin Se refiere a cuando es necesario dar mayor
funcionalidad a las funciones o procesos existentes

TERMINO DESCRIPCION
definidos e implementados en un sistema. Se extienden
las funciones ya existentes, no aumentan las funciones
sino algn aspecto de alguna de ellas
Lmites del sistema Se usa como sinnimo de los alcances del sistema o
aplicacin. Se refiere genricamente a los procesos que
involucra, y particularmente con que otros sistemas
(entidades externas) se relaciona recibiendo o enviando
informacin y que informacin es la que intercambia con
esas entidades.
Manipulacin Proceso de diseo de las partes componentes de un
sistema o aplicacin.
Pocas opciones de diseo No mas de tres posibilidades de modelos formales o de
diseo a partir de un modelo de anlisis
Pocas opciones de No mas de dos posibilidades de modelos
implementacin implementables computacionalmente.
Problemas de Arquitectura Incumplimiento de Restricciones que se deben tener en
cuenta al disear y configurar los componentes de un
sistema. Se aplica al diseo de sistemas informticos
procesadores, aplicaciones de software y redes.
Problemas de Eficacia Incumplimiento de Restricciones en el cumplimiento de
los objetivos vinculadas a la arquitectura de un sistema.
Progresin no uniforme y Las actividades que es necesario realizar durante el
secuencial de las fases desarrollo pueden cumplirse de tal modo que cada
actividad cumplida puede determinar retroceder a una
etapa anterior o continuar con alguna otra sin mantener
un ordenamiento. El grado de avance puede ser
desparejo y con diferentes ritmos.
Progresin uniforme y Las actividades que es necesario realizar durante el
secuencial de las fases desarrollo pueden cumplirse en una sucesin ordenada
de tal modo que cada actividad cumplida determina la
siguiente con un avance gradual y parejo (sin grandes
distorsiones)
Proyecto Conjunto integrado de planes, tareas, actividades y
operaciones necesarias para planificar y desarrollar un
sistema o una aplicacin.
Ver Aplicacin
Redefinicin Se refiere a cuando se cambian los procedimientos de
una o varias funciones principales ya definidas e
implementadas en un sistema
Requerimientos Es la especificacin de que informacin debe brindar el
sistema o aplicacin informtica. Se usa como sinnimo
de Requisitos.
Ver Requisitos.
Requisitos Es la especificacin de cmo se desea que brinda la
informacin el sistema o aplicacin informtica. Es un
conjunto de condiciones que ha de cumplir un sistema
de informacin, restriccin que se impone a su
desarrollo o a su funcionamiento. Se usa como sinnimo
de Requerimientos.
Ver Requerimientos

TERMINO DESCRIPCION
Requisitos definidos Que se han definido las restricciones que debe cumplir
desestructuradamente el sistema a desarrollar en forma desordenada y
despareja. Que no se ha observado alguna metodologa
que de estructura similar a la documentacin de los
requisitos.
Requisitos definidos Que se han definido en detalle y sin omisiones, las
exhaustivamente restricciones que debe cumplir el sistema a desarrollar.
formalmente el sistema a desarrollar en forma expresa (en algn
documento o informe) y con precisin. Que se ha
observado alguna metodologa de documentacin.
Requisitos definidos Que se han definido genricamente y con posibilidad de
Incompletos omisiones, las restricciones que debe cumplir el sistema
a desarrollar.
informalmente el sistema a desarrollar en forma imprecisa y que no
estn expresamente documentados. Que no se ha
observado alguna metodologa de documentacin.
Requisitos definidos Cuando el usuario manifiesta que se encuentran
mayoritariamente definidos el 90% o mas de los requisitos del sistema y
que el 10 % pueden ser detalles que no modifican la
estructura de las restricciones ya definidas, ni de la
aplicacin a desarrollar.
Requisitos definidos Cuando el usuario manifiesta que se encuentran
parcialmente definidos menos del 90% de los requisitos del sistema
y/o que los restantes pueden modificar la estructura de
las restricciones ya definidas y de la aplicacin a
desarrollar.
uniformemente el sistema a desarrollar en forma ordenada, pareja y
semejante. Que se ha observado alguna metodologa
que ordena, facilita y da estructura similar a la
documentacin de los requisitos.
Sistema Forma abreviada de referirse a Sistema de Informacin.
Ver Aplicacin
Sistema de Informacin Conjunto integrado de las personas, procedimientos,
medios materiales y otros recursos destinado a la
captura, administracin, proceso y distribucin de
informacin en el mbito de una organizacin.
Software de base Conjunto integrado de programas que se encargan de la
gestin de algn servicio bsico para el usuario del
ordenador, por ejemplo, procesador de textos, planilla
de clculo, graficador, etc.
Subsistemas Componentes o partes distinguibles de una aplicacin.
Tiempo Real Forma de procesamiento interactivo en que un
ordenador ejecuta las instrucciones y procesa los datos,
teniendo como restriccin un limitado y ajustado margen
de tiempo para producir las respuestas.


TERMINO DESCRIPCION
Usuario Persona que usa el sistema informtico. Persona que
contrata el desarrollo del sistema. Suele usarse Cliente
como sinnimo.
Varias opciones de diseo Cuatro o ms posibilidades de modelos formales o de
diseo a partir de un modelo de anlisis
Varias opciones de Tres o ms posibilidades de modelos formales
implementacin implementables computacionalmente.

TABLA 6-2: DICCIONARIO DE CONCEPTOS
CONCEPTO FUNCION SINNIMOS/ ATRIBUTOS DERIVADO DE

ACRONIMOS
Proyecto Proyecto para el que se selecciona Aplicacin /Sistema Identificacin La carpeta del proyecto, en
el CV. Nombre del proyecto particular del Informe de
Registro para identificar cada uno Lder del proyecto requerimientos.
de los casos en que se usa el SE, Objetivo
con fines estadsticos posteriores. Fecha inicio
Fecha finalizacin
CV propuesto por SE
CV seleccionado
Requisitos Registro de la estimacin del lder Requerimientos Tipo de definicin Estimacin del Informe de
de proyecto respecto de las Grado de certidumbre requerimientos del proyecto y
caractersticas de la especificacin Grado de cumplimiento de las primeras entrevistas
de requisitos para el proyecto a Definicin requisitos con el usuario.
desarrollar. Definicin lmites
Aplicacin Registro de la estimacin del lder Sistema Niveles de Composicin Estimacin resultante de los
de proyecto respecto de las Complejidad Subsistemas requerimientos del proyecto y
caractersticas de la aplicacin Componentes Predominantes de las primeras entrevistas
(software) a desarrollar Comportamiento Predominante con el usuario.
Orientacin
Progresin Fases desarrollo
Relacin Fases desarrollo
Retroalimentacin Fases desarrollo
Integracin HW-SW
Factores diseo
Existencia Aplicaciones
Posibilidad diseo
Posibilidad Implementacin
Modelado Prototipo
Modelado Objetos
Variabilidad Procesos
Opcionalidad
Tipo modificacin
Coordinacin Especifica los aspectos de gestin: Gestin Formalidad Estimacin resultante de los
polticos, tcnicos, metodolgicos Entregas requerimientos del proyecto y
CONCEPTUALIZACIN DE CONOCIMIENTOS 02/09/2003 Bibiana D. Rossi 156

ACRONIMOS
que influyen en la seleccin del Responsabilidad de las primeras entrevistas
CV. Control gestin con el usuario.
Software para prototipar
Factibilidad metodologa
Necesidad metodologa
Reso aplicacin existente
Reso aplicacin OO
Reso aplicacin futura
Procedimientos cambios
Procedimientos Desarrollo-
Mantenimiento
Conveniencia Metodologa
Factibilidad Prototipo
Sistema OO
Entrega Intermedia
Aplicabilidad Espiral
Aplicabilidad Prototipo
Aplicabilidad OO
Procedimientos D-M
Usuario Especifica el tipo de relacin, Cliente / operador Participacin

participacin, del usuario en el Introduccin gradual
proyecto a desarrollar.
Equipo de proyecto Especifica las caractersticas de Experiencia tcnicas de IS Estimacin resultante de las
los recursos humanos que Experiencia previa aptitudes de los recursos
participan en el desarrollo de la humanos asignados, o de los
aplicacin. recursos existentes, para el
desarrollo de la aplicacin.
Riesgos del proyecto Especifica la estimacin de varios Viabilidad software Estimacin resultante de los
tems a tener en cuenta respecto Nivel de riesgo requerimientos del proyecto y
de los posibles riesgos del Anlisis riesgo de las primeras entrevistas
proyecto que afectan en la Tcnicas AR con el usuario

ACRONIMOS
seleccin del CV. Identificacin Alternativas
Riesgos Alternativa
Categoras riesgo
Objetivo calidad
Terminacin Proyectos
Riesgo Cascada
Riesgo Objetos
Habilidad Riesgo
Factor Riesgo
Riesgo Espiral
Riesgo
rea Requisitos Especifica el ciclo de vida CV Propuesto Requisitos Los valores estimados por el
propuesto de acuerdo a los usuario del SE para los
factores estimados en Requisitos. atributos de Requisitos.
rea Aplicacin Especifica el ciclo de vida CV Propuesto Aplicacin Los valores estimados por el
propuesto de acuerdo a los usuario del SE para los
factores estimados en Aplicacin atributos de Aplicacin
rea Gestin Especifica el ciclo de vida CV Propuesto Gestin Los valores estimados por el
Proyecto propuesto de acuerdo a los usuario del SE para los
factores estimados en atributos de Coordinacin,
Coordinacin, Usuario, Equipo de Usuario, Equipo de proyecto,
Proyecto y Riesgos del Proyecto Riesgos del proyecto.
CV Diagnstico Especifica el ciclo de vida CV Propuesto del Proyecto Los valores derivados de las
propuesto de acuerdo a los ciclos reas de Requisitos,
de vida estimados en rea aplicacin y Gestin
Requisitos, rea Aplicacin, rea Proyecto.
Gestin Proyecto

TABLA 6-3: TABLA CONCEPTOS-ATRIBUTOS-VALORES

CONCEPTO ATRIBUTO VALOR
Proyecto Identificacin Cdigo alfanumrico
Nombre del proyecto Descripcin (texto)
Lder del proyecto Nombre y Apellido
Objetivo Descripcin (texto libre)
Fecha inicio DD / MM /AAAA
Fecha finalizacin DD / MM /AAAA
CV propuesto por SE Cascada

Espiral
Objetos
CV seleccionado Cascada
Espiral
Objetos
Otro


Requisitos Tipo de Definicin Formalmente
Informalmente
Requerimientos Exhaustivamente
Incompleto
Uniformemente
Desestructuradamente
Definicin Requisitos (al inicio del proyecto) Definicin Clara
Definicin Incierta
Alta incertidumbre
Baja incertidumbre
Definicin Lmites (al inicio del proyecto) Definicin Clara
Definicin Incierta
Alta incertidumbre
Baja incertidumbre
Grado de Certidumbre al inicio del proyecto Mayoritariamente definidos (> = 90%)
Parcialmente definidos (< 90%)
Grado de Cumplimiento en Producto final Usuario muy exigente
Usuario poco exigente
Aplicacin Componentes Predominantes Algortmicos
Matemticos
Sistema Grficos
Complejidad Subsistemas Baja
Alta
Comportamiento Predominante Batch
Dinmico
Interactivo
Tiempo Real
Orientacin Software de Base
Sistema Basado en Conocimiento
Otros
Niveles de Composicin Pocos Subsistemas
Varios Subsistemas

Progresin Fases desarrollo Uniforme y Secuencial
No Uniforme y Secuencial
Relacin Fases desarrollo Poca Dependencia
Mucha Dependencia
Independencia
Retroalimentacin Fases desarrollo Baja
Alta
Integracin HW-SW Fuertemente
Medianamente
Levemente
Factores Diseo Problemas de Arquitectura
(a considerar en etapas tempranas del desarrollo) Problemas de eficacia
Existencia Aplicaciones Innovador
(similares en el mercado) Conocido
Posibilidad Diseo Pocas opciones
Varias opciones
Posibilidad Implementacin Pocas opciones
Varias opciones
Modelado Prototipo Conveniente
No conveniente
Modelado Objetos Conveniente
No conveniente
Variabilidad Procesos Alta
Baja
Tipo modificacin Redefinicin
(explcitamente previstas en datos y procesos) Extensin
Ampliacin
Emisin gradual
Opcionalidad Mltiple
Simple
Coordinacin Formalidad Poco formal
Medianamente formal


Muy formal
Entregas Versin temprana
Versin completa
Versin gradual
Versin parcial
Responsabilidad Terceros
Organizacin propia
Control gestin Muy ajustado
Medianamente ajustado
Poco ajustado
Software para prototipar No disponible
Hay disponible
Factible de adquirir
No adquirible
Factibilidad Metodologa Ampliamente probada
Medianamente probada
Poco probada
Necesidad Metodologa Ampliamente probada
Poco probada
Reso aplicacin existente Estrategias explcitas
No estrategias explcitas
Reso aplicacin futura Muy necesario
Medianamente necesario
Poco necesario
Reso aplicacin OO Subsistema del existente
Ampliacin del existente
Modificacin del existente
Componentes del actual
Procedimientos Cambios Acuerdos confirmados
No Acuerdos confirmados

Procedimientos Desarrollo-Mantenimiento Es factible usar los mismos
Es factible usar diferentes
Es necesario usar los mismos
Es necesario usar diferentes
Conveniencia Metodologa Ampliamente probada
Poco probada
Factibilidad Prototipo Factible
No factible
Sistema OO Existe
No existe
Entrega Intermedia Existe
No existe
Aplicabilidad Espiral Aplicable
No aplicable
Aplicabilidad Prototipo Aplicable
No aplicable
Aplicabilidad OO Aplicable
No aplicable
Procedimientos D-M Conveniente
No conveniente
Usuario / cliente Participacin Fuerte
Regular
Poca
Introduccin gradual Necesaria
No necesaria
Equipo de proyecto Experiencia tcnicas IS Hay
No hay
Experiencia previa Hay
No hay


Riesgos del Proyecto Viabilidad software Hay certeza
Hay dudas
Nivel de riesgo Alto riesgo
Mediano riesgo
Bajo riesgo
No hay riesgo
Anlisis riesgo Estrategias explcitas
No estrategias explcitas
Tcnicas AR Se dispone
No se dispone
Identificacin Alternativas Se identifican
No se identifican
Etapas anteriores
Riesgos Alternativa Se identifican
No se identifican
Etapas anteriores
Categoras riesgo Tcnicos
Otros riesgos
Objetivo calidad Mecanismos explcitos
No mecanismos explcitos
Terminacin Proyectos Prematura
En trmino.
Riesgo Cascada Aceptable
No aceptable
Riesgo Objetos Aceptable
No aceptable
Habilidad Riesgo Existe
No existe
Factor Riesgo Existe
No existe
Riesgo Espiral Aceptable
No aceptable


Riesgo Evaluable
No evaluable
Area Requisitos CV Propuesto Requisitos Cascada Espiral
Objetos No hay propuesta
Area Aplicacin CV Propuesto Aplicacin Cascada Espiral
Area Gestin proyecto CV Propuesto Gestin Cascada Espiral
CV Diagnstico CV Propuesto Proyecto Cascada Espiral

6.2.2 PASO 2: IDENTIFICACIN DE LAS RELACIONES ENTRE

CONCEPTOS
El segundo paso del proceso de Conceptualizacin es identificar las

relaciones entre los conceptos. En este paso se trabaja con conocimientos
fcticos, se representa grficamente el modelo mental que el experto tiene del
aspecto esttico del problema, usando el modelo entidad-relacin de Chen
[Chen, P.S. 1976]. En la figura 6-2 se detalla el modelo relacional del presente
trabajo.
N N 1 AREA
REQUISITOS
REQUISITOS
SE ESTIMAN SE SUGIERE
1 SE PROPONE
SE ESTIMAN SE PROPONE
N N 1 AREA
APLICACION
APLICACION
SE SUGIERE
1
1 1 1 1
CV
PROYECTO
DIAGNOSTICO
1 1 1 1 1
N
N
USUARIO SE SUGIERE
SE ESTIMAN
N
EQUIPO DE
1
N 1
PROYECTO SE SUGIERE SE PROPONE
AREA 1
GESTION
SE ESTIMAN
PROYECTO
N COORDINA- SE SUGIERE
N 1 1
CION
N RIESGOS DEL
N
PROYECTO
FIGURA 6-2: Modelo Relacional

6.2.3 PASO 3: IDENTIFICACIN DE LOS CONOCIMIENTOS ESTRATEGICOS
Una vez identificados los conceptos, sus atributos y sus relaciones el tercer
paso del proceso de Conceptualizacin consiste en identificar las funciones del
proceso de resolucin del experto. Estos conocimientos son de tipo estratgico.
En primer lugar se presenta una representacin grfica en forma de rbol

(figura 6-3) que ilustra los pasos modulares que completan la tarea del experto y
el flujo de control del proceso de resolucin. Los mdulos se han identificado
considerando su cohesin funcional y su independencia.
En segundo lugar se describen los mdulos de acuerdo a la propuesta de

Gmez [Gmez, A. y otros 1997]:
Pasos de Alto Nivel:
Se corresponden con el nivel 1 y 2 de la figura 6-3: rbol de
Descomposicin funcional del Problema.
Subpasos de la Tarea:
Se corresponden con el nivel 3 de la figura 6-3: rbol de
Subpasos de Bajo Nivel:
Se corresponden con el nivel 4 de la figura 6-3: rbol de
6.2.3.1 DESCOMPOSICION FUNCIONAL
Mdulo 1. Seleccin del CV del proyecto

A partir de la decisin de construir un sistema de informacin una de las primeras
actividades consiste en definir los requerimientos del sistema. Una vez definidos
es necesario seleccionar el ciclo de vida gua del proceso de desarrollo.
En el marco del presente trabajo y siguiendo la propuesta del equipo de expertos,
a partir del anlisis de los textos, se han identificado tres grandes reas de
anlisis respecto del proyecto software. Estas reas: Especificacin de
Requerimientos, Tipo de Aplicacin y Gestin de Proyecto no son exhaustivas y la
identificacin de mdulos independientes facilita la incorporacin de otras reas
en futuros prototipos.

1. SELECCION DEL
CV DEL
PROYECTO
1.1 SELECCION DEL

1.2 SELECCION DEL 1.3 SELECCION DEL
CV
CV TIPO DE CV GESTIN DE
ESPECIFICACION
APLICACION PROYECTO
REQUERIMIENTOS
1.1.3
1.3..2
1.1.1 ESTIMAR 1.2.1 1.2.2 1.2.4 1.3.3 1.3.4
1.2.3 1.3.1 ESTIMAR
ANALIZAR 1.1.2 NIVEL ESTIMAR ANALIZAR ESTIMAR ESTIMAR ANALIZAR
ESTIMAR ANALIZAR RELACION
DEFINICION ESTIMAR EXIGENCIA FACTORES FACTORES INTEGRA- FACTORES RIESGOS
NIVEL COORDINA- CON
REQUERI- LIMITES EN EL PREDOMI- PROTOTI- CION EQUIPO DEL
OPCIONES CION USUARIO
MIENTOS PRODUCTO NANTES PACION HW-SW PROYECTO PROYECTO
FINAL
1.3.4.2
1.3.1.2 1.3.1.4
1.3.1.1 1.3.1.3 1.3.4.1 ESTIMAR
ESTIMAR ESTIMAR
ESTIMAR ESTIMAR ESTIMAR HABILIDAD
FACTORES FACTORES
FACTORES RECURSOS RIESGO PARA
MANTENI- ADMINIS-
REUSO SOFTWARE EXISTENTE EVALUAR
MIENTO TRACION
RIESGO
FIGURA 6-3 Arbol de Descomposicin Funcional del Problema

Propsito:
Determinar el ciclo de vida propuesto para el desarrollo del proyecto.
Para llevar a cabo la tarea, el sistema debe realizar las siguientes
funciones de alto nivel:
Mdulo 1.1 Seleccin del CV Especificacin de Requerimientos
Mdulo 1.2 Seleccin del CV Tipo de Aplicacin
Mdulo 1.3 Seleccin del CV Gestin de Proyecto
Entrada- Origen de la Entrada:
Los resultados parciales obtenidos para cada uno de los subpasos.
Razonamiento:
Considerando el/los ciclos de vida posibles para cada rea se determina el
ciclo de vida ms adecuado para el proyecto.
Salida- Destino de la Salida:
El nombre del ciclo de vida seleccionado para el proyecto. Su destino es la
Base de Conocimientos y edicin en pantalla de resultados.
Mdulo 1.1 Seleccin del CV Especificacin de Requerimientos

Se analizan algunos aspectos de la Especificacin de Requerimientos para
proponer el o los ciclos de vida posibles de acuerdo a esta rea. Los aspectos
analizados estn encuadrados dentro del marco del presente trabajo y no son
exhaustivos. La identificacin en mdulos independientes prev la incorporacin
de otros aspectos a analizar en esta rea en futuros prototipos.
Propsito:
Determinar el o los ciclos de vida posibles para el rea de Especificacin
de Requerimientos.
Para llevar a cabo la tarea el sistema debe realizar las siguientes
subtareas:
Mdulo 1.1.1 Analizar Definicin de Requerimientos
Mdulo 1.1.2 Estimar Lmites
Mdulo 1.1.3 Estimar Nivel de exigencia en el producto final
Los valores estimados por el usuario del sistema experto, para los atributos
vinculados al concepto Requisitos.
Razonamiento:
Si los requisitos y los lmites estn definidos claramente y explicitados al
comienzo del proyecto se recomienda usar ciclo de vida en Cascada.
Si los requisitos y los lmites estn definidos con alta incertidumbre y no
estn explicitados al comienzo del proyecto es recomendable usar ciclo de
vida en Orientado a objetos o en Espiral.
Si la exigencia del usuario respecto del cumplimiento de los requerimientos
en el producto final es muy alta es recomendable usar ciclo de vida
Orientado a objetos o en Espiral.


El nombre del ciclo de vida seleccionado para el rea. Su destino es la
Mdulo 1.2 Seleccin del CV Tipo de Aplicacin

Se analizan algunos aspectos de la Aplicacin a desarrollar para proponer el o los
ciclos de vida posibles de acuerdo a esta rea. Los aspectos analizados estn
encuadrados dentro del marco del presente trabajo y no son exhaustivos. La
identificacin en mdulos independientes prev la incorporacin de otros aspectos
a analizar en esta rea en futuros prototipos.
Propsito:
Determinar el o los ciclos de vida posibles para el rea de Tipo de
Aplicacin.
subtareas:
Mdulo 1.2.1 Estimar Factores Predominantes
Mdulo 1.2.2 Analizar Factores Prototipacin
Mdulo 1.2.3 Estimar Nivel de opciones.
Mdulo 1.2.4 Estimar Integracin de Hardware y Software.
vinculados al concepto Aplicacin.
Razonamiento:
Para recomendar el ciclo de vida en cascada es necesario considerar la
complejidad de los subsistemas que lo conforman, la retroalimentacin en
las fases de desarrollo y los factores predominantes.
Para recomendar el ciclo de vida Orientado a objetos es necesario
considerar si las tcnicas de modelado de objetos son las ms
convenientes y si las tcnicas de prototipacin son convenientes.
Para recomendar el ciclo de vida en Espiral adems de considerar si las
tcnicas de modelado de objetos o de prototipado son convenientes hay
que tener en cuenta si el sistema es multiopcional y si se requiere una
fuerte integracin de hardware y software.
Mdulo 1.3 Seleccin del CV Gestin de Proyecto

Se analizan algunos aspectos de la Gestin de Proyecto para proponer el o los
ciclos de vida posibles de acuerdo a esta rea. Los aspectos analizados estn
encuadrados dentro del marco del presente trabajo y no son exhaustivos. La

identificacin en mdulos independientes prev la incorporacin de otros aspectos

a analizar en esta rea en futuros prototipos.
Propsito:
Determinar el o los ciclos de vida posibles para el rea de Gestin del
Proyecto.
subtareas:
Mdulo 1.3.1 Analizar Coordinacin
Mdulo 1.3.2 Estimar Relacin con el Usuario
Mdulo 1.3.3 Estimar Factores del Equipo de desarrollo del Proyecto
Mdulo 1.3.4 Analizar Riesgos del Proyecto
vinculados a los conceptos Coordinacin, Usuario, Equipo de proyecto y
Riesgos del Proyecto.
Razonamiento:
Para recomendar el ciclo de vida en Cascada es necesario analizar:
Conveniencia de usar metodologas probadas
Nivel de riesgo
Si el modelo en cascada es aplicable
Responsable de la gestin
Para recomendar el ciclo de vida Orientado a objetos es necesario analizar:
Nivel de riesgo
Necesidad de entregas intermedias
Si existe un sistema anterior desarrollado en objetos
Si el modelo de objetos es aplicable
Para recomendar el ciclo de vida en Espiral es necesario analizar:
Nivel factor de riesgo evaluable
Prototipacin es aplicable
Prototipacin es factible
Si el modelo en espiral es aplicable
Mdulo 1.1.1 Analizar Definicin Requerimientos

Propsito:
Estimar si los requisitos estn claramente definidos al comienzo del
proyecto.

Los valores ingresados por el usuario del sistema experto para los atributos
Tipo de definicin y Grado de Certidumbre al inicio del proyecto.
Razonamiento:
Si los requisitos se encuentran definidos formalmente, uniformemente y
exhaustivamente puede decirse que los requisitos estn claramente
definidos y es conveniente el modelo cascada.
Si los requisitos se encuentran definidos informalmente, incompletos o
desestructuradamente puede decirse que la incertidumbre en la definicin
de los requisitos es alta, en este caso es conveniente el modelo en espiral
u objetos.
Si los requerimientos estn mayoritariamente definidos al inicio del
proyecto es conveniente el modelo cascada, caso contrario se recomienda
alguno de los otros dos modelos.
Determinacin de la claridad o incertidumbre de los requisitos. Su destino
es la Base de Conocimientos.
Mdulo 1.1.2 Estimar Lmites

Propsito:
Estimar si los lmites estn claramente definidos al comienzo del proyecto.
Tipo de Definicin y Grado de Certidumbre al inicio del proyecto.
Razonamiento:
Si los requisitos se encuentran definidos formalmente, uniformemente y
exhaustivamente puede decirse que los lmites estn claramente definidos.
Si los requisitos se encuentran definidos informalmente, incompletos o
desestructuradamente puede decirse que la incertidumbre en el entorno del
sistemas es alta.
Determinacin de la claridad o incertidumbre de los lmites. Su destino es la
Base de Conocimientos.
Mdulo 1.1.3 Estimar Nivel Exigencia en el Producto Final

Propsito:
Estimar la exigencia del usuario respecto del cumplimiento de los
requerimientos en el producto final.
grado de cumplimiento en producto final.

Razonamiento:
Si la exigencia del usuario es mucha es recomendable el ciclo de vida en
espiral u orientado a objetos, pero no se recomienda el modelo en cascada
porque su estructura no permite prototipacin o entregas intermedias.
Valor ingresado por el usuario con destino a la Base de Conocimientos.
Mdulo 1.2.1 Estimar Factores Predominantes

Propsito:
Determinar el tipo de tcnicas de modelado (objetos, prototipacin o
cascada) que mejor se adecuan a los factores predominantes de la
Componentes Predominantes, Comportamiento Predominante y
Orientacin.
Razonamiento:
Las tcnicas de modelado en cascada son adecuadas si los factores
predominantes son:
Fuerte contenido algortmico
Comportamiento batch
Las tcnicas de modelado de objetos son adecuadas si los factores
predominantes son:
Fuerte contenido matemtico
Fuerte contenido grfico
Subsistemas con comportamiento dinmico
Comportamiento fuertemente interactivo
Comportamiento en tiempo real
Desarrollo de software de base
Las tcnicas de modelado por prototipo son adecuadas si los factores
predominantes son:
Sistema Basado en conocimiento
Valores ingresados por el usuario con destino a la Base de Conocimientos.
Mdulo 1.2.2 Analizar Factores Prototipacin

Propsito:
Determinar si para el desarrollo de la aplicacin es conveniente usar
tcnicas de prototipacin.


Niveles de Composicin, Progresin Fases desarrollo, Relacin Fases
desarrollo, Factores de Diseo a considerar en etapas tempranas del
desarrollo, Existencia de Aplicaciones similares en el mercado y Tipo de
Modificacin explcitamente previstas.
Razonamiento:
Las tcnicas de prototipacin son adecuadas si los factores predominantes
son:
Alta variabilidad de los procesos
Factores de diseo que inciden en etapas tempranas (arquitectura,
eficacia)
La aplicacin es innovadora
Subsistemas complejos
Progresin no uniforme y secuencial en las fases de desarrollo
Alta retroalimentacin en las fases de desarrollo
Progresin no uniforme y secuencial en las fases de desarrollo del
proyecto
Mdulo 1.2.3 Estimar Nivel Opciones

Propsito:
Determinar si la aplicacin es multiopcional.
Posibilidad de Diseo, Posibilidad de Implementacin.
Razonamiento:
Si la aplicacin es multiopcional es conveniente aplicar el ciclo de vida en
espiral.
Mdulo 1.2.4 Estimar Integracin HW-SW

Propsito:
Determinar nivel de integracin del hardware y software que requiere la
Los valores ingresados por el usuario del sistema experto para el atributo
Integracin entre hardware y software.

Razonamiento:
Si la aplicacin requiere una fuerte integracin hardware-software es
conveniente aplicar el ciclo de vida en espiral.
Mdulo 1.3.1 Analizar Coordinacin

Propsito:
Analizar los factores relacionados con administracin, mantenimiento y
reusabilidad que inciden en las decisiones de coordinacin en el desarrollo
de un proyecto.
subtareas:
Mdulo 1.3.1.1 Estimar Factores Reso
Mdulo 1.3.1.2 Estimar Factores Mantenimiento
Mdulo 1.3.1.3 Estimar Recursos Software
Mdulo 1.3.1.4 Estimar Factores Administracin
Los valores estimados por el usuarios del sistema experto, para los
atributos vinculados al concepto Coordinacin.
Razonamiento:
Los valores obtenidos permiten determinar
Necesidad de Entregas intermedias
Conveniencia de usar metodologas probadas
Responsable de la gestin
Aplicabilidad de modelos (cascada, objeto, espiral)
Factibilidad de usar prototipacin
Los valores obtenidos con destino a la Base de Conocimientos.
Mdulo 1.3.2 Estimar Relacin con Usuario

Propsito:
Determinar si el modelo por prototipo es aplicable.
Participacin del cliente en el desarrollo, Introduccin gradual del sistema a
los usuarios.
Razonamiento:
El modelo por prototipo es aplicable cuando se requiere una fuerte
participacin del cliente en el desarrollo o es necesario facilitar la
introduccin gradual del sistema para los usuarios.

Los valores ingresados por el usuario con destino la Base de

Conocimientos. Determinacin de la aplicabilidad del prototipo con destino
la Base de Conocimientos.
Mdulo 1.3.3 Estimar Factores Equipo Proyecto

Propsito:
Determinar si el modelo por prototipo es aplicable.
Experiencia en el uso de las tcnicas de IS, Experiencia en el tipo de
aplicacin.
Razonamiento:
El modelo por prototipo es aplicable cuando existe inexperiencia en el
sistema a desarrollar o en las tcnicas de IS a usar.
Conocimientos. Determinacin de la aplicabilidad del prototipo con destino
la Base de Conocimientos.
Mdulo 1.3.4 Analizar Riesgos del Proyecto

Propsito:
Determinar el nivel de riesgo y su evaluabilidad.
Para llevar a cabo la tarea el sistema debe realizar las siguiente subtareas:
Mdulo 1.3.4.1 Estimar Riesgo Existente
Mdulo 1.3.4.2 Estimar Habilidad para Evaluar Riesgo
vinculados al concepto Riesgos del Proyecto.
Razonamiento:
Los valores obtenidos permiten determinar:
Nivel de riesgo
Nivel de factor de riesgo evaluable
Los valores obtenidos con destino a la Base de Conocimientos.
Mdulo 1.3.1.1 Estimar Factores Reso

Propsito:
Determinar si existe un sistema anterior desarrollado en objetos y si el
modelo de objetos es aplicable.


Estrategia de reso de aplicacin existente, Reso de aplicacin existente
en OO, Reso de aplicacin a desarrollar en aplicaciones futuras.
Razonamiento:
Existe un sistema anterior desarrollado en objetos si la aplicacin a
desarrollar es un subsistema, ampliacin o modificacin de un sistema
desarrollado en objetos.
Si es necesario reusar software existente desarrollado en objetos o si es
necesario un reso posterior de componentes para el siguiente proyecto
puede considerarse que existe un sistema anterior desarrollado en objetos.
Si se definen explcitamente estrategias de reso de software existente el
modelo de objetos es aplicable.
Conocimientos. Determinacin de la aplicabilidad del modelo de objetos y
existencia de sistema anterior desarrollado en objetos con destino la Base
de Conocimientos.
Mdulo 1.3.1.2 Estimar Factores Mantenimiento

Propsito:
Determinar si el modelo en espiral es aplicable.
Procedimientos para cambios durante el desarrollo, Procedimientos para
Desarrollo y Mantenimiento.
Razonamiento:
Si es factible y necesario usar los mismos procedimientos para desarrollo y
mantenimiento o se requiere de acuerdos confirmados para los cambios
durante el desarrollo, el modelo en espiral es aplicable.
Conocimientos. Determinacin de la aplicabilidad del modelo en espiral con
destino la Base de Conocimientos.
Mdulo 1.3.1.3 Estimar Recursos Software

Propsito:
Determinar si el modelo por prototipo es factible.
Software para prototipar.

Razonamiento:
El modelo por prototipo es factible si se dispone de software para prototipar
o es posible adquirirlo.
Conocimientos. Determinacin de la factibilidad del modelo por prototipo
con destino la Base de Conocimientos.
Mdulo 1.3.1.4 Estimar Factores Administracin

Propsito:
Determinar si existen entregas intermedias, el control y la formalidad de la
gestin, y la conveniencia de usar metodologas.
Formalidad, Entregas, Responsabilidad del desarrollo, control de la
Gestin, Factibilidad de usar una Metodologa, Necesidad de usar una
Metodologa.
Razonamiento:
El ciclo de vida en cascada es recomendable en caso de una gestin de
proyecto muy formal, con un ajustado control, si se terceriza el desarrollo y
si es conveniente usar metodologas ampliamente probadas.
El modelo de objetos es aplicable en caso de que existan entregas
intermedias, que la gestin de proyecto sea poco o medianamente formal, y
que las metodologas a usar estn medianamente probadas.
El modelo por prototipo es aplicable si existen entregas intermedias.
El modelo en espiral es aplicable si las metodologas a usar estn poco
probadas, si la gestin de proyecto es poco o medianamente formal.
Conocimientos. Determinacin de la entregas intermedias, conveniencia de
usar modelos, aplicabilidad de los modelos (objetos, prototipo, espiral,
cascada) con destino la Base de Conocimientos.
Mdulo 1.3.4.1 Estimar Riesgo Existente

Propsito:
Determinar Aceptabilidad del riesgo y la existencia del factor de riesgo y la
aplicabilidad del modelo en espiral.
Viabilidad del software, Factor de riesgo, Categoras riesgo, Estrategias
para incorporar calidad y Terminacin de proyectos.

Razonamiento:
El modelo en espiral es aplicable si existe factor de riesgo, si se definen
mecanismos explcitos para incorporar calidad, si se estima la terminacin
prematura de proyectos no viables.
Si hay dudas sobre la viabilidad del software o se estiman riesgos tcnicos
en el desarrollo del sistema puede decirse que existe factor de riesgo.
El riesgo es aceptable para el modelo en espiral si el factor de riesgo es
mediano o alto.
El riesgo es aceptable para el modelo de objetos si el factor de riesgo es
mediano o bajo.
El modelo en cascada es adecuado si el riesgo es bajo o inexistente.
Conocimientos. Determinacin de la aceptabilidad del riesgo, de la
aplicabilidad del modelo en espiral y de la existencia del factor de riesgo
con destino la Base de Conocimientos.
Mdulo 1.3.4.2 Estimar Habilidad para Evaluar Riesgo

Propsito:
Determinar la evaluabilidad del riesgo, la aplicabilidad del modelo en espiral
y la habilidad para evaluar el riesgo.
Estrategias para el Anlisis de riesgo, Mtodos y tcnicas para Anlisis de
riesgo, Identificacin de Alternativas, Identificacin Riesgos para cada
Alternativa.
Razonamiento:
El modelo en espiral es aplicable si se cuenta con habilidad para la
evaluacin del riesgo y si se definen explcitamente estrategias para
analizar los riesgos. Si se identifican alternativas para resolver los riesgos y
se identifican los riesgos asociados a cada una de esas alternativas, se
cuenta entonces con habilidad para la evaluacin del riesgo.
El factor de riesgo es evaluable si existe factor de riesgo y se cuenta con
habilidad para resolver los riesgos y se cuenta con mtodos y tcnicas para
evaluar el riesgo.
Conocimientos. Determinacin de la evaluabilidad del riesgo, de la
aplicabilidad del modelo en espiral y de la habilidad para evaluar riesgo con
destino la Base de Conocimientos.
6.2.3.2 COMPROBACIN DE LOS CONOCIMIENTOS ESTRATGICOS

El modelo funcional ha sido validado por el experto. Se han realizado

sesiones de entrevistas no estructuradas en las cuales el experto ha evaluado la
representacin de conocimientos para el desempeo de la tarea. La
comprobacin ha sido satisfactoria.
6.2.4 PASO 4: IDENTIFICACIN DE LOS CONOCIMIENTOS TACTICOS
En esta fase se documentan los conocimientos tcticos, es decir, como el

experto usa los hechos conocidos y las hiptesis actuales sobre el caso para
obtener nuevos hechos e hiptesis. Este anlisis ha permitido producir una
definicin detallada de cada paso de razonamiento que deber ejecutar el sistema
experto.
Para representar los conocimientos tcticos se ha utilizado como

representacin intermedia las seudoreglas. Esta representacin es muy familiar
para el experto, por su actividad profesional en el rea de desarrollo de sistemas
informticos. En particular, muchas de las seudoreglas fueron documentndose a
medida que se realizaba la comprobacin de los conocimientos estratgicos.
6.2.4.1 ANALISIS DE LOS CONOCIMIENTOS TACTICOS - SEUDORREGLAS
El conocimiento se representa completando una Hoja de Reglas siguiendo

la propuesta de Gmez [Gmez, A. y otros 1997] con el siguiente diseo:
Estado de la regla Texto de la regla

Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
La Hoja de Reglas se ha completado de la siguiente manera:
Palabras del experto: a partir de las palabras del experto durante la

fase de Adquisicin y como descripcin detallada de la
descomposicin funcional realizada en el paso 2 del proceso de
Conceptualizacin se identificaron las reglas bajo el formato:
SI condicin1,...,condicin n ENTONCES accin1,..., accin n,
siendo este formato habitual para el razonamiento del experto.

Formulacin externa de la reglas: a partir de la identificacin de

reglas del experto se formalizan las reglas considerando la
categorizacin de conceptos realizada en el primer paso del proceso
de Conceptualizacin.
Nombre de la regla: es un nombre que identifica a cada una de las

reglas en la herramienta software (Kappa).
Las seudorreglas se han agrupado de acuerdo con las tres reas definidas
en la Adquisicin de Conocimientos por el grupo de expertos:
rea de Especificacin de Requerimientos: tablas comprendidas entre la 6-4 y

la 6-8.
rea de Tipo de Aplicacin: tablas comprendidas entre la 6-9 y la 6-39.
rea de Gestin de Proyecto: tablas comprendidas entre la 6-40 y la 6-91.
Ciclo de Vida del Proyecto: tablas comprendidas entre la 6-92 y la 6-118

Palabras del experto Si
El usuario ha explicitado los requisitos formalmente y
ha explicitado los requisitos exhaustivamente y ha
explicitado los requisitos uniformemente
Entonces
Se han definido claramente los requisitos del sistema y
Se han definido claramente los lmites del sistema
Formulacin externa Si
Tipo de Definicin es igual a formalmente y
de la regla exhaustivamente y uniformemente
Entonces
Definicin Requisitos es definicin clara y Definicin
Lmites es definicin clara.
Nombre de la regla REGLA ER-R1
Tabla 6-4: Seleccin del Ciclo de vida para el rea Especificacin de Requerimientos


Se han definido claramente los requisitos del sistema y
Se han definido claramente los limites del sistema y El
usuario ha explicitado la mayora de los requerimientos al
comienzo del proyecto
Entonces
La Especificacin de Requerimientos indica usar modelo en
Cascada
Definicin Requisitos es definicin clara y Definicin Limites
de la regla es definicin clara y Grado de Certidumbre al inicio del
proyecto es Mayoritariamente definidos
Entonces
CV Propuesto Requisitos es Cascada.

El usuario ha explicitado los requisitos informalmente y ha
explicitado los requisitos incompletos y ha explicitado los
requisitos desestructuradamente.
Entonces
Hay gran nivel de incertidumbre en la especificacin de
requisitos y Hay alta incertidumbre en el entorno del sistema.
Tipo de Definicin es igual a informalmente e incompleto y
de la regla desestructuradamente
Entonces
Definicin Requisitos es definicin incierta y Definicin
Limites es definicin incierta.

Hay gran nivel de incertidumbre en la especificacin de
requisitos y Hay alta incertidumbre en el entorno del
sistema y El usuario NO ha explicitado la mayora de los
requerimientos al comienzo del proyecto
Entonces
Espiral y La Especificacin de requerimientos indica usar
modelo de Objetos.
Definicin Requisitos es definicin incierta y Definicin
de la regla Limites es definicin incierta y Grado de Certidumbre al
inicio del proyecto es Parcialmente definidos
Entonces
CV Propuesto Requisitos es Espiral y Objetos.


El usuario es muy exigente con los requerimientos del
sistema respecto del producto final.
Entonces
Espiral y La Especificacin de requerimientos indica usar
modelo de Objetos.
Grado de Cumplimiento en Producto final es Usuario muy
de la regla exigente.
Entonces
CV Propuesto Requisitos es Espiral y Objetos.

Se presume independencia entre las fases del desarrollo del
proyecto
Entonces
La necesidad de retroalimentacin en las fases del desarrollo
del proyecto es baja
Relacin Fases desarrollo es igual a Independencia
de la regla Entonces
Retroalimentacin Fases Desarrollo es baja
Nombre de la regla REGLA CV-R1
Tabla 6-9: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin

Se presume poca dependencia entre las fases de desarrollo
del proyecto
Entonces
del proyecto es baja
Relacin Fases desarrollo es igual a Poca Dependencia
Retroalimentacin Fases Desarrollo es baja


Se presume mucha dependencia entre las fases de desarrollo
del proyecto
Entonces
del proyecto es alta
Relacin Fases desarrollo es igual a Mucha Dependencia
Retroalimentacin Fases Desarrollo es alta

Se puede asumir una progresin relativamente uniforme y
secuencial en las fases de desarrollo del proyecto y La
necesidad de retroalimentacin en las fases del desarrollo del
proyecto es baja Y El sistema tiene componentes de fuerte
contenido algortmico
Entonces
Las caractersticas del Tipo de Aplicacin indican usar modelo
en Cascada.
Progresin Fases Desarrollo es uniforme y secuencial y
de la regla Retroalimentacin Fases Desarrollo es baja y Componentes
Predominantes es algortmicos.
Entonces
CV Propuesto Aplicacin es Cascada

secuencial en las fases de desarrollo del proyecto y La
necesidad de retroalimentacin en las fases del desarrollo del
proyecto es baja Y El tipo de aplicacin presenta un
comportamiento predominantemente BATCH
Entonces
Las caractersticas del Tipo Aplicacin indican usar modelo en
Cascada
de la regla Retroalimentacin Fases Desarrollo es baja y Comportamiento
Predominante es batch
Entonces
Nombre de la regla REGLA TA-R101


secuencial en las fases de desarrollo del proyecto Y el
sistema presenta subsistemas de baja complejidad y El
sistema tiene componentes de fuerte contenido algortmico
Entonces
El Tipo de Aplicacin indica usar modelo en Cascada
de la regla Complejidad subsistemas es baja y Componentes
Predominantes es algortmico
Entonces
Tabla 6-14: Seleccin del Ciclo de vida para el rea Tipo de aplicacin

Se puede asumir progresin relativamente uniforme y
secuencial en las fases de desarrollo del proyecto Y el
sistema tiene subsistemas de baja complejidad y el tipo de
aplicacin tiene un comportamiento predominantemente
BATCH
Entonces
El Tipo de Aplicacin indica usar modelo en Cascada
de la regla Complejidad subsistemas es baja y Comportamiento
Predominante es batch
Entonces

Se puede asumir una progresin NO uniforme y secuencial
en las fases de desarrollo del proyecto
Entonces
Las tcnicas de prototipacin son ms convenientes.
Progresin Fases Desarrollo es No uniforme y secuencial
Modelado Prototipo es Conveniente


del proyecto es alta
Entonces
Las tcnicas de prototipacin son ms convenientes
Retroalimentacin Fases Desarrollo es alta

Es necesario descomponer el sistema en pocos niveles para su
mejor comprensin y Es necesario descomponer el sistema en
pocos niveles para su mejor manipulacin
Entonces
El sistema presenta subsistemas de baja complejidad
Niveles de Composicin es Pocos Subsistemas
Complejidad Subsistemas es Baja

Es necesario descomponer el sistema en varios niveles para su
mejor comprensin Y Es necesario descomponer el sistema en
varios niveles para su mejor manipulacin
Entonces
El sistema presenta subsistemas complejos
Niveles de Composicin es Varios Subsistemas
Complejidad Subsistemas es Alta


El sistema se basa en componentes de fuerte contenido
matemtico
Entonces
Las tcnicas de modelado OO son ms convenientes
Componentes Predominantes es matemticos
Modelado Objetos es Conveniente

El sistema se basa en componentes de fuerte contenido
grfico
Entonces
Componentes Predominantes es grficos
Modelado Objetos es conveniente

El sistema tiene subsistemas que presentan comportamiento
dinmico
Entonces
Comportamiento Predominante es dinmico

El tipo de aplicacin presenta comportamiento fuertemente
interactivo
Entonces
Comportamiento Predominante es interactivo


El tipo de aplicacin presenta comportamiento en Tiempo
Real
Entonces
Comportamiento Predominante es tiempo real

El tipo de aplicacin es desarrollo de software de base
Entonces
Orientacin es software de base

El sistema es explcitamente sensible a cambios
Entonces
El sistema presenta una alta variabilidad en los procesos
Tipo Modificacin es Redefinicin
Variabilidad Procesos es Alta

El sistema es explcitamente sensible a extensiones
Entonces
Tipo Modificacin es Extensin


El sistema es explcitamente sensible a ampliaciones.
Entonces
Tipo Modificacin es Ampliacin

El proyecto requiere el descubrimiento de problemas de
arquitectura en etapas tempranas del desarrollo
Entonces
Factores Diseo es Problemas de Arquitectura

El proyecto requiere el descubrimiento de problemas de
eficacia en etapas tempranas del desarrollo
Entonces
Factores Diseo es Problemas de eficacia

Entonces
Tcnica Modelado es Prototipo son ms convenientes


El sistema a disear es innovador
Entonces
Existencia Aplicaciones es Innovador

El tipo de aplicacin es un SSBBCC sistema basado en
conocimientos
Entonces
Orientacin es Sistema Basado en conocimiento

El sistema presenta subsistemas complejos
Entonces
Complejidad Subsistemas es Alta

Las tcnicas de modelado OO son ms convenientes Y
Entonces
El Tipo de Aplicacin indica usar modelo de Objetos
Modelado Objetos es conveniente y Modelado Prototipo es
de la regla conveniente
Entonces
CV Propuesto Aplicacin es Objetos


Las tcnicas de prototipacin son ms convenientes Y
El tipo de aplicacin requiere el desarrollo fuertemente
integrado de hardware y software
Entonces
El Tipo de Aplicacin indica usar modelo en Espiral
Modelado Objetos es conveniente Y Modelado Prototipo es
de la regla conveniente Y Integracin HW-SW es fuertemente
Entonces
CV Propuesto Aplicacin es Espiral

El sistema a desarrollar puede resolverse por varias opciones
de diseo
Entonces
El sistema es multiopcional
Posibilidad Diseo es Varias opciones
Opcionalidad es Mltiple

El sistema a desarrollar puede resolverse por varias opciones
de implementacin
Entonces
Posibilidad Implementacin es Varias opciones
Opcionalidad es Mltiple


Las tcnicas de prototipacin son ms convenientes Y
Entonces
El Tipo de Aplicacin indica usar modelo en Espiral
Modelado Objetos es conveniente Y Modelado Prototipo es
de la regla conveniente Y Opcionalidad es Mltiple
Entonces
CV Propuesto Aplicacin es Espiral
Nombre de la regla REGLA TAR-24

Es necesario usar metodologas ampliamente probadas Y Es
factible usar metodologas ampliamente probadas
Entonces
Es conveniente usar metodologas ampliamente probadas
Necesidad Metodologa es ampliamente probada Y
de la regla Factibilidad Metodologa es ampliamente probada
Entonces
Conveniencia Metodologa es ampliamente probada
Nombre de la regla REGLA GP-R1
Tabla 6-40: Seleccin del Ciclo de vida para el rea Gestin de Proyecto

El factor de riesgo es bajo
Entonces
El riesgo es aceptable para modelo en cascada
Nivel riesgo es bajo
Riesgo Cascada es aceptable

No hay factor de riesgo
Entonces
El riesgo es aceptable para modelo en cascada
Nivel riesgo es no hay riesgo
Riesgo Cascada es aceptable


Es conveniente usar metodologas ampliamente probadas Y No
es necesario disponer de una versin temprana del software
desarrollado hasta que el proyecto este avanzado Y El riesgo
es aceptable para modelo en cascada
Entonces
La Gestin del Proyecto indica usar modelo en Cascada
Conveniencia Metodologa es ampliamente probada Y Entregas
de la regla es versin completa Y Riesgo Cascada es aceptable
Entonces
CV Propuesto Gestin es Cascada

El proyecto requiere una gestin de proyecto muy formal Y No
es necesario disponer de una versin temprana del software
desarrollado hasta que el proyecto este avanzado Y El riesgo
es aceptable para modelo en cascada.
Entonces
Formalidad es muy formal Y Entregas es versin completa Y
de la regla Riesgo Cascada es aceptable
Entonces

No se dispone de software para prototipar y no es posible
adquirir software para prototipar
Entonces
El modelo por prototipo no es factible
Software para prototipar es No disponible y No adquirible
Factibilidad Prototipo es No factible


El modelo por prototipo no es factible Y El riesgo es
aceptable para modelo en cascada
Entonces
Factibilidad Prototipo es No factible Y Riesgo Cascada es
de la regla aceptable
Entonces

Se terceriza el desarrollo Y Se requiere un ajustado control de
la gestin del proyecto Y No es necesario disponer de una
versin temprana hasta que el proyecto este avanzado.
Entonces
Responsabilidad es Terceros Y Control gestin es muy
de la regla ajustado Y Entregas es versin completa
Entonces

Es un subsistema de un sistema desarrollado en Objetos
Entonces
Existe sistema anterior desarrollado en Objetos
Reso aplicacin OO es Subsistema del existente
Sistema OO es existe

Es una ampliacin de un sistema desarrollado en Objetos
Entonces
Reso aplicacin OO es Ampliacin del existente


Es una modificacin de un sistema desarrollado en Objetos
Entonces
Reso aplicacin OO es Modificacin del existente

Se prev una fuerte necesidad de reutilizar los componentes
de un software ya existente desarrollado en Objetos
Entonces
Reso aplicacin OO es Componentes del actual

Se prev una fuerte necesidad de reutilizar los componentes
de un desarrollo para el siguiente proyecto.
Entonces
Reso aplicacin futura es muy necesario

Es necesario una versin temprana disponible del software
desarrollado
Entonces
Existen entregas intermedias
Entregas es Versin temprana
Entrega intermedia es existe


Es necesario disponer de una versin temprana del software
desarrollado con funciones a completar gradualmente
Entonces
Entregas es Versin gradual

Es necesario disponer de una versin parcial del software
desarrollado con funciones a completar gradualmente
Entonces
Entregas es Versin parcial

Entonces
El modelo de Objetos es aplicable Y El modelo por prototipo
es aplicable
Aplicabilidad OO es aplicable y Aplicabilidad prototipo es
aplicable

Se definen explcitamente estrategias de reso de software
existente
Entonces
El modelo de Objetos es aplicable
Reso aplicacin existente es estrategias explcitas
Aplicabilidad OO es aplicable


No hay factor de riesgo
Entonces
El riesgo es aceptable para el modelo de Objetos
Nivel riesgo es No hay riesgo
Riesgo Objetos es aceptable

El factor de riesgo es bajo
Entonces
Nivel riesgo es bajo riesgo

El factor de riesgo es mediano
Entonces
Nivel riesgo es mediano riesgo

Es necesario usar metodologas medianamente probadas Y Es
factible usar metodologas medianamente probadas
Entonces
Es conveniente usar metodologas medianamente probadas
Necesidad Metodologa es medianamente probada Y
de la regla Factibilidad Metodologa es medianamente probada
Entonces
Conveniencia Metodologa es medianamente probada


El proyecto requiere una gestin de proyecto medianamente
formal Y Es conveniente usar metodologas medianamente
probadas
Entonces
Formalidad es medianamente formal Y Conveniencia
de la regla Metodologa es medianamente probada
Entonces

El proyecto requiere una gestin de proyecto poco formal Y Es
conveniente usar metodologas medianamente probadas
Entonces
Formalidad es poco formal Y Conveniencia Metodologa es
de la regla medianamente probada
Entonces

El modelo de Objetos es aplicable Y Existe sistema anterior
desarrollado en Objetos Y El riesgo es aceptable para el
modelo de Objetos
Entonces
La Gestin del Proyecto indica usar modelo de Objetos
Aplicabilidad OO es aplicable Y Sistema OO es existe Y Riesgo
de la regla Objetos es aceptable
Entonces
CV Propuesto Gestin es Objetos
Nombre de la regla REGLA GPR18


Es posible adquirir software para prototipar
Entonces
El modelo por prototipo es factible
Software para prototipar es factible de adquirir
Factibilidad prototipo es factible

Se dispone de software para prototipar
Entonces
El modelo por prototipo es factible
Software para prototipar es hay disponible
Factibilidad prototipo es factible

Es necesario facilitar la introduccin gradual del sistema para
los usuarios
Entonces
El modelo por prototipo es aplicable
Introduccin gradual es necesaria
Aplicabilidad prototipo es aplicable

Es necesario contar con una fuerte participacin del usuario
cliente en el Desarrollo
Entonces
Participacin es fuerte


La gestin del proyecto prev definir explcitamente
estrategias para reusar software existente.
Entonces
Reso aplicacin existente es estrategias explcitas

Equipo de proyecto no tiene experiencia previa en el tipo de
aplicacin a desarrollar
Entonces
Experiencia previa es No hay

Existe inexperiencia con las tcnicas de ingeniera de software
que se usarn
Entonces
Experiencia tcnicas IS es No hay

Es necesario Y factible usar los mismos procedimientos para
desarrollo y mantenimiento del producto software
Entonces
Es conveniente usar los mismos procedimientos para
Procedimientos Desarrollo-Mantenimiento es necesario usar
de la regla los mismos y es factible usar los mismos.
Entonces
Procedimientos D-M es conveniente


Es conveniente usar los mismos procedimientos para
Entonces
El modelo en Espiral es aplicable
Procedimientos D-M es conveniente
Aplicabilidad Espiral es aplicable

Se requiere de acuerdos confirmados para los cambios a
efectuarse durante el desarrollo del proyecto.
Entonces
Procedimientos Cambios es acuerdos confirmados

El desarrollo del sistema es responsabilidad de la organizacin
(no se terceriza)
Entonces
Responsabilidad es organizacin propia

Se identifican los riesgos asociados con cada una de las
alternativas Y Se identifican las diferentes maneras de
resolver los riesgos
Entonces
Se cuenta con habilidad para la evaluacin del riesgo
Riesgos Alternativa es se identifican Y Identificacin
de la regla alternativas es se identifican
Entonces
Habilidad Riesgo es existe


Se cuenta con habilidad para la evaluacin del riesgo Y
Es posible volver a etapas anteriores en el desarrollo del
sistema cuando se identifican mejoras alternativas
Entonces
Habilidad Riesgo es existe Y Identificacin Alternativas es
de la regla etapas anteriores
Entonces

Es necesario volver a etapas anteriores en el desarrollo del
sistema para la resolucin de algn tpico nuevo de riesgo
Entonces
Habilidad Riesgo es existe Y Riesgos Alternativa es etapas
de la regla anteriores
Entonces

Se estima la posibilidad de la terminacin prematura de
Entonces
Habilidad Riesgo es existe Y Terminacin Proyectos es
de la regla prematura
Entonces


Existen dudas sobre la viabilidad del software
Entonces
Existe factor de riesgo
Viabilidad software es hay dudas
Factor riesgo es existe

Se estiman riesgos tcnicos en el desarrollo del sistema
Entonces
Categoras riesgo es tcnico

El factor de riesgo es mediano
Entonces
El riesgo es aceptable para el modelo en Espiral
Nivel riesgo es mediano riesgo
Riesgo Espiral es aceptable

El factor de riesgo es alto
Entonces
Nivel riesgo es alto riesgo


Entonces

Existe factor de riesgo Y Es necesario definir explcitamente
estrategias para realizar anlisis de riesgo
Entonces
Factor riesgo es existe Y Anlisis riesgo es estrategias
de la regla explcitas
Entonces

Existe factor de riesgo Y Es necesario definir mecanismos
explcitos para incorporar objetivos de calidad en el
desarrollo del producto.
Entonces
Factor riesgo es existe Y Objetivo calidad es mecanismos
de la regla explcitos
Entonces


Es necesario usar metodologas poco probadas Y Es factible
usar metodologas poco probadas
Entonces
Es conveniente usar metodologas poco probadas
Necesidad Metodologa es poco probada Y Factibilidad
de la regla Metodologa es poco probada
Entonces
Conveniencia Metodologa es poco probada

El proyecto requiere una gestin de proyecto medianamente
formal Y Es conveniente usar metodologas poco probadas
Entonces
Formalidad es medianamente formal Y Conveniencia
de la regla Metodologa es poco probada
Entonces

El proyecto requiere una gestin de proyecto poco formal Y Es
conveniente usar metodologas poco probadas
Entonces
Formalidad es poco formal Y Conveniencia Metodologa es
de la regla poco probada
Entonces


Existe factor de riesgo Y Se cuenta con habilidad para la
evaluacin del riesgo Y Se cuenta con mtodos y tcnicas para
evaluar el riesgo
Entonces
El factor de riesgo es evaluable
Factor Riesgo es existe Y Habilidad riesgo es existe Y Tcnicas
de la regla AR es se dispone
Entonces
Riesgo es evaluable

El modelo por prototipo es aplicable Y El modelo por
prototipo es factible Y El factor de riesgo es evaluable Y El
modelo en Espiral es aplicable
Entonces
La Gestin del Proyecto indica usar modelo en Espiral
Aplicabilidad Prototipo es aplicable Y Factibilidad prototipo
de la regla es factible Y Riesgo es evaluable Y Aplicabilidad Espiral es
aplicable
Entonces
CV Propuesto Gestin es Espiral

Cascada Y El Tipo de Aplicacin indica usar modelo en
Cascada Y La Gestin de Proyecto indica usar modelo en
Cascada
Entonces
El Ciclo de Vida sugerido es Cascada
CV Propuesto Requisitos es Cascada Y CV Propuesto Aplicacin
de la regla es Cascada Y CV Propuesto Gestin es Cascada
Entonces
El CV Propuesto Proyecto es Cascada
Nombre de la regla REGLA R0
Tabla 6-92: Seleccin del Ciclo de vida para Proyecto


La Especificacin de Requerimientos indica usar modelo de
Objetos Y El Tipo de Aplicacin indica usar modelo de
Objetos Y La Gestin de Proyecto indica usar modelo de
Objetos
Entonces
El Ciclo de Vida sugerido es Objetos
CV Propuesto Requisitos es Objetos Y CV Propuesto Aplicacin
de la regla es Objetos Y CV Propuesto Gestin es Objetos Entonces
El CV Propuesto Proyecto es Objetos
Tabla 6-93: Seleccin del Ciclo de vida para el Proyecto

Espiral Y El Tipo de Aplicacin indica usar modelo en Espiral
Y La Gestin de Proyecto indica usar modelo en Espiral
Entonces
El Ciclo de Vida sugerido es Espiral
CV Propuesto Requisitos es Espiral Y CV Propuesto Aplicacin
de la regla es Espiral Y CV Propuesto Gestin es Espiral
Entonces
El CV Propuesto Proyecto es Espiral

Cascada Y La Gestin de Proyecto indica usar modelo de
Objetos
Entonces
de la regla es Cascada Y CV Propuesto Gestin es Objetos
Entonces


Cascada Y El Tipo de Aplicacin indica usar modelo de
Objetos Y La Gestin de Proyecto indica usar modelo en
Cascada
Entonces
de la regla es Objetos Y CV Propuesto Gestin es Cascada
Entonces

Objetos Y El Tipo de Aplicacin indica usar modelo en
Cascada
Entonces
Entonces

Espiral
Entonces
de la regla es Cascada Y CV Propuesto Gestin es Espiral
Entonces


Cascada Y El Tipo de Aplicacin indica usar modelo en Espiral
Y La Gestin de Proyecto indica usar modelo en Cascada
Entonces
de la regla es Espiral Y CV Propuesto Gestin es Cascada
Entonces

Espiral Y El Tipo de Aplicacin indica usar modelo en Cascada
Entonces
Entonces

Cascada
Entonces
Entonces


Cascada Y La Gestin de Proyecto indica usar modelo de
Objetos
Entonces
Entonces

Cascada Y El Tipo de Aplicacin indica usar modelo de
Objetos Y La Gestin de Proyecto indica usar modelo de
Objetos
Entonces
de la regla es Objetos Y CV Propuesto Gestin es Objetos
Entonces

Espiral
Entonces
de la regla es Objetos Y CV Propuesto Gestin es Espiral
Entonces


Objetos Y El Tipo de Aplicacin indica usar modelo en Espiral
Y La Gestin de Proyecto indica usar modelo de Objetos
Entonces
de la regla es Espiral Y CV Propuesto Gestin es Objetos
Entonces

Espiral Y El Tipo de Aplicacin indica usar modelo de Objetos
Entonces
de la regla es Objetos Y CV Propuesto Gestin es Objetos
Entonces

Entonces
Entonces


Entonces
Entonces

Entonces
Entonces

Entonces
Entonces


Entonces
Entonces

Objetos Y El Tipo de Aplicacin indica usar modelo en Espiral
Entonces
Entonces

Y La Gestin de Proyecto indica usar modelo en Objetos
Entonces
Entonces


Espiral
Entonces
Entonces

Espiral
Entonces
Entonces

Objetos Y El Tipo de Aplicacin indica usar modelo de Espiral
Entonces
Entonces


Entonces
Entonces

Entonces
Entonces
6.2.4.2 COMPROBACION DE LOS CONOCIMIENTOS TACTICOS
El experto ha completado, validado y revisado todas las seudorreglas,

considerando los casos de prueba descriptos en el Captulo 9 y se ha
comprobado si el accionar del experto coincida con las representaciones de los
conocimientos tcticos. Esto permiti ajustar las seudorreglas que se
relacionaban con el anlisis del riesgo.
6.2.5 PASO 5: IDENTIFICACIN DE LOS CONOCIMIENTOS FACTICOS
Se completa la identificacin de los conocimientos fcticos iniciada en el

paso 1 y 2 (identificacin, comparacin, categorizacin y relaciones entre los
conceptos). Los conocimientos fcticos del experto contienen informacin que el
SE conocer a priori acerca del rea de aplicacin y la informacin que el
sistema obtendr acerca del caso especfico al ejecutar la tarea. En este paso se
organiza la informacin recopilada acerca de cada atributo general de acuerdo al
formato estndar propuesto por Gmez [Gmez, A y otros 1997].

6.2.5.1 ANALISIS DE LOS CONOCIMIENTOS FACTICOS
En el presente trabajo los atributos pueden clasificarse en tres grupos:

Los valores ingresados por el usuario del SE, que identifican al proyecto
analizado y no participan en el proceso de razonamiento.
Los valores ingresados por el usuario del SE, a partir de su conocimiento
respecto del proyecto informtico a desarrollar.
Los valores deducidos a partir de los valores ingresados por el usuario
del sistema.
Estos atributos se describen en las tablas 6-119 a 6-192 que se presentan
a continuacin.
Informacin Descripcin
Nombre Identificacin
Concepto Proyecto
Descripcin Identifica al proyecto que se esta analizando.
Tipo Valor Cdigo Univoco
Rango de valores Valor alfanumrico
Nro. Valores por caso Mnimo 1
Fuente Ingresada por el usuario
Detalles acerca del No hay mtodo especifico ya que es nombre de un archivo que
mtodo para obtener guarda datos identificatorios del proceso.
esta informacin
Confiabilidad de los El sistema verifica que no puedan ingresarse valores ya existentes en
datos de entrada el directorio seleccionado.
Uso Permite identificar el proyecto analizado.
Formato de los Valor alfanumrico. No actualiza ningn atributo, no afecta el
resultados de salida proceso de seleccin del CV.
Material de soporte ___
Tabla 6-119: Descripcin del atributo Identificacin
Nombre Nombre del proyecto
Concepto Proyecto
Descripcin Describe el nombre del proyecto.
Tipo Valor Texto
Rango de valores Valores alfanumricos
Nro. Valores por caso Mnimo 0, Mximo 1
Detalles acerca del No hay mtodo.
mtodo para obtener
esta informacin
Confiabilidad de los ___
datos de entrada
Uso Identificar al proyecto por nombre.
Formato de los Valor alfanumrico. No actualiza ningn atributo, no afecta el
resultados de salida proceso de seleccin del CV.
Tabla 6-120: Descripcin del atributo Nombre del Proyecto

Nombre Lder del proyecto
Concepto Proyecto
Descripcin Nombre y apellido del lder del proyecto que se esta analizando.
Tipo Valor Texto
mtodo para obtener
esta informacin
datos de entrada
Uso Identificar al lder del proyecto por nombre.
Formato de los No actualiza atributos, no afecta el proceso de seleccin del CV.
resultados de salida
Tabla 6-121: Descripcin del atributo Lder del Proyecto
Nombre Fecha inicio
Concepto Proyecto
Descripcin Identifica la fecha en la que se inici el proyecto.
Tipo Valor Numrico: DD/MM/AAAA
Rango de valores DD 1-31; MM: 1-12; AAAA 1900 en adelante.
mtodo para obtener
esta informacin
Confiabilidad de los La fecha no puede ser mayor a la fecha del da.
datos de entrada
Uso Permite conocer la fecha de inicio del proyecto.
Tabla 6-122: Descripcin del atributo Fecha inicio
Nombre Fecha finalizacin
Concepto Proyecto
Descripcin Es la fecha en la que se termin o se estima terminar el proyecto.
Tipo Valor Numrico: DD/MM/AAAA
Rango de valores DD 1-31; MM: 1-12; AAAA 1900 en adelante.
mtodo para obtener
esta informacin
Confiabilidad de los La fecha debe ser mayor a la fecha de entrada.
datos de entrada
Uso Permite conocer la fecha de inicio del proyecto.
Tabla 6-123: Descripcin del atributo Fecha finalizacin

Nombre Objetivo
Concepto Proyecto
Descripcin Describe el objetivo del proyecto desarrollar
Tipo Valor Texto
mtodo para obtener
esta informacin
datos de entrada
Uso Permite conocer el objetivo del proyecto a desarrollar.
Tabla 6-124: Descripcin del atributo Objetivo
Nombre CV propuesto por SE
Concepto Proyecto
Descripcin Identifica el ciclo de vida propuesto por el Sistema Experto para el
proyecto a desarrollar
Tipo Valor Texto
Rango de valores Cascada, Objetos, Espiral, No hay propuesta
Fuente Obtenido a partir de CV Propuesto Requisitos, CV Propuesto
Aplicacin, CV Propuesto Gestin
Detalles acerca del De acuerdo con los de CV Propuesto Requisitos, CV Propuesto
mtodo para obtener Aplicacin, CV Propuesto Gestin se estima el ciclo de vida mas
esta informacin adecuado para el Proyecto
Confiabilidad de los __
datos de entrada
Uso Permite conocer el ciclo de vida ms adecuado para las
caractersticas del proyecto analizado propuesto por el SE.
Formato de los Texto. Se actualiza cuando se actualiza el atributo CV Propuesto
resultados de salida Proyecto. Se graba en archivo del proyecto. No afecta el proceso de
seleccin del CV.
Material de soporte Sesiones: A.4.5 sesin IV, A.4.3 sesin VI, A.4.4 sesin VII, A.4.5
sesin VIII
Tabla 6-125: Descripcin del atributo CV propuesto por SE

Nombre CV seleccionado
Concepto Proyecto
Descripcin Identifica el ciclo de vida seleccionado por el Lder del proyecto a
desarrollar
Tipo Valor Texto
Rango de valores Cascada, Objetos, Espiral, Otros
mtodo para obtener
esta informacin
datos de entrada
Uso Permite conocer el CV seleccionado por el lder del proyecto
Tabla 6-126: Descripcin del atributo CV seleccionado
Nombre Tipo de Definicin
Concepto Requisitos
Descripcin Describe la forma en la que se han definido los requisitos del
proyecto a desarrollar
Tipo Valor Texto
Rango de valores Formalmente, Informalmente, Exhaustivamente, Incompleto,
Uniformemente, Desestructuradamente
Detalles acerca del Valor estimado por el usuario del sistema experto a partir del
mtodo para obtener Informe de requerimientos del proyecto a desarrollar y de las
esta informacin primeras entrevistas con los usuarios. Se analiza el grado de
detalle, si existen omisiones, si estn documentados con alguna
metodologa , si estn descriptos en forma estructurada
(ordenada, pareja, semejante) respectivamente.
Confiabilidad de los El sistema experto verifica que no puedan ingresarse valores
datos de entrada opuestos como formalmente e informalmente al mismo tiempo.
Uso Permite determinar si los requisitos y los limites del sistema
estn claramente definidos
Formato de los Texto. Actualiza los atributos Definicin Requisitos y Definicin
resultados de salida Limites
Material de soporte Sesines: A.4.5 sesin IV, A.4.3 sesin VI, A.4.4 sesin VII, A.4.5
sesin VIII
Tabla 6-127: Descripcin del atributo Tipo de Definicin

Nombre Grado de Certidumbre
Concepto Requisitos
Descripcin Describe el nivel de certidumbre en el que se han definido los
requisitos al inicio del proyecto a desarrollar
Tipo Valor Texto
Rango de valores Mayoritariamente definidos, Parcialmente definidos
esta informacin primeras entrevistas con los usuarios. Se consideran
mayoritariamente definidos si han sido definidos el 90 % o ms de
los requerimientos y parcialmente definidos si se han definido
menos del 90 % al inicio del sistema para ambos casos.
Confiabilidad de los El sistema experto verifica que slo pueda ingresarse uno de los
datos de entrada valores, ya que son opuestos.
Uso Permite determinar junto con otros atributos la seleccin del
ciclo de vida para el rea Especificacin de Requerimientos.
Formato de los Texto. Actualiza, en combinacin con los atributos Definicin
resultados de salida Requisitos y Definicin Limites, el atributo CV Propuesto
Requisitos
sesin VIII
Tabla 6-128 Descripcin del atributo Grado de Certidumbre
Nombre Grado de Cumplimiento
Concepto Requisitos
Descripcin Describe el nivel de exigencia en el cumplimiento de los
requerimientos en el producto final, que espera el usuario que
contrata el desarrollo de la aplicacin.
Tipo Valor Texto
Rango de valores Usuario muy exigente, Usuario poco exigente
esta informacin primeras entrevistas con los usuarios.
Uso Permite determinar la seleccin del ciclo de vida para el rea
Especificacin de Requerimientos.
Formato de los Texto. Actualiza el atributo CV Propuesto Requisitos.
sesin VIII
Tabla 6-129 Descripcin del atributo Grado de Cumplimiento

Nombre Definicin Requisitos
Concepto Requisitos
Descripcin Describe el nivel de certidumbre en la definicin de los requisitos
al inicio del proyecto.
Tipo Valor Texto
Rango de valores Definicin clara, Definicin incierta, Alta incertidumbre, Baja
incertidumbre
Fuente Obtenido a partir del Tipo de Definicin
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Tipo de
mtodo para obtener Definicin se estima si la definicin es clara, incierta, alta o baja.
esta informacin
datos de entrada
sesin VIII
Tabla 6-130 Descripcin del atributo Definicin Requisitos
Nombre Definicin Lmites
Concepto Requisitos
Descripcin Describe el nivel de certidumbre en la definicin de los lmites o
contexto al inicio del proyecto..
Tipo Valor Texto
Rango de valores Definicin clara, Definicin incierta, Alta incertidumbre, Baja
incertidumbre
Fuente Obtenido a partir del Tipo de Definicin
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Tipo de
mtodo para obtener Definicin se estima si la definicin es clara, incierta, alta o baja
esta informacin
datos de entrada
sesin VIII
Tabla 6-131 Descripcin del atributo Definicin Lmites

Nombre Niveles de Composicin
Concepto Aplicacin
Descripcin Describe el nivel de composicin necesario del sistema en
subsistemas para alcanzar una mejor comprensin y manipulacin
del sistema a desarrollar.
Tipo Valor Texto
Rango de valores Pocos subsistemas, Varios subsistemas
Uso Permite determinar si los subsistemas que componen el sistema
son de baja o alta complejidad.
Formato de los Texto. Actualiza el atributo Complejidad subsistemas.
sesin VIII
Tabla 6-132 Descripcin del atributo Niveles de Composicin
Nombre Complejidad Subsistemas
Concepto Aplicacin
Descripcin Describe el nivel de complejidad de los subsistemas componentes
de la aplicacin a desarrollar.
Tipo Valor Texto
Rango de valores Baja, Alta
Fuente Obtenido a partir de Niveles de Composicin
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Niveles de
mtodo para obtener Composicin se estima si la complejidad es alta o baja.
esta informacin
datos de entrada
Uso Permite determinar junto con otros atributos ( Progresin Fases
Desarrollo Retroalimentacin Fases Desarrollo, Componentes
Predominantes y Comportamiento Predominante) si el modelo en
cascada es adecuado para el rea Tipo de Aplicacin.
Formato de los Texto. Participa en la actualizacin del atributo CV Propuesto
resultados de salida Aplicacin.
sesin VIII
Tabla 6-133 Descripcin del atributo Complejidad Subsistemas

Nombre Componentes Predominantes
Concepto Aplicacin
Descripcin Describe el componente predominante en la aplicacin a
desarrollar.
Tipo Valor Texto
Rango de valores Algortmicos, Matemticos, Grficos
Confiabilidad de los No son opciones excluyentes.
datos de entrada
Uso Permite determinar si las tcnicas de modelado orientadas a objetos
son adecuadas para esos componentes. Permite determinar junto
con otros atributos (Complejidad subsistemas, Progresin Fases
Desarrollo Retroalimentacin Fases Desarrollo) si el modelo en
Formato de los Texto. Actualiza el atributo Modelado Objetos y participa en la
resultados de salida actualizacin del atributo CV Propuesto Aplicacin.
sesin VIII
Tabla 6-134 Descripcin del atributo Componentes Predominantes
Nombre Comportamiento Predominante
Concepto Aplicacin
Descripcin Describe el comportamiento predominante en la aplicacin a
desarrollar.
Tipo Valor Texto
Rango de valores Batch, Dinmico, Interactivo, Tiempo Real
esta informacin primeras entrevistas con los usuarios. Se considera Batch si la
modalidad de procesamiento predominante es diferida y dinmico si
no lo es. La modalidad es interactiva cuando hay dialogo entre el
usuario y la aplicacin, y si el tiempo de procesamiento es
interactivo dentro de un ajustado y limitado margen de tiempo para
producir las respuestas, se considera tiempo real.
Confiabilidad de los No son opciones excluyentes, pero es conveniente que el usuario
datos de entrada seleccione una de ellas como predominante. La opcin Batch excluye
a las otras tres y viceversa.
son adecuadas para ese comportamiento predominante. Permite
determinar junto con otros atributos (Complejidad subsistemas,
Progresin Fases Desarrollo Retroalimentacin Fases Desarrollo) si el
modelo en cascada es adecuado para el rea Tipo de Aplicacin.
Formato de los Texto. Actualiza el atributo Modelado Objetos y participa en la
sesin VIII
Tabla 6-135 Descripcin del atributo Comportamiento Predominante

Nombre Relacin Fases Desarrollo
Concepto Aplicacin
Descripcin Describe el grado de dependencia entre las fases de desarrollo
del proyecto.
Tipo Valor Texto
Rango de valores Mucha Dependencia, Poca Dependencia, Independencia
mtodo para obtener Informe de requerimientos y de las primeras entrevistas con los
esta informacin usuarios.
datos de entrada valores, ya que son excluyentes.
Uso Permite determinar si la retroalimentacin entre las fases de
desarrollo del proyecto el alta o baja.
Formato de los Texto. Actualiza el atributo Retroalimentacin Fases Desarrollo.
sesin VIII
Tabla 6-136 Descripcin del atributo Relacin Fases desarrollo
Nombre Retroalimentacin Fases Desarrollo
Concepto Aplicacin
Descripcin Describe el grado de relacin de retroalimentacin que se estima
entre las fases de desarrollo del proyecto.
Tipo Valor Texto
Rango de valores Alta, Baja
Fuente Obtenido a partir de Relacin Fases Desarrollo
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Relacin
mtodo para obtener Fases Desarrollo se estima si la retroalimentacin es alta o baja.
esta informacin
datos de entrada
Uso Permite determinar si el Modelado en Prototipo es Conveniente.
Permite determinar junto con otros atributos ( Progresin Fases
Desarrollo, Complejidad Subsistemas, Componentes
Predominantes y Comportamiento Predominante) si el modelo en
Formato de los Texto. Participa en la actualizacin de los atributos, Modelado
resultados de salida Prototipo y CV Propuesto Aplicacin.
sesin VIII
Tabla 6-137 Descripcin del atributo Retroalimentacin Fases desarrollo

Nombre Orientacin
Concepto Aplicacin
Descripcin Describe la orientacin con la que se va a modelar y formalizar la
Tipo Valor Texto
Rango de valores Software de base, Sistema Basado en Conocimiento, Otros
esta informacin primeras entrevistas con los usuarios. Segn el problema pueda
resolverse por el desarrollo de mtodos convencionales de tipo
algortmicos o sean problemas que requieren de heursticas para
alcanzar la solucin se analiza si es un sistema basado en
conocimiento. El sistema puede ser una aplicacin que esta
orientada a dar un servicio bsico (como procesador de textos,
prototipador, sistema operativo) una aplicacin directa.
Confiabilidad de los Son opciones excluyentes.
datos de entrada
o de prototipacin son adecuadas para esa orientacin.
Permite determinar junto con otros atributos (Complejidad
subsistemas, Progresin Fases Desarrollo Retroalimentacin Fases
Desarrollo) si el modelo en cascada es adecuado para el rea Tipo de
Aplicacin.
Formato de los Texto. Actualiza los atributos Modelado Objetos y Modelado
resultados de salida Prototipo y participa en la actualizacin del atributo CV Propuesto
Aplicacin.
sesin VIII
Tabla 6-138 Descripcin del atributo Orientacin
Nombre Integracin HW-SW
Concepto Aplicacin
Descripcin Describe el grado de integracin entre los componentes de hardware
y software que requiere la aplicacin a desarrollar.
Tipo Valor Texto
Rango de valores Fuertemente, Medianamente, Levemente
Uso Permite determinar junto con otros atributos (Modelado Objetos,
Modelado Prototipo y Opcionalidad) si el modelo en espiral o el
modelo de objetos es adecuado para el rea Tipo de Aplicacin.
sesin VIII
Tabla 6-139 Descripcin del atributo Integracin HW-SW

Nombre Progresin Fases Desarrollo
Concepto Aplicacin
Descripcin Describe el modo en el que se puede avanzar cumpliendo las
etapas del ciclo de vida durante el desarrollo de la aplicacin.
Tipo Valor Texto
Rango de valores Uniforme y Secuencial, No uniforme y secuencial
esta informacin usuarios. Si el modo de avance es desparejo y con distintos
ritmos, cumplida una etapa se puede volver a la anterior o
continuar con otra sin seguir un ordenamiento entonces la
progresin a travs de las fases de desarrollo es No uniforme y
secuencial. Si las fases se cumplen en una sucesin ordenada de
modo que cada actividad determina la siguiente y el avance es
gradual y parejo entonces la progresin se considera uniforme y
secuencial.
Uso Permite determinar si las tcnicas de prototipacin son
adecuadas para esa orientacin. Permite determinar junto con
otros atributos (Complejidad subsistemas, Progresin Fases
Desarrollo Retroalimentacin Fases Desarrollo) si el modelo en
Formato de los Texto. Actualiza el atributo Modelado Prototipo y participa en la
sesin VIII
Tabla 6-140 Descripcin del atributo Progresin Fases desarrollo
Nombre Factores Diseo
Concepto Aplicacin
Descripcin Describe algunos problemas a considerar en etapas tempranas del
desarrollo en los factores de diseo vinculados a la arquitectura y
eficacia del sistema.
Tipo Valor Texto
Rango de valores Problemas de Arquitectura, Problemas de Eficacia
Confiabilidad de los No se consideran valores excluyentes.
datos de entrada
adecuadas para esa orientacin.
Formato de los Texto. Actualiza el atributo Modelado Prototipo.
sesin VIII
Tabla 6-141 Descripcin del atributo Factores Diseo

Nombre Existencia Aplicaciones
Concepto Aplicacin
Descripcin Describe si la aplicacin a desarrollar es innovadora o ya existen
aplicaciones similares.
Tipo Valor Texto
Rango de valores Innovador, Conocido
esta informacin usuarios y de su propio conocimiento del mercado de productos
de software
adecuadas para esa orientacin.
Formato de los Texto. Actualiza el atributo Modelado Prototipo.
sesin VIII
Tabla 6-142 Descripcin del atributo Existencia Aplicaciones
Nombre Posibilidad Diseo
Concepto Aplicacin
Descripcin Describe las posibilidades de modelos formales o de diseo a
considerar a partir de un mismo modelo de anlisis.
Tipo Valor Texto
Rango de valores Pocas opciones, Varias opciones
esta informacin usuarios y de su propia experiencia en el proceso de
formalizacin.
Si las posibilidades de desarrollo de modelos formales son tres o
menos se considera que el valor del atributo puede ser pocas
opciones, si las posibilidades son mas de tres entonces se
consideran varias.
Uso Permite determinar si el sistema puede considerarse con
opcionalidades mltiples o simples.
Formato de los Texto. Actualiza el atributo Opcionalidad.
sesin VIII
Tabla 6-143 Descripcin del atributo Posibilidad Diseo

Nombre Tipo Modificacin
Concepto Aplicacin
Descripcin Describe las modificaciones que pueda tener la aplicacin que se
encuentren explcitamente prevista en los datos y los procesos.
Tipo Valor Texto
Rango de valores Redefinicin, Extensin, Ampliacin, Emisin gradual
Detalles acerca del Valor estimado por el usuario del SE a partir del Informe de
mtodo para obtener requerimientos, de las entrevistas con los usuarios y de su
esta informacin experiencia en el tipo de aplicacin y el negocio.
Se considera ampliacin cuando por nuevos requerimientos se
agregan funciones o procesos al sistema ya implementado. Se
considera redefinicin al cambio de los procedimientos de una o
varias funciones principales ya implementadas en un sistema.
Se considera extensin cuando es necesario dar mayor funcionalidad
a los procesos existentes ya implementados. Se extienden, no
aumentan las funciones sino algn aspecto de alguna de ellas.
Emisin gradual es una nueva edicin de una aplicacin con
modificaciones notables respecto de emisiones anteriores. Es una
nueva versin de la aplicacin. Abarca la aplicacin en su totalidad.
datos de entrada
Uso Permite determinar si el sistema presenta alta variabilidad en los
procesos y/o datos.
Formato de los Texto. Actualiza el atributo Variabilidad Procesos
sesin VIII
Tabla 6-144 Descripcin del atributo Tipo Modificacin
Nombre Modelado Objetos
Concepto Aplicacin
Descripcin Describe si el modelado en objetos es aplicable en el desarrollo de la
aplicacin.
Tipo Valor Texto
Rango de valores Conveniente, No conveniente
Fuente Obtenido a partir de Orientacin, Componentes Predominantes,
Comportamiento Predominante.
Detalles acerca del De acuerdo con los valores ingresados por el Orientacin,
mtodo para obtener Componentes Predominantes, Comportamiento Predominante se
esta informacin estima si el modelado por objetos es conveniente o no.
datos de entrada
Uso Permite determinar junto con otros atributos (Modelado Prototipo,
Opcionalidad, Integracin HW-SW) si el modelo en Objetos o Espiral
es adecuado para el rea Tipo de Aplicacin.
sesin VIII
Tabla 6-145 Descripcin del atributo Modelado Objetos

Nombre Modelado Prototipo
Concepto Aplicacin
Descripcin Describe si el modelado en prototipo es aplicable en el desarrollo
de la aplicacin.
Tipo Valor Texto
Fuente Obtenido a partir de Complejidad Subsistemas, Retroalimentacin
Fases Desarrollo, Variabilidad Procesos, Progresin Fases
Desarrollo, Existencia Aplicaciones, Factores Diseo, Orientacin.
Detalles acerca del De acuerdo con los valores ingresados por el usuario Complejidad
mtodo para obtener Subsistemas, Retroalimentacin Fases Desarrollo, Variabilidad
esta informacin Procesos, Progresin Fases Desarrollo, Existencia Aplicaciones,
Factores Diseo, Orientacin se estima si el modelado por
prototipo es conveniente o no.
datos de entrada
Opcionalidad, Integracin HW-SW) si el modelo en Objetos o
Espiral es adecuado para el rea Tipo de Aplicacin.
sesin VIII
Tabla 6-146 Descripcin del atributo Modelado Prototipo
Nombre Variabilidad Procesos
Concepto Aplicacin
Descripcin Describe el nivel de variabilidad esperado en los procesos de la
Tipo Valor Texto
Rango de valores Alta, Baja
Fuente Obtenido a partir de Tipo Modificacin
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Tipo
mtodo para obtener Modificacin se estima si la variabilidad es alta o baja.
esta informacin
datos de entrada
Uso Permite determinar junto con otros atributos (Complejidad
Subsistemas, Retroalimentacin Fases Desarrollo, Progresin
Fases Desarrollo, Existencia aplicaciones y Factores Diseo) si el
Modelado en Prototipo es Conveniente.
Formato de los Texto. Participa en la actualizacin de los atributos, Modelado
resultados de salida Prototipo.
sesin VIII
Tabla 6-147 Descripcin del atributo Variabilidad Procesos

Nombre Opcionalidad
Concepto Aplicacin
Descripcin Describe el tipo de opciones de diseo e implementacin que se
estima tiene la aplicacin a desarrollar.
Tipo Valor Texto
Rango de valores Mltiple, Simple
Fuente Obtenido a partir de Posibilidad Diseo y Posibilidad
Implementacin.
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Posibilidad
mtodo para obtener Diseo y Posibilidad Implementacin se estima si la opcionalidad es
esta informacin mltiple o simple.
datos de entrada
modelado Prototipo, Integracin HW-SW) si el modelo en Objetos o
Espiral es adecuado para el rea Tipo de Aplicacin.
Formato de los Texto. Participa en la actualizacin del atributo, CV Propuesto
sesin VIII
Tabla 6-148 Descripcin del atributo Opcionalidad
Nombre Posibilidad Implementacin
Concepto Aplicacin
Descripcin Describe las posibilidades de modelos implementables
computacionalmente a partir de un modelo de diseo y de un mismo
modelo de anlisis.
Tipo Valor Texto
Rango de valores Pocas opciones, Varias opciones
esta informacin usuarios y de su propio conocimiento de proceso de codificacin y
formalizacin.
Si las posibilidades de desarrollo de modelos programados son tres o
menos se considera que el valor del atributo puede ser pocas
opciones, si las posibilidades son mas de tres entonces se consideran
varias.
Uso Permite determinar si el sistema puede considerarse con
opcionalidad es mltiples o simples.
Formato de los Texto. Actualiza el atributo Opcionalidad.
sesin VIII
Tabla 6-149 Descripcin del atributo Posibilidad Implementacin

Nombre Formalidad
Concepto Coordinacin
Descripcin Describe el grado de formalidad que se requiere para la gestin
del proyecto a desarrollar.
Tipo Valor Texto
Rango de valores Poco formal, Medianamente formal, Muy formal
Detalles acerca del Valor estimado por el usuario del SE a partir del Informe de
mtodo para obtener requerimientos y de las primeras entrevistas con los usuarios y de
esta informacin su propio conocimiento del tipo de aplicacin y del negocio.
Uso Permite determinar junto con otros atributos la aplicabilidad el
modelo de objetos, espiral o cascada.
Formato de los Texto. Actualiza junto con otros atributos el atributo
resultados de salida Aplicabilidad OO, Aplicabilidad Espiral y Cv Propuesto Gestin.
sesin VIII
Tabla 6-150 Descripcin del atributo Formalidad
Nombre Entregas
Descripcin Describe si es necesario gestionar la entrega de versiones
tempranas o versiones parciales o graduales de la aplicacin a
desarrollar.
Tipo Valor Texto
Rango de valores Versin temprana, no versin temprana, versin gradual, versin
parcial
esta informacin usuarios y de su propio conocimiento de proceso del tipo de
aplicacin y del negocio.
modelo en cascada y la existencia de entregas intermedias.
Formato de los Texto. Actualiza junto con otros atributos el atributo Entrega
resultados de salida Intermedia y Cv Propuesto Gestin.
sesin VIII
Tabla 6-151 Descripcin del atributo Entregas

Nombre Responsabilidad
Descripcin Describe quien tiene la responsabilidad del desarrollo de la
aplicacin. Es decir si el desarrollo se terceriza o no.
Tipo Valor Texto
Rango de valores Terceros, Organizacin propia
modelo de objetos, espiral o cascada.
Formato de los Texto. Actualiza junto con otros atributos el atributo,
resultados de salida Aplicabilidad Espiral y Cv Propuesto Gestin.
sesin VIII
Tabla 6-152 Descripcin del atributo Responsabilidad
Nombre Control gestin
Descripcin Describe el grado de control que se requiere para la gestin del
proyecto a desarrollar.
Tipo Valor Texto
Rango de valores Muy ajustado, Medianamente ajustado, Poco ajustado
modelo cascada.
Formato de los Texto. Actualiza junto con otros atributos el atributo Cv
resultados de salida Propuesto Gestin.
sesin VIII
Tabla 6-153 Descripcin del atributo Control gestin

Nombre Software para prototipar
Descripcin Describe la disponibilidad de software para prototipar para ser
usado en el proyecto a desarrollar.
Tipo Valor Texto
Rango de valores No disponible, Hay disponible, Factible de adquirir, No adquirible
Confiabilidad de los No se consideran excluyentes.
datos de entrada
Uso Permite determinar junto con otros atributos la factibilidad de
usar prototipos en el desarrollo de la aplicacin.
Formato de los Texto. Actualiza el atributo Factibilidad Prototipo.
sesin VIII
Tabla 6-154 Descripcin del atributo Software para prototipar
Nombre Factibilidad Metodologa
Descripcin Describe el grado o nivel de prueba, de conocimiento general
acerca de la metodologa que es posible usar para el desarrollo
de la aplicacin.
Tipo Valor Texto
Rango de valores Ampliamente probada, Medianamente probada, Poco probada
Uso Permite determinar junto con otros atributos la conveniencia de
usar metodologas segn haya sido probada previamente en el
desarrollo de otras aplicaciones..
Formato de los Texto. Actualiza el atributo Conveniencia Metodologa.
sesin VIII
Tabla 6-155 Descripcin del atributo Factibilidad Metodologa

Nombre Necesidad Metodologa
Descripcin Describe el grado o nivel de prueba, de conocimiento general
acerca de la metodologa que es necesario usar para el desarrollo
de la aplicacin.
Tipo Valor Texto
usar metodologas segn haya sido probada previamente en el
desarrollo de otras aplicaciones..
Formato de los Texto. Actualiza el atributo Conveniencia Metodologa.
sesin VIII
Tabla 6-156 Descripcin del atributo Necesidad Metodologa
Nombre Reso aplicacin OO
Descripcin Describe si el sistema a desarrollar esta relacionado con algn
sistema previo desarrollado segn el paradigma de orientacin a
objetos.
Tipo Valor Texto
Rango de valores Subsistema del existente, Ampliacin del existente, Modificacin
del existente, Componentes del actual
datos de entrada
Uso Permite determinar junto con otros atributos si existe un sistema
anterior desarrollado en objetos que se encuentre relacionado
con el desarrollo del proyecto actual.
Formato de los Texto. Actualiza el atributo Sistema OO.
sesin VIII
Tabla 6-157 Descripcin del atributo Reso aplicacin OO

Nombre Reso aplicacin existente
Descripcin Describe si en los requerimientos se definen explcitamente
estrategias para el reso del software existente.
Tipo Valor Texto
Rango de valores Estrategias explcitas, No estrategias explcitas
Uso Permite determinar junto con otros atributos la aplicabilidad del
modelo de Objetos y la aplicabilidad del prototipo.
Formato de los Texto. Actualiza el atributo Aplicabilidad OO y Aplicabilidad
resultados de salida Prototipo.
sesin VIII
Tabla 6-158 Descripcin del atributo Reso aplicacin existente
Nombre Reso aplicacin futura
Descripcin Describe si el grado de necesidad existente de reutilizar
componentes del desarrollo de la aplicacin actual en proyectos
subsiguientes.
Tipo Valor Texto
Rango de valores Muy necesario, Medianamente necesario, Poco necesario
Uso Permite determinar junto con otros atributos la si existe un
sistema desarrollado bajo el paradigma de Objetos que afecte o
condicione desarrollos subsiguientes.
Formato de los Texto. Actualiza el atributo Sistema OO.
sesin VIII
Tabla 6-159 Descripcin del atributo Reso aplicacin futura

Nombre Procedimientos Cambios
Descripcin Describe si en los requerimientos se requiere de acuerdos
confirmados par gestionar cambios durante el desarrollo de la
aplicacin. Si se requiere de un procedimiento de control de
cambios en la gestin de configuracin.
Tipo Valor Texto
Rango de valores Acuerdos confirmados, No acuerdos confirmados
modelo en espiral .
Formato de los Texto. Actualiza el atributo Aplicabilidad Espiral.
sesin VIII
Tabla 6-160 Descripcin del atributo Procedimientos Cambios
Nombre Procedimientos Desarrollo-Mantenimiento
Descripcin Describe la factibilidad y necesidad de usar los mismos
procedimientos para el desarrollo y mantenimiento de la
Tipo Valor Texto
Rango de valores Es factible usar los mismos, Es factible usar diferentes, Es
necesario usar los mismos, Es necesario usar diferentes
datos de entrada
usar los mismos procedimientos para el desarrollo y
mantenimiento de la aplicacin a desarrollar.
Formato de los Texto. Actualiza el atributo Procedimientos D-M.
sesin VIII
Tabla 6-161 Descripcin del atributo Procedimientos Desarrollo-Mantenimiento

Nombre Conveniencia Metodologa
Descripcin Describe de acuerdo con el grado de factibilidad y necesidad que
tipo de metodologa es conveniente considerar en la gestin del
proyecto de la aplicacin a desarrollar.
Tipo Valor Texto
Fuente Obtenido a partir de Factibilidad Metodologa y Necesidad
Metodologa
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Factibilidad
mtodo para obtener Metodologa y Necesidad Metodologa se estima la conveniencia de la
esta informacin metodologa a aplicar
datos de entrada
Uso Permite determinar junto con otros atributos la aplicabilidad de la
Orientacin a Objetos, de la Espiral y/o del modelo en Cascada para
el rea Gestin de Proyectos.
Formato de los Texto. Participa en la actualizacin de los atributos, Aplicabilidad
resultados de salida OO, Aplicabilidad Espiral y CV Propuesto Gestin.
sesin VIII
Tabla 6-162 Descripcin del atributo Conveniencia Metodologa
Nombre Factibilidad Prototipo
Descripcin Describe de acuerdo con disponibilidad o posibilidad de adquirir
software para prototipar el grado de factibilidad de usar prototipos
para el desarrollo de la aplicacin
Tipo Valor Texto
Rango de valores Factible, No factible
Fuente Obtenido a partir de Software para Prototipar
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Software
mtodo para obtener para Prototipar se estima la factibilidad de usar prototipos
esta informacin
datos de entrada
del modelo en Cascada o del modelo en Espiral para el rea Gestin
de Proyectos.
resultados de salida Gestin.
sesin VIII
Tabla 6-163 Descripcin del atributo Factibilidad Prototipo

Nombre Sistema OO
Descripcin Describe si existe algn sistema anterior o esta prevista uno
posterior orientado a objetos
Tipo Valor Texto
Rango de valores Existe, No existe
Fuente Obtenido a partir de Reso Aplicacin OO y Reso Aplicacin Futura.
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Reso
mtodo para obtener Aplicacin OO y Reso Aplicacin Futura si existe o esta previsto un
esta informacin sistema orientado a objetos
datos de entrada
Modelo de Objetos para el rea Gestin de Proyectos.
sesin VIII
Tabla 6-164 Descripcin del atributo Sistema OO
Nombre Entrega Intermedia
Descripcin Describe el de acuerdo con el tipo de entregas que espera el usuario
si existe o no la necesidad de entregas intermedias de la aplicacin a
desarrollar.
Tipo Valor Texto
Fuente Obtenido a partir de Entregas
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Entregas se
mtodo para obtener estima la necesidad de entregas intermedias
esta informacin
datos de entrada
Prototipo, de la Orientacin a Objetos, y/o del modelo en Cascada
para el rea Gestin de Proyectos.
Formato de los Texto. Participa en la actualizacin de los atributos, Aplicabilidad
resultados de salida OO, Aplicabilidad Prototipo y CV Propuesto Gestin.
sesin VIII
Tabla 6-165 Descripcin del atributo Entrega Intermedia

Nombre Aplicabilidad Espiral
Descripcin Describe la posibilidad de aplicar la modelizacin en Espiral en la
Tipo Valor Texto
Rango de valores Aplicable, No aplicable
Fuente Obtenido a partir de Terminacin Proyectos, Factor Riesgo, Objetivo
Calidad, Anlisis Riesgo, Responsabilidad, procedimientos Cambios,
formalidad, Habilidad Riesgo, Procedimientos D-M, Riesgos
Alternativa, Conveniencia Metodologa e Identificacin Alternativas
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Terminacin
mtodo para obtener Proyectos, Factor Riesgo, Objetivo Calidad, Anlisis Riesgo,
esta informacin Responsabilidad, procedimientos Cambios, formalidad, Habilidad
Riesgo, Procedimientos D-M, Riesgos Alternativa, Conveniencia
Metodologa e Identificacin Alternativas se estima la aplicabilidad
de la modelizacin en Espiral
datos de entrada
modelo en Espiral para el rea Gestin de Proyectos.
sesin VIII
Tabla 6-166 Descripcin del atributo Aplicabilidad Espiral
Nombre Aplicabilidad Prototipo
Descripcin Describe la posibilidad de aplicar la modelizacin de prototipos en la
Tipo Valor Texto
Fuente Obtenido a partir de Entrega Intermedia, Experiencia previa,
Participacin, Experiencia Tcnicas IS, Reso Aplicacin existente,
Introduccin gradual
Detalles acerca del De acuerdo con los valores ingresados por el usuario Entrega
mtodo para obtener Intermedia, Experiencia previa, Participacin, Experiencia Tcnicas
esta informacin IS, Reso Aplicacin existente, Introduccin gradual se estima la
aplicabilidad de prototipos
datos de entrada
modelo en Espiral para el rea Gestin de Proyectos.
sesin VIII
Tabla 6-167 Descripcin del atributo Aplicabilidad Prototipo

Nombre Aplicabilidad OO
Descripcin Describe la posibilidad de aplicar la modelizacin de objetos en la
Tipo Valor Texto
Fuente Obtenido a partir de Conveniencia Metodologa, entrega Intermedia,
Formalidad, Reso Aplicacin existente
Detalles acerca del De acuerdo con los valores ingresados por el usuario en de
mtodo para obtener Conveniencia Metodologa, entrega Intermedia, Formalidad, Reso
esta informacin Aplicacin existente se estima la aplicabilidad de objetos
datos de entrada
modelo en Objetos para el rea Gestin de Proyectos.
sesin VIII
Tabla 6-168 Descripcin del atributo Aplicabilidad OO
Nombre Procedimientos D-M
Descripcin Describe de acuerdo con el grado de factibilidad y necesidad si es
conveniente considerar los mismos procedimientos para el desarrollo
y para el mantenimiento.
Tipo Valor Texto
Fuente Obtenido a partir de Procedimientos Desarrollo-Mantenimiento
Detalles acerca del De acuerdo con los valores ingresados por el usuario en
mtodo para obtener Procedimientos Desarrollo-Mantenimiento se estima la conveniencia
esta informacin o no de los mismos procedimientos.
datos de entrada
Espiral.
Formato de los Texto. Participa en la actualizacin del atributo Aplicabilidad
resultados de salida Espiral.
sesin VIII
Tabla 6-169 Descripcin del atributo Procedimientos D-M

Nombre Participacin
Concepto Usuario
Descripcin Describe el grado de participacin del cliente en el durante el
proceso de desarrollo de la aplicacin.
Tipo Valor Texto
Rango de valores Fuerte, Regular, Poca
Uso Permite determinar la aplicabilidad del modelo de prototipo.
Formato de los Texto. Actualiza el atributo Aplicabilidad Prototipo.
sesin VIII
Tabla 6-170 Descripcin del atributo Participacin
Nombre Introduccin gradual
Concepto Usuario
Descripcin Describe si es necesario facilitar la introduccin gradual del
sistema a los usuarios.
Tipo Valor Texto
Rango de valores Necesaria, No necesaria
sesin VIII
Tabla 6-171 Descripcin del atributo Introduccin gradual

Nombre Experiencia tcnicas IS
Concepto Equipo de Proyecto
Descripcin Describe si el equipo que participar en el desarrollo del proyecto
tiene experiencia con las tcnicas de ingeniera del software a
usar.
Tipo Valor Texto
Rango de valores Hay, No hay
sesin VIII
Tabla 6-172 Descripcin del atributo Experiencia tcnicas IS
Nombre Experiencia previa
Concepto Equipo de Proyecto
Descripcin Describe si el equipo que participar en el desarrollo del proyecto
tiene experiencia previa en el tipo de sistema a desarrollar.
Tipo Valor Texto
Rango de valores Hay, No hay
sesin VIII
Tabla 6-173 Descripcin del atributo Experiencia previa

Nombre Viabilidad software
Concepto Riesgos del Proyecto
Descripcin Describe si existen dudas acerca de la viabilidad de la aplicacin a
desarrollar.
Tipo Valor Texto
Rango de valores Hay certeza, Hay dudas
Uso Permite determinar la existencia de factor de riesgo.
Formato de los Texto. Actualiza el atributo Factor Riesgo.
sesin VIII
Tabla 6-174 Descripcin del atributo Viabilidad software
Nombre Nivel de riesgo
Descripcin Describe si el grado de riesgo que se estima existe para el
desarrollo del proyecto.
Tipo Valor Texto
Rango de valores Alto riesgo, Mediano riesgo, Bajo riesgo, No hay riesgo
Uso Permite determinar cuan aceptable es el riesgo estimado para
cada tipo de CV considerado cascada, objetos, espiral.
Para el modelo en espiral el riesgo aceptable es de nivel mediano
o alto. Para el modelo en objetos el riesgo aceptable es mediano,
bajo o sin riesgo. Para el modelo en cascada el riesgo aceptable
es bajo o sin riesgo.
Formato de los Texto. Actualiza los atributos Riesgo Cascada, Riesgo Objetos y
resultados de salida Riesgo Espiral.
sesin VIII
Tabla 6-175 Descripcin del atributo Nivel de riesgo

Nombre Anlisis riesgo
Descripcin Describe si es necesario definir explcitamente estrategias para
realizar anlisis de riesgo.
Tipo Valor Texto
Rango de valores Estrategias explcitas, No estrategias explcitas
Uso Permite determinar la aplicabilidad del modelo en espiral.
sesin VIII
Tabla 6-176 Descripcin del atributo Anlisis riesgo
Nombre Tcnicas AR
Descripcin Describe si se cuenta con los conocimientos para aplicar mtodos
y tcnicas par evaluar el riesgo.
Tipo Valor Texto
Rango de valores Se dispone, No se dispone
Uso Permite determinar junto con otros atributos (Factor Riesgo y
Habilidad Riesgo) si el factor de riesgo es evaluable.
Formato de los Texto. Actualiza junto con otros atributos el atributo Riesgo.
sesin VIII
Tabla 6-177 Descripcin del atributo Tcnicas AR

Nombre Identificacin Alternativas
Descripcin Describe si es posible identificar distintas alternativas para
resolver los riesgos y si es posible volver a etapas anteriores en el
desarrollo del sistema cuando se identifican las mejores
alternativas.
Tipo Valor Texto
Rango de valores Se identifican, No se identifican, Etapas anteriores
datos de entrada
Uso Permite determinar si se cuenta con habilidad para la evaluacin
del riesgo la aplicabilidad del modelo de prototipo.
Formato de los Texto. Actualiza el atributo Habilidad Riesgo y Aplicabilidad
sesin VIII
Tabla 6-178 Descripcin del atributo Identificacin Alternativas
Nombre Riesgos Alternativa
Descripcin Describe si es posible identificar los riesgos asociados con cada
una de las alternativas para el desarrollo del sistema y si es
necesario volver a etapas anteriores en el desarrollo del sistema
para la resolucin de algn tpico nuevo de riesgo.
Tipo Valor Texto
Rango de valores Se identifican, No se identifican, Etapas anteriores
datos de entrada
Uso Permite determinar si se cuenta con habilidad para la evaluacin
del riesgo la aplicabilidad del modelo de prototipo.
Formato de los Texto. Actualiza el atributo Habilidad Riesgo y Aplicabilidad
sesin VIII
Tabla 6-179 Descripcin del atributo Riesgos Alternativa

Nombre Categoras riesgo
Descripcin Describe si que tipo de riesgos se identifican en el desarrollo del
sistema.
Tipo Valor Texto
Rango de valores Tcnicos, Otros riesgos
datos de entrada
Uso Permite determinar si se existe factor de riesgo.
Formato de los Texto. Actualiza el atributo Factor Riesgo.
sesin VIII
Tabla 6-180 Descripcin del atributo Categoras riesgo
Nombre Objetivo calidad
Descripcin Describe si es necesario incorporar mecanismos explcitos para
incorporar objetivos de calidad en el desarrollo del producto.
Tipo Valor Texto
Rango de valores Mecanismos explcitos, No mecanismos explcitos
sesin VIII
Tabla 6-181 Descripcin del atributo Objetivo calidad

Nombre Terminacin Proyectos
Descripcin Describe si se estima la terminacin prematura de proyectos no
viables.
Tipo Valor Texto
Rango de valores Prematura, En trmino
sesin VIII
Tabla 6-182 Descripcin del atributo Terminacin Proyectos
Nombre Riesgo Cascada
Descripcin Describe el nivel de riesgo aceptable para un modelo de ciclo de
vida en cascada.
Tipo Valor Texto
Rango de valores Aceptable, No aceptable
Fuente Obtenido a partir de Nivel de Riesgo
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Nivel de
mtodo para obtener Riesgo se estima si es no aceptable para aplicar modelo en cascada
esta informacin
datos de entrada
ciclo de vida en Cascada en la Gestin de Proyectos.
Formato de los Texto. Actualiza el atributo CV Propuesto Gestin
sesin VIII
Tabla 6-183 Descripcin del atributo Riesgo Cascada

Nombre Riesgo Objetos
vida en objetos.
Tipo Valor Texto
mtodo para obtener Riesgo se estima si es no aceptable para aplicar modelo en objetos
esta informacin
datos de entrada
ciclo de vida en Objetos en la Gestin de Proyectos.
sesin VIII
Tabla 6-184 Descripcin del atributo Riesgo Objetos
Nombre Habilidad Riesgo
Descripcin Describe si existe habilidad para evaluar el nivel de riesgo para un
modelo de ciclo de vida en espiral.
Tipo Valor Texto
Fuente Obtenido a partir de Identificacin alternativas, Riesgos alternativa
Detalles acerca del De acuerdo con los valores ingresados por el usuario en
mtodo para obtener Identificacin alternativas, Riesgos alternativa se estima si existe o
esta informacin no habilidad para evaluar el nivel de riesgo
datos de entrada
modelado en espiral y la evaluabilidad del riesgo.
Formato de los Texto. Actualiza los atributos Aplicabilidad Espiral y Riesgo
sesin VIII
Tabla 6-185 Descripcin del atributo Habilidad Riesgo

Nombre Factor Riesgo
Descripcin Describe si existen factores de riesgo.
Tipo Valor Texto
Fuente Obtenido a partir de Viabilidad software, Riesgo Espiral, Categoras
Riesgo.
Detalles acerca del De acuerdo con los valores ingresados por el usuario Viabilidad
mtodo para obtener software, Riesgo Espiral, Categoras Riesgo se estima si existe o no
esta informacin Factor de riesgo para aplicar modelo en espiral
datos de entrada
modelo espiral y la Evaluabilidad del Riesgo.
Formato de los Texto. Junto con otros atributos actualiza los atributos
resultados de salida Aplicabilidad Espiral y Riesgo
sesin VIII
Tabla 6-186 Descripcin del atributo Factor Riesgo
Nombre Riesgo Espiral
vida en espiral.
Tipo Valor Texto
mtodo para obtener Riesgo se estima si es no aceptable para aplicar modelo en espiral
esta informacin
datos de entrada
Uso Permite determinar junto con otros atributos si existe Factor de
riesgo.
Formato de los Texto. Actualiza junto con otros atributos, el atributo Factor Riesgo
sesin VIII
Tabla 6-187 Descripcin del atributo Riesgo Espiral

Nombre Riesgo
Descripcin Define si el riesgo es evaluable para un modelo de ciclo de vida en
espiral.
Tipo Valor Texto
Rango de valores Evaluable, No evaluable
Fuente Obtenido a partir de Factor Riesgo, Tcnicas AR, Habilidad Riesgo
Detalles acerca del De acuerdo con los valores ingresados por el usuario en Factor
mtodo para obtener Riesgo, Tcnicas AR, Habilidad Riesgo se estima si es no evaluable
esta informacin para aplicar modelo en espiral
datos de entrada
ciclo de vida en Espiral.
sesin VIII
Tabla 6-188 Descripcin del atributo Riesgo
Nombre CV Propuesto Requisitos
Concepto rea Requisitos
Descripcin Define el modelo ciclo de vida mas adecuado para el rea
Requisitos.
Tipo Valor Texto
Fuente Obtenido a partir de Definicin Requisitos, Definicin Limites,
Grado de Cumplimiento, Grado de Certidumbre
Detalles acerca del De acuerdo con los de Definicin Requisitos, Definicin Limites,
mtodo para obtener Grado de Cumplimiento, Grado de Certidumbre se estima el ciclo de
esta informacin vida mas adecuado para el rea Requisitos
datos de entrada
Uso Permite determinar junto con otros atributos el ciclo de vida ms
adecuado para las caractersticas del proyecto analizado.
Formato de los Texto. Actualiza el atributo CV Propuesto del Proyecto. Se edita
resultados de salida resultado en pantalla.
sesin VIII
Tabla 6-189 Descripcin del atributo CV Propuesto Requisitos

Nombre CV Propuesto Aplicacin
Concepto rea Aplicacin
Descripcin Define el modelo ciclo de vida mas adecuado para el rea Aplicacin
Tipo Valor Texto
Fuente Obtenido a partir de Componentes predominantes, Comportamiento
predominante, Complejidad Subsistemas, Retroalimentacin Fases
Desarrollo, Progresin Fases Desarrollo, Opcionalidad, integracin
HW-SW, Modelado objetos, Modelado Prototipo.
Detalles acerca del De acuerdo con de Componentes predominantes, Comportamiento
mtodo para obtener predominante, Complejidad Subsistemas, Retroalimentacin Fases
esta informacin Desarrollo, Progresin Fases Desarrollo, Opcionalidad, integracin
HW-SW, Modelado objetos, Modelado Prototipo se estima el ciclo de
vida mas adecuado para el rea Aplicacin
datos de entrada
sesin VIII
Tabla 6-190 Descripcin del atributo CV Propuesto Aplicacin
Nombre CV Propuesto Gestin
Concepto rea Gestin Proyecto
Descripcin Define el modelo ciclo de vida mas adecuado para el rea Gestin
Proyecto
Tipo Valor Texto
Fuente Obtenido a partir de Riesgo Cascada, Responsabilidad, Control
Gestin, Formalidad, Factibilidad Prototipo, Conveniencia
metodologa, Entregas, Riesgo Objetos, Sistema OO, Aplicabilidad
OO, Factibilidad Prototipo, Aplicabilidad Prototipo, aplicabilidad
Espiral, Riesgo
Detalles acerca del De acuerdo con los de Riesgo Cascada, Responsabilidad, Control
mtodo para obtener Gestin, Formalidad, Factibilidad Prototipo, Conveniencia
esta informacin metodologa, Entregas, Riesgo Objetos, Sistema OO, Aplicabilidad
OO, Factibilidad Prototipo, Aplicabilidad Prototipo, aplicabilidad
Espiral, Riesgo se estima el ciclo de vida mas adecuado para el rea
Gestin Proyecto
datos de entrada
sesin VIII
Tabla 6-191 Descripcin del atributo CV Propuesto Gestin

Nombre CV Propuesto del Proyecto
Concepto CV Diagnstico
Descripcin Define el modelo ciclo de vida mas adecuado para el Proyecto
Tipo Valor Texto
Fuente Obtenido a partir de CV Propuesto Requisitos, CV Propuesto
Aplicacin, CV Propuesto Gestin
Detalles acerca del De acuerdo con los de CV Propuesto Requisitos, CV Propuesto
mtodo para obtener Aplicacin, CV Propuesto Gestin se estima el ciclo de vida mas
esta informacin adecuado para el Proyecto
datos de entrada
Formato de los Texto. Actualiza el atributo CV Propuesto Proyecto y CV Propuesto
resultados de salida por SE. Se edita resultado en pantalla.
sesin VIII
Tabla 6-192 Descripcin del atributo CV Propuesto del Proyecto
6.2.5.2 COMPROBACION DE LOS CONOCIMIENTOS FACTICOS
Se han realizado junto con el experto revisiones exhaustivas de la

definicin de los atributos. Esta verificacin ha permitido completar cundo era
necesario la tabla 6-3 de conceptosatributos-valores y revisar las seudorreglas
definidas anteriormente. La representacin de los conocimientos fcticos se
considera satisfactoria.
6.3 SINTESIS DE CONOCIMIENTOS
En los pasos precedentes se ha desarrollado el proceso de anlisis de los

conocimientos identificando, modelando y documentando los conocimientos
estratgicos, tcticos y fcticos. A partir de ahora se presenta la sntesis de esos
conocimientos en el Modelo Dinmico, tambin conocido como Modelo de
Procesos y en el Modelo Esttico. Por ltimo, y como paso final de la fase de
Conceptualizacin, ambos Modelos se integran en el Mapa de Conocimientos.
6.3.1 MODELO DE PROCESOS MODELO DINAMICO
Para la construccin del modelo dinmico hay que tomar como punto de
partida la identificacin de los conocimientos estratgicos, definir una jerarqua
entre las tareas y comprobar que no haya errores u olvidos. El experto participa

en este paso corroborando las metas, submetas y decisiones y los conceptos y

atributos que se usan en cada estadio.
Las figuras 6-4 a 6-7 muestran la Jerarqua de Tareas (metas, submetas y

procesos) para Seleccionar el Ciclo de Vida del proyecto.
Las figuras 6-8 a 6-10 muestran los conceptos y las relaciones

intervinientes en cada uno de los procedimientos (submetas).
Las Tablas 6-193 a 6-212 muestran la descripcin de los procesos del

Modelo Dinmico.
6.3.2 MODELO ESTTICO
El modelo esttico est formado por los siguientes componentes que han
sido documentados y actualizados durante el proceso de anlisis de los
conocimientos fcticos:
Glosario de Trminos: Tabla 6-1, pginas 152 a 155.

Diccionario de conceptos: Tabla 6-2, pginas 156 a 158.
Tabla de Concepto Atributo Valor: Tabla 6-3, pginas 159 a 165.
Modelo Relacional de los Conceptos: Figura 6-2, pgina 166.

Seleccionar el CV del Proyecto

Def. de la Meta: Deducir el ciclo de vida a partir de los
valores obtenidos para cada una de las reas analizadas.
Entradas Necesarias:
CV Propuesto Requisitos
CV Propuesto Aplicacin
CV Propuesto Gestin
Salida Producida: El ciclo de vida ms adecuado a partir
del CV Propuesto para cada una de las reas analizadas.
Seleccionar el CV del Area Requerimientos Seleccionar el CV del Area Tipo de Aplicacin Seleccionar el CV del Area Gestin de
Proyecto
Def. de la Meta: Deducir el ciclo de vida a partir de Def. de la Meta: Deducir el ciclo de vida a partir de Def. de la Meta: Deducir el ciclo de vida a partir de
los valores obtenidos para los atributos del rea los valores obtenidos para los atributos del rea Tipo los valores obtenidos para los atributos del rea
Requerimientos. de Aplicacin. Gestin de Proyecto..
Entradas Necesarias: Entradas Necesarias: Entradas Necesarias:
Tipo de definicin Niveles de Composicin Formalidad Software para prototipar
Grado de Certidumbre Complejidad Subsistemas Entregas Factibilidad Metodologa
Grado de Cumplimiento Componentes Predominantes Responsabilidad Necesidad Metodologa
Comportamiento Predominante Control Gestin Reso Aplicacin OO
Orientacin Reso aplicacin existente Participacin
Progresin Fases Desarrollo Reso aplicacin futura Introduccin Gradual
Relacin Fases Desarrollo Procedimientos Cambios Experiencia tcnicas IS
Retroalimentacin Fases Desarrollo Experiencia Previa Viabilidad software
Integracin HW-SW Nivel de riesgo Anlisis de riesgo
Factores Diseo Tcnicas AR Identificacin Alternativas
Existencia Aplicaciones Riesgos Alternativa Categoras Riesgo
Posibilidad Diseo Objetivo Calidad Terminacin Proyectos
Posibilidad Implementacin Procedimientos Desarrollo-Mantenimiento
Salida Producida: El ciclo de vida ms adecuado Salida Producida: El ciclo de vida ms adecuado Salida Producida: El ciclo de vida ms adecuado
para el rea de Requerimientos a partir de las para el rea Tipo de Aplicacin a partir de las para el rea Gestin de Proyecto. CV Propuesto
caractersticas del proyecto. CV Propuesto Requisitos. caractersticas del proyecto. CV Propuesto Aplicacin. Gestin..
Figura 6-4 Jerarqua de Tareas de Seleccionar el Ciclo de Vida del Proyecto

Seleccionar el CV del
Area Requerimientos
ESTIMAR NIVEL
ANALIZAR ESTIMAR
EXIGENCIA EN EL
DEFINICIN LIMITES
PRODUCTO FINAL
REQUERIMIENTOS
Figura 6-5 Jerarqua de Tareas de Seleccionar del Ciclo de Vida para el Area Especificacin Requerimientos

Seleccionar el CV del
Area Tipo de Aplicacin
ESTIMAR
ESTIMAR ANALIZAR ESTIMAR INTEGRACIN
FACTORES FACTORES NIVEL HARDWARE-
PREDOMINANTES PROTOTIPACIN OPCIONES SOFTWARE
Figura 6-6 Jerarqua de Tareas de Seleccionar el Ciclo de Vida para el Area Tipo de Aplicacin

Seleccionar el CV del Area Gestin del Proyecto
Analizar Coordinacin Analizar Riesgos del Proyecto

ESTIMAR ESTIMAR
Def. de la Meta: Analizar los factores relacionados con RELACION FACTORES Def. de la Meta: Determinar el nivel de riesgo y su
administracin, mantenimiento y reusabilidad que inciden en CON EQUIPO DE evaluabilidad.
la coordinacin del proyecto. EL USUARIO PROYECTO
Entradas Necesarias: Entradas Necesarias:
Formalidad Entregas Control Gestin Viabilidad Software Categoras riesgo
Responsabilidad Factibilidad Metodologa Nivel de riesgo Objetivo Calidad
Necesidad metodologa Reso aplicacin OO Anlisis Riesgo Terminacin proyectos
Reso aplicacin existente Reso aplicacin futura Tcnicas AR
Procedimientos cambios Software para prototipar Identificacin Alternativas
Procedimientos Desarrollo Mantenimiento Riesgos Alternativa
Salida Producida: Valorizacin de atributos con destino a Salida Producida: Valorizacin de atributos con destino
la Base de Conocimientos. a la Base de Conocimientos.
ESTIMAR
ESTIMAR ESTIMAR ESTIMAR ESTIMAR ESTIMAR HABILIDAD
FACTORES FACTORES RECURSOS FACTORES RIESGO PARA
REUSO MANTENI- SOFTWARE ADMINIS- EXISTENTE EVALUAR
MIENTO TRACIN RIESGO
Figura 6-7 Jerarqua de Tareas de Seleccionar del Ciclo de Vida para el Area Gestin del Proyecto

N N 1 AREA
REQUISITOS
REQUISITOS
1 SE PROPONE
N N 1 AREA
APLICACION
APLICACION
SE SUGIERE
1
1 1
1 1
CV
PROYECTO
DIAGNOSTICO
1 1 1 1 1
N
N
USUARIO SE SUGIERE
SE ESTIMAN
N
EQUIPO DE
1
N 1
AREA 1
GESTION
SE ESTIMAN
PROYECTO
CION
N 1 1
N RIESGOS DEL
N
PROYECTO
FIGURA 6-8 Conceptos Intervinientes en el Proceso

Seleccionar el CV del Proyecto
Analizar Definicin Requerimientos

Propsito:
Establecer el nivel de claridad con el que se encuentran definidos los requisitos y el grado de certidumbre
en la definicin de los mismos al inicio del proyecto.
Informacin necesaria:
Los valores asignados por el usuario del sistema a los atributos Tipo de Definicin y Grado de
certidumbre
Acciones:
1. Solicitar al usuario los valores de Tipo de definicin
2. Solicitar al usuario los valores Grado de certidumbre
3. Deducir Definicin requisitos
3.1 Tipo de Definicin formales y exhaustivos y uniformes = Definicin requisitos es definicin clara.
Tabla 6-193 Descripcin del Proceso Analizar Definicin Requerimientos

Estimar Lmites
Propsito:
Establecer el nivel de claridad con el que se encuentran definidos los lmites al inicio del proyecto.
Los valores asignados por el usuario del sistema a los atributos Tipo de Definicin
Acciones:
1. Solicitar al usuario los valores de Tipo de definicin
2. Deducir Definicin Lmites
3.1 Tipo de Definicin formales y exhaustivos y uniformes = Definicin lmites es definicin clara.
Tabla 6-194 Descripcin del Proceso Estimar Lmites
N N 1 AREA
REQUISITOS
REQUISITOS
1 SE PROPONE
N N 1 AREA
APLICACION
APLICACION
SE SUGIERE
1
1 1 1 1
CV
PROYECTO
DIAGNOSTICO
1 1 1 1 1
N
N
USUARIO SE SUGIERE
SE ESTIMAN
N
EQUIPO DE
1
N 1
AREA 1
GESTION
SE ESTIMAN
PROYECTO
CION
N 1 1
N RIESGOS DEL
N
PROYECTO

Seleccionar el CV del rea Especificacin Requerimientos

Estimar Nivel de Exigencia en el Producto Final

Propsito:
Establecer el grado de cumplimiento de los requerimientos en el producto final que exige el usuario.
Los valores asignados por el usuario del sistema a los atributos Grado de cumplimiento
Acciones:
1. Solicitar al usuario los valores Grado de certidumbre
Tabla 6-195 Descripcin del Proceso Estimar Nivel de Exigencia en el Producto Final
Seleccionar el CV del Area Requerimientos

Propsito:
Deducir el ciclo de vida para el rea Especificacin de Requerimientos a partir de los valores obtenidos
para los atributos del rea requerimientos.
Los valores asignados por el usuario del sistema a los atributos Grado de Cumplimiento y Grado de
Certidumbre.
Los valores deducidos para los atributos Definicin Requisitos y Definicin Lmites.
Acciones:
1. Deducir si el CV del rea es Objetos o Espiral
1.1 Definicin Requisitos es definicin incierta + Definicin Limites es definicin incierta + Grado de
certidumbre parcialmente definidos = CV Propuesto Requisitos es Objetos o Espiral
1.2 Grado de Cumplimiento es usuario muy exigente = CV Propuesto Requisitos es Objetos o Espiral
2. Deducir si el CV del rea es Cascada
2.1 Definicin Requisitos es definicin clara + Definicin Limites es definicin clara + Grado de
certidumbre mayoritariamente definidos = CV Propuesto Requisitos es Cascada
Tabla 6-196 Descripcin del Proceso Seleccionar el CV del Area Requerimientos
Estimar Factores Predominantes

Propsito:
Determinar las tcnicas de modelado que mejor se adecuan a los factores predominantes de la aplicacin
a desarrollar.
Los valores asignados por el usuario del sistema a los atributos Componentes Predominantes,
Comportamiento predominante y Orientacin
Acciones:
1. Solicitar al usuario los valores de Componentes Predominantes + Comportamiento Predominante +
Orientacin
2. Deducir modelo
2.1 Componente predominante Algortmico + Comportamiento Predominante batch + Resultado del
procesamiento de Otros valores ingresados = CV Propuesto Aplicacin Cascada
2.2 Componente predominante Matemtico o Grafico = Modelado OO es conveniente
2.3 Comportamiento predominante Dinmico o Interactivo o Tiempo Real = Modelado OO es
conveniente
2.4 Orientacin Software de Base = Modelado OO es conveniente.
2.5 Orientacin Sistema Basado en Conocimiento = Modelado Prototipo es conveniente
Tabla 6-197 Descripcin del Proceso Estimar Factores Predominantes

N N 1 AREA
REQUISITOS
REQUISITOS
1 SE PROPONE
N N 1 AREA
APLICACION
APLICACION
SE SUGIERE
1
1 1 1 1
CV
PROYECTO
DIAGNOSTICO
1 1 1 1 1
N
N
USUARIO SE SUGIERE
SE ESTIMAN
N
EQUIPO DE
1
N 1
AREA 1
GESTION
SE ESTIMAN
PROYECTO
CION
N 1 1
N RIESGOS DEL
N
PROYECTO

Seleccionar el CV del rea Tipo de Aplicacin
Estimar Nivel de Opciones

Propsito:
Determinar si la aplicacin a desarrollar es multiopcional desde el punto de vista del diseo y la
implementacin.
Los valores asignados por el usuario del sistema a los atributos Posibilidad Diseo, Posibilidad
Implementacin.
Acciones:
1. Solicitar al usuario los valores de los atributos necesarios
2. Deducir grado de opcionalidad de la aplicacin
2.1 Posibilidad Diseo es Varias Opciones = Opcionalidad es Mltiple
2.2 Posibilidad Implementacin es Varias Opciones = Opcionalidad es Mltiple
2.3 Posibilidad Diseo es Pocas Opciones = Opcionalidad es Simple
2.4 Posibilidad Implementacin es Pocas Opciones = Opcionalidad es Simple
Tabla 6-198 Descripcin del Proceso Estimar Nivel de Opciones

Analizar Factores Prototipacin

Propsito:
Determinar si la tcnicas de prototipacin es conveniente para modelar la aplicacin a desarrollar.
Los valores asignados por el usuario del sistema a los atributos Niveles de Composicin, Progresin Fases
desarrollo, Relacin Fases desarrollo, Factores Diseo, Existencia aplicaciones y Tipo de Modificacin.
Acciones:
1. Solicitar al usuario los valores de los atributos necesarios.
2. Deducir si el modelo de prototipos es conveniente
2.1 Niveles de Composicin es pocos = Complejidad Subsistemas es baja
2.2 Niveles de Composicin es varios = Complejidad Subsistemas es alta = Modelado Prototipo es
conveniente
2.3 Relacin Fases Desarrollo es Poca Dependencia o Independencia = Retroalimentacin Fases
desarrollo es baja
2.4 Relacin Fases Desarrollo es Mucha Dependencia = Retroalimentacin Fases desarrollo es alta =
Modelado Prototipo es conveniente.
2.5 Progresin Fases Desarrollo es No uniforme y Secuencial = Modelado Prototipo es conveniente
2.6 Factores Diseo es Problemas Arquitectura o Problemas eficacia = Modelado Prototipo es
conveniente
2.7 Existencia Aplicaciones es innovador = Modelado Prototipo es conveniente
2.8 Tipo de Modificacin es Redefinicin o Extensin o Ampliacin = Variabilidad procesos alta =
Modelado Prototipo es conveniente
Tabla 6-199 Descripcin del Proceso Analizar Factores Prototipacin
Seleccionar el CV del Area Tipo de Aplicacin

Propsito:
Deducir el ciclo de vida para el rea Tipo de aplicacin a partir de los valores obtenidos y deducidos para
los atributos del rea aplicacin
Los valores asignados por el usuario del sistema a los atributos Componentes predominantes y
Comportamiento Predominante
Los valores deducidos para los atributos Complejidad Subsistemas, Retroalimentacin Fases Desarrollo,
Modelado Prototipo, Modelado Objetos, Opcionalidad
Acciones:
1. Deducir si el CV del rea es Espiral
1.1 Modelado Objetos es conveniente + Modelado Prototipo es conveniente + Opcionalidad es Mltiple
= CV Propuesto Aplicacin es Espiral
1.2 Modelado Objetos es conveniente + Modelado Prototipo es conveniente + Integracin HW-SW es
fuertemente = CV Propuesto Aplicacin es Espiral
2. Deducir si el CV del rea es Objetos
2.1 Modelado Objetos es conveniente + Modelado Prototipo es conveniente = CV Propuesto Aplicacin
es Objetos
3.1 Complejidad Subsistemas es baja + Componente Predominante algortmico + Progresin Fases
Desarrollo Uniforme y Secuencial = CV Propuesto Aplicacin es Cascada
3.2 Complejidad Subsistemas es baja + Comportamiento Predominante batch + Progresin Fases
Desarrollo Uniforme y Secuencial = CV Propuesto Aplicacin es Cascada
3.3 Retroalimentacin Fases desarrollo baja + Componente Predominante algortmico + Progresin
Fases Desarrollo Uniforme y Secuencial = CV Propuesto Aplicacin es Cascada
3.4 Retroalimentacin Fases desarrollo baja + Comportamiento Predominante batch + Progresin
Fases Desarrollo Uniforme y Secuencial = CV Propuesto Aplicacin es Cascada
Tabla 6-200 Descripcin del Proceso Seleccionar el CV del Area Tipo de Aplicacin

Estimar Integracin Hardware-Software

Propsito:
Obtener el nivel de integracin entre el hardware y el software que requiere la aplicacin a desarrollar.
Los valores asignados por el usuario del sistema al atributo Integracin HW-SW
Acciones:
Solicitar al usuario los valores de Integracin HW-SW
Tabla 6-201 Descripcin del Proceso Estimar Integracin Hardware-Software
Estimar Factores Reso

Propsito:
Determinar si existe una aplicacin previa desarrollada en objetos y determinar la aplicabilidad del modelo
de objetos.
Los valores asignados por el usuario del sistema a los atributos Reso Aplicacin OO, Reso aplicacin
existente, Reso aplicacin futura.
Acciones:
2. Deducir aplicacin previa desarrollada en objetos
2.1 Reso Aplicacin OO es Subsistema del existente o Ampliacin del existente o Modificacin del
existente O Componentes del actual = Sistema OO es existe
2.2 Reso Aplicacin futura es muy necesario = Sistema OO es existe
3. Deducir si el modelo de objetos es aplicable
3.1 Reso Aplicacin existente es estrategias explcitas = Aplicabilidad OO es aplicable
Tabla 6-202 Descripcin del Proceso Estimar Factores Reso
Estimar Factores Mantenimiento

Propsito:
Determinar la aplicabilidad del modelo en espiral.
Los valores asignados por el usuario del sistema a los atributos Procedimientos Cambios, Procedimientos
Desarrollo- Mantenimiento.
Acciones:
2. Deducir si el modelo en espiral es aplicable
2.1 Procedimientos Cambios es acuerdos confirmados = Aplicabilidad espiral es aplicable
2.2 Procedimientos Desarrollo-Mantenimiento es factible usar los mismos y es necesario usar los
mismos = Procedimientos D-M es conveniente = Aplicabilidad espiral es aplicable
Tabla 6-203 Descripcin del Proceso Estimar Factores Mantenimiento
Estimar Recursos Software

Propsito:
Determinar la factibilidad del modelo en prototipo.
Los valores asignados por el usuario del sistema al atributo Software para prototipar.
Acciones:
2. Deducir si el prototipo es factible
2.1 Software para prototipar es hay disponible o factible de adquirir = Factibilidad prototipo es factible
Tabla 6-204 Descripcin del Proceso Estimar Recursos Software

N N 1 AREA
REQUISITOS
REQUISITOS
1 SE PROPONE
N N 1 AREA
APLICACION
APLICACION
SE SUGIERE
1
1 1
1 1
CV
PROYECTO
DIAGNOSTICO
1 1 1 1 1
N
N
USUARIO SE SUGIERE
SE ESTIMAN
N
EQUIPO DE
1
N 1
AREA 1
GESTION
SE ESTIMAN
PROYECTO
N 1 1
CION
N RIESGOS DEL
N
PROYECTO

Seleccionar el CV del rea Gestin de Proyecto
Estimar Factores Administracin

Propsito:
Determinar la existencia de entregas intermedias y el nivel de reconocimientos conveniente de la
metodologa a usar.
Los valores asignados por el usuario del sistema a los atributos formalidad, Entregas, Factibilidad
Metodologa, Necesidad Metodologa.
Acciones:
2. Deducir si existen entregas intermedias
2.1 Entregas es versin temprana o versin gradual o versin parcial = Entrega intermedia existe
3. Deducir conveniencia de usar metodologa
3.1 Si Factibilidad metodologa es ampliamente probada y Necesidad Metodologa es ampliamente
probada = Conveniencia metodologa es ampliamente probada.
3.2 Si Factibilidad metodologa es medianamente probada y Necesidad Metodologa es medianamente
probada = Conveniencia metodologa es medianamente probada.
3.3 Si Factibilidad metodologa es poco probada y Necesidad Metodologa es poco probada =
Conveniencia metodologa es poco probada.
Tabla 6-205 Descripcin del Proceso Estimar Factores Administracin

Analizar Coordinacin
Propsito:
Analizar los factores que inciden en las decisiones de coordinacin en el desarrollo de un proyecto.
Los valores asignados por el usuario del sistema a los atributos Formalidad, Entregas, Control Gestin,
Responsabilidad, factibilidad Metodologa, Necesidad Metodologa, Reso aplicacin OO, Reso aplicacin
existente, Reso aplicacin futura, Procedimientos cambios, Software para prototipar, Procedimientos
Desarrollo-Mantenimiento..
Acciones:
2. Estimar Factores Reso
2.1. Deducir aplicacin previa desarrollada en objetos
2.2. Deducir si el modelo de objetos es aplicable
3. Estimar Factores mantenimiento
3.1 Deducir si el modelo en espiral es aplicable
4. Estimar Recursos software
4.1 Deducir si el prototipo es factible
5. Estimar factores Administracin.
5.1 Deducir si existen entregas intermedias
5.2 Deducir conveniencia de usar metodologa
Tabla 6-206 Descripcin del Proceso Analizar Coordinacin
Estimar Relacin con Usuario

Propsito:
Determinar el grado y tipo de relacin que se espera del usuario para deducir la necesidad de usar un
sistema de prototipacin en el desarrollo de la aplicacin.
Los valores asignados por el usuario del sistema a los atributos Participacin e Introduccin gradual.
Acciones:
2. Deducir si el modelo por prototipo es aplicable
2.1 Participacin es fuerte = Aplicabilidad Prototipo es aplicable
2.2 Introduccin gradual es necesaria = Aplicabilidad Prototipo es aplicable
Tabla 6-207 Descripcin del Proceso Estimar Relacin con Usuario
Estimar Factores Equipo de Proyecto

Propsito:
Determinar el grado y tipo de experiencia (en sistemas similares y en las tcnicas de ingeniera de software
a usar) con que cuenta el equipo afectado al desarrollo del sistema, para deducir la necesidad de usar un
sistema de prototipacin en el desarrollo de la aplicacin.
Los valores asignados por el usuario del sistema a los atributos Experiencia tcnicas IS, Experiencia previa.
Acciones:
2. Deducir si el modelo por prototipo es aplicable
2.1 Experiencia tcnicas IS es no hay = Aplicabilidad Prototipo es aplicable
2.2 Experiencia previa es no hay = Aplicabilidad Prototipo es aplicable
Tabla 6-208 Descripcin del Proceso Estimar Factores Equipo de Proyecto

Estimar Riesgo Existente

Propsito:
Determinar la existencia del factor de riesgo y el nivel de aceptabilidad del riesgo para cada tipo de CV.
Los valores asignados por el usuario del sistema a los atributos Viabilidad software, Nivel de riesgo,
Categoras riesgo, Objetivo calidad, Terminacin proyectos y valores existentes en la Base de
conocimientos para Habilidad Riesgo
Acciones:
2. Deducir existencia del factor de riesgo
2.1 Viabilidad software es hay dudas o Categoras riesgo es tcnicos = Factor riesgo existe
3. Deducir el modelo aceptable de acuerdo al nivel del factor de riesgo.
3.1 Nivel de riesgo es alto o mediano = Riesgo espiral es aceptable
3.2 Nivel de riesgo es mediano o bajo o no hay = Riesgo objetos es aceptable
3.3 Nivel de riesgo es bajo o no hay = Riesgo cascada es aceptable
4. Deducir aplicabilidad del modelo en espiral.
4.1 Objetivo calidad es mecanismos explcitos y Factor riesgo existe = Aplicabilidad espiral es aplicable.
4.2 Terminacin proyectos es prematura y Habilidad riesgo es existe = Aplicabilidad espiral es aplicable.
Tabla 6-209 Descripcin del Proceso Estimar Riesgo Existente
Estimar Habilidad para Evaluar Riesgo

Propsito:
Determinar si se cuenta con la habilidad para la evaluacin del riesgo y la aplicabilidad del modelo en
espiral..
Los valores asignados por el usuario del sistema a los atributos Anlisis riesgo, Tcnicas AR, Identificacin
alternativas, Riesgos Alternativa y valores existentes en la Base de conocimientos para Factor Riesgo
Acciones:
2. Deducir habilidad para evaluar riesgo
2.1 Identificacin Alternativas es se identifican y Riesgos alternativa es se identifican = Habilidad riesgo es
existe
3. Deducir aplicabilidad del modelo en espiral.
3.1 Habilidad riesgo es existe y Identificacin alternativas es etapas anteriores = Aplicabilidad espiral es
aplicable
3.2 Habilidad riesgo es existe y Riesgos alternativa es etapas anteriores = Aplicabilidad espiral es
aplicable
3.3 Factor riesgo es existe y Anlisis riesgo es estrategias explcitas = Aplicabilidad espiral es aplicable
4. Deducir si el riesgo es evaluable para el modelo en espiral.
4.1 Factor Riesgo es existe y Habilidad Riesgo es existe y Tcnicas AR es se dispone = Riesgo es
evaluable.
Tabla 6-210 Descripcin del Proceso Estimar Habilidad para Evaluar Riesgo

Analizar Riesgos del Proyecto

Propsito:
Analizar los factores que inciden en las decisiones de coordinacin en el desarrollo de un proyecto.
Los valores asignados por el usuario del sistema a los atributos Viabilidad software, Categoras riesgo, Nivel
de riesgo, Objetivo Calidad, Anlisis riesgo, Tcnicas AR, Identificacin Alternativas, Riesgos alternativa,
Terminacin proyectos. Valores existentes en la Base de conocimientos para Factor Riesgo, Riesgo
Cascada, Riesgo objetos, Habilidad Riesgo, Factor riesgo, Riesgo espiral, Riesgo.
Acciones:
2. Estimar Riesgo existente
2.1 Deducir existencia del factor de riesgo
2.2 Deducir el modelo aceptable de acuerdo al nivel del factor de riesgo.
2.3 Deducir aplicabilidad del modelo en espiral.
3. Estimar Habilidad para evaluar riesgo
3.1 Deducir habilidad para evaluar riesgo
3.2 Deducir aplicabilidad del modelo en espiral.
3.3 Deducir si el riesgo es evaluable para el modelo en espiral.
Tabla 6-211 Descripcin del Proceso Analizar Riesgos del Proyecto
Seleccionar el CV del Area Gestin del Proyecto

Propsito:
Deducir el ciclo de vida para el rea Gestin del Proyecto.
Los valores asignados por el usuario del sistema y deducidos para los atributos de los conceptos
Coordinacin, Usuario, Equipo de proyecto, Riesgos del proyecto.
Acciones:
1. Deducir si el CV del rea es Espiral
1.1 Aplicabilidad Prototipo es aplicable + Factibilidad Prototipo es factible + Riesgo es Evaluable +
Aplicabilidad espiral es aplicable = CV Propuesto Gestin es Espiral
2. Deducir si el CV del rea es Objetos
2.1 Riesgo Objetos aceptable + Sistema OO existe + Aplicabilidad OO aplicable = CV Propuesto
Gestin Objetos
3.4 Factibilidad Prototipo no factible + Riesgo Cascada aceptable = CV Propuesto Gestin es Cascada
3.5 Riesgo Cascada aceptable + Entregas no versin temprana + Conveniencia Metodologa
ampliamente probada = CV Propuesto Gestin es Cascada
3.6 Riesgo Cascada aceptable + Formalidad muy formal + Entregas no versin temprana = CV
Propuesto Gestin es Cascada
3.4 Conveniencia Metodologa ampliamente probada + Responsabilidad Terceros + Control gestin
muy ajustado = CV Propuesto Gestin es Cascada
Tabla 6-212 Descripcin del Proceso Seleccionar el CV del Area Gestin del Proyecto
6.3.3 MAPA DE CONOCIMIENTOS
El Mapa de Conocimientos es un mtodo para representar en dos

dimensiones las conexiones que efecta el cerebro cuando entiende hechos
acerca de algo. Por lo tanto, representa el proceso de inferir valores de los

atributos. Los enlaces entre los atributos y los valores inferidos forman una parte
importante de los conocimientos [Gmez, A. y otros 1997].
Las figuras comprendidas entre 6-12 y 6-19 describen los mapas de

conocimiento que se han construido para la representacin del problema. Tanto el
experto como el grupo de expertos han identificado tres reas que son las que se
han tenido en cuenta para la construccin del Mapa, lo que ha facilitado la
evaluacin de estos subproblemas a resolver.
rea Especificacin de Requerimientos: figura 6-12

rea Tipo de Aplicacin: figuras 6-13 y 6-14
rea Gestin de Proyecto: figuras 6-15, 6-16, 6-17, 6-18
El Proyecto en su visin global: 6-19. En el caso de esta figura se ha
identificado con lnea punteada tanto las cajas, como las flechas que
representan los atributos del concepto Proyecto, ya que si bien identifican a
cada uno de los proyectos que se estn analizando, el valor de los atributos
no incide en el razonamiento del Sistema Experto.
6.4 COMPROBACION DE LA Conceptualizacin
Si bien se han realizado comprobaciones sobre los distintos modelos

construidos en la fase de Conceptualizacin, se puso especial atencin en la
comprobacin del Mapa de Conocimientos para verificar la consistencia ente los
modelos. Los pasos seguidos en la comprobacin fueron:
Se verific que todos los atributos de la periferia eran ingresados por el

usuario o provenan de un archivo externo
Se verific que los atributos inferidos no fueran subjetivos y que
estuvieran contenidos en la reglas
Se verific que los valores desconocidos de los atributos fueran un valor
por omisin
Se comprob que los valores de los atributos sean usados. Los que no
son usados en esta versin del prototipo se los dej como parte del
modelo conceptual a considerar en prximas versiones del prototipo
Se complet y verific que todos los atributos (perifricos o inferidos) se
encuentren en la tabla de Concepto-Atributo-Valor

TIPO DE DEFINICION
Formalmente,Informalmente,
Exhaustivamente,
Incompleto, Uniformemente,
DEFINICION REQUISITOS DEFINICION LIMITES
Definicin clara Definicin clara

Definicin incierta Definicin incierta
CV PROPUESTO
REQUISITOS
Espiral
Objeto
Cascada
GRADO DE GRADO DE
CUMPLIMIENTO CERTIDUMBRE
Usuario muy exigente Mayoritariamente definidos

Usuario poco exigente Parcialmente definidos
FIGURA 6-12 Mapa de Conocimientos del Area Especificacin Requerimientos

COMPONENTES COMPORTAMIENTO
PREDOMINANTES PREDOMINANTE
Batch
Algortmicos
RELACION FASES
NIVELES COMPOSICION DESARROLLO
Pocos Subsistemas
Poca dependencia,
Independencia
CV PROPUESTO
APLICACION
COMPLEJIDAD
SUBSISTEMAS RETROALIMENTACION
Cascada
FASES DESARROLLO
Baja
Baja
PROGRESION FASES
DESARROLLO
Uniforme y Secuencial
FIGURA 6-13 Mapa de Conocimientos del Area Tipo Aplicacin - CV en Cascada

NIVELES COMPOSICION
COMPONENTES
Varios Subsistemas PREDOMINANTES POSIBILIDAD
POSIBILIDAD DISEO
IMPLEMENTACION
Matemticos, Grficos
Varias opciones Varias opciones
COMPLEJIDAD COMPORTAMIENTO
SUBSISTEMAS ORIENTACION PREDOMINANTE
Dinmico, Interactivo,
Alta Software de Base, SSBBCC Tiempo real
OPCIONALIDAD
Mltiple
RELACION FASES
DESARROLLO
Mucha dependencia MODELADO OBJETOS
Conveniente
CV PROPUESTO
RETROALIMENTACION APLICACION
FASES DESARROLLO
Alta Espiral
Objetos
MODELADO PROTOTIPO
VARIABILIDAD
PROCESOS Conveniente
Alta
INTEGRACION HW-SW
Fuertemente
TIPO MODIFICACION
Redefinicin, Extensin, PROGRESION FASES EXISTENCIA

DESARROLLO APLICACIONES FACTORES DISEO
Ampliacin
Problemas de Arquitectura,
NO Uniforme y Secuencial Innovador
Problemas de Eficacia
FIGURA 6-14 Mapa de Conocimientos del Area Tipo Aplicacin - CV en Objetos y Espiral

FACTIBILIDAD NECESIDAD
METODOLOGIA NIVEL DE RIESGO
METODOLOGIA
ENTREGAS
Ampliamente probada Bajo riesgo,
Ampliamente probada
NO Hay riesgo
Versin completa
CONVENIENCIA RIESGO CASCADA

METODOLOGIA
Aceptable
Ampliamente probada
CV PROPUESTO
GESTIN
FACTIBILIDAD
RESPONSABILIDAD
PROTOTIPO Cascada
NO Factible Organizacin propia
SOFTWARE PARA FORMALIDAD

PROTOTIPAR CONTROL GESTION
NO Disponoble, Muy formal

Muy ajustado
NO Adquirible
FIGURA 6-15 Mapa de Conocimientos del Area Gestin de Proyectos - CV en Cascada

FACTIBILIDAD NECESIDAD NIVEL DE RIESGO

METODOLOGIA METODOLOGIA
ENTREGAS Mediano riesgo, Bajo riesgo,
Medianamente probada Medianamente probada NO Hay riesgo
Versin temprana, Versin
gradual, Versin parcial
CONVENIENCIA
METODOLOGIA
RIESGO OBJETOS
ENTREGA INTERMEDIA Medianamente probada
Aceptable
Existe
APLICABILIDAD OO
CV PROPUESTO
GESTIN SISTEMA OO
Aplicable
FORMALIDAD
Objetos Existe
Poco formal,
Medianamente formal
REUSO APLICACION
EXISTENTE
REUSO APLICACION REUSO APLICACION OO
Estrategias explcitas
FUTURA
Subsistema del existente,
Muy necesario Ampliacin del existente,
Modificacin del existentes
Componentes del actual
FIGURA 6-16 Mapa de Conocimientos del Area Gestin de Proyectos - CV en Objetos

ENTREGAS EXPERIENCIA REUSO APLICACION

PREVIA PARTICIPACION SOFTWARE PARA
EXISTENTE PROTOTIPAR
Versin temprana, Versin Fuerte
No hay Estrategias explcitas
gradual, Versin parcial Hay Disponible,
Factible de adquirir
EXPERIENCIA
ENTREGA INTERMEDIA TECNICAS IS
INTRODUCCION
FACTOR RIESGO
Existe GRADUAL FACTIBILIDAD
No hay
Existe PROTOTIPO
Necesaria
Factible
OBJETIVO CALIDAD TERMINACION
PROYECTOS
Mecanismos explcitos APLICABILIDAD PROTOTIPO
Prematura
ANALISIS RIESGO Aplicable
Estrategias explcitas CV PROPUESTO

GESTIN
RESPONSABILIDAD
APLICABILIDAD ESPIRAL
Organizacin propia
Espiral
Aplicable
PROCEDIMIENTOS
CAMBIOS
Acuerdos confirmados
PROCEDIMIENTOS D-M
RIESGOS CONVENIENCIA IDENTIFICACION
FORMALIDAD Conveniente ALTERNATIVA METODOLOGIA ALTERNATIVAS
Poco formal, Etapas RIESGO
Medianamente formal Poco probada Etapas anteriores
anteriores
PROCEDIMIENTOS
HABILIDAD RIESGO DESARROLLO- Evaluable
MANTENIMIENTO
Existe NECESIDAD FACTIBILIDAD
Es factible usar los mismos METODOLOGIA METODOLOGIA
Es necesario usar los
mismos Poco probada Poco probada
FIGURA 6-17 Mapa de Conocimientos del Area Gestin de Proyectos - CV en Espiral

FACTIBILIDAD
PROTOTIPO
Factible
VIABILIDAD SOFTWARE
Hay dudas
APLICABILIDAD
NIVEL DE FACTOR RIESGO PROTOTIPO
RIESGO RIESGO ESPIRAL
Existe Aplicable
Mediano riesgo, Aceptable
Alto riesgo
CV PROPUESTO
GESTIN
CATEGORIAS RIESGO
Tcnicos Espiral
RIESGO
TECNICAS AR
Se dispone Evaluable
IDENTIFICACION
ALTERNATIVAS
Se identifican
HABILIDAD RIESGO APLICABILIDAD
ESPIRAL
Existe
RIESGOS ALTERNATIVA Aplicable
Se identifican
FIGURA 6-18 Continuacin figura 6-17

Mapa de Conocimientos del Area Gestin de Proyectos - CV en Espiral

PROYECTO
IDENTIFICACION
Codigo Alfanumrico CV PROPUESTO
REQUISITOS
Cascada
PROYECTO
Objetos
NOMBRE DEL PROYECTO Espiral
Descripcin No hay respuesta
PROYECTO
LIDER DEL PROYECTO
CV PROPUESTO CV PROPUESTO
Nombre del lider APLICACION DEL PROYECTO
Cascada Cascada
PROYECTO Objetos Objetos
FECHA INICIO Espiral Espiral
No hay respuesta
Fecha DD/MM/AAAA No hay respuesta
PROYECTO
FECHA FINALIZACION
CV PROPUESTO
Fecha DD/MM/AAAA GESTION
Cascada PROYECTO
PROYECTO Objetos CV PROPUESTO POR SE
OBJETIVO Espiral
Descripcion No hay respuesta
Cascada
Objetos
Espiral
PROYECTO No hay respuesta
CV SELECCIONADO
Cascada
Objetos
Espiral
Otros.... FIGURA 6-19 Mapa de Conocimientos del Proyecto

Los casos de prueba que se usaron para validar el Modelo Conceptual se

detallan en el captulo 9. Se usaron los casos 1.1; 1.2; 2; 3; 4; 6. El resultado de
la comprobacin fue el siguiente:
Los casos, 1.1, 1.2, 2, 4 coincidieron perfectamente en su resolucin

por el experto y por el Mapa .
Para el caso de prueba 3 se corrigi un error de tipeo en las reglas,
pero eso llevo a revisar todo el conjunto de reglas como verificacin.
Para el caso de prueba 6 se realizaron cambios en la modificacin de
los valores de algunos atributos.
El resultado de la comprobacin fue altamente satisfactorio ya que el

Modelo Conceptual reflej el razonamiento del experto.

Captulo 7
Formalizacin
de Conocimientos
Los conocimientos que en la fase de Conceptualizacin fueron expresados

en representaciones externas intermedias: rbol de descomposicin funcional,
seudorreglas y tablas de concepto-atributo-valor se representan en la fase de
Formalizacin en representaciones compatibles con la tecnologa computacional.
En primer lugar se seleccionan los formalismos a utilizar. Luego se formalizan los
conocimientos que sern posteriormente implementados en la herramienta
seleccionada.
7.1 SELECCIN DE FORMALISMOS
Formalizar consiste en representar simblicamente los conocimientos

mediante alguno de los formalismos existentes, organizarlos de acuerdo con
algn modelo de diseo y determinar los mtodos de inferencia adecuados para
manejar eficientemente y efectivamente dichos conocimientos [Gmez, A. y otros
1997]. Teniendo en cuenta los diversos tipos de formalismos existentes en la
bibliografa de referencia [Gmez, A. y otros 1997], los formalismos de
representacin usados en la etapa de Conceptualizacin y que uno de los
objetivos del presente trabajo es construir el sistema experto usando la
herramienta Kappa los formalismos seleccionados son:
Reglas de produccin para las seudorreglas ya que su estructura es la
misma
Marcos para la tabla Concepto-atributo-valor.
Procedimientos para los procesos a realizar
7.2 FORMALIZACION DE LOS CONOCIMIENTOS EN REGLAS DE

PRODUCCION
Las seudorreglas han sido definidas en detalle en el capitulo de

Conceptualizacin. Considerando que la formalizacin de las seudorreglas en
reglas de produccin es muy semejante a las ya detalladas en el captulo
anterior se ha realizado en un solo paso la formalizacin y la implementacin de
las reglas directamente en la herramienta Kappa-PC.
7.3 FORMALIZACION DE LOS CONOCIMIENTOS EN MARCOS
Cada concepto de la tabla Concepto-Atributo-Valor se formaliza en un

marco clase, siguiendo la propuesta sugerida por Gmez, [Gmez, A. y otros
1997]. Las ranuras de esos marcos son los atributos de cada concepto. Los
demonios de esos marcos precisan cuando y cmo se obtiene el valor de esas
ranuras.
FORMALIZACIN DE CONOCIMIENTOS 02/09/2003 Bibiana D. Rossi 281
MC PROYECTO Tipo Min/ Multiv. Propiedad Valores Valor Si Necesito Si Modifico Si Borro
Ranura Max General Permitidos Omisin
Ranura
() Identificacin Numrico 1/1 No __ Entero > 0 __ PROC.Guardar __ __
() Nombre proyecto Conj. de 1/1 No __ __ __ PROC.Guardar __ __
caracteres
() Lder del proyecto Conj. de 1/1 No __ __ __ PROC.Guardar __ __
caracteres
() Fecha inicio Fecha 1/1 No __ dd/mm/aa __ PROC.Guardar __ __
() Fecha finalizacin Fecha 1/1 No __ dd/mm/aa __ PROC.Guardar __ __
() Objetivo Conj. de 1/n S __ __ __ PROC.Guardar __ __
caracteres
() CV seleccionado Conj. de 1/1 No __ __ __ PROC.Guardar __ __
caracteres
Requisitos Marco 1/n S ^MC __ __ __ __ __
Requisitos
Aplicacin Marco 1/n S ^MC __ __ __ __ __
Aplicacin
Gestin Marco 1/n S ^MC __ __ __ __ __
Gestin
CV Diagnostico Marco 1/n S ^MC CV __ __ __ __ __
Diagnstico
Tabla 7-1 Marco Clase Proyecto

MC GESTION Tipo Min/ Multiv. Propiedad Valores Valor Si Necesito Si Modifico Si Borro
Ranura
Coordinacin Marco 1/n S ^MC __ __ __ __ __
Coordinacin
Usuario Marco 1/n S ^MC __ __ __ __ __
Usuario
Riesgos del Marco 1/n S ^MC Riesgos __ __ __ __ __
proyecto del proyecto
Equipo de proyecto Marco 1/n S ^MC Equipo __ __ __ __ __
de proyecto
Tabla 7-2 Marco Clase Gestin

MC REQUISITOS Tipo Min/ Multiv. Propiedad Valores Valor Si Necesito Si Modifico Si Borro
Ranura
()Tipo de Definicin Conj. de 1/n S __ Formalmente __ PROC. __ __
caracteres Informalmente PreguntarTipoDefin
Exhaustivamente icin
Incompleto
Uniformemente
()Definicin Conj. de 1/n S __ Definicin Clara __ __ __ __
caracteres Definicin Incierta
Requisitos Alta incertidumbre
Baja incertidumbre
() Definicin Lmites Conj. de 1/n S __ Definicin Clara __ __ __ __
caracteres Definicin Incierta
Alta incertidumbre
Baja incertidumbre
()Grado de Conj. de 1/1 No __ Mayoritariamente __ PROC. __ __
caracteres definidos ValoresExcluyentes
certidumbre Parcialmente definidos
()Grado de Conj. de 1/1 No __ Usuario muy exigente __ PROC. __ __
caracteres Usuario poco exigente ValoresExcluyentes
cumplimiento
Tabla 7-3 Marco Clase Requisitos

MC APLICACION Tipo Min/ Multiv. Propiedad Valores Valor Si Necesito Si Modifico Si Borro
Ranura
() Niveles de Conj. de 1/1 No __ Pocos Subsistemas __ PROC. __ __
caracteres Varios Subsistemas ValoresExcluyentes
Composicin
() Complejidad Conj. de 1/1 No __ Baja __ __ __ __
caracteres Alta
Subsistemas
() Componentes Conj. de 1/n S __ Algortmicos __ PROC. __ __
caracteres Matemticos ValoresNoExcluyentes
Predominantes Grficos
() Comportamiento Conj. de 1/n S __ Batch __ PROC. __ __
caracteres Dinmico PreguntarComportami
Predominante Interactivo entoPredominante
Tiempo Real
() Orientacin Conj. de 1/1 No __ Software de Base __ PROC. __ __
caracteres Sistema Basado en ValoresExcluyentes
Conocimiento
Otros
() Progresin Fases Conj. de 1/1 No __ Uniforme y Secuencial __ PROC. __ __
caracteres No Uniforme y ValoresExcluyentes
desarrollo Secuencial
() Relacin Fases Conj. de 1/1 No __ Poca Dependencia __ PROC. __ __
caracteres Mucha Dependencia ValoresExcluyentes
desarrollo Independencia
() Retroalimentacin Conj. de 1/1 No __ Baja __ __ __ __
caracteres Alta
Fases desarrollo
() Integracin HW- Conj. de 1/1 No __ Fuertemente __ PROC. __ __
caracteres Medianamente ValoresExcluyentes
SW Levemente
() Factores diseo Conj. de 1/n S __ Problemas de __ PROC. __ __
caracteres Arquitectura ValoresNoExcluyentes
Problemas de eficacia
Tabla 7-4a Marco Clase Aplicacin

MC APLICACION Tipo Min/ Multiv. Propiedad Valores Valor Si Necesito Si Modifico Si Borro
Ranura
() Existencia Conj. de 1/1 No __ Innovador __ PROC. __ __
caracteres Conocido ValoresExcluyentes
Aplicaciones
() Posibilidad Conj. de 1/1 No __ Pocas opciones __ PROC. __ __
caracteres Varias opciones ValoresExcluyentes
Diseo
() Posibilidad Conj. de 1/1 No __ Pocas opciones __ PROC. __ __
caracteres Varias opciones ValoresExcluyentes
Implementacin
() Modelado Conj. de 1/1 No __ Conveniente __ __ __ __
caracteres No conveniente
Prototipo
() Modelado Objetos Conj. de 1/1 No __ Conveniente __ __ __ __
caracteres No conveniente
() Variabilidad Conj. de 1/1 No __ Alta __ __ __ __
caracteres Baja
Procesos
() Opcionalidad Conj. de 1/1 No __ Mltiple __ __ __ __
caracteres Simple
() Tipo modificacin Conj. de 1/n S __ Redefinicin __ PROC. __ __
caracteres Extensin ValoresNoExcluyentes
Ampliacin
Emisin gradual
Tabla 7-4b Marco Clase Aplicacin

MC Tipo Min/ Multiv. Propiedad Valores Valor Si Necesito Si Modifico Si Borro

COORDINACION
Ranura
() Formalidad Conj. de 1/1 No __ Poco formal __ PROC. __ __
caracteres Medianamente formal ValoresExcluyentes
Muy formal
() Entregas Conj. de 1/1 No __ Versin temprana __ PROC. Entregas __ __
caracteres No versin temprana
Versin gradual
Versin parcial
() Responsabilidad Conj. de 1/1 No __ Terceros __ PROC. __ __
caracteres Organizacin propia ValoresExcluyentes
() Control Gestin Conj. de 1/1 No __ Muy ajustado __ PROC. __ __
ajustado
Poco ajustado
() Software para Conj. de 1/n S __ No disponible __ __ __ __
caracteres Hay disponible
prototipar Factible de adquirir
No adquirible
() Factibilidad Conj. de 1/1 No __ Ampliamente probada __ PROC. __ __
metodologa probada
Poco probada
() Necesidad Conj. de 1/1 No __ Ampliamente probada __ PROC. __ __
Metodologa probada
Poco probada
() Reso aplicacin Conj. de 1/1 No __ Estrategias explcitas __ PROC. __ __
caracteres No estrategias ValoresExcluyentes
existente explcitas
Tabla 7-5a Marco Clase Coordinacin


COORDINACION
Ranura
() Reso aplicacin Conj. de 1/n S __ Subsistema del __ PROC. __ __
caracteres existente ValoresNoExcluyen
OO Ampliacin del tes
existente
Modificacin del
existente
Componentes del
actual
() Reso aplicacin Conj. de 1/1 No __ Muy necesario __ PROC. __ __
futura necesario
Poco necesario
() Procedimientos Conj. de 1/1 No __ Acuerdos confirmados __ PROC. __ __
caracteres No Acuerdos ValoresExcluyentes
Cambios confirmados
() Procedimientos Conj. de 1/n S __ Factible usar los __ PROC. __ __
caracteres mismos ValoresNoExcluyen
Desarrollo- Factible usar tes
Mantenimiento diferentes
Necesario usar los
mismos
Necesario usar
diferentes
() Conveniencia Conj. de 1/1 No __ Ampliamente probada __ __ __ __
caracteres Medianamente
Metodologa probada
Poco probada
() Factibilidad Conj. de 1/1 No __ Factible __ __ __ __
caracteres No factible
Prototipo
() Sistema OO Conj. de 1/1 No __ Existe __ __ __ __
caracteres No existe
Tabla 7-5b Marco Clase Coordinacin


COORDINACION
Ranura
() Entrega Conj. de 1/1 No __ Existe __ __ __ __
Intermedia
() Aplicabilidad Conj. de 1/1 No __ Aplicable __ __ __ __
caracteres No aplicable
Espiral
() Aplicabilidad Conj. de 1/1 No __ Aplicable __ __ __ __
Prototipo
() Aplicabilidad OO Conj. de 1/1 No __ Aplicable __ __ __ __
() Procedimientos Conj. de 1/1 No __ Conveniente __ PROC. __ __
caracteres No conveniente ValorInconsistente
D-M
Tabla 7-5c Marco Clase Coordinacin
MC USUARIO Tipo Min/ Multiv. Propiedad Valores Valor Si Necesito Si Modifico Si Borro
Ranura Ranura Max General Permitidos Omisin
() Participacin Conj. de 1/1 No __ Fuerte __ PROC. __ __

caracteres Regular ValoresExcluyentes
Poca
() Introduccin Conj. de 1/1 No __ Necesaria __ __ __ __
caracteres No necesaria
gradual
Tabla 7-6 Marco Clase Usuario

MC RIESGOS Tipo Min/ Multiv. Propiedad Valores Valor Si Necesito Si Modifico Si Borro
DEL PROYECTO
Ranura
() Viabilidad Conj. de 1/1 S __ Hay certeza __ PROC. __ __
caracteres Hay dudas ValoresExcluyentes
software
() Nivel de riesgo Conj. de 1/1 No __ Alto riesgo __ PROC. __ __
caracteres Mediano riesgo ValoresExcluyentes
Bajo riesgo
No hay riesgo
() Anlisis riesgo Conj. de 1/1 No __ Estrategias explcitas __ PROC. __ __
caracteres No estrategias ValoresExcluyentes
explcitas
() Tcnicas AR Conj. de 1/1 S __ Se dispone __ PROC. __ __
caracteres No se dispone ValoresExcluyentes
() Identificacin Conj. de 1/1 No __ Se identifican __ PROC. __ __
caracteres No se identifican ValoresExcluyentes
Alternativas Etapas anteriores
() Riesgos Conj. de 1/1 No __ Se identifican __ PROC. __ __
caracteres No se identifican ValoresExcluyentes
Alternativa Etapas anteriores
() Categoras riesgo Conj. de 1/n No __ Tcnicos __ __ __ __
caracteres Otros riesgos
() Objetivo calidad Conj. de 1/1 No __ Mecanismos explcitos __ PROC. __ __
caracteres No mecanismos ValoresExcluyentes
explcitos
() Terminacin Conj. de 1/1 No __ Prematura __ PROC. __ __
caracteres En trmino. ValoresExcluyentes
proyectos
() Riesgo Cascada Conj. de 1/1 No __ Aceptable __ __ __ __
caracteres No aceptable
() Riesgo Objetos Conj. de 1/1 No __ Aceptable __ __ __ __
() Habilidad Riesgo Conj. de 1/1 No __ Existe __ __ __ __
Tabla 7-7a Marco Clase Riesgos del Proyecto

MC RIESGOS Tipo Min/ Multiv. Propiedad Valores Valor Si Necesito Si Modifico Si Borro
DEL PROYECTO
Ranura
() Factor Riesgo Conj. de 1/1 No __ Existe. __ __ __ __
() Riesgo Espiral Conj. de 1/1 No __ Aceptable __ __ __ __
() Riesgo Conj. de 1/1 No __ Evaluable __ __ __ __
caracteres No evaluable
Tabla 7-7b Marco Clase Riesgos del Proyecto
MC EQUIPO DE Tipo Min/ Multiv. Propiedad Valores Valor Si Necesito Si Modifico Si Borro
PROYECTO
Ranura
() Experiencia Conj. de 1/1 No __ Hay __ PROC. __ __
caracteres No hay ValoresExcluyentes
tcnicas IS
() Experiencia Conj. de 1/1 No __ Hay __ PROC. __ __
caracteres No hay ValoresExcluyentes
previa
Tabla 7-8 Marco Clase Equipo de proyecto

MC CV Tipo Min/ Multiv. Propiedad Valores Valor Si Necesito Si Modifico Si Borro

DIAGNOSTICO
Ranura
() CV Propuesto Conj. de 1/n No __ Cascada __ __ __ __
caracteres Objetos
Requisitos Espiral
No hay propuesta
caracteres Objetos
Aplicacin Espiral
No hay propuesta
caracteres Objetos
Gestin Espiral
No hay propuesta
() CV Propuesto Conj. de 1/1 No __ Cascada __ __ __ __
caracteres Objetos
proyecto Espiral
No hay propuesta
Tabla 7-9 Marco Clase CV Diagnstico

7.4 FORMALIZACION DE LOS CONOCIMIENTOS EN PROCEDIMIENTOS
A continuacin se describen los procedimientos asociados a cada una de

las propiedades representadas en los marcos que intervienen en la resolucin del
problema.
PROCEDIMIENTO Proyecto:Guardar
COMIENZO
{
Global:NombreBC = SelectFile( "Guardar Proyecto", "*.pro" );
If Not( Null?( Global:NombreBC ) )
Then {
OpenWriteFile( Global:NombreBC );
WriteLine( FormatValue( "/*SISTEMA EXPERTO PARA LA SELECCION DE CICLOS DE
VIDA DE PROYECTOS DE SOFTWARE*/" ) );
WriteLine( FormatValue( "/*Copyright 2001 by Alberto Patron\n*/" ) );
WriteLine( FormatValue( "/*--------------------------------------------------------------------------------------
-*/" ) );
WriteLine( FormatValue( "/*Proyecto: %s (%s)*/", Proyecto:Nombre,
Proyecto:ID ) );
WriteLine( FormatValue( "/*Fecha: %s*/", Date( ) ) );
WriteLine( FormatValue( "/*--------------------------------------------------------------------------------------
-*/" ) );
WriteLine( FormatValue( "/*--------------------------------------------*/" ) );
WriteLine( FormatValue( "/* Informacion del Proyecto */" ) );
WriteInstance( Proyecto );
ForAll [ x|Expresion ]
WriteInstance( x );
WriteLine( FormatValue( "/* Valor de las variables */" ) );
WriteLine( FormatValue( "Global:TA_Modif = %s;", Global:TA_Modif ) );
WriteLine( FormatValue( "Global:TA_Concl = %s;", Global:TA_Concl ) );
WriteLine( FormatValue( "Global:ER_Modif = %s;", Global:ER_Modif ) );
WriteLine( FormatValue( "Global:ER_Concl = %s;", Global:ER_Concl ) );
WriteLine( FormatValue( "Global:GP_Modif = %s;", Global:GP_Modif ) );
WriteLine( FormatValue( "Global:GP_Concl = %s;", Global:GP_Concl ) );
WriteLine( FormatValue( "Global:G_Concl = %s;", Global:G_Concl ) );
WriteLine( FormatValue( "Global:Method = %s;", Global:Method ) );
WriteLine( FormatValue( "Global:RE_Concl = %s;", Global:RE_Concl ) );
WriteLine( FormatValue( "Global:recomendacion = %s;",
Global:recomendacion ) );
CloseWriteFile( );
PostMessage( "Proyecto guardado exitosamente" );
};
};
FIN

PROCEDIMIENTO Requisitos:PreguntarTipoDefinicin
COMIENZO
{
If LengthList(ER1:Valor)>0
Then
{
If Member?(ER1:Valor,formalmente) And Member?(ER1:Valor,informalmente)
Then
{
SetPostMessageTitle("Error en datos");
PostMessage("Se seleccionaron dos valores contradictorios (formalmente,informalmente)");
};
If Member?(ER1:Valor,uniformemente) And Member?(ER1:Valor,desestructuradamente)

Then
{
PostMessage("Se seleccionaron dos valores contradictorios
(uniformemente,desestructuradamente)");
};
If Member?(ER1:Valor,exhaustivamente) And Member?(ER1:Valor,incompletos)

Then
{
PostMessage("Se seleccionaron dos valores contradictorios (exhaustivamente,incompletos)");
};
};
};
FIN
PROCEDIMIENTO ValoresExcluyentes
Este procedimiento esta preprogramado en Kappa-PC. Cuando se usa la
opcin de SINGLE LIST BOX, funcionalmente solo permite seleccionar un nico
valor, por lo tanto cumple con el procedimiento de ValoresExcluyentes.
PROCEDIMIENTO ValoresNoExcluyentes
Este procedimiento esta preprogramado en Kappa-PC. Cuando se usa la
opcin de MULTIPLE LIST BOX, funcionalmente permite seleccionar varios
valores, por lo tanto cumple con el procedimiento de ValoresNoExcluyentes.

PROCEDIMIENTO Aplicacin:PreguntarComportamientoPredominante
COMIENZO
{
If LengthList(ER1:Valor)>0
Then
{
If Member?(TA51:Valor,batch) And Member?(TA5:Valor,interactivo)
Then
{
PostMessage("Se seleccionaron dos valores contradictorios (batch,interactivo)");
};
If Member?(TA51:Valor,batch) And Member?(TA5:Valor,tiempo_real)
Then
{
PostMessage("Se seleccionaron dos valores contradictorios (batch,tiempo_real)");
};
If Member?(TA51:Valor,batch) And Member?(TA5:Valor,dinmico)
Then
{
PostMessage("Se seleccionaron dos valores contradictorios (batch,dinmico)");
};
If Member?(TA51:Valor,ninguno) And Member?(TA5:Valor,interactivo)

Then
{
PostMessage("Se seleccionaron dos valores contradictorios (ninguno,interactivo)");
};
If Member?(TA51:Valor,ninguno) And Member?(TA5:Valor,tiempo_real)
Then
{
PostMessage("Se seleccionaron dos valores contradictorios (ninguno,tiempo_real)");
};
If Member?(TA51:Valor,ninguno) And Member?(TA5:Valor,dinmico)
Then
{
PostMessage("Se seleccionaron dos valores contradictorios (ninguno,dinmico)");
};
};
};
FIN

PROCEDIMIENTO Coordinacin:Entregas
COMIENZO
{
If ( GP20:Valor #= versin_completa And GP18:Valor
#= Si )
Then {
SetPostMessageTitle( "Error en datos" );
PostMessage( "Se seleccionaron dos valores contradictorios Pregunta 8= Si, Pregunta 6=
versin_completa" );
};
If ( GP20:Valor #= versin_parcial And GP18:Valor
#= No )
Then {
PostMessage( "Se seleccionaron dos valores contradictorios Pregunta 8= No, Pregunta 6=
versin_parcial" );
};
If ( GP20:Valor #= versin_gradual And GP18:Valor
#= No )
Then {
versin_gradual" );
};
If ( GP20:Valor #= versin_temprana And GP18:Valor
#= No )
Then {
versin_temprana" );
};
};
FIN
PROCEDIMIENTO Coordinacin:ValorInconsistente
COMIENZO
{
If ( LengthList( GP26:Valor ) > 0 )
Then {
If ( Member?( GP26:Valor, necesario )
And Member?( GP26:Valor, indiferente ) )
Then {
PostMessage( "Se seleccionaron dos valores contradictorios (necesario,indiferente)" );
};
If ( Member?( GP26:Valor, factible )
And Member?( GP26:Valor, indiferente ) )
Then {
PostMessage( "Se seleccionaron dos valores contradictorios (factible,indiferente)" );
};
};
};
FIN

Captulo 8
Implementacin
del Sistema
En este captulo se describen en primer lugar las caractersticas de la

herramienta que se usar para implementar el sistema experto. Luego usando
un caso como ejemplo se presenta el sistema en s, la interfaz y su operatoria
general.
8.1 SELECCIN DE LA HERRAMIENTA
La herramienta seleccionada es Kappa PC desarrollada en 1990 por

INTELLICORP Inc., que posee caractersticas altamente compatibles con la
metodologa que se ha aplicado en el desarrollo del sistema experto. Kappa
brinda un entorno de desarrollo que permite prototipado rpido, lo que facilita un
desarrollo basado en prototipado incremental que es lo que propone la
metodologa IDEAL. El ambiente de desarrollo es totalmente grfico con una
amplia gama de objetos que facilitan la operacin de la aplicacin. Tiene un
entorno de programacin orientada a objetos y facilidades para el desarrollo de
las interfaces de usuario. Kappa tiene un lenguaje propio KAL con el que se
escriben las funciones, los mtodos y las reglas
Los formalismos de representacin del conocimiento en Kappa son los

objetos y las reglas. El motor de inferencias es de dos tipos:
Encadenamiento hacia delante o encadenamiento conducido por
hechos (forward chaining).
Encadenamiento hacia atrs o encadenamiento conducido por
objetivos (backward chaining).
8.1.1 LOS OBJETOS EN KAPPA
Los objetos permiten representar varias propiedades como la herencia,

encapsulamiento de datos y cdigo, jerarquas, herencia. Todas estas
propiedades son compartidas por el sistema de marcos usado para formalizar
los conocimientos. En Kappa los objetos tambin permiten representar los
procedimientos representados en si necesito, si modifico, si borro propios
del sistema de marcos.
El concepto de clase e instancias en los marcos y en los objetos es el

mismo. Los objetos se componen de atributos llamados slots y a los
procedimientos se los llama mtodos.
IMPLEMENTACION DEL SISTEMA 02/09/2003 Bibiana D. Rossi 299

Los slots tiene propiedades como la cardinalidad, el tipo (texto, numrico,

booleano). Pueden ser:
Heredados son derivados del objeto antecesor en la jerarqua. Se

refieren generalmente a propiedades genricas o comunes que
comparten los objetos.
Propios son los que aparecen solamente en un objeto y se refieren a
propiedades especificas del objeto, o sea atributos propios del objeto.
Los mtodos al igual que los slots pueden ser heredados o locales. Se
activan cuando el valor del slot del cual dependen es accedido para ser
consultado o modificado. Hay 4 tipos :
If needed: este mtodo se usa para inicializar el slot

When accesed: se dispara cuando se pide el valor del slot
Before change: se dispara en el momento previo a una modificacin
del valor del slot.
After change: se dispara en el momento posterior a una modificacin
del valor del slot.
8.1.2 LAS REGLAS EN KAPPA
Las reglas representan el conocimiento causal del tipo SI-ENTONCES.

Cada regla queda identificada por un nombre. La parte SI de la regla est
constituida por un conjunto de premisas y la parte ENTONCES por un conjunto
de conclusiones. En Kappa los hechos involucrados en premisas y conclusiones
se refieren a valores de atributos de objetos. El razonamiento del sistema se
basa en reglas y est gestionado por el motor de inferencia.
En el encadenamiento hacia delante la filosofa general consiste en

introducir una serie de hechos que se consideran ciertos en un momento
determinado y dejar que las reglas infieran los nuevos valores. Kappa podr
buscar todas las posibles consecuencias derivadas de los nuevos hechos o slo
algunas, dependiendo que la estrategia sea exhaustiva o selectiva.
En el encadenamiento hacia atrs la filosofa general consiste en

establecer una serie de objetivos y dejar que las reglas deduzcan su veracidad o
no, en funcin del estado actual del sistema. Kappa busca todas las reglas que
puedan probar el objetivo.

8.2 IMPLEMENTACION EN LA HERRAMIENTA
Los pasos seguidos en la implementacin del presente trabajo han sido:

Declaracin del modelo de marcos relacionados con las dos primeras
reas de anlisis del sistema experto: Requisitos y Tipo de aplicacin,
codificando sus propiedades y mtodos.
Incorporacin de las reglas de las dos primeras reas Requisitos y Tipo
de Aplicacin. El sistema se corresponde con la estructura de
razonamiento Encadenamiento hacia atrs (Backward Chaining) . Los
objetivos que se fijan por orden de prioridad son: 1) Ciclo de Vida en
Espiral, 2) Ciclo de vida Orientado a Objetos y 3) Ciclo de Vida en
Cascada.
Desarrollo de una primera interfaz de usuario, donde fue necesario
prestar especial atencin a la forma de preguntar acerca de las
caractersticas del proyecto a analizar. El diseo se realiz sobre la
base de recuadros, en cada recuadro se defini una pregunta con
opciones de respuesta, ya sean del tipo SI / NO o con opciones
predefinidas. Para ello se usaron las facilidades que brinda el Kappa en
la definicin de este tipo de diseo. Los detalles del diseo de interfaz
de usuario se pueden apreciar adecuadamente a partir del tem 8.3
donde se muestra el desarrollo completo de un caso ejemplo.
Se completaron los marcos y las reglas correspondientes a la tercer
rea de anlisis Gestin de proyecto.
Se refin la interfaz de usuario en la presentacin de los resultados, y
se prest especial atencin a la forma de agrupar las preguntas para
facilitar al usuario el anlisis de las caractersticas del proyecto a
analizar.
Se consider especialmente que el usuario al usar el sistema en una
primera aproximacin pudiera desconocer algunos datos. En ese caso
el sistema si bien le brinda el resultado obtenido a partir de la
informacin existente, tambin le informa que preguntas han quedado
sin responder. De esta forma el usuario puede completar la informacin
faltante en las primeras entrevistas, luego incorporarlas al sistema y
obtener un diagnstico ms preciso.
Se ha realizado una sesin de pruebas con el grupo de expertos que
participaron, realizndose as el ultimo refinamiento de la interfaz de
usuario. Los expertos solicitaron conocer el ciclo de vida recomendado
para cada rea, adems del ciclo de vida propuesto, esto le permite al
usuario, dentro del ciclo de vida elegido, organizar el proyecto
adaptndolo con mayor precisin a las caractersticas de cada rea.
Se ha desarrollado una evaluacin exhaustiva del sistema con el experto
principal.
8.2.1 ESTRUCTURA GENERAL DE LOS OBJETOS
La estructura general de los objetos del sistema es la siguiente:
Figura 8-1: Estructura general de objetos del sistema
La estructura general de los objetos del rea Especificacin de

Requerimientos es la siguiente:
Figura 8-2: Estructura general de objetos del rea Especificacin Requerimientos

La estructura general de los objetos del rea Tipo de Aplicacin

es la siguiente:
Figura 8-3: Estructura general de objetos del rea Tipo de Aplicacin
La estructura general de los objetos del rea Gestin de Proyecto

es la siguiente:

Figura 8-4: Estructura general de objetos del rea Gestin de Proyecto

La estructura general de los objetos del rea CV Diagnostico:
Figura 8-5: Estructura general de objetos del rea CV Diagnstico
8.3 DESARROLLO DE UN CASO EJEMPLO
A continuacin se presenta un caso de ejemplo.

Cuando se ingresa al sistema se visualiza la pantalla de presentacin que
se observa en la figura 8-6.
Figura 8-6: Ingreso al sistema

A continuacin se visualiza la pantalla principal del sistema. Figura 8-7.
Figura 8-7: Pantalla Principal del Sistema
Usando el Men desplegable de la barra en Archivo puede

seleccionarse, (figura 8-8), algn proyecto ya ingresado (Abrir Proyecto), figura
8-9, para completar la informacin o comenzar con un proyecto nuevo (Nuevo
Proyecto. Si no hay indicacin expresa el sistema asume que se trabajar con
un proyecto nuevo.
Usando el men desplegable de la barra en Datos puede ingresarse los

datos que identifican al Proyecto , figura 8-10. Para los datos de las reas puede
ingresarse por cualquiera de las opciones indistintamente: Ingresar al rea
Especificacin de Requerimientos, Ingresar al rea Tipo de aplicacin, o al rea
Gestin de Proyecto ya sea desde el men desplegable en Datos o desde los
botones de la pantalla Figura 8-11.

Figura 8-8: Seleccin de un proyecto
Figura 8-9: Abrir un Proyecto

Figura 8-10: Identificacin de un proyecto
Figura 8-11: reas del Proyecto

Para el ejemplo se define un proyecto nuevo que se corresponde con el

caso 2, del capitulo 9, y se seguir el orden sugerido para un proyecto nuevo
que es: Identificacin del Proyecto (figura 8-12), Requerimientos, Tipo de
Aplicacin y Gestin de proyecto.
CASO EJEMPLO 2: Control de Stock

Proyecto: P002-Fabrica de ropa de hombre
Objetivo del proyecto: Desarrollar e implementar un sistema de control de
stock para el depsito central y los negocios de venta al pblico.
Caso 2 Resultados del caso de prueba:

Ciclo de vida esperado Ciclo de vida sugerido por
el sistema experto
CV Especificacin Requerimientos CV Especificacin Requerimientos
Cascada
CV Tipo de Aplicacin Tipo de Aplicacin
Cascada
CV Gestin de proyecto Gestin de proyecto
Objetos
CV del Proyecto CV del Proyecto
Cascada
Figura 8-12: Ejemplo: Identificacin del Proyecto

La figura 8-13 se corresponde con las caractersticas de Requerimientos.

La interfaz de usuario esta diseada para seleccionar las opciones que den
respuesta a las siguientes preguntas (para el caso de ejemplo se han marcado
en letra negrita la opcin de respuesta seleccionada):
Especificacin Requerimientos
ID Afirmacin / Pregunta Opciones
ER1 Al comienzo del proyecto los requerimientos se encuentran Mayoritariamente
definidos:
ER2 El usuario ha explicitado los requisitos: Formalmente,
Exhaustivamente,
Uniformemente
ER3 La exigencia del usuario en el cumplimiento de los Poco exigente
requerimientos en el producto final es:
Figura 8-13: Ingresar cada una de las opciones de las Caractersticas de

Especificacin de Requerimientos
Cada uno de los cuadros de preguntas a completar tiene una opcin de

ayuda, es el recuadro superior donde figura el numero de cuadro, al presionar
el botn (recuadro superior) el usuario obtiene informacin complementaria
sobre las opciones a elegir. Se muestra a modo de ejemplo la informacin
sobre el recuadro 2, figura 8-14.

Figura 8-14: Especificacin de Requerimientos - Consulta de ayuda
La figura 8-15 a 8-17 se corresponde con las caractersticas de Tipo de

Aplicacin. La interfaz de usuario esta diseada para seleccionar las opciones
que den respuesta a las siguientes preguntas (para el caso de ejemplo se han
marcado en letra negrita la opcin de respuesta seleccionada):
Tipo de Aplicacin
TA1 El tipo de aplicacin se orienta al desarrollo de : Otros
TA2 Los componentes predominantes de la aplicacin son: Algortmico
TA3 El comportamiento predominante en la aplicacin es: Batch
TA4 La progresin entre las fases del desarrollo es secuencial y Si

uniforme?
TA5 La relacin entre las fases del proyecto es: Poca dependencia
TA6 El tipo de aplicacin requiere el desarrollo fuertemente integrado de No

hardware y software?
TA7 El sistema a disear es innovador? No
TA8 Para lograr una mejor comprensin del sistema los niveles de Pocos
descomposicin en subsistemas son:
TA9 Para lograr una mejor manipulacin del sistema los niveles de Pocos
TA10 Se requiere detectar en etapas tempranas del proyecto problemas de: Desconoce
TA11 El Diseo del sistema a desarrollar puede resolverse por: Pocas opciones
TA12 La Implementacin del sistema a desarrollar puede resolverse por: Pocas opciones
TA13 Las modificaciones explcitamente previstas son: Extensin

Figura 8-15: Caractersticas de Tipo de Aplicacin- Pantalla 1

Las figuras 8-18 a 8-22 se corresponden con las caractersticas de la

Gestin de Proyecto. La interfaz de usuario esta diseada para seleccionar las
opciones que den respuesta a las siguientes preguntas (para el caso de ejemplo
se han marcado en letra negrita la opcin de respuesta seleccionada):
Gestin de Proyecto
GP1 El desarrollo del proyecto es responsabilidad de: La organizacin
GP2 El equipo de desarrollo tiene experiencia previa en el tipo de Si

aplicacin a desarrollar?
GP3 Es factible usar metodologas de desarrollo: Medianamente probadas
GP4 Es necesario usar metodologas de desarrollo: Medianamente probadas
GP5 El equipo de desarrollo tiene experiencia con las tcnicas de Si

ingeniera del software que su usarn?
GP6 El tipo de entrega que el usuario requiere de la aplicacin es: Versin parcial
GP7 El grado de participacin del usuario en el desarrollo debe ser: Medio
GP8 Es necesario facilitar la introduccin gradual del sistema para Si

los usuarios?
GP9 Se requiere una gestin de proyecto: Poco formal
GP10 El grado de control que se requiere de la gestin del proyecto es: Poco ajustado
GP11 La gestin de proyecto prev definir explcitamente estrategias No

para reusar software existente?

GP12 Se prev la necesidad de reutilizar los componentes del Muy necesario

software a desarrollar en proyectos futuros?
GP13 Existe un sistema previo desarrollado en objetos de forma tal Sin relacin
que el proyecto actual es ..?
GP14 Existe la necesidad de reutilizar los componentes de un No
software ya existente desarrollado en objetos?
GP15 Se dispone de software para prototipar? No
GP16 Es posible adquirir software para prototipar? Desconoce
GP17 Existen dudas sobre la viabilidad del software? No
GP18 Se estima la posibilidad de terminacin prematura de proyectos No

no viables?
GP19 Se estima que el factor de riesgo en el desarrollo del sistema es: Bajo
GP20 Se estiman riesgos tcnicos en el desarrollo del sistema? No
GP21 Se identifican los riesgos asociados con cada una de las Desconoce
alternativas?
GP22 Se cuenta con mtodos y tcnicas para evaluar el riesgo? No
GP23 Se identifican las diferentes maneras de resolver los riesgos? No
GP24 Es necesario definir explcitamente estrategias para realizar Desconoce

anlisis de riesgo?
GP25 Es necesario volver a etapas anteriores en el desarrollo del Desconoce
sistema para la resolucin de algn tpico nuevo de riesgo?
GP26 Es posible volver a etapas anteriores en el desarrollo del Desconoce
sistema cuando se identifican mejores alternativas?
GP27 Es necesario definir mecanismos explcitos para incorporar Si
objetivos de calidad en el desarrollo del producto?
GP28 El uso de los mismos procedimientos para desarrollo y Indiferente
mantenimiento del producto software est previsto como:
GP29 Se requiere de acuerdos confirmados para los cambios a Si
efectuarse durante el desarrollo del proyecto?
Figura 8-18: Caractersticas de Gestin de Proyecto - Pantalla 1



Cada vez que se completan las preguntas de una de las reas, antes de
pasar a otra el sistema verifica que se hayan completado todas las preguntas,
caso contrario le informa al usuario cuales preguntas han quedado sin responder
para que decida si desea continuar o si desea completar esa informacin. En la
figura 8-23 se presenta un ejemplo del rea gestin de Proyectos.
Figura 8-23: Verificacin de preguntas respondidas del rea Gestin de Proyectos
Una vez completadas cada una de las reas el botn Evaluar Ciclo de
Vida realiza el proceso de razonamiento y el sistema presenta los resultados
finales, indicando el resultado propuesta para cada una de las reas y el
resultado final propuesto como el ciclo de vida mas adecuado para llevar
adelante el desarrollo del proyecto, figura 8-24.
El sistema tambin detalla cada una de las reglas que se han aplicado en
el proceso de razonamiento para ese caso en particular, figura 8-25.
El sistema permite guardar la informacin del proyecto, las reglas usadas

en el razonamiento y los resultados obtenidos en un archivo *.txt para poder
imprimir todos los datos del proyecto, figura 8-26.
El sistema actualiza automticamente los datos de Informacin del

Proyecto con el CV propuesto por el sistema experto, figura 8-27.

Figura 8-24: Recomendacin por rea y Recomendacin del CV del Proyecto
Figura 8-25: Detalle de Reglas aplicadas en el proceso de razonamiento

Figura 8-26: Guardar informacin y resultados del Proyecto
Figura 8-27: Actualizacin del CV propuesto por el Sistema Experto

en los datos de Identificacin del Proyecto
Se muestra a continuacin la informacin guardada en el archivo 002.txt,

del caso de ejemplo.
SISTEMA EXPERTO PARA LA SELECCION DE CICLOS DE VIDA DE PROYECTOS
DE SOFTWARE
Copyright 2001 by Bibiana Rossi
------------------------------------------------------------------------------------------
Fecha: 21/07/2001
ID: 002
Proyecto: Control de stock
Lder de Proyecto: Lic. Carlos Beltrami
Objetivo: Desarrollar e Implementar un sistema. de control de stock para deposito
central de una fabrica de ropa
Fecha de inicio: 19/02/1998
Fecha de finalizacin: 30/06/1998
Ciclo de Vida recomendado: Cascada
Ciclo de Vida seleccionado: Cascada
------------------------------------------------------------------------------------------
REGLA ER-R1
<SI TIPO-DEFINICION ES Formalmente Y Exhaustivamente Y Uniformemente
ENTONCES DEFINICION-REQUISITOS ES Clara Y DEFINICION-LIMITES ES Clara>
REGLA ER-R2
<SI DEFINICION-REQUISITOS ES Clara Y DEFINICION-LIMITES ES Clara Y
GRADO-DE-CERTIDUMBRE-INICIO ES Mayoritariamente
ENTONCES CV-PROPUESTO-REQUISITOS ES Cascada>
REGLA CV-R2
<SI RELACION-FASES-DESARROLLO ES Poca dependencia
ENTONCES RETROALIMENTACION-FASES-DESARROLLO ES Baja>
REGLA CV-R4
<SI PROGRE-FASES-DESARR ES Uniforme Y Secuencial Y
RETROALIM-FASES-DESARR ES Baja Y COMP-PREDOMINANTES ES Algortmico
ENTONCES CV-PROP-APLICACION ES Cascada>
REGLA TA-R1
<SI NIVELES-COMPOSICION ES Pocos subsistemas
ENTONCES COMPLEJIDAD-SUBSISTEMAS ES Baja>
REGLA TA-R12
<SI TIPO-MODIFICACION ES Extensin
ENTONCES VARIABILIDAD-PROCESOS ES Alta>
REGLA TA-R16
<SI VARIABILIDAD-PROCESOS ES Alta

ENTONCES MODELADO-PROTOTIPO ES Conveniente>

REGLA GP-R2
<SI NIVEL-RIESGO ES Bajo
ENTONCES RIESGO-CASCADA ES Aceptable>
REGLA GP-R11
<SI REUSO-APLIC-FUTURA ES Muy necesario
ENTONCES SISTEMA-OO ES Existe>
REGLA GP-R12
ENTONCES RIESGO-OO ES Aceptable>
REGLA GP-R17
<SI FORMALIDAD ES Poco Y CONVENIENCIA-METOD ES Medianamente probada
ENTONCES APLICABILIDAD-OO ES Aplicable>
REGLA GP-R18
<SI APLICABILIDAD-OO ES Aplicable Y SISTEMA-OO ES Existe Y RIESGO-OO ES Aceptable
ENTONCES CV-PROPU-GESTION ES Objetos>
REGLA GP-R22
<SI INTRODUCCION-GRADUAL ES Necesaria
ENTONCES APLICABILIDAD-PROTOTIPO ES Aplicable>
REGLA GP-R28
<SI ENTREGAS ES Versin parcial
ENTONCES ENTREGA-INTERMEDIA ES Existe>
REGLA GP-R29
<SI ENTREGA-INTERMEDIA ES Existe
ENTONCES APLICABILIDAD-OO ES Aplicable Y APLICABILIDAD-PROTOTIPO ES Aplicable>
REGLA GP-R33
<SI PROC-CAMBIOS ES Acuerdos confirmados
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA GP-R34
<SI RESPONSABILIDAD ES Organizacin propia
REGLA GP-R37
<SI NECESIDAD-METOD ES Medianamente probada Y
FACTIB-METOD ES Medianamente probada
ENTONCES CONVENIENCIA-METOD ES Medianamente probada>
REGLA GP-R17
REGLA GP-R18


REGLA R3
<SI CV-PROPU-REQUISITOS ES Cascada Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Objetos
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA ER-R2
REGLA R3
REGLA TA-R101
<SI PROGRESION-FASES-DESARR ES Uniforme Y Secuencial Y
RETROALIMENTACION-FASES-DESARR ES Baja Y
COMPORTAMIENTO-PREDOMINANTE ES Batch
ENTONCES CV-PROPU-APLIC ES Cascada>
REGLA R3
REGLA TA-R102
COMPLEJIDAD-SUBSISTEMAS ES Baja Y
COMPONENTES-PREDOMINANTES ES Algortmico
REGLA R3
REGLA TA-R103
COMPLEJIDAD-SUBSISTEMAS ES Baja Y COMPORTAMIENTO-PREDOMINANTE ES Batch
REGLA R3

---------------------------------------------------------------------------------------------------------------------------
CICLO DE VIDA RECOMENDADO
---------------------------------------------------------------------------------------------------------------------------
Se recomienda el Ciclo de Vida en Cascada
Especificacin de Requerimientos recomienda: Cascada

Tipo de Aplicacin recomienda: Cascada
Gestin de Proyecto recomienda: Objetos
El sistema ha respondido satisfactoriamente de acuerdo

con la definicin de los resultados esperados establecida al
inicio del caso de prueba

el sistema experto
Cascada Cascada
Cascada Cascada
Objetos Objetos
Cascada Cascada

Captulo 9
Evaluacin
El objetivo de la etapa de evaluacin es garantizar la calidad del sistema

experto. La calidad esta asociada con el funcionamiento correcto del sistema y
que el sistema responda a las expectativas del usuario. La evaluacin no es, una
fase concreta de la ingeniera del conocimiento [Gmez, A. y otros 1997] sino un
conjunto de actividades que ser realizan a lo largo de cada fase de desarrollo del
sistema. Cada fase del proceso de desarrollo requiere una evaluacin diferente
aunque es conveniente utilizar los mismos casos de prueba a lo largo de todas las
fases.
En este capitulo se presentan los casos de prueba con los que se ha

evaluado el sistema. Se documenta la verificacin y validacin que se ha
realizado y se mencionan los tem que documentan la evaluacin realizada a lo
largo del desarrollo del sistema.
9.1 EVALUACIN DE LA ADQUISICIN DE CONOCIMIENTOS.
Para todas las sesiones cumplidas en la fase de adquisicin de

conocimientos se ha cumplido un ciclo de educcin en el cual el ultimo de los
pasos incluye la Evaluacin de la Sesin (ver pgina 108). Las actividades en
este paso consisten en evaluar los resultados obtenidos, la comprensin de los
mismos por parte del ingeniero en conocimiento y la deteccin de informacin
faltante para analizar en la siguiente sesin.
Entrevistas: se encuentran las evaluaciones de las sesiones A.1, A.2,

A.3 y A.4 (referencias en pginas 92 y 93).
Anlisis de textos: se encuentra la evaluacin de la sesin B.1

(referencias en pgina 93).
Mtodo Delphi: se encuentran las evaluaciones de las sesiones C.1,

C.2 y C.3 (referencias en pgina 93).
Tcnica Nominal de Grupo: se encuentra la evaluacin de la sesin

C.3 (referencias en pagina 93).
Emparrillado: si bien la evaluacin de la parrilla se concret en una

entrevista con el experto, el objetivo de dicha entrevista fue evaluar los
resultados de la aplicacin de la tcnica por eso est asociada esa
evaluacin con esta tcnica. Se encuentran referencias de la evaluacin
de las sesiones D.1 y A.4 (referencias en la pgina 93).
EVALUACION 02/09/2003 Bibiana D. Rossi 325

9.2 EVALUACIN DE LA CONCEPTUALIZACIN DE CONOCIMIENTOS.
Asegurar la calidad del modelo conceptual es una prctica de fundamental

importancia. Usualmente el experto no entiende los formalismos de
representacin, de ah la importancia de que el experto apruebe el modelo
conceptual. [Sierra, A. 1996]. En este caso ha habido varias instancias de
evaluacin concretadas en entrevistas para la revisin parcial de cada uno de los
modelos como as tambin para la Comprobacin final de los distintos tipos de
conocimientos:
Comprobacin de los conocimientos estratgicos: Se encuentran
referencias de la evaluacin en la pgina 180. En las revisiones
parciales a travs de entrevistas se evalu el modelo de descomposicin
funcional.
Comprobacin de los conocimientos tcticos: Se encuentran referencias
de la evaluacin en la pgina 215. En las revisiones parciales a travs
de entrevistas se revisaron detalladamente las seudorreglas.
Comprobacin de los conocimientos fcticos: Se encuentran referencias
de la evaluacin en la pgina 215. En las revisiones parciales se
revisaron: el Glosario de Trminos, el Diccionario de Conceptos, la Tabla
de Concepto Atributo Valor, la Definicin de los Atributos
Comprobacin del Modelo dinmico y del Modelo esttico: una vez
terminados fueron revisados por el experto principal.
Comprobacin del Mapa de Conocimientos y de la fase de
Conceptualizacin: el experto seleccion los casos de prueba 1-1. 1-2, 2,
3, 4 y 6. Se encuentran referencias de la comprobacin en la pgina
268.
9.3 EVALUACIN DE LA FORMALIZACIN DE CONOCIMIENTOS.
En este caso en particular, el experto entiende de formalismos

computacionales lo que fortaleci la evaluacin de la formalizacin respecto de la
conceptualizacin. El experto seleccion los mismos casos de prueba usados en
la comprobacin del Mapa de Conocimiento: 1-1. 1-2, 2, 3, 4 y 6
La evaluacin se ha realizado teniendo en cuenta los criterios propuestos

por Gmez [Gmez, A. y otros 1997] y ha consistido en:
Marcos: se ha revisado si coincide con el modelo conceptual, y se
analizaron Redundancias, Incompletud e Inconsistencia.
Reglas: se han revisado analizando Redundancia, Identidad,
Subsuncin o reglas embebidas, Condiciones SI innecesarias,
Callejones sin salida, Redundancia indirecta (reglas circulares), Reglas
ausentes, Reglas inalcanzables, Inconsistencia, Incompatibilidades.
9.4 EVALUACIN DE LA IMPLEMENTACIN DE CONOCIMIENTOS.
Se ha revisado la definicin de objetos y reglas en la herramienta.
Se ha aplicado el juego de ensayo probando cada uno de los casos

propuestos por los expertos, en el sistema. Los casos presentados son casos
reales que fueron liderados por los expertos consultados. Los proyectos ya fueron
cumplidos. Se detallan en los apartados siguientes cada uno de los casos,
detallando dos cuadros:
Resultados del caso de prueba, donde se presentan los resultados

esperados con el caso de prueba y los resultados obtenidos por el
sistema experto.
Valores del caso de prueba, donde se especifican los valores

particulares de ese proyecto para cada rea de anlisis.
9.4.1 CASO EJEMPLO 1.1: Facturacin Telefnica
Proyecto: 001-1 Telefnica
Objetivo del proyecto: Desarrollar e implementar un sistema de facturacin para

el trfico telefnico.
Caso 1.1 Resultados del caso de prueba:

el sistema experto
Sin respuesta - ninguno
1- Espiral Espiral Objetos
2- Objetos
Sin respuesta - ninguno
No se pudo sacar ninguna conclusin de No se pudo sacar ninguna conclusin de
los datos los datos
El sistema experto, ha respondido satisfactoriamente de acuerdo con la

definicin de los casos de prueba.
Caso 1.1 Valores del caso de prueba

ER1 Al comienzo del proyecto los requerimientos se encuentran Parcialmente
definidos:
ER2 El usuario ha explicitado los requisitos: Formalmente
Incompletos
Tipo de Aplicacin
TA2 Los componentes predominantes de la aplicacin son: Matemtico

Algortmico
TA4 La progresin entre las fases del desarrollo es secuencial y No

uniforme?
TA6 El tipo de aplicacin requiere el desarrollo fuertemente Si

integrado de hardware y software?
TA10 Se requiere detectar en etapas tempranas del proyecto Desconoce
problemas de:
TA11 El Diseo del sistema a desarrollar puede resolverse por: Varias opciones
TA12 La Implementacin del sistema a desarrollar puede resolverse Varias opciones

por:
Ampliacin
Gestin de Proyecto
GP1 El desarrollo del proyecto es responsabilidad de: Terceros



los usuarios?
GP9 Se requiere una gestin de proyecto: Medianamente formal
GP10 El grado de control que se requiere de la gestin del proyecto Medianamente ajustado
es:

GP11 La gestin de proyecto prev definir explcitamente No

estrategias para reusar software existente?
GP12 Se prev la necesidad de reutilizar los componentes del Medianamente necesario
GP18 Se estima la posibilidad de terminacin prematura de No

proyectos no viables?
GP19 Se estima que el factor de riesgo en el desarrollo del sistema Medio
es:
GP20 Se estiman riesgos tcnicos en el desarrollo del sistema? Si
alternativas?
GP22 Se cuenta con mtodos y tcnicas para evaluar el riesgo? Desconoce
GP23 Se identifican las diferentes maneras de resolver los riesgos? Desconoce
GP24 Es necesario definir explcitamente estrategias para realizar No

anlisis de riesgo?
GP27 Es necesario definir mecanismos explcitos para incorporar No
SISTEMA EXPERTO PARA LA SELECCION DE CICLOS DE VIDA DE PROYECTOS DE

SOFTWARE
--------------------------------------------------------------------------
Fecha: 19/05/2001
ID: 001-1
Proyecto: Telefnica
Lder de Proyecto: Lic. Laura Lucchini
Objetivo: Desarrollar e implementar un sistema de facturacin para el trafico telefnico
Ciclo de Vida recomendado: Ninguno
Ciclo de Vida seleccionado: Ninguno
--------------------------------------------------------------------------
REGLA CV-R2

REGLA CV-R5
<SI PROGRE-FASES-DESARR ES No uniforme Y Secuencial
REGLA TA-R1
REGLA TA-R4
<SI COMPONENTES-PREDOMINANTES ES Matematicos
ENTONCES MODELADO-OBJETOS ES Conveniente>
REGLA TA-R12
<SI TIPO-MODOFICACION ES Extension
REGLA TA-R13
<SI TIPO-MODIFICACION ES Ampliacion
REGLA TA-R16
REGLA TA-R20
<SI MODELADO-OBJETOS ES Conveniente Y MODELADO-PROTOTIPO ES Conveniente
ENTONCES CV-PROPU-APLICACION ES Objetos>
REGLA TA-R21
<SI MODELADO-OBJETOS ES Conveniente Y MODELADO-PROTOTIPO ES Conveniente Y
INTREGRACION-HW-SW ES Fuertemente
ENTONCES CV-PROPU-APLICACION ES Espiral>
REGLA TA-R22
<SI POSIBILIDAD-DISEO ES Varias opciones
ENTONCES OPCIONALIDAD ES Mltiple>
REGLA TA-R23
<SI POSIBILIDAD-IMPLEMENTACION ES Varias opciones
REGLA TA-R24
OPCIONALIDAD ES Mltiple
REGLA GP-R13
<SI NIVEL-RIESGO ES Mediano
REGLA GP-R15
<SI FORMALIDAD ES Medianamente Y CONVENIENCIA-METOD ES Medianamente probada


REGLA GP-R22
REGLA GP-R28
REGLA GP-R29
REGLA GP-R33
REGLA GP-R36
<SI CATEGORIA-RIESGO ES Tcnico
ENTONCES FACTOR-RIESGO ES Existe>
REGLA GP-R37
REGLA GP-R15
REGLA GP-R50
ENTONCES RIESGO-ESPIRAL ES Aceptable>
REGLA GP-R52
<SI RIESGO-ESPIRAL ES Aceptable
-------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------
No se pudo sacar ninguna conclusin de los datos
Especificacin de Requerimientos recomienda: - ninguno

Tipo de Aplicacin recomienda: Espiral Objetos
Gestin de Proyecto recomienda: - ninguno -

9.4.2 CASO EJEMPLO 1.2: Facturacin Telefnica
Proyecto: 001-2 Telefnica
Objetivo del proyecto: Desarrollar e implementar un sistema de facturacin para

el trfico telefnico.
Caso 1.2 Resultados del caso de prueba:

el sistema experto
2- Objetos
2- Objetos
Espiral Espiral
Espiral Se recomienda el Ciclo de Vida en Espiral

Caso 1.2 Valores del caso de prueba

definidos:
ER2 El usuario ha explicitado los requisitos: Informalmente
Incompletos
ER3 La exigencia del usuario en el cumplimiento de los requerimientos Poco exigente
en el producto final es:
Tipo de Aplicacin
TA2 Los componentes predominantes de la aplicacin son: Matemtico - Algortmico
uniforme?
TA6 El tipo de aplicacin requiere el desarrollo fuertemente integrado Si
de hardware y software?

TA10 Se requiere detectar en etapas tempranas del proyecto problemas Desconoce
de:
TA12 La Implementacin del sistema a desarrollar puede resolverse por: Varias opciones
TA13 Las modificaciones explcitamente previstas son: Extensin - Ampliacin
Gestin de Proyecto
GP2 El equipo de desarrollo tiene experiencia previa en el tipo de No
GP6 El tipo de entrega que el usuario requiere de la aplicacin es: Versin gradual
GP7 El grado de participacin del usuario en el desarrollo debe ser: Alto
GP8 Es necesario facilitar la introduccin gradual del sistema para los Si
usuarios?
GP10 El grado de control que se requiere de la gestin del proyecto es: Medianamente ajustado
GP11 La gestin de proyecto prev definir explcitamente estrategias Desconoce
GP12 Se prev la necesidad de reutilizar los componentes del software Poco necesario
a desarrollar en proyectos futuros?
GP13 Existe un sistema previo desarrollado en objetos de forma tal que Sin relacin
el proyecto actual es ..?
GP14 Existe la necesidad de reutilizar los componentes de un software No
ya existente desarrollado en objetos?
GP15 Se dispone de software para prototipar? Desconoce
GP16 Es posible adquirir software para prototipar? Si
GP18 Se estima la posibilidad de terminacin prematura de proyectos Desconoce
no viables?
GP19 Se estima que el factor de riesgo en el desarrollo del sistema es: Medio
GP21 Se identifican los riesgos asociados con cada una de las Si

alternativas?
GP22 Se cuenta con mtodos y tcnicas para evaluar el riesgo? Si
GP23 Se identifican las diferentes maneras de resolver los riesgos? Si
GP24 Es necesario definir explcitamente estrategias para realizar Si
anlisis de riesgo?
GP26 Es posible volver a etapas anteriores en el desarrollo del sistema Desconoce
cuando se identifican mejores alternativas?
GP27 Es necesario definir mecanismos explcitos para incorporar Desconoce
GP28 El uso de los mismos procedimientos para desarrollo y Necesario - Factible


SOFTWARE
------------------------------------------------------------------------------------------
Fecha: 19/05/2001
ID: 001-2
Proyecto: Telefnica
Lder de Proyecto: Lic. Laura Lucchini
Objetivo: Desarrollar e implementar un sistema de facturacin para el trafico telefnico
Ciclo de Vida recomendado: Espiral
Ciclo de Vida seleccionado: Espiral
-----------------------------------------------------------------------------------------
REGLA ER-R3
<SI TIPO-DEFINICION ES Informalmente Y Incompleto Y Desestructuradamente
ENTONCES DEFINICION-REQUISITOS ES Incierta Y DEFINICION-LIMITES ES Incierta>
REGLA ER-R4
<SI DEFINICION-REQUISITOS ES Incierta Y DEFINICION-LIMITES ES Incierta Y
GRADO-DE-CERTIDUMBRE-INICIO ES Parcialmente
ENTONCES CV-PROPUESTO-REQUISITOS ES Espiral Y Objetos>
REGLA CV-R2
REGLA CV-R5
REGLA TA-R1
REGLA TA-R4
<SI COMPONENTES-PREDOMINANTES ES Matemticos
REGLA TA-R12
<SI TIPO-MODOFICACION ES Extensin
REGLA TA-R13
<SI TIPO-MODIFICACION ES Ampliacin
REGLA TA-R16


REGLA TA-R20
REGLA TA-R21
REGLA TA-R22
REGLA TA-R23
REGLA TA-R24
REGLA GP-R13
REGLA GP-R15
REGLA GP-R20
<SI SOFT-PROTOTIPO ES Factible
ENTONCES FACTIBILIDAD-PROTOTIPO ES Factible>
REGLA GP-R22
REGLA GP-R23
<SI PARTICIPACION-USUARIO ES Fuerte
REGLA GP-R25
<SI ENTREGAS ES Versin gradual
REGLA GP-R27
<SI EXPERIENCIA-PREVIA ES No hay

REGLA GP-R29
REGLA GP-R31
<SI PROC-DES-MANTE ES Necesario Y Factible
ENTONCES PROCEDIMIENTOS-DM ES Conveniente>
REGLA GP-R32
<SI PROCEDIMIENTOS-DM ES Conveniente
REGLA GP-R33
REGLA GP-R36
<SI CATEGORIA-RIESGO ES Tecnico
REGLA GP-R37
REGLA GP-R15
REGLA GP-R38
<SI RIESGO-ALTERNATIVAS ES Se identifican Y
IDENTIFICACION-ALTERNATIVAS ES Se identifican
ENTONCES HABILIDAD-RIESGO ES Existe>
REGLA GP-R43
<SI FACTOR-RIESGO ES Existe Y ANALISIS-RIESGO ES Estrategias explicitas
REGLA GP-R45
<SI APLICAB-PROTOTIPO ES Aplicable Y FACTIB-PROTOTIPO ES Factible Y
RIESGO ES Evaluable Y APLICAB-ESPIRAL ES Aplicable
ENTONCES CV-PROPU-GESTION ES Espiral>
REGLA R2
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Espiral Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
REGLA ER-R4


REGLA R15
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Objetos Y
ENTONCES CV-PROPU-PROYECTO ES Objetos>
REGLA R2
REGLA R24
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Objetos Y
REGLA R26
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Espiral Y
REGLA GP-R50
REGLA GP-R52
REGLA GP-R43
REGLA GP-R45
REGLA R2
REGLA R15
REGLA R24

REGLA R26
REGLA GP-R56
<SI FACTOR-RIESGO ES Existe Y HABILIDAD-RIESGO ES Existe Y
TECNICAS-AR ES Se dispone
ENTONCES RIESGO ES Evaluable>
REGLA GP-R45
REGLA R2
REGLA R15
REGLA R24
REGLA R26
-------------------------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------------------------
Se recomienda el Ciclo de Vida en Espiral
Especificacin de Requerimientos recomienda: Espiral Objetos

Gestin de Proyecto recomienda: Espiral

9.4.3 CASO EJEMPLO 2: Control de Stock
Proyecto: 002 Fabrica de ropa de hombre
Objetivo del proyecto: Desarrollar e implementar un sistema de control de stock

para el depsito central y los negocios de venta al pblico.

el sistema experto
Cascada Cascada
Cascada Cascada
Objetos Objetos
Cascada Se recomienda el Ciclo de Vida en Cascada

Caso 2 Valores del caso de prueba

definidos:
Exhaustivamente,
Uniformemente
Tipo de Aplicacin
uniforme?
TA6 El tipo de aplicacin requiere el desarrollo fuertemente No

problemas de:
TA12 La Implementacin del sistema a desarrollar puede resolverse Pocas opciones

por:
Gestin de Proyecto



los usuarios?
GP10 El grado de control que se requiere de la gestin del proyecto Poco ajustado
es:
GP19 Se estima que el factor de riesgo en el desarrollo del sistema Bajo
es:
alternativas?

anlisis de riesgo?

SOFTWARE
------------------------------------------------------------------------------------------
Fecha: 19/05/2001
ID: 002
Proyecto: Control de stock
Lider de Proyecto: Lic. Carlos Beltrami
Objetivo: Desarrollar e Implementar un Sist. de control de stock para deposito central y negocios.
------------------------------------------------------------------------------------------
REGLA ER-R1
REGLA ER-R2
REGLA CV-R2
REGLA CV-R4
REGLA TA-R1
REGLA TA-R12
REGLA TA-R16
REGLA GP-R2
REGLA GP-R11


REGLA GP-R12
REGLA GP-R17
REGLA GP-R18
REGLA GP-R22
REGLA GP-R28
<SI ENTREGAS ES Version parcial
REGLA GP-R29
REGLA GP-R33
REGLA GP-R34
REGLA GP-R37
REGLA GP-R17
REGLA GP-R18
REGLA R3

REGLA ER-R2
REGLA R3
REGLA TA-R101
REGLA R3
REGLA TA-R102
REGLA R3
REGLA TA-R103
REGLA R3
------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------


9.4.4 CASO EJEMPLO 3: Control de Morosos
Proyecto: 003 Municipal
Objetivo del proyecto: Desarrollar e implementar un sistema para el control de

morosos de la tasa municipal de alumbrado, barrido y limpieza.

el sistema experto
1- Espiral Espiral Objetos Cascada
2- Objetos
3- Cascada
Cascada Cascada
Cascada Cascada


definidos:
Exhaustivamente,
Uniformemente
ER3 La exigencia del usuario en el cumplimiento de los Muy exigente,
Tipo de Aplicacin
uniforme?

problemas de:

por:
TA13 Las modificaciones explcitamente previstas son: Redefinicin
Gestin de Proyecto

GP3 Es factible usar metodologas de desarrollo: Ampliamente probadas
GP4 Es necesario usar metodologas de desarrollo: Ampliamente probadas

GP6 El tipo de entrega que el usuario requiere de la aplicacin es: Versin completa
los usuarios?
es:
GP12 Se prev la necesidad de reutilizar los componentes del Poco necesario
GP16 Es posible adquirir software para prototipar? No
GP19 Se estima que el factor de riesgo en el desarrollo del sistema Sin riesgo
es:
GP21 Se identifican los riesgos asociados con cada una de las No
alternativas?
anlisis de riesgo?
GP25 Es necesario volver a etapas anteriores en el desarrollo del No
GP26 Es posible volver a etapas anteriores en el desarrollo del No


SOFTWARE

------------------------------------------------------------------------------------------
Fecha: 19/05/2001
ID: 003
Proyecto: Control de Morosos
Lder de Proyecto: Lic. Enrique Fernndez
Objetivo: Desarrollar un sistema para control de morosos de la Tasa Municipal de ABL
------------------------------------------------------------------------------------------
REGLA ER-R1
REGLA ER-R2
REGLA ER-R5
<SI GRADO-CUMPLIMIENTO-PRODUCTO-FINAL ES Usuario muy exigente
REGLA CV-R2
REGLA CV-R4
REGLA TA-R1
REGLA TA-R11
<SI TIPO-MODOFICACION ES Redefinicin
REGLA TA-R16
REGLA GP-R1
<SI NECESIDAD-METOD ES Ampliamente probada Y
FACTIBILIDAD-METOD ES Ampliamente probada
ENTONCES CONVENIENCIA-METOD ES Ampliamente probada>
REGLA GP-R3
<SI SOFT-PROTOTIPO ES No disponible Y No adquirible
ENTONCES FACTIBILIDAD-PROTOTIPO ES No factible>
REGLA GP-R4
<SI NIVEL-RIESGO ES No hay
REGLA GP-R5
<SI CONVENIENCIA-METOD ES Ampliamente probada Y
ENTREGAS ES Versin completa Y RIESGO-CASCADA ES Aceptable
ENTONCES CV-PROPU-GESTION ES Cascada>
REGLA GP-R16
<SI FACTIB-PROTOTIPO ES No factible Y RIESGO-CASCADA ES Aceptable
REGLA GP-R19
REGLA GP-R22
REGLA GP-R33
REGLA GP-R34
REGLA R0
CV-PROPU-GESTION ES Cascada
REGLA ER-R2
REGLA R0
REGLA R6
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Cascada Y
REGLA R10
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Cascada Y
REGLA TA-R101
REGLA R0
REGLA R6

REGLA R10
REGLA TA-R102
REGLA R0
REGLA R6
REGLA R10
REGLA TA-R103
REGLA R0
REGLA R6
REGLA R10
----------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------
Especificacin de Requerimientos recomienda: Espiral Objetos Cascada

Gestin de Proyecto recomienda: Cascada

9.4.5 CASO EJEMPLO 4: Tcnica Emparrillado
Proyecto: 004 Emparrillado.
Objetivo del proyecto: Desarrollar e implementar una aplicacin para el calculo

automtico de la tcnica de emparrillado. El sistema debe dibujar los grficos
resultantes del calculo.

el sistema experto
2- Objetos
Objetos Objetos
Objetos Objetos
Objetos Se recomienda el Ciclo de Vida de Objetos


ER1 Al comienzo del proyecto los requerimientos se encuentran No
definidos:
ER2 El usuario ha explicitado los requisitos: Informalmente, Incompletos
Tipo de Aplicacin
TA1 El tipo de aplicacin se orienta al desarrollo de : Software de base
TA2 Los componentes predominantes de la aplicacin son: Grfico Matemtico
TA3 El comportamiento predominante en la aplicacin es: Interactivo Dinmico

uniforme?

TA5 La relacin entre las fases del proyecto es: Mucha dependencia

TA7 El sistema a disear es innovador? Si
TA10 Se requiere detectar en etapas tempranas del proyecto Eficacia
problemas de:

por:
TA13 Las modificaciones explcitamente previstas son: Redefinicin - Ampliacin
Gestin de Proyecto

GP5 El equipo de desarrollo tiene experiencia con las tcnicas de No

GP6 El tipo de entrega que el usuario requiere de la aplicacin es: Versin temprana
GP8 Es necesario facilitar la introduccin gradual del sistema para No

los usuarios?
es:
GP11 La gestin de proyecto prev definir explcitamente Si
GP14 Existe la necesidad de reutilizar los componentes de un Desconoce
GP15 Se dispone de software para prototipar? Si

es:
GP21 Se identifican los riesgos asociados con cada una de las No

alternativas?


anlisis de riesgo?
GP25 Es necesario volver a etapas anteriores en el desarrollo del No
GP28 El uso de los mismos procedimientos para desarrollo y Necesario Factible
GP29 Se requiere de acuerdos confirmados para los cambios a No

SOFTWARE
------------------------------------------------------------------------------------------
Fecha: 19/05/2001
ID: 004
Proyecto: Tcnica Emparrillado
Lder de Proyecto: Lic. Enrique Fernndez
Objetivo: Desarrollar aplicacin para el calculo automtico y grficos de la tcnica de emparrillado.
Ciclo de Vida recomendado: Objetos
Ciclo de Vida seleccionado: Objetos
------------------------------------------------------------------------------------------
REGLA ER-R3
REGLA ER-R4
REGLA ER-R5
REGLA CV-R3
<SI RELACION-FASES-DESARROLLO ES Mucha dependencia
ENTONCES RETROALIMENTACION-FASES-DESARROLLO ES Alta>
REGLA CV-R5
REGLA TA-R1


REGLA TA-R4
REGLA TA-R5
<SI COMPONENTES-PREDOMINANTES ES Grficos
REGLA TA-R7
<SI COMPORTAMIENTO-PREDOMINANTE ES Interactivo
ENTONCES MODELAO-OBJETOS ES Conveniente>
REGLA TA-R9
<SI ORIENTACION ES Software de base
ENTONCES MODELADO OBJETOS ES Conveniente>
REGLA TA-R11
REGLA TA-R13
REGLA TA-R15
<SI FACTORES-DISEO ES Problemas de eficacia
REGLA TA-R16
REGLA TA-R17
<SI EXISTENCIA-APLICACIONES ES Innovador
ENTONCES MODELADO PROTOTIPO ES Conveniente>
REGLA TA-R20
REGLA GP-R2
REGLA GP-R11
REGLA GP-R12


REGLA GP-R17
REGLA GP-R18
REGLA GP-R20
REGLA GP-R21
<SI SOFT-PROTOTIPO ES Disponible
ENTONCES FACTIBLIDAD-PROTOTIPO ES Factible>
REGLA GP-R24
<SI ENTREGAS ES Versin temprana
REGLA GP-R26
<SI REUSO-APLIC-EXISTENTE ES Estrategias explicitas
REGLA GP-R18
REGLA GP-R27
REGLA GP-R29
REGLA GP-R30
<SI EXPERIENCIA-TECNICAS-IS ES No hay
REGLA GP-R31
REGLA GP-R32
REGLA GP-R34

REGLA GP-R37
REGLA GP-R17
REGLA GP-R18
REGLA R1
REGLA ER-R4
REGLA R1
REGLA R18
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
Se recomienda el Ciclo de Vida de Objetos

Tipo de Aplicacin recomienda: Objetos

9.4.6 CASO EJEMPLO 5: Inscripcin Universitaria
Proyecto: 005 Inscripcin Sistemas
Objetivo del proyecto: Desarrollar e implementar un sistema que permita la

inscripcin en las materias a cursar para alumnos de una carrera universitaria.

el sistema experto
1-Espiral Espiral Objetos
2- Objetos
1-Espiral Espiral Objetos
2- Objetos
Espiral Espiral


definidos:
ER2 El usuario ha explicitado los requisitos: Informalmente, Incompletos
ER3 La exigencia del usuario en el cumplimiento de los Muy exigente
Tipo de Aplicacin
TA3 El comportamiento predominante en la aplicacin es: Interactivo

uniforme?
TA5 La relacin entre las fases del proyecto es: Mucha dependencia


TA8 Para lograr una mejor comprensin del sistema los niveles de Muchos
TA9 Para lograr una mejor manipulacin del sistema los niveles de Muchos
TA10 Se requiere detectar en etapas tempranas del proyecto Arquitectura Eficacia
problemas de:

por:
Gestin de Proyecto



los usuarios?
es:
GP18 Se estima la posibilidad de terminacin prematura de Desconoce

GP19 Se estima que el factor de riesgo en el desarrollo del sistema Alto
es:

alternativas?

anlisis de riesgo?

GP26 Es posible volver a etapas anteriores en el desarrollo del Si


SOFTWARE
------------------------------------------------------------------------------------------
Fecha: 19/05/2001
ID: 005
Proyecto: Inscripcin Universitaria
Lder de Proyecto: Ing. Mara Florencia Pollo Cattaneo
Objetivo: Desarrollar un sistema que permite la inscripcin en materias para alumnos
universitarios.
------------------------------------------------------------------------------------------
REGLA ER-R3
REGLA ER-R5
REGLA CV-R3
REGLA CV-R5
REGLA TA-R7
REGLA TA-R11
REGLA TA-R14

<SI FACTORES-DISEO ES Problemas de arquitectura

REGLA TA-R15
REGLA TA-R16
REGLA TA-R20
REGLA TA-R21
REGLA TA-R22
REGLA TA-R23
REGLA TA-R24
REGLA GP-R11
REGLA GP-R15
REGLA GP-R20
REGLA GP-R22
REGLA GP-R23

REGLA GP-R27
REGLA GP-R30
REGLA GP-R31
REGLA GP-R32
REGLA GP-R33
REGLA GP-R34
REGLA GP-R36
REGLA GP-R37
REGLA GP-R15
REGLA GP-R38
REGLA GP-R39
<SI HABILIDAD-RIESGO ES Existe Y IDENTIFICACION-ALTERNATIVAS ES Etapas anteriores
REGLA GP-R40
<FORMULACION EXTERNA>
REGLA GP-R43

REGLA GP-R44
<SI FACTOR-RIESGO ES Existe Y OBJETIVO-CALIDAD ES Mecanismos explcitos
REGLA GP-R45
REGLA R2
REGLA R2
REGLA R15
REGLA R24
REGLA R26
REGLA GP-R52
REGLA GP-R43
REGLA GP-R45
REGLA R2


REGLA R15
REGLA R24
REGLA R26
REGLA GP-R44
REGLA GP-R45
REGLA R2
REGLA R15
REGLA R24
REGLA R26
REGLA GP-R51
<SI NIVEL-RIESGO ES Alto
REGLA GP-R52


REGLA GP-R43
REGLA GP-R45
REGLA R2
REGLA R15
REGLA R24
REGLA R26
REGLA GP-R44
REGLA GP-R45
REGLA R2
REGLA R15

REGLA R24
REGLA R26
REGLA GP-R56
REGLA GP-R45
REGLA R2
REGLA R15
REGLA R24
REGLA R26
---------------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------------


9.4.7 CASO EJEMPLO 6: Organizar Comisiones
Proyecto: 006-Comisiones Inscripcin
Objetivo del proyecto: Desarrollar e implementar un sistema que organice las

comisiones para el dictado de clases, informando: materia-profesor-alumnos de
cada comisin.

el sistema experto
1- Espiral
2- Objetos Espiral Objetos Cascada
3- Cascada
Cascada Cascada
Cascada Cascada


definidos:
Exhaustivamente,
Uniformemente
ER3 La exigencia del usuario en el cumplimiento de los Muy exigente
Tipo de Aplicacin

uniforme?
TA5 La relacin entre las fases del proyecto es: Poca dependencia,


problemas de:

por:
Gestin de Proyecto

GP3 Es factible usar metodologas de desarrollo: Ampliamente probadas
GP4 Es necesario usar metodologas de desarrollo: Ampliamente probadas

GP7 El grado de participacin del usuario en el desarrollo debe ser: Bajo

los usuarios?
GP9 Se requiere una gestin de proyecto: Muy formal
GP10 El grado de control que se requiere de la gestin del proyecto Muy ajustado
es:
GP18 Se estima la posibilidad de terminacin prematura de Desconoce

es:
alternativas?

anlisis de riesgo?

GP26 Es posible volver a etapas anteriores en el desarrollo del No


SOFTWARE
------------------------------------------------------------------------------------------
Fecha: 20/05/2001
ID: 006
Proyecto: Organizar Comisiones
Lder de Proyecto: Lic. Carlos Leone
Objetivo: Desarrollar un sistema que organice las comisiones para el dictado de clases,
informando: materia-profesor-alumnos de cada comisin
------------------------------------------------------------------------------------------
REGLA ER-R1
REGLA ER-R2
REGLA ER-R5
REGLA CV-R2
REGLA CV-R4
REGLA TA-R1


REGLA TA-R11
REGLA TA-R16
REGLA GP-R2
REGLA GP-R1
<SI NECESIDAD-METOD ES Ampliamente probada Y
FACTIBILIDAD-METOD ES Ampliamente probada
ENTONCES CONVENIENCIA-METOD ES Ampliamente probada>
REGLA GP-R3
REGLA GP-R5
<SI CONVENIENCIA-METOD ES Ampliamente probada Y ENTREGAS ES Versin completa Y
RIESGO-CASCADA ES Aceptable
REGLA GP-R12
REGLA GP-R16
REGLA GP-R22
REGLA GP-R31
REGLA GP-R32
REGLA GP-R33
REGLA GP-R34


REGLA R0
REGLA ER-R2
REGLA R0
REGLA R6
REGLA R10
REGLA TA-R101
REGLA R0
REGLA R6
REGLA R10
REGLA TA-R102


REGLA R0
REGLA R6
REGLA R10
REGLA TA-R103
REGLA R0
REGLA R6
REGLA R10
-----------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------
Especificacin de Requerimientos recomienda: Espiral Objetos Cascada


9.4.8 CASO EJEMPLO 7: Administracin Consorcio
Proyecto: 007 Consorcio
Objetivo del proyecto: Desarrollar e implementar un sistema de facturacin

mensual para consorcios de edificios de departamento.

el sistema experto
Cascada Cascada
Cascada Cascada
Cascada Cascada

Caso 7 Valores del caso de prueba:

definidos:
Exhaustivamente,
Uniformemente
ER3 La exigencia del usuario en el cumplimiento de los Poco exigente,

Tipo de Aplicacin

uniforme?
TA5 La relacin entre las fases del proyecto es: Poca dependencia,


problemas de:

por:
TA13 Las modificaciones explcitamente previstas son: Ampliacin
Gestin de Proyecto

GP3 Es factible usar metodologas de desarrollo: Desconoce
GP4 Es necesario usar metodologas de desarrollo: Desconoce
GP5 El equipo de desarrollo tiene experiencia con las tcnicas de Desconoce

GP7 El grado de participacin del usuario en el desarrollo debe ser: Bajo
GP8 Es necesario facilitar la introduccin gradual del sistema para Desconoce

los usuarios?
GP9 Se requiere una gestin de proyecto: Desconoce
es:

GP19 Se estima que el factor de riesgo en el desarrollo del sistema Sin riesgo
es:
alternativas?

anlisis de riesgo?


GP29 Se requiere de acuerdos confirmados para los cambios a Desconoce

SOFTWARE
------------------------------------------------------------------------------------------
Fecha: 20/05/2001
ID: 007
Proyecto: Consorcio
Objetivo: Desarrollar e Implementar un sistema de facturacin mensual para consorcios de
edificios de departamentos.
------------------------------------------------------------------------------------------
REGLA ER-R1
REGLA ER-R2
REGLA CV-R2
REGLA CV-R4
REGLA TA-R1
REGLA TA-R13
REGLA TA-R16
REGLA GP-R3
REGLA GP-R4
REGLA GP-R16
REGLA GP-R19
REGLA ER-R2
REGLA R0
REGLA TA-R101
REGLA R0
REGLA TA-R102
REGLA R0
REGLA TA-R103
REGLA R0
----------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------


9.4.9 CASO EJEMPLO 8: Registracin Contable
Proyecto: 008 Contable
Objetivo del proyecto: Desarrollar e implementar un sistema de registracion de

asientos contables para una empresa distribuidora de productos farmacolgicos.

el sistema experto
Sin respuesta - ninguno -
Objetos Objetos Cascada

Cascada Cascada

Sin Respuesta No se pudo sacar ninguna conclusin de los datos


definidos:
ER2 El usuario ha explicitado los requisitos: Exhaustivamente,
Informalmente
ER3 La exigencia del usuario en el cumplimiento de los Poco exigente,
Tipo de Aplicacin

uniforme?
TA5 La relacin entre las fases del proyecto es: Mucha dependencia,


problemas de:

por:
TA13 Las modificaciones explcitamente previstas son: Extensin - Ampliacin
Gestin de Proyecto

GP4 Es necesario usar metodologas de desarrollo: Desconoce
GP5 El equipo de desarrollo tiene experiencia con las tcnicas de Desconoce
GP8 Es necesario facilitar la introduccin gradual del sistema para Desconoce
los usuarios?
GP10 El grado de control que se requiere de la gestin del proyecto es: Medianamente ajustado
GP11 La gestin de proyecto prev definir explcitamente estrategias Desconoce
GP18 Se estima la posibilidad de terminacin prematura de proyectos No
no viables?
GP19 Se estima que el factor de riesgo en el desarrollo del sistema es: Bajo
alternativas?
anlisis de riesgo?


SOFTWARE
------------------------------------------------------------------------------------------
Fecha: 20/05/2001
ID: 008
Proyecto: Registracin Contable
Objetivo: Desarrollar e Implementar un sistema de registracin de asientos contables para una
empresa distribuidora de productos farmacolgicos.
------------------------------------------------------------------------------------------
REGLA CV-R3
REGLA TA-R1
REGLA TA-R7
REGLA TA-R12
REGLA TA-R13
REGLA TA-R16
REGLA TA-R20
REGLA GP-R2
REGLA GP-R3
REGLA GP-R12
REGLA GP-R16
REGLA GP-R28


REGLA GP-R29
REGLA GP-R33
REGLA TA-R102
-----------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------
No se pudo sacar ninguna conclusin de los datos
Especificacin de Requerimientos recomienda: - ninguno -

Tipo de Aplicacin recomienda: Objetos Cascada
9.4.10 CASO EJEMPLO 9: Portal Empleos
Proyecto: 009 Empleos
Objetivo del proyecto: Desarrollar e implementar un sistema de acceso masivo

por Internet para oferta y bsqueda de empleos.

el sistema experto
2- Objetos
Objetos Objetos

Objetos Objetos

Objetos Se recomienda el Ciclo de Vida de Objetos



definidos:
Incompletos
Tipo de Aplicacin
TA2 Los componentes predominantes de la aplicacin son: Grafico - Otro
TA3 El comportamiento predominante en la aplicacin es: Interactivo - Tiempo Real

uniforme?

problemas de:

por:
TA13 Las modificaciones explcitamente previstas son: Emisin gradual
Gestin de Proyecto


GP8 Es necesario facilitar la introduccin gradual del sistema para No

los usuarios?
GP10 El grado de control que se requiere de la gestin del proyecto Muy ajustado
es:
GP11 La gestin de proyecto prev definir explcitamente Si


GP15 Se dispone de software para prototipar? Desconoce

GP19 Se estima que el factor de riesgo en el desarrollo del sistema Medio
es:

alternativas?
anlisis de riesgo?
GP28 El uso de los mismos procedimientos para desarrollo y Necesario

SOFTWARE
------------------------------------------------------------------------------------------
Fecha: 21/07/2001
ID: 009
Proyecto: Portal Empleos
Lder de Proyecto: Ing. Mariano Wechsler
Objetivo: Desarrollar e Implementar un sistema de acceso masivo por Internet para oferta y
bsqueda de empleos.
Ciclo de Vida recomendado: Objetos
Ciclo de Vida seleccionado: Objetos
------------------------------------------------------------------------------------------
REGLA ER-R3

REGLA ER-R4
REGLA ER-R5
REGLA CV-R3
REGLA CV-R5
REGLA TA-R5
<SI COMPONENTES-PREDOMINANTES ES Grficos
REGLA TA-R7
REGLA TA-R8
<SI COMPORTAMIENTO-PREDOMINANTE ES Tiempo real
ENTONCES MODELADO OBJETOS ES Conveniente>
REGLA TA-R14
REGLA TA-R15
REGLA TA-R20
REGLA GP-R11
<SI REUSO-APLIC-FUTURA ES Muy necesario ENTONCES SISTEMA-OO ES Existe>
REGLA GP-R13
<SI NIVEL-RIESGO ES Mediano ENTONCES RIESGO-OO ES Aceptable>
REGLA GP-R15
REGLA GP-R18


REGLA GP-R26
<SI REUSO-APLIC-EXISTENTE ES Estrategias explicitas
REGLA GP-R18
REGLA GP-R27
REGLA GP-R28
REGLA GP-R29
REGLA GP-R33
REGLA GP-R36
REGLA GP-R37
REGLA GP-R15
REGLA GP-R18
REGLA GP-R38
REGLA GP-R43

REGLA GP-R44
REGLA R1
REGLA R18
REGLA ER-R4
REGLA R1
REGLA R18
REGLA GP-R50
REGLA GP-R52
REGLA GP-R43
REGLA GP-R44
REGLA GP-R56

---------------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------------
Se recomienda el Ciclo de Vida de Objetos

Tipo de Aplicacin recomienda: Objetos
9.4.11 CASO EJEMPLO 10: Pedidos Droguera
Proyecto: 010 Droguera
Objetivo del proyecto: Desarrollar e implementar un sistema de toma de pedidos

en lnea para una distribuidora de productos farmacuticos, con el armado
automtico del pedido.

el sistema experto
2- Objetos
2- Objetos
Espiral Espiral



definidos:
Incompletos
Tipo de Aplicacin
TA2 Los componentes predominantes de la aplicacin son: Matemtico

Algortmico - Otro

uniforme?

TA7 El sistema a disear es innovador? Si
problemas de:

por:
TA13 Las modificaciones explcitamente previstas son: Redefinicin Extensin
Ampliacin
Gestin de Proyecto

GP3 Es factible usar metodologas de desarrollo: Poco probadas
GP4 Es necesario usar metodologas de desarrollo: Poco probadas

GP6 El tipo de entrega que el usuario requiere de la aplicacin es: Versin temprana

los usuarios?
es:

GP18 Se estima la posibilidad de terminacin prematura de Si

GP19 Se estima que el factor de riesgo en el desarrollo del sistema Alto
es:

alternativas?

anlisis de riesgo?
GP25 Es necesario volver a etapas anteriores en el desarrollo del Si
GP26 Es posible volver a etapas anteriores en el desarrollo del Si

SOFTWARE
------------------------------------------------------------------------------------------
Fecha: 20/05/2001
ID: 010
Proyecto: Pedidos Droguera
Lder de Proyecto: Lic. Carlos Leone
Objetivo: Desarrollar e Implementar un sistema de toma de pedidos en lnea para una distribuidora
de productos farmacuticos, con el armado automtico del pedido.
------------------------------------------------------------------------------------------
REGLA ER-R3
REGLA ER-R4
REGLA ER-R5


REGLA CV-R3
REGLA CV-R5
REGLA TA-R4
REGLA TA-R7
REGLA TA-R12
REGLA TA-R11
REGLA TA-R13
REGLA TA-R14
REGLA TA-R15
REGLA TA-R16
REGLA TA-R17
<SI EXISTENCIA-APLICACIONES ES Innovador
ENTONCES MODELADO PROTOTIPO ES Conveniente>
REGLA TA-R20
REGLA TA-R21

REGLA TA-R22
REGLA TA-R23
REGLA TA-R24
REGLA GP-R20
REGLA GP-R22
REGLA GP-R23
REGLA GP-R24
<SI ENTREGAS ES Versin temprana
REGLA GP-R27
REGLA GP-R29
REGLA GP-R30
REGLA GP-R31
REGLA GP-R32
REGLA GP-R33


REGLA GP-R34
REGLA GP-R36
REGLA GP-R38
REGLA GP-R39
<SI HABILIDAD-RIESGO ES Existe Y
IDENTIFICACION-ALTERNATIVAS ES Etapas anteriores
REGLA GP-R40
<FORMULACION EXTERNA>
REGLA GP-R41
<SI HABILIDAD-RIESGO ES Existe Y RIESGOS-ALTERNATIVA ES Etapas anteriores
REGLA GP-R42
<SI HABILIDAD-RIESGO ES Existe Y TERMINACION-PROYECTOS ES Prematura
REGLA GP-R43
REGLA GP-R44
REGLA GP-R51
<SI NIVEL-RIESGO ES Alto
REGLA GP-R52
REGLA GP-R43
REGLA GP-R44


REGLA GP-R53
<SI NECESIDAD-METOD ES Poco probada Y FACTIB-METOD ES Poco probada
ENTONCES CONVENIENCIA-METOD ES Poco probada>
REGLA GP-R54
<SI FORMALIDAD ES Medianamente Y CONVENIENCIA-METOD ES Poco probada
REGLA GP-R56
REGLA GP-R45
REGLA R2
REGLA R15
REGLA R2
REGLA ER-R4
REGLA R15
REGLA R2

REGLA R24
REGLA R26
CV-PROPU-GESTION ES Espiral ENTONCES CV-PROPU-PROYECTO ES Espiral>
REGLA R24
REGLA R26
----------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------

9.5 RESULTADOS DE LA EVALUACIN DEL SISTEMA EXPERTO
El sistema implementado se prob con cuatro grupos de usuarios: los

expertos que participaron en el desarrollo del sistema; profesionales que se
dedican al desarrollo de proyectos de software; docentes que ensean el tema en
ctedras universitarias; y alumnos que usaran el sistema para la aplicacin
prctica de los conceptos de ciclo de vida. Se solicit a cada grupo que analizara
el sistema desde los siguientes aspectos:
Correccin: existencia de elementos redundantes, incompletos o
inconsistentes.
Validez: la capacidad del sistema de tratar los casos y el cumplimiento
de los requisitos.
Usabilidad: la amigabilidad del sistema para ser operado, el grado de
facilidad de aprendizaje para operar el sistema.
Utilidad: este aspecto tiene que ver con los beneficios que aporta el
sistema para la organizacin o institucin que lo aplicar respecto de
no hacerlo.

1. Expertos que participaron en el desarrollo del sistema:

Correccin: no encontraron elementos redundantes, incompletos o
inconsistentes.
Validez: permitieron corregir algunos errores de codificacin que afectaban
al razonamiento del sistema. Particularmente los casos 4 y 5.
Usabilidad: se redefini alguna funcionalidad en el diseo de pantallas
previsto originalmente
Utilidad: participaron del proyecto porque estaban interesados desde el
aspecto profesional para contrastar sus apreciaciones del proyecto en la
seleccin del ciclo de vida, lo que se consider como una mejora en la
calidad y tiempos de trabajo en el desarrollo de sistemas informticos. En su
faceta docente para mejorar la explicacin del tema ciclos de vida con la
posibilidad de una aplicacin prctica concreta, lo que consideran una
mejora en la calidad de las clases y por ende para la imagen de la institucin
educativa.
2. Profesionales que se dedican al desarrollo de proyectos de software:

inconsistentes.
al razonamiento del sistema. Particularmente los casos 5 y 9.
Usabilidad: se redefini alguna funcionalidad en el diseo de pantallas
previsto originalmente
Utilidad: opinaron que el sistema les facilitaba recordar aspectos a analizar
del proyecto, que en algunos casos se les pasaban por alto, y contrastar sus
apreciaciones desde su propia experiencia con la propuesta del sistema
para la seleccin del ciclo de vida. Se lo consider como una mejora de
recursos en tiempos, personal entrenado y calidad de resultados por la toma
ms adecuada de decisiones tempranas.
3. Docentes que ensean el tema en ctedras universitarias:

inconsistentes.
al razonamiento del sistema. Particularmente los casos 4, 5 y 9.
Usabilidad: permiti redefinir con mayor precisin, algunas de las preguntas
de las reas a evaluar.
Utilidad: encontraron que el sistema facilitaba y lograba encontrar mayor
especificidad para el tema ciclos de vida y desarrollo de proyectos. Permite
ejercitacin prctica concreta, pudiendo aprovechar mejor los casos reales
de trabajo en la definicin de casos de prctica. Consideraron una mejora
significativa en la comprensin del tema y en la preparacin de clases ms
interesantes para los alumnos.

4. Alumnos que usaran el sistema para la aplicacin prctica de los

conceptos de ciclo de vida:
inconsistentes.
Validez: no encontraron errores que afectaran al razonamiento del sistema.
Usabilidad: permiti redefinir con mayor precisin, algunas de las preguntas
y opciones de las reas a evaluar.
Utilidad: consideraron una mejora significativa la posibilidad de realizar
prctica para la mejor la comprensin del tema y para que las clases fueran
ms motivadoras e interesantes. Consideraron de mejor calidad la
preparacin del tema ya que la teora les resulta en general mas aburrida y
tenan que estudiar de memoria en lugar de comprender el tema. Adems
les permiti relacionar y comprender mejor la utilidad de una metodologa de
trabajo en la actividad profesional. Tambin valoraron mejor el nivel del
docente. Algunos pudieron armar casos de prctica en relacin a alguna
experiencia laboral previa que tenan y contrastar lo que el sistema propona
con lo que haban hecho.
El resultado de la evaluacin se consider altamente satisfactorio, por el

experto principal y por el Ingeniero en conocimiento.

Captulo 10
Conclusiones y
Futuras Lneas de
Investigacin
El desarrollo de la tesis de magster ha permitido profundizar los temas y las

tcnicas estudiadas durante el curso de Magster. Este captulo considera tres
aspectos importantes en relacin al trabajo realizado y a su continuidad. En la
primera parte de Conclusiones se detallarn los aportes originales que el trabajo
de tesis ha generado en el dominio de conocimiento de la Seleccin del Modelo de
Ciclo de Vida ms adecuado. En la segunda parte se mencionan aspectos y lneas
de investigacin que se pueden considerar para ampliar el presente desarrollo. En
la tercera parte se mencionan temas de investigacin complementarios.
10.1. CONCLUSIONES DEL TRABAJO
Constituyen aportes originales del presente trabajo:
Una primer estructuracin del conocimiento asociado al proceso de

seleccin de un modelo de Ciclo de Vida, en tres reas de anlisis,
Definicin de los Requerimientos, Tipo de Aplicacin y Gestin del
Proyecto.
La identificacin y sntesis de las variables de anlisis asociadas a cada

una de las reas definidas que definen la informacin requerida para
proponer el Modelo del Ciclo.
El desarrollo de un sistema decisorio sobre la base de los escenarios

identificados.
La modularidad del sistema de escenarios que permite la extensin de la

seleccin a otros modelos de ciclos de vida.
La modularidad de identificacin de reas que permite la extensin,

agregado o subdivisin de otras reas de anlisis.
La modularidad de identificacin de las variables que permite la

extensin de valores posibles para cada una de ellas.
Aplicacin y adaptacin para este caso en particular de la tcnica

Mtodo Delphi para adquirir informacin del grupo de expertos.
Desarrollo de una herramienta de software que asista al Ingeniero de

Software en el procesos de:
Analizar las variables y las opciones para cada una de ellas que
identifican un proyecto de desarrollo de sistemas.
CONCLUSIONES Y FUTURAS LINEAS DE INVESTIGACION 02/09/2003 Bibiana D. Rossi 395

Seleccionar el modelo de ciclo de vida ms adecuado para cada

rea de anlisis.
Seleccionar el modelo de ciclo de vida ms adecuado para el

proyecto.
Explicar el modelo de razonamiento aplicado para la seleccin

sugerida. No se usa la opcin del Kappa PC, ya que no resultaba
fcil de comprender por usuarios no entrenados, por lo tanto se
program en la herramienta que junto con la solucin sugerida se
identificaran todas las reglas que fueron usadas en el razonamiento
para obtener ese resultado.
Facilitar la congruencia en el proceso de decisin del modelo de

ciclo de vida ms adecuado, entre distintos proyectos de desarrollo
de sistemas de una misma organizacin y entre distintos equipos de
desarrollo de una misma organizacin.
Desarrollo de un modelo de estructuracin del conocimiento y de una

herramienta de software que asista a los docentes en la explicacin y
prctica del tema en las ctedras universitarias.
10.2. LINEAS DE INVESTIGACIN Y DESARROLLO
A partir de los resultados obtenidos pueden plantearse las siguientes lneas

de trabajo:
Extender la lista de modelos de ciclo de vida seleccionables con otros

modelos de Ciclo de vida: Prototipos, Proceso Unificado, Emisin
Gradual, cualquier otro modelo que se desee incluir.
Extender, o redefinir los escenarios ya identificados incorporando

variables para determinar las caractersticas del proyecto considerando
tcnicas como COCOMO, Puntos de Funcin, Marcos de Sistemas
propuestos por Jackson, [Jackson, M. 1995], [Jackson, M. a 1999],
[Jackson, M. b 1999].
Completar el modelo de estructuracin del conocimiento que define los

criterios de seleccin de ciclo de vida ms adecuado para un proyecto
software dado.

En el actual modelo desarrollado se han relacionado en el

razonamiento, las variables de cada una de las reas entre s. Puede
extenderse el razonamiento del modelo incorporando la incidencia de
las relaciones, de las variables de las reas entre el conjunto de reas
definidas.
Determinar el aporte que la Ingeniera del Conocimiento puede realizar

al proceso de automatizar la seleccin del modelo de ciclo de vida de
software, considerando especialmente que el modelo debe ser
evolutivo y, por lo tanto, debe permitir una actualizacin continua, que
es una propiedad caracterstica de los sistemas basados en
conocimiento.
10.3. LINEAS DE INVESTIGACIN COMPLEMENTARIAS
A partir de dificultades que se presentaron al resolver el trabajo de tesis, se

han considerado algunos temas complementarios como Lneas de Investigacin Y
Desarrollo para trabajos de Final de materias, de Especialidad o Tesis de Grado.
Software que facilite el clculo de la Viabilidad del proyecto, cuando se

aplica el Test de Viabilidad propuesto en la bibliografa de referencia
[Gmez, A. y otros 1997].
Software para clculo de las matrices y grficos de la tcnica de

Emparrillado, con opcin para usar distintas frmulas de distancia,
rangos de evaluacin, metodologas y lenguajes de programacin. Las
experiencias que se han realizado son:
Describe en detalle el proceso de clculo de la parrilla y algunas

dificultades encontradas durante el desarrollo del trabajo, que estn
pendientes de ser completadas por versiones posteriores. El software
slo permite usar la frmula de distancia lineal, calcula las matrices,
permitiendo usar rangos de valoracin entre 1 y 50 y realiza los
grficos. En este trabajo se han presentado varios casos resueltos
por la herramienta. Se ha utilizado una metodologa orientada a los
datos y est programado en Visual Basic.
Estado: Tesis de Grado presentada. Licenciatura en Sistemas de
Informacin. Universidad Nacional de Lujn. 2000. Tesista: Lic.
Enrique Fernndez, Directora: Lic. Bibiana Rossi.

El software permite usar la frmula de distancia lineal, calcula las

matrices permitiendo usar rangos de valoracin entre 1 y 999 y
realiza los grficos. Se ha desarrollado siguiendo la metodologa
Orientada a objetos Proceso Unificado y Notacin UML, se utilizo
para la documentacin la herramienta CASE Rational Rose y se
program en Microsoft Java.
Estado: Trabajo final presentado. Materia Programacin Orientada a
Objetos. Licenciatura en Sistemas de Informacin. Universidad
Nacional de Lujn. 2001. Alumno A.S. Marcelo Castro, Directora: Lic.
Bibiana Rossi.
El software permite usar distintas frmulas de distancia, calcula las

matrices permitiendo usar rangos de valoracin entre 1 y 999 y
realiza los grficos. Se ha desarrolla siguiendo la metodologa
Orientada a Objetos Proceso Unificado y Notacin UML. An no se
ha decidido el lenguaje de programacin a usar.
Estado: Tesis de Grado en curso. presentada. Universidad de
Buenos Aires, Facultad de Ingeniera. 2001. Tesista: Sr. Emiliano
Castaeda, Directora: Lic. Bibiana Rossi.

Captulo 11
Bibliografa
En este capitulo se detalla la bibliografa usada en el presente trabajo y las

abreviaturas.
11. 1 REFERENCIAS BIBLIOGRAFICAS
Behm, B.W., Software Engineering Economics. Prentice-Hall, Englewood Clifs.

Nueva Jersey, 1981.
Behm, B.W., A Spiral Model of Software Development and Enhancement.

Software Engineering Project Management, IEEE Computer
Society, pp 128-142, 1987.
Booch, G., Anlisis y Diseo Orientado a Objetos con Aplicaciones. Addison-

Wesley, Wilmington, Delaware, 1996.
Booch, G., Rumbaugh, J. y Jacobson, I.: El Lenguaje Unificado de Modelado.

Addison Wesley, 1999.
Burch, J.G. y Grudnitski, G., Diseo de Sistemas de Informacin. Editorial

Limusa, Noriega editores, Megabyte. 1994.
Charette, R.N., Building Bridges over Intelligent Rivers. American Programmer,

vol. 5, N 7, pp 2-9, 1992.
Chen, P.S., The Entity-Relationship Model: Toward a Unifying View of Dat.

TODS, 1. 9-36.1976.
Gmez, A., Juristo, N., Montes, C., Pazos, J. Ingeniera del Conocimiento.
Centro de Estudios Ramn Areces. S.A., Madrid, 1997
Hawryszkiewycz, I.T., Introduccin al Anlisis y Diseo de Sistemas con ejemplos

prcticos. Anaya, Madrid, 1990.
IEEE, Standard for Developing Software Life Cycle Processes. IEEE Std|. 1074-
1991, Nueva York, IEEE Computer Society, 1991.
Ierache, J.S., Mtricas en sistemas orientados a objetos. Cuaderno de reportes

tcnicos. CAPIS, Instituto Tecnolgico de Buenos Aires,
Argentina, 1999.
BIBLIOGRAFIA 02/09/2003 Bibiana D. Rossi 401

ISO, ISO/IEC 12701-1 Software life-cycle process, 1994.
Jackson, M., Software Requirement & Specification. ACM Press, Addison-

Wesley, 1995.
Jackson, M. a, Problem Analysis Using Small Problem Frames, South African

Computer Journal 22; Special Issue on WOFACS98, pp 47-60,
1999.
Jackson, M. b, Problem Analysis and Structure, Keynote Talk at ITG/SEV

Symposium. Zrich, 29 september 1999.
Jacobson, I. et al., Object Oriented Software Engineering. A Use Case Driven

Approach. ACM Press, Addison-Wesley, Workingham 1992.
Jacobson, I., Booch, G., Rumbaugh, J., The Unified Software Development
Process . Addison-Wesley, 1999.
Juristo Juzgado, N. a, Introduccin a la Ingeniera de software. Mster en

Ingeniera del Software e Ingeniera del Conocimiento, unidad 1,
Madrid, 1996.
Juristo Juzgado, N. b, Proceso de Construccin de Software y Ciclos de vida.

Mster en Ingeniera del Software e Ingeniera del Conocimiento,
unidad 2, Madrid, 1996.
Macro, A.. Software Engineering concepts and management. Prentice-Hall,

Nueva York, 1990.
Martin, J. y Odell, J., Anlisis y Diseo Orientado a Objetos. Prentice-Hall. 1994.
Paulk, M. et al., "Capability Maturity Model for Software", Software Engineering

Institute, Carnegie Mellon University, Pittsburgh, PA, 1993.
Piattini, M.G. y Daryanani, S.N., Elementos y Herramientas en el Desarrollo de

Sistemas de Informacin. Ra-ma 1995.
Piattini, M.G., Calvo-Manzano, J., Cervera, J. y Fernndez, L., Anlisis y Diseo

detallado de Aplicaciones Informticas de Gestin. Rama,
Madrid, 1996.

Pressman, R.S., Ingeniera del Software Un Enfoque Prctico, Mc Graw Hill,

Madrid, 1997
Rincn, A., Plgaro, J., Diccionario conceptual de Informtica y Comunicaciones.

Paraninfo, Madrid, 1998
Rossi, B., Britos, P., Garca Martnez, R., Modelado de Objetos. Revista N 21
del Intituto Tecnolgico de Buenos Aires, Argentina, 1998.
Royce, W.W., Managing the development of large Software Systems: concepts

and Techniques. Proceedings, Wescon, 1970.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. y Lorensen, W., Modelado y
Diseo Orientado a Objetos. Prentice Hall, Espaa. 1996.
Whitten Jeffrey L., Bentley Lonnie D. y Barlow Victor M.: Anlisis y Diseo de
Sistemas de Informacin, 3era. edicin. Editorial IRWIN. Madrid,
1996.
11.2 ABREVIATURAS
CASE: Computer Aided Software Engineering

CV: Ciclo de Vida
DFD: Diagrama de Flujo de Datos
HW: Hardware
IC: Ingeniero del Conocimiento
INCO: Ingeniera del Conocimiento
IS: Ingeniera del Software
OO : Orientacin a Objetos
OOSE: Object Oriented Software Engineering
SE: Sistema Experto
SEI: Software Engineering Institute
SW: Software
UML: Unified Modelling Language Lenguaje Unificado de Modelado

Captulo 12
Anexos
En este captulo se detallan los anexos. En primer lugar se presentan los

anexos del captulo 3, Definicin del problema: el control de configuracin. En
segundo lugar se presentan los anexos del captulo 5, Adquisicin de Conocimientos:
las sesiones de entrevista realizadas al experto y las sesiones de extraccin de
conocimientos realizadas sobre el anlisis de la bibliografa del dominio de aplicacin
del presente trabajo.
12.1 ANEXOS DEL CAPITULO 3: CONTROL DE CONFIGURACIN
Las actividades de Gestin de Configuracin para este proyecto son:

Identificacin de la Configuracin
Control de la Configuracin
Generacin de Informes de Estado
Identificacin de la Configuracin:
Nombre elegido para la aplicacin: SECV
Objetivo de la Aplicacin: Asistir al lder de un proyecto de desarrollo de

Software en la seleccin del modelo de ciclo de vida mas apropiado segn las
caractersticas particulares de ese proyecto.
Ciclo de vida del Software: Modelo Troncocnico
Fases del Ciclo de vida: se enumeran las fases para este proyecto y se
determinan los productos que se espera obtener al final de cada una de ellas.
1. Identificacin de la tarea
Documento que describe el objetivo, alcance, mbito, y metodologa a
aplicar en el desarrollo del SECV.
Plan de actividades.
Estudio de Viabilidad del proyecto.
Estos productos servirn de base para la redaccin del captulo 3 y 4 del

presente trabajo de tesis.
2. Desarrollo de prototipos
Trascripcin de las Entrevistas con el Experto
Tablas de Ventajas / Desventajas de los Modelos de Ciclos de vida
Cuestionario Mtodo Delphi sesin I
Resultados Mtodo Delphi, sesin I
Cuestionario Mtodo Delphi sesin II
Resultados Mtodo Delphi, sesin II
Cuestionario Mtodo Delphi sesin III
ANEXO 12.1: CAPITULO 3 02/09/2003 Bibiana D. Rossi 407

Resultados Mtodo Delphi, sesin III

Glosario de trminos
Tabla de Concepto-Atributo-Valor
Diagrama Relacional de Conceptos
Determinacin y Resultados del Emparrillado
Diccionario de Conceptos
Modelo de conocimientos estratgicos
Modelo de conocimientos tcticos seudorreglas
Modelo de conocimientos fcticos
Casos de prueba
Modelo Dinmico
Mapa de Conocimientos
Definicin de Marcos
Definicin de Procedimientos
Definicin de Reglas de Produccin
Codificacin de Marcos, Procedimientos y Reglas en Kappa PC
Estos productos servirn de base para la redaccin del captulo 5, 6 y 7 del

3. Ejecucin de la Construccin del Sistema Integrado

Casos de prueba presentados por el experto
Sistema funcionando en Kappa PC
Informe final del resultado de la prueba del sistema
Manual de usuario del sistema
Estos productos servirn de base para la redaccin del captulo 8 y 9 del

4. Actuacin para conseguir el mantenimiento perfectivo

Nuevas versiones de documentos ya presentados en etapas anteriores con
actualizaciones.
Nuevas versiones de la aplicacin
5. Lograr una adecuada transferencia tecnolgica

Material de capacitacin en el uso del sistema, casos de ejemplo
6. Preparacin de la Tesis de Magster

Documento de tesis para evaluar
Correcciones del documento de tesis
Documento final de la tesis
Versin definitiva de la aplicacin a los efectos del trabajo de tesis.

Lneas Bases establecidas:
A los efectos del presente trabajo se ha realizado una simplificacin tanto de las
lneas base como de los elementos de configuracin definidos. En este caso el
criterio adoptado es, que dado que es una sola persona, el tesista, quien realiza la
documentacin del proyecto y la programacin se ha definido una sola lnea base
para todo el proceso de Desarrollo y Programacin y una lnea base para el
Mantenimiento Perfectivo.
1. Lnea Base Desarrollo, Codificacin y Evaluacin: comprende las fases

Identificacin de la tarea,
Desarrollo de prototipos,
Ejecucin de la Construccin del Sistema Integrado,
Lograr una adecuada transferencia tecnolgica y
Preparacin de la Tesis de Magster
Los Elementos de configuracin que comprende son todos los productos

obtenidos en las fases mencionadas.
2. Lnea Base Mantenimiento Perfectivo: comprende la fase de

Actuacin para conseguir el mantenimiento perfectivo
Los Elementos de configuracin que comprende son todos los productos

obtenidos en la fase mencionada.
Nomenclatura de los elementos del Producto:
Todos los nombres de los elementos que componen el Producto, se encuentran

sujetos a la nomenclatura que se detalla a continuacin:
Caracteres 1-2: Valor fijo CV, que identifica al Producto Sistema Experto para la
seleccin del Ciclo de Vida
Caracteres 3: Identifica a la lnea base. Sus valores posibles son

DCE: Desarrollo, Codificacin y Evaluacin
MP: Mantenimiento Perfectivo
Caracteres 4-7: Identificacin numrica del elemento
Carcter 8: Identificacin de la versin del elemento

Control de Configuracin:
Se implementa el siguiente mecanismo para el control de cambios:
Generacin de una solicitud de cambio
Ante el requerimiento de un cambio funcional o un reporte de error, se completa la

correspondiente solicitud.
Ingreso de la solicitud a la Base de Datos de cambios
Una vez recibida la solicitud de cambio, se la ingresa en la Base de Datos de

cambios.
Anlisis de la solicitud de cambio
Cada solicitud de cambio debe ser analizada por el Ingeniero en Conocimiento,

conjuntamente con el Comit de Control de Cambios, y decidir si se rechaza o se
acepta el cambio. La decisin tomada por el Comit queda registrada en la Base
de Datos de Cambios.
Evaluacin de la solicitud de cambio
Si se decide la aceptacin de la solicitud de cambio, el Ingeniero en Conocimiento,

debe realizar la evaluacin tcnica de la misma, emitiendo un informe en donde se
exprese el esfuerzo requerido para satisfacer el pedido, las repercusiones que
dicho cambio genera en otros elementos y el costo estimado. La evaluacin
realizada, queda registrada en la Base de Datos de Cambios.
Generacin de la orden de cambio
El informe generado durante la evaluacin de la solicitud de cambio, se somete al

anlisis del Comit de Control de Cambios, el cual le asigna la prioridad y los
recursos necesarios. Se emite una Orden de Cambio
Realizacin del cambio
Se realiza el cambio. Seguimiento y control de la modificacin
Prueba e implementacin del cambio
Se certifica que el cambio funciona correctamente y se procede a su

implementacin, a travs de la modificacin de manuales y documentos que
deban reflejar el cambio.

Generacin de Informes de Estado:
Registro de solicitudes de cambio
Consultora BIROSSI Nro. Solicitud:.

Solicitud de cambios
Producto : SECV
Fecha: dd/mm/aaaa
Responsable del Pedido:
Area / Sector / Empresa :
Recibido por: Fecha: dd/mm/aaaa
Analizado por: Fecha: dd/mm/aaaa
ACEPTADO / RECHAZADO
Descripcin del cambio solicitado

________________________________________________________________
________________________________________________________________
________________________________________________________________
____________________________________________________
Solucin Propuesta
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
_________________________________________________
Elementos del Producto afectados por el cambio
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
_________________________________________________Documentacin
anexa
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
_________________________________________________
Hoja : 1


Solicitud de cambios
Estimacin del cambio

Solucin Propuesta por el equipo tcnico
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
______________________________________________________
Tiempo evaluado en horas / hombre por perfil:
Perfil Estimacin en Horas

Ing. Conocimiento
Programador
.
.
Costo del cambio:
Perfil Estimacin en Costo x hora Costo total

Horas
Ing. Conocimiento
Programador
.
.
TOTAL
Cronograma de desarrollo e implementacin:

_____________________________________________________________________
__________________________________________________________________
__________________________________________________________________
______________________________________________________
Plan de Pruebas:
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
______________________________________________________
Hoja : 2

Orden de cambio

Orden de cambio
Producto : SECV Fecha: dd/mm/aaaa

Responsable del Pedido:
Recibido por: Fecha: dd/mm/aaaa
Analizado por:.. Fecha: dd/mm/aaaa
Descripcin del cambio Solicitado

__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
________________________________________________
Solucin a implementar
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
___________________________________________________
Elementos del Producto afectados por el cambio
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
________________________________________________
Hoja : 1


Orden de cambio
Documentacin anexa
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
___________________________________________________
Estimacin del cambio

Tiempo evaluado en horas / hombre por perfil:
Perfil Estimacin en Horas Nombre Funcionario

Ing. Conocimiento
Programador
.
.
Responsable del cambio:

Comentarios:
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
______________________________________________________
Fecha de entrega:
Hoja : 2

Registro en la Base de Datos de Cambios
Consultora BIROSSI
Registro de Cambios
Producto : SECV
Solicitud Nmero : ..
Responsable del Pedido : ...
Recibido por : ..
Fecha de recepcin : dd/mm/aaaa
Descripcin breve : ______________________________________
Analizado por : ..
Fecha del anlisis : dd/mm/aaaa
Decisin : (Aprobacin / Rechazo)
Comentarios : _____________________________________
_______________________________________________________________
Prioridad asignada :
Estado actual del pedido :
Fecha de terminacin : dd/mm/aaaa

Funcionarios involucrados : _____________________________________
Hoja : 1

Registro de Instalaciones
Consultora BIROSSI
Registro de Instalaciones
Producto : SECV
Solicitud Nmero : ..
Descripcin breve : ______________________________________
Responsable : .
Fecha de terminacin : dd/mm/aaaa
Lugar de instalacin : ..
Fecha de instalacin : dd/mm/aaaa
Versin instalada : ..
Hoja : 1

Informe de Estado de los cambios
Consultora BIROSSI Fecha: dd/mm/aaaa
Informe de Estado de los Cambios
Producto: SECV
Desde Fecha: dd/mm/aaaa Hasta Fecha: dd/mm/aaaa
Solicitud Fecha Descripcin Prioridad Estado

Nmero Recep. Actual
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
. dd/mm/aaaa .. .
Hoja : 1

Informe de Instalaciones
Consultora BIROSSI Fecha: dd/mm/aaaa
Informe de Instalaciones
Producto: SECV
Desde Fecha: dd/mm/aaaa Hasta Fecha: dd/mm/aaaa
Descripcin Instalado
Lugar Fecha Versin
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
. dd/mm/aaaa
Hoja : 1

12.2 ANEXOS DEL CAPITULO 5: SESIONES DE ADQUISICIN DE

CONOCIMIENTOS
El grupo de sesiones identificadas con A.x se corresponde con las entrevistas

realizadas al experto.
El grupo de sesiones identificadas con B.x se corresponde con las sesiones de

extraccin de conocimiento, particularmente del anlisis de la bibliografa.
A.1 SESION I
A.1.1 Preparacin de la Sesin I

Informacin a tratar: Primera aproximacin a la tarea y a su problemtica.
Establecer mbito, alcances y objetivo del sistema experto a desarrollar.
Amplitud y Profundidad: Establecer el mbito general de desarrollo de la tarea
sin detallar ningn caso especfico.
Tcnica utilizada: Entrevista no estructurada.
En qu momento del desarrollo de un sistema de informacin se
selecciona el ciclo de vida del proyecto?
Quin lleva a cabo la tarea?
Qu dificultades tiene la tarea?
En qu aspecto servira de apoyo el sistema experto?
A.1.2 Realizacin de la Sesin I

entrevista y el tipo de preguntas que se van a realizar y que se tomar nota de
sus respuestas. El entrevistado se muestra muy dispuesto. Se desarrolla la sesin
de la entrevista.
A.1.3 Trascripcin de la Sesin I

Entrevista realizada el 20 de octubre de 1999
Tiempo: 14 a 15.30 hs.
Objetivos: Establecer alcances y objetivos del proyecto
IC. Cules son las primeras actividades a llevar a cabo, en trminos generales en el
desarrollo de un proyecto informtico?
E. Si se trabaja con criterios metodolgicos las primeras fases son la Definicin de los
Requerimientos y la Planificacin o calendarizacin del proyecto y el Anlisis del sistema
actual y/o futuro.

IC. En qu fase se incluye la actividad de la seleccin del ciclo de vida ms adecuado

para el proyecto?
E. Esto puede variar segn el criterio del lder a cargo del proyecto, puede ser un tpico
en la especificacin de los requerimientos, o puede incluirlo como una de las primeras
actividades del Anlisis del Sistema. Lo que es cierto es que no es conveniente iniciar el
anlisis del sistema sin haber definido el modelo de ciclo de vida a utilizar. Yo dira que
como momento ms tardo debe ser la primer actividad de la fase de anlisis. En mi caso
particular suelo hacerlo antes de calendarizar el proyecto ya que me facilita
considerablemente el armado del plan.
IC. Existe algn tipo de dificultad en la actividad de seleccin del ciclo de vida?
E. Unas cuantas, y podra decir que hay dificultades propias de la tarea de seleccin y
dificultades que son particulares cuando es necesario ensear este tema a los
estudiantes de informtica en la universidad.
IC. En qu consisten las dificultades propias de la tarea de seleccin?

E. Intentar puntualizar las ms conflictivas:
Existen diversos modelos de ciclo de vida entre los que realizar la seleccin:
cascada, prototipado de usar y tirar, incremental, emisin gradual, mejora iterativa,
ensamblaje de componentes, espiral, prototipado operativo, prototipado rpido, etc.
No existe un modelo de ciclo de vida que funcione para cualquier proyecto. Desde
la presentacin del ciclo de vida en cascada hasta el presente se han presentado
un promedio de 30 ciclos de vida posibles, que yo conozco, para llevar adelante un
proyecto. Esto implica conocerlos, reconocer cuales son los aplicables y tenerlos
presentes en el momento de la seleccin.
Es necesario tener en cuenta un con amplio conjunto de variables que representan
las caractersticas particulares del proyecto. El anlisis de estas variables se
complica, ya que se determinan con relacin a las ventajas y desventajas de
aplicacin de los distintos ciclos de vida y en relacin con el proyecto en particular.
Este proceso de que variables considerar es un proceso fuertemente relacionado
con la experiencia personal del lder de proyecto. Un lder de proyecto que se inicia
carece de experiencia suficiente para conocer todos los ciclos de vida posibles y
mucho ms aun cules son los aspectos del proyecto que debe considerar. Y la
nica manera de adquirir esa experiencia es haciendo selecciones, con la cascada
de errores que implica en el desarrollo de un sistema las equivocaciones iniciales.
La actividad se realiza al inicio del proyecto. Suponiendo que el lder de proyecto
tenga la suficiente experiencia para conocer al menos 10 ciclos de vida y que pueda
definir las variables a considerar, es probable que no pueda cuantificarlas
apropiadamente porque al inicio del proyecto muchas de ellas son solo
estimaciones. Con el avance del proyecto se puede recin tener mas precisin
respecto de esas caractersticas.
IC. En qu consisten las dificultades al ensear el tema a los estudiantes?

E. En la bibliografa aparecen explicados con bastante claridad los ciclos de vida, pero en
cuanto a cuales son las caractersticas del proyecto a tener en cuenta, la bibliografa es
ambigua. Para explicarme con mayor claridad: en la bibliografa se menciona que es

necesario tener en cuenta las polticas de la empresa, la cultura de la organizacin, la

disponibilidad para correr riesgos, la volatilidad y comprensin de los requisitos, el
dominio de aplicacin, la complejidad del proyecto, etctera. Es cierto que hay que tener
en cuenta todo esto pero as explicado es muy ambiguo, cmo se tiene en cuenta la
poltica de la empresa?, o qu se mide para saber la complejidad del proyecto? En este
tema el conocimiento no esta sistemticamente organizado y no se especifica cmo debe
realizarse el proceso de seleccin. Por esto, la tarea es muy difcil de explicar para los
alumnos y para un profesional sin experiencia.
IC. Quines son los encargados de seleccionar el ciclo de vida?

E. El lder de proyecto o quienquiera que cumpla esa funcin en el desarrollo de un
proyecto informtico.
IC. Cul puede ser entonces el apoyo que preste el sistema experto a desarrollar?
E. Entiendo que el mayor apoyo est en la especificacin del conjunto de variables que
representan las caractersticas particulares del proyecto de desarrollo, que es necesario
considerar para seleccionar el ciclo de vida.
IC. Quines utilizaran en su tarea el sistema experto a desarrollar?

E. Los que tengan la responsabilidad de liderar el desarrollo de sistemas informticos, o
sea los lderes de proyecto y los docentes de las ctedras de anlisis y diseo de
sistemas, por supuesto los alumnos que cursen esas materias para su prctica.
A.1.4 Anlisis de la Sesin I
Los conocimientos extrados de la sesin I se encuentran reflejados en el
captulo III, Definicin del problema y en el captulo IV, Estudio de Viabilidad.
Ubicacin de la tarea:
Las primeras fases son la Definicin de los Requerimientos y la
Planificacin o calendarizacin del proyecto y el Anlisis del sistema actual
y/o futuro.
No es conveniente iniciar el anlisis del sistema sin haber definido el
modelo de ciclo de vida a utilizar. Yo dira que como momento ms tardo
debe ser la primer actividad de la fase de anlisis. En mi caso particular
suelo hacerlo antes de calendarizar el proyecto ya que me facilita
considerablemente el armado del plan.
Dificultades:
Existen diversos modelos de ciclo de vida entre los que realizar la seleccin:
cascada, prototipado de usar y tirar, incremental, emisin gradual, mejora
iterativa, ensamblaje de componentes, espiral, prototipado operativo,
prototipado rpido, etc. No existe un modelo de ciclo de vida que funcione
para cualquier proyecto.

Es necesario tener en cuenta un con amplio conjunto de variables que

representan las caractersticas particulares del proyecto. El anlisis de estas
variables se complica, ya que se determinan con relacin a las ventajas y
desventajas de aplicacin de los distintos ciclos de vida y en relacin con el
proyecto en particular. Este proceso de qu variables considerar es un
proceso fuertemente relacionado con la experiencia personal del lder de
proyecto.
La actividad se realiza al inicio del proyecto, es probable que no sea posible
cuantificarlas apropiadamente porque al inicio del proyecto muchas de ellas
son slo estimaciones. Con el avance del proyecto se puede recin tener
mas precisin respecto de esas caractersticas.
En la bibliografa se menciona que es necesario tener en cuenta las
polticas de la empresa, la cultura de la organizacin, la disponibilidad para
correr riesgos, la volatilidad y comprensin de los requisitos, el dominio de
aplicacin, la complejidad del proyecto, etctera. En este tema el
conocimiento no est sistemticamente organizado y no se especifica cmo
debe realizarse el proceso de seleccin.
Apoyo del SE a desarrollar:

Entiendo que el mayor apoyo est en la especificacin del conjunto de
variables que representan las caractersticas particulares del proyecto de
desarrollo, que es necesario considerar para seleccionar el ciclo de vida.
Responsable de la tarea:
Los que tengan la responsabilidad de liderar el desarrollo de sistemas
informticos, o sea los lderes de proyecto y los docentes de las ctedras de
anlisis y diseo de sistemas, por supuesto los alumnos que cursen esas
materias para su prctica.

- Es posible establecer una jerarqua de importancia entre los ciclos de
vida?
- Cul puede ser un buen punto de partida para identificar las variables que
definen las caractersticas particulares de un proyecto de desarrollo?
- Qu material bibliogrfico recomienda para el proceso de extraccin de
conocimientos?
A.1.5 Evaluacin de la Sesin I

Si se han cumplido los objetivos ya que se obtuvo la informacin prevista,
sobre los objetivos, se determin en gran medida los alcances y mbito del

proyecto, como as tambin se obtuvo informacin para el estudio de

viabilidad.

S es necesario para:
- Definir el alcance del prototipo respecto de los ciclos de vida que incluir.
- Obtener orientacin respecto del material bibliogrfico ms conveniente
para el proceso de extraccin de conocimientos.
- Analizar cmo es ms conveniente encarar la dificultad que presenta la falta
de sistematizacin en el conocimiento respecto de las variables que
identifican las caractersticas de un proyecto.

No es posible establecer en este momento el nmero de sesiones necesarias,
hasta no tener mayor precisin sobre los alcances del sistema.
A.2 SESION II
A.2.1 Preparacin de la Sesin II

Informacin a tratar: Alcance del sistema experto a desarrollar. Caractersticas
que intervienen en el estudio de viabilidad del proyecto.
Amplitud y Profundidad: Precisar los alcances del sistema, analizar el grado
de las dificultades, precisar la informacin para completar el estudio de
viabilidad.
Tcnica utilizada: Entrevista estructurada.
Es posible establecer una jerarqua de importancia entre los ciclos de
vida?
Cul puede ser un buen punto de partida para identificar las variables que
definen las caractersticas particulares de un proyecto de desarrollo?
Qu material bibliogrfico recomienda para el proceso de extraccin de
conocimientos?
De los proyectos en los que ha participado, existe documentacin que
pueda ser utilizada para probar y evaluar el sistema?
Para seleccionar el CV es necesario utilizar el sentido comn?
Para seleccionar el CV se requiere un alto nivel de abstraccin?
Para realizar la seleccin del CV qu pasos intermedios es necesario
cumplir?
Es conveniente justificar el CV que se ha seleccionado?
El sistema debe buscar la solucin ptima?

A.2.2 Realizacin de la Sesin II

entrevista, las preguntas que se van a realizar y que se tomar nota de sus
respuestas. Se desarrolla la sesin de la entrevista.
A.2.3 Transcripcin de la Sesin II
Entrevista realizada el 26 de octubre de 1999

Tiempo: 17 a 18.30 hs.
Objetivos: a) Completar alcances y objetivos del proyecto
b) Identificacin de la viabilidad
IC. Usted ha mencionado que existe un promedio de 30 ciclos de vida, quizs algunos
ms. Es posible establecer una jerarqua de importancia?
E. Si es muy posible hacerlo ya que en varios casos muchos de ellos son similares en su
esencia bsica y se diferencian en alguna fase o en algn detalle. Si tuviera que
agruparlos genricamente de alguna forma, se puede decir que existen los modelos con
filosofa de cascada, los modelos con filosofa de prototipo, los modelos con filosofa de
orientacin a objetos y quizs algunos modelos menos usados como el modelo en
espiral.
IC. Cul le parece que puede ser un buen punto de partida para identificar las variables
que representan las caractersticas del proyecto que son necesarias conocer para
seleccionar el ciclo de vida?
E. Entiendo que un buen comienzo y casi dira imprescindible es partir de una anlisis de
la bibliografa existente para despus consensuar con la opinin y experiencia de otros
profesionales.
IC. A qu otros profesionales consultara?

E. A los docentes de las ctedras de anlisis y diseo, que trabajan en la empresa como
lideres de proyecto y adems tienen la dificultad de ensear el tema y a algunos
profesionales reconocidos con quien he trabajado en algunos proyectos de envergadura.
IC. Es posible contactarlos para invitarlos a participar y ver si es posible comprometerlos

para algunas entrevistas? Estoy pensando particularmente en entrevistas de tipo grupal
con ellos.
E. Por supuesto, yo me pondr en contacto para avisarles del proyecto y cuando
acordemos les aviso de la entrevista.
IC. Qu material bibliogrfico recomienda para el proceso de extraccin de

conocimientos?
E. El material que recomiendo es el siguiente:

A Spiral Model of Software Development and Enhancement Software Engineering

Project Management, de Behm,
Anlisis y Diseo Orientado a Objetos con Aplicaciones de Booch,
Estndares del IEEE y de ISO.
Anlisis y Diseo Orientado a Objetos de Martin y Odell.
Elementos y Herramientas en el Desarrollo de Sistemas de Informacin de Piattini
Anlisis y Diseo detallado de Aplicaciones Informticas de Gestin de Piattini
Ingeniera del Software Un Enfoque Prctico de Pressman
Modelado y Diseo Orientado a Objetos de Rumbaugh
IC. De los proyectos en los que ha participado, existe documentacin que pueda ser
utilizada para probar y evaluar el sistema?
E. Si es posible utilizar la documentacin existente como as tambin los prcticos ya
preparados por los docentes de las ctedras de anlisis y diseo de sistemas.
IC. Para seleccionar el CV es necesario utilizar el sentido comn?

E. S por sentido comn se entiende experiencia, la experiencia si es necesaria. En
realidad se requiere de experiencia previa tanto para reconocer qu variables es
necesario analizar como as tambin para estimar aquellas que puedan ser relativamente
inciertas al inicio de un proyecto, pero que es necesario tenerlas en cuenta para la
seleccin del ciclo de vida.
IC. Para seleccionar el CV se requiere un alto nivel de abstraccin?

E. No mucho, es necesario tener presentes las caractersticas a evaluar en trminos
generales, y precisar su valor. Es posible que sea necesario reconocer alguna
caracterstica particular de algn proyecto que no se haya evaluado previamente. O
incorporar a la evaluacin presente alguna caracterstica que haya resultado importante
en proyectos previos. Justamente por eso es importante la experiencia.
IC. Para realizar la seleccin del CV qu pasos intermedios es necesario cumplir?

E. a) Tener claros los requerimientos y el objetivo del proyecto
b) Conocer la lista de variables que caracterizan el problema
c) Analizar si es necesario agregar alguna variable nueva
d) Asignarle un valor a las variables de acuerdo al proyecto a desarrollar
e) Analizar cual es el ciclo de vida que responde mas adecuadamente a las
caractersticas del proyecto.
IC. Es conveniente justificar el CV que se ha seleccionado?

E. Es muy necesario no solo para justificar la seleccin del proyecto presente en
desarrollo sino tambin para contar con mecanismos que permitan a posteriori la revisin
de los criterios de seleccin, sobre todo en aquellos casos donde la eleccin no result
acertada.
IC. El sistema debe buscar la solucin ptima?

E. No existe una solucin optima, siempre es necesario una solucin de compromiso. El
solo hecho de tener sistematizada el anlisis de las caractersticas del proyecto ya
optimiza considerablemente la forma actual en la que se realiza la seleccin.

A.2.4 Anlisis de la Sesin II

Los conocimientos extrados de la sesin II se encuentran reflejados en el
captulo III, Definicin del problema y en el captulo IV, Estudio de Viabilidad.

- Revisar con el experto cada una de las dimensiones de plausibilidad,
justificacin, adecuacin y xito del Test de Viabilidad. El experto conoce
ampliamente de informtica as que es factible explicarle brevemente el
Test y repasar cada una de las caractersticas conjuntamente con l.
- Cul es la forma ms adecuada para el anlisis de la bibliografa?
A.2.5 Evaluacin de la Sesin II

Si se han cumplido, se determin los alcances y mbito del proyecto, como as
tambin se obtuvo informacin para el estudio de viabilidad.

S es necesario para:
- Revisar definitivamente las dimensiones del Test de Viabilidad.
- Obtener orientacin precisa de cmo realizar el proceso de extraccin de
conocimientos.

Es necesario establecer dos tipos de sesiones. Una serie de sesiones con el
experto y otro conjunto de sesiones con el grupo de expertos a quien desea
dar participacin el experto principal.
En cuanto a la serie de sesiones con el experto se estima una sesin para
completar la informacin para la viabilidad del proyecto y otra sesin para
preparar las entrevistas con el grupo.
En cuanto al grupo de expertos es necesario organizar la adquisicin de
conocimientos aplicando las tcnicas adecuadas para un equipo de expertos.
Despus de la segunda sesin prevista con el experto principal para preparar
la adquisicin de conocimientos con el grupo de expertos, ser posible estimar
el nmero de sesiones necesarias.
A.3 SESION III
A.3.1 Preparacin de la Sesin III
Informacin a tratar: Dimensiones del Test de Viabilidad. Extraccin de

conocimientos. Adquisicin de conocimientos con el grupo de expertos.

Amplitud y Profundidad: Necesarias para completar el Test de Viabilidad.
Tcnica utilizada: Entrevista estructurada para Test de Viabilidad y abierta

para proceso de extraccin de conocimientos y proceso de adquisicin de
conocimientos con el grupo de expertos.
Preparacin de Preguntas: Proponer la tcnica de Mtodo Delphi.

Revisar cada una de las caractersticas de las tablas de las dimensiones del
Test de Viabilidad.
Al analizar la bibliografa cules son los conceptos o trminos que es
necesario identificar?
A.3.2 Realizacin de la Sesin III

la hora de inicio y fin de la entrevista. Se le explica al experto los temas a tratar.
Se inicia la sesin con una breve explicacin del Test de Viabilidad.
A.3.3 Resumen de la Sesin III
Entrevista realizada el 31de octubre de 1999

Tiempo: 18 a 20 hs.
Objetivos: a) Identificacin de la viabilidad
b) Identificar los trminos para realizar un anlisis estructural de textos
c) Proponer el mtodo Delphi para adquisicin de conocimientos con grupo
de expertos.
IC. Breve explicacin del Test de Viabilidad. Revisin de cada una de las caractersticas
de las dimensiones de plausibilidad, justificacin, adecuacin y xito.
E. Revis y ratific los valores de las caractersticas del Test de Viabilidad.
IC. Al hacer la lectura y el anlisis de la bibliografa recomendada qu conceptos o

trminos es necesario identificar?
E. Las ventajas y desventajas de los ciclos de vida y los problemas o casos de ejemplo
que presentan.
IC. Breve explicacin del Mtodo Delphi. Colaborara en el diseo de los cuestionarios y
en el anlisis de los mismos?
E. Por supuesto. Me parece una excelente idea consensuar la opinin de los expertos, es
una forma clara y ordenada de hacerlo. Los primeros cuestionarios pueden basarse en el
anlisis que resulte en los textos de las ventajas y desventajas de cada ciclo de vida.

A.3.4 Anlisis de la Sesin III
Los conocimientos extrados de la sesin III se encuentran reflejados en el en
el captulo IV, Estudio de Viabilidad.
Actividades para continuar la adquisicin de conocimientos:

- Preparar las primeras cuestionarios para las sesiones de adquisicin de
conocimiento con el Mtodo Delphi.
A.3.5 Evaluacin de la Sesin III

Si se han cumplido, se determinaron las caractersticas del Test de Viabilidad.
Se defini el proceso para extraccin de conocimientos de la bibliografa y el
experto se comprometi a colaborar en las sesiones de adquisicin de
conocimientos con el grupo de expertos.

No parece necesario.

Se estima
1 sesin con el experto principal para la preparacin de los cuestionarios.
3 sesiones con el experto principal para realizar el anlisis y tabulacin de
los resultados.
3 sesiones con el experto principal para completar la fase inicial de

B.1 EXTRACCION DE CONOCIMIENTOS
B.1.1 Preparacin del Anlisis de textos

Informacin a tratar: Tipos de Ciclos de vida. Ventajas y desventajas de los
ciclos de vida. Casos de aplicacin.
Tcnica utilizada: Anlisis estructural de textos.
Trminos a buscar:
Conceptos: ciclo de vida, fases, etapas
Es una caracterstica de ...;
Es una ventaja de ..., es una desventaja de
Es un caso de aplicacin de...
B.1.2 Realizacin de las sesiones de extraccin de conocimientos

El IC realiz el anlisis de la bibliografa disponible tomando como base los textos
mencionados por el experto en la sesin II.
El anlisis de textos se realiz en 25 sesiones de 3 horas aproximadamente
durante un mes.
Se document el anlisis de textos en una matriz de cuatro columnas con el
siguiente diseo.
Titulo del grupo de CV

Modelo Ventajas Desventajas Casos de Ejemplo
Aaaa Ventaja 1 Desventaja 1 Descripcin
Ventaja 2 Desventaja 2
... ...
Bbbb Ventaja 1 Desventaja 1 Descripcin
... ...
Cccc Ventaja 1 Desventaja 1 Descripcin
... ...
El experto principal revis la documentacin en 4 momentos:

Al finalizar el primer anlisis de textos
Al finalizar los 4 primeros textos
Al finalizar los 8 primeros textos
Al dar por terminada la extraccin de conocimientos
B.1.3 Documentacin del anlisis realizado

Se adjunta a continuacin de la presente documentacin en el tem B 1.6, el
documento de trabajo: Modelos de Ciclos de Vida, en el que se sintetiz el
anlisis de textos.

B.1.4 Anlisis de la extraccin de conocimientos

Ventajas, desventajas y caractersticas de los modelos de ciclos de vida de
acuerdo con la bibliografa revisada.
No se han detectado en la bibliografa casos de ejemplo.

Identificar con mayor precisin las caractersticas particulares de los ciclos de
vida.
B.1.5 Evaluacin de las sesiones de extraccin de conocimientos

S se han cumplido, se realiz un anlisis de la bibliografa ms relevante
recomendada por el experto.
Se ha precisado el alcance del prototipo:
Se convino con el experto que para la realizacin de este primer prototipo
no es necesario continuar con el anlisis bibliogrfico.
Se ha convenido en virtud del la revisin realizada por el experto en
trabajar sobre los ciclos de vida en Cascada, Espiral y Orientado a objetos
para la realizacin de este primer prototipo.
Debe considerarse en el diseo la posibilidad de incorporar ms
conocimiento al sistema experto una vez que se haya desarrollado y est
en uso, tanto sea por la incorporacin de mas bibliografa estudiada como
as tambin por la incorporacin de ms modelos de ciclos de vida.

Es necesario refinar la informacin obtenida y consensuarla con el grupo de
expertos, siguiendo el procedimiento propuesto en el mtodo Delphi.

Se estima:
1 sesin con el experto principal para la preparacin de los cuestionarios.
3 sesiones con el experto principal para realizar el anlisis y tabulacin de
los resultados.
3 sesiones con el experto principal para completar la fase inicial de

B.1.6: RESULTADO DEL ANLISIS DE TEXTOS SISTEMA EXPERTO: SELECCIN DEL MODELO DE CICLO DE VIDA
B.1.6 : Resultado del Anlisis de textos
MODELOS DE CICLOS DE VIDA

Prototipado Rpido
Es un enfoque que intenta remediar algunos de las falencias del ciclo de vida (1)
Prototipo Evolutivo
El propsito del Prototipo Evolutivo es permitir al sistema evolucionar a medida que es usado.
El sistema es construido gradualmente.
Al principio se hace el suficiente desarrollo que permita al usuario llevar a cabo una o ms de las tareas en forma completa (1)
Prototipo de usar y tirar
Es usado con el propsito de obtener especificaciones y clarificaciones (1)
Una vez que ha servido su propsito es descartado (1)
Prototipado Incremental
Aqu el sistema es construido en forma incremental, una seccin por vez (1)
Combina elementos del modelo lineal (cascada) con la filosofa interactiva de los prototipos (5)
Cada secuencia lineal produce un incremento del software. (5)
El primer incremento a menudo es un producto esencial (ncleo).
El plan afronta la modificacin del producto central a fin de cumplir las necesidades del cliente y la entrega de las funciones y caractersticas
adicionales.
Este proceso se repite hasta que el producto esta completo (5)
Se centra en la entrega de un producto operacional en cada incremento (5)
El modelo incremental corrige la necesidad de una secuencia no lineal de pasos de desarrollo. En el modelo incremental se va creando el sistema
software aadiendo componentes funcionales al sistema llamado incremento. En cada paso sucesivo, se actualiza el sistema con nuevas
funcionalidades o requisitos, es decir, cada versin o refinamiento parte de una versin previa y le aade nuevas funciones.
El sistema software ya no se ve como una nica entidad monoltica con una fecha fija de entrega , sino como una integracin de resultados
sucesivos obtenidos despus de cada iteracin.
ANEXO 12.1: ADQUISICIN DE CONOCIMIENTOS 02/09/2003 Bibiana D. Rossi 431
Cascada (Waterfall) (2) (5)

Sugiere un enfoque sistemtico, secuencial del desarrollo del software. El numero de fases o etapas que se proponen en este ciclo de vida suele variar,
aunque suelen ser: anlisis de requisitos del sistema, anlisis de requisitos del software, diseo preliminar, diseo detallado, codificacin ,
pruebas, explotacin y mantenimiento.
Tiene las siguientes actividades (5) : Ingeniera y modelado de Sistemas / Informacin, Anlisis de los requisitos del software, Diseo,
Generacin del cdigo, Pruebas, Mantenimiento (5). Cada fase empieza cuando se ha terminado la fase anterior. Para pasar de una fase a otra es
necesario conseguir todos los objetivos de la etapa previa.
Modelo en espiral (2) (5)

Se centra en un grfico en espiral en el cual
- la dimensin radial representa el costo acumulado incurrido en lograr los pasos hasta la fecha
- la dimensin angular representa el progreso hecho en cada ciclo de la espiral
cada ciclo comienza con la identificacin de:
- los objetivos de la porcin del producto que se esta elaborando
- las restricciones impuestas sobre la aplicacin de alternativas (2)
el siguiente paso es evaluar las alternativas con respecto a los objetivos y las restricciones (2)
el siguiente paso involucra la formulacin de una estrategia para resolver las fuentes de riesgo (2)
el siguiente paso esta determinado por los riesgos remanentes. Si la performance o los riesgos de interfaces de usuario dominan el desarrollo
del programa entonces el siguiente paso podra ser desarrollo evolutivo. (2)
cada ciclo es completado con una revisin involucrando a la gente a la que le concierne el producto (2)
Segn Pressman el modelo tiene las siguientes regiones de tareas: (5) comunicacin con el cliente, planificacin, anlisis de riesgos, Ingeniera,
construccin y adaptacin, evaluacin del cliente
Metodologa OMT (Object Modeling Tool) (6)

Consta de varias fases:
- El anlisis se dedica a la comprensin y modelado de la aplicacin y del dominio en el cual funciona
- La arquitectura global del sistema se determina durante el Diseo del Sistema. Utilizando el modelo de objetos como gua, se organiza el
sistema en subsistemas
- Durante la fase de Diseo de Objetos, se elaboran los modelos de anlisis, se refinan, y despus se optimizan para producir un diseo prctico
Una aproximacin orientada a objetos:
- traslada gran parte del esfuerzo del desarrollo del software hacia la fase de anlisis del ciclo de vida
- centra su atencin en las estructuras de datos, y no en las funciones que haya que efectuar
El propsito del anlisis orientado a objetos es modelar el sistema del mundo real para que sea posible entenderlo
El diseo del sistema es la estrategia de alto nivel para resolver el problema y construir una solucin
Durante el diseo del sistema, se decide la estructura y el estilo global
Durante el diseo de objetos, se ejecuta la estrategia seleccionada durante el diseo del sistema, y se rellena los detalles
Los desarrollos experimentados son capaces de combinar varios pasos, o bien pueden llevar a acabo varios pasos en paralelo para ciertas partes
del proyecto
Modelos CV OO Booch (7)

Es iterativo en el sentido de que conlleva el refinamiento sucesivo de una arquitectura orientada a objetos, por la cual se aplica la experiencia y
resultados de cada versin a la siguiente iteracin del anlisis y el diseo. El proceso es incremental en el sentido de que cada pasado por un ciclo
anlisis/diseo/evolucin lleva a refinar gradualmente las decisiones estratgicas y tcticas, convergiendo en ultima instancia hacia una solucin
que se encuentra con los requerimientos reales del usuario final y que adems es simple fiable y adaptable.
Utiliza el diseo global circular que enfatiza el desarrollo incremental e iterativo de un sistema mediante el refinamiento de vistas lgicas y
fsicas diferentes, aunque consistentes del sistema como un todo. El diseo global circular es el fundamento del proceso del diseo orientado a
objetos.
Microproceso: esta compuesto por las siguientes actividades:
identificar las clases y objetos a un nivel de abstraccin dado
identificar las semnticas de estas clases y objetos
identificar las relaciones entre estas clases y objetos
especificar el interfaz y despus la implementacin de estas clases y objetos
Macroproceso
sirve como marco de referencia para controlar al microproceso. Incluye practicas como gestin de configuraciones, control de calidad, recorridos
de cdigo y documentacin. Incluye las siguientes actividades.
establecer requisitos centrales para el software (conceptualizacin)
desarrollar un modelo del comportamiento deseado del sistema (anlisis)
crear una arquitectura par la implementacin (diseo)
transformar la implementacin mediante refinamiento sucesivo(evolucin)
gestionar la evolucin posventa o postentrega (mantenimiento)
Es de importancia capital tener un liderazgo fuerte en el proyecto que gestione y dirija activamente las actividades del mismo
Two Leg Model (2)

Contiene procesos de abstraccin separados hasta que una especificacin formal es conseguida, seguido por un conjunto de pasos formales
deductivos de rectificacin para proceder a lo largo del diseo y la codificacin (2)
Anlisis Estructurado/Diseo Estructurado (6)

Es til para aquellos problemas en los que las funciones sean ms importantes y complejas que los datos
Modelo Convencional (4)

Esta compuesto por las siguientes fases
- fase de requerimientos
- fase de diseo
- fase de implementacin
llevar el diseo al cdigo
Separa los requerimientos del comportamiento interno. Separa los mecanismo de alto y bajo nivel. Se mezclan los mecanismo de intra mdulos
con decisiones de implementacin de lenguaje
Mejora Iterativa (3)

Incluye el use de un diseo modular descendente, un diseo cuidadoso antes de la codificacin, componentes modulares bien estructurados y un
mnimo nmero de implementadores.
Cada paso puede hacer uso de refinamiento. Representa una forma practica de aplicar refinamiento paso a paso.
El primer paso consiste de una implementacin inicial simple del esqueleto del subproblema de un proyecto. Se crea una lista de control de
proyecto que contiene todas las tareas que necesitan completarse para conseguir la implementacin final deseada.
En los pasos restantes se mejora iterativamente hasta que la implementacin final es conseguida. Cada etapa iterativa consiste en seleccionar y
quitar la siguiente tarea de la lista, diseando la implementacin para la tarea seleccionada.(fase de diseo). codificarla y debugear la
implementacin de la tarea (implementacin), realizar el anlisis de la implementacin parcial existente a esta altura de iteracin y poner al da la
lista de control de proyecto. El proceso es iterado hasta la lista de control de proyecto esta vacua.
La mejora iterativa es un algoritmo heurstico que comienza con la implementacin de un subproblema y prosigue con la modificacin iterativa
de la implementacin existente basada en un conjunto de guas informales para conseguir la implementacin completa deseada. Esta tcnica
involucra el desarrollo de un producto de software a travs de una secuencia de pasos sucesivos de diseo y implementacin empezando con una
prediccin inicial y una implementacin de un esqueleto del subproblema.
Enfoque operacional (4)
incluye los requerimientos del comportamiento interno en la especificacin operacional
separa la orientacin a problema de la especificacin operacional de las consideraciones de implementacin
todos los mecanismos funcionales son explicitados en la especificacin funcional
separa los mecanismo de su realizacin en trminos de lenguaje de implementacin

PROTOTIPOS
Modelo Ventajas Desventajas Ejemplo
Prototipo No est limitado a proyectos chicos tambin puede
Evolutivo manejar proyectos grandes (1)
Sirve para la formular los requerimientos de un
sistema de Software cuando los requerimientos del
usuario son vagos, incompletos o inestables (1)
Puede servir como herramienta para experimentar
con nuevas e innovadoras ideas de diseo (1)
Puede servir como factor de seguridad en
desarrollos con alto factor de riesgo (1)
Puede servir como forma de reaccionar ante
potenciales cambios organizacionales (1)
Puede servir como forma de promover al cliente a
participar del proceso de desarrollo (1)
Facilita un ambiente de enseanza para usuarios
finales potenciales durante el desarrollo (1)
Puede facilitar la introduccin gradual de un
sistema de computacin en una organizacin (1)
Es usado cuando hay un gran nivel de
incertidumbre (1)
Es usado cuando hay varias opciones de diseo e
implementacin (1)
Es usado cuando hay dificultades en formular las
especificaciones (1)
Es usado cuando no hay experiencia previa en el
desarrollo con una tcnica especifica (1)
Cuando se necesita un mtodo para producir el
sistema en forma gradual (1)


Prototipo de Sirve para formular los requerimientos de un Se puede caer en el error de prolongar en el
usar y tirar sistema de Software cuando los requerimientos desarrollo final, decisiones ineficientes
del usuario son vagos, incompletos o inestables utilizadas en el prototipo
Prototipado Los incrementos se pueden planear para Falta de planificacin a largo plazo
Incremental gestionar riesgos tcnicos Tentacin de caer en el modelo de codificar
Se ajusta a entornos de alta incertidumbre, por y corregir
no tener la necesidad de poseer un conjunto Existe el problema de determinar si los
exhaustivo de requisitos, (especificaciones, requisitos propuestos son vlidos, se
diseos, etc.), al comenzar el sistema, ya que detectan tarde.
cada refinamiento ampla los requisitos y las Puede encomendar demasiados recursos a
especificaciones derivadas de la fase anterior. una solucin errnea
Es particularmente til cuando la dotacin de Es difcil para ms de una persona trabajar
personal no est disponible para una en un nico prototipo
implementacin completa en cuanto a la fecha Aunque permite el cambio continuo de
lmite de gestin que se ha establecido (5) requisitos existe el problema de si los
requisitos propuestos son vlidos.
Los errores en los requisitos se detectan
tarde y su correccin resulta tan costosa
como en el modelo en cascada.
Prototipado Descuida el anlisis apropiado
Rpido Recae en la intuicin de los desarrolladores
Lleva a decisiones de diseo prematuras
La adquisicin de conocimientos y el
anlisis se vuelven manejados por la
implementacin
Se hace difcil de mantener ya que favorece
la falta de documentacin del anlisis y
diseo.
CASCADA
Cascada Ayuda a prevenir que se sobrepasen las fechas de Enfoque secuencial para construir un producto en
entrega y los costos esperados. el cual la iteracin no es evidente.
Al final de cada fase el personal tcnico y los Se tarda mucho tiempo en pasar por todo el ciclo,
usuarios tienen la oportunidad de revisar el progreso dado que hasta que no se finalice una fase no se
del proyecto. pasa a la siguiente.
Da facilidades a los gestores para controlar el El enfoque top-down necesita ser matizado con un
progreso de los sistemas. paso de reciclado (vuelta para atrs) para cubrir
Reconocimiento de ciclos de realimentacin entre temas como riesgo y reuso de mdulos de
etapas (2) software (2)
Es mejor que un enfoque hecho al azar (5) No maneja adecuadamente aspectos
concernientes al desarrollo de familias de
programas y de organizacin de software para
permitir cambios (2)
Asume progresin relativamente uniforme en los
pasos de elaboracin (2)
El nfasis en elaborados documentos como
criterio de finalizacin de las fases de
requerimientos y diseo no funciona bien para
muchas clases de software, particularmente las
aplicaciones interactivos.
No contempla la clase de desarrollo evolutivo que
presenta el prototipado rpido y los lenguajes de
cuarta generacin. (2)
Los proyectos reales rara vez siguen el modelo
secuencial que propone el modelo (5).
No contempla los posibles modos de desarrollo de
software futuros, asociados con las

capacidades de la programacin automtica,
transformacin de programas y asistentes de
software basados en el conocimiento. (2)
A menudo es difcil que el cliente explicite todos
los requisitos (5)
Una versin de trabajo del programa no estar
disponible hasta que el proyecto est muy
avanzado (5)
No refleja el proceso real de desarrollo de
software. Los proyectos reales raramente siguen
este flujo secuencial, puesto que siempre hay
iteraciones. Aunque en este modelo la iteracin
est permitida en etapas contiguas
(MACRO,1990),en la vida real la iteracin abarca
mas de una etapa. Un caso tpico es la redefinicin
de los requisitos cuando se est codificando la
aplicacin.
Acenta el fracaso de la industria del software con
el usuario final. En este caso, el usuario debe tener
paciencia, ya que el sistema en funcionamiento no
estar disponible hasta las fases finales del
proyecto.
Asume una especificacin de requisitos perfecta.
Deteccin de errores tarda
Agravado para KBS (incompleto y con
especificaciones cambiantes)
Administradores y usuarios tienen poca idea de
como quedar el sistema cuando se especifican los
requerimientos
ESPIRAL
Modelo en En el desarrollo interno existe una gran flexibilidad y Trabaja bien en los desarrollos internos, pero
espiral libertad para ajustarse a los acuerdos etapa por etapa, para necesita un ajuste posterior para adaptarlo a la
aplazar acuerdos de opciones especficas, para establecer subcontratacin de software.
miniespirales para resolver caminos crticos, para ajustar Necesidad de expertos en evaluacin de riesgos
niveles de esfuerzo, o para acomodar prcticas como para identificar y manejar las fuentes de riesgos
prototipado desarrollo evolutivo y uso de mtodos de de un proyecto.
diseo ajustado al costo. Requiere una considerable habilidad para la
Alienta el desarrollo de especificaciones que no son evaluacin del riesgo y depende de ella para el
necesariamente uniformes, exhaustivas o formales, al xito (5)
diferir la elaboracin detallada de los elementos de Deposita una gran cantidad de confianza en la
software de bajo riesgo, y evita roturas innecesarias en sus habilidad de los desarrolladores de software
diseos, hasta que los elementos de alto riesgo del diseo para identificar y manejar las fuentes de riesgo
sean establecidos. del proyecto. (5)
La revisin de los principales objetivos sirve para En general, los pasos del proceso necesitan una
asegurar que todas las partes involucradas estn de elaboracin adicional para asegurar que todos
acuerdo respecto al mtodo de trabajo para la siguiente los participantes de un desarrollo de software
fase. estn operando en un contexto consistente. (5)
Existe un reconocimiento explcito de las diferentes Presenta un riesgo de decisiones prematuras de
alternativas para alcanzar los objetivos de un proyecto. diseo
La identificacin de riesgos asociados con cada una de las Puede demostrar dificultad para ejecutar
alternativas y las diferentes maneras de resolverlos son el especificaciones con una adecuada performance
centro del modelo. Con los mtodos tradicionales, es En el desarrollo de software bajo contrato no
habitual dejar las partes, ms difciles para el final y existe esta flexibilidad y libertad, por lo que es
empezar con las ms fciles y de menor riesgo, necesario mucho tiempo para definir los
obteniendo as la ilusin de un gran avance. contratos, ya que los entregables no estn
previamente definidos de forma clara.


Contesta la pregunta cunto es suficiente? para cada Todava no encaja en el mundo de la
una de las fuentes de la actividad del proyecto y para el adquisicin de software por contrato.
manejo de los recursos. A no ser que se realice una inspeccin por
La divisin de los proyectos en ciclos, cada uno con un expertos, en este tipo de proyecto se tendr la
acuerdo al final de cada ciclo, implica que existe un ilusin de progresar por un perodo, y sin
acuerdo para los cambios que hay que realizar o para embargo, se encuentra dirigido directamente
terminar el proyecto, en funcin de lo que se ha aprendido hacia el desastre.
desde el inicio del proyecto. Las personas pueden encontrarlo difcil para
El modelo se adapta a cualquier tipo de actividad, dirigir transformaciones
incluidas algunas que no existen en otros mtodos (por
ejemplo, consulta de asesores expertos o investigadores
ajenos) que son muy tiles para la consecucin de los
objetivos de un proyecto.
Puede aplicarse a lo largo de la vida del proyecto (5)
Acomoda una mezcla apropiada de enfoques orientados a
especificaciones, orientados a prototipos, orientados a
simulaciones, orientados a transformacin automtica, y
otros
Es aplicable tanto a esfuerzos de desarrollo como de
mejora (enhacement). (2)
Incorpora prototipado como una opcin de reduccin
corte innecesario en su diseo y como una opcin de
reduccin de riesgo en cualquier etapa del desarrollo
Promueve el desarrollo de especificaciones que no son
necesariamente uniformes, exhaustivas o formales en las
que posterga la elaboracin detallada de elementos de
software de bajo riesgo, evitando un corte innecesario en
su diseo (2)


Mejora la estimacin y reduce el costo de corregir
Permite vueltas atrs en etapas tempranas del espiral al
identificar alternativas ms atractivas o al necesitar la
resolucin de un nuevo riesgo. (2)
Su rango de opciones y enfoque orientado a riesgos
permite acomodar las mejores caractersticas de los
modelos de software existentes evitando sus dificultades
(2)
Permite explcitamente estrategias para desarrollar
familias de programas y para reusar software existente (2)
Permite la evolucin del ciclo de vida, crecimiento y
cambios en el producto de software. (2)
Provee mecanismos para incorporar objetivos de calidad
del software en el proceso de desarrollo del producto de
software. (2)
Se focaliza en eliminar errores y alternativas poco
atractivas en forma temprana (2)
Permite iteraciones, vueltas atrs y terminacin prematura
de proyectos no viables (2)
Puede soportar y ser soportado por ambientes de
desarrollo de software avanzados (2)
No implica procedimientos separados para desarrollo y
mejoramiento de software. (2)
Provee un marco viable para el desarrollo de sistemas de
software o hardware integrados. (2)
Evita forzar procedimientos del desarrollo de software en
los paradigmas de desarrollo de hardware

ORIENTACION A OBJETOS
Modelo para La tecnologa de objetos pretende acelerar el desarrollo de Otro aspecto importante en la tecnologa de
Desarrollo de sistemas de una manera iterativa e incremental. objetos es la de "generalizar" los componentes
Sistemas La ventaja principal que permiten fijar hitos ms para que sean reutilizables, lo que incrementa
Orientados a frecuentemente, realizando entregas de sistemas que son los costos de desarrollo entre un 10 y 50%, por
Objetos operativos cada dos o tres meses para recibir lo que resulta imprescindible un desarrollo que
retroalimentacin del cliente lo antes posible e ir optimice esta inversin.
adaptando la aplicacin segn cambien las necesidades y El inconveniente que presentan es la dificultad
se refinen los requisitos de gestionar de manera formal los proyectos que
siguen estos ciclos de vida aunque este
problema se puede paliar diferenciando el
"micro" del "macroproceso".
Object Modeling Produce un diseo limpio y fcil de comprender, que La distincin entre anlisis y diseo podr
Tool (OMT) (6) resulta ms fcil de probar, mantener y extender parecer a veces arbitraria y confusa
El diseo resultante es ms adaptable, los cambios futuros
sern mucho ms sencillos
Da al proceso de desarrollo una base ms estable, y
permite utilizar un nico concepto unificador de software
a lo largo del proceso: el concepto de objeto, de tal forma
que la informacin registrada durante el anlisis no se
pierde ni se transforma cuando se produce el diseo y la
implementacin
La organizacin de un sistema en torno de objetos da al
desarrollo una estabilidad mayor que las orientadas a
funciones.
Es ms flexible al cambio y ms extensible.
Cambios de funcionalidad se admiten con facilidad en el
diseo orientado a objetos
Ejemplo Ventajas Desventajas Ejemplo

No hay discontinuidad en los modelos. La misma
notacin hace ms sencillo repetir los pasos de desarrollo
con grados de detalle cada vez ms finos. Cada iteracin
aade o clarifica caractersticas. Hay menos
oportunidades para incongruencias y errores
El paradigma del mundo real formado por objetos y
relaciones proporciona el contexto para comprender el
comportamiento dinmico y funcional
Los sistemas son ms fciles de entender, esto hace que el
diseo sea ms intuitivo y simplifica la seguibilidad entre
los requisitos y el cdigo de software. El diseo resulta
ms coherente para personas que no fueran parte del
equipo original del diseo
Se incrementa la reutilizabilidad de los componentes de
un proyecto para el siguiente
Integra mejor las bases de datos con el cdigo
La descomposicin de software OO modela ms de cerca
la percepcin que de la realidad tiene la persona. Por
tanto, no es sorprendente que el software desarrollado
resulte ms comprensible, extensible y mantenible.


Modelos CV OO La tecnologa de objetos pretende acelerar el La tecnologa de objetos pretende generalizar
Booch desarrollo de sistemas de una manera iterativa e los componentes para que sean reutilizables, lo
incremental. que incrementa los costos de desarrollo entre
Permite fijar hitos ms frecuentemente, un 10 y un 50%, por lo que resulta
realizando entregas de sistemas que son imprescindible un desarrollo que optimice esta
operativos, para recibir retroalimentacin del inversin.
cliente lo antes posible e ir adaptando la Dificultad de gestionar de manera formal los
aplicacin segn cambian las necesidades y se proyectos que siguen estos ciclos de vida
refinan los requisitos. aunque, como se ha sealado, este problema se
El enfoque evolutivo que el macroproceso puede paliar diferenciando el micro del
adopta para el desarrollo significa que hay macroproceso
oportunidades para identificar problemas en En algunos casos tiene un alto costo de puesta
momentos tempranos del ciclo de vida y en marcha (7)
responder a estos riesgos antes de que Tiene problemas de eficacia en ciertos casos
comprometan el xito del proyecto (7) particulares (7)
El proceso de desarrollo OO ayuda El microproceso del desarrollo orientado a
explcitamente a desarrollar factores de objetos es inestable de forma innata y requiere
calibracin (7) una direccin activa para forzar su conclusin
La gestin de proyectos OO, en estado estables, (7)
provoca una reduccin en la cantidad total de
recursos que se necesitan y un desplazamiento en
el ritmo de su despliegue respecto a mtodos
ms tradicionales.
Los costos del ciclo de vida son con frecuencia
menores que los de un enfoque tradicional
porque el producto resultante
tiende a ser de mucha mejor calidad y por
eso es mucho mas flexible ante el cambio

Alienta la reutilizacin de componentes de

software.
La integracin incremental tiende a reducir
el riesgo de desarrollo porque acelera el
descubrimiento de problemas de arquitectura
y eficacia en etapas tempranas del desarrollo
(7)
El macroproceso funciona muy bien para
asegurar la calidad porque permite una
recoleccin de datos continua sobre la tasa
de descubrimiento de errores (7)
La integracin sucede incrementalmente a lo
largo de todo el ciclo de vida en vez de
ocurrir en un evento explosivo (7)
Un desarrollo orientado a objetos explota la
potencia expresiva de todo los lenguajes de
programacin orientados a objetos (7)
Lleva a sistemas ms flexibles al cambio (7)
Reduce el riesgo de desarrollo (7)
Resulta atractivo al funcionamiento de la
mente humana (7)
El enfoque de desarrollo incremental es
extremadamente apropiado para el
paradigma orientado a objetos (7)

OTROS
Parnas information Maneja adecuadamente aspectos No ha sido completamente elaborado para ver
hiding approach concernientes al desarrollo de familias de como cubre aspectos tales como prototipado y
programas y a la organizacin de software reusabilidad (2)
para acomodar cambios (2)
Two Leg Model Contiene procesos de abstraccin separados Tiene retos en acomodar reusabilidad de software,
hasta que se obtiene una especificacin familias de programas y compromisos (trade-offs)
formal (2) de diseo fsico lgico (2)
Automatic Incorpora al ciclo de vida un marco Tiene problemas en escalar a sistemas muy
Paradigm conceptual para incorporar capacidades de grandes (2)
programacin automtica, transformacin de Tiene problemas en acomodar familas de
programas y asistentes basados en programas (2)
conocimiento (2) Tiene problemas en manejar opciones entre
nuevas y antiguas capacidades (2)
Anlisis /Diseo Tienen unos lmites del sistema bien definidos, as
Estucturado (6) que puede resultar difcil extender un diseo
SA/SD hasta unos nuevos lmites
Modelo Los requerimientos en prosa pueden ser Los requerimientos informales son notorios por su
Convencional (4) ledos y aprobados directamente por los ambigedad (4)
clientes (4) El testeo y la prueba de correctitud son muy
El prototipado es posible por iteracin del difciles (4)
ciclo de desarrollo entero Es difcil que soporte automatizacin completa (4)
Provee de puntos tiles de chequeo Los requerimientos de caja negra son difciles de
(milestones) (4) especificar (4)
La descomposicin top-down es difcil y riesgosa


Mejora Iterativa Facilita el logro de objetivos de desarrollo Generalmente no es fcil de aplicar cuando el
de software para muchos proyectos (3) proyecto es de tamao considerable(3)
Provee una forma prctica de usar un Requiere que el problema y su solucin estn bien
enfoque top-down step-wise (3) comprendidos (3)
Modelo Los requerimientos formales pueden ser Los requerimientos formales son inaccesibles para
Operacional (4) procesados por la maquina (4) los usuarios finales y otras personas no tcnicas
Est disponible prototipado rpido (4)
automticamente (4) Presenta peligro de decisiones de diseo
El testing o verificacin es evitado prematuras (4)
derivando la implementacin de la Puede resultar difcil ejecutar especificaciones con
especificacin usando solo transformaciones performance adecuada
y mapeos que han sido probados (4) Es una tecnologa nueva y subdesarrollada (4)
Las especificaciones ejecutables proveen La implementacin transformacional es nueva y
resultados tempranos y (4) no desarrollada tecnolgicamente
Maneja objetos formales, lo que implica que Las personas pueden encontrarlo difcil para
se pueden desarrollar templetes y dirigir transformaciones
herramientas (4)
Los usuarios tienen un modelo del sistema
para interiorizarse y evaluarlo
La implementacin transformacional
garantiza la correccin
La transformacin y realizacin son
altamente automticas.
Direcciona directamente el conflicto
estructural entre la eficiencia y
mantenimiento sencillo.

Bibliografa Analizada
1. Experiencie with evolutionary Prototyping in a Large Software Project. Sharam Hekmatpour

2. A spiral model of software development and enhacement. Barry Boehm
3. Iterative Enhacement: A Practical Technique for Software Development. Victor R. Basili and Albert J. Turner
4. The operational versus the conventional approach to software development. Pamela Zave
5. Ingeniera del Software Un enfoque prctico. 4ta Ed. Roger S. Pressman. Madrid. 1998
6. Modelado y diseo orientado a objetos OMT- Rumbaugh
7. Anlisis y Diseo Orientado a Objetos con Aplicaciones - Booch
8. Estndares del IEEE 1074-1991
9. Estndares ISO 12701-1
10. Anlisis y Diseo Orientado a Objetos - Martin y Odell
11. Elementos y Herramientas en el desarrollo de sistemas de informacin- Piattini
12. Anlisis y diseo detallado de aplicaciones informticas de Gestin- Piattini

Se Kappa

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Se Kappa

Uploaded by

Copyright:

Available Formats

TESIS DE MASTER

Sistemas Experto de Ayuda para la Seleccin del

Autor: Lic. Bibiana D. Rossi

DRA. Almudena Sierra

Madrid, Buenos Aires, Septiembre 2001

Agradecimientos 01/09/2003 Bibiana D. Rossi 1

A la Universidad Tecnolgica Nacional, Facultad Regional Buenos Aires, Repblica Argentina

A la Universidad Nacional de Lujn, Repblica Argentina

A la Facultad de Informtica de la Universidad Politcnica de Madrid

Al Dr. Edmundo No Gramajo

A mi primer maestro y jefe Lic. Carlos A. Uhalde

A mi directora Dra. Almudena Sierra, por el tiempo dedicado,

A mi director Dr. Ramn Garca Martnez, por su especial dedicacin,

Al equipo de expertos del dominio, Prof. Gregorio Perichinsky,

A mi hermana, amiga, colega y socia Lic. Paola Britos

A mis alumnos Ing. Alberto Patrn e Ing. Sebastin Corbat

A todos mis alumnos del Magster quienes

A mis compaeras de trabajo Cecilia Cardozo y Carolina Procopio, por su paciencia

A mi ahijado Maxi, por reglarme sus sonrisas, abrazos, travesuras y amor

A mis hijos Vernica La Valle y Gastn La Valle

Agradecimientos 01/09/2003 Bibiana D. Rossi 3

INDICE 01/09/2003 Bibiana D. Rossi 5

4.2 Anlisis de Viabilidad para el proyecto 68

INDICE 01/09/2003 Bibiana D. Rossi 6

6.2.5 Paso 5: Identificacin de los conocimientos fcticos 215

INDICE 01/09/2003 Bibiana D. Rossi 7

9.4.4 Caso Ejemplo 3: Control de Morosos 344

INDICE 01/09/2003 Bibiana D. Rossi 8

En los ltimos aos el proceso software se ha presentado como el eje

Existen varios modelos de ciclo de vida, entre los que se destacan:

El Ingeniero en software debe estudiar las caractersticas del proyecto y

Esta seleccin se realiza al inicio del proyecto y se deben considerar un

En este contexto, se ha considerado conveniente disponer de la asistencia

Se observa que el conocimiento requerido para confeccionar el Sistema

INTRODUCCION 01/09/2003 Bibiana D. Rossi 11

Este trabajo esta organizado en captulos cuyo contenido es el siguiente:

En el captulo II, Domino del problema, se describe el dominio de aplicacin

En el captulo III, Definicin del problema, se presenta el objetivo y alcance

En el captulo IV, Estudio de Viabilidad, se describe el Test de Viabilidad que

En el captulo V, Adquisicin del Conocimiento se describe el proceso de

En el captulo VI, Conceptualizacin de Conocimientos se presenta el

INTRODUCCION 01/09/2003 Bibiana D. Rossi 12

En el captulo VII, Formalizacin de Conocimientos se especifica cmo los

En el captulo VIII, Implementacin del sistema se describen en primer lugar

En el captulo X, Conclusiones finales y Futuras Lneas de Investigacin, se

En el captulo XI, Bibliografa, se presenta la bibliografa que se ha usado en

En el captulo XII, Anexos, se detallan los anexos. En primer lugar se

experto y las sesiones de extraccin de conocimientos realizadas sobre el

INTRODUCCION 01/09/2003 Bibiana D. Rossi 14

En este captulo se describe brevemente el dominio de aplicacin del

Del CV en Cascada se describen sus fases. Del CV en Espiral se explica

Todos los sistemas de informacin estn conformados por componentes

Todos estos elementos no hacen un sistema de informacin a menos que

Existen varios tipos de ciclos de vida entre los cuales seleccionar. Es

Las tcnicas y metodologas de desarrollo de sistemas se confunden con

Algunos autores y profesionales presentan el concepto de ciclo de vida

Una tcnica es un mtodo que aplica herramientas y reglas especficas

Una metodologa es una versin particular e individual de un ciclo de vida

Una autntica metodologa debe acompaar al ciclo de vida completo del

As pues, puede afirmarse que el ciclo de vida sigue vigente. Simplemente

Independientemente del nmero o nombres de las fases del ciclo de vida,

DOMINIO DE LA APLICACIN 01/09/2003 Bibiana D. Rossi 18

falsos, reciclamiento indebido y callejones sin salida. Adems aumenta la