0.4 Stakeholders  (Page 7/9)

Responsabilidades dos stakeholders

Como já foi mencionado anteriormente, stakeholders têm responsabilidadesdurante o ciclo de vida do software. A seguir, agrupamos as responsabilidadesem quatro grandes tipos e citamos seu principais interessados:

• Uso ou aquisição do sistema, que são responsabilidadesde usuários e clientes;
• Desenvolvimento, descrição e documentação da arquitetura dosistema, que são responsabilidades do arquiteto do sistema;
• Desenvolvimento e manutenção do sistema, que sãoresponsabilidades que envolvem o maior número de stakeholders:arquitetos, projetistas, programadores, mantenedores, testadores, engenheirosde domínio, gerentes de projetos e desenvolvedores, entre outros;
• Avaliação do sistema e do seu desenvolvimento, que sãoresponsabilidades de CIOs Chief Information Officer ou CIO é o nome dadoao diretor do departamento de Tecnologia da Informaçãode uma empresa. , auditores e avaliadores independentes.

Por fim, descrevemos alguns dos stakeholders citados e qualsua influência da arquitetura e em sua documentação. Para tanto, mencionamosquais são seus interesses comuns e o que eles esperam da documentaçãoda arquitetura.

Usuários

A principal preocupação dos usuários é com as funcionalidadesprovidas pelo sistema, pouco importando como o software foi dividido emmódulos ou como esses módulos se comunicam entre si. Podemos afirmarque um usuário só pensa em um atributo de qualidade, por exemplo, em desempenhoou em segurança, quando algum desses lhe faltar.

Essa despreocupação com a organização interna do softwarepoderia nos fazer afirmar ingenuamente que a arquitetura não interessaao usuário. No entanto, ela interessa, ainda que indiretamente, uma vezque o sistema deve possuir uma arquitetura que proporcione osatributos de qualidade esperados pelos usuários para que funcionede forma satisfatória.

Já em relação à documentação, os usuários estãointeressados em saber as capacidades e o comportamento do sistema. Valenotar que essa informação pode estar em outros documentos, comoem um manual do usuário, mas esse e outros documentos devem ser escritostendo por base o documento de arquitetura, que deve conter essas informações.

Clientes

Da mesma forma que os usuários, os clientes nãocostumam se preocupar em detalhes técnicos da arquitetura. Eles estãointeressados nas característicasda arquitetura ligadas ao seu negócio: se o sistema faz o que deveriafazer, seus custos, sejam de desenvolvimento ou de execução, e o planejamentode seu desenvolvimento. Isso se faz necessário para justificaro dinheiro investido no software.