ACE y TSP Comenzamos ofreciendo una visin general de las prcticas de la ECA y el TSP desarrollo iterativo modelo como

contexto para entender el enfoque combinado. 2.1 La Arquitectura-Centric Prcticas de Ingeniera: un breve resumen ACE es la disciplina de la utilizacin eficaz de la arquitectura (s) para guiar el desarrollo del sistema. Figura 1: Arquitectura centrada en Ingeniera La figura 1 muestra la arquitectura de juegos de rol en asegurar que un sistema satisface sus negocios y misin objetivos durante la ejecucin y evolucin. ACE mtodos de anlisis y diseo de guiar la creacin de una arquitectura que trata satisfactoriamente las cualidades deseadas del sistema. Los mtodos de inters para este informe son: El Taller atributo de calidad (Qaw) [Barbacci 2003], para guiar obtencin de la calidad requisitos de atributos de negocio y objetivos de la misin a la arquitectura. Calidad atributo requisitos se suscit a partir de los actores del sistema y se capturan como atributo de calidad escenarios. Estos escenarios se utiliza como fuerza motriz para las actividades de configuracin. El diseo atributo Driven (ADD) mtodo [Wojcik 2006], para guiar el diseo de negocios y los objetivos de la misin a la arquitectura. El mtodo Add proporciona un enfoque prctico para el desarrollo de una arquitectura para satisfacer sus requisitos de atributos de calidad. En el diseo de la arquitectura, la escenarios definidos por el atributo de calidad se utilizan para descomponer iterativamente el sistema en una arquitectura que cumpla con los objetivos de negocio. La Vista and Beyond (V & B) Aproximacin a la documentacin de la arquitectura [Clements 2003], a guiar al equipo de arquitectura en la documentacin de arquitectura productora que sea til para su las partes interesadas, fcil de navegar, y prctico para crear. IMPLEMENTAR Y EVOLUCIONAR SATISFACER DISEO DE IMPLEMENTAR SATISFACER CONFORM ARQUITECTURA DEL SISTEMA NEGOCIOS E OBJETIVOS DE LA MISIN 4 | CMU/SEI-2010-TR-031 La compensacin Arquitectura Mtodo de Anlisis (ATAM ) [Clements 2002], para asegurar la arquitectura

satisface los objetivos empresariales y de misin. La ATAM valora la arquitectura diseada con la participacin de los actores del sistema para descubrir posibles problemas en la arquitectura temprano, antes de que creen problemas costosos. Revisiones activas para diseos intermedios (ARID) [Clements 2002], para ayudar a la mano de la arquitectura para el equipo de aplicacin del sistema. La revisin se centra en si el diseo es suficiente para que los desarrolladores que lo utilizarn. 2.2 El Proceso de Software Equipo: Una breve descripcin TSP es un proceso de desarrollo permite a los equipos de ingeniera para cumplir los compromisos previstos, producir productos de alta calidad, y entregar software que funciona a tiempo y dentro del presupuesto. TSP ofrece marco y una estructura de procesos para crear y guiar equipos autodirigidos. Figura 2: TSP desarrollo iterativo La Figura 2 muestra cmo TSP es compatible con una estrategia de desarrollo iterativo o cclico. Los productos son desarrollados durante varios ciclos. Los ciclos pueden ser organizados en fases, de acuerdo con el ciclo de vida particular, proceso de desarrollo en el que se utiliza TSP. TSP puede ser introducida en cualquier fase o ciclo. Cada ciclo comienza con un lanzamiento o relanzamiento y termina con un postmortem. Despus de cada lanzamiento, TSP sigue proporcionando orientacin en el manejo del equipo a travs de reuniones semanales, puestos de control, y un postmortem. Las guas del entrenador del equipo de TSP a travs de cada lanzamiento, relanzamiento y postmortem, y proporciona apoyo de entrenamiento semanal durante el ciclo. Tradeoff Architecture Mtodo de Anlisis y ATAM estn registrados en la Oficina de Patentes y Marcas de los EE.UU. por Carnegie Mellon University. Desarrollo fase o ciclo Desarrollo fase o ciclo Fase o Ciclo Autopsia Desarrollo fase o ciclo Lanzar Re-lanzamiento

Proyecto Autopsia Lecciones, nuevo metas, nuevos requisitos, nuevo riesgo, etc Negocios y tcnico Estimaciones objetivos, planes, proceso, el compromiso Productos de trabajo, estado, la mtrica, resultados Fase Ciclo 5 | CMU/SEI-2010-TR-031 3 cucharaditas de Prcticas de ACE En esta seccin se describe el enfoque de utilizar el TSP con las prcticas de la ECA para guiar la arquitectura equipo en la elaboracin de la arquitectura. Se describe cmo agregar actividades relacionadas con la arquitectura en un TSP proyecto de desarrollo que incluye el diseo de arquitectura, diseo detallado, implementacin y pruebas. TSP proyectos comienzan con un lanzamiento para construir el equipo. Completando este lanzamiento requiere una cierta comprensin de la cantidad de equipos que participarn. Ser un equipo hacer todo o varios voluntad equipos de hacer diferentes tareas, tales como un equipo de arquitectos y un equipo de desarrolladores. Si el nmero de equipos no est claro en el comienzo de la puesta en marcha, estar claro despus de la puesta en marcha se ha completado. La Lanzamiento TSP describe aqu es para un equipo cuya responsabilidad es, entre otras cosas, para definir o evolucionar la arquitectura del producto a desarrollar. Se describe en este apartado las actividades relacionadas con la arquitectura que son necesarios durante el lanzamiento realizado por un equipo que tiene la tarea de diseo de la arquitectura. Un equipo de TSP se maneja de acuerdo para el plan desarrollado durante el lanzamiento, as que describen cmo influye en la arquitectura los miembros del equipo a medida que realizan su labor. Tambin describe cmo el plan es revisado y ajustado. Por ltimo, volvemos al concepto de la puesta en marcha TSP, slo que esta vez con la transicin a partir de la elaboracin de la arquitectura para la construccin de la aplicacin del

sistema. 3.1 Software contexto de desarrollo TSP se puede utilizar para gestionar todas las fases de desarrollo de software, de obtencin de requisitos a implementacin y prueba. Aqu nos centramos en la fase de la arquitectura con la puesta en marcha del equipo el desarrollo de la arquitectura, la ejecucin del plan durante esa fase, y la transferencia de la arquitectura para el equipo de desarrollo responsable de la implementacin del sistema. El lanzamiento TSP para la fase de arquitectura se puede hacer cuando las condiciones siguientes son verdaderas: El equipo responsable de la ejecucin de las actividades de arquitectura se define. Esto incluye la asignacin del lder del equipo y el arquitecto principal del sistema. Para proyectos pequeos, la lder del equipo tambin puede asumir el papel del arquitecto plomo. Los escenarios principales atributos de calidad se definen. Esto se hace generalmente mediante la ejecucin de un Qaw. Las funciones principales del sistema se definen. La versin inicial de una estrategia de diseo de la arquitectura se define. El lanzamiento est dirigido por el entrenador del equipo. El lder del equipo y el entrenador entiende TSP, as como la mtodos arquitectura. El lder del equipo y el entrenador tienen funciones complementarias en la formacin del equipo y en la orientacin de los miembros del equipo para llevar a cabo su labor. El lder del equipo es responsable de el proyecto, llevando al equipo a entregar un producto de calidad a tiempo y dentro del presupuesto. El equipo entrenador ofrece capacitacin, orientacin y retroalimentacin sobre la base de los datos de seguimiento y el proceso. La fase de requisitos todava puede estar en marcha, pero el trabajo se ha hecho suficiente para establecer la visin del futuro sistema, el contexto empresarial, las funciones clave del sistema y los requisitos de calidad de los atributos. 6 | CMU/SEI-2010-TR-031 Si los diferentes equipos son los responsables del diseo de la arquitectura y de ejecucin, entonces hay ser transferencias mltiples de los incrementos de la arquitectura para el equipo de desarrollo. Tambin habr controles de conformidad de productos de aplicacin como las actividades de arquitectura e implementacin proceder en paralelo. 3.2 Estrategia de Arquitectura Diseo El objetivo de la fase de lanzamiento TSP arquitectura es planificar las actividades de arquitectura en el contexto

de apoyar los objetivos de negocio de la organizacin y teniendo en cuenta el momento actual y las limitaciones presupuestarias. El logro de este objetivo requiere una cierta comprensin inicial de los principales componentes de la mayora de los probabilidades de ser incluidos en la arquitectura, as como un acuerdo sobre las principales tareas necesarias para exitosamente el diseo de la arquitectura. Una estrategia predeterminada que funciona en muchos casos y se puede ajustar si no se dispone de otra estrategia es para llevar a cabo el diseo de la arquitectura e implementacin de iteraciones. La duracin de una iteracin depende de la complejidad del sistema a desarrollar. Seis semanas por iteracin se puede utilizar como un punto de partida. La Tabla 1 muestra los objetivos de los primeros cinco iteraciones de la arquitectura y la implementacin actividades, que pueden ser realizados por uno o varios equipos. Tabla 1: Actividades y Metas para las iteraciones primera arquitectura Actividades de arquitectura e iteracin objetivos de ejecucin y metas 1 Crear un diseo candidato con ADD con la mayor escenarios de estructurar la arquitectura. Realizar peridicamente estilo ATAM-peer reviews. Al final de la iteracin, el problema de las reas en la arquitectura que requieren una investigacin ms detallada y / o creacin de prototipos se identifican. No es aplicable ya que las actividades de arquitectura necesita una iteracin de tiempo de espera para iniciar actividades de ejecucin. 2 Utilice Agregar para especificar las reas bien conocidas de la arquitectura en detalle suficiente que la arquitectura se puede dar al equipo desarrollador. Realizar peridicamente estilo ATAM-peer reviews. Al final de esta iteracin, las reas bien entendidos de la arquitectura se definen con suficiente detalle. Crear prototipos para dar una idea de la reas problemticas de la arquitectura. Al final de esta iteracin, se dispone de datos que ayuda a disear las reas problemticas de la arquitectura. 3 Entregue las partes bien definidas de la arquitectura de aplicacin al equipo de desarrollo utilizando ARIDstyle las evaluaciones por homlogos. Utilizar add para especificar las partes restantes de la arquitectura, teniendo en cuenta los resultados de la creacin de prototipos esfuerzo. Realizar peridicamente estilo ATAM-peer reviews. Al final de esta iteracin, todas las reas de la arquitectura se definen en detalle suficiente y pueda ser

revisar. Implementar una funcin del sistema en una parcial esqueleto del sistema [Wojcik 2006] con el bien definido componentes. Al final de esta iteracin, la funcin del sistema primero se puede demostrar que las partes interesadas. 4 Mano de toda la arquitectura de la aplicacin por el equipo de desarrollo utilizando ARID de estilo evaluaciones por pares. Llevar a cabo una evaluacin de la arquitectura con ATAM. Acotar la arquitectura para mitigar los riesgos descubiertos por la ATAM. Al final de la iteracin, versin 1,0 de la arquitectura est disponible. Aplicar una segunda funcin mediante la implementacin de el sistema de esqueleto completo y la funcionalidad requerido para proporcionar la funcin del sistema elegido. Al final de esta iteracin, un esqueleto completo sistema con la funcin de funcionamiento adicional puede se mostrar a los interesados. 7 | CMU/SEI-2010-TR-031 Si no hay barreras en las carreteras principales se encuentran, las iteraciones restantes siguen el esquema como se muestra para Iteracin 5. 3.3 Lanzamiento de la Fase de Arquitectura Durante el lanzamiento de TSP, el equipo llega a un entendimiento comn sobre el trabajo y el enfoque que y se elabora un plan detallado para guiar su labor. El lanzamiento TSP se organiza como un conjunto de nueve sesiones durante cuatro das. El proceso de lanzamiento TSP produce artefactos necesarios de planificacin (por ejemplo, los objetivos, las funciones, presupuestos, plan de trabajo, los hitos de calidad plan, y el plan de mitigacin de riesgos). El resultado ms importante es un equipo comprometido. La Tabla 2 muestra un resumen de las reuniones de lanzamiento y las actividades relacionadas con la arquitectura que son exclusivo para el lanzamiento de un equipo en esta fase del ciclo de vida. El equipo lleva a cabo tpicamente detallada planificacin para el corto plazo y la planificacin general para toda la vida til del proyecto. La puesta en marcha establece un entendimiento comn de equipo del proyecto. Durante el lanzamiento, el papel de la Reunin 3 se mejora ya que existe ms informacin sobre la estrategia de diseo de arquitectura para trabajar. Reuniones 5 y 7 se han simplificado puesto que muchos de los temas que abordan no se conocen tan temprano en la vida del proyecto. Reunin 6 se simplifica ya que la inversin realizada en la

Reunin 3 en la comprensin la arquitectura de la pena cuando llegue el momento de utilizarlo en la formulacin del nextphase detallada plan. 5 Acotar la arquitectura y / o documentacin para dar cabida a problemas descubiertos durante la conformidad revisin (ver a la derecha). Al final de esta iteracin, una arquitectura estable con documentacin suficiente disponible. Llevar a cabo una revisin del cumplimiento de la arquitectura miembros del equipo. Solucionar problemas en el cdigo descubierto por el cumplimiento revisar y aplicar la siguiente serie de funciones del sistema. Al final de esta iteracin, las siguientes funciones se puede demostrar que el

El arquitecto principal lleva el equipo en la discusin o la produccin de la arquitectura de diseo conceptual con el detalle suficiente para apoyar la planificacin del proyecto durante el lanzamiento. Mientras que un sistema detallado la arquitectura no puede existir, es tpico que descripciones de alto nivel del sistema, el contexto, los dibujos o artefactos se han creado otros que describen algunos de los detalles tcnicos del sistema. En este caso, en lugar de empezar desde cero, el arquitecto principal presenta y se basa en la arquitectura del sistema descripciones que se destacan con respecto a estos documentos tempranos. A menudo, los diagramas de contexto existentes o de alto nivel diagramas de sistemas describir una vista de despliegue que muestra el sistema y cmo el software se distribuye en el entorno informtico o conceptual de un vista en capas que muestra los principales mdulos de software dentro del sistema y oportunidades para la reutilizacin. Cualquiera de los dos de estos pueden ser utilizados para fines de planificacin. El arquitecto principal lleva el equipo en hacer una estimacin del esfuerzo bruto para el diseo de la arquitectura. Actividades de arquitectura de diseo se dividen en dos grandes categoras que deben ser estimadas de manera diferente. La primera categora de actividades es el diseo y el anlisis de una estructura para cumplir con la calidad escenarios de atributos. La segunda categora de actividades consiste en especificar los elementos arquitectnicos (tpicamente mdulos) con el detalle suficiente para que los miembros del equipo encargados de la

aplicacin de la arquitectura. Al principio de la fase de diseo de la arquitectura, la primera categora de tareas por lo general recibir nfasis; hacia el final de esta fase, el segundo conjunto de actividades sern ms frecuentes. Estimacin de las tareas de diseo de arquitectura Arquitectura tareas de diseo pueden estimarse utilizando escenarios de calidad de atributos y la arquitectura componentes mostrados en el diseo conceptual. Los escenarios de atributos de calidad se clasifican por la forma en difcil ser para disear una solucin que satisfaga a los escenarios en trminos de alta, media o baja (H / M / L). Los componentes de la arquitectura se clasifican por tamao (H / M / L). Para cada escenario, el equipo va a determinar qu componentes de la arquitectura ms probable es que haya que ajustar cuando diseo para el escenario (ver Tabla 5 para un ejemplo). Tabla 5: Escenario / Mapeo de Componentes Componente A (H) Componente B (L) Componente C (M) Componente D (L) Escenario 1 (M) X X Escenario 2 (L) X X X Escenario 3 (H) X X Estimacin de tareas mdulo de especificacin Tareas se centran en el diseo arquitectnico para los escenarios de atributos especficos de calidad no es probable para producir la documentacin arquitectura que es suficiente para los desarrolladores. Por ejemplo, ni definicin concreta de las responsabilidades de cada mdulo ni las especificaciones detalladas de las interfaces para los mdulos se requiere generalmente para asegurar que la arquitectura cumple los escenarios de atributos de calidad. Pero las responsabilidades y las interfaces son muy importantes para la coordinacin de los esfuerzos de desarrollo Los equipos de produccin de cdigo que pueden ser integrados y se ejecuta como se esperaba. Los casos de uso ayudan a descubrir las responsabilidades de mdulos e interfaces. Sin embargo, producir buena arquitectura documentacin para los desarrolladores no requiere descripcin de todos los casos de uso, es suficiente para centrarse en los ms importantes. Major utiliza casos especificar las funciones principales del sistema. Para identificar los casos de uso, por regla general, compruebe las siguientes cuatro categoras: 13 | CMU/SEI-2010-TR-031 Operational casos de uso que especifican el propsito del sistema (por ejemplo, en un sistema de comunicaciones, conectar y desconectar, en un sistema de informacin, la creacin de un informe)

 Administrativo casos de uso que especifican las funciones principales de administracin (por ejemplo, la administracin de ajustes de la aplicacin) Uso de Monitoreo casos de los que se especifique la funcin de monitoreo (por ejemplo, los usuarios actuales de lnea) Puesta en marcha / shutdown-casos de uso que la inicializacin especfica y limpiar las funciones El equipo clasifica los casos de uso de acuerdo con la complejidad (H / M / L). El establecimiento de criterios de salida para las tareas arquitectnicas Criterios de salida que definen cundo una tarea arquitectnica se realiza promover un entendimiento comn de el esfuerzo necesario para ejecutar la tarea. Para las dos categoras de edificios y estructuras tareas de arquitectura especificacin y dos de diseo y criterios de salida diferentes mdulos que se establezcan. Los criterios de salida para las tareas de diseo de arquitectura necesita definir cuando un escenario atributo de calidad se puede considerar que hacer. Esto se puede lograr por evaluaciones por pares utilizando tcnicas ATAM. Tan pronto como el equipo de arquitectura piensa que un escenario se hace, una revisin por pares utilizando al menos uno arquitecto no particip en este proyecto se lleva a cabo. Los resultados de la revisin por pares en una lista de riesgos y posiblemente los elementos de accin. Los riesgos deben ser mitigados, y los puntos de accin que se ejecutar. El diseo de un escenario se considera completa si todos los riesgos descubiertos son mitigados y no hay elementos de accin abiertas. Una reduccin del riesgo de "ignorar este riesgo" es aceptable, si esta designacin es aceptable para las partes interesadas. Los criterios de salida para las tareas mdulo de especificacin necesita definir cuando la descripcin de un mdulo es lo suficientemente bueno. Esto depende de los conocimientos y habilidades de los desarrolladores encargados de aplicar los mdulos definidos. Esto se puede lograr usando la revisin por pares ARID-estilo, donde los desarrolladores tienen la tarea de esbozar la solucin para uno o dos casos de uso, utilizando la arquitectura siempre Descripcin. El resultado de la revisin por pares es una serie de sugerencias de mejora. Las tareas de especificacin del mdulo se considera completa cuando todas las sugerencias que afectan la documentacin se resuelvan. Actividades restantes en reunin 3 Estimacin de arquitectura y diseo de mdulo de especificacin de tareas, as como criterios de salida, son aspectos

de la estrategia de diseo de la arquitectura, una de las actividades de la Reunin 3. En el resto de actividades El lder del equipo lidera el equipo en el uso de la clasificacin de tareas para establecer el desarrollo estrategia, por lo que las entregas incrementales arquitectura explcita. El lder del equipo tambin lidera el equipo en la definicin de los productos de trabajo. Documentacin asociada artefactos incluyen escenarios de atributos de calidad, casos de uso, vistas de arquitectura y diagramas de apoyo, descripciones, y resultados de anlisis. Manuales, capacitacin y demostraciones son algunas de las otras entregables en que puede utilizarse la arquitectura descrita de los interesados para conducir descendentes del ciclo de vida (por ejemplo, actividades, pruebas, instalacin, supervisin y operaciones). El administrador de procesos lidera el equipo en la elaboracin del proceso de desarrollo. El plan de trabajo incluye una estrategia y directrices para el diseo de la arquitectura, la documentacin de la arquitectura y la arquitectura evaluacin. 14 | CMU/SEI-2010-TR-031 Reunin 4: Crear los planes generales y Next PhaseEl propsito de la reunin 4 es producir el plan general. El equipo construye un plan de arriba hacia abajo para el trabajo completo. Esto se hace mediante el clculo del tamao de los productos a ser producidos, la identificacin de las tareas necesarios para hacer el trabajo, y la estimacin de su esfuerzo. Las actividades incluyen lo siguiente: El arquitecto principal lleva el equipo en la estimacin del tamao de cada producto de trabajo. Dimensionamiento de las estimaciones para los productos de trabajo relacionados con la arquitectura, tener en cuenta los escenarios de atributos de calidad, la arquitectura, modelos de anlisis / prototipos, y el carcter iterativo de diseo. El lder del equipo lidera el equipo en la produccin de un plan de tareas. El plan incluye tareas de proyecto para revisiones peridicas de arquitectura de pares, de seguimiento de los riesgos de arquitectura, y una arquitectura de ltima evaluacin. El arquitecto tiene un papel principal en la realizacin de las tareas del proyecto a lo largo de la general desarrollo del plan. Las tareas se definen por la duracin del proyecto. Siguen proceso del equipo, incluyen a todos lo productos, y se detallan para la siguiente fase. Las estimaciones de tiempo para cada tarea se basa en el tamao y los datos de productividad o de la experiencia pasada. Dimensionamiento y planificacin para el proyecto en general se puede hacer

revisando las estimaciones brutas de software de dimensionamiento de los componentes de productos principales que se deducen del diseo conceptual en Reunin 3. Anteriormente, los tamaos de los artefactos se estim en trminos de tamao pequeo a muy grande, y baja hasta alta complejidad. Estas estimaciones deben ser traducidos en nmeros ms precisos y asignado a un ciclo de lanzamiento en el plan general. Estimacin de las tareas de diseo de arquitectura El uso de datos histricos se recomienda para estimar el esfuerzo para disear un atributo de calidad escenario de acuerdo con la clasificacin establecida durante la reunin 3. Si no hay datos histricos disponibles, la siguiente regla general se puede utilizar como punto de partida. Si un escenario simple (L dificultad) requiere un pequeo componente (talla L) para cambiar, entonces esto probablemente se puede hacer dentro de un da de esfuerzo. Un escenario complicado (dificultad H) que requiere un gran componente que desea cambiar (tamao H) ms probable es que requiere de un orden de magnitud mayor esfuerzo, que es de 10 das. Otras combinaciones de caer en el medio, como se ilustra en la Tabla 6. Tabla 6: Tabla Estimacin esfuerzo (das) Componentes LMH Escenarios H 5 8 10 M358 L135 El propsito de estos nmeros es proporcionar un punto de partida. Los datos histricos pueden soportar ms precisa estimacin. En cualquier caso, los nmeros reales pueden variar y dependen de muchos factores, tales como el tamao del proyecto, el nmero de equipos implicados, si el desarrollo se distribuye, y el el nivel de habilidad del personal disponible. 15 | CMU/SEI-2010-TR-031 Asignacin de nmeros de esfuerzo a los escenarios y su mapeo sobre las piezas (que se muestran en la Tabla 5) resultara en una tabla de estimacin de esfuerzo como el que se muestra en la Tabla 7. Tabla 7: Escenario de ejemplo Esfuerzo Tabla Estimacin (Das) Componente A (H) Componente B (L) Componente C (M) Componente D (L) Suma Escenario 1 (M) 8 N / A N 5/13 A Escenario 2 (L) N / A 1 3 5 1 Escenario 3 (H) 10 N / A N 8/18 A Un equipo de arquitectura suele trabajar juntos, por lo que las tareas no se pueden

ejecutar en paralelo diferentes miembros del equipo. Como resultado, los nmeros de esfuerzo han de multiplicarse por el nmero de los miembros del equipo que trabaja en esas tareas. Estimacin de tareas mdulo de especificacin Los datos histricos tambin es til para estimar el esfuerzo para la especificacin de los mdulos con los casos de uso de acuerdo a la clasificacin establecida durante la reunin 3. Si no hay datos histrica est disponible, la siguiente estimaciones de esfuerzo de los casos de uso se puede utilizar: Caja-0.5 Fcil de usar das Caja-1.5 Medium uso complejo da Caso-3 Complex utilizacin das Tpicamente dos miembros del equipo se les asigna a un caso de uso. Por lo tanto los nmeros de esfuerzo tienen que estar multiplicada por dos. En caso de que los datos histricos disponibles, estos nmeros se pueden ajustar en consecuencia. Contabilizacin de retrabajo Cuando el equipo de arquitectura disea la arquitectura de la tercera segunda, y as sucesivamente escenario, la diseo para los escenarios anteriores probablemente tendr que ser ajustado. Si se sigue la arquitectura por defecto estrategia de diseo (vase la seccin 3.2), los siguientes porcentajes del esfuerzo general para un iteracin debera asignarse a la reanudacin de la documentacin de la arquitectura existente, como regla general: 10% del esfuerzo para la iteracin 2 para ajustar los escenarios de Iteracin 1 Esfuerzo del 20% para la iteracin 3 para ajustar los escenarios de iteraciones 1 y 2 Una recomendacin es planear en un nivel bruto, y distribuir el esfuerzo durante los dos primeros ciclos y el resto del ciclo de vida del proyecto. Tenga en cuenta que el dimensionamiento de los elementos de esta manera no hace explcitamente en cuenta la infraestructura de forma separada elementos, los cuales estn distribuidos entre los otros elementos. Dimensionamiento y planificacin de los productos de trabajo de la fase de arquitectura a corto plazo del proyecto puede hacerse con mayor precisin mediante la estimacin del tiempo necesario para crear la documentacin de arquitectura artefactos. Estos artefactos pueden ser eventualmente traducirse en unas medidas de tamao (por ejemplo, las pginas de la arquitectura documentacin, el nmero de artefactos en una descripcin de la arquitectura), y el esfuerzo se puede asignar para su produccin. 16 | CMU/SEI-2010-TR-031 Documentacin artefactos incluyen vistas y modelos de apoyo. ADD sugiere el diseo

de la sistema se representa mediante vistas desde dos o tres categoras (por ejemplo, componentes y conectores, mdulos, o de implementacin). Los puntos de vista y enfoque all describe cmo cada punto de vista es documentado, con varios diagramas para representar la estructura y el comportamiento y el texto para describir la catlogo de elementos, fundamentos, trazabilidad, y similares. Para estimar los artefactos necesarios, el siguiente reglas del pulgar se puede utilizar si los datos histricos no est disponible: Un escenario atributo de la calidad aplicado Reunin 3 requiere la creacin o el perfeccionamiento de los dos diagramas estructurales, tales como un componente y vista conector y un mdulo de vista. Un escenario atributo de calidad por lo general se refina en cuatro escenarios ms especficos. Cada escenario especfico se describe con tres diagramas de secuen cia. Cada diagrama de secuencia requerir la definicin o refinamiento de los cinco elementos arquitectnicos. Cada elemento arquitectnico tiene su propio diagrama mostrando su contexto. Por lo tanto, un escenario de atributo de calidad de Reunin 3, en promedio, es descrito por dos estructural diagramas, doce diagramas de secuencia, diagramas y cinco elementos arquitectnicos. El diagrama plazo aqu se utiliza para significar una representacin visual de elementos de la arquitectura y todas las descripciones textuales necesarias. El proceso de diseo puede implicar la construccin de modelos de anlisis y / o prototipos de entender y validar los conceptos de diseo para importantes requisitos de calidad de atributos tales como el rendimiento y disponibilidad. Una vez que los modelos existen, Alternativas de la arquitectura pueden ser analizados para determinar la apropiada solucin. El esfuerzo para la construccin de modelos y / o prototipos no est incluido en la estimacin anteriormente. El proceso de diseo es iterativo e incremental. Despus de que el puado inicial de escenarios se trata, algunos ms se aadir a verificar y ampliar el diseo. Por consiguiente, el esfuerzo se necesita asignar para modificar las decisiones de diseo tomadas para abordar las situaciones iniciales y para aadir un unos escenarios mucho ms. Finalmente, el tiempo tiene que tenerse en cuenta en el plan de inspeccin cada dos semanas y una evaluacin final cuando la arquitectura es estable. Cuando se genera el plan general, las tareas de continuar por el arquitecto a lo largo de

la vida del desarrollo ciclo para mantener la arquitectura, guiar a los desarrolladores en la utilizacin de la arquitectura, garantizar la aplicacin se ajusta a la arquitectura, y as sucesivamente. Reunin 5: Desarrollar el Plan de Calidad El propsito de la reunin 5 es guiar al equipo en la elaboracin del plan de calidad. El plan de calidad muestra cmo el equipo va a lograr su objetivo de calidad del producto. En TSP, la calidad del software durante el producto desarrollo se mide contando los defectos y la normalizacin por la medida de tamao apropiado. Las actividades incluyen lo siguiente: El equipo vuelve a mirar los objetivos de atributos de calidad del equipo vinculadas establecidas en la reunin 1. El equipo revisa el plan de calidad frente a la calidad