<< Chapter < Page Chapter >> Page >

É importante lembrar que dentro de um mesmo grupo de interessadospodem existir interesses conflitantes entre si. Afinal, um grupo pode se organizarem subgrupos de interesses comuns, mas um subgrupo pode demonstrar interessesconflitantes com outro subgrupo. Portanto, subgrupos diferentes de usuários ou dedesenvolvedores resultam em requisitos diferentes, que significam atributos dequalidade diferentes e que são frutos de arquiteturas diferentes. Podemos observarisso no estudo de caso (também citado no [link] ), quando o grupo de usuários se organiza em dois subgrupos:os que se cadastram no sistema para alugar filmes e as distribuidoras de filmes. Oresultado dessa divisão e o conflito podem também ser observados no exemplo (e na [link] ). Por um lado, as distribuidoras impõem seus requisitosde proteção aos direitos autorais. Por outro, os usuários têm a forma de interaçãocom o sistema modificada, uma vez que devem usar um reprodutor de filmes específicopara que os requisitos das distribuidoras sejam alcançados. Em resumo, mesmo fazendoparte de um mesmo grupo de envolvidos, a influência de cada subgrupo não podeser desconsiderada, uma vez que ela pode ser grande o bastante para modificar, inclusive,a forma de outros subgrupos interagirem com o sistema.

Stakeholders de um mesmo grupo, mas divergindo nos requisitos.

Importância dos interessados

Podemos observar por meio do [link] que a presença ou ausência de um interessado tem grandeinfluência na arquitetura. Além disso, é comum que sua ausência dê espaçopara simplificações nas decisões arquiteturais. Note que uma arquitetura mais simples não necessariamentesignifica um produto com desenvolvimento mais barato ou execução mais rápida. 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 dosoftware de diversas maneiras diferentes. Esses envolvidos que influenciam ociclo de vida do software também são chamados stakeholders . Devido ao conceito de stakeholder serbastante amplo e transcender a Engenharia de Software, preocupamo-nos apenascom aqueles que impactam a arquitetura e, por isso, usamos a definição dadapor Rozanski e Woods:

stakeholder
“Um stakeholder em uma arquitetura de software é uma pessoa, grupoou entidade com um interesse ou preocupações sobre a realizaçãoda arquitetura.” N. Rozanski and E. Woods. Software Systems Architecture: WorkingWith Stakeholders Using Viewpoints and Perspectives , Addison-Wesley Professional2005.

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