Imprimir

Ver anotações
117 minutos

 Aula 1 - Fundamentos de arquitetura de software

 Aula 2 - Decompondo a de�nição de arquitetura de

software

 Aula 3 - Visões da arquitetura

 Aula 4 - Stakeholders

 Aula 5 - Revisão da unidade

 Referências

Nesta aula, você aprenderá sobre os conceitos fundamentais de arquitetura de software, o

padrão ISO/IEEE 1471-2000 e muito mais.

22 minutos

Olá, estudante!

Boas-vindas à nossa aula sobre Fundamentos da Arquitetura de Software! Você está interessado em

aprender a projetar um software de alta qualidade que atenda às necessidades de seus usuários? Quer
aprender a usar a arquitetura de software para atingir esse objetivo? Junte-se a mim para uma aula que

explora os conceitos e princípios essenciais da arquitetura de software e como ela pode ser usada para
desenvolver o melhor software possível.

Você aprenderá sobre os conceitos fundamentais de arquitetura de software, o padrão ISO/IEEE 1471-2000

e muito mais. Ao �nal desta aula, você terá uma sólida compreensão dos fundamentos da arquitetura de
software e do padrão ISO/IEEE 1471-2000 e estará pronto para uma visão mais afundo do tema!

Bons estudos!
Às vezes, quando pensamos em arquitetura de software, é comum fazer analogia com a construção civil,
pois também realizamos essa comparação com a engenharia de software com as outras engenharias
(ZENKER et al., 2019). A arquitetura de software é a base de qualquer projeto de software bem-sucedido. Ela

abrange o design de alto nível e a organização de um sistema de software, e de�ne os relacionamentos e

Ver anotações
interações entre seus componentes.

Apesar de realizar analogias com a construção civil, para você, estudante, é importante entender que a

arquitetura de software não é uma área independente. Pressman e Maxim (2021, p. 253) esclarecem que a

arquitetura de software de um programa ou sistema computacional “abrange os componentes de software,

as propriedades externamente visíveis desses componentes e as relações entre eles”.

Para Perry e Wolf (1992), a arquitetura de software é um conjunto de elementos arquiteturais (dados,

processamento e conexão), que estão organizados de certa forma. Essa organização é de�nida por tomadas

de decisões para contentar os objetivos e restrições. Pressman e Maxim (2021, p. 182) destacam três

principais razões pelas quais a arquitetura de software é importante:

• “A arquitetura de software fornece uma representação que facilita a comunicação

entre todos os envolvidos;

• A arquitetura destaca desde o início as decisões de projeto que terão profundo

impacto no trabalho de engenharia de software que se segue;

• A arquitetura constitui um modelo relativamente pequeno como os componentes

do sistema que estão estruturados e trabalham em conjunto.”

Para Pressman e Maxim (2021, p. 182) “o modelo de projeto de arquitetura e os padrões de arquitetura são

transferíveis, ou seja, representam um conjunto de abstrações que permitem aos engenheiros de software
descrever a arquitetura de modo previsível”.

Um padrão de arquitetura resulta em uma transformação do projeto de arquitetura. Segundo Pressman e

Maxim (2021, p. 186), ele difere de um estilo em alguns modos fundamentais, como: o escopo de um padrão

é menos abrangente; um padrão impõe uma regra sobre a arquitetura, descrevendo como o software vai
tratar um aspecto de sua funcionalidade em termos de infraestrutura; os padrões de arquitetura tendem a

tratar de questões comportamentais e especí�cas no contexto de arquitetura, por exemplo, aplicações em

tempo real que tratam a sincronização ou interrupções.

Nesta aula, abordaremos o padrão ISO/IEEE 1471-2000, também conhecida como “Prática Recomendada

para Descrição Arquitetural de Sistemas Intensivos em Software”. Ele fornece uma estrutura para descrever
e avaliar a arquitetura de um sistema de software, e de�ne os seguintes termos:

• uma representação da arquitetura de um sistema a partir de uma perspectiva

particular ou ponto de vista das partes interessadas. Por exemplo, um desenvolvedor pode usar uma

visão de componente para descrever a estrutura do sistema, enquanto um stakeholder do negócio

pode usar uma visão funcional para descrever os recursos do sistema.

• uma especi�cação das convenções, regras e preocupações que

governam a construção, interpretação e uso de uma visão arquitetônica. Elas servem para capturar as
preocupações e interesses de diferentes partes interessadas no sistema.

• o conjunto de visualizações e pontos de vista arquitetônicos que descrevem

a arquitetura de um sistema. Ela deve ser uma descrição abrangente e coerente da arquitetura do
sistema.
A arquitetura de software é como a planta de um prédio. Assim como um projeto que ajuda arquitetos e
construtores a entender como um prédio será construído, a arquitetura de software permite que os
desenvolvedores de software entendam como um sistema de software será construído, o que deve ser

seguido e como deve ser feito (ZENKER et al., 2019).

Ver anotações
A arquitetura de software garante que as diferentes partes de um sistema de software funcionem juntas

adequadamente. É como um quebra-cabeça, com muitas peças diferentes que precisam se encaixar
perfeitamente (PERRY; WOLF, 1992). Por exemplo, se você estiver construindo um sistema de software para
uma loja, precisará garantir que o sistema de estoque, o sistema de checkout e o sistema de pagamento

funcionem conjuntamente sem problemas.

Uma boa arquitetura de software é importante porque garante que o sistema de software funcione bem e

seja fácil de manter. Assim como um prédio bem construído dura muito tempo, um sistema de software
bem projetado será mais con�ável e durará mais.

Compreendendo a arquitetura do software, os desenvolvedores podem garantir que o software que

construíram funcione bem e atenda às necessidades das pessoas que o utilizam. Também os ajuda a se

comunicar melhor com outras pessoas envolvidas na construção do software, como designers, analista de

negócios e/ou gerentes de produto.

O padrão ISO/IEEE 1471-2000 fornece uma estrutura para descrever e avaliar a arquitetura de software. Ele

de�ne diferentes perspectivas ou “visões” do sistema de software, dependendo dos interesses e

preocupações dos diferentes stakeholders. Por exemplo, um desenvolvedor de software pode usar uma

“visão de componente” para entender como as diferentes partes do sistema serão construídas, enquanto

uma parte interessada do negócio pode usar uma “visão funcional” para entender como o sistema atenderá
às necessidades dos usuários (ISO/IEEE, 2000).

O padrão ISO/IEEE 1471-2000 também de�ne princípios para uma boa arquitetura de software. Isso inclui
abstração, que signi�ca focar nas partes mais importantes do sistema;, separação de interesses, que

signi�ca dividir o sistema em partes menores que atendam a interesses especí�cos; modularidade, que
signi�ca organizar o sistema em módulos independentes; e hierarquia, que signi�ca organizar o sistema em
níveis de abstração.

Ao seguir o padrão ISO/IEEE 1471-2000, os desenvolvedores podem garantir que o software criado por eles
atenda aos altos padrões de qualidade e con�abilidade. Também os ajuda a se comunicar melhor com

outras pessoas envolvidas na construção do software. Compreendendo a arquitetura de software e o

padrão ISO/IEEE 1471-2000, os desenvolvedores podem criar sistemas de software escaláveis, sustentáveis e
que atendam às necessidades de seus usuários e stakeholders. Eles também podem se comunicar

efetivamente com outros stakeholders, como proprietários de empresas, designers e outros

desenvolvedores, usando uma linguagem e uma estrutura comuns.

O padrão ISO/IEEE 1471-2000 para arquitetura de software fornece uma estrutura que os desenvolvedores
de software podem usar para projetar e construir sistemas de software con�áveis e de alta qualidade (IEEE

ARCHITECTURE WORKING GROUP et al., 2000). Seguindo o padrão, desenvolvedores podem criar softwares
fáceis de manter, que atendam às necessidades de seus usuários e sejam consistentes com as melhores

práticas de desenvolvimento de software.

Para aplicar o padrão ISO/IEEE 1471-2000, desenvolvedores devem seguir um conjunto de etapas que
servirão de orientação no processo de projeto e construção de um sistema de software. São elas, (IEEE
ARCHITECTURE WORKING GROUP et al., 2000):
O padrão ISO/IEEE 1471-2000 fornece diferentes visões de arquitetura de software, que mostram diferentes
aspectos do sistema de software. Essas visões incluem:

•A , que mostra o que o software faz e como o faz.

•A , que mostra como as diferentes partes do sistema estão conectadas.

•A , que mostra como o software é instalado e usado.

Ver anotações
Para aplicar o padrão, desenvolvedores devem entender cada uma dessas visões e como elas se relacionam

entre si.

Depois que os desenvolvedores entenderem as diferentes visões da arquitetura de software, eles devem

criar um plano de como o sistema de software funcionará. Isso envolve a de�nição dos componentes do

sistema, como eles interagem entre si e como serão implementados. Os desenvolvedores podem usar as

diferentes visualizações do padrão para ajudá-los a criar esse plano.

Depois de criar um plano para o sistema de software, os desenvolvedores devem avaliá-lo para garantir que

atenda às necessidades do software. Eles devem considerar fatores como usabilidade, desempenho e

capacidade de manutenção e garantir que a arquitetura seja consistente com as melhores práticas de

desenvolvimento de software. Os desenvolvedores podem usar os princípios de uma boa arquitetura de

software, como: abstração, separação de preocupações, modularidade e hierarquia, para avaliar o plano e

garantir que seja de alta qualidade.

Para construir um sistema de software que atenda às necessidades de seus usuários, os desenvolvedores
precisam comunicar a arquitetura de forma nítida a todas as partes interessadas no projeto. Isso inclui

designers, responsáveis por negócios e outros desenvolvedores. Ao comunicar de forma clara o plano, todos
podem estar na mesma página e trabalhar juntos para construir o software.

À medida que o sistema de software é construído e testado, desenvolvedores podem precisar fazer
alterações na arquitetura. Ao seguir o padrão ISO/IEEE 1471-2000, desenvolvedores podem garantir que

quaisquer alterações feitas sejam consistentes com o plano geral do software. Eles podem avaliar as
mudanças usando os princípios da boa arquitetura de software e certi�car-se de que as mudanças não

comprometam a con�abilidade, manutenibilidade ou usabilidade do sistema de software.

Em conclusão, o padrão ISO/IEEE 1471-2000 para arquitetura de software fornece um conjunto de diretrizes
e princípios que os desenvolvedores de software podem usar para projetar e construir sistemas de software

de alta qualidade. Seguindo as etapas descritas acima, os desenvolvedores podem criar um software fácil de
manter, que atenda às necessidades de seus usuários e seja consistente com as melhores práticas de

desenvolvimento de software.

Nesta videoaula, você aprenderá sobre os princípios fundamentais da arquitetura de software e do padrão
ISO/IEEE 1471-2000 em seus projetos. Você obterá uma compreensão profunda das diferentes visões da
arquitetura de software e como criar um plano de arquitetura e�caz que atenda às necessidades de seus

usuários.
 

Arquitetura de Software: nesse link, você poderá acessar uma aula da professora Silvia Regina Vergilio,
da UFPR, sobre arquitetura de software, com de�nições de outros autores.

A importância do arquiteto de software: nesse link, você terá acesso a características do papel de um
pro�ssional de arquitetura de software.

Ver anotações
Ao longo desta aula, usaremos exemplos para ilustrar como diferentes decisões arquiteturais
podem impactar o processo de desenvolvimento e o produto. Ao �nal dela, você terá uma
compreensão da de�nição da arquitetura de software e do papel crucial que ela desempenha
na criação de software e�ciente e e�caz.

19 minutos

Olá, estudante!

Nesta aula, exploraremos os conceitos fundamentais da arquitetura de software, incluindo sua de�nição,

elementos-chave e processos essenciais de tomada de decisão. Também discutiremos o papel crítico que a
qualidade arquitetônica e os atributos de visão desempenham na formação do sucesso de um projeto de

software.

Ao longo desta aula, usaremos exemplos para ilustrar como diferentes decisões arquiteturais podem
impactar o processo de desenvolvimento e o produto. Ao �nal dela, você terá uma compreensão da

de�nição da arquitetura de software e do papel crucial que ela desempenha na criação de software e�ciente
e e�caz. Prepare-se para embarcar nessa jornada no mundo da arquitetura de software!

Bons estudos!

De acordo com Perry e Wolf (1992), os elementos arquiteturais são os blocos de construção da arquitetura
de software. Esses elementos são os componentes básicos usados para criar a arquitetura de um sistema de

software. Exemplos de elementos arquiteturais incluem módulos, componentes, conectores e modelos de

dados. Os elementos arquiteturais fornecem a base para o projeto e desenvolvimento do sistema de

software.

A relação entre os elementos arquiteturais é crucial para o sucesso de um sistema de software. Os

componentes e conectores devem trabalhar juntos para garantir que o sistema funcione conforme o
esperado. Portanto, os arquitetos de software devem considerar cuidadosamente o projeto e a utilização
dos elementos arquiteturais para garantir que o sistema funcione conforme esperado pelo usuário �nal
(PERRY; WOLF, 1992).

Compreender os diferentes elementos arquiteturais e seus relacionamentos é essencial para criar um

sistema de software bem projetado. À medida que os sistemas de software se tornam cada vez mais
complexos, é ainda mais difícil ter uma profunda compreensão dos elementos arquiteturais e suas
interdependências. Ao dominar os elementos fundamentais da arquitetura de software, os arquitetos
podem criar sistemas de software e�cientes, con�áveis e sustentáveis ao longo do tempo.

Para Pressman e Maxim (2021), “as decisões sobre a arquitetura do software identi�cam importantes

problemas do projeto e o raciocínio por trás das soluções arquiteturais escolhidas”. As decisões são

Ver anotações
realizadas por meio da organização do sistema de software, por exemplo, das escolhas de padrões

arquiteturais e suas interfaces, através de suas colaborações e da composição desses elementos em

subsistemas cada vez maiores.

As decisões arquiteturais nada mais são do que as escolhas realizadas por arquitetos de software no

planejamento da estrutura de sistemas de software. De acordo com Perry e Wolf (1992), essas decisões
envolvem:

• A seleção de quais componentes usar.

• Como serão as interações.

• Quais técnicas devem ser usadas para atingir a qualidade desejada do sistema.

As decisões tomadas no nível de arquitetura impactarão signi�cativamente todo o sistema de software,

incluindo seu desempenho, manutenibilidade e escalabilidade. Os arquitetos devem considerar uma ampla
gama de fatores, como requisitos de projeto, restrições de recursos e necessidades do usuário ao tomar

decisões arquiteturais. Com decisões arquiteturais conscientes e bem pensadas, os arquitetos de software
poderão criar sistemas mais con�áveis, e�cientes e econômicos.

Atributos de qualidade de arquitetura são os critérios que os arquitetos de software usam para avaliar a
qualidade de um sistema de software. Eles re�etem as características do sistema que são as mais

importantes para os stakeholders, como desempenho, segurança, con�abilidade e usabilidade.

Esses atributos são críticos para garantir que o sistema de software atenda às necessidades de seus

usuários, além da manutenção e durabilidade dele. De acordo com Perry e Wolf (1992), identi�car e priorizar
atributos de qualidade arquiteturais é uma etapa essencial no processo de projeto de arquitetura de

software. Se essa etapa for ignorada, pode resultar em sistemas de baixa qualidade, difíceis de manter e
evoluir.

A visão arquitetural é uma descrição de alto nível das metas e objetivos da arquitetura de um sistema de
software. Ele fornece um roteiro para a equipe de desenvolvimento e os stakeholders seguirem, a �m de

garantir que o sistema atenda aos objetivos esperados para o usuário �nal (PRESSMAN; MAXIM, 2021).

Cada elemento arquitetural tem suas próprias responsabilidades especí�cas e interações com outros
elementos, e eles determinam coletivamente o comportamento do sistema e os atributos de qualidade. De

acordo com Pressman e Maxim (2021), nesse âmbito, podemos elencar três elementos fundamentais para
qualquer projeto de software:

1. unidades essenciais do sistema; podem ser de�nidos por módulos de software com
responsabilidades especí�cas dentro do sistema, como gerenciamento de dados ou processamento de
entrada do usuário.

2. elementos que são de�nidos pelas particularidades de cada componente, como

 desempenho e con�abilidade.

3. são identi�cados como mecanismos pelos quais os componentes se comunicam entre si,
por meio de chamadas de função ou de mensagens.

Para entender melhor como esses três componentes funcionam juntos, imagine um motor de carro. O

próprio motor é um componente, sua potência e e�ciência de combustível são suas propriedades, e os

vários tubos e cabos que o conectam ao resto do carro são seus conectores. Ao entender esses elementos e

Ver anotações
como eles interagem, os arquitetos podem projetar sistemas de software con�áveis, e�cientes e fáceis de

manter.

Escolher uma linguagem de programação, selecionar um sistema de gerenciamento de banco de dados,

determinar a escalabilidade do sistema e projetar os recursos de segurança do sistema, são exemplos de

decisões arquiteturais realizadas pelo arquiteto de software. Vamos entender um pouco mais?

• selecionar uma linguagem de programação pode afetar

o desempenho e a manutenção do sistema, pois algumas linguagens são mais adequadas para tarefas

especí�cas do que outras.

• a escolha de um sistema de
gerenciamento de banco de dados pode afetar a capacidade de o sistema armazenar e recuperar

dados com e�ciência.

• decidir sobre a escalabilidade do sistema pode afetar a

capacidade de o sistema lidar com um número crescente de usuários ou dados.

• projetar os recursos de segurança do sistema pode afetar a capacidade do

sistema de se proteger contra-ataques cibernéticos.

Portanto, os arquitetos devem considerar cuidadosamente essas decisões e seu impacto no design e na
função geral do sistema. Pressman e Maxim (2021) enfatizam a importância de tomar decisões arquiteturais

de forma correta, pois os arquitetos podem garantir que o sistema de software atenda aos objetivos
desejados e possa ser facilmente adaptado às mudanças nos requisitos.

De acordo com Pressman e Maxim (2021), os atributos de qualidade arquiteturais referem-se às

características de um sistema de software que determinam sua e�cácia e e�ciência. Exemplos incluem

desempenho, segurança, con�abilidade e escalabilidade. A visão arquitetural, por outro lado, refere-se a um
entendimento compartilhado das metas e objetivos de um sistema de software, que orienta seu projeto e

implementação. Inclui elementos como a �nalidade, o escopo e os stakeholders do sistema. Para obter um

sistema de software bem-sucedido, é crucial considerar os atributos de qualidade arquitetural e a visão

desde o início do processo de design. Ao fazer isso, podemos garantir que o sistema atenda aos seus
requisitos funcionais e não funcionais, alinhando-se com os objetivos gerais do projeto.

A arquitetura de software é uma parte essencial do desenvolvimento de software. Envolve o uso de

elementos arquiteturais, decisões arquitetônicas, visão arquitetural e atributos de qualidade para
desenvolver um sistema de software que atenda aos requisitos do usuário. Elementos de arquitetura

referem-se aos componentes, propriedades e conectores que compõem um sistema de software. As

decisões de arquitetura, por outro lado, são as escolhas feitas pelos arquitetos de software para alcançar as
propriedades desejadas do sistema, como con�abilidade, segurança e capacidade de manutenção
(PRESSMAN; MAXIM, 2021).
A visão arquitetural refere-se aos objetivos de longo prazo de um sistema de software, enquanto os
atributos de qualidade referem-se aos requisitos não funcionais do sistema, como desempenho,
escalabilidade e usabilidade. Por exemplo, um sistema de software projetado para uma plataforma de
comércio eletrônico deve ter alta disponibilidade, con�abilidade e segurança para garantir a satisfação do
cliente.

Para aplicar esses conceitos de forma e�caz, os arquitetos de software precisam usar uma combinação de

Ver anotações
ferramentas, princípios e classi�cações. De acordo com Pressman e Maxim (2021) a Uni�ed Modeling

Language (UML) é uma dessas ferramentas que os arquitetos usam para projetar sistemas de software. O
modelo de visão 4+1, desenvolvido por Kruchten (1995), é outra ferramenta que ajuda os arquitetos a
projetar sistemas de múltiplas perspectivas, como visão lógica, visão de processo, visão física e visão de
desenvolvimento.

Os princípios que os arquitetos de software usam para projetar sistemas de software incluem modularidade,

encapsulamento, abstração e separação de preocupações. Esses princípios garantem que os sistemas de

software sejam fáceis de manter, entender e modi�car. A classi�cação dos estilos de arquitetura de software

inclui camadas, cliente-servidor, microsserviços e arquitetura orientada a eventos.

Vamos imaginar que uma equipe esteja construindo uma nova plataforma de comércio eletrônico. Sua

é criar uma plataforma escalável, segura e fácil de usar, e que possa lidar com um grande

volume de transações. Para atingir essa , eles tomam várias , como usar uma

arquitetura baseada em micros serviços e implantar a plataforma em uma infraestrutura baseada em

nuvem.

Para implementar essas decisões, eles identi�cam vários , como: autenticação do

usuário, processamento de pagamentos, catálogo de produtos e funcionalidade de pesquisa. Eles de�nem

as propriedades desses elementos, como desempenho, disponibilidade e segurança. Também determinam

os conectores entre esses elementos, como APIs e �las de mensagens, para garantir a comunicação e a

coordenação adequadas entre eles.

Finalmente, eles de�nem vários arquiteturais que desejam que a plataforma tenha,
como alto desempenho, disponibilidade, segurança e usabilidade. Eles desenvolvem e implementam casos

de teste e métricas de desempenho para avaliar a conformidade da plataforma com esses atributos.

Em conclusão, a arquitetura de software desempenha um papel crítico no desenvolvimento de sistemas de

software que atendam aos requisitos dos usuários. Os arquitetos devem usar uma combinação de
ferramentas, princípios e classi�cações para projetar sistemas de software e�cazes. Eles também devem
tomar decisões arquiteturais corretas e manter uma visão arquitetural nítida em mente para garantir o

sucesso do sistema a longo prazo. Por �m, os arquitetos devem equilibrar os atributos de qualidade
arquitetural para garantir que o sistema funcione de maneira ideal enquanto atende aos requisitos do

usuário (PRESSMAN; MAXIM, 2021). Seguindo essas diretrizes, os arquitetos podem desenvolver sistemas de
software con�áveis, seguros e e�cientes.

Nesta videoaula, vamos de�nir as decisões arquiteturais, a visão arquitetural, os elementos arquiteturais e
os atributos de qualidade. Também vamos explorar a importância desses conceitos na engenharia de

software e como eles podem ser aplicados para criar sistemas de software e�cazes e e�cientes. Esta aula

fornecerá insights valiosos de práticas para melhorar suas habilidades de arquitetura de software.

Arquitetura de Software: desenvolvimento orientado para arquitetura. Aprenda os conceitos e a

 importância da arquitetura de software.

Arquitetura de Software: atributos para decisões do projeto arquitetural. Conheça um conjunto de

informações que podem subsidiar decisões de projeto arquitetural de sistemas de software.

Ver anotações
A documentação da arquitetura de software tem seus benefícios. Traz clareza para a equipe,
facilitando o entendimento e a manutenção do sistema. Também permite escalabilidade,
garantindo que o software possa crescer com o negócio.

23 minutos

Olá, estudante!

Nesta aula, exploraremos o conceito de documento de arquitetura e sua importância no desenvolvimento

de software. Discutiremos os benefícios que ela traz, as di�culdades envolvidas e por que documentar a

arquitetura de software é crucial.

Então, do que se trata este documento de arquitetura? É como um projeto que descreve como um sistema
de software deve ser construído. Isso nos ajuda a organizar nossas ideias, comunicar de forma e�caz e

orientar o processo de desenvolvimento. A documentação da arquitetura de software tem seus benefícios.

Traz clareza para a equipe, facilitando o entendimento e a manutenção do sistema. Também permite

escalabilidade, garantindo que o software possa crescer com o negócio.

Agora, você deve estar se perguntando, por que deveríamos nos preocupar em documentar a arquitetura?
Vamos descobrir juntos? Então, prepare-se para explorar o fascinante mundo da arquitetura de software e

descobrir como ela molda o cenário digital!

Bons estudos!

De acordo com Pressman e Bruce (2014), o documento de arquitetura é um artefato vital, um modelo para
projetar e construir sistemas de software. Ele fornece uma visão de alto nível da estrutura, componentes e

interações do sistema. O documento de arquitetura serve como referência para desenvolvedores,

interessados e futuros mantenedores, garantindo um entendimento compartilhado do design do sistema.

Agora, vamos nos aprofundar nos benefícios de documentar a arquitetura de software. Wiegers e Beatty
(2013) enfatizam que uma arquitetura bem documentada traz clareza ao projeto. O documento de

arquitetura ajuda as partes interessadas a visualizar a estrutura e a funcionalidade do sistema, reduzindo

mal-entendidos e permitindo uma comunicação e�caz entre os membros da equipe.

Além disso, documentar a arquitetura do software aumenta a capacidade de manutenção do sistema,

conforme mencionado por Pressman e Bruce (2014). Ao documentar a arquitetura, os desenvolvedores
podem compreender facilmente o design do sistema, permitindo solução e�ciente dos problemas, correção

de bugs e aprimoramentos. Esta documentação atua como um ponto de referência, orientando futuras
modi�cações e garantindo que o sistema permaneça adaptável ao longo do tempo.

No entanto, documentar a arquitetura de software pode apresentar desa�os. Wiegers e Beatty (2013)
observam que capturar a complexidade da arquitetura com precisão é uma dessas di�culdades. O
documento de arquitetura deve fornecer uma visão abrangente do sistema, mantendo-se conciso e
compreensível. Equilibrar esses requisitos pode ser desa�ador, exigindo atenção cuidadosa aos detalhes e
habilidades de comunicação e�cazes.

Manter a exatidão da documentação é outro desa�o destacado por Pressman e Bruce (2014). Os sistemas

de software evoluem e as atualizações são feitas para atender a novos requisitos ou para melhorar a
funcionalidade existente. É crucial manter o documento de arquitetura atualizado, re�etindo essas

Ver anotações
mudanças com precisão. Deixar de fazer isso pode levar a confusão e a inconsistências entre a arquitetura
documentada e o sistema real.

Agora, você pode se perguntar, por que é importante documentar a arquitetura de software? Segundo
Pressman e Bruce (2014), a documentação promove o compartilhamento do conhecimento dentro da

equipe. O documento garante que todos os envolvidos tenham uma compreensão clara da estrutura e
funcionalidade do sistema. Esse conhecimento compartilhado aprimora a colaboração, minimiza a

dependência de indivíduos especí�cos e promove a comunicação e�caz.

Além disso, a documentação da arquitetura de software permite a rastreabilidade, conforme descrito por

Booch et al. (2005). O documento de arquitetura permite a rastreabilidade das decisões de projeto e a lógica

por trás delas. Ele fornece um registro histórico da evolução do sistema, ajudando as futuras equipes a

aprender com as experiências passadas e a tomar decisões informadas.

A documentação da arquitetura de software dá suporte à evolução do sistema, conforme enfatizado por

Pressman e Bruce (2014). À medida que o sistema cresce e muda, o documento de arquitetura atua como

um guia para incorporar novos recursos, modi�car os existentes ou atender a requisitos emergentes. Ele

garante que essas alterações se alinhem com a arquitetura geral, evitando inconsistências e preservando a
integridade do sistema.

De acordo com Clements et al. (2002), os documentos arquiteturais desempenham um papel fundamental
no desenvolvimento de software. Vejamos alguns exemplos desses documentos:

• esse diagrama mostra a organização dos componentes do sistema e suas

relações. Por exemplo, em um sistema de comércio eletrônico, o diagrama de arquitetura pode incluir

componentes como banco de dados, servidor web, aplicativo de front-end e sistemas externos de

pagamento. Esses componentes são interligados por meio de interfaces e troca de dados.

• esse tipo de documentação descreve como os diferentes componentes

se comunicam entre si. No sistema de comércio eletrônico, por exemplo, pode haver uma interface

entre o aplicativo de front-end e o servidor web, de�nindo os métodos e parâmetros necessários para a

troca de informações.

• esse modelo descreve os diferentes componentes do sistema e suas

interações. Em uma rede social, por exemplo, o modelo de componentes pode incluir componentes

como per�l do usuário, feed de notícias, sistema de mensagens e sistema de busca.

• esse tipo de documento mostra como os dados são processados e movimentados

dentro do sistema. Em um sistema de gerenciamento de estoque, por exemplo, o �uxo de dados pode

descrever como os pedidos de compra são recebidos, processados e registrados no banco de dados.

Para Kruchten (1995), os documentos arquiteturais possuem características importantes que garantem sua
e�cácia como ferramentas de comunicação e referência. São elas:

1. os documentos arquiteturais devem ser elaborados de forma clara e

compreensível para todos os envolvidos no projeto, independentemente do nível de conhecimento
 técnico. A linguagem utilizada deve ser acessível, evitando jargões e terminologia técnica complexa,
permitindo que desenvolvedores, gerentes de projeto e clientes entendam facilmente a arquitetura do
sistema.

2. os documentos arquiteturais devem ser atualizados conforme o sistema

evolui. É importante re�etir as mudanças nos requisitos, funcionalidades e componentes na

documentação. Manter a documentação atualizada garante sua relevância e precisão, evitando

Ver anotações
inconsistências entre a documentação e o sistema real.

3. os documentos arquiteturais devem manter coerência e consistência

interna. As informações apresentadas nos diferentes documentos e diagramas devem estar alinhadas e

não apresentar contradições. Isso garante a con�abilidade da documentação como referência para o
sistema em desenvolvimento.

4. os documentos arquiteturais devem adotar uma abordagem modular,

destacando as diferentes partes do sistema e suas interações. Isso permite uma compreensão clara da

estrutura do sistema, identi�cando componentes, módulos e camadas envolvidas. A abordagem

modular facilita a manutenção e a evolução do sistema, pois as partes podem ser modi�cadas

independentemente umas das outras.

5. os documentos arquiteturais devem ser integrados a outros

artefatos e documentos relacionados ao desenvolvimento do software, como requisitos, casos de uso,

diagramas de sequência e planos de testes. Essa integração proporciona uma visão completa do
sistema e garante consistência entre as diferentes partes do processo de desenvolvimento.

Essas características garantem que os documentos arquiteturais sejam valiosos recursos para comunicar e
compreender a arquitetura do sistema, permitindo que todos os envolvidos tenham uma visão clara e
consistente dele.

Imagine que você faz parte de uma equipe de desenvolvimento de software em uma empresa de tecnologia.
Vocês estão trabalhando em um projeto para criar um sistema de gerenciamento de pedidos online para

uma empresa de comércio eletrônico. O objetivo é permitir que os clientes façam pedidos de forma fácil e
e�ciente, enquanto a empresa acompanha e gerencia os pedidos de forma automatizada.

De acordo com Pressman e Bruce (2014), para garantir o sucesso do projeto, é crucial que todos os
membros da equipe tenham uma compreensão clara da estrutura e das interações do sistema. Nesse

sentido, você decide utilizar um documento de arquitetura com várias visões dentro dele para representar e
documentar as informações essenciais sobre o sistema. Vamos ver como fazer isso?

• Um dos documentos arquiteturais que você cria é o diagrama de arquitetura. Nesse diagrama, você

representa gra�camente a estrutura geral do sistema, incluindo os principais componentes e como eles
se relacionam entre si. Por exemplo, você identi�ca componentes como a interface do usuário, o banco

de dados, o servidor web e o sistema de pagamentos. Você mostra como esses componentes estão
interconectados e como as informações �uem entre eles. Isso ajuda a equipe a visualizar a arquitetura
do sistema e entender como os diferentes componentes se relacionam para fornecer a funcionalidade
desejada.

• Além disso, você cria uma documentação de interfaces. Nessa documentação, você descreve em

detalhes como os diferentes componentes se comunicam entre si. Por exemplo, você explica como a
interface do usuário interage com o servidor web, quais dados são transmitidos e quais ações são
realizadas. Você também descreve como o servidor web se comunica com o banco de dados para

armazenar e recuperar informações. Essa documentação de interfaces é fundamental para garantir a

integração e a correta comunicação entre os componentes do sistema.

• Outro documento importante que você desenvolve é o modelo de componentes. Nesse modelo, você
 descreve cada um dos principais componentes do sistema em detalhes. Por exemplo, para o
componente de interface do usuário, você descreve as diferentes telas e funcionalidades disponíveis
para os usuários. Para o componente de banco de dados, você descreve as tabelas e os
relacionamentos entre elas. Esse modelo de componentes ajuda a equipe a entender as
responsabilidades de cada componente e como eles se encaixam no contexto geral do sistema.

• Além disso, você cria um �uxo de dados para ilustrar como as informações são processadas e

Ver anotações
movimentadas dentro do sistema. Por exemplo, você descreve o �uxo desde o momento em que um

cliente faz um pedido na interface do usuário, passando pela validação e processamento no servidor

web, até o armazenamento no banco de dados. Esse �uxo de dados ajuda a equipe a entender como as
informações percorrem o sistema e como são transformadas ao longo do processo.

Ao desenvolver esses documentos arquiteturais detalhados, você garante que todos os membros da equipe

tenham uma visão compartilhada e precisa do sistema em desenvolvimento. Esses documentos servem

como uma referência fundamental durante todo o ciclo de vida do projeto, desde o planejamento até a

implementação e a manutenção. Eles facilitam a comunicação e a colaboração entre os membros da equipe,

além de fornecerem uma base sólida para tomar decisões de projeto e realizar ajustes quando necessário.

Documentos arquiteturais promovem a colaboração e�caz, facilitam a tomada de decisões e contribuem

para o sucesso do projeto como um todo.

Convidamos você para uma videoaula sobre documentos arquiteturais na prática. Aprenda a projetar

sistemas de software de forma e�ciente e a entender sua estrutura e interações. Compartilharemos um

exemplo real e explicaremos como criar e utilizar esses documentos. Descubra as melhores práticas e como

elas impulsionam o desenvolvimento de software. Não perca essa oportunidade de expandir seus
conhecimentos e se destacar na área!

Aprofunde seus conhecimentos com:

• Uma abordagem para Inspeção de Documentos Arquiteturais Baseada em Checklist.

• Princípios e Práticas em Arquitetura de Software.

s stakeholders são indivíduos ou grupos que possuem interesse ou são afetados pelo
resultado de um projeto. Eles desempenham um papel crucial na de�nição de requisitos,
tomada de decisões e sucesso geral do projeto.

21 minutos

Olá, estudante!

Nesta aula, mergulharemos no mundo dos stakeholders e exploraremos sua importância no

desenvolvimento de projetos. Os stakeholders são indivíduos ou grupos que possuem interesse ou são

afetados pelo resultado de um projeto. Eles desempenham um papel crucial na de�nição de requisitos,
tomada de decisões e sucesso geral do projeto.

Ao longo de nossa jornada, examinaremos os diferentes tipos de stakeholders, suas expectativas e como
gerenciar efetivamente suas necessidades. Vamos discutir estratégias de engajamento e comunicação, além
de abordar os desa�os e benefícios de envolver os stakeholders desde o início até o �m do projeto. Prepare-

se para aprender e descobrir como maximizar a colaboração e o suporte dos stakeholders.

Bons estudos!

Ver anotações
Quando falamos de um sistema de software, é importante entender que existem várias pessoas e grupos

que têm interesse ou são afetados por ele. Essas pessoas e grupos são chamados de interessados, ou

stakeholders. Mas quem são eles?

Os stakeholders são indivíduos, ou organizações, que têm algum tipo de interesse no sistema de software.
Isso signi�ca que eles podem se bene�ciar ou serem afetados pelo sistema de alguma forma. Os

interessados podem incluir clientes, usuários �nais, gerentes, desenvolvedores, analistas de negócios e até

mesmo fornecedores de hardware ou software.

Agora que sabemos quem são os interessados, é importante entender a importância deles. Os interessados

desempenham um papel fundamental no desenvolvimento e sucesso de um sistema de software. Eles têm

necessidades, expectativas e preocupações especí�cas em relação ao sistema.

O Guia PMBOK (2013), que é uma referência importante na área de gerenciamento de projetos, aborda os

interessados como parte do processo de gerenciamento das partes interessadas. Ele destaca a importância
de identi�car, analisar e gerenciar os interessados ao longo de todo o ciclo de vida do projeto de software.

Os interessados têm uma grande in�uência nos atributos de qualidade de um sistema de software. Por

exemplo, os usuários �nais desejam um sistema fácil de usar, com uma interface amigável. Os clientes

podem estar preocupados com a con�abilidade e segurança do sistema. Os gerentes podem estar
interessados na escalabilidade e e�ciência do sistema.

Existem diferentes tipos de interessados, cada um com suas próprias necessidades e expectativas em

relação ao sistema de software. Alguns exemplos de tipos de interessados incluem:

1. são aqueles que solicitam o desenvolvimento do sistema de software e têm interesse direto
no seu funcionamento. Eles são responsáveis por de�nir os requisitos e fornecer orientações sobre o

que esperam do sistema.

2. são as pessoas que realmente utilizarão o sistema de software. Eles têm interesse em
um sistema intuitivo, fácil de usar e que atenda às suas necessidades especí�cas.

3. são os pro�ssionais responsáveis por construir o sistema de software. Eles têm

interesse em um sistema bem documentado, com código de qualidade e que possa ser facilmente

mantido e atualizado.

4. são responsáveis por entender as necessidades dos clientes e traduzi-las em

requisitos claros para o sistema de software. Eles têm interesse em um sistema que atenda aos

requisitos de negócio e agregue valor para a organização.

5. são as empresas ou indivíduos que fornecem hardware, software ou serviços

relacionados ao sistema de software. Eles têm interesse em um sistema compatível com suas soluções

e que possa integrar-se de forma e�ciente ao ambiente existente.

A relação entre os interessados e os atributos de qualidade é fundamental para o sucesso do sistema de

software. Cada interessado tem suas próprias necessidades e expectativas em relação ao sistema, e é
importante considerar esses aspectos ao de�nir e desenvolver os atributos de qualidade do sistema.

Em resumo, os interessados são pessoas ou grupos que têm interesse ou são afetados por um sistema de
software. Eles desempenham um papel fundamental no desenvolvimento e sucesso do sistema,
in�uenciando os atributos de qualidade. Identi�car, analisar e gerenciar os interessados ao longo do projeto
é essencial para garantir o alinhamento de expectativas e a satisfação de todas as partes envolvidas.

Na gestão de projetos, compreender o papel das partes interessadas é fundamental para o sucesso de

Ver anotações
qualquer empreendimento. As partes interessadas são indivíduos ou grupos que têm interesse, in�uência
ou são afetados pelo projeto. Elas podem variar de acordo com o projeto em questão, mas geralmente

incluem clientes, membros da equipe, gerentes, acionistas, usuários �nais e até mesmo a comunidade em
que o projeto está inserido. Cada uma dessas partes interessadas possui expectativas e necessidades

especí�cas que devem ser levadas em consideração ao longo do ciclo de vida do projeto.

Uma parte importante do papel da equipe de projeto é identi�car e engajar as partes interessadas de forma
e�caz. Isso envolve a compreensão das suas necessidades e expectativas, bem como a comunicação clara e

constante para manter todas as partes alinhadas. Uma comunicação e�caz é essencial para garantir que as
informações relevantes sejam compartilhadas, o feedback seja ouvido e quaisquer problemas ou

preocupações sejam abordados prontamente. A comunicação também permite que as partes interessadas

se sintam envolvidas e tenham con�ança de que suas perspectivas estão sendo consideradas. A Figura 1,

presente no Guia PMBOK (2013), ilustra a relação entre o projeto, a equipe e as diversas partes interessadas,

destacando a importância de uma comunicação e�caz e um relacionamento sólido para o sucesso do

projeto.

Figura 1 | Relação entre as partes interessadas e o projeto

Fonte: PMBOK (2013, p. 25).

As partes interessadas desempenham um papel fundamental no sucesso do projeto, pois podem fornecer
informações valiosas, in�uenciar decisões importantes e contribuir com recursos. Por exemplo, os clientes

são partes interessadas cruciais, pois solicitam o projeto e �nanciam sua execução. Eles têm interesse direto
no sucesso do projeto e esperam que suas necessidades sejam atendidas de forma adequada. Os usuários

�nais também são partes interessadas essenciais, pois são aqueles que utilizarão o produto do projeto.
Satisfazer suas expectativas é vital para garantir a aceitação e a utilidade do produto.

O Guia PMBOK (2013) é uma referência importante para a gestão de projetos e fornece diretrizes especí�cas
para o gerenciamento das partes interessadas. O guia destaca a importância de identi�car todas as partes
interessadas relevantes, analisar suas expectativas e necessidades, bem como determinar o nível de
in�uência e poder que cada uma possui. Essa análise é fundamental para priorizar as partes interessadas e
alocar recursos de forma e�ciente.
Além disso, as partes interessadas podem ser classi�cadas de acordo com sua in�uência e poder no projeto.
Algumas têm um impacto direto e signi�cativo, enquanto outras têm uma in�uência indireta ou menos
expressiva. É essencial identi�car e envolver as partes interessadas com maior poder e in�uência, pois suas
decisões e ações podem afetar consideravelmente o andamento e o resultado do projeto.

Outro aspecto importante é a compreensão dos diferentes interesses das partes interessadas. Cada uma
delas tem seus próprios objetivos e expectativas em relação ao projeto. Por exemplo, alguns podem estar

Ver anotações
mais preocupados com o resultado, enquanto outros podem enfatizar o cumprimento dos prazos, controle
de custos ou qualidade do produto. Conhecer essas expectativas permite que a equipe do projeto

desenvolva estratégias adequadas para atender às necessidades de todas as partes interessadas envolvidas.

Na gestão de projetos, os stakeholders desempenham um papel fundamental. Eles são indivíduos ou grupos

que têm interesse, in�uência ou podem ser afetados pelo projeto. São essenciais para o sucesso do projeto,

pois sua participação e suporte são fundamentais para alcançar os objetivos estabelecidos.

Para entender melhor o conceito de stakeholders, vamos considerar um exemplo prático de um projeto de

desenvolvimento de um novo produto tecnológico, como um smartphone avançado. Nesse caso, os

stakeholders podem incluir:

a. são os consumidores �nais do produto, aqueles que vão comprar e utilizar o smartphone.

Eles têm interesse direto no produto e suas necessidades devem ser atendidas para garantir a

satisfação do cliente e o sucesso do projeto.

b. são os investidores ou proprietários da empresa que está desenvolvendo o smartphone.

Eles têm interesse no retorno �nanceiro do projeto e esperam que o produto seja bem-sucedido no

mercado, gerando lucro para a empresa.

c. são os pro�ssionais envolvidos no desenvolvimento do smartphone, como

engenheiros, designers, especialistas em marketing, entre outros. Eles têm interesse em entregar um

produto de qualidade dentro do prazo e orçamento estabelecidos.

d. são as empresas ou indivíduos que fornecem os componentes, materiais e serviços

necessários para o desenvolvimento do smartphone. Eles têm interesse em fornecer produtos de alta

qualidade e cumprir os prazos acordados.

e. são as entidades governamentais e órgãos reguladores responsáveis por

estabelecer normas e regulamentos para a indústria de tecnologia. Eles têm interesse em garantir que

o produto atenda aos requisitos de segurança, qualidade e conformidade.

f. é a comunidade local onde a empresa está sediada ou onde o produto será lançado. A
comunidade pode ter interesse em questões como impacto ambiental, empregos gerados pelo projeto,

responsabilidade social da empresa, entre outros.

A interação e o envolvimento desses stakeholders ao longo do projeto são cruciais para o seu sucesso. A

comunicação e�caz é essencial para entender suas expectativas, necessidades e preocupações. Além disso,
é importante estabelecer canais de comunicação abertos e transparentes para garantir que todas as partes
interessadas sejam ouvidas e suas contribuições sejam consideradas.

No exemplo do projeto do smartphone, os stakeholders podem ser envolvidos em várias fases, desde a
concepção e design do produto até sua produção, lançamento e suporte pós-venda. Por exemplo, os

clientes podem ser convidados a participar de pesquisas de mercado e testes de usabilidade para garantir
que o produto atenda às suas necessidades e expectativas. Os acionistas podem acompanhar o progresso
do projeto por meio de relatórios e reuniões periódicas. A equipe do projeto pode se comunicar

regularmente com os fornecedores para garantir que os materiais e componentes sejam entregues no
prazo.

Em resumo, os stakeholders desempenham um papel fundamental na gestão de projetos. Eles têm

interesses, in�uência e expectativas que podem impactar diretamente o sucesso do projeto. É essencial
identi�car, engajar e gerenciar os stakeholders de forma e�caz, estabelecendo uma comunicação clara e
estreitando relacionamentos sólidos. Um envolvimento adequado dos stakeholders aumenta as chances de
alcançar os objetivos do projeto e garantir a satisfação de todas as partes envolvidas.

Ver anotações
Nesta videoaula, vamos explorar exemplos reais de projetos e discutir como identi�car, analisar e gerenciar

os stakeholders de forma e�caz. Aprenda como selecionar, engajar e satisfazer as diferentes partes
interessadas, garantindo o sucesso do projeto. Não perca essa oportunidade de aprimorar suas habilidades

em gestão de stakeholders!

Aprofunde seus conhecimentos com:

• Gestão de stakeholders: o que é, por que é importante fazer e 4 dicas para implementar na sua
empresa.

• Stakeholders, o que são, exemplos, importância e tipos.

29 minutos

Olá, estudante! A habilidade de compreender e de�nir a arquitetura de software é de extrema importância

para os pro�ssionais da área de desenvolvimento. Uma das abordagens que nos auxiliam nessa tarefa é o

padrão ISO/IEEE 1471-2000. Vamos explorar os conceitos fundamentais desse padrão e como eles nos
ajudam a criar sistemas de alta qualidade.

A arquitetura de software é a estrutura organizacional fundamental de um sistema, englobando seus

componentes, interações e restrições. Ela nos dá uma visão abrangente do sistema, permitindo

compreender seus elementos e relacionamentos. Nesse contexto, o padrão ISO/IEEE 1471-2000 fornece
uma abordagem sistemática para a de�nição, documentação e comunicação da arquitetura de software.

Um dos principais aspectos abordados pelo padrão é a identi�cação dos stakeholders. Stakeholders são as
partes interessadas no sistema, como usuários, clientes, desenvolvedores, gerentes, entre outros.
Compreender suas necessidades e expectativas é essencial para de�nir uma arquitetura que atenda aos

requisitos e objetivos estabelecidos. O padrão nos orienta a identi�car e descrever os stakeholders de forma

clara e precisa.

Outro conceito importante do padrão é a de�nição de visões arquiteturais. As visões arquiteturais são
perspectivas especí�cas da arquitetura que permitem uma compreensão mais aprofundada do sistema.
Cada visão representa uma preocupação ou interesse particular dos stakeholders. Por exemplo, uma visão
pode focar na segurança, enquanto outra na usabilidade. O padrão ISO/IEEE 1471-2000 nos guia na criação

de diferentes visões arquiteturais para representar essas perspectivas.

Além disso, o padrão destaca a importância da documentação arquitetural. A documentação é essencial

para comunicar e compartilhar a arquitetura com a equipe de desenvolvimento e os stakeholders
envolvidos no projeto. Ela proporciona um registro claro e compreensível da estrutura, comportamento e
restrições do sistema. A documentação arquitetural pode incluir diagramas, descrições textuais,
especi�cações técnicas e outros artefatos relevantes.

Ao aplicar o padrão ISO/IEEE 1471-2000, somos capazes de de�nir a arquitetura de software de forma

precisa e abrangente. Consideramos as necessidades e expectativas dos stakeholders, desenvolvemos

visões arquiteturais que representam suas perspectivas e documentamos a arquitetura de maneira clara e

Ver anotações
acessível. Isso resulta em sistemas mais robustos, �exíveis e de alta qualidade.

Em resumo, a competência de compreender e de�nir a arquitetura de software utilizando o padrão ISO/IEEE

1471-2000 é essencial para os pro�ssionais da área. A aplicação desse padrão nos permite criar sistemas
que atendam às expectativas dos stakeholders e evoluam de forma contínua. Portanto, é fundamental

estudar e aplicar os conceitos desse padrão em nossos projetos, visando à excelência na arquitetura de
software.

Esperamos que esse resumo tenha sido útil para você compreender melhor esse tema. Continue se
aprofundando nos conceitos e pratique a aplicação do padrão ISO/IEEE 1471-2000 em seus projetos. Com o

tempo e a experiência, você se tornará um arquiteto de software habilidoso na de�nição de arquiteturas

sólidas e e�cientes.

Nossa videoaula fará um resumo sobre a de�nição da arquitetura de software usando o padrão ISO/IEEE

1471-2000. Você aprenderá os conceitos-chave, termos e técnicas necessárias para compreender e

documentar arquiteturas de software de forma precisa e abrangente. Descubra como identi�car

stakeholders, visões arquiteturais e documentos arquiteturais signi�cativos. Não perca a oportunidade de

fortalecer seus conhecimentos e aprimorar suas habilidades na área de arquitetura de software. Junte-se a
mim nessa jornada de aprendizado!

você foi contratado como arquiteto de software por uma empresa de

entretenimento para desenvolver uma nova plataforma de streaming de vídeos. O objetivo é criar uma

arquitetura sólida e e�ciente para o aplicativo, que possa lidar com muitos usuários e fornecer uma
experiência de streaming de alta qualidade. O foco é utilizar o padrão IEEE 1471-2000 para a elaboração da

arquitetura, considerando as visões arquiteturais, envolvimento dos stakeholders e documentos

arquiteturais.

um dos desa�os enfrentados é garantir a escalabilidade da plataforma para lidar

com muitos usuários simultâneos. Como arquiteto de software, você precisa de�nir uma visão arquitetural

que aborde essa questão, considerando a distribuição de carga, o dimensionamento horizontal e a utilização
de tecnologias escaláveis. Como garantir que a plataforma possa crescer de forma e�ciente e atender à

demanda de um grande público?

outro desa�o é assegurar a disponibilidade e con�abilidade do serviço de streaming.

A plataforma deve ser capaz de lidar com falhas de componentes e garantir a continuidade do serviço sem

interrupções para os usuários. Como arquiteto de software, você precisa de�nir uma visão arquitetural que
aborde a resiliência do sistema, incluindo a utilização de redundância, monitoramento e recuperação de
falhas. Como garantir que a plataforma seja con�ável e ofereça uma experiência de streaming contínua?

a plataforma de streaming precisa oferecer uma ampla variedade de conteúdos,

incluindo vídeos, músicas e podcasts. Além disso, é necessário fornecer recursos como recomendações
personalizadas e a capacidade de criação de listas de reprodução. Como arquiteto de software, você precisa
de�nir uma visão arquitetural que aborde a �exibilidade e a extensibilidade do sistema, permitindo a
inclusão de novos tipos de conteúdo e recursos adicionais. Como garantir que a plataforma seja adaptável
às mudanças nas demandas dos usuários e possa ser facilmente expandida no futuro?

Estudante, utilize as ferramentas vistas em aula para indicar como resolver as questões abordadas nas

situações propostas, aplicando os conhecimentos adquiridos. Utilize essas ferramentas como insumos para
identi�car soluções adequadas e apresentar uma abordagem e�caz para lidar com os desa�os apresentados

Ver anotações
nas situações propostas.


Neste estudo de caso, você terá a oportunidade de enfrentar desa�os reais ao desenvolver a

arquitetura de software para uma plataforma de streaming. Essa experiência prática vai estimular sua

leitura, raciocínio lógico e capacidade de resolver problemas, enquanto fortalece seus conhecimentos

teóricos.

Para começar, é fundamental entender a importância de uma arquitetura sólida e e�ciente para lidar

com muitos usuários e fornecer uma experiência de streaming de alta qualidade. Ao aplicar o padrão

IEEE 1471-2000, você terá uma estrutura guia para elaborar a arquitetura, considerando as visões
arquiteturais, envolvimento dos stakeholders e documentos arquiteturais.

Ao analisar as situações-problema, você perceberá a necessidade de uma arquitetura escalável, capaz

de suportar o crescimento da plataforma. Isso envolve distribuição de carga, dimensionamento

horizontal e utilização de tecnologias escaláveis. Além disso, a disponibilidade e con�abilidade do

serviço são aspectos cruciais a serem considerados, incluindo a resiliência do sistema, redundância,

monitoramento e recuperação de falhas.

Outra questão é a �exibilidade e extensibilidade da plataforma. É essencial projetar uma arquitetura

que permita a inclusão de novos tipos de conteúdo e recursos adicionais, garantindo a adaptabilidade
às mudanças nas demandas dos usuários e a facilidade de expansão futura.

Ao mergulhar nesse estudo de caso, você vivenciará uma situação complexa da realidade pro�ssional,

aplicando seus conhecimentos teóricos e habilidades práticas. Lembre-se de buscar soluções alinhadas
com as diretrizes do padrão IEEE 1471-2000. No �nal, você terá a satisfação de ter contribuído para o
desenvolvimento de uma plataforma de streaming robusta e de alta qualidade.

Para resolver essas situações-problema, é necessário aplicar os conceitos do padrão IEEE 1471-2000. A
seguir, estão algumas sugestões de ações a serem realizadas:

garantir a escalabilidade da plataforma para lidar com muitos usuários simultâneos.

• Identi�cação dos stakeholders: realizar uma análise dos stakeholders envolvidos, como usuários �nais,
produtores de conteúdo, anunciantes e administradores da plataforma.

• De�nição das visões arquiteturais: elaborar visões arquiteturais relevantes, como a visão de

implantação, descrevendo a infraestrutura de hardware e software necessária para suportar a

plataforma, incluindo servidores, serviços de armazenamento e serviços de streaming.

• Consideração da escalabilidade, disponibilidade e �exibilidade: Avaliar soluções tecnológicas escaláveis,

como a utilização de serviços em nuvem e arquiteturas de microsserviços.

• Implementar mecanismos de balanceamento de carga, monitoramento de desempenho e recuperação

de falhas para garantir a disponibilidade e con�abilidade do serviço.

assegurar a disponibilidade e con�abilidade do serviço de streaming.

• Elaboração dos documentos arquiteturais: desenvolver documentos arquiteturais, como diagramas de

 contexto, diagramas de componentes e diagramas de sequência, para descrever a arquitetura
proposta.

• Consideração da escalabilidade, disponibilidade e �exibilidade: implementar mecanismos de

balanceamento de carga, monitoramento de desempenho e recuperação de falhas para garantir a

disponibilidade e con�abilidade do serviço.

oferecer uma ampla variedade de conteúdos e recursos na plataforma de streaming.

Ver anotações
• De�nição das visões arquiteturais: elaborar visões arquiteturais relevantes, como a visão de

informação, detalhando a estrutura de dados utilizada, como metadados de vídeos, músicas e

informações do usuário.

• Elaboração dos documentos arquiteturais: desenvolver documentos arquiteturais, como diagramas de

contexto, diagramas de componentes e diagramas de sequência, para descrever a arquitetura

proposta;

• Consideração da escalabilidade, disponibilidade e �exibilidade: adotar padrões e práticas de

desenvolvimento que permitam a extensibilidade e a modularidade do sistema, facilitando a inclusão

de novos conteúdos e recursos.

Ao aplicar essas ações, você utilizará os conceitos do padrão IEEE 1471-2000 para resolver as situações-

problema do estudo de caso. Essa abordagem permitirá a criação de uma arquitetura de software robusta e
e�ciente para a plataforma de streaming, considerando as necessidades dos stakeholders e seguindo as

diretrizes estabelecidas. Lembre-se de utilizar as ferramentas vistas em aula como insumos para identi�car

soluções adequadas e apresentar uma abordagem e�caz na resolução dos desa�os propostos.

Fonte: elaborada pela autora.

3 minutos

IEEE ARCHITECTURE WORKING GROUP et al.

IEEE std, v. 1471, 2000;

MEDVIDOVIC, Nenad; TAYLOR, Richard N. Software architecture: foundations, theory, and practice.
In: – Volume 2,
2010. p. 471-472.

PERRY, Dewayne E.; WOLF, Alexander L. Foundations for the study of software architecture.

v. 17, n. 4, p. 40-52, 1992.

PRESSMAN, Roger S.; MAXIM, Bruce R. Porto Alegre: Grupo A, 2021. E-book. ISBN

Ver anotações
9786558040118. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso

em: 27 abr. 2023;

ZENKER, Aline M.; SANTOS, Jailson Costa dos; COUTO, Júlia M C.; et al. Porto
Alegre: Grupo A, 2019. E-book. ISBN 9788595029767. Disponível em:

https://integrada.minhabiblioteca.com.br/#/books/9788595029767/. Acesso em: 27 abr. 2023.

KRUCHTEN, Philippe B. The 4+ 1 view model of architecture. v. 12, n. 6, p. 42-50, 1995.

PERRY, Dewayne E.; WOLF, Alexander L. Foundations for the study of software architecture.

v. 17, n. 4, p. 40-52, 1992;

PRESSMAN, Roger S.; MAXIM, Bruce R. Porto Alegre: Grupo A, 2021. E-book. ISBN

9786558040118. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso

em: 5 maio 2023;

ZENKER, Aline M.; SANTOS, Jailson Costa dos; COUTO, Júlia M C.; et al. Porto
Alegre: Grupo A, 2019. E-book. ISBN 9788595029767. Disponível em:

https://integrada.minhabiblioteca.com.br/#/books/9788595029767/. Acesso em: 5 maio 2023.

BOOCH, Grady; et al. The uni�ed modeling language. v. 14, n. 13, p. 5, 1996.

CLEMENTS, Paul C. Pittsburgh: Software Engineering Institute, 2002.

KRUCHTEN, Philippe B. The 4+ 1 view model of architecture. v. 12, n. 6, p. 42-50, 1995.

PRESSMAN, Roger S.; MAXIM, Bruce R. Porto Alegre: Grupo A, 2021. E-book. ISBN
9786558040118. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso

em: 15 maio 2023.

PRESSMAN, R. S.; BRUCE, M. A Practitioner’s Approach. 8a edição. Nova York:

McGraw-Hill Education, 2014.

WIEGERS, Karl; BEATTY, Joy. Londres: Pearson Education, 2013.

PMBOK. São Paulo: Editora Saraiva, 2014.

E-book. ISBN 9788502223745. Disponível em: https://integrada.minhabiblioteca.com.br/#/books

/9788502223745/. Acesso em: 21 maio 2023.

ISO/IEC/IEEE. Systems and software engineering–architecture description. 2011

(E)(Revision of ISO/IEC 42010: 2007 and IEEE Std 1471-2000), v. 2011, p. 1-46, 2011;

PRESSMAN, Roger S.; MAXIM, Bruce R. Nova York: McGraw Hill Brasil, 2021.
Imagem de capa: Storyset e ShutterStock.

Ver anotações