METODOLOGIAS DE DESARROLLO DE SOFTWARE

Presentación del tema: "METODOLOGIAS DE DESARROLLO DE SOFTWARE"— Transcripción de la presentación:

1 METODOLOGIAS DE DESARROLLO DE SOFTWARE
LIC. 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 los objetivos de las metodologias son:
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 la descomposición de proceso se realiza a nivel de tareas elementales.
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 Desde su aparición se han hecho mejoras:
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

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 Selección de herramientas Da una estructura visible Procedimientos de gestión Da informes a dirección Coordinan y guían Metodología de desarrollo Soportan métodos Soporte automatizado Técnicas Determinan las herramientas necesarias

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 Se puede identificar dos enfoques en metod. OO:
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 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

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 Administracion y control
SSADM Anali de Requis Especi de Requi Espec logic del sistem Plan. Estra. Estud. De viabil Diseñ fisico Constr y prueb Produ Estudio Completo desarrollo Administracion y control

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 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 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
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 Durante esta etapa se define:
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 Se plantea la necesidad de comprender mas el problema :
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
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 No se debe construir el sistema de golpe.
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 Puede también apoyarse en : Diagramas de Interacción.
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