Este documento describe conceptos generales sobre metodologías de desarrollo de software. Explica que una metodología define cómo se divide un proyecto en etapas, las tareas en cada etapa, los productos esperados y las herramientas utilizadas. También cubre la evolución de las metodologías desde el desarrollo convencional hasta el enfoque estructurado y orientado a objetos, así como características deseables de una metodología como la cobertura del ciclo de desarrollo y verificaciones intermedias.

1. 1
METODOLOGIAS DE
DESARROLLO DE
SOFTWARE
LIC. ESPINOZA ROBLES
ARMANDO DAVID

2. 2
Conceptos Generales
• No existe un consenso entre los autores
sobre el concepto de metodología.
• Una primera definición:“ una metodología es
un conjunto de filosofías, fases,
procedimientos, reglas, técnicas,
herramientas, documentación y aspectos de
formación para los desarrolladores de softw.”
• según esto una metodología especifica:

3. 3
– 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 definición mas genérica;
“una metodología es un conjunto de
procedimientos, técnicas, herramientas, y un
soporte documental que ayuda a los
desarrolladores ha realizar softw.”

4. 4
• De forma general podemos identificar tres
necesidades principales que se intenta cubrir
con una metodología:
– mejores aplicaciones
– un mejor proceso de desarrollo
– un proceso estándar en la organización
• los objetivos de las metodologias son:
– registrar los requisitos de un SI
– proporcionar un método sistemático de
desarrollo
– construir un SI dentro de un tiempo apropiado y
costos aceptables

5. 5
– Construir un sistema bien documentado y fácil
de mantener
– identificar lo mas rápido posible cualquier
cambio necesario
– proporcionar un sistema que satisfaga a todas
las personas (clientes, directivos, auditores etc)
• la descomposición 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
conjunto de productos finales

6. 6
• Para aplicar un procedimientos se usa una o
mas TECNICAS: suelen ser gráficas con
apoyo de texto.
• Para la realización de una técnica nos
apoyamos en Herramientas de Softw.
• Por ejemplo: una metodología donde hay
una tarea que define un procedimiento para
construir un modelo conceptual de datos.
Para ello se usa la Técnica de Chen, con la
herramienta Power Designer, resultado
modelo conceptual de datos

7. 7
• Es necesario aclarar la confusión entre los
términos: metodología, método y ciclo de
vida.
• Una metodología 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 metodología si debe indicar como
• una metodología es un conjunto de
métodos.

8. 8
• Al inicio los métodos se centraban en una
fase del ciclo de vida: métodos de
programación estructurada. Siguiendo los
de diseño estructurado, luego análisis
estructurado.
• Luego se establecen métodos conjunto de
análisis y diseño estructurado enlazando las
dos fases.

9. 9
Visión 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
programación estructurada seguido de los
métodos de análisis y diseño. Cubre todo el
ciclo de vida completo.
• Actualmente aparece el paradigma de la
Orientación a objetos. Nuevo enfoque en la
Ing.Sft.

10. 10
Desarrollo Convencional
• En los años 50 no existía metodologías de
desarrollo. El desarrollo estaba a cargo de
programadores.
• Se vio la importancia del análisis y diseño
en el desarrollo del sistemas.
• Aparecen los analistas programadores y
analistas de sistemas.
• Los analistas se dividen en dos: analistas
funcionales y analistas técnicos

11. 11
• 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 documentación estandarizada o no
se actualizan oportunamente.

12. 12
Desarrollo estructurado
• El nacimiento de técnicas estructuradas
define el punto de partida donde se pasa de
la construcción de programas de una forma
artesanal a una que sigue unos métodos de
ingeniería.
• El termino programación estructurada se
introdujo a finales de los 60 pasando las
técnicas al entorno industrial a mediados de
los 70

13. 13
• Programación Estructurada
• el enfoque de desarrollo estructurado
comenzó con la programación.
• Diseño estructurado:
• mediados de los 60 el enfoque estructurado
se extiende a la fase de diseño, en los que se
define una abstracción mas amplia usando
los módulos de programa como
componentes básicos de construcción.

14. 14
• Diseño Estructurado:
• se refina concepto de modularidad
normalizando la estructura de un modulo de
programa, restringiendo las relaciones entre
módulos.( Yourdon y Constantine)
• Análisis Estructurado:
• antes de la aparición del análisis
estructurado, las especificaciones de
requisitos se hacen de manera narrativa.

15. 15
• Análisis estructurado:
• las especificaciones estaban afectadas por:
– eran monolíticas: había que leer todas la
especificaciones para entender el prob.
– Eran redundantes: se repetía la misma
información 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.

16. 16
• Por estos inconvenientes había un
movimiento gradual hacia las
especificaciones funcionales:
– Gráficas: compuestas por diagramas, apoyados
en técnicas textuales.
– Particionadas: leer de porciones independientes
las especificaciones.
– Mínimamente redundantes: de forma que los
cambios afectan a una parte de las
especificaciones.

17. 17
• Este enfoque se conoce como análisis
estructurado análisis descendente o top -
down.
• Desde su aparición se han hecho mejoras:
– dar menor importancia a la construcción de los
modelos físicos actuales y a los modelos
lógicos actuales
– diferenciar mas los modelos físicos y lógicos.
– Ampliar las tec. De análisis estructurado, para
modelar sistemas en tiempo real
– enfocarse en el modelo de datos.
– Estudio de eventos.a través de lista de eventos.

18. 18
• Cronología de las metodología mas
representativas en la historia de la Ing. De
Softw.
• Año Metodología
• 1968 concepto sobre prog.estructurada
• 1974 Tec. De prog. Estructurada
• 1975 primeros conceptos sobre diseño
• estructurado
• 1977 primeros conceptos sobre análisis
• estructurado

19. 19
• Año Metodología
• 1978 análisis estructurado
• 1981 SSADM versión inicial
• 1985 análisis y diseño estructurado para
• sistemas tiempo real
• 1986 SSADM siguiente versión
• 1987 análisis diseño estructurado para
• sistemas tiempo real.
• 1989 Métrica versión inicial
• 1990 SSADM siguiente versión

20. 20
• Ano Metodología
• 1993 Métrica siguiente versión
• 1995 Métrica versión actual
• Desarrollo OO
• el paradigma de OO trata los procesos y
datos de forma conjunta
• lo OO comienza con los lenguajes de
programación LOO en los que se daba
énfasis a la abstracción de datos para los
que se adjuntaba un conjunto de
operaciones.

21. 21
• A partir de mediados de los 80 OO alcanzo
gran resonancia.
• Por otra parte los conceptos de técnicas
estructuradas han servido de base para
muchas de las metodológicas OO. Así como
el diseño de bloques usado en
telecomunicaciones y otras de inteligencia
artificial e inteligencia del conocimiento.

22. 22
Características principales de las
Metodológias
• Impacto de la metodología en el entorno de
desarrollo de Softw.
• Todo entorno de desarrollo incluye un
conjunto de componentes que condicionan
la construcción de softw.
• La productividad no basta y debe estar
asociado a la calidad de los productos
finales.

23. 23
• La metodología de desarrollo es el corazón
de este entorno e influye muy directamente
en estos dos factores ( productividad y
calidad)

24. 24
Entorno de desarrollo de software
Organización de desarrollo de software
Equipo de desarrollo de software
Procedimientos
de gestión
Metodología
de
desarrollo
Soporte
automatizado
Técnicas
Da informes
a dirección
Coordinan
y guían
Determinan las herramientas necesarias
Selección de herramientas Da una estructura visible
Soportan métodos

25. 25
• Dentro del entorno la org.mantiene un
equipo de desarrollo softw.
• Los procedimientos de gestión determinan
el tipo de soporte automatizado de softw. Y
hardw.
• Los procedimientos de gestión coordinan y
guían a los desarrolladores en el empleo de
técnicas
• el soporte automatizado mejora la
productividad.

26. 26
• La organización de desarrollo tiene dos
opciones:
– selección entre un gran numero de métodos de
gestión, técnicas de desarrollo y soporte
automatizado, para crear y desarrollar la
metodología mas apropiada
– analizar y evaluar las metodologias existentes a
adoptar en la organización la que mas se ajuste
a sus necesidades. Esta es la mas común.

27. 27
Características deseables de una
metodología
• 1. Existencia de regalas predefinidas
• 2. Cobertura total del ciclo de desarrollo
• 3. Verificaciones intermedias
• 4. Planificación y control
• 5. Comunicación efectiva
• 6. Utilización sobre un abanico de proyectos
• 7. Fácil formación

28. 28
• 8. Herramienta CASE
• 9. La metodología debe contener
actividades que mejoren el proceso de
desarrollo
• 10. Soporte de mantenimiento
• 11. Soporte de la reutilizacion de softw.

29. 29
Clasificación de las Metodológias
• Debe tener en cuenta tres punto de vista o
dimensiones.
• Enfoque tipo de Siste formalidad
• estructurado gestión no formal
– orientado proc.
– Orientado datos
• jerarquico
• no jerarquico
– mixtos
• orientado a obj. Tiempo real formal

30. 30
Metodologias Estructuradas
• Propone la creación 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 visión general del problema
(nivel alto de abstracción) hasta llegar a
niveles mas sencillos de abstracción

31. 31
• Da lugar a los siguientes tipos de
metodológias:
– orientado a procesos
– orientado a datos
• orientado a estruc. Datos jerárquico
• orientado a estruc. Dato no jerárquico
– mixtos

32. 32
Metodología orientado a procesos
• La Ing. De Softw., se funda en el modelo
básico entrada / proceso/salida de un
sistema.
• Este modelo básico lo usan todas las
metodologías estructuradas, las que se
enfocan en los proceso se llaman orientadas
el proceso.

33. 33
• Se basan en métodos descendentes de
descomposición funcional para definir los
requisitos del sistema.
• Se apoya en técnicas gráficas dando lugar al
concepto de especificación estructurada que
es un modelo gráfico participando
descendente y jerárquico de los procesos del
sistema y de los datos usados por el sistema

34. 34
• La especificación estructurada esta
compuesta de:
– Diagrama de flujo de datos: representa los
procesos en distintos niveles de descomposición
los complejos se descomponen en mas sencillos
es la técnica mas importante del análisis
estructurado
– diccionario de datos: definición de todos los
datos que aparen en DFD
– especificaciones de proceso: describe con
detalle lo que sucede en un proceso

35. 35
Actividades de las principales
metodologias
• Metodología de DeMarco: los pasos son:
– 1. Estudio del entorno físico actual: modelo del
sistema actual con sus procedimientos. A través
de un conjunto de DFD
– 2. Derivación del correspondiente modelo
lógico actual: modelo derivado del anterior sin
connotación física.
– 3. Derivación del nuevo modelo lógico: tomar
en cuenta las nuevas necesidades. Formado por
un DFD, diccionario de datos y
especificaciones de proceso del sistema.

36. 36
– 4. Crear un conjunto de modelos físicos
alternativos: del modelo lógico se establecen
alternativas se enoje el mas conveniente.
– 5. Valorar cada opción: costos y beneficios de
los modelos físicos.
– 6. Seleccionar una opción: selecciona modelo
físico
– 7. Empaquetar la especificación: se recopila
toda la documentación.
•

37. 37
Metodología de Gane y Sarson
• Es el resultado de varios años de practica
en consultoría de análisis y diseño
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.

38. 38
Diferencias entre metodologias de DeMarco y Gane
Sarson
Fase del análisis Estructurado
• Método DeMarco
• Construir el
mod.físico actual DFD
físico actual
• construir mod. Lógico
actual DFD lógico
actual
• crear un conjunto de
modelos físicos
alternativos
• Método Gane y Sarson
• construir el Mod.
Lógico actual DFD
lógico actual
• construir el mod.
Lógico del nuevo
sistema: datos en 3FN
• seleccionar un Mod.
logico

39. 39
• Método DeMarco
• estimar costos y
tiempo de cada opción
• seleccionar un modelo
• empaquetar la
especificación
• Metod Gane y Sarsan
• crear nuevo mod.
Físico del sistema
• empaquetar la
especificación

40. 40
Metodología 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 análisis de transformación,
y análisis de transacción.
– 3. Evaluación del diseño midiendo la calidad de
la estructura mediante el acoplamiento y
cohesión
– preparación del diseño para la implementacion
dividiendola en Und. Físicas o cuadernos de
carga.

41. 41
Metodologias Orientados a datos
Jerárquicos
• 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:

42. 42
• La estructura de control del programa debe
ser jerárquica
• el proceso de diseño define primero la
estructura de los datos de E/S. Mezclar
todos en una estructura jerárquica de
programa y luego ordenar la lógica
procedimental para que se ajuste a la
estructura.
• El diseño lógico precede y esta separado del
físico

43. 43
Metodologias orientados a datos no
Jerarquicos
• Se divide en cuatro etapas con los siguientes
objetivos:
– Planificación: construir arquitectura de
información y una estrategia que soporte los
objetivos de la org.
– Análisis: comprender las áreas del negocio y
determinar los requisitos del sistema.
– Diseño: establecer sistema deseado por el
usuario y alcanzable por la tec.
– Construcción: construir un sistema que cumpla
lo anterior.

44. 44
Metodología Orientado a Objetos.
• En la metodología de análisis y diseño
estructurado se examina los sistemas desde
las funciones o tareas que deben realizar,
que se descomponen sucesivamente en
tareas mas pequeñas, para formar los
módulos de la aplicación.
• En OO cobra importancia el aspecto del
modelado del sistema examinando el
dominio del problema como un conjunto de
objetos que interactuan entre si.

45. 45
• En las metodologias tradicionales
(estructuradas) se produce una dicotomía
entre : función 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:

46. 46
Sistemas en Tiempo Real
• Son los sistemas independientes del tiempo
que procesan la información, 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”

47. 47
• Los sistemas en tiempo real se caracterizan
por:
– Concurrencia
– Prioridades a determinados procesos
– existe comunicación entre tareas
– accesos simultaneo a datos comunes
• no se debe confundir sistemas en tiempo
real y sistemas en línea.
– Sistemas en línea interactuan con personas
– sist. Tiempo real interactuan con personas y
depósitos físicos del exterior

48. 48
• Para especificar los requisitos de este
sistema hay que incluir nuevos conceptos
para:
– manejo de interrupciones
– comunicación y sincronización de tareas
– gestionar procesos concurrentes
– dar respuesta oportuna y a tiempo entre eventos
externos
– datos continuos o discretos

49. 49
Principales Metodologias de
Desarrollo
• Metodología MERISE:
• se planteo en 1972. Su primera versión
1976 fue iniciativa del ministerio de
industria francés.
• Se realizo con apoyo de diversas empresas,
el proyecto finalizo 1978 dando lugar al
MERISE

50. 50
• La mayor aportación de la metodología es:
– ciclo de vida mas largo: se incluye la etapa de
planificación previa al desarrollo denominada
esquema director
– introducción de 2 ciclos complementarios: ciclo
de abstracción y ciclo de decisión. El ciclo de
abstracción tiene tres niveles:
• nivel conceptual: finalidad la empresa
• nivel organizativo: organización adecuada
• nivel físico: interrogación medios técnicos

51. 51
Resultados en los Niveles de
MERESI
Nivel Datos Tratamiento
Conceptual Mod.
Conceptual
datos
Mod. Concep.
De tratamiento
Organizativo Mod. Lógico
datos
Mod. Organiz.
Tratamiento
Físico Mod. Físico
datos
Mod. Operativ
tratamiento

52. 52
• Fases de la Metodología:
– 1. Estudio preliminar: estudia situación
existente propone solución global
– 2. Estudio detallado
– 3. Implementacion: realiza los programas que
correspondan, se divide en :
• estudio técnico:
• Producción de Programas
– 4. Realización y puesta en Marcha

53. 53
Metodología SSADM
• A iniciativa del Gob. Británico a principios
de los 80 se plantea estandarizar proyectos
de tecnología de información
• Surge el SSADM: structured Systems
Analysis and desing method.

54. 54
• Los aspectos del SSADM son:
– énfasis en los usuarios: requisitos y
participación
– definición del proceso de producción: que
hacer, como , cuando
– tres punto de vista : dato, evento, proceso.
– Máxima flexibilidad en herramientas y técnicas
de implementacion.
• El SSADM no cubre aspectos como la
planificación estratégica ni la construcción
del código

55. 55
Plan.
Estra.
Estud.
De
viabil
Anali
de
Requis
Espec
logic
del
sistem
Especi
de
Requi
Diseñ
fisico
Constr
y
prueb Produ
Administracion y control
Estudio Completo desarrollo
SSADM

56. 56
Metodología Métrica
• El consejo superior de informática de
España en 1989 acuerda realizar el proyecto
Métrica
• en 1993 aparece la versión 2 de Métrica.esta
estructurada mediante una sucesión de
fases, módulos, actividades y tareas. Indica
los productos que se obtienen en cada una
de las tareas

57. 57
• Se divide en las siguientes fases:
– Fase 0 : Plan de sistemas de información
– Fase 1: Análisis de Sistemas
– Fase 2: Diseño del sistema
– Fase 3: Construcción de Sistemas
– Fase 4 Implementacion de sistemas
• se enfoca directamente en el desarrollo.

58. 58
EL PROCESO UNIFICADO
VISION GENERAL
• Es importante primero analizar el proceso
para poder ver como funciona un desarrollo
OO.
• Se mostrara una primera visión general del
Proceso para tener una idea de cómo llevar
a cabo un proyecto

59. 59
Panorámica del Proceso
• En la figura se muestra la secuencia al nivel
mas alto del proceso de desarrollo
unificado.
concepción elaboración construcción transicion

60. 60
• 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 construcción: 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: Análisis, Diseño, Implementacion,
experimentación.

61. 61
• Las dos primeras etapas son de:
– Concepción
– Elaboración
• en este proceso iterativo algunas cosas se
dejan para al final la etapa de transición
como las pruebas Beta , la afinación del
desempeño y el entrenamiento al usuario.
• Los proyectos varían: muy formales en
entregas y reuniones o de poca formalidad.
• Las iteraciones se dan en cada fase, pero
centralmente en la fase de construcción.

62. 62
• CONCEPCION:
• puede adoptar muchas forma, en algunos
proyectos una conversación en la cafetería.
Para proyectos mayores un amplio estudio
de factibilidad de meses.
• Durante esta etapa se define:
– la situación económica del proyecto. Costos
– alcance del proyecto
– magnitud del proyecto.

63. 63
• En la concepción, de define si vale la pena
dedicar algunos mese de investigación. En
este momento el patrocinador del proyecto
no se compromete mas que ha una mirada
seria del proyecto.

64. 64
• 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 tecnología empleara?

65. 65
• 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 Tecnológicos: plantea las sig.
Preguntas:
• a) va ha usar objetos:¿tiene suficiente experiencia en
OO?
• B) usara Java, Web: ¿ que también funciona esta
tecnología?

66. 66
– 3. Riesgos de Habilidades: ¿puede conseguir la
asesoría de expertos necesaria?
– 4. Riesgos Políticos: ¿ existen fuerzas Políticas
que se interpongan en su camino?

67. 67
• MANEJO DE LOS RIESGOS DE
REQUERIMIENTOS:
• los requerimientos son importantes y en esta
metodología 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 iteración entre
usuario y sistema. Con el fin de lograr un
objetivo

68. 68
• El tamaño del caso de uso puede variar
según el problema.
• La importancia radica en que un caso de uso
indica una función que el usuario puede
entender y tiene un valor para el.
• Los caso de uso son la base para la
comunicación entre los patrocinadores y los
desarrolladores, durante la planificación del
proyecto.
• En la etapa de elaboración deben
descubrirse los casos de uso principales del
SI.

69. 69
• 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 descripción será breve y
precisa, para entender la idea básica, para
usuarios y desarrolladores.

70. 70
• 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

71. 71
• Los modelos de Análisis abarcan las
implicancias de estos requerimientos para
una aplicación
• los modelos de Diseño agregan la
infraestructura interna que hace que
funcione la aplicación.
• El propósito del modelo de Dominio es
explorar el vocabulario del dominio en
términos comprensibles para los expertos.

72. 72
• Contando con un modelo de Dominio y un
modelo de casos de uso, se desarrolla un
Modelo de Diseño que reconoce tanto la
información en los objetos del dominio
como el comportamiento de los casos de
uso.
• El Modelo de Diseño agrega clases que
realizan el trabajo y proporcionan una
estructura reutilizable.
•

73. 73
• 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 diseño, de forma iterativa.
• No se debe construir el sistema de golpe.
• Para construir modelos de Diseño se debe
considerar técnicas que proporciona el
UML, como:
– los diagramas de clase: que captura el lenguaje
del negocio.

74. 74
– Los diagramas de Actividades: describen el
flujo de trabajo del negocio. Elimina secuencias
innecesarias en el proceso.
• Puede también apoyarse en : Diagramas de
Interacción.
• Apoyados en Diagramas Conceptuales de
clase y de actividad se consulta la opinión
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 diseño de clases en
la etapa de construcción.

75. 75
• 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 .

76. 76
• El equipo que construye el dominio debe ser
pequeño ( de dos a cuatro personas)
• durante el periodo de elaboración el líder
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.

77. 77
• MANEJO DE RIESGOS
TECNOLOGICOS:
• para abarcar los riesgos tecnológicos se
debe construir prototipos, que pruebe la
tecnología que uno quiere usar. Si trabaja en
VB y SQL.
– Conseguir una versión 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 .

78. 78
• Los riesgos tecnológicos mayores son los
inherentes a la manera como se integran los
componentes de un diseño.
• Concentrese en la áreas que parezca que
mas adelante será difícil de cambiar.
Preguntese:
– ¿qué sucederá si no trabaja una pieza de la
tecnología
– ¿qué ocurrirá si no podemos conectar dos
piezas del rompecabezas?
– ¿cuál es la probabilidad de que algo vaya mal?
– ¿qué haremos si eso sucede?

79. 79
• Se deberá analizar los caso de uso a medida
que aparezcan, a fin de ver si tiene algo que
pueda echar por tierra su diseño.
• Los diagramas de clase y de iteración 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 visión
panorámica de la distribución de piezas.

80. 80
• 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

81. 81
• 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 través del método de tutoría,
contratarlos para áreas especificas o todo el
proyecto.
• También podrá completar sus habilidades
mediante la lecturas. Constituir grupos
técnico de estudio

82. 82
• 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 tecnológica.
• Esta arquitectura es el cimiento del
desarrollo y funciona como ante proyecto.

83. 83
• CUANDO TERMINA LA
ELABORACION:
• la elaboración consume una quinta parte de
la duración del proyecto
• Dos circunstancias son indicadores claves
que señalan que se ha completado la
elaboración:
– los desarrolladores pueden tener la confianza
necesaria para dar estimaciones.
– Se han identificado todos los riesgos
significativos, se sabe como tratarlos