Stakeholders na Arquitetura de Software: Influência e Gestão

Stakeholders na Arquitetura de Software

O ciclo de vida do software é composto por diversas responsabilidades atribuídas a pessoas, grupos e entidades a quem chamamos de stakeholders ou interessados. Entre essas responsabilidades, podemos citar o financiamento, o projeto, o desenvolvimento, o teste, o uso e a manutenção do software.

A arquitetura, por sua vez, tem como objetivos tanto facilitar o cumprimento das responsabilidades dos stakeholders, quanto atender às suas necessidades. Entre as necessidades, citamos a urgência por desempenho, diversos aspectos de segurança e usabilidade. Por sua vez, o cumprimento desses objetivos tem impacto direto nos atributos de qualidade exibidos pelo software.

Logo, os stakeholders têm forte influência sobre a arquitetura do software e também sobre os atributos de qualidade que este exibirá ao longo de seu ciclo de vida e é por isso que dedicamos um capítulo a eles.

Quem São os Interessados em um Sistema de Software?

É comum termos como principais interessados no ciclo de vida de um software os seus usuários e desenvolvedores.

Acontece que eles não são os únicos envolvidos ou, ao menos, não são grupos homogêneos em termos de interesses e necessidades.

A desconsideração de apenas um grupo de interessados causou mudanças profundas tanto nos atributos de segurança, quanto nos de usabilidade do sistema e, como consequência, causou mudanças também na arquitetura. Se continuarmos a simplificação de nosso cenário e desconsiderarmos o cliente do software, poderemos então descartar a necessidade de um baixo custo de desenvolvimento e operação.

Escalabilidade Vertical

Essa abordagem consiste em apenas melhorar o hardware para servir a uma maior demanda.

A escalabilidade vertical costuma ser bem cara e ter um limite menor de crescimento em relação à sua alternativa (a escalabilidade horizontal).

Escalabilidade Horizontal

Nesse tipo de escalabilidade, a organização do software e como ele se comunica desempenha um papel essencial para atender à grande demanda de usuários, mesmo quando executando em hardware de menor capacidade.

É importante lembrar que dentro de um mesmo grupo de interessados podem existir interesses conflitantes entre si. Afinal, um grupo pode se organizar em subgrupos de interesses comuns, mas um subgrupo pode demonstrar interesses conflitantes com outro subgrupo. Portanto, subgrupos diferentes de usuários ou de desenvolvedores resultam em requisitos diferentes, que significam atributos de qualidade diferentes e que são frutos de arquiteturas diferentes.

Importância dos Stakeholders

A presença ou ausência de um interessado tem grande influência na arquitetura. Além disso, é comum que sua ausência dê espaço para simplificações nas decisões arquiteturais. Entretanto, no mundo real, os envolvidos não se limitam a usuários e desenvolvedores. Há diversos outros tipos de envolvidos que influenciam o desenvolvimento do software de diversas maneiras diferentes. Esses envolvidos que influenciam o ciclo de vida do software também são chamados stakeholders.

Definição de Stakeholders: Rozanski e Woods

Um stakeholder em uma arquitetura de software é uma pessoa, grupo ou entidade com um interesse ou preocupações sobre a realização da arquitetura.

Alguns stakeholders têm diferentes responsabilidades durante o ciclo de vida do software. Entre as responsabilidades, podemos citar financiamento, projeto, desenvolvimento, teste, uso, manutenção e até passagem de conhecimento sobre ele.

Outros stakeholders, por sua vez, esperam que o software funcione de alguma forma específica: eles têm necessidades em relação ao software. Por exemplo, é comum para um usuário esperar que o resultado alcançado pelo software seja confiável ou que seja alcançado em um tempo hábil.

Espaço do Problema e Solução

No Espaço do Problema, responsabilidades e necessidades equivalem a requisitos do software.

No Espaço da Solução, responsabilidades e necessidades equivalem a atributos de qualidade.

Os stakeholders têm forte influência sobre a arquitetura de um software porque ela é uma ferramenta essencial para proporcionar seus atributos de qualidade e atender aos requisitos, como, por exemplo: custo, reusabilidade, testabilidade, manutenibilidade, legibilidade, desempenho, escalabilidade, segurança, confiabilidade, entre outros.

Tipos de Stakeholders e Atributos de Qualidade

Entre os diversos tipos de stakeholders que influenciam a arquitetura, podemos citar os usuários, os desenvolvedores, os gerentes, os testadores, os clientes (que podem ou não ser usuários), os designers de outros sistemas e os mantenedores, além dos analistas e o próprio arquiteto do sistema.

Resolver conflitos de interesses entre stakeholders está entre as obrigações de um arquiteto de software. Ele deve ser consciente de que muitas vezes não será possível agradar perfeitamente a todos os interessados, uma vez que esses conflitos podem impedir o projeto de uma solução ótima. Portanto, sua obrigação será a de produzir uma arquitetura boa o suficiente e que faça todos os stakeholders ficarem satisfeitos.

Por isso, é importante que cada envolvido seja informado de como a solução de seu interesse foi restringida pelos interesses de outros envolvidos. Note que para afirmarmos que uma arquitetura alcançou algum sucesso, os stakeholders devem se mostrar satisfeitos com o sistema desenvolvido a partir dela.

O arquiteto deve ser capaz de projetar uma arquitetura que alcance dois principais objetivos: atendimento de requisitos e resolução de conflitos.

Atendimento aos Requisitos como Medida de Sucesso

O primeiro objetivo, atender aos requisitos dos stakeholders, acaba sendo óbvio, pois para satisfazer os interessados, o sistema deve fazer o que eles esperam dele. Mas apesar de óbvio, enfatizar esse objetivo serve para o arquiteto iniciante perceber que seu objetivo principal é projetar uma arquitetura com atributos de qualidade capazes de atender aos requisitos do sistema impostos e esperados pelos stakeholders e não só por ele próprio.

Muitos arquitetos não consideram o real impacto de suas decisões e se deixam levar por modas de padrões, frameworks ou abordagens que prometem resolver todos seus problemas.

Em relação ao primeiro objetivo: não importa o quanto de acordo com as boas práticas a arquitetura de um software está, se ela não atende aos requisitos que esperam que ela atenda.

Conflito entre Requisitos e Atributos de Qualidade

Situações de conflito surgem quando requisitos de stakeholders divergem ou afetam atributos de qualidade comuns. Ex.: conflitos entre atributos de segurança e usabilidade e entre segurança e desempenho.

A seguir, citamos outros atributos de qualidade e relacionamos a alguns stakeholders que têm requisitos que comumente divergem durante o ciclo de vida do software:

• Desempenho versus Custo
• Desempenho versus Escalabilidade
• Usabilidade versus Segurança

Responsabilidades dos Stakeholders

A seguir, agrupamos as responsabilidades em quatro grandes tipos e citamos seus principais interessados:

• Uso ou aquisição do sistema, que são responsabilidades de usuários e clientes;
• Desenvolvimento, descrição e documentação da arquitetura do sistema, que são responsabilidades do arquiteto do sistema;
• Desenvolvimento e manutenção do sistema, que são responsabilidades que envolvem o maior número de stakeholders: arquitetos, projetistas, programadores, mantenedores, testadores, engenheiros de domínio, gerentes de projetos e desenvolvedores, entre outros;
• Avaliação do sistema e do seu desenvolvimento, que são responsabilidades de CIOs, auditores e avaliadores independentes.

Chief Information Officer ou CIO é o nome dado ao diretor do departamento de Tecnologia da Informação de uma empresa.

Usuários

A principal preocupação dos usuários é com as funcionalidades providas pelo sistema.

Clientes

Os clientes estão interessados nas características da arquitetura ligadas ao seu negócio: se o sistema faz o que deveria fazer, seus custos, sejam de desenvolvimento ou de execução, e o planejamento de seu desenvolvimento. Isso se faz necessário para justificar o dinheiro investido no software.

Arquiteto

O principal responsável por projetar a arquitetura, o arquiteto tem a obrigação de conhecer os stakeholders envolvidos no sistema. Isso permitirá que ele saiba o que os stakeholders esperam do sistema e, por fim, seja capaz de projetar o sistema de acordo com os requisitos esperados. O arquiteto também é responsável por negociar os conflitos de interesses entre os stakeholders, o que resultará numa arquitetura com atributos de qualidade que agradem a vários, mesmo que parcialmente. A necessidade de conhecer e dialogar com os diversos stakeholders faz com que o arquiteto precise de:

• Conhecimento Técnico: Ser experiente no domínio do problema o ajudará a identificar previamente as dificuldades e soluções a serem encontradas ao longo do desenvolvimento.
• Habilidade Social: O ajudam tanto na descoberta de requisitos, quanto na negociação de divergências.

Desenvolvedor

O desenvolvedor vê a arquitetura como base para construir o sistema. Há dois extremos. Ela pode ser apresentada como uma especificação, onde não há qualquer liberdade de design durante o desenvolvimento.

Ou como um guia, que apresenta algumas restrições essenciais para que o software alcance o sucesso, mas também possui diversas liberdades para as decisões de implementação e design de baixo nível que ficam a cargo do time de desenvolvimento. A ideia geral do sistema, onde as funcionalidades serão implementadas, quem serão os responsáveis por elas e quais as decisões de design de alto nível relacionadas a elas.

Testador

O testador procura no documento de arquitetura as restrições às quais o software deve obedecer. Além disso, ele espera que o software seja testável e, para tanto, sua arquitetura deve proporcionar tal atributo de qualidade. O nível de testabilidade de um software está diretamente ligado à capacidade dele (ou de suas partes) ser posto em execução em ambiente de desenvolvimento e de seu comportamento, interno ou externo, ser verificável a partir do esperado.

Gerente de Projetos

O gerente de projeto, assim como o cliente, está interessado em custos e planejamento. No entanto, ele também se preocupa com detalhes técnicos da arquitetura e como ela ajudará no desenvolvimento do software.

A arquitetura o ajudará a resolver problemas do tipo:

• Como dividir o time de desenvolvimento a fim de paralelizar a construção dos módulos;
• Quais partes do software podem ter o código reusado, terceirizado ou comprado;
• Ou ainda como as funcionalidades serão divididas entre os múltiplos releases do software.