METODOLOGIAS DE

DESARROLLO DE
SOFTWARE
LIC. ESPINOZA ROBLES
ARMANDO DAVID

Conceptos Generales
No existe un consenso entre los autores
sobre el concepto de metodologa.
Una primera definicin: una metodologa es
un conjunto de filosofas, fases,
procedimientos, reglas, tcnicas,
herramientas, documentacin y aspectos de
formacin para los desarrolladores de softw.
segn esto una metodologa especifica:

Como se debe dividir un proyecto en etapas

que tareas se llevan a cabo en cada etapa
que salida se produce y cuanto deben producir
que restricciones se aplican
que herramientas se van a usar
como se gestiona y controla un proyecto

atendiendo a una definicin mas genrica; una

metodologa es un conjunto de procedimientos,
tcnicas, herramientas, y un soporte documental
que ayuda a los desarrolladores ha realizar
softw.
3

 De forma general podemos identificar tres

necesidades principales que se intenta
cubrir con una metodologa:
mejores aplicaciones
un mejor proceso de desarrollo
un proceso estndar en la organizacin

los objetivos de las metodologias son:

registrar los requisitos de un SI
proporcionar un mtodo sistemtico de
desarrollo
construir un SI dentro de un tiempo apropiado y
costos aceptables

 Construir un sistema bien documentado y fcil

de mantener
identificar lo mas rpido posible cualquier
cambio necesario
proporcionar un sistema que satisfaga a todas
las personas (clientes, directivos, auditores etc)

la descomposicin de proceso se realiza a

nivel de tareas elementales.
Para cada tarea se identifica un
procedimiento.
Como resultado se obtiene uno o mas
productos. El Sistema esta compuesto de un
5
conjunto de productos finales

 Para aplicar un procedimientos se usa una o

mas TECNICAS: suelen ser grficas con
apoyo de texto.
Para la realizacin de una tcnica nos
apoyamos en Herramientas de Softw.
Por ejemplo: una metodologa donde hay
una tarea que define un procedimiento para
construir un modelo conceptual de datos.
Para ello se usa la Tcnica de Chen, con la
herramienta Power Designer, resultado
modelo conceptual de datos
6

 Es necesario aclarar la confusin entre los

trminos: metodologa, mtodo y ciclo de
vida.
Una metodologa puede seguir una o varios
modelos de ciclo de vida.
El ciclo de vida indica que es lo que hay
que obtener a lo largo del desarrollo pero no
como. La metodologa si debe indicar como
una metodologa es un conjunto de
mtodos.
7

 Al inicio los mtodos se centraban en una

fase del ciclo de vida: mtodos de
programacin estructurada. Siguiendo los
de diseo estructurado, luego anlisis
estructurado.
Luego se establecen mtodos conjunto de
anlisis y diseo estructurado enlazando las
dos fases.

Visin del desarrollo de

metodologias de desarrollo de SI.

Han ido evolucionando a lo largo del tiempo.

Inicialmente periodo de desarrollo
convencional: practicas artesanales
surge el Desarrollo estructurada: parte de la
programacin estructurada seguido de los
mtodos de anlisis y diseo. Cubre todo el
ciclo de vida completo.
Actualmente aparece el paradigma de la
Orientacin a objetos. Nuevo enfoque en la
Ing.Sft.
9

Desarrollo Convencional
En los aos 50 no exista metodologas de
desarrollo. El desarrollo estaba a cargo de
programadores.
Se vio la importancia del anlisis y diseo
en el desarrollo del sistemas.
Aparecen los analistas programadores y
analistas de sistemas.
Los analistas se dividen en dos: analistas
funcionales y analistas tcnicos
10

 El enfoque convencional tiene serios

problemas, como los siguientes:
los resultados finales son impredecibles: no se
sabe cuando debe acabar un proyecto.
No hay forma d controlar lo que esta
sucediendo en el proyecto: al no existir fases
establecidas y productos intermedios sobre los
que realizar verificaciones.
Los cambios organizativos afectan
negativamente al proceso de desarrollo: no
suele existir documentacin estandarizada o no
se actualizan oportunamente.
11

Desarrollo estructurado
El nacimiento de tcnicas estructuradas define el
punto de partida donde se pasa de la
construccin de programas de una forma
artesanal a una que sigue unos mtodos de
ingeniera.
El termino programacin estructurada se
introdujo a finales de los 60 pasando las tcnicas
al entorno industrial a mediados de los 70
12

 Programacin Estructurada
el enfoque de desarrollo estructurado
comenz con la programacin.
Diseo estructurado:
mediados de los 60 el enfoque estructurado
se extiende a la fase de diseo, en los que se
define una abstraccin mas amplia usando
los mdulos de programa como
componentes bsicos de construccin.
13

 Diseo Estructurado:
se refina concepto de modularidad
normalizando la estructura de un modulo de
programa, restringiendo las relaciones entre
mdulos.( Yourdon y Constantine)
Anlisis Estructurado:
antes de la aparicin del anlisis
estructurado, las especificaciones de
requisitos se hacen de manera narrativa.

14

 Anlisis estructurado:
las especificaciones estaban afectadas por:
eran monolticas: haba que leer todas la
especificaciones para entender el prob.
Eran redundantes: se repeta la misma
informacin en partes diferentes del doc.
Eran ambiguas: el enfoque de requisitos se
interpretaba diferente por cada usuario.
Imposible de mantener: cuando se finalizaba el
proceso de desarrollo las especificaciones eran
obsoletas.
15

 Por estos inconvenientes haba un

movimiento gradual hacia las
especificaciones funcionales:
Grficas: compuestas por diagramas, apoyados
en tcnicas textuales.
Particionadas: leer de porciones independientes
las especificaciones.
Mnimamente redundantes: de forma que los
cambios afectan a una parte de las
especificaciones.

16

 Este enfoque se conoce como anlisis

estructurado anlisis descendente o top - down.
Desde su aparicin se han hecho mejoras:
dar menor importancia a la construccin de los
modelos fsicos actuales y a los modelos lgicos
actuales
diferenciar mas los modelos fsicos y lgicos.
Ampliar las tec. De anlisis estructurado, para
modelar sistemas en tiempo real
enfocarse en el modelo de datos.
Estudio de eventos.a travs de lista de eventos.
17

 Cronologa de las metodologa mas

representativas en la historia de la Ing. De
Softw.
Ao
Metodologa
1968
concepto sobre prog.estructurada
1974
Tec. De prog. Estructurada
1975
primeros conceptos sobre diseo

estructurado
1977
primeros conceptos sobre anlisis

estructurado
18

Ao
1978
1981
1985
1986
1987
1989
1990

Metodologa
anlisis estructurado
SSADM versin inicial
anlisis y diseo estructurado para
sistemas tiempo real
SSADM siguiente versin
anlisis diseo estructurado para
sistemas tiempo real.
Mtrica versin inicial
SSADM siguiente versin
19

Ano
Metodologa
1993
Mtrica siguiente versin
1995
Mtrica versin actual
Desarrollo OO
el paradigma de OO trata los procesos y
datos de forma conjunta
lo OO comienza con los lenguajes de
programacin LOO en los que se daba
nfasis a la abstraccin de datos para los que
se adjuntaba un conjunto de operaciones.
20

 A partir de mediados de los 80 OO alcanzo

gran resonancia.
Por otra parte los conceptos de tcnicas
estructuradas han servido de base para
muchas de las metodolgicas OO. As como
el diseo de bloques usado en
telecomunicaciones y otras de inteligencia
artificial e inteligencia del conocimiento.

21

Caractersticas principales de las

Metodolgias
Impacto de la metodologa en el entorno de
desarrollo de Softw.
Todo entorno de desarrollo incluye un
conjunto de componentes que condicionan la
construccin de softw.
La productividad no basta y debe estar
asociado a la calidad de los productos finales.
22

 La metodologa de desarrollo es el corazn

de este entorno e influye muy directamente
en estos dos factores ( productividad y
calidad)

23

Entorno de desarrollo de software

Organizacin de desarrollo de software
Equipo de desarrollo de software
Seleccin de herramientas

Da una estructura visible

Procedimientos
de gestin
Da informes

Coordinan

a direccin

y guan

Metodologa
de
desarrollo

Soportan mtodos

Soporte
automatizado

Tcnicas

Determinan las herramientas necesarias

24

 Dentro del entorno la org.mantiene un

equipo de desarrollo softw.
Los procedimientos de gestin determinan
el tipo de soporte automatizado de softw. Y
hardw.
Los procedimientos de gestin coordinan y
guan a los desarrolladores en el empleo de
tcnicas
el soporte automatizado mejora la
productividad.
25

 La organizacin de desarrollo tiene dos

opciones:
seleccin entre un gran numero de mtodos de
gestin, tcnicas de desarrollo y soporte
automatizado, para crear y desarrollar la
metodologa mas apropiada
analizar y evaluar las metodologias existentes a
adoptar en la organizacin la que mas se ajuste
a sus necesidades. Esta es la mas comn.

26

Caractersticas deseables de una

metodologa

1. Existencia de regalas predefinidas

2. Cobertura total del ciclo de desarrollo
3. Verificaciones intermedias
4. Planificacin y control
5. Comunicacin efectiva
6. Utilizacin sobre un abanico de proyectos
7. Fcil formacin
27

 8. Herramienta CASE
9. La metodologa debe contener
actividades que mejoren el proceso de
desarrollo
10. Soporte de mantenimiento
11. Soporte de la reutilizacion de softw.

28

Clasificacin de las
Metodolgias

Debe tener en cuenta tres punto de vista o

dimensiones.
Enfoque
tipo de Siste formalidad
estructurado
gestin
no formal
orientado proc.
Orientado datos
jerarquico
no jerarquico

mixtos

orientado a obj. Tiempo real

formal
29

Metodologias Estructuradas
Propone la creacin de modelos de sistemas
que representan los procesos, los flujos y la
estructura de los datos de manera
descendente top down
se pasa de una visin general del problema
(nivel alto de abstraccin) hasta llegar a
niveles mas sencillos de abstraccin
30

 Da lugar a los siguientes tipos de

metodolgias:
orientado a procesos
orientado a datos
orientado a estruc. Datos jerrquico
orientado a estruc. Dato no jerrquico

mixtos
31

Metodologa orientado a
procesos
La Ing. De Softw., se funda en el modelo
bsico entrada / proceso/salida de un
sistema.
Este modelo bsico lo usan todas las
metodologas estructuradas, las que se
enfocan en los proceso se llaman orientadas
el proceso.
32

 Se basan en mtodos descendentes de

descomposicin funcional para definir los
requisitos del sistema.
Se apoya en tcnicas grficas dando lugar al
concepto de especificacin estructurada que
es un modelo grfico participando
descendente y jerrquico de los procesos del
sistema y de los datos usados por el sistema

33

 La especificacin estructurada esta

compuesta de:
Diagrama de flujo de datos: representa los
procesos en distintos niveles de descomposicin
los complejos se descomponen en mas sencillos
es la tcnica mas importante del anlisis
estructurado
diccionario de datos: definicin de todos los
datos que aparen en DFD
especificaciones de proceso: describe con
detalle lo que sucede en un proceso
34

Actividades de las principales

metodologias
Metodologa de DeMarco: los pasos son:
1. Estudio del entorno fsico actual: modelo del
sistema actual con sus procedimientos. A travs
de un conjunto de DFD
2. Derivacin del correspondiente modelo lgico
actual: modelo derivado del anterior sin
connotacin fsica.
3. Derivacin del nuevo modelo lgico: tomar
en cuenta las nuevas necesidades. Formado por
un DFD, diccionario de datos y especificaciones
de proceso del sistema.
35

 4. Crear un conjunto de modelos fsicos

alternativos: del modelo lgico se establecen
alternativas se enoje el mas conveniente.
5. Valorar cada opcin: costos y beneficios de
los modelos fsicos.
6. Seleccionar una opcin: selecciona modelo
fsico
7. Empaquetar la especificacin: se recopila
toda la documentacin.

36

Metodologa de Gane y Sarson

Es el resultado de varios aos de practica
en consultora de anlisis y diseo
estructurado.
Creado por la empresa MCAUTO/IST bajo
el nombre de STRADIS SDM.
Es parecido al de DEMARCO, la principal
diferencia es que hay una etapa en la que se
define los contenidos de los almacenes de
datos que aparecen en DFD en 3FN.
37

Diferencias entre metodologias de DeMarco y Gane

Sarson
Fase del anlisis Estructurado
Mtodo DeMarco
Construir el mod.fsico
actual DFD fsico actual
construir mod. Lgico
actual DFD lgico
actual
crear un conjunto de
modelos fsicos
alternativos

Mtodo Gane y Sarson

construir el Mod.
Lgico actual DFD
lgico actual
construir el mod.
Lgico del nuevo
sistema: datos en 3FN
seleccionar un Mod.
logico
38

 Mtodo DeMarco
estimar costos y
tiempo de cada opcin
seleccionar un modelo
empaquetar la
especificacin

Metod Gane y Sarsan

crear nuevo mod.
Fsico del sistema
empaquetar la
especificacin

39

Metodologa de Yourdon / Constantine

Consta de las siguientes fases
1. realizar los DFD del sistema
2. Realizar el diagrama de estructuras a partir del
DFD, mediante anlisis de transformacin, y
anlisis de transaccin.
3. Evaluacin del diseo midiendo la calidad de
la estructura mediante el acoplamiento y cohesin
preparacin del diseo para la implementacion
dividiendola en Und. Fsicas o cuadernos de
carga.
40

Metodologias Orientados a datos

Jerrquicos
En el mod. Basico Entrada / Proceso/Salida,
esta Metodologia se orienta a las entradas y
salidas.
Primero se define la estructura del dato, a
partir de estos se dividen los componentes
procedimentales. Se destaca que:

41

 La estructura de control del programa debe

ser jerrquica
el proceso de diseo define primero la
estructura de los datos de E/S. Mezclar
todos en una estructura jerrquica de
programa y luego ordenar la lgica
procedimental para que se ajuste a la
estructura.
El diseo lgico precede y esta separado del
fsico
42

Metodologias orientados a datos no

Jerarquicos
Se divide en cuatro etapas con los siguientes
objetivos:
Planificacin: construir arquitectura de
informacin y una estrategia que soporte los
objetivos de la org.
Anlisis: comprender las reas del negocio y
determinar los requisitos del sistema.
Diseo: establecer sistema deseado por el
usuario y alcanzable por la tec.
Construccin: construir un sistema que cumpla
lo anterior.

43

Metodologa Orientado a Objetos.

En la metodologa de anlisis y diseo
estructurado se examina los sistemas desde las
funciones o tareas que deben realizar, que se
descomponen sucesivamente en tareas mas
pequeas, para formar los mdulos de la
aplicacin.
En OO cobra importancia el aspecto del
modelado del sistema examinando el dominio
del problema como un conjunto de objetos que
interactuan entre si.
44

 En las metodologias tradicionales

(estructuradas) se produce una dicotoma
entre : funcin y datos.
En OO se propugna un enfoque unificar de
ambos espectos que se encapsulan en los
objetos.
Se puede identificar dos enfoques en metod.
OO:
revolucionarios o puros:
Sintetista o evolutivo:
45

Sistemas en Tiempo Real

Son los sistemas independientes del tiempo
que procesan la informacin, mas
orientados al control, se controlan y son
controlados por eventos externos.
Sist. Tiempo Real es aquel que controla un
ambiente recibiendo datos procesandolos y
devolviendolos con suficiente rapidez como
para influir en dicho ambiente en ese momento

46

 Los sistemas en tiempo real se caracterizan

por:

Concurrencia
Prioridades a determinados procesos
existe comunicacin entre tareas
accesos simultaneo a datos comunes

no se debe confundir sistemas en tiempo

real y sistemas en lnea.
Sistemas en lnea interactuan con personas
sist. Tiempo real interactuan con personas y
depsitos fsicos del exterior
47

 Para especificar los requisitos de este

sistema hay que incluir nuevos conceptos
para:

manejo de interrupciones
comunicacin y sincronizacin de tareas
gestionar procesos concurrentes
dar respuesta oportuna y a tiempo entre eventos
externos
datos continuos o discretos

48

Principales Metodologias de
Desarrollo
Metodologa MERISE:
se planteo en 1972. Su primera versin
1976 fue iniciativa del ministerio de
industria francs.
Se realizo con apoyo de diversas empresas,
el proyecto finalizo 1978 dando lugar al
MERISE
49

 La mayor aportacin de la metodologa es:

ciclo de vida mas largo: se incluye la etapa de
planificacin previa al desarrollo denominada
esquema director
introduccin de 2 ciclos complementarios: ciclo
de abstraccin y ciclo de decisin. El ciclo de
abstraccin tiene tres niveles:
nivel conceptual: finalidad la empresa
nivel organizativo: organizacin adecuada
nivel fsico: interrogacin medios tcnicos

50

Resultados en los Niveles de

MERESI

Nivel
Conceptual

Datos
Mod.
Conceptual
datos
Organizativo Mod. Lgico
datos
Fsico
Mod. Fsico
datos

Tratamiento
Mod. Concep.
De tratamiento
Mod. Organiz.
Tratamiento
Mod. Operativ
tratamiento
51

 Fases de la Metodologa:
1. Estudio preliminar: estudia situacin
existente propone solucin global
2. Estudio detallado
3. Implementacion: realiza los programas que
correspondan, se divide en :
estudio tcnico:
Produccin de Programas

4. Realizacin y puesta en Marcha

52

Metodologa SSADM
A iniciativa del Gob. Britnico a principios
de los 80 se plantea estandarizar proyectos
de tecnologa de informacin
Surge el SSADM: structured Systems
Analysis and desing method.

53

 Los aspectos del SSADM son:

nfasis en los usuarios: requisitos y participacin
definicin del proceso de produccin: que hacer,
como , cuando
tres punto de vista : dato, evento, proceso.
Mxima flexibilidad en herramientas y tcnicas
de implementacion.

El SSADM no cubre aspectos como la

planificacin estratgica ni la construccin
del cdigo
54

SSADM

Plan.
Estra.

Estud.
De
viabil

Espec
Anali Especi
logic
de de
del
RequisRequi
sistem

Constr
Dise
y
fisico
prueb

Estudio Completo

desarrollo

Produ

Administracion y control
55

Metodologa Mtrica
El consejo superior de informtica de
Espaa en 1989 acuerda realizar el proyecto
Mtrica
en 1993 aparece la versin 2 de Mtrica.esta
estructurada mediante una sucesin de fases,
mdulos, actividades y tareas. Indica los
productos que se obtienen en cada una de
las tareas
56

 Se divide en las siguientes fases:

Fase 0 : Plan de sistemas de informacin

Fase 1: Anlisis de Sistemas
Fase 2: Diseo del sistema
Fase 3: Construccin de Sistemas
Fase 4 Implementacion de sistemas

se enfoca directamente en el desarrollo.

57

EL PROCESO UNIFICADO
VISION GENERAL
Es importante primero analizar el proceso
para poder ver como funciona un desarrollo
OO.
Se mostrara una primera visin general del
Proceso para tener una idea de cmo llevar
a cabo un proyecto

58

Panormica del Proceso

En la figura se muestra la secuencia al nivel
mas alto del proceso de desarrollo
unificado.

concepcin

elaboracin

construccin

transicion

59

 Este es un proces de desarrollo iterativo y

gradual, el softw. No se elabora de un solo
golpe, sino se libera por partes.
La Etapa de construccin: consta de muchas
iteraciones en cada una se construye softw..,
de calidad, probada e integrado que cumple
un subconjunto de requisitos.
Cada etapa contiene todas la etapas del
ciclo de vida: Anlisis, Diseo,
Implementacion, experimentacin.
60

 Las dos primeras etapas son de:

Concepcin
Elaboracin

en este proceso iterativo algunas cosas se

dejan para al final la etapa de transicin
como las pruebas Beta , la afinacin del
desempeo y el entrenamiento al usuario.
Los proyectos varan: muy formales en
entregas y reuniones o de poca formalidad.
Las iteraciones se dan en cada fase, pero
centralmente en la fase de construccin.
61

 CONCEPCION:
puede adoptar muchas forma, en algunos
proyectos una conversacin en la cafetera.
Para proyectos mayores un amplio estudio
de factibilidad de meses.
Durante esta etapa se define:
la situacin econmica del proyecto. Costos
alcance del proyecto
magnitud del proyecto.

62

 En la concepcin, de define si vale la pena

dedicar algunos mese de investigacin. En
este momento el patrocinador del proyecto
no se compromete mas que ha una mirada
seria del proyecto.

63

 ELABORACION:
Se tiene la luz verde para iniciar el
proyecto. En esta etapa se pose una vaga
idea de los requerimientos.
Se plantea la necesidad de comprender mas
el problema :
Que es lo que va ha construir en realidad ?
Como lo va ha construir?
Que tecnologa empleara?

64

 Al decidir sobre estas interrogantes deber

considerar los riesgos de su proyecto que
pueden ser:
1. Riesgo de requerimientos: entender bien el
problema.
2. Riesgos Tecnolgicos: plantea las sig.
Preguntas:
a) va ha usar objetos:tiene suficiente experiencia en
OO?
B) usara Java, Web: que tambin funciona esta
tecnologa?
65

 3. Riesgos de Habilidades: puede conseguir la

asesora de expertos necesaria?
4. Riesgos Polticos: existen fuerzas Polticas
que se interpongan en su camino?

66

 MANEJO DE LOS RIESGOS DE

REQUERIMIENTOS:
los requerimientos son importantes y en esta
metodologa los casos de uso son el punto
de partida.
Los caso de uso son el motor del proceso de
desarrollo.
Un caso de uso es una iteracin entre
usuario y sistema. Con el fin de lograr un
objetivo
67

 El tamao del caso de uso puede variar segn

el problema.
La importancia radica en que un caso de uso
indica una funcin que el usuario puede
entender y tiene un valor para el.
Los caso de uso son la base para la
comunicacin entre los patrocinadores y los
desarrolladores, durante la planificacin del
proyecto.
En la etapa de elaboracin deben descubrirse
los casos de uso principales del SI.
68

 Es poco probable descubrir todos los casos

de uso. Se debe contar en los mas
importantes.
Para lo cual deber programar entrevistas
con los usuarios , para recopilar los caso de
uso.
Los casos de uso no deben ser muy
detallados, la descripcin ser breve y
precisa, para entender la idea bsica, para
usuarios y desarrolladores.
69

 La otra tarea es elaborar el esqueleto del

Modelo Conceptual del Dominio.
El modelo conceptual responde a las
preguntas como se relacionan los objetos
entre ellos? Y establece los fundamentos
para el modelo de objetos.
El concepto Modelo de Dominio, es el
mundo al que da apoyo el Sistema de
computo.
El Modelo del Dominio y los Casos de Uso
capturan los requerimientos
70

 Los modelos de Anlisis abarcan las

implicancias de estos requerimientos para
una aplicacin
los modelos de Diseo agregan la
infraestructura interna que hace que
funcione la aplicacin.
El propsito del modelo de Dominio es
explorar el vocabulario del dominio en
trminos comprensibles para los expertos.

71

 Contando con un modelo de Dominio y un

modelo de casos de uso, se desarrolla un
Modelo de Diseo que reconoce tanto la
informacin en los objetos del dominio
como el comportamiento de los casos de
uso.
El Modelo de Diseo agrega clases que
realizan el trabajo y proporcionan una
estructura reutilizable.

72

 Se deja correcto las clases de Dominio y los

casos de uso importantes, para luego
agregar de manera progresiva casos de uso,
al modelo de diseo, de forma iterativa.
No se debe construir el sistema de golpe.
Para construir modelos de Diseo se debe
considerar tcnicas que proporciona el
UML, como:
los diagramas de clase: que captura el lenguaje
del negocio.

73

 Los diagramas de Actividades: describen el flujo de

trabajo del negocio. Elimina secuencias innecesarias en
el proceso.

Puede tambin apoyarse en : Diagramas de

Interaccin.
Apoyados en Diagramas Conceptuales de clase y
de actividad se consulta la opinin de los expertos
del Dominio, para identificar reas de riesgo y
casos de uso.
Consolidar los diversos diagramas en un solo
modelo de dominio, que sirve como punto de
partida para un diseo de clases en la etapa de
construccin.
74

 Si el modelo en muy grande mediante

paquetes se divide en partes, consolidando
los diag. De clase y actividad.
El primer modelo de dominio debe
concentrar los detalles mas importantes. El
resto se cubrir durante el desarrollo
iterativo.
El modelo de Dominio es dirigido por
Casos de Uso .

75

 El equipo que construye el dominio debe

ser pequeo ( de dos a cuatro personas)
durante el periodo de elaboracin el lder
del proyecto deber asegurase que el equipo
no se empantane en detalles, ni que pierda
contacto con la realidad.
Para comprender los requerimientos se debe
construir prototipos de las partes intrincadas
de los casos de uso.

76

 MANEJO DE RIESGOS TECNOLOGICOS:

para abarcar los riesgos tecnolgicos se debe
construir prototipos, que pruebe la tecnologa
que uno quiere usar. Si trabaja en VB y SQL.
Conseguir una versin adecuada del VB con sus
herramientas
construir partes sencillas del modulo y ver como
funciona
construir la BD y conectar al VB
probar las diversas herramientas .

77

 Los riesgos tecnolgicos mayores son los

inherentes a la manera como se integran los
componentes de un diseo.
Concentrese en la reas que parezca que mas
adelante ser difcil de cambiar. Preguntese:
qu suceder si no trabaja una pieza de la
tecnologa
qu ocurrir si no podemos conectar dos piezas
del rompecabezas?
cul es la probabilidad de que algo vaya mal?
qu haremos si eso sucede?
78

 Se deber analizar los caso de uso a medida

que aparezcan, a fin de ver si tiene algo que
pueda echar por tierra su diseo.
Los diagramas de clase y de iteracin son
tiles para mostrar como se comunican los
componentes.
Los diagramas de paquetes pueden mostrar
un cuadro de alto nivel de los componentes
los diagramas de desplazamiento
(deployment) proveen una visin panormica
de la distribucin de piezas.
79

 MANEJO DE RIESGOS DE HABILIDAD:

el principal riesgo es iniciar un proyecto
OO sin la suficiente experiencia.
Los directivos se preocupan por los costos
del entrenamiento pero se paga hasta el
ultimo centavo cuando se alargan los
proyectos.
El entrenamiento es una manera de evitar
errores, cometerlos consume tiempo y
cuesta
80

 Lo adecuado son cursos de entrenamiento

breve, brindados por instructores capaces,
por partes en el momento que se necesite, y
poner en practica lo aprendido.
La mejor manera de adquirir las habilidades
en OO es a travs del mtodo de tutora,
contratarlos para reas especificas o todo el
proyecto.
Tambin podr completar sus habilidades
mediante la lecturas. Constituir grupos
tcnico de estudio
81

 BASE ARQUTECTONICA
se compone de:
la lista de casos de uso, que le dice cuales son
los requerimientos.
El modelo del dominio : compuesto de lo que
se entiende del negocio. Sirve para armar las
clases.
La plataforma tecnolgica.

Esta arquitectura es el cimiento del

desarrollo y funciona como ante proyecto.
82

 CUANDO TERMINA LA
ELABORACION:
la elaboracin consume una quinta parte de
la duracin del proyecto
Dos circunstancias son indicadores claves
que sealan que se ha completado la
elaboracin:
los desarrolladores pueden tener la confianza
necesaria para dar estimaciones.
Se han identificado todos los riesgos
significativos, se sabe como tratarlos
83