Beruflich Dokumente
Kultur Dokumente
Dirigida por:
DRA. Almudena Sierra
DR. Ramn Garca Martnez
A mis hijos
Gastn La Valle y Vernica La Valle
Agradecimientos 01/09/2003
Bibiana D. Rossi
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
INDICE
Captulo 1.
1. Introduccin
11
Captulo 2.
2. Dominio de la Aplicacin
17
2.1 Introduccin
17
19
20
26
26
28
31
32
35
42
43
44
45
Captulo 3.
3. Definicin del problema
49
3.1 Planteamiento
49
50
3.3 Alcance
50
50
52
56
3.6.1 Planificacin
56
57
57
57
Captulo 4.
4. Estudio de Viabilidad
65
01/09/2003
65
Bibiana D. Rossi
68
68
69
71
73
77
87
Captulo 5.
5. Adquisicin de Conocimientos
91
91
92
94
95
Sesin C.1
95
Sesin C.2
118
Sesin C.3
128
136
Sesin D.1
136
Sesin A.4
142
145
Captulo 6.
6. Conceptualizacin de Conocimientos
149
149
150
166
167
167
180
180
01/09/2003
180
215
Bibiana D. Rossi
215
216
252
252
252
253
267
268
Captulo 7.
7. Formalizacin de Conocimientos
281
281
281
281
293
Captulo 8.
8. Implementacin del sistema
299
299
299
300
301
302
304
Captulo 9.
9. Evaluacin
325
325
326
326
327
332
327
339
01/09/2003
Bibiana D. Rossi
344
349
355
364
370
374
377
383
390
Captulo 10.
10. Conclusiones y Futuras Lneas de Investigacin
395
395
396
397
Captulo 11
11. Bibliografa
401
401
11.2 Abreviaturas
403
Captulo 12
12. Anexos
407
407
419
INDICE
419
429
01/09/2003
Bibiana D. Rossi
Captulo 1
Introduccin
INTRODUCCION 01/09/2003
Bibiana D. Rossi
11
INTRODUCCION 01/09/2003
Bibiana D. Rossi
12
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.
INTRODUCCION 01/09/2003
Bibiana D. Rossi
13
INTRODUCCION 01/09/2003
Bibiana D. Rossi
14
Captulo 2
Dominio de la
Aplicacin
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
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.
Bibiana D. Rossi
18
PROCESO DE
CONSTRUCCION
DEFINIR
REQUISITOS
DISEAR
EL SISTEMA
PROBAR
EL SISTEMA
PROGRAMAR
CICLO DE
VIDA
NECESIDAD
DEFINICION
DE
REQUISITOS
DISEO
CODIGO
SISTEMA
SOFTWARE
Bibiana D. Rossi
19
Bibiana D. Rossi
20
PLANIFICACION
DE SISTEMAS
DEFINICION DE
REQUERIMIENTOS
ANALISIS
DISEO
CODIFICACION
PRUEBA
IMPLEMENTACION
MANTENIMIENTO
Bibiana D. Rossi
21
Bibiana D. Rossi
22
Bibiana D. Rossi
23
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.
Bibiana D. Rossi
24
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
hardware y
software
Pruebas
del sistema
software
Pruebas
Integracin
del software
Bibiana D. Rossi
25
Bibiana D. Rossi
26
Bibiana D. Rossi
27
Costos
acumulados
Progreso a travs de pasos
Evaluacin de alternativas,
Identificacin, resolucin
de riesgos
Determinacin de
objetivos,
alternativas,
restricciones
Anlisis
de riesgo
Anlisis
de riesgo
Anlisis
de riesgo
Anlisis
de riesgo
Revisin
Prototipo 1
Particin
obligatoria
Planificacin
de requisitos
Concepto
Planificacin
del ciclo de vida de operacin
Planificacin
del desarrollo
Validacin
de requisitos
Prototipo 2
Prototipo
operacional
Requisitos
del software
Diseo del
producto
software
Planificacin de
Validacin y verificacin
la integraciny prueba
del diseo
Planificacin de las prximas fases
Prototipo 3
Prueba de Integracin
aceptacin y prueba
Implementacin
Diseo
detallado
Codificacin
Prueba
de
unidad
Desarrollo, verificacin
del producto del prximo nivel
Bibiana D. Rossi
28
Bibiana D. Rossi
29
Bibiana D. Rossi
30
Bibiana D. Rossi
31
Bibiana D. Rossi
32
Bibiana D. Rossi
33
Bibiana D. Rossi
34
Bibiana D. Rossi
35
DISEO
ARQUITECTURA
ANALISIS OO
DISEO OO
COMPLETAR MODELO DE
OBJETOS
ESPECIFICAR INTERFASES
BUSCAR CLASES REUSABLES
CREAR NUEVAS CLASES
MANTENIMIENTO
PROGRAMACION
OO
PRUEBA
Bibiana D. Rossi
36
Bibiana D. Rossi
37
Bibiana D. Rossi
38
Bibiana D. Rossi
39
Bibiana D. Rossi
40
Bibiana D. Rossi
41
Bibiana D. Rossi
42
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.
Primer paso
Bibiana D. Rossi
43
Quinto paso
Sexto paso
Primer paso
Segundo Paso
Bibiana D. Rossi
44
Cuarto Paso
Bibiana D. Rossi
45
Primer paso
Segundo Paso
Tercer Paso
Bibiana D. Rossi
46
Captulo 3
Definicin del
problema
01/09/2003
Bibiana D. Rossi
49
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.
01/09/2003
Bibiana D. Rossi
50
01/09/2003
Bibiana D. Rossi
51
Herramienta: el prototipo
computadoras personales.
se
desarrollar
para
ser
usado
en
01/09/2003
Bibiana D. Rossi
52
De
vali
aci
vas
eo
n
ny
uis
ici
n
conc
eptu
ali
del n zacin
uevo
Adq
cin
gra
Inte
to
ien
cim
no
co
ue
ici
vo
nue
vo
ue
ln
de
Pr
aci
fin
n
ci
za
ali
rm
Fo
egr
De
los
n
ci o
za ient
ali
rm ocim
Fo on
lc
de
d el
Adquisicin y
conceptualizacin
del conocimiento
int
es
De
fin
ap icin
lic
ac de l
in a
cin
de
Imp
l
d e ement
pro
d u c acin
c i n prot
o
(op
Tra
e r a tipo
nsf
tivo
ere
)
del ncia
y
Sis
tem mant
e
aC
om nimien
erc
ial to
egr
k
ar
hm
nc
Be
Mo
n
ci
ula
Sim
Imple
del p mentaci
ro
n
dem totipo d
ostra
e
cin
Imple
del p mentaci
ro
n
inve totipo d
e
stiga
cin
Imple
proto menta
cin
tipo
de c
amp
o
int
ny
de n
ue
ion
de
dise
Plan de
requisitos
icac
ici
es
_
ep
nc e
Co n d
ci cin
lu
so
y
in e
d
ac
alu n
Ev lecci cin
se plica
a
ecif
in
fin
on
Dis
esp
dac
aci
, im
pl
pru menta
cin
eba
y
ific
con
ocim
ien
to
pec
ad a
vali
Re
qu
isi
to
s
ot de
i
ro
s s nteg
ist
r
em aci
as n c
on
De
fin
ci
va
ny
lid
ac
in
de
nu
ev
req
os
uis
ito
s
Es
ba
c
ea
ep
tac
ion
Segundo nivel de
acumulacin de conocimiento
Primer nivel de
acumulacin de
conocimiento
01/09/2003
Bibiana D. Rossi
53
01/09/2003
Bibiana D. Rossi
54
01/09/2003
Bibiana D. Rossi
55
01/09/2003
Bibiana D. Rossi
56
01/09/2003
Bibiana D. Rossi
57
Id
1
2
Nombre de tarea
Desarrollo del Sistema Experto sobre Ciclos de Vida
Fase I: Identificacin de la tarea
Duracin
140,13 das
41 horas
49 horas
55 horas
103,75 das
330 horas
120 horas
10
II.4: Implementacin.
180 horas
11
100 horas
12
13
14
15
16
17
70 horas
30 horas
2 das
0 das
0 das
16 horas
6 das
18
16 horas
19
16 horas
20
16 horas
21
9,5 das
22
26 horas
23
50 horas
24
10/10
17/10
24/10
noviembre
31/10
07/11
14/11
21/11
diciembre
28/11
05/12
18,13 das
octubre
26/09
03/10
113,25 das
25
500 horas
26
180 horas
27
Presentacin final
70 horas
19/10
09/11
06/12
12/12
19/12
26/12
enero
02/01
09/01
16/01
Id
1
2
Nombre de tarea
Desarrollo del Sistema Experto sobre Ciclos de Vida
23/01
febrero
30/01
06/02
13/02
5
6
10
II.4: Implementacin.
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Presentacin final
10/02
20/02
marzo
27/02
05/03
12/03
19/03
26/03
abril
02/04
09/04
16/04
23/04
mayo
30/04
07/05
14/05
21/05
Id
1
2
Nombre de tarea
Desarrollo del Sistema Experto sobre Ciclos de Vida
junio
28/05
04/06
11/06
18/06
25/06
julio
02/07
09/07
16/07
23/07
agosto
30/07
06/08
13/08
20/08
27/08
septiembre
03/09
10/09
17/09
24/09
5
6
10
II.4: Implementacin.
11
12
13
10/07
04/09
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Presentacin final
25/09
Id
1
2
Nombre de tarea
Desarrollo del Sistema Experto sobre Ciclos de Vida
octubre
01/10
08/10
15/10
22/10
noviembre
29/10
05/11
12/11
19/11
5
6
10
II.4: Implementacin.
11
12
13
21/11
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Presentacin final
21/11
diciembre
26/11
03/12
10/12
17/12
24/12
enero
31/12
07/01
14/01
21/01
feb
28/01
Id
1
2
Nombre de tarea
Desarrollo del Sistema Experto sobre Ciclos de Vida
ero
04/02
11/02
18/02
marzo
25/02
04/03
11/03
18/03
25/03
abril
01/04
08/04
15/04
22/04
mayo
29/04
06/05
13/05
20/05
27/05
junio
03/06
5
6
10
II.4: Implementacin.
11
12
13
13/02
06/03
14
15
16
17
20/03
18
19
20
21
03/04
12/04
22
23
24
20/03
27/03
03/05
25
26
27
Presentacin final
04/06
Captulo 4
Estudio de
Viabilidad
Bibiana D. Rossi
65
10
0
10
0
10
0
10
0
0
1.2
3.4
5.6
7.8
0
2.2
4.4
6.6
8.8
1.2
3.4
5.6
7.8
10
2.2
4.4
6.6
8.8
10
Bibiana D. Rossi
66
1
VCi =
2
Pik
ri
PikVik
1
k =1
+
Pik 2 ri
1 Vik
Pik
K=
k =1
k =1
ri
Bibiana D. Rossi
67
Plausibilidad
Adecuacin
Justificacin
Exito
8
8
3
5
P Vi
i
Vf =
i =1
4
i =1
Bibiana D. Rossi
68
Bibiana D. Rossi
69
Bibiana D. Rossi
70
Bibiana D. Rossi
71
Bibiana D. Rossi
72
Bibiana D. Rossi
73
Bibiana D. Rossi
74
Bibiana D. Rossi
75
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.
ESTUDIO DE VIABILIDAD 01/09/2003
Bibiana D. Rossi
76
Bibiana D. Rossi
77
TABLA 4.3.1
DIMENSION DE PLAUSIBILIDAD
Denominacin de la Caracterstica
Existen expertos, estn disponibles y son
cooperativos.
El experto es capaz de estructurar sus
mtodos y procedimientos de trabajo.
La tarea esta bien estructurada y se entiende.
Existen suficientes casos de prueba y sus
soluciones asociadas.
La tarea slo depende de los conocimientos y
no del sentido comn.
TABLA 4.3.2
Categora
Dimensin
Peso
Tipo
Naturaleza
Umbral
Valor
Experto
P1
10
Esencial
Booleana
S (s)
SI
Experto
P2
Deseable
Difusa
No
MUCHO
Tarea
Tarea
P3
P4
8
10
Deseable
Esencial
Difusa
Numrica
No
S (8)
REGULAR
10
Tarea
P5
Deseable
Numrica
No
Categora
Dimensin
Peso
Tipo
Naturaleza
Umbral
Valor
Tarea
Directivos /
Usuarios
Experto
Tarea
J1
J2
8
7
Deseable
Deseable
Difusa
Numrica
No
No
MUCHO
7
J3
J4
6
10
Deseable
Deseable
Difusa
Difusa
No
No
MUCHO
REGULAR
Tarea
Experto
J5
J6
10
10
Deseable
Deseable
Difusa
Difusa
No
No
MUCHO
REGULAR
Tarea
J7
Esencial
Booleana
S (s)
SI
DIMENSION DE JUSTIFICACIN
Denominacin de la Caracterstica
Resuelve una tarea til y necesaria.
Se espera una alta tasa de recuperacin de la
inversin
Hay escasez de experiencia humana.
Hay necesidad de tomar decisiones en
situaciones criticas o ambientes hostiles,
penosos y/o pocos gratificantes.
Hay necesidad de distribuir los conocimientos.
Los conocimientos pueden perderse de no
realizarse el sistema.
No existen soluciones alternativas.
Bibiana D. Rossi
78
TABLA 4.3.3
DIMENSION DE ADECUACION
Denominacin de la Caracterstica
Categora
Dimensin
Peso
Tipo
Naturaleza
Umbral
Valor
Tarea
A1
Deseable
Difusa
No
MUCHO
Tarea
Tarea
A2
A3
10
-2
Deseable
Deseable
Difusa
Difusa
No
No
TODO
POCO
Tarea
Tarea
A4
A5
5
7
Deseable
Deseable
Difusa
Difusa
No
No
MUCHO
MUCHO
Tarea
A6
Deseable
Booleana
No
SI
Tarea
A7
Esencial
Difusa
MUCHO
Tarea
A8
Deseable
Difusa
S
(mucho)
No
Tarea
A9
Deseable
Difusa
No
MUCHO
Experto
A10
Deseable
Booleana
No
SI
Tarea
Experto
A11
A12
8
3
Deseable
Deseable
Booleana
Difusa
No
No
SI
TODO
Tarea
A13
Deseable
Difusa
No
TODO
Tarea
Tarea
A14
A15
-10
-6
Esencial
Deseable
Booleana
Difusa
S (No)
No
NO
NADA
Bibiana D. Rossi
POCO
79
TABLA 4.3.4
DIMENSION DE XITO
Denominacin de la Caracterstica
Existe una ubicacin idnea para el SE.
Problemas similares se han resuelto con INCO.
El problema es similar a otros en lo que resulto
imposible aplicar esta tecnologa.
La continuidad del proyecto est influenciada por
vaivenes polticos.
La insercin del sistema se efecta sin traumas,
es decir, apenas se interfiere en la rutina
cotidiana.
Se dispone de experiencia en INCO.
Se dispone de los recursos humanos, hardware y
software necesarios para el desarrollo e
implementacin del sistema.
El experto resuelve el problema en la actualidad.
La solucin del problema es prioridad para la
institucin.
Las soluciones son explicables.
Los objetivos del sistema son claros y evaluables.
Los conocimientos estn repartidos entre un
conjunto de individuos.
Los directivos, usuarios, experto e IC estn de
acuerdo en las funcionalidades del SE.
La actitud de los expertos ante el desarrollo del
sistema es positiva y no se sienten amenazados
por el proyecto.
Categora
Dimensin
Peso
Tipo
Naturaleza
Umbral
Valor
Directivos /
Usuarios
Tarea
Tarea
E1
Deseable
Difusa
No
TODO
E2
E3
8
-5
Deseable
Deseable
Booleana
Booleana
No
No
SI
NO
Directivos /
Usuarios
Directivos /
Usuarios
E4
-9
Esencial
Difusa
S (poco)
POCO
E5
Deseable
Difusa
No
MUCHO
Tarea
Tarea
E6
E7
7
4
Deseable
Deseable
Difusa
Difusa
No
No
REGULAR
TODO
Experto
Directivos /
Usuarios
Tarea
Tarea
Experto
E8
E9
4
8
Deseable
Esencial
Difusa
Difusa
TODO
MUCHO
E10
E11
E12
5
6
-7
Deseable
Deseable
Deseable
Difusa
Difusa
Difusa
No
S
(mucho)
No
No
No
E13
Esencial
Difusa
E14
Deseable
Difusa
Directivos /
Usuarios
Experto
Bibiana D. Rossi
S
(mucho)
No
MUCHO
MUCHO
REGULAR
MUCHO
TODO
80
TABLA 4.3.4
Denominacin de la Caracterstica
Categora
Dimensin
Peso
Tipo
Naturaleza
Umbral
Valor
Experto
E15
Deseable
Difusa
No
REGULAR
Directivos /
Usuarios
Tarea
E16
Esencial
Booleana
S (s)
SI
E17
-6
Deseable
Difusa
No
POCO
Directivos /
Usuarios
Directivos /
Usuarios
Experto
Tarea
E18
Esencial
Difusa
MUCHO
E19
-2
Deseable
Difusa
S
(mucho)
No
E20
E21
4
-6
Deseable
Deseable
Difusa
Booleana
No
No
MUCHO
NO
Directivos /
Usuarios
Experto
E22
Esencial
Difusa
MUCHO
E23
Deseable
Booleana
S
(mucho)
No
Bibiana D. Rossi
MUCHO
SI
81
TABLA 4.3.5
F
Peso
P1
P2
P3
P4
P5
10
7
8
10
9
S
Mucho
Regular
10
8
10
5,6
3,4
10
8
10
6,6
4,4
10
8
Peso / Valor
Peso * Valor
10 10 1
7,8 8,8 1,25
5,6 6,6 2,35
10 10 1
8
8 1,13
1
1,06
1,82
1
1,13
1
0,9
1,43
1
1,13
1
0,8
1,21
1
1,13
100
39,2
27,2
100
72
100
46,2
35,2
100
72
100
54,6
44,8
100
72
100
61,6
52,8
100
72
6,72
6,00
5,45
5,13
338,4
353,4
371,4
386,4
44
Rtdo
7,12
7,68
8,26
8,67
PLAUSIBILIDAD
1,2
1
0,8
0,6
0,4
0,2
0
NADA
POCO
REGULAR
Bibiana D. Rossi
MUCHO
TODO
10
82
TABLA 4.3.6
Peso Valor
J1
J2
J3
J4
J5
J6
J7
Valores Difusos
8
Mucho 5,6 6,6 7,8
7
7
7 7 7
6
Mucho 5,6 6,6 7,8
10 Regular 3,4 4,4 5,6
10 Mucho 5,6 6,6 7,8
10 Mucho 5,6 6,6 7,8
8
S
10 10 10
Peso * Valor
8,8
7
8,8
6,6
8,8
8,8
10
44,8 52,8
49
49
33,6 39,6
34
44
56
66
56
66
80
80
331,4 375,4
59
Valor Mximo:
80
Rtdo
7,8
8,8
Aprox.Numrica
10
TODO
JUSTIFICACION
1,2
NADA
POCO
REGULAR
MUCHO
TODO
1
0,8
0,6
0,4
0,2
0
0
Bibiana D. Rossi
10
83
TABLA 4.3.7
Peso
Valor
Valores Difusos
A1
A2
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
A13
A14
A15
7
10
-(2)
5
7
8
8
8
6
3
8
3
3
-(10)
-(6)
Mucho
Todo
(Poco)
Mucho
Mucho
S
Mucho
Poco
Mucho
S
S
Todo
Todo
(No)
(Nada)
5,6
7,8
5,6
5,6
5,6
10
5,6
1,2
5,6
10
10
7,8
7,8
10
7,8
6,6
8,8
6,6
6,6
6,6
10
6,6
2,2
6,6
10
10
8,8
8,8
10
8,8
7,8
10
7,8
7,8
7,8
10
7,8
3,4
7,8
10
10
10
10
10
10
8,8
10
8,8
8,8
8,8
10
8,8
4,4
8,8
10
10
10
10
10
10
Peso * Valor
Rtdo
1,25
1,282
0,357
0,893
1,25
0,8
1,429
6,667
1,071
0,3
0,8
0,385
0,385
1
0,769
1,061
1,136
0,303
0,758
1,061
0,8
1,212
3,636
0,909
0,3
0,8
0,341
0,341
1
0,682
0,897
1
0,256
0,641
0,897
0,8
1,026
2,353
0,769
0,3
0,8
0,3
0,3
1
0,6
0,795
1
0,227
0,568
0,795
0,8
0,909
1,818
0,682
0,3
0,8
0,3
0,3
1
0,6
39,2
78
11,2
28
39,2
80
44,8
9,6
33,6
30
80
23,4
23,4
100
46,8
46,2
88
13,2
33
46,2
80
52,8
17,6
39,6
30
80
26,4
26,4
100
52,8
18,64
58
Peso / Valor
14,34
11,94
10,9
667,2
732,2
6,07
Bibiana D. Rossi
7,17
8,25
54,6
100
15,6
39
54,6
80
62,4
27,2
46,8
30
80
30
30
100
60
810,
2
61,6
100
17,6
44
61,6
80
70,4
35,2
52,8
30
80
30
30
100
60
853,
2
8,85
84
TABLA 4.3.8
Peso
Valor
E1
E2
E3
E4
E5
E6
E7
E8
E9
E10
E11
E12
E13
E14
E15
E16
E17
E18
E19
E20
E21
E22
E23
7
8
-(5)
-(9)
8
7
4
4
8
5
6
-(7)
4
8
5
8
-(6)
7
-(2)
4
-(6)
8
5
Todo
S
(No)
(Poco)
Mucho
Regular
Todo
Todo
Mucho
Mucho
Mucho
(Regular)
Mucho
Todo
Regular
S
(Poco)
Mucho
(Mucho)
Mucho
(No)
Mucho
S
Valores Difusos
7,8
10
10
5,6
5,6
3,4
7,8
7,8
5,6
5,6
5,6
3,4
5,6
7,8
3,4
10
5,6
5,6
1,2
5,6
10
5,6
10
8,8
10
10
6,6
6,6
4,4
8,8
8,8
6,6
6,6
6,6
4,4
6,6
8,8
4,4
10
6,6
6,6
2,2
6,6
10
6,6
10
10
10
10
7,8
7,8
5,6
10
10
7,8
7,8
7,8
5,6
7,8
10
5,6
10
7,8
7,8
3,4
7,8
10
7,8
10
10
10
10
8,8
8,8
6,6
10
10
8,8
8,8
8,8
6,6
8,8
10
6,6
10
8,8
8,8
4,4
8,8
10
8,8
10
Peso * Valor
Rtdo.
0,897
0,8
0,5
1,067
1,429
2,059
0,513
0,513
1,429
0,893
1,071
23,8
0,714
1,026
1,471
0,8
1,071
1,25
1,667
0,714
0,6
1,429
0,5
0,795
0,8
0,5
1,364
1,212
1,591
0,455
0,455
1,212
0,758
0,909
30,8
0,606
0,909
1,136
0,8
0,909
1,061
0,909
0,606
0,6
1,212
0,5
0,7
0,8
0,5
1,154
1,026
1,25
0,4
0,4
1,026
0,641
0,769
39,2
0,513
0,8
0,893
0,8
0,769
0,897
0,588
0,513
0,6
1,026
0,5
0,7
0,8
0,5
1,023
0,909
1,061
0,4
0,4
0,909
0,568
0,682
46,2
0,455
0,8
0,758
0,8
0,682
0,795
0,455
0,455
0,6
0,909
0,5
54,6
80
50
50,4
44,8
23,8
31,2
31,2
44,8
28
33,6
23,8
22,4
62,4
17
80
33,6
39,2
2,4
22,4
60
44,8
50
61,6
80
50
59,4
52,8
30,8
35,2
35,2
52,8
33
39,6
30,8
26,4
70,4
22
80
39,6
46,2
4,4
26,4
60
52,8
50
70
80
50
70,2
62,4
39,2
40
40
62,4
39
46,8
39,2
31,2
80
28
80
46,8
54,6
6,8
31,2
60
62,4
50
70
80
50
79,2
70,4
46,2
40
40
70,4
44
52,8
46,2
35,2
80
33
80
52,8
61,6
8,8
35,2
60
70,4
50
25,01
71
Peso / Valor
20,09
17,81
16,22
930,4
1039
1170
1256
6,118
Bibiana D. Rossi
7,061
8,107
8,801
85
ADECUACION
NADA
1,2
POCO
REGULAR
EXITO
MUCHO
TODO
0,2
1,2
1
0,8
0,6
0,4
0,2
NADA
POCO
REGULAR
MUCHO
TODO
1
0,8
0,6
0,4
TABLA 4.3.9
10
10
Factor
Coeficiente
Plausibilidad
Justificacin
Adecuacin
xito
8
3
8
5
Valores Difusos
7,12
7,8
6,07
6,12
7,68
8,8
7,17
7,06
8,26
10
8,25
8,11
Peso*Valor
8,63
10
8,85
8,8
Valor Final
Media General
ESTUDIO DE VIABILIDAD 01/09/2003
Bibiana D. Rossi
61,44
26,4
57,36
35,3
66,08
30
66
40,55
69,04
30
70,8
44
159,5
24
56,96
23,4
48,56
30,6
180,5
202,6
213,8
6,65
7,52
8,44
8,91
7,9
86
RESULTADO FINAL
NADA
1,2
POCO
REGULAR
MUCHO
TODO
1
0,8
0,6
0,4
0,2
0
0
10
Bibiana D. Rossi
87
Captulo 5
Adquisicin de
Conocimientos
Bibiana D. Rossi
91
Bibiana D. Rossi
92
Bibiana D. Rossi
93
Bibiana D. Rossi
94
Bibiana D. Rossi
95
Expertos asistentes: Prof. Perichinsky, Lic. Beltrami, Lic. Leone, Ing. Pollo
Cattaneo, Lic. Lucchini, Ing. Weschler, Lic. Fernndez.
Tiempo: 18 a 21.00hs.
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.
Bibiana D. Rossi
96
Bibiana D. Rossi
97
- CUESTIONARIO
Proyecto:
Tcnicas Utilizadas:
Tcnica usada
Resultado
Entrevistas
Estudio de viabilidad
Anlisis de
textos
vida
Mtodo Delphi
2.
3.
4.
5.
6.
7.
Bibiana D. Rossi
98
- CUESTIONARIO
Acerca de la Sesin I
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.
3. Identificar todas las caractersticas relevantes de un proyecto para seleccionar
el modelo de ciclo de vida en Orientado a objetos (considerando tem 5).
Escribirlas en la lista correspondiente.
4. 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.
5. Analizar en cada caso:
Es posible modificar algo?
Es posible aadir?
Es posible eliminar?
Es posible sustituir un concepto por otro?
Es posible combinar elementos entre s?
Se puede tomar la idea en sentido opuesto?
Est asociada a uno a dos o a los tres modelos de CV a seleccionar?
Bibiana D. Rossi
99
- CUESTIONARIO
Experto:
Bibiana D. Rossi
100
- CUESTIONARIO
Experto:
Bibiana D. Rossi
101
- CUESTIONARIO
Experto:
Bibiana D. Rossi
102
- CUESTIONARIO
Modelo Ventajas
Desventajas
No est limitado a proyectos chicos
Modelo
tambin puede manejar proyectos
1
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)
Bibiana D. Rossi
103
- CUESTIONARIO
Modelo Ventajas
Desventajas
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
3
Modelo
4
Bibiana D. Rossi
104
- CUESTIONARIO
Modelo Ventajas
Desventajas
Enfoque secuencial para construir
Ayuda a prevenir que se
Modelo
un producto en el cual la iteracin
sobrepasen las fechas de entrega y
5
no es evidente.
los costos esperados.
Se tarda mucho tiempo en pasar
Al final de cada fase el personal
por todo el ciclo, dado que hasta
tcnico y los usuarios tienen la
que no se finalice una fase no se
oportunidad de revisar el progreso
pasa a la siguiente.
del proyecto.
El enfoque top-down necesita ser
Da facilidades a los gestores para
matizado con un paso de
controlar el progreso de los
reciclado (vuelta para atrs) para
sistemas.
cubrir temas como riesgo y reuso
Reconocimiento de ciclos de
de mdulos de software (2)
realimentacin entre etapas (2)
No maneja adecuadamente
Es mejor que un enfoque hecho al
aspectos concernientes al
azar (5)
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
Bibiana D. Rossi
105
- CUESTIONARIO
Modelo Ventajas
Desventajas
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
Bibiana D. Rossi
106
- CUESTIONARIO
Modelo Ventajas
Desventajas
Trabaja bien en los desarrollos
Modelo
En el desarrollo interno existe
internos, pero necesita un ajuste
6
gran flexibilidad y libertad para
posterior para adaptarlo a la
ajustarse a los acuerdos etapa
subcontratacin de software.
por etapa, para aplazar acuerdos
Necesidad de expertos en
de opciones especficas, para
evaluacin de riesgos para
establecer miniespirales para
identificar y manejar las fuentes
resolver caminos crticos, para
de riesgos de un proyecto.
ajustar niveles de esfuerzo, o
Requiere una considerable
para acomodar prcticas como
habilidad para la evaluacin del
prototipado desarrollo evolutivo
riesgo y depende de ella para el
y uso de mtodos de diseo
xito (5)
ajustado al costo.
Deposita una gran cantidad de
Alienta el desarrollo de
confianza en la habilidad de los
especificaciones que no son
desarrolladores de software para
necesariamente uniformes,
identificar y manejar las fuentes
exhaustivas o formales, al diferir
de riesgo del proyecto. (5)
la elaboracin detallada de los
En general, los pasos del proceso
elementos de software de bajo
necesitan una elaboracin
riesgo, y evita roturas
adicional para asegurar que todos
innecesarias en sus diseos,
los participantes de un desarrollo
hasta que los elementos de alto
de software estn operando en un
riesgo del diseo sean
contexto consistente. (5)
establecidos.
Puede demostrar dificultad para
La revisin de los principales
ejecutar especificaciones con una
objetivos sirve para asegurar que
adecuada performance
todas las partes involucradas
En el desarrollo de software bajo
estn de acuerdo respecto al
contrato no existe esta flexibilidad
mtodo de trabajo para la
y libertad, por lo que es necesario
siguiente fase.
mucho tiempo para definir los
La identificacin de riesgos
contratos, ya que los entregables
asociados con cada una de las
no estn previamente definidos de
alternativas y las diferentes
forma clara.
maneras de resolverlos son el
Todava no encaja en el mundo de
centro del modelo. Con los
la adquisicin de software por
mtodos tradicionales, es
contrato.
habitual dejar las partes, difciles
A no ser que se realice una
para el final y empezar con las
inspeccin por expertos, en este
ms fciles y de menor riesgo,
tipo de proyecto se tendr la
obteniendo as la ilusin de un
ilusin de progresar por un
gran avance.
perodo, y sin embargo, se
La divisin de los proyectos en
encuentra dirigido directamente
ciclos, cada uno con un acuerdo
hacia el desastre.
al final de cada ciclo, implica
Las personas pueden encontrarlo
que existe un acuerdo para los
difcil para dirigir
cambios a realizar o para
transformaciones
terminar el proyecto, en funcin
de lo que se ha aprendido desde
el inicio del proyecto.
Bibiana D. Rossi
107
- CUESTIONARIO
Modelo Ventajas
Desventajas
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.
Bibiana D. Rossi
108
- CUESTIONARIO
Modelo Ventajas
Desventajas
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)
Otro aspecto importante en la
La tecnologa OO pretende
Modelo
tecnologa OO es "generalizar"
acelerar el desarrollo de sistemas
7
los componentes para que sean
de una manera iterativa e
reutilizables, lo que incrementa
incremental.
los costos de desarrollo entre un
La ventaja principal de estos
10 y 50%, por lo que resulta
modelos es que permiten fijar
imprescindible un desarrollo que
hitos ms frecuentemente,
optimice esta inversin.
realizando entregas de sistemas
El inconveniente que presentan es
que son operativos cada dos o
la dificultad de gestionar de
tres meses para recibir
manera formal los proyectos que
retroalimentacin del cliente lo
siguen estos ciclos de vida
antes posible e ir adaptando la
aunque, como se ha sealado, este
aplicacin segn cambien las
problema se puede paliar
necesidades y se refinen los
diferenciando el "micro" del
requisitos
"macroproceso".
Modelo
8
Bibiana D. Rossi
109
- CUESTIONARIO
Modelo Ventajas
Desventajas
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
Bibiana D. Rossi
110
- CUESTIONARIO
Modelo Ventajas
Desventajas
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
La tecnologa de objetos pretende
La tecnologa de objetos
Modelo
generalizar los componentes para
pretende acelerar el desarrollo de
9
que sean reutilizables, lo que
sistemas de una manera iterativa
incrementa los costos de
e incremental.
desarrollo entre un 10 y un 50%,
Permite fijar hitos ms
por lo que resulta imprescindible
frecuentemente, realizando
un desarrollo que optimice esta
entregas de sistemas que son
inversin.
operativos cada dos o tres
Dificultad de gestionar de manera
meses, para recibir
formal los proyectos que siguen
retroalimentacin del cliente lo
estos ciclos de vida aunque, como
antes posible e ir adaptando la
se ha sealado, este problema se
aplicacin segn cambian las
puede paliar diferenciando el
necesidades y se refinan los
micro del macroproceso
requisitos.
En algunos casos tiene un alto
El enfoque evolutivo que el
costo de puesta en marcha (7)
macroproceso adopta para el
Tiene problemas de eficacia en
desarrollo significa que hay
ciertos casos particulares (7)
oportunidades para identificar
El microproceso del desarrollo
problemas en momentos
orientado a objetos es inestable de
tempranos del ciclo de vida y
forma innata y requiere una
responder convenientemente a
direccin activa para forzar su
estos riesgos antes de que
conclusin (7)
comprometan el xito del
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)
Bibiana D. Rossi
111
- CUESTIONARIO
Modelo Ventajas
Desventajas
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
11
Contiene procesos de
abstraccin separados hasta que
se obtiene una especificacin
formal (2)
Modelo
12
Bibiana D. Rossi
112
- CUESTIONARIO
Modelo Ventajas
Desventajas
No es fcil de aplicar cuando el
Modelo
Facilita el logro de objetivos de
proyecto es de gran tamao(3)
13
desarrollo de soft para muchos
Requiere que el problema y su
proyectos (3)
Es prctico en el uso del enfoque
solucin estn bien comprendidos
top-down step-wise.
Tiene problemas en escalar a
Modelo
Incorpora al ciclo de vida un
sistemas muy grandes (2)
14
marco conceptual para
Tiene problemas en acomodar
incorporar capacidades de
familias de programas (2)
programacin automtica,
Tiene problemas en manejar
transformacin de programas y
opciones entre nuevas y antiguas
asistentes basados en
capacidades (2)
conocimiento (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
Es difcil que soporte
iteracin del ciclo de desarrollo
automatizacin completa (4)
entero
La descomposicin top-down es
Provee de puntos tiles de
difcil y riesgosa (4)
chequeo (milestones) (4)
Los requerimientos formales son
Modelo
Los requerimientos formales
inaccesibles para los usuarios
16
pueden ser procesados por la
finales y otras personas no
maquina La especificacin
tcnicas (4)
ejecutable provee resultados
Presenta peligro de decisiones de
tempranos. (4)
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
Bibiana D. Rossi
113
- RESULTADOS SESION I
Modelo en CASCADA
ITEM
Bibiana D. Rossi
114
- RESULTADOS SESION I
Bibiana D. Rossi
115
- RESULTADOS SESION I
Modelo en ESPIRAL
ITEM
Bibiana D. Rossi
116
- RESULTADOS SESION I
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
Permite vuelta atrs a etapas anteriores cuando se requiere la
resolucin de algn tpico nuevo de riesgo
Permite vuelta atrs a etapas anteriores de la espiral cuando son
identificadas mejores alternativas
Acomoda iteraciones, vuelta atrs y terminacin prematura de
proyectos no viables
Identificar los riesgos asociados con cada una de las alternativas y las
diferentes maneras de resolverlos.
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
Es necesario definir explcitamente estrategias para realizar anlisis de
riesgo
Permite vuelta atrs a etapas anteriores cuando se requiere la
resolucin de algn tpico nuevo de riesgo
Permite vuelta atrs a etapas anteriores de la espiral cuando son
identificadas mejores alternativas
Acomoda iteraciones, vuelta atrs y terminacin prematura de
proyectos no viables
Identificar los riesgos asociados con cada una de las alternativas y las
diferentes maneras de resolverlos.
Es necesario definir mecanismos explcitos para incorporar objetivos
de calidad en el desarrollo del producto (anlisis de riesgo)
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.
Bibiana D. Rossi
117
SESION C.2
C.2.1 Preparacin de la Sesin II
Expertos asistentes: Prof. Perichinsky, Lic. Beltrami, Lic. Leone, Ing. Pollo
Cattaneo, Lic. Lucchini, Ing. Weschler, Lic. Fernndez.
Tiempo: 18 a 21.00hs.
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.
Bibiana D. Rossi
118
Bibiana D. Rossi
119
- CUESTIONARIO SESION II
Proyecto:
proyecto en
Tcnicas Utilizadas:
Tcnica usada
Resultado
Entrevistas
Estudio de viabilidad
Anlisis de
textos
vida
Mtodo Delphi
Bibiana D. Rossi
120
- CUESTIONARIO SESION II
Acerca de la Sesin II
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.
Bibiana D. Rossi
121
- CUESTIONARIO SESION II
Experto:
SIGLA
BREVE EXPLICACION
MODELO
CASCADA
AREA
MODELO
ORIENTADO A
OBJETOS
AREA
MODELO
ESPIRAL
AREA
Bibiana D. Rossi
122
- RESULTADOS SESION II
Bibiana D. Rossi
123
- RESULTADOS SESION II
Bibiana D. Rossi
124
- RESULTADOS SESION II
Bibiana D. Rossi
125
- RESULTADOS SESION II
Bibiana D. Rossi
126
- RESULTADOS SESION II
Bibiana D. Rossi
127
SESION C.3
C.3.1 Preparacin de la Sesin III
Preparacin de la sesin:.
No se ha preparado un cuestionario. Se presentan los resultados de la sesin
anterior y se solicita que lo revisen.
Expertos asistentes: Prof. Perichinsky, Lic. Beltrami, Lic. Leone, Ing. Pollo
Cattaneo, Lic. Lucchini, Ing. Weschler, Lic. Fernndez
Tiempo: 18 a 21.00hs.
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.
Bibiana D. Rossi
128
Bibiana D. Rossi
129
Bibiana D. Rossi
130
Bibiana D. Rossi
131
Bibiana D. Rossi
132
Bibiana D. Rossi
133
Bibiana D. Rossi
134
Bibiana D. Rossi
135
Pasos a seguir:
Identificacin de los elementos
Identificacin de las caractersticas
Diseo de la parrilla
Formalizacin
Anlisis de resultados
Bibiana D. Rossi
136
Bibiana D. Rossi
137
E2
OBJETOS
E3
ESPIRAL
10
REQ. EXPLICITADOS
C2:
REQ. INCOMPLETOS
INDEPENDENCIA
C3:
10
10
10
10
10
10
10
RESP. TERCEROS
C10:
NO VERSION TEMPRANA
10
ALTO RIESGO
C12:
C9:
PROT. NO DISPONIBLE
VERSION TEMPRANA
C11:
C8:
NO SOFT. SSBBCC
PROT. DISPONIBLE
C10:
C7:
NO SOFT. BASE
SOFT. SSBBCC
C9:
C6:
BAJO GRAFICO
SOFT. BASE
C8:
C5:
BAJO MATEMATICO
FUERTE GRAFICO
C7:
C4:
APL. BATCH
FUERTE MATEMATICO
C6:
C3:
SUB. SIMPLES
APL. INTERACTIVA
C5:
C2:
DEPENDENCIA
SUB. COMPLEJOS
C4:
C1:
C11:
BAJO RIESGO
C12:
RESP. ORGANIZACION
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.
Bibiana D. Rossi
138
E1
E2
69
E1
E3
82
E2
37
E3
E2-E3
E2-E3
E1
69
E1
69
37
E2
E3
E1
Bibiana D. Rossi
139
C2
C3
C4
C5
C6
C7
C8
C9
C10
C11
C12
16
15
17
18
15
18
17
16
17
16
10
18
19
16
19
18
17
11
18
C1
C2
14
C3
C4
18
C5
14
11
12
11
17
14
13
14
15
11
C6
20
19
13
19
C7
21
20
14
22
20
C8
18
17
11
19
20
C9
21
20
14
22
23
20
C10
20
19
13
21
22
19
22
C11
19
18
12
20
21
18
21
20
C12
15
16
14
17
20
19
18
NC2
C3
C4
C5
C6
C7
C8
C9
C10
C11
NC12
10
11
11
13
13
12
11
NC1
NC2
C3
C4
C5
C6
C7
C8
C9
C10
C11
NC12
11
C3
C4
10
NC2
7
2
NC1
11
6
C5
Bibiana D. Rossi
140
6
9
[C8-C9-C10-C11-NC12]
[NC1-NC2-C3]
C5
[C6-C7] [C4]
C5
[C8-C9-C10-C11-NC12]
[NC1-NC2-C3]
[C6-C7] [C4]
[C8-C9-C10-C11-NC12]
[NC1-NC2-C3]
C5
2
1
C6
C7
C4
C8
C9
C5
Bibiana D. Rossi
141
SESION A.4
A.4.1 Preparacin de la Sesin IV
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-NC2C3)
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
Bibiana D. Rossi
142
Bibiana D. Rossi
143
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.
Bibiana D. Rossi
144
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.
5.6 CONCLUSIN DE
CONOCIMIENTOS
LA
FASE
PRIMARIA
DE
ADQUISICIN
DE
Bibiana D. Rossi
145
Bibiana D. Rossi
146
Captulo 6
Conceptualizacin
de Conocimientos
02/09/2003
Bibiana D. Rossi
149
PROCESO ANALISIS
PROCESO SINTESIS
CONOCIMIENTOS
ESTRATEGICOS
MODELO DINAMICO
PROCESOS
CONOCIMIENTOS
TACTICOS
MAPA DE
CONOCIMIENTOS
MODELO ESTATICO
CONCEPTOS Y
RELACIONES
CONOCIMIENTOS
FACTICOS
CONCEPTUAIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
150
CONCEPTUAIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
151
Aplicacin
Batch
Cliente
Comienzo del proyecto
Comportamiento dinmico
Comportamiento interactivo
Comprensin
Emisin gradual
Extensin
CONCEPTUAIZACIN DE CONOCIMIENTOS
DESCRIPCION
Conjunto de operaciones que siguen un proceso
predefinido para la solucin de un problema. Principio
opuesto a la heurstica.
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.
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.
Procesamiento diferido. Modalidad de procesamiento
informtico con carga y control de informacin por lotes
y ejecucin normalmente diferida
Ver Usuario.
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.
Forma de procesamiento donde el ordenador recibe y/o
procesa la informacin en el momento inmediatamente
(sin diferir). Usualmente el comportamiento dinmico es
interactivo
Forma de procesamiento en que el usuario dialoga con
un ordenador. Usualmente el comportamiento interactivo
es dinmico.
Proceso de anlisis del dominio de conocimiento de las
partes componentes de un sistema
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.
Se refiere a los sistemas o elementos externos a la
aplicacin que se vinculan con ella recibiendo o
enviando informacin. Ver Lmites del sistema.
Se dice que algo es conveniente cuando es necesario y
factible
Se dice que algo es factible cuando es una alternativa
posible de aplicar o seleccionar, considerando los
aspectos polticos y de recursos
Se dice que algo es necesario cuando existen razones
que justifican, condicionan su aplicacin o seleccin
considerando los recursos disponibles y los aspectos
polticos
Se refiere a cuando es necesario dar mayor
funcionalidad a las funciones o procesos existentes
02/09/2003
Bibiana D. Rossi
152
Manipulacin
Pocas opciones de diseo
Pocas opciones de
implementacin
Problemas de Arquitectura
Problemas de Eficacia
Progresin no uniforme y
secuencial de las fases
Progresin uniforme y
secuencial de las fases
Proyecto
Redefinicin
Requerimientos
Requisitos
CONCEPTUAIZACIN DE CONOCIMIENTOS
DESCRIPCION
definidos e implementados en un sistema. Se extienden
las funciones ya existentes, no aumentan las funciones
sino algn aspecto de alguna de ellas
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.
Proceso de diseo de las partes componentes de un
sistema o aplicacin.
No mas de tres posibilidades de modelos formales o de
diseo a partir de un modelo de anlisis
No mas de dos posibilidades de modelos
implementables computacionalmente.
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.
Incumplimiento de Restricciones en el cumplimiento de
los objetivos vinculadas a la arquitectura de un sistema.
Las actividades que es necesario realizar durante el
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.
Las actividades que es necesario realizar durante el
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)
Conjunto integrado de planes, tareas, actividades y
operaciones necesarias para planificar y desarrollar un
sistema o una aplicacin.
Ver Aplicacin
Se refiere a cuando se cambian los procedimientos de
una o varias funciones principales ya definidas e
implementadas en un sistema
Es la especificacin de que informacin debe brindar el
sistema o aplicacin informtica. Se usa como sinnimo
de Requisitos.
Ver 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
02/09/2003
Bibiana D. Rossi
153
Requisitos definidos
exhaustivamente
Requisitos definidos
formalmente
Requisitos definidos
Incompletos
Requisitos definidos
informalmente
Requisitos definidos
mayoritariamente
Requisitos definidos
parcialmente
Requisitos definidos
uniformemente
Sistema
Sistema de Informacin
Software de base
Subsistemas
Tiempo Real
CONCEPTUAIZACIN DE CONOCIMIENTOS
DESCRIPCION
Que se han definido las restricciones que debe cumplir
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.
Que se han definido en detalle y sin omisiones, las
restricciones que debe cumplir el sistema a desarrollar.
Que se han definido las restricciones que debe cumplir
el sistema a desarrollar en forma expresa (en algn
documento o informe) y con precisin. Que se ha
observado alguna metodologa de documentacin.
Que se han definido genricamente y con posibilidad de
omisiones, las restricciones que debe cumplir el sistema
a desarrollar.
Que se han definido las restricciones que debe cumplir
el sistema a desarrollar en forma imprecisa y que no
estn expresamente documentados. Que no se ha
observado alguna metodologa de documentacin.
Cuando el usuario manifiesta que se encuentran
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.
Cuando el usuario manifiesta que se encuentran
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.
Que se han definido las restricciones que debe cumplir
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.
Forma abreviada de referirse a Sistema de Informacin.
Ver Aplicacin
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.
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.
Componentes o partes distinguibles de una aplicacin.
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.
02/09/2003
Bibiana D. Rossi
154
CONCEPTUAIZACIN DE CONOCIMIENTOS
DESCRIPCION
Persona que usa el sistema informtico. Persona que
contrata el desarrollo del sistema. Suele usarse Cliente
como sinnimo.
Cuatro o ms posibilidades de modelos formales o de
diseo a partir de un modelo de anlisis
Tres o ms posibilidades de modelos formales
implementables computacionalmente.
02/09/2003
Bibiana D. Rossi
155
FUNCION
SINNIMOS/
ACRONIMOS
Proyecto
Requisitos
Aplicacin
Coordinacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Sistema
Bibiana D. Rossi
ATRIBUTOS
DERIVADO DE
Identificacin
Nombre del proyecto
Lder del proyecto
Objetivo
Fecha inicio
Fecha finalizacin
CV propuesto por SE
CV seleccionado
Tipo de definicin
Grado de certidumbre
Grado de cumplimiento
Definicin requisitos
Definicin lmites
Niveles de Composicin
Complejidad Subsistemas
Componentes Predominantes
Comportamiento Predominante
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
Formalidad
Entregas
FUNCION
SINNIMOS/
ACRONIMOS
ATRIBUTOS
Responsabilidad
Control gestin
Software para prototipar
Factibilidad metodologa
Necesidad metodologa
Reso aplicacin existente
Reso aplicacin OO
Reso aplicacin futura
Procedimientos cambios
Procedimientos DesarrolloMantenimiento
Conveniencia Metodologa
Factibilidad Prototipo
Sistema OO
Entrega Intermedia
Aplicabilidad Espiral
Aplicabilidad Prototipo
Aplicabilidad OO
Procedimientos D-M
Usuario
Equipo de proyecto
Experiencia tcnicas de IS
Experiencia previa
Viabilidad software
Nivel de riesgo
Anlisis riesgo
Tcnicas AR
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Cliente / operador
DERIVADO DE
Bibiana D. Rossi
Participacin
Introduccin gradual
157
FUNCION
SINNIMOS/
ACRONIMOS
rea Requisitos
rea Aplicacin
rea Gestin
Proyecto
CV Diagnstico
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
ATRIBUTOS
Identificacin Alternativas
Riesgos Alternativa
Categoras riesgo
Objetivo calidad
Terminacin Proyectos
Riesgo Cascada
Riesgo Objetos
Habilidad Riesgo
Factor Riesgo
Riesgo Espiral
Riesgo
CV Propuesto Requisitos
CV Propuesto Aplicacin
CV Propuesto Gestin
DERIVADO DE
158
ATRIBUTO
VALOR
Identificacin
Cdigo alfanumrico
Descripcin (texto)
Nombre y Apellido
Objetivo
Fecha inicio
DD / MM /AAAA
Fecha finalizacin
DD / MM /AAAA
CV propuesto por SE
Proyecto
Cascada
Espiral
Objetos
Cascada
Espiral
Objetos
Otro
CV seleccionado
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
159
ATRIBUTO
Tipo de Definicin
Requisitos
Requerimientos
VALOR
Formalmente
Informalmente
Exhaustivamente
Incompleto
Uniformemente
Desestructuradamente
Definicin Clara
Definicin Incierta
Alta incertidumbre
Baja incertidumbre
Definicin Clara
Definicin Incierta
Alta incertidumbre
Baja incertidumbre
Mayoritariamente definidos (> = 90%)
Parcialmente definidos (< 90%)
Aplicacin
Sistema
Complejidad Subsistemas
Comportamiento Predominante
Orientacin
Niveles de Composicin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
160
ATRIBUTO
Progresin Fases desarrollo
Relacin Fases desarrollo
Factores Diseo
(a considerar en etapas tempranas del desarrollo)
Existencia Aplicaciones
(similares en el mercado)
Posibilidad Diseo
Posibilidad Implementacin
Modelado Prototipo
Modelado Objetos
Variabilidad Procesos
Tipo modificacin
(explcitamente previstas en datos y procesos)
Opcionalidad
Formalidad
Coordinacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
VALOR
Uniforme y Secuencial
No Uniforme y Secuencial
Poca Dependencia
Mucha Dependencia
Independencia
Baja
Alta
Fuertemente
Medianamente
Levemente
Problemas de Arquitectura
Problemas de eficacia
Innovador
Conocido
Pocas opciones
Varias opciones
Pocas opciones
Varias opciones
Conveniente
No conveniente
Conveniente
No conveniente
Alta
Baja
Redefinicin
Extensin
Ampliacin
Emisin gradual
Mltiple
Simple
Poco formal
Medianamente formal
161
ATRIBUTO
VALOR
Muy formal
Entregas
Responsabilidad
Control gestin
Factibilidad Metodologa
Necesidad Metodologa
Reso aplicacin OO
Procedimientos Cambios
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
Versin temprana
Versin completa
Versin gradual
Versin parcial
Terceros
Organizacin propia
Muy ajustado
Medianamente ajustado
Poco ajustado
No disponible
Hay disponible
Factible de adquirir
No adquirible
Ampliamente probada
Medianamente probada
Poco probada
Ampliamente probada
Medianamente probada
Poco probada
Estrategias explcitas
No estrategias explcitas
Muy necesario
Medianamente necesario
Poco necesario
Subsistema del existente
Ampliacin del existente
Modificacin del existente
Componentes del actual
Acuerdos confirmados
No Acuerdos confirmados
162
ATRIBUTO
Procedimientos Desarrollo-Mantenimiento
Conveniencia Metodologa
Factibilidad Prototipo
Sistema OO
Entrega Intermedia
Aplicabilidad Espiral
Aplicabilidad Prototipo
Aplicabilidad OO
Procedimientos D-M
Participacin
Usuario / cliente
Introduccin gradual
Equipo de proyecto
Experiencia tcnicas IS
Experiencia previa
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
VALOR
Es factible usar los mismos
Es factible usar diferentes
Es necesario usar los mismos
Es necesario usar diferentes
Ampliamente probada
Medianamente probada
Poco probada
Factible
No factible
Existe
No existe
Existe
No existe
Aplicable
No aplicable
Aplicable
No aplicable
Aplicable
No aplicable
Conveniente
No conveniente
Fuerte
Regular
Poca
Necesaria
No necesaria
Hay
No hay
Hay
No hay
163
ATRIBUTO
Viabilidad software
Nivel de riesgo
Anlisis riesgo
Tcnicas AR
Identificacin Alternativas
Riesgos Alternativa
Categoras riesgo
Objetivo calidad
Terminacin Proyectos
Riesgo Cascada
Riesgo Objetos
Habilidad Riesgo
Factor Riesgo
Riesgo Espiral
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
VALOR
Hay certeza
Hay dudas
Alto riesgo
Mediano riesgo
Bajo riesgo
No hay riesgo
Estrategias explcitas
No estrategias explcitas
Se dispone
No se dispone
Se identifican
No se identifican
Etapas anteriores
Se identifican
No se identifican
Etapas anteriores
Tcnicos
Otros riesgos
Mecanismos explcitos
No mecanismos explcitos
Prematura
En trmino.
Aceptable
No aceptable
Aceptable
No aceptable
Existe
No existe
Existe
No existe
Aceptable
No aceptable
164
ATRIBUTO
Riesgo
Area Requisitos
CV Propuesto Requisitos
Area Aplicacin
CV Propuesto Aplicacin
CV Propuesto Gestin
CV Diagnstico
CV Propuesto Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
VALOR
Evaluable
No evaluable
Cascada
Objetos
Cascada
Objetos
Cascada
Objetos
Cascada
Objetos
Espiral
No hay propuesta
Espiral
No hay propuesta
Espiral
No hay propuesta
Espiral
No hay propuesta
165
ENTRE
REQUISITOS
SE ESTIMAN
SE ESTIMAN
AREA
REQUISITOS
SE SUGIERE
APLICACION
AREA
APLICACION
SE SUGIERE
1
1
CV
DIAGNOSTICO
PROYECTO
SE PROPONE
SE PROPONE
1
N
N
USUARIO
SE SUGIERE
SE ESTIMAN
N
N
SE ESTIMAN
SE ESTIMAN
EQUIPO DE
PROYECTO
SE SUGIERE
1
SE PROPONE
AREA
GESTION
PROYECTO
COORDINACION
RIESGOS DEL
PROYECTO
SE SUGIERE
SE SUGIERE
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
166
de
de
de
de
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
167
1. SELECCION DEL
CV DEL
PROYECTO
1.1.1
ANALIZAR
DEFINICION
REQUERIMIENTOS
1.1.2
ESTIMAR
LIMITES
1.1.3
ESTIMAR
NIVEL
EXIGENCIA
EN EL
PRODUCTO
FINAL
1.2.1
ESTIMAR
FACTORES
PREDOMINANTES
1.2.2
ANALIZAR
FACTORES
PROTOTIPACION
1.2.3
ESTIMAR
NIVEL
OPCIONES
1.2.4
ESTIMAR
INTEGRACION
HW-SW
1.3.1.1
ESTIMAR
FACTORES
REUSO
1.3.1
ANALIZAR
COORDINACION
1.3.1.2
ESTIMAR
FACTORES
MANTENIMIENTO
1.3..2
ESTIMAR
RELACION
CON
USUARIO
1.3.1.3
ESTIMAR
RECURSOS
SOFTWARE
1.3.3
ESTIMAR
FACTORES
EQUIPO
PROYECTO
1.3.1.4
ESTIMAR
FACTORES
ADMINISTRACION
1.3.4
ANALIZAR
RIESGOS
DEL
PROYECTO
1.3.4.1
ESTIMAR
RIESGO
EXISTENTE
1.3.4.2
ESTIMAR
HABILIDAD
PARA
EVALUAR
RIESGO
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
168
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
Entrada- Origen de la Entrada:
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.
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
169
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
170
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
171
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.
Salida- Destino de la Salida:
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.
Entrada- Origen de la Entrada:
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 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.
Salida- Destino de la Salida:
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.
Entrada- Origen de la Entrada:
Los valores ingresados por el usuario del sistema experto para los atributos
grado de cumplimiento en producto final.
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
172
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.
Salida- Destino de la Salida:
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
aplicacin a desarrollar.
Entrada- Origen de la Entrada:
Los valores ingresados por el usuario del sistema experto para los atributos
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
Salida- Destino de la Salida:
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.
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
173
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
174
Razonamiento:
Si la aplicacin requiere una fuerte integracin hardware-software es
conveniente aplicar el ciclo de vida en espiral.
Salida- Destino de la Salida:
Valores ingresados por el usuario con destino a la Base de Conocimientos.
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.
Para llevar a cabo la tarea el sistema debe realizar las siguientes
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
Entrada- Origen de la Entrada:
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
Salida- Destino de la Salida:
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.
Entrada- Origen de la Entrada:
Los valores ingresados por el usuario del sistema experto para los atributos
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.
Salida- Destino de la Salida:
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
175
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
176
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
177
Razonamiento:
El modelo por prototipo es factible si se dispone de software para prototipar
o es posible adquirirlo.
Salida- Destino de la Salida:
Los valores ingresados por el usuario con destino la Base de
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.
Entrada- Origen de la Entrada:
Los valores ingresados por el usuario del sistema experto para los atributos
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.
Salida- Destino de la Salida:
Los valores ingresados por el usuario con destino la Base de
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.
Entrada- Origen de la Entrada:
Los valores ingresados por el usuario del sistema experto para los atributos
Viabilidad del software, Factor de riesgo, Categoras riesgo, Estrategias
para incorporar calidad y Terminacin de proyectos.
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
178
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.
Salida- Destino de la Salida:
Los valores ingresados por el usuario con destino la Base de
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.
Entrada- Origen de la Entrada:
Los valores ingresados por el usuario del sistema experto para los atributos
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.
Salida- Destino de la Salida:
Los valores ingresados por el usuario con destino la Base de
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
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
179
Texto de la regla
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
180
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
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
Si
Tipo de Definicin es igual a formalmente y
exhaustivamente y uniformemente
Entonces
Definicin Requisitos es definicin clara y Definicin
Lmites es definicin clara.
REGLA ER-R1
Tabla 6-4: Seleccin del Ciclo de vida para el rea Especificacin de Requerimientos
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
181
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
Si
Definicin Requisitos es definicin clara y Definicin Limites
es definicin clara y Grado de Certidumbre al inicio del
proyecto es Mayoritariamente definidos
Entonces
CV Propuesto Requisitos es Cascada.
REGLA ER-R2
Tabla 6-5: Seleccin del Ciclo de vida para el rea Especificacin de Requerimientos
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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.
Si
Tipo de Definicin es igual a informalmente e incompleto y
desestructuradamente
Entonces
Definicin Requisitos es definicin incierta y Definicin
Limites es definicin incierta.
REGLA ER-R3
Tabla 6-6: Seleccin del Ciclo de vida para el rea Especificacin de Requerimientos
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
La Especificacin de Requerimientos indica usar modelo en
Espiral y La Especificacin de requerimientos indica usar
modelo de Objetos.
Si
Definicin Requisitos es definicin incierta y Definicin
Limites es definicin incierta y Grado de Certidumbre al
inicio del proyecto es Parcialmente definidos
Entonces
CV Propuesto Requisitos es Espiral y Objetos.
REGLA ER-R4
Tabla 6-7: Seleccin del Ciclo de vida para el rea Especificacin de Requerimientos
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
182
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El usuario es muy exigente con los requerimientos del
sistema respecto del producto final.
Entonces
La Especificacin de Requerimientos indica usar modelo en
Espiral y La Especificacin de requerimientos indica usar
modelo de Objetos.
Si
Grado de Cumplimiento en Producto final es Usuario muy
exigente.
Entonces
CV Propuesto Requisitos es Espiral y Objetos.
REGLA ER-R5
Tabla 6-8: Seleccin del Ciclo de vida para el rea Especificacin de Requerimientos
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se presume independencia entre las fases del desarrollo del
proyecto
Entonces
La necesidad de retroalimentacin en las fases del desarrollo
del proyecto es baja
Si
Relacin Fases desarrollo es igual a Independencia
Entonces
Retroalimentacin Fases Desarrollo es baja
REGLA CV-R1
Tabla 6-9: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se presume poca dependencia entre las fases de desarrollo
del proyecto
Entonces
La necesidad de retroalimentacin en las fases del desarrollo
del proyecto es baja
Si
Relacin Fases desarrollo es igual a Poca Dependencia
Entonces
Retroalimentacin Fases Desarrollo es baja
REGLA CV-R2
Tabla 6-10: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
183
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se presume mucha dependencia entre las fases de desarrollo
del proyecto
Entonces
La necesidad de retroalimentacin en las fases del desarrollo
del proyecto es alta
Si
Relacin Fases desarrollo es igual a Mucha Dependencia
Entonces
Retroalimentacin Fases Desarrollo es alta
REGLA CV-R3
Tabla 6-11: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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.
Si
Progresin Fases Desarrollo es uniforme y secuencial y
Retroalimentacin Fases Desarrollo es baja y Componentes
Predominantes es algortmicos.
Entonces
CV Propuesto Aplicacin es Cascada
REGLA CV-R4
Tabla 6-12: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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 tipo de aplicacin presenta un
comportamiento predominantemente BATCH
Entonces
Las caractersticas del Tipo Aplicacin indican usar modelo en
Cascada
Si
Progresin Fases Desarrollo es uniforme y secuencial y
Retroalimentacin Fases Desarrollo es baja y Comportamiento
Predominante es batch
Entonces
CV Propuesto Aplicacin es Cascada
REGLA TA-R101
Tabla 6-13: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
184
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se puede asumir una progresin relativamente uniforme y
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
Si
Progresin Fases Desarrollo es uniforme y secuencial y
Complejidad subsistemas es baja y Componentes
Predominantes es algortmico
Entonces
CV Propuesto Aplicacin es Cascada
REGLA TA-R102
Tabla 6-14: Seleccin del Ciclo de vida para el rea Tipo de aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
Si
Progresin Fases Desarrollo es uniforme y secuencial y
Complejidad subsistemas es baja y Comportamiento
Predominante es batch
Entonces
CV Propuesto Aplicacin es Cascada
REGLA TA-R103
Tabla 6-15: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se puede asumir una progresin NO uniforme y secuencial
en las fases de desarrollo del proyecto
Entonces
Las tcnicas de prototipacin son ms convenientes.
Si
Progresin Fases Desarrollo es No uniforme y secuencial
Entonces
Modelado Prototipo es Conveniente
REGLA CV-R5
Tabla 6-16: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
185
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La necesidad de retroalimentacin en las fases del desarrollo
del proyecto es alta
Entonces
Las tcnicas de prototipacin son ms convenientes
Si
Retroalimentacin Fases Desarrollo es alta
Entonces
Modelado Prototipo es Conveniente
REGLA CV-R6
Tabla 6-17: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
Si
Niveles de Composicin es Pocos Subsistemas
Entonces
Complejidad Subsistemas es Baja
REGLA TA-R1
Tabla 6-18: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
Si
Niveles de Composicin es Varios Subsistemas
Entonces
Complejidad Subsistemas es Alta
REGLA TA-R2
Tabla 6-19: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
186
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El sistema se basa en componentes de fuerte contenido
matemtico
Entonces
Las tcnicas de modelado OO son ms convenientes
Si
Componentes Predominantes es matemticos
Entonces
Modelado Objetos es Conveniente
REGLA TA-R4
Tabla 6-20: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El sistema se basa en componentes de fuerte contenido
grfico
Entonces
Las tcnicas de modelado OO son ms convenientes
Si
Componentes Predominantes es grficos
Entonces
Modelado Objetos es conveniente
REGLA TA-R5
Tabla 6-21: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El sistema tiene subsistemas que presentan comportamiento
dinmico
Entonces
Las tcnicas de modelado OO son ms convenientes
Si
Comportamiento Predominante es dinmico
Entonces
Modelado Objetos es Conveniente
REGLA TA-R3
Tabla 6-22: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El tipo de aplicacin presenta comportamiento fuertemente
interactivo
Entonces
Las tcnicas de modelado OO son ms convenientes
Si
Comportamiento Predominante es interactivo
Entonces
Modelado Objetos es Conveniente
REGLA TA-R7
Tabla 6-23: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
187
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El tipo de aplicacin presenta comportamiento en Tiempo
Real
Entonces
Las tcnicas de modelado OO son ms convenientes
Si
Comportamiento Predominante es tiempo real
Entonces
Modelado Objetos es Conveniente
REGLA TA-R8
Tabla 6-24: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El tipo de aplicacin es desarrollo de software de base
Entonces
Las tcnicas de modelado OO son ms convenientes
Si
Orientacin es software de base
Entonces
Modelado Objetos es Conveniente
REGLA TA-R9
Tabla 6-25: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El sistema es explcitamente sensible a cambios
Entonces
El sistema presenta una alta variabilidad en los procesos
Si
Tipo Modificacin es Redefinicin
Entonces
Variabilidad Procesos es Alta
REGLA TA-R11
Tabla 6-26: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El sistema es explcitamente sensible a extensiones
Entonces
El sistema presenta una alta variabilidad en los procesos
Si
Tipo Modificacin es Extensin
Entonces
Variabilidad Procesos es Alta
REGLA TA-R12
Tabla 6-27: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
188
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El sistema es explcitamente sensible a ampliaciones.
Entonces
El sistema presenta una alta variabilidad en los procesos
Si
Tipo Modificacin es Ampliacin
Entonces
Variabilidad Procesos es Alta
REGLA TA-R13
Tabla 6-28: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El proyecto requiere el descubrimiento de problemas de
arquitectura en etapas tempranas del desarrollo
Entonces
Las tcnicas de prototipacin son ms convenientes
Si
Factores Diseo es Problemas de Arquitectura
Entonces
Modelado Prototipo es Conveniente
REGLA TA-R14
Tabla 6-29: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El proyecto requiere el descubrimiento de problemas de
eficacia en etapas tempranas del desarrollo
Entonces
Las tcnicas de prototipacin son ms convenientes
Si
Factores Diseo es Problemas de eficacia
Entonces
Modelado Prototipo es Conveniente
REGLA TA-R15
Tabla 6-30: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El sistema presenta una alta variabilidad en los procesos
Entonces
Tcnica Modelado es Prototipo son ms convenientes
Si
Variabilidad Procesos es Alta
Entonces
Modelado Prototipo es Conveniente
REGLA TA-R16
Tabla 6-31: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
189
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El sistema a disear es innovador
Entonces
Las tcnicas de prototipacin son ms convenientes
Si
Existencia Aplicaciones es Innovador
Entonces
Modelado Prototipo es Conveniente
REGLA TA-R17
Tabla 6-32: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El tipo de aplicacin es un SSBBCC sistema basado en
conocimientos
Entonces
Las tcnicas de prototipacin son ms convenientes
Si
Orientacin es Sistema Basado en conocimiento
Entonces
Modelado Prototipo es Conveniente
REGLA TA-R18
Tabla 6-33: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El sistema presenta subsistemas complejos
Entonces
Las tcnicas de prototipacin son ms convenientes
Si
Complejidad Subsistemas es Alta
Entonces
Modelado Prototipo es Conveniente
REGLA TA-R19
Tabla 6-34: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Las tcnicas de modelado OO son ms convenientes Y
Las tcnicas de prototipacin son ms convenientes
Entonces
El Tipo de Aplicacin indica usar modelo de Objetos
Si
Modelado Objetos es conveniente y Modelado Prototipo es
conveniente
Entonces
CV Propuesto Aplicacin es Objetos
REGLA TA-R20
Tabla 6-35: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
190
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Las tcnicas de modelado OO son ms convenientes Y
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
Si
Modelado Objetos es conveniente Y Modelado Prototipo es
conveniente Y Integracin HW-SW es fuertemente
Entonces
CV Propuesto Aplicacin es Espiral
REGLA TA-R21
Tabla 6-36: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El sistema a desarrollar puede resolverse por varias opciones
de diseo
Entonces
El sistema es multiopcional
Si
Posibilidad Diseo es Varias opciones
Entonces
Opcionalidad es Mltiple
REGLA TA-R22
Tabla 6-37: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El sistema a desarrollar puede resolverse por varias opciones
de implementacin
Entonces
El sistema es multiopcional
Si
Posibilidad Implementacin es Varias opciones
Entonces
Opcionalidad es Mltiple
REGLA TA-R23
Tabla 6-38: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
191
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Las tcnicas de modelado OO son ms convenientes Y
Las tcnicas de prototipacin son ms convenientes Y
El sistema es multiopcional
Entonces
El Tipo de Aplicacin indica usar modelo en Espiral
Si
Modelado Objetos es conveniente Y Modelado Prototipo es
conveniente Y Opcionalidad es Mltiple
Entonces
CV Propuesto Aplicacin es Espiral
REGLA TAR-24
Tabla 6-39: Seleccin del Ciclo de vida para el rea Tipo de Aplicacin
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es necesario usar metodologas ampliamente probadas Y Es
factible usar metodologas ampliamente probadas
Entonces
Es conveniente usar metodologas ampliamente probadas
Si
Necesidad Metodologa es ampliamente probada Y
Factibilidad Metodologa es ampliamente probada
Entonces
Conveniencia Metodologa es ampliamente probada
REGLA GP-R1
Tabla 6-40: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El factor de riesgo es bajo
Entonces
El riesgo es aceptable para modelo en cascada
Si
Nivel riesgo es bajo
Entonces
Riesgo Cascada es aceptable
REGLA GP-R2
Tabla 6-41: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
No hay factor de riesgo
Entonces
El riesgo es aceptable para modelo en cascada
Si
Nivel riesgo es no hay riesgo
Entonces
Riesgo Cascada es aceptable
REGLA GP-R4
Tabla 6-42: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
192
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
Si
Conveniencia Metodologa es ampliamente probada Y Entregas
es versin completa Y Riesgo Cascada es aceptable
Entonces
CV Propuesto Gestin es Cascada
REGLA GP-R5
Tabla 6-43: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
La Gestin del Proyecto indica usar modelo en Cascada
Si
Formalidad es muy formal Y Entregas es versin completa Y
Riesgo Cascada es aceptable
Entonces
CV Propuesto Gestin es Cascada
REGLA GP-R14
Tabla 6-44: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
No se dispone de software para prototipar y no es posible
adquirir software para prototipar
Entonces
El modelo por prototipo no es factible
Si
Software para prototipar es No disponible y No adquirible
Entonces
Factibilidad Prototipo es No factible
REGLA GP-R3
Tabla 6-45: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
193
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El modelo por prototipo no es factible Y El riesgo es
aceptable para modelo en cascada
Entonces
La Gestin del Proyecto indica usar modelo en Cascada
Si
Factibilidad Prototipo es No factible Y Riesgo Cascada es
aceptable
Entonces
CV Propuesto Gestin es Cascada
REGLA GP-R16
Tabla 6-46: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
La Gestin del Proyecto indica usar modelo en Cascada
Si
Responsabilidad es Terceros Y Control gestin es muy
ajustado Y Entregas es versin completa
Entonces
CV Propuesto Gestin es Cascada
REGLA GP-R6
Tabla 6-47: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es un subsistema de un sistema desarrollado en Objetos
Entonces
Existe sistema anterior desarrollado en Objetos
Si
Reso aplicacin OO es Subsistema del existente
Entonces
Sistema OO es existe
REGLA GP-R7
Tabla 6-48: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es una ampliacin de un sistema desarrollado en Objetos
Entonces
Existe sistema anterior desarrollado en Objetos
Si
Reso aplicacin OO es Ampliacin del existente
Entonces
Sistema OO es existe
REGLA GP-R8
Tabla 6-49: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
194
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es una modificacin de un sistema desarrollado en Objetos
Entonces
Existe sistema anterior desarrollado en Objetos
Si
Reso aplicacin OO es Modificacin del existente
Entonces
Sistema OO es existe
REGLA GP-R9
Tabla 6-50: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se prev una fuerte necesidad de reutilizar los componentes
de un software ya existente desarrollado en Objetos
Entonces
Existe sistema anterior desarrollado en Objetos
Si
Reso aplicacin OO es Componentes del actual
Entonces
Sistema OO es existe
REGLA GP-R10
Tabla 6-51: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se prev una fuerte necesidad de reutilizar los componentes
de un desarrollo para el siguiente proyecto.
Entonces
Existe sistema anterior desarrollado en Objetos
Si
Reso aplicacin futura es muy necesario
Entonces
Sistema OO es existe
REGLA GP-R11
Tabla 6-52: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es necesario una versin temprana disponible del software
desarrollado
Entonces
Existen entregas intermedias
Si
Entregas es Versin temprana
Entonces
Entrega intermedia es existe
REGLA GP-R24
Tabla 6-53: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
195
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es necesario disponer de una versin temprana del software
desarrollado con funciones a completar gradualmente
Entonces
Existen entregas intermedias
Si
Entregas es Versin gradual
Entonces
Entrega intermedia es existe
REGLA GP-R25
Tabla 6-54: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es necesario disponer de una versin parcial del software
desarrollado con funciones a completar gradualmente
Entonces
Existen entregas intermedias
Si
Entregas es Versin parcial
Entonces
Entrega intermedia es existe
REGLA GP-R28
Tabla 6-55: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Existen entregas intermedias
Entonces
El modelo de Objetos es aplicable Y El modelo por prototipo
es aplicable
Si
Entrega intermedia es existe
Entonces
Aplicabilidad OO es aplicable y Aplicabilidad prototipo es
aplicable
REGLA GP-R29
Tabla 6-56: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se definen explcitamente estrategias de reso de software
existente
Entonces
El modelo de Objetos es aplicable
Si
Reso aplicacin existente es estrategias explcitas
Entonces
Aplicabilidad OO es aplicable
REGLA GP-R26
Tabla 6-57: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
196
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
No hay factor de riesgo
Entonces
El riesgo es aceptable para el modelo de Objetos
Si
Nivel riesgo es No hay riesgo
Entonces
Riesgo Objetos es aceptable
REGLA GP-R19
Tabla 6-58: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El factor de riesgo es bajo
Entonces
El riesgo es aceptable para el modelo de Objetos
Si
Nivel riesgo es bajo riesgo
Entonces
Riesgo Objetos es aceptable
REGLA GP-R12
Tabla 6-59: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El factor de riesgo es mediano
Entonces
El riesgo es aceptable para el modelo de Objetos
Si
Nivel riesgo es mediano riesgo
Entonces
Riesgo Objetos es aceptable
REGLA GP-R13
Tabla 6-60: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es necesario usar metodologas medianamente probadas Y Es
factible usar metodologas medianamente probadas
Entonces
Es conveniente usar metodologas medianamente probadas
Si
Necesidad Metodologa es medianamente probada Y
Factibilidad Metodologa es medianamente probada
Entonces
Conveniencia Metodologa es medianamente probada
REGLA GP-R37
Tabla 6-61: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
197
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El proyecto requiere una gestin de proyecto medianamente
formal Y Es conveniente usar metodologas medianamente
probadas
Entonces
El modelo de Objetos es aplicable
Si
Formalidad es medianamente formal Y Conveniencia
Metodologa es medianamente probada
Entonces
Aplicabilidad OO es aplicable
REGLA GP-R15
Tabla 6-62: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El proyecto requiere una gestin de proyecto poco formal Y Es
conveniente usar metodologas medianamente probadas
Entonces
El modelo de Objetos es aplicable
Si
Formalidad es poco formal Y Conveniencia Metodologa es
medianamente probada
Entonces
Aplicabilidad OO es aplicable
REGLA GP-R17
Tabla 6-63: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
Si
Aplicabilidad OO es aplicable Y Sistema OO es existe Y Riesgo
Objetos es aceptable
Entonces
CV Propuesto Gestin es Objetos
REGLA GPR18
Tabla 6-64: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
198
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es posible adquirir software para prototipar
Entonces
El modelo por prototipo es factible
Si
Software para prototipar es factible de adquirir
Entonces
Factibilidad prototipo es factible
REGLA GP-R20
Tabla 6-65: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se dispone de software para prototipar
Entonces
El modelo por prototipo es factible
Si
Software para prototipar es hay disponible
Entonces
Factibilidad prototipo es factible
REGLA GP-R21
Tabla 6-66: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es necesario facilitar la introduccin gradual del sistema para
los usuarios
Entonces
El modelo por prototipo es aplicable
Si
Introduccin gradual es necesaria
Entonces
Aplicabilidad prototipo es aplicable
REGLA GP-R22
Tabla 6-67: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es necesario contar con una fuerte participacin del usuario
cliente en el Desarrollo
Entonces
El modelo por prototipo es aplicable
Si
Participacin es fuerte
Entonces
Aplicabilidad prototipo es aplicable
REGLA GP-R23
Tabla 6-68: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
199
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La gestin del proyecto prev definir explcitamente
estrategias para reusar software existente.
Entonces
El modelo por prototipo es aplicable
Si
Reso aplicacin existente es estrategias explcitas
Entonces
Aplicabilidad prototipo es aplicable
REGLA GP-R29
Tabla 6-69: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Equipo de proyecto no tiene experiencia previa en el tipo de
aplicacin a desarrollar
Entonces
El modelo por prototipo es aplicable
Si
Experiencia previa es No hay
Entonces
Aplicabilidad prototipo es aplicable
REGLA GP-R27
Tabla 6-70: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Existe inexperiencia con las tcnicas de ingeniera de software
que se usarn
Entonces
El modelo por prototipo es aplicable
Si
Experiencia tcnicas IS es No hay
Entonces
Aplicabilidad prototipo es aplicable
REGLA GP-R30
Tabla 6-71: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es necesario Y factible usar los mismos procedimientos para
desarrollo y mantenimiento del producto software
Entonces
Es conveniente usar los mismos procedimientos para
desarrollo y mantenimiento del producto software
Si
Procedimientos Desarrollo-Mantenimiento es necesario usar
los mismos y es factible usar los mismos.
Entonces
Procedimientos D-M es conveniente
REGLA GP-R31
Tabla 6-72: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
200
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es conveniente usar los mismos procedimientos para
desarrollo y mantenimiento del producto software
Entonces
El modelo en Espiral es aplicable
Si
Procedimientos D-M es conveniente
Entonces
Aplicabilidad Espiral es aplicable
REGLA GP-R32
Tabla 6-73: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se requiere de acuerdos confirmados para los cambios a
efectuarse durante el desarrollo del proyecto.
Entonces
El modelo en Espiral es aplicable
Si
Procedimientos Cambios es acuerdos confirmados
Entonces
Aplicabilidad Espiral es aplicable
REGLA GP-R33
Tabla 6-74: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El desarrollo del sistema es responsabilidad de la organizacin
(no se terceriza)
Entonces
El modelo en Espiral es aplicable
Si
Responsabilidad es organizacin propia
Entonces
Aplicabilidad Espiral es aplicable
REGLA GP-R34
Tabla 6-75: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
Si
Riesgos Alternativa es se identifican Y Identificacin
alternativas es se identifican
Entonces
Habilidad Riesgo es existe
REGLA GP-R38
Tabla 6-76: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
201
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
El modelo en Espiral es aplicable
Si
Habilidad Riesgo es existe Y Identificacin Alternativas es
etapas anteriores
Entonces
Aplicabilidad Espiral es aplicable
REGLA GP-R39
Tabla 6-77: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se cuenta con habilidad para la evaluacin del riesgo Y
Es necesario volver a etapas anteriores en el desarrollo del
sistema para la resolucin de algn tpico nuevo de riesgo
Entonces
El modelo en Espiral es aplicable
Si
Habilidad Riesgo es existe Y Riesgos Alternativa es etapas
anteriores
Entonces
Aplicabilidad Espiral es aplicable
REGLA GP-R41
Tabla 6-78: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se cuenta con habilidad para la evaluacin del riesgo Y
Se estima la posibilidad de la terminacin prematura de
proyectos no viables
Entonces
El modelo en Espiral es aplicable
Si
Habilidad Riesgo es existe Y Terminacin Proyectos es
prematura
Entonces
Aplicabilidad Espiral es aplicable
REGLA GP-R42
Tabla 6-79: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
202
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Existen dudas sobre la viabilidad del software
Entonces
Existe factor de riesgo
Si
Viabilidad software es hay dudas
Entonces
Factor riesgo es existe
REGLA GP-R35
Tabla 6-80: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Se estiman riesgos tcnicos en el desarrollo del sistema
Entonces
Existe factor de riesgo
Si
Categoras riesgo es tcnico
Entonces
Factor riesgo es existe
REGLA GP-R36
Tabla 6-81: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El factor de riesgo es mediano
Entonces
El riesgo es aceptable para el modelo en Espiral
Si
Nivel riesgo es mediano riesgo
Entonces
Riesgo Espiral es aceptable
REGLA GP-R50
Tabla 6-82: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El factor de riesgo es alto
Entonces
El riesgo es aceptable para el modelo en Espiral
Si
Nivel riesgo es alto riesgo
Entonces
Riesgo Espiral es aceptable
REGLA GP-R51
Tabla 6-83: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
203
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El riesgo es aceptable para el modelo en Espiral
Entonces
Existe factor de riesgo
Si
Riesgo Espiral es aceptable
Entonces
Factor riesgo es existe
REGLA GP-R52
Tabla 6-84: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Existe factor de riesgo Y Es necesario definir explcitamente
estrategias para realizar anlisis de riesgo
Entonces
El modelo en Espiral es aplicable
Si
Factor riesgo es existe Y Anlisis riesgo es estrategias
explcitas
Entonces
Aplicabilidad Espiral es aplicable
REGLA GP-R43
Tabla 6-85: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Existe factor de riesgo Y Es necesario definir mecanismos
explcitos para incorporar objetivos de calidad en el
desarrollo del producto.
Entonces
El modelo en Espiral es aplicable
Si
Factor riesgo es existe Y Objetivo calidad es mecanismos
explcitos
Entonces
Aplicabilidad Espiral es aplicable
REGLA GP-R44
Tabla 6-86: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
204
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
Es necesario usar metodologas poco probadas Y Es factible
usar metodologas poco probadas
Entonces
Es conveniente usar metodologas poco probadas
Si
Necesidad Metodologa es poco probada Y Factibilidad
Metodologa es poco probada
Entonces
Conveniencia Metodologa es poco probada
REGLA GP-R53
Tabla 6-87: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El proyecto requiere una gestin de proyecto medianamente
formal Y Es conveniente usar metodologas poco probadas
Entonces
El modelo en Espiral es aplicable
Si
Formalidad es medianamente formal Y Conveniencia
Metodologa es poco probada
Entonces
Aplicabilidad Espiral es aplicable
REGLA GP-R54
Tabla 6-88: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
El proyecto requiere una gestin de proyecto poco formal Y Es
conveniente usar metodologas poco probadas
Entonces
El modelo en Espiral es aplicable
Si
Formalidad es poco formal Y Conveniencia Metodologa es
poco probada
Entonces
Aplicabilidad Espiral es aplicable
REGLA GP-R55
Tabla 6-89: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
205
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
Si
Factor Riesgo es existe Y Habilidad riesgo es existe Y Tcnicas
AR es se dispone
Entonces
Riesgo es evaluable
REGLA GP-R56
Tabla 6-90: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
Si
Aplicabilidad Prototipo es aplicable Y Factibilidad prototipo
es factible Y Riesgo es evaluable Y Aplicabilidad Espiral es
aplicable
Entonces
CV Propuesto Gestin es Espiral
REGLA GP-R45
Tabla 6-91: Seleccin del Ciclo de vida para el rea Gestin de Proyecto
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
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
Si
CV Propuesto Requisitos es Cascada Y CV Propuesto Aplicacin
es Cascada Y CV Propuesto Gestin es Cascada
Entonces
El CV Propuesto Proyecto es Cascada
REGLA R0
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
206
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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
Si
CV Propuesto Requisitos es Objetos Y CV Propuesto Aplicacin
es Objetos Y CV Propuesto Gestin es Objetos Entonces
El CV Propuesto Proyecto es Objetos
REGLA R1
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
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
Si
CV Propuesto Requisitos es Espiral Y CV Propuesto Aplicacin
es Espiral Y CV Propuesto Gestin es Espiral
Entonces
El CV Propuesto Proyecto es Espiral
REGLA R2
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Cascada Y El Tipo de Aplicacin indica usar modelo en
Cascada Y La Gestin de Proyecto indica usar modelo de
Objetos
Entonces
El Ciclo de Vida sugerido es Cascada
Si
CV Propuesto Requisitos es Cascada Y CV Propuesto Aplicacin
es Cascada Y CV Propuesto Gestin es Objetos
Entonces
El CV Propuesto Proyecto es Cascada
REGLA R3
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
207
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Cascada Y El Tipo de Aplicacin indica usar modelo de
Objetos Y La Gestin de Proyecto indica usar modelo en
Cascada
Entonces
El Ciclo de Vida sugerido es Cascada
Si
CV Propuesto Requisitos es Cascada Y CV Propuesto Aplicacin
es Objetos Y CV Propuesto Gestin es Cascada
Entonces
El CV Propuesto Proyecto es Cascada
REGLA R4
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo de
Objetos 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
Si
CV Propuesto Requisitos es Objetos Y CV Propuesto Aplicacin
es Cascada Y CV Propuesto Gestin es Cascada
Entonces
El CV Propuesto Proyecto es Cascada
REGLA R6
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Cascada Y El Tipo de Aplicacin indica usar modelo en
Cascada Y La Gestin de Proyecto indica usar modelo en
Espiral
Entonces
El Ciclo de Vida sugerido es Cascada
Si
CV Propuesto Requisitos es Cascada Y CV Propuesto Aplicacin
es Cascada Y CV Propuesto Gestin es Espiral
Entonces
El CV Propuesto Proyecto es Cascada
REGLA R7
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
208
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Cascada Y El Tipo de Aplicacin indica usar modelo en Espiral
Y La Gestin de Proyecto indica usar modelo en Cascada
Entonces
El Ciclo de Vida sugerido es Cascada
Si
CV Propuesto Requisitos es Cascada Y CV Propuesto Aplicacin
es Espiral Y CV Propuesto Gestin es Cascada
Entonces
El CV Propuesto Proyecto es Cascada
REGLA R8
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Espiral 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
Si
CV Propuesto Requisitos es Espiral Y CV Propuesto Aplicacin
es Cascada Y CV Propuesto Gestin es Cascada
Entonces
El CV Propuesto Proyecto es Cascada
REGLA R10
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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 en
Cascada
Entonces
El Ciclo de Vida sugerido es Objetos
Si
CV Propuesto Requisitos es Objetos Y CV Propuesto Aplicacin
es Objetos Y CV Propuesto Gestin es Cascada
Entonces
El CV Propuesto Proyecto es Objetos
REGLA R11
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
209
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo de
Objetos Y El Tipo de Aplicacin indica usar modelo en
Cascada Y La Gestin de Proyecto indica usar modelo de
Objetos
Entonces
El Ciclo de Vida sugerido es Objetos
Si
CV Propuesto Requisitos es Objetos Y CV Propuesto Aplicacin
es Cascada Y CV Propuesto Gestin es Objetos
Entonces
El CV Propuesto Proyecto es Objetos
REGLA R12
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Cascada 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
Si
CV Propuesto Requisitos es Cascada Y CV Propuesto Aplicacin
es Objetos Y CV Propuesto Gestin es Objetos
Entonces
El CV Propuesto Proyecto es Objetos
REGLA R14
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
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 en
Espiral
Entonces
El Ciclo de Vida sugerido es Objetos
Si
CV Propuesto Requisitos es Objetos Y CV Propuesto Aplicacin
es Objetos Y CV Propuesto Gestin es Espiral
Entonces
El CV Propuesto Proyecto es Objetos
REGLA R15
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
210
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo de
Objetos Y El Tipo de Aplicacin indica usar modelo en Espiral
Y La Gestin de Proyecto indica usar modelo de Objetos
Entonces
El Ciclo de Vida sugerido es Objetos
Si
CV Propuesto Requisitos es Objetos Y CV Propuesto Aplicacin
es Espiral Y CV Propuesto Gestin es Objetos
Entonces
El CV Propuesto Proyecto es Objetos
REGLA R16
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Espiral 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
Si
CV Propuesto Requisitos es Espiral Y CV Propuesto Aplicacin
es Objetos Y CV Propuesto Gestin es Objetos
Entonces
El CV Propuesto Proyecto es Objetos
REGLA R18
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Espiral Y El Tipo de Aplicacin indica usar modelo en Espiral
Y La Gestin de Proyecto indica usar modelo en Cascada
Entonces
El Ciclo de Vida sugerido es Espiral
Si
CV Propuesto Requisitos es Espiral Y CV Propuesto Aplicacin
es Espiral Y CV Propuesto Gestin es Cascada
Entonces
El CV Propuesto Proyecto es Espiral
REGLA R19
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
211
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Espiral Y El Tipo de Aplicacin indica usar modelo en Cascada
Y La Gestin de Proyecto indica usar modelo en Espiral
Entonces
El Ciclo de Vida sugerido es Espiral
Si
CV Propuesto Requisitos es Espiral Y CV Propuesto Aplicacin
es Cascada Y CV Propuesto Gestin es Espiral
Entonces
El CV Propuesto Proyecto es Espiral
REGLA R20
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Cascada 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
Si
CV Propuesto Requisitos es Cascada Y CV Propuesto Aplicacin
es Espiral Y CV Propuesto Gestin es Espiral
Entonces
El CV Propuesto Proyecto es Espiral
REGLA R22
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Espiral Y El Tipo de Aplicacin indica usar modelo en Espiral
Y La Gestin de Proyecto indica usar modelo de Objetos
Entonces
El Ciclo de Vida sugerido es Espiral
Si
CV Propuesto Requisitos es Espiral Y CV Propuesto Aplicacin
es Espiral Y CV Propuesto Gestin es Objetos
Entonces
El CV Propuesto Proyecto es Espiral
REGLA R23
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
212
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Espiral Y El Tipo de Aplicacin indica usar modelo de Objetos
Y La Gestin de Proyecto indica usar modelo en Espiral
Entonces
El Ciclo de Vida sugerido es Espiral
Si
CV Propuesto Requisitos es Espiral Y CV Propuesto Aplicacin
es Objetos Y CV Propuesto Gestin es Espiral
Entonces
El CV Propuesto Proyecto es Espiral
REGLA R24
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo de
Objetos 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
Si
CV Propuesto Requisitos es Objetos Y CV Propuesto Aplicacin
es Espiral Y CV Propuesto Gestin es Espiral
Entonces
El CV Propuesto Proyecto es Espiral
REGLA R26
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Cascada Y El Tipo de Aplicacin indica usar modelo en Espiral
Y La Gestin de Proyecto indica usar modelo en Objetos
Entonces
El Ciclo de Vida sugerido es Espiral
Si
CV Propuesto Requisitos es Cascada Y CV Propuesto Aplicacin
es Espiral Y CV Propuesto Gestin es Objetos
Entonces
El CV Propuesto Proyecto es Espiral
REGLA R27
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
213
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Cascada Y El Tipo de Aplicacin indica usar modelo en
Objetos Y La Gestin de Proyecto indica usar modelo en
Espiral
Entonces
El Ciclo de Vida sugerido es Objetos
Si
CV Propuesto Requisitos es Cascada Y CV Propuesto Aplicacin
es Objetos Y CV Propuesto Gestin es Espiral
Entonces
El CV Propuesto Proyecto es Objetos
REGLA R28
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Objetos Y El Tipo de Aplicacin indica usar modelo en
Cascada Y La Gestin de Proyecto indica usar modelo en
Espiral
Entonces
El Ciclo de Vida sugerido es Espiral
Si
CV Propuesto Requisitos es Objetos Y CV Propuesto Aplicacin
es Cascada Y CV Propuesto Gestin es Espiral
Entonces
El CV Propuesto Proyecto es Espiral
REGLA R29
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Objetos Y El Tipo de Aplicacin indica usar modelo de Espiral
Y La Gestin de Proyecto indica usar modelo en Cascada
Entonces
El Ciclo de Vida sugerido es Espiral
Si
CV Propuesto Requisitos es Objetos Y CV Propuesto Aplicacin
es Espiral Y CV Propuesto Gestin es Cascada
Entonces
El CV Propuesto Proyecto es Espiral
REGLA R30
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
214
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo en
Espiral Y El Tipo de Aplicacin indica usar modelo en Cascada
Y La Gestin de Proyecto indica usar modelo de Objetos
Entonces
El Ciclo de Vida sugerido es Objetos
Si
CV Propuesto Requisitos es Espiral Y CV Propuesto Aplicacin
es Cascada Y CV Propuesto Gestin es Objetos
Entonces
El CV Propuesto Proyecto es Objetos
REGLA R31
Estado de la regla
Palabras del experto
Formulacin externa
de la regla
Nombre de la regla
Texto de la regla
Si
La Especificacin de Requerimientos indica usar modelo de
Espiral Y El Tipo de Aplicacin indica usar modelo de Objetos
Y La Gestin de Proyecto indica usar modelo en Cascada
Entonces
El Ciclo de Vida sugerido es Objetos
Si
CV Propuesto Requisitos es Espiral Y CV Propuesto Aplicacin
es Objetos Y CV Propuesto Gestin es Cascada
Entonces
El CV Propuesto Proyecto es Objetos
REGLA R32
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
215
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
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
216
Informacin
Descripcin
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
217
Informacin
Nombre
Concepto
Descripcin
Tipo Valor
Rango de valores
Nro. Valores por caso
Fuente
Detalles acerca del
mtodo para obtener
esta informacin
Confiabilidad de los
datos de entrada
Uso
Formato de los
resultados de salida
Material de soporte
Descripcin
Objetivo
Proyecto
Describe el objetivo del proyecto desarrollar
Texto
Valores alfanumricos
Mnimo 0, Mximo 1
Ingresada por el usuario
No hay mtodo.
___
Permite conocer el objetivo del proyecto a desarrollar.
No actualiza atributos, no afecta el proceso de seleccin del CV.
___
Tabla 6-124: Descripcin del atributo Objetivo
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
218
Informacin
Descripcin
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
Nro. Valores por caso Mnimo 0, Mximo 1
Fuente Ingresada por el usuario
Detalles acerca del No hay mtodo.
mtodo para obtener
esta informacin
Confiabilidad de los ___
datos de entrada
Uso Permite conocer el CV seleccionado por el lder del proyecto
Formato de los No actualiza atributos, no afecta el proceso de seleccin del CV.
resultados de salida
Material de soporte ___
Tabla 6-126: Descripcin del atributo CV seleccionado
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
219
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
220
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
221
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
222
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
223
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
224
Informacin
Descripcin
Nombre Orientacin
Concepto Aplicacin
Descripcin Describe la orientacin con la que se va a modelar y formalizar la
aplicacin a desarrollar.
Tipo Valor Texto
Rango de valores Software de base, Sistema Basado en Conocimiento, Otros
Nro. Valores por caso Mnimo 0, Mximo 1
Fuente Ingresada por el usuario
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. 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
Uso Permite determinar si las tcnicas de modelado orientadas a objetos
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.
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-138 Descripcin del atributo Orientacin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
225
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
226
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
227
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
228
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
229
Informacin
Descripcin
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
Nro. Valores por caso Mnimo 0, Mximo 1
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.
Confiabilidad de los __
datos de entrada
Uso Permite determinar junto con otros atributos (Modelado Objetos,
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
resultados de salida Aplicacin.
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-148 Descripcin del atributo Opcionalidad
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
230
Informacin
Descripcin
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
Nro. Valores por caso Mnimo 0, Mximo 1
Fuente Ingresada por el usuario
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.
Confiabilidad de los El sistema experto verifica que slo pueda ingresarse uno de los
datos de entrada valores, ya que son excluyentes.
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.
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-150 Descripcin del atributo Formalidad
Informacin
Descripcin
Nombre Entregas
Concepto Coordinacin
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
Nro. Valores por caso Mnimo 0, Mximo 1
Fuente Ingresada por el usuario
Detalles acerca del Valor estimado por el usuario del sistema experto a partir del
mtodo para obtener Informe de requerimientos y de las primeras entrevistas con los
esta informacin usuarios y de su propio conocimiento de proceso del tipo de
aplicacin y del negocio.
Confiabilidad de los El sistema experto verifica que slo pueda ingresarse uno de los
datos de entrada valores, ya que son excluyentes.
Uso Permite determinar junto con otros atributos la aplicabilidad el
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.
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-151 Descripcin del atributo Entregas
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
231
Informacin
Descripcin
Nombre Responsabilidad
Concepto Coordinacin
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
Nro. Valores por caso Mnimo 0, Mximo 1
Fuente Ingresada por el usuario
Detalles acerca del Valor estimado por el usuario del sistema experto a partir del
mtodo para obtener Informe de requerimientos y de las primeras entrevistas con los
esta informacin usuarios.
Confiabilidad de los El sistema experto verifica que slo pueda ingresarse uno de los
datos de entrada valores, ya que son excluyentes.
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 Espiral y Cv Propuesto Gestin.
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-152 Descripcin del atributo Responsabilidad
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
232
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
233
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
234
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
235
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
236
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
237
Informacin
Descripcin
Nombre Sistema OO
Concepto Coordinacin
Descripcin Describe si existe algn sistema anterior o esta prevista uno
posterior orientado a objetos
Tipo Valor Texto
Rango de valores Existe, No existe
Nro. Valores por caso Mnimo 0, Mximo 1
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
Confiabilidad de los __
datos de entrada
Uso Permite determinar junto con otros atributos la aplicabilidad del
Modelo de Objetos para el rea Gestin de Proyectos.
Formato de los Texto. Participa en la actualizacin del atributo CV Propuesto
resultados de salida Gestin.
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-164 Descripcin del atributo Sistema OO
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
238
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
239
Informacin
Descripcin
Nombre Aplicabilidad OO
Concepto Coordinacin
Descripcin Describe la posibilidad de aplicar la modelizacin de objetos en la
aplicacin a desarrollar.
Tipo Valor Texto
Rango de valores Aplicable, No aplicable
Nro. Valores por caso Mnimo 0, Mximo 1
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
Confiabilidad de los __
datos de entrada
Uso Permite determinar junto con otros atributos la aplicabilidad del
modelo en Objetos para el rea Gestin de Proyectos.
Formato de los Texto. Participa en la actualizacin del atributo CV Propuesto
resultados de salida Gestin.
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-168 Descripcin del atributo Aplicabilidad OO
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
240
Informacin
Descripcin
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
Nro. Valores por caso Mnimo 0, Mximo 1
Fuente Ingresada por el usuario
Detalles acerca del Valor estimado por el usuario del sistema experto a partir del
mtodo para obtener Informe de requerimientos y de las primeras entrevistas con los
esta informacin usuarios y de su propio conocimiento de proceso del tipo de
aplicacin y del negocio.
Confiabilidad de los El sistema experto verifica que slo pueda ingresarse uno de los
datos de entrada valores, ya que son excluyentes.
Uso Permite determinar la aplicabilidad del modelo de prototipo.
Formato de los Texto. Actualiza el atributo Aplicabilidad Prototipo.
resultados de salida
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-170 Descripcin del atributo Participacin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
241
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
242
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
243
Informacin
Descripcin
Informacin
Descripcin
Nombre Tcnicas AR
Concepto Riesgos del Proyecto
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
Nro. Valores por caso Mnimo 0, Mximo 1
Fuente Ingresada por el usuario
Detalles acerca del Valor estimado por el usuario del sistema experto a partir del
mtodo para obtener Informe de requerimientos y de las primeras entrevistas con los
esta informacin usuarios y de su propio conocimiento de proceso del tipo de
aplicacin y del negocio.
Confiabilidad de los El sistema experto verifica que slo pueda ingresarse uno de los
datos de entrada valores, ya que son excluyentes.
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.
resultados de salida
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-177 Descripcin del atributo Tcnicas AR
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
244
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
245
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
246
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
247
Informacin
Descripcin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
248
Informacin
Nombre
Concepto
Descripcin
Tipo Valor
Rango de valores
Nro. Valores por caso
Fuente
Descripcin
Factor Riesgo
Riesgos del Proyecto
Describe si existen factores de riesgo.
Texto
Existe, No existe
Mnimo 0, Mximo 1
Obtenido a partir de Viabilidad software, Riesgo Espiral, Categoras
Riesgo.
De acuerdo con los valores ingresados por el usuario Viabilidad
software, Riesgo Espiral, Categoras Riesgo se estima si existe o no
Factor de riesgo para aplicar modelo en espiral
__
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
249
Informacin
Descripcin
Nombre Riesgo
Concepto Riesgos del Proyecto
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
Nro. Valores por caso Mnimo 0, Mximo 1
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
Confiabilidad de los __
datos de entrada
Uso Permite determinar junto con otros atributos la aplicabilidad del
ciclo de vida en Espiral.
Formato de los Texto. Actualiza el atributo CV Propuesto Gestin
resultados de salida
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-188 Descripcin del atributo Riesgo
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
250
Informacin
Nombre
Concepto
Descripcin
Tipo Valor
Rango de valores
Nro. Valores por caso
Fuente
Descripcin
CV Propuesto Aplicacin
rea Aplicacin
Define el modelo ciclo de vida mas adecuado para el rea Aplicacin
Texto
Cascada, Objetos, Espiral, No hay propuesta
Mnimo 1
Obtenido a partir de Componentes predominantes, Comportamiento
predominante, Complejidad Subsistemas, Retroalimentacin Fases
Desarrollo, Progresin Fases Desarrollo, Opcionalidad, integracin
HW-SW, Modelado objetos, Modelado Prototipo.
De acuerdo con de Componentes predominantes, Comportamiento
predominante, Complejidad Subsistemas, Retroalimentacin Fases
Desarrollo, Progresin Fases Desarrollo, Opcionalidad, integracin
HW-SW, Modelado objetos, Modelado Prototipo se estima el ciclo de
vida mas adecuado para el rea Aplicacin
__
Confiabilidad de los
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.
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-190 Descripcin del atributo CV Propuesto Aplicacin
Informacin
Descripcin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
251
Informacin
Nombre
Concepto
Descripcin
Tipo Valor
Rango de valores
Nro. Valores por caso
Fuente
Descripcin
CV Propuesto del Proyecto
CV Diagnstico
Define el modelo ciclo de vida mas adecuado para el Proyecto
Texto
Cascada, Objetos, Espiral, No hay propuesta
Mnimo 1
Obtenido a partir de CV Propuesto Requisitos, CV Propuesto
Aplicacin, CV Propuesto Gestin
De acuerdo con los de CV Propuesto Requisitos, CV Propuesto
Aplicacin, CV Propuesto Gestin se estima el ciclo de vida mas
adecuado para el Proyecto
__
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
252
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
253
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.
Tipo de definicin
Niveles de Composicin
Formalidad
Grado de Certidumbre
Complejidad Subsistemas
Entregas
Factibilidad Metodologa
Grado de Cumplimiento
Componentes Predominantes
Responsabilidad
Necesidad Metodologa
Comportamiento Predominante
Control Gestin
Reso Aplicacin OO
Orientacin
Introduccin Gradual
Procedimientos Cambios
Experiencia tcnicas IS
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
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
254
Seleccionar el CV del
Area Requerimientos
ANALIZAR
DEFINICIN
REQUERIMIENTOS
ESTIMAR
LIMITES
ESTIMAR NIVEL
EXIGENCIA EN EL
PRODUCTO FINAL
Figura 6-5 Jerarqua de Tareas de Seleccionar del Ciclo de Vida para el Area Especificacin Requerimientos
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
255
Seleccionar el CV del
Area Tipo de Aplicacin
ESTIMAR
FACTORES
PREDOMINANTES
ANALIZAR
FACTORES
PROTOTIPACIN
ESTIMAR
NIVEL
OPCIONES
ESTIMAR
INTEGRACIN
HARDWARESOFTWARE
Figura 6-6 Jerarqua de Tareas de Seleccionar el Ciclo de Vida para el Area Tipo de Aplicacin
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
256
Analizar Coordinacin
Def. de la Meta: Analizar los factores relacionados con
administracin, mantenimiento y reusabilidad que inciden en
la coordinacin del proyecto.
ESTIMAR
RELACION
CON
EL USUARIO
Entradas Necesarias:
Formalidad
ESTIMAR
FACTORES
EQUIPO DE
PROYECTO
Entradas Necesarias:
Entregas
Control Gestin
Viabilidad Software
Categoras riesgo
Responsabilidad
Factibilidad Metodologa
Nivel de riesgo
Objetivo Calidad
Necesidad metodologa
Reso aplicacin OO
Anlisis Riesgo
Terminacin proyectos
Tcnicas AR
Procedimientos cambios
Identificacin Alternativas
Riesgos Alternativa
la Base de Conocimientos.
a la Base de Conocimientos.
ESTIMAR
FACTORES
REUSO
ESTIMAR
FACTORES
MANTENIMIENTO
ESTIMAR
RECURSOS
SOFTWARE
ESTIMAR
FACTORES
ADMINISTRACIN
ESTIMAR
RIESGO
EXISTENTE
ESTIMAR
HABILIDAD
PARA
EVALUAR
RIESGO
Figura 6-7 Jerarqua de Tareas de Seleccionar del Ciclo de Vida para el Area Gestin del Proyecto
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
257
REQUISITOS
SE ESTIMAN
SE ESTIMAN
AREA
REQUISITOS
SE SUGIERE
APLICACION
AREA
APLICACION
SE SUGIERE
SE PROPONE
SE PROPONE
1
1
CV
DIAGNOSTICO
PROYECTO
1
N
N
USUARIO
SE SUGIERE
SE ESTIMAN
N
N
SE ESTIMAN
SE ESTIMAN
EQUIPO DE
PROYECTO
SE SUGIERE
1
SE PROPONE
AREA
GESTION
PROYECTO
COORDINACION
RIESGOS DEL
PROYECTO
SE SUGIERE
SE SUGIERE
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.
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
258
Estimar Lmites
Propsito:
Establecer el nivel de claridad con el que se encuentran definidos los lmites al inicio del proyecto.
Informacin necesaria:
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.
REQUISITOS
SE ESTIMAN
SE ESTIMAN
AREA
REQUISITOS
APLICACION
SE PROPONE
SE PROPONE
AREA
APLICACION
SE SUGIERE
SE SUGIERE
1
1
CV
DIAGNOSTICO
PROYECTO
1
N
N
USUARIO
SE SUGIERE
SE ESTIMAN
N
N
SE ESTIMAN
SE ESTIMAN
EQUIPO DE
PROYECTO
SE SUGIERE
1
SE PROPONE
AREA
GESTION
PROYECTO
COORDINACION
RIESGOS DEL
PROYECTO
SE SUGIERE
SE SUGIERE
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
259
Informacin necesaria:
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
Informacin necesaria:
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
Informacin necesaria:
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
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
260
REQUISITOS
SE ESTIMAN
SE ESTIMAN
AREA
REQUISITOS
SE SUGIERE
APLICACION
SE PROPONE
SE PROPONE
AREA
APLICACION
SE SUGIERE
1
1
CV
DIAGNOSTICO
PROYECTO
1
N
N
USUARIO
SE SUGIERE
SE ESTIMAN
N
N
SE ESTIMAN
SE ESTIMAN
EQUIPO DE
PROYECTO
SE SUGIERE
1
SE PROPONE
AREA
GESTION
PROYECTO
COORDINACION
RIESGOS DEL
PROYECTO
SE SUGIERE
SE SUGIERE
Informacin necesaria:
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
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
261
Informacin necesaria:
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
Informacin necesaria:
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. Deducir si el CV del rea es Cascada
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
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
262
Informacin necesaria:
Los valores asignados por el usuario del sistema al atributo Integracin HW-SW
Acciones:
Solicitar al usuario los valores de Integracin HW-SW
Informacin necesaria:
Los valores asignados por el usuario del sistema a los atributos Reso Aplicacin OO, Reso aplicacin
existente, Reso aplicacin futura.
Acciones:
1. Solicitar al usuario los valores de los atributos necesarios
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
Informacin necesaria:
Los valores asignados por el usuario del sistema a los atributos Procedimientos Cambios, Procedimientos
Desarrollo- Mantenimiento.
Acciones:
1. Solicitar al usuario los valores de los atributos necesarios
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
Informacin necesaria:
Los valores asignados por el usuario del sistema al atributo Software para prototipar.
Acciones:
1. Solicitar al usuario los valores de los atributos necesarios
2. Deducir si el prototipo es factible
2.1 Software para prototipar es hay disponible o factible de adquirir = Factibilidad prototipo es factible
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
263
REQUISITOS
SE ESTIMAN
SE ESTIMAN
AREA
REQUISITOS
SE SUGIERE
APLICACION
SE PROPONE
AREA
APLICACION
SE SUGIERE
SE PROPONE
CV
DIAGNOSTICO
PROYECTO
1
N
N
USUARIO
SE SUGIERE
SE ESTIMAN
N
N
SE ESTIMAN
SE ESTIMAN
EQUIPO DE
PROYECTO
SE SUGIERE
1
SE PROPONE
AREA
GESTION
PROYECTO
COORDINACION
RIESGOS DEL
PROYECTO
SE SUGIERE
SE SUGIERE
Informacin necesaria:
Los valores asignados por el usuario del sistema a los atributos formalidad, Entregas, Factibilidad
Metodologa, Necesidad Metodologa.
Acciones:
1. Solicitar al usuario los valores de los atributos necesarios
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.
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
264
Analizar Coordinacin
Propsito:
Analizar los factores que inciden en las decisiones de coordinacin en el desarrollo de un proyecto.
Informacin necesaria:
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:
1. Solicitar al usuario los valores de los atributos necesarios.
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
Informacin necesaria:
Los valores asignados por el usuario del sistema a los atributos Participacin e Introduccin gradual.
Acciones:
1. Solicitar al usuario los valores de los atributos necesarios
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
Informacin necesaria:
Los valores asignados por el usuario del sistema a los atributos Experiencia tcnicas IS, Experiencia previa.
Acciones:
1. Solicitar al usuario los valores de los atributos necesarios
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
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
265
Informacin necesaria:
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:
1. Solicitar al usuario los valores de los atributos necesarios
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.
Informacin necesaria:
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:
1. Solicitar al usuario los valores de los atributos necesarios
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
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
266
Informacin necesaria:
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:
1. Solicitar al usuario los valores de los atributos necesarios.
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.
Informacin necesaria:
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. Deducir si el CV del rea es Cascada
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
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
267
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.
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
268
TIPO DE DEFINICION
Formalmente,Informalmente,
Exhaustivamente,
Incompleto, Uniformemente,
Desestructuradamente
DEFINICION REQUISITOS
DEFINICION LIMITES
Definicin clara
Definicin incierta
Definicin clara
Definicin incierta
CV PROPUESTO
REQUISITOS
Espiral
Objeto
Cascada
GRADO DE
CUMPLIMIENTO
GRADO DE
CERTIDUMBRE
Mayoritariamente definidos
Parcialmente definidos
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
269
COMPONENTES
PREDOMINANTES
COMPORTAMIENTO
PREDOMINANTE
Batch
Algortmicos
RELACION FASES
DESARROLLO
NIVELES COMPOSICION
Pocos Subsistemas
Poca dependencia,
Independencia
CV PROPUESTO
APLICACION
COMPLEJIDAD
SUBSISTEMAS
Cascada
RETROALIMENTACION
FASES DESARROLLO
Baja
Baja
PROGRESION FASES
DESARROLLO
Uniforme y Secuencial
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
270
NIVELES COMPOSICION
COMPONENTES
PREDOMINANTES
POSIBILIDAD DISEO
POSIBILIDAD
IMPLEMENTACION
Varias opciones
Varios Subsistemas
Varias opciones
Matemticos, Grficos
COMPLEJIDAD
SUBSISTEMAS
ORIENTACION
COMPORTAMIENTO
PREDOMINANTE
Alta
Dinmico, Interactivo,
Tiempo real
OPCIONALIDAD
Mltiple
RELACION FASES
DESARROLLO
Mucha dependencia
MODELADO OBJETOS
Conveniente
CV PROPUESTO
APLICACION
RETROALIMENTACION
FASES DESARROLLO
Espiral
Objetos
Alta
MODELADO PROTOTIPO
VARIABILIDAD
PROCESOS
Conveniente
Alta
INTEGRACION HW-SW
Fuertemente
TIPO MODIFICACION
PROGRESION FASES
DESARROLLO
Redefinicin, Extensin,
Ampliacin
EXISTENCIA
APLICACIONES
FACTORES DISEO
Innovador
Problemas de Arquitectura,
Problemas de Eficacia
NO Uniforme y Secuencial
FIGURA 6-14
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
271
NECESIDAD
METODOLOGIA
FACTIBILIDAD
METODOLOGIA
Ampliamente probada
NIVEL DE RIESGO
ENTREGAS
Ampliamente probada
Bajo riesgo,
NO Hay riesgo
Versin completa
CONVENIENCIA
METODOLOGIA
RIESGO CASCADA
Aceptable
Ampliamente probada
CV PROPUESTO
GESTIN
FACTIBILIDAD
PROTOTIPO
RESPONSABILIDAD
Cascada
NO Factible
Organizacin propia
SOFTWARE PARA
PROTOTIPAR
FORMALIDAD
NO Disponoble,
NO Adquirible
Muy formal
FIGURA 6-15
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
CONTROL GESTION
Muy ajustado
Bibiana D. Rossi
272
FACTIBILIDAD
METODOLOGIA
ENTREGAS
NECESIDAD
METODOLOGIA
Medianamente probada
NIVEL DE RIESGO
Medianamente probada
CONVENIENCIA
METODOLOGIA
RIESGO OBJETOS
ENTREGA INTERMEDIA
Medianamente probada
Aceptable
Existe
APLICABILIDAD OO
CV PROPUESTO
GESTIN
SISTEMA OO
Objetos
Existe
Aplicable
FORMALIDAD
Poco formal,
Medianamente formal
REUSO APLICACION
EXISTENTE
Estrategias explcitas
REUSO APLICACION
FUTURA
Muy necesario
FIGURA 6-16
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
REUSO APLICACION OO
Subsistema del existente,
Ampliacin del existente,
Modificacin del existentes
Componentes del actual
Bibiana D. Rossi
273
EXPERIENCIA
PREVIA
PARTICIPACION
No hay
ENTREGAS
Fuerte
ENTREGA INTERMEDIA
SOFTWARE PARA
PROTOTIPAR
Estrategias explcitas
Hay Disponible,
Factible de adquirir
EXPERIENCIA
TECNICAS IS
Existe
REUSO APLICACION
EXISTENTE
No hay
FACTOR RIESGO
Existe
INTRODUCCION
GRADUAL
Necesaria
Factible
TERMINACION
PROYECTOS
OBJETIVO CALIDAD
FACTIBILIDAD
PROTOTIPO
APLICABILIDAD PROTOTIPO
Mecanismos explcitos
Prematura
Aplicable
ANALISIS RIESGO
Estrategias explcitas
CV PROPUESTO
GESTIN
RESPONSABILIDAD
APLICABILIDAD ESPIRAL
Organizacin propia
Espiral
Aplicable
PROCEDIMIENTOS
CAMBIOS
Acuerdos confirmados
PROCEDIMIENTOS D-M
Conveniente
Poco formal,
Medianamente formal
PROCEDIMIENTOS
DESARROLLOMANTENIMIENTO
HABILIDAD RIESGO
Existe
FIGURA 6-17
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
RIESGOS
ALTERNATIVA
CONVENIENCIA
METODOLOGIA
IDENTIFICACION
ALTERNATIVAS
Etapas
anteriores
FORMALIDAD
Poco probada
Etapas anteriores
RIESGO
Evaluable
NECESIDAD
METODOLOGIA
FACTIBILIDAD
METODOLOGIA
Poco probada
Poco probada
Bibiana D. Rossi
274
FACTIBILIDAD
PROTOTIPO
Factible
VIABILIDAD SOFTWARE
Hay dudas
FACTOR RIESGO
NIVEL DE
RIESGO
APLICABILIDAD
PROTOTIPO
Existe
Aplicable
RIESGO ESPIRAL
Mediano riesgo,
Alto riesgo
Aceptable
CV PROPUESTO
GESTIN
CATEGORIAS RIESGO
Tcnicos
TECNICAS AR
RIESGO
Se dispone
Evaluable
HABILIDAD RIESGO
Espiral
APLICABILIDAD
ESPIRAL
IDENTIFICACION
ALTERNATIVAS
Se identifican
Existe
RIESGOS ALTERNATIVA
Aplicable
Se identifican
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
275
PROYECTO
IDENTIFICACION
CV PROPUESTO
REQUISITOS
Codigo Alfanumrico
Cascada
Objetos
Espiral
No hay respuesta
PROYECTO
CV PROPUESTO
APLICACION
PROYECTO
FECHA INICIO
Fecha DD/MM/AAAA
CV PROPUESTO
DEL PROYECTO
Cascada
Objetos
Espiral
No hay respuesta
Cascada
Objetos
Espiral
No hay respuesta
PROYECTO
FECHA FINALIZACION
CV PROPUESTO
GESTION
Fecha DD/MM/AAAA
Cascada
Objetos
Espiral
No hay respuesta
PROYECTO
OBJETIVO
Descripcion
PROYECTO
PROYECTO
CV PROPUESTO POR SE
Cascada
Objetos
Espiral
No hay respuesta
CV SELECCIONADO
Cascada
Objetos
Espiral
Otros....
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
276
CONCEPTUALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
277
Captulo 7
Formalizacin
de Conocimientos
7.2 FORMALIZACION
PRODUCCION
DE
LOS
CONOCIMIENTOS
EN
REGLAS
DE
02/09/2003
Bibiana D. Rossi
281
MC PROYECTO
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Valor
Omisin
__
Entero > 0
__
Si Necesito
Si Modifico
Si Borro
PROC.Guardar
__
__
__
__
Ranura
1/1
1/1
No
No
__
__
__
PROC.Guardar
1/1
No
__
__
__
PROC.Guardar
__
__
1/1
1/1
1/n
No
No
S
__
__
dd/mm/aa
dd/mm/aa
__
__
PROC.Guardar
PROC.Guardar
__
__
__
__
__
__
__
PROC.Guardar
__
__
1/1
No
__
__
__
PROC.Guardar
__
__
Requisitos
Numrico
Conj. de
caracteres
Conj. de
caracteres
Fecha
Fecha
Conj. de
caracteres
Conj. de
caracteres
Marco
1/n
__
__
__
__
__
Aplicacin
Marco
1/n
__
__
__
__
__
Gestin
Marco
1/n
__
__
__
__
__
CV Diagnostico
Marco
1/n
^MC
Requisitos
^MC
Aplicacin
^MC
Gestin
^MC CV
Diagnstico
__
__
__
__
__
( ) Identificacin
( ) Nombre proyecto
( ) Lder del proyecto
( ) Fecha inicio
( ) Fecha finalizacin
( ) Objetivo
( ) CV seleccionado
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
282
MC GESTION
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Valor
Omisin
Si Necesito
Si Modifico
Si Borro
^MC
Coordinacin
^MC
Usuario
^MC Riesgos
del proyecto
__
__
__
__
__
__
__
__
__
__
__
__
__
__
__
__
__
__
__
__
Ranura
Coordinacin
Marco
1/n
Usuario
Marco
1/n
Riesgos del
proyecto
Equipo de proyecto
Marco
1/n
Marco
1/n
^MC Equipo
de proyecto
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
283
MC REQUISITOS
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Valor
Omisin
Si Necesito
Si Modifico
Si Borro
Formalmente
Informalmente
Exhaustivamente
Incompleto
Uniformemente
Desestructuradamente
Definicin Clara
Definicin Incierta
Alta incertidumbre
Baja incertidumbre
Definicin Clara
Definicin Incierta
Alta incertidumbre
Baja incertidumbre
Mayoritariamente
definidos
Parcialmente definidos
Usuario muy exigente
Usuario poco exigente
__
PROC.
PreguntarTipoDefin
icin
__
__
__
__
__
__
__
__
__
__
__
PROC.
ValoresExcluyentes
__
__
__
PROC.
ValoresExcluyentes
__
__
Ranura
( )Tipo de Definicin
Conj. de
caracteres
1/n
__
( )Definicin
Requisitos
Conj. de
caracteres
1/n
__
1/n
__
Conj. de
caracteres
1/1
No
__
Conj. de
caracteres
1/1
No
__
caracteres
( )Grado de
certidumbre
( )Grado de
cumplimiento
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
284
MC APLICACION
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Valor
Omisin
Si Necesito
Si Modifico
Si Borro
__
__
Ranura
( ) Niveles de
Composicin
( ) Complejidad
Subsistemas
( ) Componentes
Predominantes
( ) Comportamiento
Predominante
Conj. de
caracteres
1/1
No
__
Pocos Subsistemas
Varios Subsistemas
__
Conj. de
caracteres
1/1
No
__
Baja
Alta
__
__
__
__
Conj. de
caracteres
1/n
__
__
PROC.
ValoresNoExcluyentes
__
__
Conj. de
caracteres
1/n
__
__
PROC.
PreguntarComportami
entoPredominante
__
__
( ) Orientacin
Conj. de
caracteres
1/1
No
__
__
PROC.
ValoresExcluyentes
__
__
( ) Progresin Fases
desarrollo
( ) Relacin Fases
desarrollo
( ) Retroalimentacin
Fases desarrollo
( ) Integracin HWSW
( ) Factores diseo
Conj. de
caracteres
1/1
No
__
__
PROC.
ValoresExcluyentes
__
__
Conj. de
caracteres
1/1
No
__
__
PROC.
ValoresExcluyentes
__
__
Conj. de
caracteres
1/1
No
__
Algortmicos
Matemticos
Grficos
Batch
Dinmico
Interactivo
Tiempo Real
Software de Base
Sistema Basado en
Conocimiento
Otros
Uniforme y Secuencial
No Uniforme y
Secuencial
Poca Dependencia
Mucha Dependencia
Independencia
Baja
Alta
__
__
Conj. de
caracteres
1/1
No
__
Conj. de
caracteres
1/n
__
Fuertemente
Medianamente
Levemente
Problemas de
Arquitectura
Problemas de eficacia
__
PROC.
ValoresExcluyentes
__
__
PROC.
ValoresExcluyentes
__
__
__
PROC.
ValoresNoExcluyentes
__
__
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
285
MC APLICACION
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Valor
Omisin
Si Necesito
Si Modifico
Si Borro
Ranura
( ) Existencia
Aplicaciones
( ) Posibilidad
Diseo
( ) Posibilidad
Implementacin
( ) Modelado
Prototipo
( ) Modelado Objetos
( ) Variabilidad
Procesos
( ) Opcionalidad
( ) Tipo modificacin
Conj. de
caracteres
1/1
No
__
Innovador
Conocido
__
PROC.
ValoresExcluyentes
__
__
Conj. de
caracteres
1/1
No
__
Pocas opciones
Varias opciones
__
PROC.
ValoresExcluyentes
__
__
Conj. de
caracteres
1/1
No
__
Pocas opciones
Varias opciones
__
PROC.
ValoresExcluyentes
__
__
Conj. de
caracteres
1/1
No
__
Conveniente
No conveniente
__
__
__
__
Conj. de
caracteres
Conj. de
caracteres
1/1
No
__
__
__
__
__
1/1
No
__
Conveniente
No conveniente
Alta
Baja
__
__
__
__
Conj. de
caracteres
Conj. de
caracteres
1/1
No
__
__
__
__
__
1/n
__
Mltiple
Simple
Redefinicin
Extensin
Ampliacin
Emisin gradual
__
PROC.
ValoresNoExcluyentes
__
__
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
286
MC
COORDINACION
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Valor
Omisin
Si Necesito
Si Modifico
Si Borro
Poco formal
Medianamente formal
Muy formal
Versin temprana
No versin temprana
Versin gradual
Versin parcial
Terceros
Organizacin propia
Muy ajustado
Medianamente
ajustado
Poco ajustado
No disponible
Hay disponible
Factible de adquirir
No adquirible
Ampliamente probada
Medianamente
probada
Poco probada
Ampliamente probada
Medianamente
probada
Poco probada
Estrategias explcitas
No estrategias
explcitas
__
PROC.
ValoresExcluyentes
__
__
__
PROC. Entregas
__
__
__
PROC.
ValoresExcluyentes
PROC.
ValoresExcluyentes
__
__
__
__
__
__
__
__
__
PROC.
ValoresExcluyentes
__
__
__
PROC.
ValoresExcluyentes
__
__
__
PROC.
ValoresExcluyentes
__
__
Ranura
( ) Formalidad
Conj. de
caracteres
1/1
No
__
( ) Entregas
Conj. de
caracteres
1/1
No
__
( ) Responsabilidad
Conj. de
caracteres
Conj. de
caracteres
1/1
No
__
1/1
No
__
( ) Software para
prototipar
Conj. de
caracteres
1/n
__
( ) Factibilidad
metodologa
Conj. de
caracteres
1/1
No
__
( ) Necesidad
Metodologa
Conj. de
caracteres
1/1
No
__
( ) Reso aplicacin
existente
Conj. de
caracteres
1/1
No
__
( ) Control Gestin
__
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
287
MC
COORDINACION
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Valor
Omisin
Si Necesito
Si Modifico
Si Borro
Subsistema del
existente
Ampliacin del
existente
Modificacin del
existente
Componentes del
actual
Muy necesario
Medianamente
necesario
Poco necesario
Acuerdos confirmados
No Acuerdos
confirmados
Factible usar los
mismos
Factible usar
diferentes
Necesario usar los
mismos
Necesario usar
diferentes
Ampliamente probada
Medianamente
probada
Poco probada
Factible
No factible
__
PROC.
ValoresNoExcluyen
tes
__
__
__
PROC.
ValoresExcluyentes
__
__
__
PROC.
ValoresExcluyentes
__
__
__
PROC.
ValoresNoExcluyen
tes
__
__
__
__
__
__
__
__
__
__
__
__
__
__
Ranura
( ) Reso aplicacin
OO
Conj. de
caracteres
1/n
__
( ) Reso aplicacin
futura
Conj. de
caracteres
1/1
No
__
( ) Procedimientos
Cambios
( ) Procedimientos
DesarrolloMantenimiento
Conj. de
caracteres
1/1
No
__
Conj. de
caracteres
1/n
__
( ) Conveniencia
Metodologa
Conj. de
caracteres
1/1
No
__
( ) Factibilidad
Prototipo
( ) Sistema OO
Conj. de
caracteres
1/1
No
__
Conj. de
caracteres
1/1
No
__
Existe
No existe
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
288
MC
COORDINACION
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Valor
Omisin
Si Necesito
Si Modifico
Si Borro
Ranura
( ) Entrega
Intermedia
( ) Aplicabilidad
Espiral
( ) Aplicabilidad
Prototipo
( ) Aplicabilidad OO
( ) Procedimientos
D-M
Conj. de
caracteres
1/1
No
__
Existe
No existe
__
__
__
__
Conj. de
caracteres
1/1
No
__
Aplicable
No aplicable
__
__
__
__
Conj. de
caracteres
1/1
No
__
Aplicable
No aplicable
__
__
__
__
Conj. de
caracteres
Conj. de
caracteres
1/1
No
__
__
__
__
__
1/1
No
__
Aplicable
No aplicable
Conveniente
No conveniente
__
PROC.
ValorInconsistente
__
__
MC USUARIO
Ranura
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
( ) Participacin
Conj. de
caracteres
1/1
No
__
( ) Introduccin
gradual
Conj. de
caracteres
1/1
No
__
Valores
Permitidos
Valor
Omisin
Fuerte
Regular
Poca
Necesaria
No necesaria
__
__
Si Necesito
PROC.
ValoresExcluyentes
__
Si Modifico
Si Borro
__
__
__
__
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
289
MC RIESGOS
DEL PROYECTO
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Valor
Omisin
Si Necesito
Si Modifico
Si Borro
Ranura
( ) Viabilidad
software
( ) Nivel de riesgo
Conj. de
caracteres
1/1
__
Hay certeza
Hay dudas
__
PROC.
ValoresExcluyentes
__
__
Conj. de
caracteres
1/1
No
__
__
PROC.
ValoresExcluyentes
__
__
( ) Anlisis riesgo
Conj. de
caracteres
1/1
No
__
__
PROC.
ValoresExcluyentes
__
__
( ) Tcnicas AR
Conj. de
caracteres
Conj. de
caracteres
1/1
__
__
__
1/1
No
__
PROC.
ValoresExcluyentes
PROC.
ValoresExcluyentes
__
( ) Identificacin
Alternativas
Conj. de
( ) Riesgos
caracteres
Alternativa
( ) Categoras riesgo Conj. de
__
__
1/1
No
__
__
PROC.
ValoresExcluyentes
__
__
1/n
No
__
__
__
__
__
( ) Objetivo calidad
1/1
No
__
__
PROC.
ValoresExcluyentes
__
__
Conj. de
caracteres
1/1
No
__
Alto riesgo
Mediano riesgo
Bajo riesgo
No hay riesgo
Estrategias explcitas
No estrategias
explcitas
Se dispone
No se dispone
Se identifican
No se identifican
Etapas anteriores
Se identifican
No se identifican
Etapas anteriores
Tcnicos
Otros riesgos
Mecanismos explcitos
No mecanismos
explcitos
Prematura
En trmino.
__
PROC.
ValoresExcluyentes
__
__
Conj. de
caracteres
Conj. de
caracteres
Conj. de
caracteres
1/1
No
__
__
__
__
__
1/1
No
__
__
__
__
__
1/1
No
__
__
__
__
__
( ) Terminacin
proyectos
( ) Riesgo Cascada
( ) Riesgo Objetos
( ) Habilidad Riesgo
caracteres
Conj. de
caracteres
Aceptable
No aceptable
Aceptable
No aceptable
Existe
No existe
__
02/09/2003
Bibiana D. Rossi
290
MC RIESGOS
DEL PROYECTO
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Valor
Omisin
Si Necesito
Si Modifico
Si Borro
__
__
__
__
__
__
__
__
__
__
__
__
Valor
Omisin
Si Necesito
Si Modifico
Si Borro
Ranura
( ) Factor Riesgo
( ) Riesgo Espiral
( ) Riesgo
Conj. de
caracteres
Conj. de
caracteres
Conj. de
caracteres
1/1
No
__
1/1
No
__
1/1
No
__
Existe.
No existe
Aceptable
No aceptable
Evaluable
No evaluable
MC EQUIPO DE
PROYECTO
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Ranura
( ) Experiencia
tcnicas IS
( ) Experiencia
previa
Conj. de
caracteres
1/1
No
__
Hay
No hay
__
PROC.
ValoresExcluyentes
__
__
Conj. de
caracteres
1/1
No
__
Hay
No hay
__
PROC.
ValoresExcluyentes
__
__
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
291
MC CV
DIAGNOSTICO
Tipo
Ranura
Min/ Multiv.
Max
Propiedad
General
Valores
Permitidos
Valor
Omisin
Si Necesito
Si Modifico
Si Borro
__
__
__
__
__
__
__
__
__
__
__
__
__
__
__
__
Ranura
( ) CV Propuesto
Requisitos
Conj. de
caracteres
1/n
No
__
( ) CV Propuesto
Aplicacin
Conj. de
caracteres
1/n
No
__
( ) CV Propuesto
Gestin
Conj. de
caracteres
1/n
No
__
( ) CV Propuesto
proyecto
Conj. de
caracteres
1/1
No
__
Cascada
Objetos
Espiral
No hay propuesta
Cascada
Objetos
Espiral
No hay propuesta
Cascada
Objetos
Espiral
No hay propuesta
Cascada
Objetos
Espiral
No hay propuesta
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
292
FIN
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
293
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
{
SetPostMessageTitle("Error en datos");
PostMessage("Se seleccionaron dos valores contradictorios
(uniformemente,desestructuradamente)");
};
If Member?(ER1:Valor,exhaustivamente) And Member?(ER1:Valor,incompletos)
Then
{
SetPostMessageTitle("Error en datos");
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.
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
294
PROCEDIMIENTO Aplicacin:PreguntarComportamientoPredominante
COMIENZO
{
If LengthList(ER1:Valor)>0
Then
{
If Member?(TA51:Valor,batch) And Member?(TA5:Valor,interactivo)
Then
{
SetPostMessageTitle("Error en datos");
PostMessage("Se seleccionaron dos valores contradictorios (batch,interactivo)");
};
If Member?(TA51:Valor,batch) And Member?(TA5:Valor,tiempo_real)
Then
{
SetPostMessageTitle("Error en datos");
PostMessage("Se seleccionaron dos valores contradictorios (batch,tiempo_real)");
};
If Member?(TA51:Valor,batch) And Member?(TA5:Valor,dinmico)
Then
{
SetPostMessageTitle("Error en datos");
PostMessage("Se seleccionaron dos valores contradictorios (batch,dinmico)");
};
If Member?(TA51:Valor,ninguno) And Member?(TA5:Valor,interactivo)
Then
{
SetPostMessageTitle("Error en datos");
PostMessage("Se seleccionaron dos valores contradictorios (ninguno,interactivo)");
};
If Member?(TA51:Valor,ninguno) And Member?(TA5:Valor,tiempo_real)
Then
{
SetPostMessageTitle("Error en datos");
PostMessage("Se seleccionaron dos valores contradictorios (ninguno,tiempo_real)");
};
If Member?(TA51:Valor,ninguno) And Member?(TA5:Valor,dinmico)
Then
{
SetPostMessageTitle("Error en datos");
PostMessage("Se seleccionaron dos valores contradictorios (ninguno,dinmico)");
};
};
};
FIN
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
295
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 {
SetPostMessageTitle( "Error en datos" );
PostMessage( "Se seleccionaron dos valores contradictorios Pregunta 8= No, Pregunta 6=
versin_parcial" );
};
If ( GP20:Valor #= versin_gradual And GP18:Valor
#= No )
Then {
SetPostMessageTitle( "Error en datos" );
PostMessage( "Se seleccionaron dos valores contradictorios Pregunta 8= No, Pregunta 6=
versin_gradual" );
};
If ( GP20:Valor #= versin_temprana And GP18:Valor
#= No )
Then {
SetPostMessageTitle( "Error en datos" );
PostMessage( "Se seleccionaron dos valores contradictorios Pregunta 8= No, Pregunta 6=
versin_temprana" );
};
};
FIN
PROCEDIMIENTO Coordinacin:ValorInconsistente
COMIENZO
{
If ( LengthList( GP26:Valor ) > 0 )
Then {
If ( Member?( GP26:Valor, necesario )
And Member?( GP26:Valor, indiferente ) )
Then {
SetPostMessageTitle( "Error en datos" );
PostMessage( "Se seleccionaron dos valores contradictorios (necesario,indiferente)" );
};
If ( Member?( GP26:Valor, factible )
And Member?( GP26:Valor, indiferente ) )
Then {
SetPostMessageTitle( "Error en datos" );
PostMessage( "Se seleccionaron dos valores contradictorios (factible,indiferente)" );
};
};
};
FIN
FORMALIZACIN DE CONOCIMIENTOS
02/09/2003
Bibiana D. Rossi
296
Captulo 8
Implementacin
del Sistema
Bibiana D. Rossi
299
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 :
Bibiana D. Rossi
300
Bibiana D. Rossi
301
Bibiana D. Rossi
302
Bibiana D. Rossi
303
Bibiana D. Rossi
304
Bibiana D. Rossi
305
Bibiana D. Rossi
306
Bibiana D. Rossi
307
Bibiana D. Rossi
308
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
Bibiana D. Rossi
309
Afirmacin / Pregunta
Opciones
Formalmente,
Exhaustivamente,
Uniformemente
los Poco exigente
Bibiana D. Rossi
310
Afirmacin / Pregunta
Opciones
TA1
Otros
TA2
Algortmico
TA3
Batch
TA4
TA5
TA6
TA7
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
descomposicin en subsistemas son:
TA10 Se requiere detectar en etapas tempranas del proyecto problemas de: Desconoce
TA8
Pocas opciones
Pocas opciones
Extensin
Bibiana D. Rossi
311
Bibiana D. Rossi
312
Afirmacin / Pregunta
Opciones
La organizacin
GP1
GP2
GP3
GP4
GP5
GP6
GP7
GP8
GP9
Medianamente probadas
Medio
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?
Bibiana D. Rossi
313
GP13 Existe un sistema previo desarrollado en objetos de forma tal Sin relacin
que el proyecto actual es ..?
No
Desconoce
No
Bajo
No
GP21 Se identifican los riesgos asociados con cada una de las Desconoce
alternativas?
No
No
Bibiana D. Rossi
314
Bibiana D. Rossi
315
Bibiana D. Rossi
316
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.
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.
IMPLEMENTACION DEL SISTEMA 02/09/2003
Bibiana D. Rossi
317
Bibiana D. Rossi
318
Bibiana D. Rossi
319
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
IMPLEMENTACION DEL SISTEMA 02/09/2003
Bibiana D. Rossi
320
Bibiana D. Rossi
321
Bibiana D. Rossi
322
Cascada
Cascada
Objetos
Cascada
CV Tipo de Aplicacin
CV Especificacin Requerimientos
Cascada
Tipo de Aplicacin
Cascada
Cascada
CV Gestin de proyecto
Gestin de proyecto
Objetos
Objetos
CV del Proyecto
CV del Proyecto
Cascada
Cascada
Bibiana D. Rossi
323
Captulo 9
Evaluacin
EVALUACION 02/09/2003
Bibiana D. Rossi
325
Bibiana D. Rossi
326
CV Especificacin Requerimientos
Sin respuesta
- ninguno
CV Tipo de Aplicacin
Tipo de Aplicacin
1- Espiral
2- Objetos
CV Gestin de proyecto
Espiral Objetos
Gestin de proyecto
Sin respuesta
- ninguno
CV del Proyecto
CV del Proyecto
Bibiana D. Rossi
327
Afirmacin / Pregunta
Opciones
Tipo de Aplicacin
ID
Afirmacin / Pregunta
Opciones
TA1
Otros
TA2
TA3
Matemtico
Algortmico
Batch
TA4
TA5
TA6
TA7
TA8
Pocos
Pocos
Desconoce
Varias opciones
Extensin
Ampliacin
Gestin de Proyecto
ID
Afirmacin / Pregunta
Opciones
Terceros
GP1
GP2
GP3
GP4
GP5
GP6
GP7
GP8
GP9
Medianamente probadas
Medio
GP10 El grado de control que se requiere de la gestin del proyecto Medianamente ajustado
es:
EVALUACION 02/09/2003
Bibiana D. Rossi
328
GP11 La
No
GP12
Medianamente necesario
GP13
GP14
GP15
Sin relacin
No
No
Desconoce
No
Si
GP21 Se identifican los riesgos asociados con cada una de las Desconoce
alternativas?
Desconoce
Desconoce
Bibiana D. Rossi
329
REGLA CV-R5
<SI PROGRE-FASES-DESARR ES No uniforme Y Secuencial
ENTONCES MODELADO-PROTOTIPO ES Conveniente>
REGLA TA-R1
<SI NIVELES-COMPOSICION ES Pocos subsistemas
ENTONCES COMPLEJIDAD-SUBSISTEMAS ES Baja>
REGLA TA-R4
<SI COMPONENTES-PREDOMINANTES ES Matematicos
ENTONCES MODELADO-OBJETOS ES Conveniente>
REGLA TA-R12
<SI TIPO-MODOFICACION ES Extension
ENTONCES VARIABILIDAD-PROCESOS ES Alta>
REGLA TA-R13
<SI TIPO-MODIFICACION ES Ampliacion
ENTONCES VARIABILIDAD-PROCESOS ES Alta>
REGLA TA-R16
<SI VARIABILIDAD-PROCESOS ES Alta
ENTONCES MODELADO-PROTOTIPO ES Conveniente>
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
ENTONCES OPCIONALIDAD ES Mltiple>
REGLA TA-R24
<SI MODELADO-OBJETOS ES Conveniente Y MODELADO-PROTOTIPO ES Conveniente Y
OPCIONALIDAD ES Mltiple
ENTONCES CV-PROPU-APLICACION ES Espiral>
REGLA GP-R13
<SI NIVEL-RIESGO ES Mediano
ENTONCES RIESGO-OO ES Aceptable>
REGLA GP-R15
<SI FORMALIDAD ES Medianamente Y CONVENIENCIA-METOD ES Medianamente probada
EVALUACION 02/09/2003
Bibiana D. Rossi
330
EVALUACION 02/09/2003
- ninguno
Espiral Objetos
- ninguno -
Bibiana D. Rossi
331
CV Especificacin Requerimientos
1- Espiral
2- Objetos
CV Tipo de Aplicacin
Espiral Objetos
Tipo de Aplicacin
1- Espiral
2- Objetos
CV Gestin de proyecto
Gestin de proyecto
Espiral
Espiral
CV del Proyecto
CV del Proyecto
Espiral
Espiral Objetos
Afirmacin / Pregunta
Opciones
Tipo de Aplicacin
ID
TA1
TA2
TA3
TA4
TA5
TA6
TA7
Afirmacin / Pregunta
Opciones
EVALUACION 02/09/2003
Bibiana D. Rossi
Otros
Matemtico - Algortmico
Batch
No
Poca dependencia
Si
No
332
TA8
TA9
TA10
TA11
TA12
TA13
Pocos
Pocos
Desconoce
Varias opciones
Varias opciones
Extensin - Ampliacin
Gestin de Proyecto
ID
GP1
GP2
GP3
GP4
GP5
GP6
GP7
GP8
GP9
GP10
GP11
GP12
GP13
GP14
GP15
GP16
GP17
GP18
GP19
Afirmacin / Pregunta
Opciones
Terceros
No
Medianamente probadas
Medianamente probadas
Si
Versin gradual
Alto
Si
Medianamente formal
Medianamente ajustado
Desconoce
Poco necesario
Sin relacin
No
Desconoce
Si
No
Desconoce
Medio
Si
EVALUACION 02/09/2003
Bibiana D. Rossi
333
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
Fecha de inicio: 10/03/1998
Fecha de finalizacin: 10/12/1998
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
<SI RELACION-FASES-DESARROLLO ES Poca dependencia
ENTONCES RETROALIMENTACION-FASES-DESARROLLO ES Baja>
REGLA CV-R5
<SI PROGRE-FASES-DESARR ES No uniforme Y Secuencial
ENTONCES MODELADO-PROTOTIPO ES Conveniente>
REGLA TA-R1
<SI NIVELES-COMPOSICION ES Pocos subsistemas
ENTONCES COMPLEJIDAD-SUBSISTEMAS ES Baja>
REGLA TA-R4
<SI COMPONENTES-PREDOMINANTES ES Matemticos
ENTONCES MODELADO-OBJETOS ES Conveniente>
REGLA TA-R12
<SI TIPO-MODOFICACION ES Extensin
ENTONCES VARIABILIDAD-PROCESOS ES Alta>
REGLA TA-R13
<SI TIPO-MODIFICACION ES Ampliacin
ENTONCES VARIABILIDAD-PROCESOS ES Alta>
REGLA TA-R16
EVALUACION 02/09/2003
Bibiana D. Rossi
334
Bibiana D. Rossi
335
REGLA GP-R29
<SI ENTREGA-INTERMEDIA ES Existe
ENTONCES APLICABILIDAD-OO ES Aplicable Y APLICABILIDAD-PROTOTIPO ES Aplicable>
REGLA GP-R31
<SI PROC-DES-MANTE ES Necesario Y Factible
ENTONCES PROCEDIMIENTOS-DM ES Conveniente>
REGLA GP-R32
<SI PROCEDIMIENTOS-DM ES Conveniente
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA GP-R33
<SI PROC-CAMBIOS ES Acuerdos confirmados
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA GP-R36
<SI CATEGORIA-RIESGO ES Tecnico
ENTONCES FACTOR-RIESGO ES Existe>
REGLA GP-R37
<SI NECESIDAD-METOD ES Medianamente probada Y
FACTIB-METOD ES Medianamente probada
ENTONCES CONVENIENCIA-METOD ES Medianamente probada>
REGLA GP-R15
<SI FORMALIDAD ES Medianamente Y CONVENIENCIA-METOD ES Medianamente probada
ENTONCES APLICABILIDAD-OO ES Aplicable>
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
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
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
<SI DEFINICION-REQUISITOS ES Incierta Y DEFINICION-LIMITES ES Incierta Y
GRADO-DE-CERTIDUMBRE-INICIO ES Parcialmente
EVALUACION 02/09/2003
Bibiana D. Rossi
336
Bibiana D. Rossi
337
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
REGLA R26
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Espiral Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
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
<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 R15
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Objetos>
REGLA R24
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
REGLA R26
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Espiral Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
-------------------------------------------------------------------------------------------------------------------------------------
Espiral Objetos
Espiral Objetos
Espiral
EVALUACION 02/09/2003
Bibiana D. Rossi
338
CV Especificacin Requerimientos
Cascada
Cascada
CV Tipo de Aplicacin
Tipo de Aplicacin
Cascada
Cascada
CV Gestin de proyecto
Gestin de proyecto
Objetos
Objetos
CV del Proyecto
CV del Proyecto
Cascada
Afirmacin / Pregunta
Opciones
Tipo de Aplicacin
ID
TA1
TA2
TA3
TA4
TA5
TA6
TA7
TA8
TA9
Afirmacin / Pregunta
Opciones
EVALUACION 02/09/2003
Bibiana D. Rossi
Otros
Algortmico
Batch
Si
Poca dependencia
No
No
Pocos
Pocos
339
Pocas opciones
Extensin
Gestin de Proyecto
ID
Afirmacin / Pregunta
Opciones
La organizacin
GP1
GP2
GP3
GP4
GP5
GP6
GP7
GP8
GP9
Medianamente probadas
Medio
GP10 El grado de control que se requiere de la gestin del proyecto Poco ajustado
es:
GP11 La
No
GP12
Muy necesario
GP13
GP14
GP15
GP16
GP17
GP18
GP19
GP20
Sin relacin
No
No
Desconoce
No
No
Bajo
No
GP21 Se identifican los riesgos asociados con cada una de las Desconoce
alternativas?
No
No
EVALUACION 02/09/2003
Bibiana D. Rossi
340
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.
Fecha de inicio: 06/08/1999
Fecha de finalizacin: 22/03/2000
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-MODOFICACION 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
EVALUACION 02/09/2003
Bibiana D. Rossi
341
Bibiana D. Rossi
342
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 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 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
<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 TA-R102
<SI PROGRESION-FASES-DESARR ES Uniforme Y Secuencial Y
COMPLEJIDAD-SUBSISTEMAS ES Baja Y
COMPONENTES-PREDOMINANTES ES Algortmico
ENTONCES CV-PROPU-APLIC ES Cascada>
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 TA-R103
<SI PROGRESION-FASES-DESARR ES Uniforme Y Secuencial Y
COMPLEJIDAD-SUBSISTEMAS ES Baja Y COMPORTAMIENTO-PREDOMINANTE ES Batch
ENTONCES CV-PROPU-APLIC ES Cascada>
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>
------------------------------------------------------------------------------------------------------------
Cascada
Cascada
Objetos
Bibiana D. Rossi
343
CV Especificacin Requerimientos
1- Espiral
2- Objetos
3- Cascada
CV Tipo de Aplicacin
Tipo de Aplicacin
Cascada
Cascada
CV Gestin de proyecto
Gestin de proyecto
Cascada
Cascada
CV del Proyecto
CV del Proyecto
Cascada
Afirmacin / Pregunta
Opciones
Tipo de Aplicacin
ID
TA1
TA2
TA3
TA4
TA5
TA6
TA7
TA8
Afirmacin / Pregunta
Opciones
Otros
Algortmico
Batch
Si
Poca dependencia
No
No
Para lograr una mejor comprensin del sistema los niveles de Pocos
descomposicin en subsistemas son:
EVALUACION 02/09/2003
Bibiana D. Rossi
344
Para lograr una mejor manipulacin del sistema los niveles de Pocos
descomposicin en subsistemas son:
TA10 Se requiere detectar en etapas tempranas del proyecto Desconoce
problemas de:
Pocas opciones
TA11 El Diseo del sistema a desarrollar puede resolverse por:
TA9
Redefinicin
Gestin de Proyecto
ID
Afirmacin / Pregunta
Opciones
La organizacin
GP1
GP2
GP3
GP4
Ampliamente probadas
GP5
Si
GP6
GP7
GP8
GP9
GP10
GP11
GP12
GP13
GP14
GP15
GP16
GP17
GP18
GP19
GP20
GP21
GP22
GP23
GP24
GP25
GP26
GP27
GP28
GP29
EVALUACION 02/09/2003
Bibiana D. Rossi
Versin completa
Medio
Si
Poco formal
Medianamente ajustado
No
Poco necesario
Sin relacin
No
No
No
No
No
Sin riesgo
No
No
No
No
No
No
No
No
Indiferente
Si
345
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
Fecha de inicio: 9/02/1999
Fecha de finalizacin: 12/06/1999
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 ER-R5
<SI GRADO-CUMPLIMIENTO-PRODUCTO-FINAL ES Usuario muy exigente
ENTONCES CV-PROPUESTO-REQUISITOS ES Espiral Y Objetos>
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-R11
<SI TIPO-MODOFICACION ES Redefinicin
ENTONCES VARIABILIDAD-PROCESOS ES Alta>
REGLA TA-R16
<SI VARIABILIDAD-PROCESOS ES Alta
ENTONCES MODELADO-PROTOTIPO ES Conveniente>
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
ENTONCES RIESGO-CASCADA ES Aceptable>
EVALUACION 02/09/2003
Bibiana D. Rossi
346
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
ENTONCES CV-PROPU-GESTION ES Cascada>
REGLA GP-R19
<SI NIVEL-RIESGO ES No hay
ENTONCES RIESGO-OO ES Aceptable>
REGLA GP-R22
<SI INTRODUCCION-GRADUAL ES Necesaria
ENTONCES 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
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA R0
<SI CV-PROPU-REQUISITOS ES Cascada Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
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 R0
<SI CV-PROPU-REQUISITOS ES Cascada Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA R6
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA R10
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
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 R0
<SI CV-PROPU-REQUISITOS ES Cascada Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA R6
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Cascada Y
EVALUACION 02/09/2003
Bibiana D. Rossi
347
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA R10
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA TA-R102
<SI PROGRESION-FASES-DESARR ES Uniforme Y Secuencial Y
COMPLEJIDAD-SUBSISTEMAS ES Baja Y
COMPONENTES-PREDOMINANTES ES Algortmico
ENTONCES CV-PROPU-APLIC ES Cascada>
REGLA R0
<SI CV-PROPU-REQUISITOS ES Cascada Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA R6
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA R10
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA TA-R103
<SI PROGRESION-FASES-DESARR ES Uniforme Y Secuencial Y
COMPLEJIDAD-SUBSISTEMAS ES Baja Y COMPORTAMIENTO-PREDOMINANTE ES Batch
ENTONCES CV-PROPU-APLIC ES Cascada>
REGLA R0
<SI CV-PROPU-REQUISITOS ES Cascada Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA R6
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA R10
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
EVALUACION 02/09/2003
Bibiana D. Rossi
348
CV Especificacin Requerimientos
1- Espiral
2- Objetos
CV Tipo de Aplicacin
Espiral Objetos
Tipo de Aplicacin
Objetos
Objetos
CV Gestin de proyecto
Gestin de proyecto
Objetos
Objetos
CV del Proyecto
CV del Proyecto
Objetos
Afirmacin / Pregunta
Opciones
Tipo de Aplicacin
ID
Afirmacin / Pregunta
Opciones
TA1
Software de base
TA2
Grfico Matemtico
TA3
Interactivo Dinmico
TA4
EVALUACION 02/09/2003
Bibiana D. Rossi
349
Mucha dependencia
TA5
TA6
TA7
TA8
Pocos
Pocos
Eficacia
Pocas opciones
Redefinicin - Ampliacin
Gestin de Proyecto
ID
Afirmacin / Pregunta
Opciones
La organizacin
GP1
GP2
GP3
GP4
GP5
GP6
GP7
GP8
GP9
Medianamente probadas
Medio
GP10 El grado de control que se requiere de la gestin del proyecto Poco ajustado
es:
GP11 La
Si
GP12
Muy necesario
GP13
GP14
GP15
Sin relacin
Desconoce
Si
Si
No
No
Desconoce
Desconoce
EVALUACION 02/09/2003
Bibiana D. Rossi
350
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.
Fecha de inicio: 22/02/2000
Fecha de finalizacin: 15/09/2000
Ciclo de Vida recomendado: Objetos
Ciclo de Vida seleccionado: Objetos
------------------------------------------------------------------------------------------
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 ER-R5
<SI GRADO-CUMPLIMIENTO-PRODUCTO-FINAL ES Usuario muy exigente
ENTONCES CV-PROPUESTO-REQUISITOS ES Espiral Y Objetos>
REGLA CV-R3
<SI RELACION-FASES-DESARROLLO ES Mucha dependencia
ENTONCES RETROALIMENTACION-FASES-DESARROLLO ES Alta>
REGLA CV-R5
<SI PROGRE-FASES-DESARR ES No uniforme Y Secuencial
ENTONCES MODELADO-PROTOTIPO ES Conveniente>
REGLA TA-R1
EVALUACION 02/09/2003
Bibiana D. Rossi
351
Bibiana D. Rossi
352
Bibiana D. Rossi
353
REGLA GP-R37
<SI NECESIDAD-METOD ES Medianamente probada Y
FACTIB-METOD ES Medianamente probada
ENTONCES CONVENIENCIA-METOD ES Medianamente probada>
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 R1
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Objetos
ENTONCES CV-PROPU-PROYECTO ES Objetos>
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 R1
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Objetos
ENTONCES CV-PROPU-PROYECTO ES Objetos>
REGLA R18
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Objetos
ENTONCES CV-PROPU-PROYECTO ES Objetos>
Espiral Objetos
Objetos
Objetos
EVALUACION 02/09/2003
Bibiana D. Rossi
354
CV Especificacin Requerimientos
1-Espiral
2- Objetos
CV Tipo de Aplicacin
Espiral Objetos
Tipo de Aplicacin
1-Espiral
2- Objetos
CV Gestin de proyecto
Gestin de proyecto
Espiral
Espiral
CV del Proyecto
CV del Proyecto
Espiral
Espiral Objetos
Afirmacin / Pregunta
Opciones
Tipo de Aplicacin
ID
Afirmacin / Pregunta
Opciones
TA1
Otros
TA2
Algortmico
TA3
Interactivo
TA4
TA5
TA6
EVALUACION 02/09/2003
Bibiana D. Rossi
355
TA7
No
TA8
Muchos
Muchos
Arquitectura Eficacia
Varias opciones
Redefinicin
Gestin de Proyecto
ID
Afirmacin / Pregunta
Opciones
La organizacin
GP1
GP2
GP3
GP4
GP5
GP6
GP7
GP8
GP9
Medianamente probadas
Alto
GP10 El grado de control que se requiere de la gestin del proyecto Medianamente ajustado
es:
GP11 La
No
GP12
Muy necesario
GP13
GP14
GP15
Sin relacin
No
No
Si
No
Si
Si
Si
EVALUACION 02/09/2003
Bibiana D. Rossi
356
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.
Fecha de inicio: 01/08/1998
Fecha de finalizacin: 15/02/2000
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-R5
<SI GRADO-CUMPLIMIENTO-PRODUCTO-FINAL ES Usuario muy exigente
ENTONCES CV-PROPUESTO-REQUISITOS ES Espiral Y Objetos>
REGLA CV-R3
<SI RELACION-FASES-DESARROLLO ES Mucha dependencia
ENTONCES RETROALIMENTACION-FASES-DESARROLLO ES Alta>
REGLA CV-R5
<SI PROGRE-FASES-DESARR ES No uniforme Y Secuencial
ENTONCES MODELADO-PROTOTIPO ES Conveniente>
REGLA TA-R7
<SI COMPORTAMIENTO-PREDOMINANTE ES Interactivo
ENTONCES MODELAO-OBJETOS ES Conveniente>
REGLA TA-R11
<SI TIPO-MODOFICACION ES Redefinicin
ENTONCES VARIABILIDAD-PROCESOS ES Alta>
REGLA TA-R14
EVALUACION 02/09/2003
Bibiana D. Rossi
357
Bibiana D. Rossi
358
REGLA GP-R27
<SI EXPERIENCIA-PREVIA ES No hay
ENTONCES APLICABILIDAD-PROTOTIPO ES Aplicable>
REGLA GP-R30
<SI EXPERIENCIA-TECNICAS-IS ES No hay
ENTONCES APLICABILIDAD-PROTOTIPO ES Aplicable>
REGLA GP-R31
<SI PROC-DES-MANTE ES Necesario Y Factible
ENTONCES PROCEDIMIENTOS-DM ES Conveniente>
REGLA GP-R32
<SI PROCEDIMIENTOS-DM ES Conveniente
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA GP-R33
<SI PROC-CAMBIOS ES Acuerdos confirmados
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA GP-R34
<SI RESPONSABILIDAD ES Organizacin propia
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA GP-R36
<SI CATEGORIA-RIESGO ES Tcnico
ENTONCES FACTOR-RIESGO ES Existe>
REGLA GP-R37
<SI NECESIDAD-METOD ES Medianamente probada Y
FACTIB-METOD ES Medianamente probada
ENTONCES CONVENIENCIA-METOD ES Medianamente probada>
REGLA GP-R15
<SI FORMALIDAD ES Medianamente Y CONVENIENCIA-METOD ES Medianamente probada
ENTONCES APLICABILIDAD-OO ES Aplicable>
REGLA GP-R38
<SI RIESGO-ALTERNATIVAS ES Se identifican Y
IDENTIFICACION-ALTERNATIVAS ES Se identifican
ENTONCES HABILIDAD-RIESGO ES Existe>
REGLA GP-R39
<SI HABILIDAD-RIESGO ES Existe Y IDENTIFICACION-ALTERNATIVAS ES Etapas anteriores
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA GP-R40
<FORMULACION EXTERNA>
REGLA GP-R43
<SI FACTOR-RIESGO ES Existe Y ANALISIS-RIESGO ES Estrategias explicitas
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
EVALUACION 02/09/2003
Bibiana D. Rossi
359
REGLA GP-R44
<SI FACTOR-RIESGO ES Existe Y OBJETIVO-CALIDAD ES Mecanismos explcitos
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
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 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 R15
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Objetos>
REGLA R24
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
REGLA R26
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Espiral Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
REGLA GP-R52
<SI RIESGO-ESPIRAL ES Aceptable
ENTONCES FACTOR-RIESGO ES Existe>
REGLA GP-R43
<SI FACTOR-RIESGO ES Existe Y ANALISIS-RIESGO ES Estrategias explicitas
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
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
EVALUACION 02/09/2003
Bibiana D. Rossi
360
Bibiana D. Rossi
361
Bibiana D. Rossi
362
REGLA R24
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
REGLA R26
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Espiral Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
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
<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 R15
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Objetos>
REGLA R24
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
REGLA R26
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Espiral Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
---------------------------------------------------------------------------------------------------------------------
Espiral Objetos
Espiral Objetos
Espiral
EVALUACION 02/09/2003
Bibiana D. Rossi
363
CV Especificacin Requerimientos
1- Espiral
2- Objetos
3- Cascada
CV Tipo de Aplicacin
Cascada
CV Gestin de proyecto
Cascada
Gestin de proyecto
Cascada
CV del Proyecto
Cascada
CV del Proyecto
Cascada
Afirmacin / Pregunta
Opciones
Tipo de Aplicacin
ID
Afirmacin / Pregunta
Opciones
TA1
Otros
TA2
Algortmico
TA3
Batch
TA4
TA5
TA6
EVALUACION 02/09/2003
Bibiana D. Rossi
364
TA7
No
TA8
Pocos
Pocos
Desconoce
Pocas opciones
Redefinicin
Gestin de Proyecto
ID
Afirmacin / Pregunta
Opciones
La organizacin
GP1
GP2
GP3
GP4
GP5
GP6
GP7
GP8
GP9
Ampliamente probadas
GP10 El grado de control que se requiere de la gestin del proyecto Muy ajustado
es:
GP13 Existe un sistema previo desarrollado en objetos de forma tal Sin relacin
que el proyecto actual es ..?
No
No
No
No
GP21 Se identifican los riesgos asociados con cada una de las Desconoce
alternativas?
Desconoce
EVALUACION 02/09/2003
Bibiana D. Rossi
365
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
Fecha de inicio: 1/05/2000
Fecha de finalizacin: 1/08/2000
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 ER-R5
<SI GRADO-CUMPLIMIENTO-PRODUCTO-FINAL ES Usuario muy exigente
ENTONCES CV-PROPUESTO-REQUISITOS ES Espiral Y Objetos>
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
EVALUACION 02/09/2003
Bibiana D. Rossi
366
Bibiana D. Rossi
367
Bibiana D. Rossi
368
Cascada
Cascada
EVALUACION 02/09/2003
Bibiana D. Rossi
369
CV Especificacin Requerimientos
Cascada
Cascada
CV Tipo de Aplicacin
Tipo de Aplicacin
Cascada
Cascada
CV Gestin de proyecto
Gestin de proyecto
Cascada
Cascada
CV del Proyecto
CV del Proyecto
Cascada
ER3
Afirmacin / Pregunta
Opciones
de
Tipo de Aplicacin
ID
Afirmacin / Pregunta
Opciones
TA1
Otros
TA2
Algortmico
TA3
Batch
TA4
TA5
TA6
EVALUACION 02/09/2003
Bibiana D. Rossi
370
TA7
No
TA8
Pocos
Pocos
Desconoce
Pocas opciones
Ampliacin
Gestin de Proyecto
ID
Afirmacin / Pregunta
Opciones
Terceros
GP1
GP2
GP3
GP4
GP5
GP6
GP7
GP8
GP9
Desconoce
Bajo
GP10 El grado de control que se requiere de la gestin del proyecto Poco ajustado
es:
GP11 La
No
GP12
Medianamente necesario
GP13
GP14
GP15
Sin relacin
No
No
No
No
GP19 Se estima que el factor de riesgo en el desarrollo del sistema Sin riesgo
es:
No
GP21 Se identifican los riesgos asociados con cada una de las Desconoce
alternativas?
Desconoce
Desconoce
EVALUACION 02/09/2003
Bibiana D. Rossi
371
Fecha: 20/05/2001
ID: 007
Proyecto: Consorcio
Lder de Proyecto: Lic. Carlos Beltrami
Objetivo: Desarrollar e Implementar un sistema de facturacin mensual para consorcios de
edificios de departamentos.
Fecha de inicio: 12/05/1998
Fecha de finalizacin: 20/10/1988
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-R13
<SI TIPO-MODIFICACION ES Ampliacin
ENTONCES VARIABILIDAD-PROCESOS ES Alta>
REGLA TA-R16
<SI VARIABILIDAD-PROCESOS ES Alta
ENTONCES MODELADO-PROTOTIPO ES Conveniente>
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
ENTONCES RIESGO-CASCADA ES Aceptable>
EVALUACION 02/09/2003
Bibiana D. Rossi
372
REGLA GP-R16
<SI FACTIB-PROTOTIPO ES No factible Y RIESGO-CASCADA ES Aceptable
ENTONCES CV-PROPU-GESTION ES Cascada>
REGLA GP-R19
<SI NIVEL-RIESGO ES No hay
ENTONCES RIESGO-OO ES Aceptable>
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 R0
<SI CV-PROPU-REQUISITOS ES Cascada Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
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 R0
<SI CV-PROPU-REQUISITOS ES Cascada Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA TA-R102
<SI PROGRESION-FASES-DESARR ES Uniforme Y Secuencial Y
COMPLEJIDAD-SUBSISTEMAS ES Baja Y
COMPONENTES-PREDOMINANTES ES Algortmico
ENTONCES CV-PROPU-APLIC ES Cascada>
REGLA R0
<SI CV-PROPU-REQUISITOS ES Cascada Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
REGLA TA-R103
<SI PROGRESION-FASES-DESARR ES Uniforme Y Secuencial Y
COMPLEJIDAD-SUBSISTEMAS ES Baja Y COMPORTAMIENTO-PREDOMINANTE ES Batch
ENTONCES CV-PROPU-APLIC ES Cascada>
REGLA R0
<SI CV-PROPU-REQUISITOS ES Cascada Y CV-PROPU-APLIC ES Cascada Y
CV-PROPU-GESTION ES Cascada
ENTONCES CV-PROPU-PROYECTO ES Cascada>
EVALUACION 02/09/2003
Cascada
Cascada
Cascada
Bibiana D. Rossi
373
CV Especificacin Requerimientos
Sin respuesta
- ninguno -
CV Tipo de Aplicacin
Tipo de Aplicacin
Objetos
Objetos Cascada
CV Gestin de proyecto
Gestin de proyecto
Cascada
Cascada
CV del Proyecto
CV del Proyecto
Sin Respuesta
Afirmacin / Pregunta
Opciones
Tipo de Aplicacin
ID
Afirmacin / Pregunta
Opciones
TA1
Otros
TA2
Algortmico
TA3
Interactivo
TA4
TA5
TA6
TA7
EVALUACION 02/09/2003
Bibiana D. Rossi
374
TA8
Pocos
Pocos
Desconoce
Pocas opciones
Extensin - Ampliacin
Gestin de Proyecto
ID
Afirmacin / Pregunta
Opciones
GP1
Terceros
GP2
Si
GP3
GP4
GP5
GP6
GP7
GP8
GP9
GP10
GP11
GP12
GP13
GP14
GP15
GP16
GP17
GP18
GP19
Medianamente probadas
Desconoce
Desconoce
Versin parcial
Medio
Desconoce
Medianamente formal
Medianamente ajustado
Desconoce
Poco necesario
Sin relacin
No
No
No
No
No
Bajo
No
GP21 Se identifican los riesgos asociados con cada una de las Desconoce
alternativas?
EVALUACION 02/09/2003
Bibiana D. Rossi
375
Fecha: 20/05/2001
ID: 008
Proyecto: Registracin Contable
Lder de Proyecto: Lic. Carlos Beltrami
Objetivo: Desarrollar e Implementar un sistema de registracin de asientos contables para una
empresa distribuidora de productos farmacolgicos.
Fecha de inicio: 10/05/1998
Fecha de finalizacin: 30/11/1998
Ciclo de Vida recomendado: Cascada
Ciclo de Vida seleccionado: Cascada
------------------------------------------------------------------------------------------
REGLA CV-R3
<SI RELACION-FASES-DESARROLLO ES Mucha dependencia
ENTONCES RETROALIMENTACION-FASES-DESARROLLO ES Alta>
REGLA TA-R1
<SI NIVELES-COMPOSICION ES Pocos subsistemas
ENTONCES COMPLEJIDAD-SUBSISTEMAS ES Baja>
REGLA TA-R7
<SI COMPORTAMIENTO-PREDOMINANTE ES Interactivo
ENTONCES MODELAO-OBJETOS ES Conveniente>
REGLA TA-R12
<SI TIPO-MODOFICACION ES Extensin
ENTONCES VARIABILIDAD-PROCESOS ES Alta>
REGLA TA-R13
<SI TIPO-MODIFICACION ES Ampliacin
ENTONCES VARIABILIDAD-PROCESOS ES Alta>
REGLA TA-R16
<SI VARIABILIDAD-PROCESOS ES Alta
ENTONCES MODELADO-PROTOTIPO ES Conveniente>
REGLA TA-R20
<SI MODELADO-OBJETOS ES Conveniente Y MODELADO-PROTOTIPO ES Conveniente
ENTONCES CV-PROPU-APLICACION ES Objetos>
REGLA GP-R2
<SI NIVEL-RIESGO ES Bajo
ENTONCES RIESGO-CASCADA ES Aceptable>
REGLA GP-R3
<SI SOFT-PROTOTIPO ES No disponible Y No adquirible
ENTONCES FACTIBILIDAD-PROTOTIPO ES No factible>
REGLA GP-R12
<SI NIVEL-RIESGO ES Bajo
ENTONCES RIESGO-OO ES Aceptable>
REGLA GP-R16
<SI FACTIB-PROTOTIPO ES No factible Y RIESGO-CASCADA ES Aceptable
ENTONCES CV-PROPU-GESTION ES Cascada>
REGLA GP-R28
<SI ENTREGAS ES Versin parcial
EVALUACION 02/09/2003
Bibiana D. Rossi
376
CV Especificacin Requerimientos
1- Espiral
2- Objetos
CV Tipo de Aplicacin
Espiral Objetos
Tipo de Aplicacin
Objetos
Objetos
CV Gestin de proyecto
Gestin de proyecto
Objetos
Objetos
CV del Proyecto
CV del Proyecto
Objetos
Bibiana D. Rossi
377
Afirmacin / Pregunta
Opciones
Tipo de Aplicacin
ID
Afirmacin / Pregunta
Opciones
TA1
TA2
TA3
TA4
TA5
TA6
TA7
Otros
Grafico - Otro
Interactivo - Tiempo Real
TA8
Muchos
Muchos
Arquitectura Eficacia
Pocas opciones
Emisin gradual
Gestin de Proyecto
ID
Afirmacin / Pregunta
Opciones
Terceros
GP1
GP2
GP3
GP4
GP5
GP6
GP7
GP8
GP9
Medianamente probadas
Medio
GP10 El grado de control que se requiere de la gestin del proyecto Muy ajustado
es:
GP11 La
EVALUACION 02/09/2003
explcitamente Si
Bibiana D. Rossi
378
GP13 Existe un sistema previo desarrollado en objetos de forma tal Sin relacin
que el proyecto actual es ..?
Desconoce
Desconoce
No
Si
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.
Fecha de inicio: 10/07/1999
Fecha de finalizacin: 20/05/2000
Ciclo de Vida recomendado: Objetos
Ciclo de Vida seleccionado: Objetos
------------------------------------------------------------------------------------------
REGLA ER-R3
<SI TIPO-DEFINICION ES Informalmente Y Incompleto Y Desestructuradamente
ENTONCES DEFINICION-REQUISITOS ES Incierta Y DEFINICION-LIMITES ES Incierta>
EVALUACION 02/09/2003
Bibiana D. Rossi
379
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 ER-R5
<SI GRADO-CUMPLIMIENTO-PRODUCTO-FINAL ES Usuario muy exigente
ENTONCES CV-PROPUESTO-REQUISITOS ES Espiral Y Objetos>
REGLA CV-R3
<SI RELACION-FASES-DESARROLLO ES Mucha dependencia
ENTONCES RETROALIMENTACION-FASES-DESARROLLO ES Alta>
REGLA CV-R5
<SI PROGRE-FASES-DESARR ES No uniforme Y Secuencial
ENTONCES MODELADO-PROTOTIPO ES Conveniente>
REGLA TA-R5
<SI COMPONENTES-PREDOMINANTES ES Grficos
ENTONCES MODELADO-OBJETOS ES Conveniente>
REGLA TA-R7
<SI COMPORTAMIENTO-PREDOMINANTE ES Interactivo
ENTONCES MODELADO-OBJETOS ES Conveniente>
REGLA TA-R8
<SI COMPORTAMIENTO-PREDOMINANTE ES Tiempo real
ENTONCES MODELADO OBJETOS ES Conveniente>
REGLA TA-R14
<SI FACTORES-DISEO ES Problemas de arquitectura
ENTONCES MODELADO-PROTOTIPO ES Conveniente>
REGLA TA-R15
<SI FACTORES-DISEO ES Problemas de eficacia
ENTONCES MODELADO-PROTOTIPO ES Conveniente>
REGLA TA-R20
<SI MODELADO-OBJETOS ES Conveniente Y MODELADO-PROTOTIPO ES Conveniente
ENTONCES CV-PROPU-APLICACION ES Objetos>
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
<SI FORMALIDAD ES Medianamente 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
EVALUACION 02/09/2003
Bibiana D. Rossi
380
EVALUACION 02/09/2003
Bibiana D. Rossi
381
REGLA GP-R44
<SI FACTOR-RIESGO ES Existe Y OBJETIVO-CALIDAD ES Mecanismos explcitos
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA R1
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Objetos
ENTONCES CV-PROPU-PROYECTO ES Objetos>
REGLA R18
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Objetos
ENTONCES CV-PROPU-PROYECTO ES Objetos>
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 R1
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Objetos
ENTONCES CV-PROPU-PROYECTO ES Objetos>
REGLA R18
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Objetos
ENTONCES CV-PROPU-PROYECTO ES Objetos>
REGLA GP-R50
<SI NIVEL-RIESGO ES Mediano
ENTONCES RIESGO-ESPIRAL ES Aceptable>
REGLA GP-R52
<SI RIESGO-ESPIRAL ES Aceptable
ENTONCES FACTOR-RIESGO ES Existe>
REGLA GP-R43
<SI FACTOR-RIESGO ES Existe Y ANALISIS-RIESGO ES Estrategias explicitas
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA GP-R44
<SI FACTOR-RIESGO ES Existe Y OBJETIVO-CALIDAD ES Mecanismos explcitos
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA GP-R56
<SI FACTOR-RIESGO ES Existe Y HABILIDAD-RIESGO ES Existe Y
TECNICAS-AR ES Se dispone
ENTONCES RIESGO ES Evaluable>
EVALUACION 02/09/2003
Bibiana D. Rossi
382
---------------------------------------------------------------------------------------------------------------------
Espiral Objetos
Objetos
Objetos
CV Especificacin Requerimientos
1- Espiral
2- Objetos
CV Tipo de Aplicacin
Espiral Objetos
Tipo de Aplicacin
Espiral Objetos
1- Espiral
2- Objetos
CV Gestin de proyecto
Gestin de proyecto
Espiral
Espiral
CV del Proyecto
CV del Proyecto
Espiral
Afirmacin / Pregunta
Opciones
EVALUACION 02/09/2003
Bibiana D. Rossi
383
ER3
de
Desestructuradamente
los Muy exigente,
Tipo de Aplicacin
ID
Afirmacin / Pregunta
Opciones
TA1
Otros
TA2
TA3
Matemtico
Algortmico - Otro
Interactivo
TA4
TA5
TA6
TA7
TA8
Muchos
Muchos
Arquitectura Eficacia
Varias opciones
Redefinicin Extensin
Ampliacin
Gestin de Proyecto
ID
Afirmacin / Pregunta
Opciones
La organizacin
GP1
GP2
GP3
GP4
GP5
GP6
GP7
GP8
GP9
Poco probadas
GP10 El grado de control que se requiere de la gestin del proyecto Medianamente ajustado
es:
GP13 Existe un sistema previo desarrollado en objetos de forma tal Sin relacin
que el proyecto actual es ..?
No
Bibiana D. Rossi
384
Si
No
Si
Si
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.
Fecha de inicio: 14/03/1998
Fecha de finalizacin: 30/05/1999
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 ER-R5
EVALUACION 02/09/2003
Bibiana D. Rossi
385
Bibiana D. Rossi
386
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
ENTONCES OPCIONALIDAD ES Mltiple>
REGLA TA-R24
<SI MODELADO-OBJETOS ES Conveniente Y MODELADO-PROTOTIPO ES Conveniente Y
OPCIONALIDAD ES Mltiple
ENTONCES CV-PROPU-APLICACION ES Espiral>
REGLA GP-R20
<SI SOFT-PROTOTIPO ES Factible
ENTONCES FACTIBILIDAD-PROTOTIPO ES Factible>
REGLA GP-R22
<SI INTRODUCCION-GRADUAL ES Necesaria
ENTONCES APLICABILIDAD-PROTOTIPO ES Aplicable>
REGLA GP-R23
<SI PARTICIPACION-USUARIO ES Fuerte
ENTONCES APLICABILIDAD-PROTOTIPO ES Aplicable>
REGLA GP-R24
<SI ENTREGAS ES Versin temprana
ENTONCES ENTREGA-INTERMEDIA ES Existe>
REGLA GP-R27
<SI EXPERIENCIA-PREVIA ES No hay
ENTONCES APLICABILIDAD-PROTOTIPO ES Aplicable>
REGLA GP-R29
<SI ENTREGA-INTERMEDIA ES Existe
ENTONCES APLICABILIDAD-OO ES Aplicable Y APLICABILIDAD-PROTOTIPO ES Aplicable>
REGLA GP-R30
<SI EXPERIENCIA-TECNICAS-IS ES No hay
ENTONCES APLICABILIDAD-PROTOTIPO ES Aplicable>
REGLA GP-R31
<SI PROC-DES-MANTE ES Necesario Y Factible
ENTONCES PROCEDIMIENTOS-DM ES Conveniente>
REGLA GP-R32
<SI PROCEDIMIENTOS-DM ES Conveniente
ENTONCES APLICABILIDAD-ESPIRAL ES Aplicable>
REGLA GP-R33
EVALUACION 02/09/2003
Bibiana D. Rossi
387
Bibiana D. Rossi
388
Bibiana D. Rossi
389
REGLA R24
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
REGLA R26
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Espiral Y
CV-PROPU-GESTION ES Espiral ENTONCES CV-PROPU-PROYECTO ES Espiral>
REGLA R24
<SI CV-PROPU-REQUISITOS ES Espiral Y CV-PROPU-APLIC ES Objetos Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
REGLA R26
<SI CV-PROPU-REQUISITOS ES Objetos Y CV-PROPU-APLIC ES Espiral Y
CV-PROPU-GESTION ES Espiral
ENTONCES CV-PROPU-PROYECTO ES Espiral>
----------------------------------------------------------------------------------------------------------
Espiral Objetos
Espiral Objetos
Espiral
Bibiana D. Rossi
390
EVALUACION 02/09/2003
Bibiana D. Rossi
391
EVALUACION 02/09/2003
Bibiana D. Rossi
392
Captulo 10
Conclusiones y
Futuras Lneas de
Investigacin
Bibiana D. Rossi
395
Bibiana D. Rossi
396
Bibiana D. Rossi
397
Bibiana D. Rossi
398
Captulo 11
Bibliografa
Bibiana D. Rossi
401
BIBLIOGRAFIA 02/09/2003
Bibiana D. Rossi
402
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
BIBLIOGRAFIA 02/09/2003
Bibiana D. Rossi
403
Captulo 12
Anexos
02/09/2003
Bibiana D. Rossi
407
02/09/2003
Bibiana D. Rossi
408
02/09/2003
Bibiana D. Rossi
409
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.
02/09/2003
Bibiana D. Rossi
410
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
02/09/2003
Bibiana D. Rossi
411
Consultora BIROSSI
Nro. Solicitud:.
Solicitud de cambios
Estimacin del cambio
Solucin Propuesta por el equipo tcnico
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
______________________________________________________
Tiempo evaluado en horas / hombre por perfil:
Perfil
Ing. Conocimiento
Programador
Estimacin en Horas
.
.
Costo del cambio:
Perfil
Estimacin en
Horas
Costo x hora
Costo total
Ing. Conocimiento
Programador
.
.
TOTAL
Cronograma de desarrollo e implementacin:
_____________________________________________________________________
__________________________________________________________________
__________________________________________________________________
______________________________________________________
Plan de Pruebas:
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
______________________________________________________
Hoja : 2
02/09/2003
Bibiana D. Rossi
412
Orden de cambio
Consultora BIROSSI
Nro. Solicitud:.
Orden de cambio
Producto : SECV
Fecha: dd/mm/aaaa
Responsable del Pedido:
Area / Sector / Empresa :
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
02/09/2003
Bibiana D. Rossi
413
Consultora BIROSSI
Nro. Solicitud:.
Orden de cambio
Documentacin anexa
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
___________________________________________________
Estimacin del cambio
Tiempo evaluado en horas / hombre por perfil:
Perfil
Ing. Conocimiento
Programador
.
.
Estimacin en Horas
Nombre Funcionario
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
______________________________________________________
Fecha de entrega:
Hoja : 2
02/09/2003
Bibiana D. Rossi
414
Consultora BIROSSI
Registro de Cambios
Producto
Solicitud Nmero
Responsable del Pedido
Area / Sector / Empresa
Recibido por
Fecha de recepcin
Descripcin breve
: SECV
: ..
: ...
:
: ..
: dd/mm/aaaa
: ______________________________________
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
02/09/2003
Bibiana D. Rossi
415
Registro de Instalaciones
Consultora BIROSSI
Registro de Instalaciones
Producto
Solicitud Nmero
Descripcin breve
: SECV
: ..
: ______________________________________
Responsable
: .
Fecha de terminacin
: dd/mm/aaaa
Lugar de instalacin
Fecha de instalacin
Versin instalada
: ..
: dd/mm/aaaa
: ..
Hoja : 1
02/09/2003
Bibiana D. Rossi
416
Consultora BIROSSI
Fecha: dd/mm/aaaa
Fecha
Recep.
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
Prioridad
..
..
..
..
..
..
..
..
..
..
..
..
..
Estado
Actual
.
.
.
.
.
.
.
.
.
.
.
.
.
Hoja : 1
02/09/2003
Bibiana D. Rossi
417
Informe de Instalaciones
Consultora BIROSSI
Fecha: dd/mm/aaaa
Informe de Instalaciones
Producto: SECV
Desde Fecha: dd/mm/aaaa
Descripcin
Lugar
Instalado
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
02/09/2003
Bibiana D. Rossi
418
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.
Preparacin de Preguntas:
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
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 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
Experto: Dr. Gregorio Perichinsky
Ingeniero del Conocimiento: Bibiana Rossi
Lugar: oficina del experto
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.
02/09/2003
Bibiana D. Rossi
419
02/09/2003
Bibiana D. Rossi
420
Conocimientos extrados:
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.
02/09/2003
Bibiana D. Rossi
421
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.
02/09/2003
Bibiana D. Rossi
422
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.
Preparacin de Preguntas:
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?
02/09/2003
Bibiana D. Rossi
423
02/09/2003
Bibiana D. Rossi
424
02/09/2003
Bibiana D. Rossi
425
02/09/2003
Bibiana D. Rossi
426
02/09/2003
Bibiana D. Rossi
427
Conocimientos extrados:
Los conocimientos extrados de la sesin III se encuentran reflejados en el en
el captulo IV, Estudio de Viabilidad.
02/09/2003
Bibiana D. Rossi
428
Desventajas
Desventaja 1
Desventaja 2
...
Desventaja 1
Desventaja 2
...
Desventaja 1
Desventaja 2
...
Casos de Ejemplo
Descripcin
Descripcin
Descripcin
02/09/2003
Bibiana D. Rossi
429
02/09/2003
Bibiana D. Rossi
430
Bibiana D. Rossi
431
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
(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
ANEXO 12.1: ADQUISICIN DE CONOCIMIENTOS 02/09/2003
Bibiana D. Rossi
432
Bibiana D. Rossi
433
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.
ANEXO 12.1: ADQUISICIN DE CONOCIMIENTOS 02/09/2003
Bibiana D. Rossi
434
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.
Bibiana D. Rossi
435
PROTOTIPOS
Modelo
Ventajas
Desventajas
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)
ANEXO 12.1: ADQUISICIN DE CONOCIMIENTOS 02/09/2003
Bibiana D. Rossi
Ejemplo
436
Modelo
Ventajas
Prototipo de
Sirve para formular los requerimientos de un
usar y tirar
sistema de Software cuando los requerimientos
del usuario son vagos, incompletos o inestables
Los incrementos se pueden planear para
Prototipado
gestionar riesgos tcnicos
Incremental
Se ajusta a entornos de alta incertidumbre, por
no tener la necesidad de poseer un conjunto
exhaustivo de requisitos, (especificaciones,
diseos, etc.), al comenzar el sistema, ya que
cada refinamiento ampla los requisitos y las
especificaciones derivadas de la fase anterior.
Es particularmente til cuando la dotacin de
personal no est disponible para una
implementacin completa en cuanto a la fecha
lmite de gestin que se ha establecido (5)
Prototipado
Rpido
Bibiana D. Rossi
Desventajas
Se puede caer en el error de prolongar en el
desarrollo final, decisiones ineficientes
utilizadas en el prototipo
Falta de planificacin a largo plazo
Tentacin de caer en el modelo de codificar
y corregir
Existe el problema de determinar si los
requisitos propuestos son vlidos, se
detectan tarde.
Puede encomendar demasiados recursos a
una solucin errnea
Es difcil para ms de una persona trabajar
en un nico prototipo
Aunque permite el cambio continuo de
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.
Descuida el anlisis apropiado
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.
Ejemplo
437
CASCADA
Modelo
Ventajas
Cascada
Ayuda a prevenir que se sobrepasen las fechas de
entrega y los costos esperados.
Al final de cada fase el personal tcnico y los
usuarios tienen la oportunidad de revisar el progreso
del proyecto.
Da facilidades a los gestores para controlar el
progreso de los sistemas.
Reconocimiento de ciclos de realimentacin entre
etapas (2)
Es mejor que un enfoque hecho al azar (5)
Bibiana D. Rossi
Desventajas
Ejemplo
Enfoque secuencial para construir un producto en
el cual la iteracin no es evidente.
Se tarda mucho tiempo en pasar por todo el ciclo,
dado que hasta que no se finalice una fase no se
pasa a la siguiente.
El enfoque top-down necesita ser matizado con un
paso de reciclado (vuelta para atrs) para cubrir
temas como riesgo y reuso de mdulos de
software (2)
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
438
Modelo
Ventajas
Desventajas
Ejemplo
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
Bibiana D. Rossi
439
ESPIRAL
Modelo
Modelo en
espiral
Ventajas
Desventajas
Ejemplo
Trabaja bien en los desarrollos internos, pero
En el desarrollo interno existe una gran flexibilidad y
necesita un ajuste posterior para adaptarlo a la
libertad para ajustarse a los acuerdos etapa por etapa, para
subcontratacin de software.
aplazar acuerdos de opciones especficas, para establecer
Necesidad de expertos en evaluacin de riesgos
miniespirales para resolver caminos crticos, para ajustar
para identificar y manejar las fuentes de riesgos
niveles de esfuerzo, o para acomodar prcticas como
de un proyecto.
prototipado desarrollo evolutivo y uso de mtodos de
Requiere una considerable habilidad para la
diseo ajustado al costo.
evaluacin del riesgo y depende de ella para el
Alienta el desarrollo de especificaciones que no son
xito (5)
necesariamente uniformes, exhaustivas o formales, al
Deposita una gran cantidad de confianza en la
diferir la elaboracin detallada de los elementos de
habilidad de los desarrolladores de software
software de bajo riesgo, y evita roturas innecesarias en sus
para identificar y manejar las fuentes de riesgo
diseos, hasta que los elementos de alto riesgo del diseo
del proyecto. (5)
sean establecidos.
En general, los pasos del proceso necesitan una
La revisin de los principales objetivos sirve para
elaboracin adicional para asegurar que todos
asegurar que todas las partes involucradas estn de
los participantes de un desarrollo de software
acuerdo respecto al mtodo de trabajo para la siguiente
estn operando en un contexto consistente. (5)
fase.
Presenta un riesgo de decisiones prematuras de
Existe un reconocimiento explcito de las diferentes
diseo
alternativas para alcanzar los objetivos de un proyecto.
Puede demostrar dificultad para ejecutar
La identificacin de riesgos asociados con cada una de las
especificaciones con una adecuada performance
alternativas y las diferentes maneras de resolverlos son el
En el desarrollo de software bajo contrato no
centro del modelo. Con los mtodos tradicionales, es
existe esta flexibilidad y libertad, por lo que es
habitual dejar las partes, ms difciles para el final y
necesario mucho tiempo para definir los
empezar con las ms fciles y de menor riesgo,
contratos, ya que los entregables no estn
obteniendo as la ilusin de un gran avance.
previamente definidos de forma clara.
Bibiana D. Rossi
440
Modelo
Ventajas
Desventajas
Todava no encaja en el mundo de la
Contesta la pregunta cunto es suficiente? para cada
adquisicin de software por contrato.
una de las fuentes de la actividad del proyecto y para el
A no ser que se realice una inspeccin por
manejo de los recursos.
expertos, en este tipo de proyecto se tendr la
La divisin de los proyectos en ciclos, cada uno con un
ilusin de progresar por un perodo, y sin
acuerdo al final de cada ciclo, implica que existe un
embargo, se encuentra dirigido directamente
acuerdo para los cambios que hay que realizar o para
hacia el desastre.
terminar el proyecto, en funcin de lo que se ha aprendido
Las personas pueden encontrarlo difcil para
desde el inicio del proyecto.
dirigir transformaciones
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.
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)
Bibiana D. Rossi
Ejemplo
441
Modelo
Ventajas
Desventajas
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
Bibiana D. Rossi
Ejemplo
442
ORIENTACION A OBJETOS
Modelo
Ventajas
Desventajas
Ejemplo
Otro aspecto importante en la tecnologa de
Modelo para
La tecnologa de objetos pretende acelerar el desarrollo de
objetos es la de "generalizar" los componentes
Desarrollo de
sistemas de una manera iterativa e incremental.
La ventaja principal que permiten fijar hitos ms
para que sean reutilizables, lo que incrementa
Sistemas
frecuentemente, realizando entregas de sistemas que son
los costos de desarrollo entre un 10 y 50%, por
Orientados a
operativos cada dos o tres meses para recibir
lo que resulta imprescindible un desarrollo que
Objetos
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".
La distincin entre anlisis y diseo podr
Produce un diseo limpio y fcil de comprender, que
Object Modeling
parecer a veces arbitraria y confusa
resulta ms fcil de probar, mantener y extender
Tool (OMT) (6)
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
ANEXO 12.1: ADQUISICIN DE CONOCIMIENTOS 02/09/2003
Bibiana D. Rossi
443
Ejemplo
Ventajas
Desventajas
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.
Bibiana D. Rossi
Ejemplo
444
Modelo
Modelos CV OO
Booch
Ventajas
Desventajas
La tecnologa de objetos pretende generalizar
La tecnologa de objetos pretende acelerar el
los componentes para que sean reutilizables, lo
desarrollo de sistemas de una manera iterativa e
que incrementa los costos de desarrollo entre
incremental.
un 10 y un 50%, por lo que resulta
Permite fijar hitos ms frecuentemente,
imprescindible un desarrollo que optimice esta
realizando entregas de sistemas que son
inversin.
operativos, para recibir retroalimentacin del
Dificultad de gestionar de manera formal los
cliente lo antes posible e ir adaptando la
proyectos que siguen estos ciclos de vida
aplicacin segn cambian las necesidades y se
aunque, como se ha sealado, este problema se
refinan los requisitos.
puede paliar diferenciando el micro del
El enfoque evolutivo que el macroproceso
adopta para el desarrollo significa que hay
macroproceso
En algunos casos tiene un alto costo de puesta
oportunidades para identificar problemas en
en marcha (7)
momentos tempranos del ciclo de vida y
Tiene problemas de eficacia en ciertos casos
responder a estos riesgos antes de que
particulares (7)
comprometan el xito del proyecto (7)
El microproceso del desarrollo orientado a
El proceso de desarrollo OO ayuda
objetos es inestable de forma innata y requiere
explcitamente a desarrollar factores de
una direccin activa para forzar su conclusin
calibracin (7)
(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.
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
Bibiana D. Rossi
Ejemplo
445
Modelo
Ventajas
Desventajas
Ejemplo
Bibiana D. Rossi
446
OTROS
Modelo
Ventajas
Maneja adecuadamente aspectos
Parnas information
concernientes al desarrollo de familias de
hiding approach
programas y a la organizacin de software
para acomodar cambios (2)
Two Leg Model
Automatic
Paradigm
Anlisis /Diseo
Estucturado (6)
Modelo
Convencional (4)
Bibiana D. Rossi
Desventajas
No ha sido completamente elaborado para ver
como cubre aspectos tales como prototipado y
reusabilidad (2)
Ejemplo
447
Modelo
Mejora Iterativa
Modelo
Operacional (4)
Ventajas
Desventajas
Ejemplo
Generalmente no es fcil de aplicar cuando el
Facilita el logro de objetivos de desarrollo
proyecto es de tamao considerable(3)
de software para muchos proyectos (3)
Requiere que el problema y su solucin estn bien
Provee una forma prctica de usar un
comprendidos (3)
enfoque top-down step-wise (3)
Los requerimientos formales son inaccesibles para
Los requerimientos formales pueden ser
los usuarios finales y otras personas no tcnicas
procesados por la maquina (4)
(4)
Est disponible prototipado rpido
Presenta peligro de decisiones de diseo
automticamente (4)
prematuras (4)
El testing o verificacin es evitado
Puede resultar difcil ejecutar especificaciones con
derivando la implementacin de la
performance adecuada
especificacin usando solo transformaciones
Es una tecnologa nueva y subdesarrollada (4)
y mapeos que han sido probados (4)
La implementacin transformacional es nueva y
Las especificaciones ejecutables proveen
no desarrollada tecnolgicamente
resultados tempranos y (4)
Las personas pueden encontrarlo difcil para
Maneja objetos formales, lo que implica que
dirigir transformaciones
se pueden desarrollar templetes y
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.
Bibiana D. Rossi
448
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
Bibiana D. Rossi
449