Arquitetando o software

O tema Arquitetura de Software está em alta nas disciplinas e conjunto de matérias da Engenharia de Software. Agora que a poeira dos fracassos com sistemas, prazos, orçamentos, etc. tem baixado aos poucos,  surgem novos rumos para a área. A interação com outras áreas de design, como o Design Thinking, com a Arquitetura, Artes, Design Gráfico, Design de Produtos, tem trazido uma influência muito positiva para a nossa área. Inicialmente essas influências não são bem aceitas e há resistências naturais, pois afinal de contas estamos passando por um período crítico de desarrumação da casa, prá que ficar arrumando mais interações que acabam por adicionar mais variáveis sobre as quais não temos controle (ainda)? As coisas têm acontecido aos poucos, e os processos de desenvolvimento de software mais adotados ao redor do mundo dão enorme destaque à arquitetura. Como por exemplo a fase de Elaboração do processo RUP, que tem o objetivo explicito de gerar um modelo (incremental) de arquitetura para o sistema a ser contruido como milestone para a fase. E no OpenUP isso é muito mais explicito, pois a Arquitetura aparece como uma disciplina elevada a processo de destaque no desenvolvimento.

51WLNBqI0ZL._AA115_ Esse livro ai, The process of Software Architecting, já pode ser considerado um começo de amadurecimento da área de Engenharia de Software, mostrando novos rumos. Claro, há outros, mas cheguei neste livro depois de um longo processo de busca na web, no Google, e principalmente nas livrarias da web, e esse livro aparece sempre em destaque. Comprei há mais tempo, li uma primeira vez, e resolvi adotar na minha disciplina de Engenharia de Software do Mestrado em Computação do DPI-UFV.  Esse semestre estamos usando uma primeira vez, repassando o livro todo e vamos até onde for possivel. O livro correspondeu às minhas expectativas: organiza o conhecimento em arquitetura de software, tem uma sequência de capítulos muito didática, dá o devido bom tratamento aos frameworks especificos para definição de arquitetura como o Zachman Framework, e lança uma base para um framework genérico, com os pontos-de-vista necessários para uma boa arquitetura. Vai ser adotado nos próximos oferecimentos das minhas disciplinas do mestrado e do lato-sensu, chegando aos poucos também nas disciplinas da graduação.

Para exemplificar os pontos do livro, os autores usam um exemplo único apresentado no capítulo 6, que vai sendo desenvolvido passo a passo nos capitulos seguintes. Os capitulos são construidos dentro da ótica mais moderna da área, incluindo princípios de gerência de projetos compatíveis com o PMBOK. Nos capítulos 7, 8 e 9, a arquitetura para o exemplo é desenvolvida passo a passo, com excelentes discussões práticas sobre como conduzir o processo, dicas para fugir das armadilhas nas interações com os usuários externos, atribuição de prioridades a requisitos, tratamento adequado de requisitos, mapeamento em arquitetura lógica e física, sem esquecer da arquitetura de dados. Os apêndices trazem as indispensáveis checklists que ajudam a procurar requisitos no ambiente do problema, principalmente os não-funcionais.

Interessante é que esse livro me fez lembrar, e muito, de dois outros livros que usávamos no passado, para definir os requisitos de dados e a arquitetura de bancos de dados: Methodology and Tools for Database Design (editado pelo Stefano Ceri) e o que se seguiu a ele, Conceptual Database Design (Carlo Batini, Stefano Ceri e Shamkant B. Navathe). Ambos excelentes livros, consegui formar várias gerações de alunos do nosso curso de graduação com as ideias desses livros, que se lerem esta postagem, vão se lembrar claramente.  Os capitulos do livro: 1-Introduction; 2-Architecture, Architect, Architecting; 3-Method Fundamentals; 4-Documenting a Software Architecture; 5-Reusable Architecture Assets; 6-Introduction to the Case Study; 7-Defining the Requirements; 8-Creating the Logical Architecture; 9-Creating the Physical Architecture; 10-Beyond the Basics; Apêndices A, B, C e D.

Fica também muito claro o que é o Arquiteto de Software e qual a bagagem de conhecimento que deve ter. Não é para qualquer um, exige uma bagagem de conhecimento muito abrangente,  tanto em fundamentos quanto em experiência de mercado. As decisões envolvidas na definição de uma arquitetura de sistema de médio porte para cima têm grandes riscos associados, as decisões tecnológicas mais riscos ainda, exigem muita responsabilidade e conhecimento. Sinceramente, e sem querer ofender ninguém, a função de Arquiteto de Software está fora do alcance da esmagadora maioria dos nossos estudantes  de graduação atuais, com seu baixo nível de interesse e compromisso, mais interessados em festas e em imediatismos do que em qualidade de software.

(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com)

Anúncios

Consultor Independente, Treinamento Empresarial, Gerência de Projetos, Engenharia de Requisitos de Software, Inovação. Professor Titular Aposentado, Departamento de Informática, Universidade Federal de Viçosa, Minas Gerais, Brasil. Doutor em Informática, PUC-Rio, 1990. Pós-Doutoramento, University of Florida, 1998-1999

Marcado com:
Publicado em Carreira, Educação, Engenharia de Software
6 comentários em “Arquitetando o software
  1. Norberto Hideaki Enomoto disse:

    Zé Luis muito bom o seu post. Não conhecia esse livro. Vou comprar para ler. Essa área de Arquitetura de Software é bastante interessante. Eu recomendo o seguinte site http://www.codingthearchitecture.com. Inclusive vc pode comprar um ebook “Software Architecture for Developers
    A practical and pragmatic guide to software architecture”. Vc mencionou o Zachman Framework que é um framework para arquitetura corporativa (Enterprise Architecture). Outro framework the arquitetura corporativa utilizado pelo mercado chama-se TOGAF (The Open Group Architecture Framework). Eu tenho utilizado o TOGAF na empresa aonde trabalho. Grande abraço.

    • Olá, Norberto. Também usamos o TOGAF, mas o livro não cita, usa o Zachman e estende a ideia de framework para possibilitar ao arquiteto criar seu próprio framework. Obrigado pelo link, já está catalogado, vou olhar com calma. Em breve vou voltar com uma postagem específica sobre os frameworks. Abraço,

  2. Deley disse:

    Oi Zé, muito legal seu post. Vc até me animou a juntar umas anotações que tinha sobre arquitetura de software, quase todas do autor Peter Eeles, e publicar umas referências no meu blog. Escreva mais sobre o assunto e como a academia está trabalhando ou pode trabalhar melhor o tema.
    []’s, Deley.

  3. Léo disse:

    boa noite Zé,
    Segue a referencia para o DODAF: http://dodcio.defense.gov/dodaf20.aspx
    abraço, Léo

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: