<< Chapter < Page Chapter >> Page >
Sobre a importância e a influência dos stakeholders no projeto da Arquitetura de Software

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] .

Exemplo

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.

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