PROJETO INTEGRADOR TRANSDICIPLINAR EM REDES DE COMPUTADORES I

Prévia do material em texto

Projeto Integrador 
Transdiciplinar 
em Redes de 
Computadores I
Responsável pelo Conteúdo:
Prof. Me. Giulio Guiyti Rossignolo Suzumura
Revisão Textual:
Prof. Esp. Claudio Brites
Gerenciamento de Projetos e Análise de Requisitos
• Introdução;
• Gerenciamento de Projetos;
• Análise de Requisitos.
• Compreender que para um projeto seja bem-sucedido, sempre será necessário ha-
ver uma supervisão sobre suas etapas de construção. O Gerenciamento de Projetos, 
desenvolvido por referências específi cas, auxilia na construção de quaisquer tipos de 
cenários. Como o nosso foco são redes de computadores, iniciaremos pela principal 
tarefa para se criar um projeto de redes, ou seja, analisando e levantando os requisi-
tos do projeto. Reconhecer as necessidades de um projeto pode parecer algo trivial, 
porém, é necessário garimpar dados para extrair a real necessidade de um cliente 
para se criar um projeto adequado e viável. Nesta unidade, você aprenderá como 
coletar informações para futuramente produzir um projeto de redes. 
OBJETIVO DE APRENDIZADO
Gerenciamento de Projetos
e Análise de Requisitos
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas:
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos e 
sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você tam-
bém encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão 
sua interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Gerenciamento de Projetose Análise de Requisitos
Introdução
Imagine duas situações: na primeira, uma família deseja reformar o banheiro 
da casa onde vivem e, em uma outra, uma pessoa que quer fazer um aplicativo de 
celular para facilitar a venda de ovos em domicílios. O que essas duas situações têm 
em comum? Ambas têm objetivos fins e podem ser classificados como projetos.
Projetos podem ser definidos como objetivos definidos e claros, seja para criar 
um produto, serviço, processo ou resultado, com uma sequência de atividades que 
devem ser desenvolvidas com duração e recursos limitados.
Para satisfazer um projeto com os recursos necessários dentro de um prazo 
estabelecido, é necessário haver uma supervisão, ou seja, um gerenciamento, com 
o intuito de aplicar conhecimentos, habilidades e técnicas específicas para os dife-
rentes tipos do projeto.
Gerenciamento de Projetos
Para apresentar o que é o Gerenciamento de Projetos, é necessário um pouco 
de história, citar as principais referências que devem ser seguidas para que se possa 
compreender este estudo.
Em 1969, nos Estados Unidos, mais precisamente na Pensilvânia, surgiu o Ins-
tituto de Gerenciamento de Projetos PMI (Project Management Institute), um 
grupo formado por profissionais para discutir e compilar as melhores práticas do 
gerenciamento de projetos, que criou e deu formato ao guia PMBOK (Project Ma-
nagement Body of Knowledge).
Uma breve história do gerenciamento de projetos pode ser encontrada em: https://goo.gl/bLtkpt
Guia PMBOK® e Padrões: https://goo.gl/YJSzLb. Ex
pl
or
Utilizando as boas práticas em gerenciamento de 
projetos e prerrogativas do PMI, orientações sobre ge-
renciamento de projetos foram compiladas e publicadas 
no documento de orientação ISO 21500 em 2012 pela 
Organização Internacional de Normalização ISO (Inter-
national Organization for Standardization).
A ISO 21500:2012 for-
nece orientações sobre 
gerenciamento de pro-
jeto; já a qualidade de 
projetos é tratada pela 
ISO 10006:2003.
A crescente demanda de rapidez na entrega de projetos com menores recur-
sos e garantia de qualidade criou diferentes desafios para quaisquer organizações.
Com o intuito de satisfazer os diferentes tipos de projetos, o Gerenciamento de 
Projeto teve seus conceitos padronizados seguindo os padrões ISO e o guia do PMI.
8
9
Figura 1 – Gerenciamento de Projetos
Fonte: iStock/Getty Images
Resumidamente, o guia PMBOK explora três conceitos fundamentais para projetos:
• o ciclo de vida do projeto;
• o processo administrativo do projeto; e
• as áreas de conhecimento.
Todos esses conceitos estão intimamente ligados e são determinados de acordo 
com as necessidades e características do projeto, como, por exemplo, a facilidade 
de se definir o escopo do projeto, bem como se haverá valor em entregar uma 
documentação parcial ou integral.
O guia não determina como deve ser gerenciado um projeto, apenas apre-
senta boas práticas e deixa livre para o gerente de projeto escolher o que me-
lhor se adapta ao seu projeto. Além disso, possui valiosas informações identifi-
cadas por profissionais que, quando usadas, aumentam as chances de sucesso 
em diferentes projetos.
Gerenciamento de Projetos de Redes
Trazendo do cenário genérico proposto pelo PMBOK para a área de redes, é 
possível dizer que as interações de um projeto de redes seguem uma metodologia 
tradicional com fases bem definidas de início, meio e fim.
Inicialmente, devem ser especificadas as necessidades dos clientes do projeto e, 
em seguida, após uma compilação das informações obtidas, é necessário compre-
ender a viabilidade do projeto. O passo de confeccionar o projeto de redes efeti-
vamente significa criar a solução lógica e física para o problema; já um passo final 
pode ser interpretado como a entrega do projeto para o cliente, após aprovação 
e validação.
A implementação da rede, ou seja, a instalação de ativos e passivos de rede, não 
faz parte de um projeto de redes, mas faz uso desse para ser implementada. Sendo 
assim, podemos fazer uma distinção entre o Projeto de Rede e a Implementação 
de Rede.
9
UNIDADE Gerenciamento de Projetose Análise de Requisitos
Após a apresentação dessas divisões, é fundamental desenvolver a ideia por trás 
de cada etapa proposta para projetar redes. De certa forma, o passo inicial pode 
ser traduzido como: identificar as partes interessadas, analisar os requisitos e 
estudar a viabilidade do projeto. Em seguida, é possível criar os projetos lógicos e 
físico da rede. Já um último passo seria obter a aprovação do projeto e entregar o 
documento contendo todas as informações necessárias para a futura implantação.
O macroprocesso de Análise de Requisitos será apresentado na sequência. Já 
o Estudo de Viabilidade será formulado na próxima unidade, juntamente com a 
definição das Áreas de Gerenciamento propostas pelo PMBOK, que podem ter os 
conceitos trazidos para projetos de redes.
Análise de Requisitos
Requisitos nada mais são do que necessidades. Todo projeto, assim como um 
projeto de redes,começa com o estudo das necessidades de alguém. Portanto, a 
Análise de Requisitos pode ser interpretada como uma forma de criar critérios para 
produzir o projeto a partir dos objetivos do cliente.
Imagine que uma pessoa quer que sua televisão do quarto se conecte na inter-
net através de uma rede sem fio. Quem for criar esse projeto tem que analisar as 
necessidades, ou seja, todo os requisitos do cliente e então confeccionar o projeto.
Para identificar a real necessidade do cliente alguns questionamentos devem ser 
realizados, como, por exemplo:
• O cliente tem contrato com algum provedor de internet?
• Já existe uma rede sem fio na casa do cliente?
• Qual a distância da televisão até o possível ponto de acesso sem fio?
• O ponto de acesso sem fio e o local da TV tem visada direta?
• Qual o orçamento disponível?
Quais poderiam ser outras perguntas inerentes ao problema? Elabore algumas.
Ex
pl
or
Diversas soluções podem ser aplicadas dependendo das respostas às perguntas 
pertinentes. Assim, é necessário criar um projeto completo para o cliente levantan-
do os requisitos. Perceba que conectar a TV à internet é apenas o objetivo principal 
do cliente.
Levantamento de Requisitos
O principal processo para se criar qualquer tipo de projeto se inicia pelo Le-
vantamento de Requisitos, ou seja, a realização da coleta de dados referente às 
necessidades do cliente para qualquer que seja sua requisição.
10
11
Para isso, os envolvidos trabalham juntos 
para tornar claro o problema a ser resolvido, 
apresentando os serviços existentes, o desem-
penho necessário, restrições de hardware e ou-
tras informações.
A principal técnica para se levantar os re-
quisito é através da realização de entrevistas e
reuniões. Mesmo parecendo algo simples, es-
sas técnicas são as principais ferramentas para 
obtenção de requisitos.
Não há padrão específico para realizar essas 
tarefas, porém, é possível utilizar alguns crité-
rios como guias – estabelecer os objetivos da 
reunião e decidir quem serão os participantes 
são alguns dos passos iniciais.
Figura 2 – Entrevista com o cliente
Fonte: iStock/Getty Images
Imagine uma empresa que cresceu de forma desorganizada e atualmente ocupa 
uma grande sala comercial. Essa empresa tem em seu quadro 10 funcionários to-
dos conectados a um único roteador sem fio e não existe um servidor de arquivos 
comum aos usuários, portanto, cada usuário guarda os documentos nos seus com-
putadores pessoais.
Para o exemplo apresentado, a primeira reunião poderia ser realizada com al-
guns funcionários administrativos (não executam tarefas técnicas de rede de com-
putadores) com o objetivo de descobrir as principais necessidades voltadas à rede. 
Nessa reunião, algumas questões poderiam ser realizadas em relação ao comparti-
lhamento de arquivos, o conhecimento de cada um com sistemas operacionais, a 
velocidade da rede para diferentes situações.
Se fossem realizadas entrevistas ao invés de reuniões, outras atividades poderiam ser: 
preparar o entrevistado previamente; defi nir uma estrutura e tipos de questões; iniciar com 
perguntas mais específi cas e fi nalizar com perguntas genéricas; entre outras abordagens 
para compreender melhor o ambiente do negócio do cliente.
Ex
pl
or
Após o completo julgamento das informações retiradas das reuniões ou entre-
vistas, compreendendo o que é ou não necessário ao projeto, é possível criar um 
relatório completo sumarizando todos os requisitos do cliente. Esse processo é a 
base para a construção do projeto de redes.
No exemplo anterior, sobre um cliente que deseja conectar sua televisão do 
quarto à internet, uma boa compilação de informações seria:
O cliente já possui acesso à internet. Sua conexão é feita por um rotea-
dor que fornece apenas rede cabeada, portanto será necessário adquirir 
um roteador sem fio. A configuração deverá estar da seguinte forma [...].
Será realizado um treinamento com o cliente sobre as configurações a 
serem efetuadas [...].
11
UNIDADE Gerenciamento de Projetose Análise de Requisitos
Não há um roteiro definido de como coletar e apresentar as informações, 
mas é fundamental mostrar todas as preocupações, necessidades e especifica-
ções dos stakeholders.
Stakeholders: São todos os envolvidos em um projeto, por exemplo: o gestor da empresa, o 
contratado, os usuários e todos os que terão contato com a rede após a conclusão do projeto. Ex
pl
or
Os requisitos do projeto podem ser separados em duas categorias:
• Requisitos do negócio; e
• Requisitos técnicos.
No restante desta unidade, serão apresentados alguns fatores comuns a diversos 
tipos de clientes relativos a ambos os tipos de requisitos. Por outro lado, os estudos 
não estão limitados às proposições aqui colocadas, ou seja, a particularidade de 
cada cliente impõe projetos únicos e personalizados.
Importante!
O intuito dessa estrutura é despertar em você o olhar crítico e curioso sobre o que o 
cliente deseja, o que realmente é necessário e o que é descartável.
Importante!
Requisitos do Negócio
O projeto de rede é analisado em ter-
mos do benefício proposto para o ne-
gócio do cliente, e não em termos de 
elegância técnica e beleza. Portanto, co-
nhecer os objetivos do cliente é essencial 
para ter sucesso no projeto.
Através dos questionamentos realiza-
dos para o cliente, é possível colher di-
versas informações importantes, e então 
criar uma lista de requisitos. Os requisi-
tos mais subjetivos podem ser extraídos 
conhecendo melhor o negócio e os ob-
jetivos do cliente. Com a composição de 
todas as informações pertinentes, é pos-
sível criar o escopo do projeto da rede, 
ou seja, compilar as informações do que 
o projeto deve ou não fazer.
Requerimento de Negócio
Figura 3 – Lista de Requisitos
Fonte: iStock/Getty Images
12
13
Conhecendo o negócio do cliente
Inicialmente, é necessário conhecer a área de negócio do cliente, o que produz 
ou quais serviços realiza, determinando também quem são seus concorrentes. 
Além de conhecer o mercado do cliente, é necessário conhecer seus fornecedo-
res e parceiros.
A finalidade do projeto para o cliente, na grande 
maioria das vezes, é obter uma vantagem compe-
titiva, ou seja, melhorar sua posição no mercado. 
É incomum que empresários desejem implementar 
uma rede nova, ou ampliar uma existente, sem en-
xergar isso como uma melhora na sua organização 
ou como um investimento.
Além de descobrir mais informações sobre o 
cliente, as discussões realizadas entre o desenvolve-
dor do projeto e o cliente podem mostrar a todos 
os stakeholders o benefício da criação do projeto.
Após ter conhecimento sobre o negócio do 
cliente, é possível descobrir, a partir de outros 
questionamentos, sua estrutura organizacional. O 
objetivo de obter informações sobre os departa-
mentos, linhas de negócio, filiais e grupos de usuá-
rios é justamente o de construir um projeto perso-
nalizado focando no sucesso.
Suponha que uma rede de hospitais tem o desejo 
de construir um novo hospital em uma cidade 
qualquer. Mesmo após conhecer o negócio do cli-
ente, é possível verifi car que a estrutura organiza-
cional interna ao hospital é muito complexa. 
Precocemente, é possível identifi car alguns de-
partamentos e necessidades, como a área relativa 
ao estoque de suprimentos médicos e suprimen-
tos administrativos. Além disso, é possível imagi-
nar o grande fl uxo de dados na rede por conta de 
acessos a banco de dados de pacientes, médicos, 
exames clínicos etc.
Agora, suponha que o corpo médico e administra-
tivo seja equivalente e a diferença entre os hospi-
tais esteja na implementação tecnológica, ou seja, 
tem infl uência direta do projeto de redes. Qual 
hospital será melhor recomendado pelos usuários?
Ex
pl
or
Figura 4 – Informatização
de um hospital
Fonte: iStock/Getty Images
13
UNIDADE Gerenciamento de Projetose Análise de Requisitos
Conhecendo os objetivos do cliente
Após conhecer melhor o cliente, é imprescindível interpretar as necessidades 
dele para se construir um bom projeto,ou seja, filtrar conteúdos de reuniões, en-
trevistas, questionários, brainstorms, e-mails, telefonemas e mensagens.
O cliente necessita de um projeto de rede para seu negócio visando a um au-
mento de produtividade, crescimento lógico ou físico, aumento de taxas de transfe-
rência ou apenas porque tem problemas com a rede atual. Essas posições podem 
definir o objetivo principal, porém, além desse, diversos objetivos implícitos podem 
complementar a necessidade do projeto.
Suponha que um cliente precise de uma nova rede sem fio pois a produtividade dos usuários 
foi prejudicada por conta da rede atual não conseguir suportar o crescimento de demanda. 
Nesse cenário, a ideia do cliente é a de aumentar a produtividade dos funcionários, portanto, 
o objetivo principal é possibilitar que os usuários da rede não tenham problemas de conexão. 
Habilitar novos pontos de rede sem fio, remanejar os atuais ou atualizar a tecnologia dos 
pontos de acesso atuais são os objetivos subjacentes nesse projeto.
Ex
pl
or
Figura 5 – Descobrindo os objetivos
Fonte: iStock/Getty Images
Identificando o escopo do projeto
É possível que a nova rede seja projetada “a partir do zero”, isto é, seja criada 
por você, porém, como apresentado nos exemplos anteriores, pode ser que já 
exista uma rede prévia.
Um projeto de rede pode ser criado para modificar algo que esteja prejudicando 
a rede atual ou ampliar uma solução já existente. Portanto, além do objetivo princi-
pal, é necessário conhecer a situação inicial do cliente e projetar a situação futura.
14
15
O escopo pode ser entendido como um resumo de como a rede está e uma lista 
do que será necessário instalar ou remover na nova rede, fornecendo todos os da-
dos possíveis da estrutura lógica e física do projeto.
Figura 6 – Escopo do projeto
Fonte: iStock/Getty Images
Depois de uma análise completa sobre o negócio do cliente, entendendo sua 
estrutura organizacional, você deverá listar todos os objetivos relacionados à nova 
rede e como será possível alcançar esses objetivos, ou seja, o caminho que deverá 
ser percorrido para satisfazer o cliente. 
Mesmo conhecendo todos os requisitos do negócio do cliente, ainda existe uma 
lacuna a ser preenchida: os requisitos técnicos.
Requisitos Técnicos
A função da análise de requisitos é de traduzir frases dos clientes – como:
“Quero que a rede seja rápida e que nunca caia” – para os reais requisitos do pro-
jeto, apresentando ao cliente o que ele deverá fazer para alcançar o seu objetivo.
No sentido de resolver um problema com a utilização de tecnologia, muitos 
clientes não sabem especificar suas necessidades técnicas com precisão para proje-
tar uma rede. Analisar os requisitos técnicos é importante para poder recomendar 
tecnologias apropriadas para satisfazer todas as pessoas afetadas pela nova rede.
Os requisitos técnicos podem ser divididos em:
• Escalabilidade;
• Disponibilidade;
• Desempenho;
• Segurança;
• Gerência;
Ao decorrer da sumarização de cada tipo de requi-
sito técnico, tente relembrar os diferentes concei-
tos estudados em outras disciplinas do curso.
15
UNIDADE Gerenciamento de Projetose Análise de Requisitos
• Usabilidade;
• Adaptabilidade.
Escalabilidade
Escalabilidade significa o quanto um projeto de rede deve suportar um cresci-
mento, ou seja, estar preparado para crescer.
É um objetivo primário de quase todo projeto de rede que se adicione postos de 
trabalho, aplicações, sites ou conexões de rede a um ritmo veloz. Portanto, sempre 
se deve planejar uma possível expansão, sendo necessário descobrir qual é o cres-
cimento planejado para a rede nos próximos anos.
Dependendo da estrutura física do cliente, é possível que alguma tecnologia específica deva 
ser utilizada. Essa estrutura pode ser de diferentes tamanhos: 
Rede corporativa: rede envolvendo múltiplos campi;
Rede de campus: rede com múltiplos prédios;
Rede de prédio: rede com múltiplas LANs dentro de um único prédio;
LAN: rede entre dispositivos interconectados. 
Ex
pl
or
Para capturar e recomendar esse tipo de requisito técnico, é possível questionar 
o cliente em relação à quantidade de hosts que poderão ser adicionados ao longo 
do tempo, ou ao crescimento esperado da empresa.
Disponibilidade
Disponibilidade representa um percentual de 
tempo que a rede está disponível, sendo que o au-
mento da disponibilidade é frequentemente o ob-
jetivo principal de um projeto de rede de grandes 
empresas. Por exemplo, se uma rede pode pa-
rar no máximo 8 horas em uma semana (que tem 
168 horas), a disponibilidade dessa é de 95,24%, 
isso é, 1-(8/168) – valor normalmente considera-
do muito ruim para sistemas grandes.
A disponibilidade está vinculada à redundância, con-
fiabilidade (taxas de erros, estabilidade, período de tem-
po entre falhas), resiliência (grau de tolerância a falhas) 
e recuperabilidade (habilidade de se recuperar rapida-
mente após uma falha).
Em projetos de redes, é comum especificar o tempo 
máximo de downtime que o sistema pode ficar indisponível. Uma tabela pode 
Figura 7 – Disponibilidade
Fonte: iStock/Getty Images
16
17
facilitar a visualização da relação entre uptime, ou seja, a taxa de disponibilidade, 
e o downtime permitido.
Quadro1 – Downtime Permitido em Período de Tempo
DISPONIBILIDADE
(% UPTIME)
ANUALMENTE MENSALMENTE SEMANALMENTE DIARIAMENTE
95% 438 h 36,5 h 8,4 h 1,2 h
99,5% 43,8 h 3,7 h 50,5 min. 7,2 min.
99,95% 4,38 h 21,9 min. 5,05 min. 43,2 s
99,98% 1,75 h 8,75 min. 2,0 min. 17,3 s
99,99% 0,88 h 4,4 min. 1,0 min. 8,7 s
Sistemas de grande porte operam aproximadamente com 99,95% de taxa de 
uptime. Nesse cenário, os 5 minutos de downtime por semana, ou uma parada de 
21 minutos aproximadamente no mês, permitem alguns transientes. 99,98% de 
uptime é desejável em muitos sistemas de missão crítica, e 99,99% é o limite da 
tecnologia atualmente. 
Dependendo do tipo de cliente, o custo do tempo parado é um fator de máxima 
prioridade. Durante o levantamento de requisitos do negócio do cliente, deve-se 
descobrir quanto dinheiro a empresa perde por hora de downtime.
Em 2013, a Amazon teve uma perda fi nanceira de US$ 5 milhões em vendas causada por um 
downtime de 49 minutos, praticamente US$102.000,00/min!
Saiba mais em: https://goo.gl/Dn21z8. 
Ex
pl
or
A disponibilidade pode ser representada por um valor objetivo. Para se calcular 
esse valor efetivo, são utilizados dois parâmetros:
• Tempo Médio entre Falhas (MTBF – Mean Time Between Failures); e
• Tempo Médio para Reparos (MTTR – Mean Time To Repair).
A disponibilidade pode ser calculada através de:
Disponibilidade MTBF
MTBF MTTR
�
�
Por exemplo, a disponibilidade de um sistema que pode falhar, em média, a cada 
4000 horas e deve ter o tempo médio de reparo de 1 hora pode ser calculada por:
Disponibilidade �
�
�
4000
4000 1
99 98, %
17
UNIDADE Gerenciamento de Projetose Análise de Requisitos
Desempenho
O desempenho de uma rede pode ser definido de acordo com diversos parâme-
tros, como:
• Capacidade (bandwidth): capacidade de uma rede transmitir dados por tem-
po, largura de banda;
• Utilização: um percentual da capacidade usada na média;
• Utilização máxima: valor da utilização em que a rede é considerada saturada;
• Vazão: quantidade de dados úteis transferidos sem erro por segundo;
• Carga oferecida: a soma de todo o tráfego oferecido à rede (em bps) num 
determinado momento;
• Acurácia: quantidade de tráfego útil corretamente recebido;
• Eficiência: quantidade de dados úteis transmitidos;
• Atraso (latência): tempo médio entre o momento em que um quadro está 
pronto para ser transmitido e sua recepção em algum destino;
• Variação de atraso (jitter): variação no atraso médio;
• Tempo de resposta: tempo entre um pedido de serviço e a recepção de 
uma resposta.
Este é mais um requisito que dificilmente o cliente terá conhecimento. Um bom 
projeto de redes deve conhecer esses valores para projetar a rede; dessa forma, 
não haverá “surpresas” após a implementação da rede.
Quando a redeentrar em funcionamento, os valores deverão estar iguais, ou 
superiores, aos pré-estabelecidos. Dependendo da situação, uma ou várias dessas 
medidas se tornam importantes para o negócio do cliente.
Segurança
Problemas de segurança não devem afetar a habilidade da empresa em conduzir 
suas atividades, portanto, uma análise deve ser realizada para investigar a gravida-
de da não implementação de segurança.
Invasores podem atacar um servidor do cliente de diversas maneiras, como, por 
exemplo, usando recursos que não deveriam acessar, aproveitando brechas de se-
gurança bem conhecidas em sistemas operacionais ou aplicações e realizando um 
ataque do tipo DDoS.
Além da vulnerabilidade externa, um projeto de redes deve se preocupar com 
aspectos de segurança relativos a outros três diferentes tipos de problemas: os cau-
sados por eventos maliciosos como vírus; os causados por erros de usuários; e os 
causados por usuários internos maliciosos.
18
19
Figura 8 – Vulnerabilidade
Fonte: iStock/Getty Images
Dependendo do projeto, é de extrema necessidade prever diversos tipos de pro-
blemas relativos à segurança, sendo necessário se informar sobre a sensibilidade 
dos dados do cliente, bem como o possível efeito do roubo ou a alteração desses.
O aumento de segurança sempre envolve um trade-off, ou seja, uma troca em 
situações com conflito de escolha. Nesse caso, quanto maior a segurança, menor a 
facilidade de uso e produtividade dos funcionários, e vice-versa.
Requisitos típicos de segurança podem atingir objetivos, como a permissão de 
que pessoas externas acessem dados públicos, mas não dados internos. Outros re-
quisitos poderiam ser: identificar, autenticar e autorizar usuários remotos; detectar 
“penetras” e identificar os danos causados pela intrusão; autenticar atualizações de 
tabelas de roteamento; proteger dados, aplicações, hosts e dispositivos através de 
senhas e direitos de uso.
Gerenciamento
Alguns clientes, principalmente os que têm em seu quadro funcionários específi-
cos da área de redes, podem ter planos específicos de gerência de rede. Gerenciar 
a rede significa analisar o tráfego na rede e analisar diversos dispositivos, portanto, 
esse requisito afeta diretamente a escolha de equipamentos.
O gerenciamento de uma rede pode ser dividido em 5 tipos:
• Gerenciamento de falhas: com finalidade de detectar, isolar e corrigir falhas;
• Gerenciamento de configuração: com o intuito de controlar, operar, iden-
tificar dispositivos;
• Gerenciamento de desempenho: evidenciando uma análise do tráfego dos 
principais aplicativos e da rede como um todo;
• Gerenciamento de segurança: com a necessidade de monitorar e testar nor-
mas de segurança;
• Gerenciamento de contabilidade: com o intuito de contabilizar a utilização 
da rede para alocar custos a setores e novas mudanças.
Descobrir a real necessidade da gerência da rede do cliente pode fazer com que 
sejam especificados softwares e hardwares com melhores custo-eficácia.
19
UNIDADE Gerenciamento de Projetose Análise de Requisitos
Para gerenciar de forma satisfatória a rede de um cliente, não são necessários equipamentos 
com funções que nunca serão utilizadas.Ex
pl
or
Usabilidade
Enquanto o uso de gerência melhora a 
vida de um gerente de rede, a usabilidade 
foca o usuário final. Usabilidade diz respeito 
à facilidade com a qual usuários acessam os 
serviços via rede.
Melhorar a usabilidade significa avaliar os 
impactos da política de segurança na facilida-
de de uso, melhorar a facilidade com a qual a 
rede é configurada, tanto para o gerente de 
rede quanto para o usuário final. Além disso, 
pode ser necessário proporcionar facilidade 
com a qual a rede corporativa é usada remo-
tamente, usando VPN por exemplo.
Figura 9 – Usabilidade
Fonte: iStock/Getty Images
Adaptabilidade
Se um projeto for utilizado para ampliar uma rede já existente, intuitivamente 
deve-se conhecer as tecnologias e os protocolos utilizados para a nova rede se 
adaptar à antiga. Se um projeto for “criado do zero”, ele deve prever possíveis 
adaptações também.
A adaptabilidade descreve como o projeto de rede pode se adaptar a distintas 
mudanças, por exemplo: de tecnologia, de protocolos, de formas do negócio e 
de legislação. Após conhecer os requisitos de negócio e técnicos, é possível com-
preender que as necessidades técnicas só podem ser fomentadas após um pleno 
conhecimento do cliente, dos seus objetivos e de suas necessidades.
Após a coleta de dados referente aos requisitos de negócio, você deve ser capaz 
de especificar os requisitos técnicos para satisfazer o projeto. Além disso, essas 
especificações podem ser divididas entre os grupos apresentados.
Importante!
Você deve documentar quaisquer planos, como, por exemplo, planos de expansão de 
estações de trabalhos e servidores, planos de migração de dados. Também é impor-
tante registrar os objetivos de disponibilidade para o novo sistema, identificar apli-
cações que precisam de prioridade nos acessos e discutir a necessidade de segurança 
para todas as etapas.
Em Síntese
20
21
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
Sites
Processos de Gerenciamento de Projetos – Guia PMBOK 5. ed. Fornecido pelo Projectlab
https://goo.gl/hgahs7
A complexidade de se entender o estudo de requisitos pode ser interpretada através de uma imagem
https://goo.gl/fxrV2Q
Introdução a Engenharia de Requisitos
Em Gestão de Projetos, a Análise de Requisitos muitas vezes é definida como Engenharia 
de Requisitos. Um bom artigo referente a esse estudo complexo.
https://goo.gl/Y7tzmC
Analyzing Business Goals and Constraints of Network Design
O capítulo Analyzing Business Goals, do livro de Priscilla Oppenheimer, disponível 
como cortesia da Cisco Press, apresenta diversos tipos de requisitos.
https://goo.gl/Qzi7br
+Requisitos do Negócio | Exemplos
Uma matéria informal contendo exemplos de requisitos do negócio.
https://goo.gl/Pqhw8J
Análise de Requisitos
O site InfoEscola também disponibiliza um bom artigo sobre a Análise de Requisitos 
voltada para a Engenharia de Software que pode ser, de certa forma, transposta para 
Projeto de Redes.
https://goo.gl/zJb5qu
21
UNIDADE Gerenciamento de Projetose Análise de Requisitos
Referências
KUROSE, James F; ROSS, Keith W. Redes de computadores e a internet: uma 
abordagem top-down. 5. ed. São Paulo: Addison Wesley, 2010.
MAIA, Luiz Paulo. Arquitetura de redes de computadores. 2. ed. Rio de Janei-
ro: LTC, 2013.
OLIFER, Natália. Redes de computadores: princípios, tecnologias e protocolos 
para o projeto de redes. Rio de Janeiro: LTC, 2008.
OPPENHEIMER, Priscilla. Top-Down Network Design: A Systems Analysis 
Approach to Enterprise Network Design. 3. ed. Indiana: Cisco Press, 2011.
WHITE, Curt M. Redes de computadores. São Paulo: Cengage Learning, 2013.
22