1

METODOLOGIAS DE DESARROLLO DE

SOFTWARELIC. ESPINOZA ROBLES

ARMANDO DAVID

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

– 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

• 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

– 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

• 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

• 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

• 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

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

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

• 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

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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

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

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

24

Entorno de desarrollo de software

Organización de desarrollo de software

Equipo de desarrollo de software

Procedimientosde gestión

Metodologíade

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

• 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

• 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

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

• 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

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

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

• 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

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

• 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

• 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

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

– 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

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

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

• 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

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

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

• 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

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

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

• 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

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

• 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

• 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

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

• 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

Resultados en los Niveles de MERESI

Nivel Datos TratamientoConceptual Mod.

Conceptualdatos

Mod. Concep.De tratamiento

Organizativo Mod. Lógicodatos

Mod. Organiz.Tratamiento

Físico Mod. Físicodatos

Mod. Operativtratamiento

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

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

• 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

Plan.Estra.

Estud.De

viabil

Analide

Requis

Especlogicdel

sistem

Especide

Requi

Diseñfisico

Constry

prueb Produ

Administracion y control

Estudio Completo desarrollo

SSADM

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

• 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

EL PROCESO UNIFICADOVISION 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

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

• 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

• 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

• 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

• 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

• 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

• 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

– 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

– 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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