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:
2

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
4

 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.

 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 9 Ing.Sft.

Visin del desarrollo de metodologias de desarrollo de SI.

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
a direccin
Coordinan y guan

Metodologa de desarrollo

Soportan mtodos

Soporte automatizado

Tcnicas
24

Determinan las herramientas necesarias

 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 Estudio Completo

Constr Dise y fisico prueb 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 68 SI.

 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 74 la etapa de construccin.

 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