Método de desenvolvimento centrado em arquitetura

 

O Método de desenvolvimento centrado em arquitetura (MDCA) é voltado para construção de sistemas intensivos de software e coloca a arquitetura de software "no centro" durante todas as fases do projeto. O método prevê a criação de uma arquitetura candidata assim que as metas de negócio forem definidas e o levantamento inicial de requisitos for concluído. A arquitetura é desenvolvida no início e iterativamente refinada como foco central do projeto. A arquitetura é refinada até que a equipe de desenvolvimento esteja confiante de que o sistema pode ser implementado vai atender as necessidades dos envolvidos. No MDCA, a arquitetura é o ponto focal para a definição de todos os processos subseqüentes de planejamento, atividades e artefatos.

 

O MDCA é composto de sete estágios descritos resumidamente abaixo: 

 

Estágio 1 - Descobrir os condutores arquiteturais:

Reúna-se com as partes interessadas do cliente para descobrir e documentar os condutores arquiteturais: requisitos funcionais alto nível, restrições e atributos de qualidade.

 

Estágio 2:Estabelecer o escopo do projeto

A partir da especificação de condutores arquiteturais criar um Plano de Projeto Preliminar.

Estágio 3:Descrever a arquitetura
Criar a arquitetura inicial, que inclui as visualizações mais adequadas para o sistema.

Estágio 4:Revisar a arquitetura
Revisão da arquitetura para descobrir e documentar riscos e trade-offs.

Estágio 5:Produzir decisão (Go/NoGo)
Priorizar e lista de riscos e os trade-offs descobertos durante a revisão de arquitetura e decidir se a arquitetura está pronta para o desenvolvimento ou se ela precisa ser refinada por uma POC.

NoGo - Arquitetura precisa ser refinada
Estágio 6:Planejar POCs
Equipe cria experimentos (Provas de conceito) para mitigar os riscos e ou resolver problemas que foram descobertos durante a revisão. 

Estágio 7:Executar POCs e Refinar arquitetura
A equipe realiza as POCs e documenta os resultados. 
A arquitetura é refinada com base nos resultados das POCs.

Go - Sistema ou elementos do sistema estão prontos para desenvolvimento
Estágio 6:Planejar desenvolvimento
A equipe cria um plano detalhado para a construção do sistema baseado na arquitetura refinada. 

Estágio 7:Desenvolver
A equipe executa o plano de projeto e está ativamente engajada na construção do sistema. A produção inclui a construção dos elementos da arquitetura, a integração do sistema, bem como os testes do sistema. O desenvolvimento resulta em incrementos de entrega do sistema.


Fonte: Artigo The Architecture Centric Development Method, Anthony J. Lattanze, February 2005


Exibições: 717

Comentar

Você precisa ser um membro de PanGea para adicionar comentários!

Entrar em PanGea

Comentário de Adriano Tavares em 24 fevereiro 2011 às 17:31
I hope this helps you guys and maybe sometime our paths will cross...

T.
Comentário de Adriano Tavares em 24 fevereiro 2011 às 17:19

Resposta do Tony Lattanze para a pergunta do Leonardo (Parte 3):

 

RUP is very heavy-weight in terms of the recommended documents and practices and there have been many attempts to lighten the load a bit (e g. AUP and others). ACDM is not as lightweight as XP, but it is considerably lighter weight than RUP - however, ACDM does not address the detailed designs and implementation phases. I did this intentionally to set architectural design apart. There are plenty of process frameworks, and I try to provide guidance for weaving various methods with ACDM. Methods such as XP, Scrum, TSP, and similar frameworks really work well with ACDM,... its a bit more cumbersome to use RUP because of the comprehensive nature of RUP.  There are religious preferences for language paradigms and detail design philosophies that I really wanted to avoid in ACDM - not because I am a coward, but I don't think its useful to say any one (detailed design, language, process, etc...) is the best. In terms of detailed design or any design representation, ACDM is completely neutral! However, I provide stiff guidance for representations to include the concept of perspectives, hierarchical decomposition, and so on,... but these things are good design practices void of any particular paradigm. What you select in terms of detailed design, language, or implementation process depends very much on the project, organizational, and market context. While architectural design can be influenced by any of these , we can address the way we design the architecture apart from adopting specific implementation processes, language paradigms and so forth where they are not constraints. This is at the heart and soul of ACDM.

Comentário de Adriano Tavares em 24 fevereiro 2011 às 17:19

Resposta do Tony Lattanze para a pergunta do Leonardo (Parte 2):

 

The key quality attributes promoted by the OO paradigm is reuse and maintainability. These are noble goals to be sure, but this is not always the biggest concern. Systemic quality attributes are cannot be attained by local design only - system design is a must. This means we must first understand what is important in terms of all the architectural drivers, design the architecture to achieve them, then ensure the design and implementation adheres to the architecture design. Again, these was a key driver for ACDM.

Comentário de Adriano Tavares em 24 fevereiro 2011 às 17:17
Resposta do Tony Lattanze para a pergunta do Leonardo (Parte 1):

There are significant differences between RUP and ACDM. First of all RUP is a complete development process, ACDM is an architecture design methodology and philosophy. At the heart of RUP is UML as a design notation and OO is the core design philosophy. One thing that troubles me about RUP and UML as a design notation is that neither really describes how teams develop architectural designs and then use them on the project and within the organization. This is what ACDM really tries to get at.

ACDM is paradigm and domain neutral.  Most people make the assumption that everyone in the whole world programs n-tiered IT systems using Java or C#,... this simple isn't true. There are plenty of engineers out there building extremely complex embedded systems for all kinds of things using C, C++, and even assembly. These systems also need design more than ever. According to the semi conductor industry analysts, there are more 8 bit processors sold for embedded applications than 32 bit processors for desktops and laptops. RUP has its origins in the IT domain and many practitioners indicate that RUP (and UML as a design notation) can be quite cumbersome in some embedded domains. ACDM can be used in embedded domains as well as IT.

Comentário de Adriano Tavares em 24 fevereiro 2011 às 17:16

Segue resposta do Tony Lattanze para a pergunta do Marcelo:

This is going to be something I plan to address better in the second edition of the book. Right now I have everything from small teams of 10-20 engineers to organizations of a few hundred engineers using ACDM. The domains vary from a company who builds cell phone com stacks (Interdigital, Philadelphia PA, USA), to Sony Business To Business (Tokyo Japan - build equipment for professional broadcasting industries), to Sony Television. There is an IT and telecom company in Portugal that I am working with right now as they use ACDM on there first full scale project. NASA's Goddard Space Center is using ACDM to design experimental packages for the international space station and also a group building the next generation of Space Suites. There are many other organizations adopting ACDM, which I get pretty excited about (its a bit humbling and scary). All of these project vary in terms of domain, complexity, organizational structure, market context, and so forth.

Instantiating ACDM (or any "textbook" methodology) takes planning and tailoring depending upon your domain, project, organizational, and market context. I never meant for ACDM to be recipe, but unfortunately many people read it that way. I am often hired to help guide organizations in their adaption of ACDM.

Comentário de Adriano Tavares em 24 fevereiro 2011 às 1:16

Leonardo,

na minha opinião eles são parecidos neste ponto, ambos tem como fio condutor para o papel do arquiteto a elaboração e refinamento da arquitetura e a mitigação de riscos através de provas de conceito.  

Comentário de Adriano Tavares em 24 fevereiro 2011 às 1:10

Marcelo,

sobre o tamanho de sistemas e outras metodologias onde o método se aplica, acredito que como é um método relativamente simples e flexível, ele possa ser aplicável a qualquer tamanho de projeto e adaptável a outros processos como RUP.   

 

Comentário de Adriano Tavares em 24 fevereiro 2011 às 0:42

Paulo, muito obrigado pelo contato do Tony.

Será que ele poderia apresentar o método para nós via um Webinar da rede SATURN ou de outra forma?

Seria muito bacana. :)

Comentário de Paulo Merson em 23 fevereiro 2011 às 21:22

Adriano, com este e o post anterior você criou uma excelente descrição da técnica, sucinta e objetiva. 

Tony Lattanze, um ex colega do SEI, é o autor do MDCA (originally ACDM). A técnica está descrita em seu livro "Architecting Software Intensive Systems: A Practitioners Guide".

Eu mandei um email pro Tony falando sobre este post. Ele não lê português, mas respondeu feliz com o post e concluiu dizendo  "... and I would be glad to chat with those guys if they have any questions".

Adriano e demais colegas do pangea, se quiserem fazer contato com Tony com questões, comentários ou experiências sobre ACDM, o email dele é lattanze [at] cs.cmu.edu.

 

Architecting Software Intensive Systems: A Practitioners Guide

Comentário de Leonardo Piedade em 23 fevereiro 2011 às 14:10
Adriano, um dos pilares do RUP é exatamente ser centrado em arquitetura, na sua opinião o MDCA e o RUP são parecidos nesse ponto ou são duas visões diferentes sobre o papel da arquitetura no desenvolvimento de software?

Evento TDC2016

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço