<< Chapter < Page Chapter >> Page >

Testador

O testador procura no documento de arquitetura asrestrições as quais o software deve obedecer. Além disso, eleespera que o software seja testável e, para tanto, sua arquitetura deve proporcionar tal atributode qualidade.

O nível de testabilidade de um software está diretamenteligado a capacidade dele (ou de suas partes) ser posto em execuçãoem ambiente de desenvolvimento e de seu comportamento, internoou externo, ser verificável a partir do esperado.

Gerente de projeto

O gerente de projeto, assim como o cliente, está interessadoem custos e planejamento. No entanto, ele também se preocupa com detalhestécnicos da arquitetura e como ela ajudará no desenvolvimentodo software. A arquitetura o ajudará a resolver problemas do tipo: comodividir o time de desenvolvimento a fim de paralelizar a construçãodos módulos, quais partes do software podem ter o código reusado, terceirizadoou comprado, ou ainda como as funcionalidades serão divididas entre os múltiplos releases do software.

Resumo

De maneira alguma esgotamos o assunto sobre stakeholders. Por outrolado, não devemos nos aprofundar ainda mais para não perdermos nosso foco queé o design da arquitetura. Entretanto, acreditamos alcançar os objetivos destecapítulo, mesmo com uma abordagem superficial sobre o assunto. Assim, esperamos que oleitor, a partir de agora:

  • entenda e exemplifique o conceito de stakeholders da arquiteturade um software;
  • entenda a influência desses stakeholders;
  • relacione os stakeholders aos atributos de qualidade esperadospelo software; e
  • entenda que os stakeholders se relacionam entre si, podendo, inclusive, gerar demandas conflitantes.

Nos capítulos a seguir, voltamos nosso foco aos atributos de qualidadee às técnicas de como se projetar uma arquitetura que atenda a esses atributos. Ainda assim,não podemos esquecer que nossos objetivos como arquitetos são descritos explicitaou implicitamente pelos stakeholders e por sua influência sobre arquitetura dosoftware.

Referências

Definição e papel dos stakeholders

O padrão ISO/IEEE 1471-2000 [link] , além de definir stakeholders, modela seu papel em relaçãoaos vários elementos relacionados à arquitetura de software. É nesse padrãoque Rozanski e Woods se baseiam para para chegar à definição de stakeholdersno livro Software Systems Architecture: Working WithStakeholders Using Viewpoints and Perspectives [link] , onde dedicam um capítulo inteiro sobre o assunto.Outras duas importantes referências sobre o papel dos stakeholders ao longoda vida da arquitetura são dois livros publicados pelo Software EngineeringInstitute, da Carnegie Mellon University: Software Architecture in Practice de Bass et al [link] e Documenting Software Architecture: Views andBeyond de Clements et al [link] . Ambos mostram a importância de considerar os stakeholders,sendo o segundo mais completo pois também trata das escolhas que o arquitetodeve fazer ao criar as visões da arquitetura de acordo com os interessados.

Arquiteto como stakeholder

Taylor et al , no livro Software Architecture: Foundations, Theory,and Practice [link] , dedicam todo um capítulo sobre a responsabilidadedo arquiteto como stakeholder, incluindo os diversos papéis que ele pode assumirdurante o ciclo de vida do software.

Outros artigos importantes sobre o papel do arquiteto de softwareque podemos citar são o The Software Architect – and The Software ArchitectureTeam de Kruchten [link] , o Who Needs an Architect? de Fowler [link] e o The Software Architect: Essence, Intuition,and Guiding Principles de McBride [link] .

Responsabilidades dos stakeholders

Booch discute sobre a “despreocupação” dos usuários emrelação à arquitetura em The Irrelevance of Architecture [link] . Já em Goodness of Fit [link] , ele escreve sobre o que seria uma arquitetura desucesso.

Por fim, Hohmann, no livro Beyond Software Architecture [link] trata das diversas preocupações ligadas aos atributosde qualidade do software. Preocupações que não são apenas do arquiteto, mastambém são dos diversos envolvidos no desenvolvimento do software.

Exercícios

Qual a importância da identificação dos stakeholdersna arquitetura de um sistema de software?

A identificação de muitos stakeholders em uma arquiteturaaumenta a chance de sucesso. No entanto, os interesses dos stakeholdersmuitas vezes não são claros e podem ser conflitantes e/ou contraditórios.Cite mais exemplos desses conflitos/contradições.

É impossível capturar as características funcionais eas propriedades de qualidade de um sistema complexo com um simplesmodelo. De que forma poder-se-ia representar arquiteturalmente sistemascomplexos de forma que seja gerenciável e compreensível por uma faixa destakeholders técnicos e de negócio?

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Arquitetura de software. OpenStax CNX. Jan 05, 2010 Download for free at http://cnx.org/content/col10722/1.9
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Arquitetura de software' conversation and receive update notifications?

Ask