0.5 Atributos de qualidade  (Page 7/18)

Custo e benefício

Como os recursos financeiros para se desenvolver o software sãolimitados, cada decisão arquitetural deve ter seu custo e o benefício proporcionadoanalisados e, com base nessa análise, priorizados ou até mesmo descartados.Essa análise deve levar em conta o ambiente de desenvolvimento em questão:capacidades do time de desenvolvimento, ferramentas disponíveis para o reusoe os objetivos do software.

Vida útil

O design de sistemas de grande vida útil deve priorizardiferentes atributos de qualidade se os compararmos com o design de sistemasde vida mais curta, como protótipos. No primeiro tipo de sistemas, atributosde manutenibilidade e portabilidade são mais valorizados; no segundo, sãopriorizados atributos de eficiência e funcionalidade.

Agenda de lançamento

O design do software é muito dependente de como ele vaiser disponibilizado a público. Por exemplo, se o software será disponibilizadoem fases distintas que englobarão diferentes conjuntos de funcionalidades, ele deveser dividido de modo que funcione sem as partes que ainda não foram disponibilizadas,mas que também facilite tanto a modificabilidade, uma vez que é desejável que novas funcionalidadessejam adicionadas com menor esforço, quanto a interoperabilidade entre diferentesversões, que eventualmente ocorrerá. Já se o software será disponibilizadosem possibilidade de posterior atualização, como acontece em muitos sistemas embarcados,preocupações de modificabilidade e interoperabilidade entre versões podemser descartadas.

Design arquitetural para qualidade de software

A principal responsabilidade do arquiteto é a de conceber o design quepossibilite ao software ser construído de modo que satisfaça os requisitos dequalidade impostos pelos stakeholders. Para que o processo de design arquiteturaltenha sucesso, é essencial que o arquiteto conheça os objetivos do software, ou seja,conheça os requisitos funcionais e de qualidade para os quais ele está projetando. Alémdisso, ele deve conhecer tanto as técnicase práticas de design arquitetural que podem ajudá-lo na concepção da arquitetura. Eledeve também conhecer como documentar a arquitetura projetada, uma vez que é precisocomunicá-la aos outros membros do time de desenvolvimento.

Neste capítulo, nós aprendemos sobre os objetivos que devem ser alcançadospelo design da arquitetura e esperamos que o leitor agora seja capaz de:

• Identificar o que são atributos de qualidade e qual é suainfluência na arquitetura de software;
• Relacionar atributos de qualidade com algumas decisões arquiteturaisque os proporcionam; e
• Entender quais os atributos de qualidade se relacionam e como elesse relacionam.

A seguir, apresentaremos técnicas e práticas de design que o arquitetodeve conhecer para projetar sistemas com determinados atributos de qualidade. Porfim, no capítulo seguinte, apresentaremos como documentar o design arquitetural.

Referências

Requisitos funcionais e não-funcionais

Os livros Software Engineering [link] , de Sommerville, Requirements Engineering: Processes and Techniques [link] , de Sommerville e Kotonya, Software Engineering: A Practitioner's Approach [link] , de Pressman, dedicam alguns capítulos a este assunto.No entanto, o foco desses livros é no papel dos requisitos de softwareno processo de desenvolvimento. Já o artigo Defining Non-Functional Requirements [link] , de Malan e Bredemeyer, é mais voltado à influênciados requisitos na arquitetura.

Diferenças entre requisitos funcionais e não-funcionais

A discussão sobre a inexistência de diferenças práticasentre requisitos funcionais e não-funcionais pode ser encontrada tanto no livro Requirements Engineering: Processes and Techniques [link] , de Sommerville e Kotonya, quanto no artigo Distinctions Between Requirements Specificationand Design of Real-Time Systems [link] , de Kalinsky e Ready, e no livro Real-Time Systems: Design Principles forDistributed Embedded Applications [link] , de Kopetz. Essa discussão se mostra bastante presenteem sistemas de tempo-real porque os requisitos de desempenho definem afuncionalidade desses sistemas – ao contrário do que encontramos, por exemplo,em sistemas de informação, onde os requisitos de desempenho são consideradosrequisitos não-funcionais.

Atributos de qualidade

Bass et al , no livro Software Architecture in Practice [link] , mostra o papel dos atributos de qualidade naarquitetura de software. Além dele, Gorton faz uma pequena introdução aeste assunto ao tratar do estudo de caso presente em Essential Software Architecture [link] . Os livros Software Systems Architecture [link] , de Rozanski e Woods, e Code Complete [link] , de Steve McConnell, também dedicam seções aosatributos de qualidade de software, sendo o primeiro em nível de designarquitetural e o segundo em nível de design detalhado.

Atributos de negócio

Por fim, podemos encontrar informações sobre atributos de qualidadede negócio nos livros Software Architecture in Practice [link] , de Bass et al , e Beyond Software Architecture [link] , de Hohmann.