0.4 Stakeholders  (Page 12/9)

O ciclo de vida do software é composto por diversas responsabilidades atribuídasa pessoas, grupos e entidades a quem chamamos de stakeholders ou interessados. Entre essas responsabilidades, podemos citar o financiamento, o projeto, odesenvolvimento, o teste, o uso e a manutenção do software. A arquitetura, por sua vez, temcomo objetivos tanto facilitar o cumprimento das responsabilidades dos stakeholders, quantoatender às suas necessidades. Entre as necessidades, citamos a urgência por desempenho, diversosaspectos de segurança e usabilidade. Por sua vez, o cumprimento desses objetivos tem impactodireto nos atributos de qualidade exibidos pelo software. Logo, os stakeholders têm forteinfluência sobre a arquitetura do software e também sobre os atributos de qualidade queeste exibirá ao longo de seu ciclo de vida e é por isso que dedicamos um capítulo a eles.

Este capítulo tem como objetivo fazer com que o leitor seja capaz de:

• Entender o conceito de stakeholders da arquitetura de um software
• Identificar alguns stakeholders e sua influência em uma arquitetura
• Relacionar stakeholders com os atributos de qualidade impostos a umsoftware
• Entender que stakeholders também se relacionam entre si, podendo, inclusive,ser conflitantes

Quem são os interessados em um sistema de software?

É comum termos como principais interessados no ciclo de vida de um softwareos seus usuários e desenvolvedores. Acontece que eles não são os únicos envolvidos ou,ao menos, são grupos homogêneos em termos de interesses e necessidades. Entretanto,para termos um ponto de partida, vamos considerar um cenário em que existem apenasesses dois grupos e algumas simplificações. Nesse cenário, eles ambos os grupos sãohomogêneos, ou seja, todos os usuários e desenvolvedores apresentam os mesmosinteresses e necessidades, e os usuários se encarregam de impor as necessidades,enquanto os desenvolvedores cuidam para que essas necessidades sejam alcançadasatravés do produto de software. Para montarmos esse cenário, vamos partir de um sistemaparecido com o nosso estudo de caso e, pouco a pouco, retirar interesses e necessidadesdos envolvidos para observar suas influências no software e em sua arquitetura. Esseprocesso é ilustrado através do [link] .

Vamos considerar uma simplificação do SASF que chamaremosSSF (Sistema de Streaming de Filmes). Ele é mais simples porque realiza apenasuma das duas principais funcionalidades do SASF: transmitir de filmes. Porsua semelhança, consideramos que ele possui um conjunto de interessadosparecido com o do SASF. Entretanto, para compormos um cenário sem conflitos,vamos começar descartando as distribuidoras de filmes desse conjunto. Com isso,passamos a responsabilidade de disponibilizar filmes aos usuários que inicialmenteusam o software apenas para assisti-los. Contudo, as distribuidoras não sãoconsideradas interessadas apenas por disponibilizarem filmes. Elas têm tambéma preocupação com que o software respeite os direitos autorais desses filmes.Para tanto, o SASF e o SSF são obrigados a só permitir a transmissão de filmesa pessoas autorizadas e impedir a redistribuição de vídeos por parte dos usuários. Essasobrigações têm efeito na arquitetura de ambos os produtos, que tem que provernão só meios de autenticar e autorizar usuários, para distinguir usuáriosque assistem dos usuários que distribuem filmes, como também prover meios deimpedir ou dificultar a redistribuição do conteúdo transmitido.