6

Prévia do material em texto

AULA 6 
 
 
 
 
 
 
 
 
 
ENGENHARIA DE SOFTWARE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Prof. Emerson Antonio Klisiewicz 
 
 
 
02 
CONVERSA INICIAL 
Nesta aula 6, estudaremos o gerenciamento da configuração de software e 
sobre as questões envolvidas na segurança da informação. 
CONTEXTUALIZANDO 
Tanto a configuração de software que envolve questões críticas no 
desenvolvimento, por exemplo, o versionamento de aplicações, como as questões 
sobre segurança no tratamento das informações fornecidas e processadas pelos 
softwares são vitais termos o controle no mundo competitivo de desenvolvimento 
que temos hoje. 
TEMA 1 – GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE: 
PROBLEMAS 
1.1 Problema dos dados compartilhados 
Figura 1 – Dados compartilhados 
 
Na situação anterior, o desenvolvedor A modifica um software que está 
compartilhado. Posteriormente, o desenvolvedor B realiza algumas alterações no 
mesmo software e, ao tentar compilá-lo, erros são apontados pelo compilador, 
mas nenhum deles ocorre na parte que B alterou, deixando o desenvolvedor B 
sem a menor ideia da causa do problema. 
Uma solução simples seria cada desenvolvedor trabalhar em uma cópia 
“local” do software. Isso resolve o problema dos softwares compartilhados, porém, 
cria um novo problema. 
 
 
03 
1.2 Problema da manutenção múltipla 
Figura 2 – Manutenção múltipla 
 
Ocorre quando cada desenvolvedor trabalha com uma cópia “local” do que 
seria o mesmo software. Isso dificultará a identificação das funcionalidades que 
foram implementadas e em quais versões, bem como quais erros foram corrigidos. 
Podemos evitá-lo por intermédio do uso de uma biblioteca central com o software. 
Nessa proposta, cada software é copiado para a biblioteca sempre que for 
alterado. Contudo, ainda não é o ideal. 
1.3 Problema da atualização simultânea 
Figura 3 – Atualização simultânea 
 
Nesse caso, o desenvolvedor A encontra e faz a correção de um erro na 
sua versão do software. Depois de corrigido, o software modificado é copiado para 
a biblioteca central. O desenvolvedor B encontra-o e faz a correção do mesmo 
defeito na sua versão do software, por não saber que A já tinha feito, 
desperdiçando todo o trabalho de A. 
Em outra situação, o desenvolvedor A encontra e corrige um defeito em 
sua versão compartilhada. Uma vez corrigido, ele copia para a biblioteca central. 
 
 
04 
O desenvolvedor B encontra o software e corrige outro erro em sua versão do 
componente, sem saber do defeito corrigido por A. O desenvolvedor B copia sua 
versão do componente para a biblioteca central. Além do trabalho de A ser 
desperdiçado, a versão que está na biblioteca central continua apresentando erro, 
sendo que o desenvolvedor A pensa que o problema foi resolvido. 
Para resolver essa situação, precisamos ter um mecanismo de controle 
para gerenciar a entrada e saída das versões da biblioteca central. 
Leitura complementar 
Engenharia de Software: uma abordagem profissional. 8. Ed. Por Roger 
Pressman e Bruce Maxim. Capítulo 29. 
TEMA 2 – GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE: POR QUE 
USAR 
A aplicação do gerenciamento de configuração de software dentro das 
empresas oferece um ambiente de desenvolvimento de software estável, porque 
qualquer alteração sem controle de softwares torna todo o desenvolvimento 
caótico. 
O gerenciamento de configuração de software nos oferece uma “memória” 
da situação do desenvolvimento dos softwares em nossa empresa. Quando 
muitas pessoas estão trabalhando no mesmo projeto, esse gerenciamento vai 
coordenar o acesso às alterações a serem feitas nos softwares que estão sendo 
desenvolvidos. 
Dentre as tarefas que um gerenciamento de configuração possui, podemos 
citar os descritos a seguir. 
 
 
05 
Quadro 1 – Tarefas de um gerenciamento de configuração de software 
 
 
 
TEMA 3 – REPOSITÓRIO DOS ITENS DE CONFIGURAÇÃO 
Um repositório de itens de configuração é um local com controle de onde 
são armazenados os itens de configuração de software depois de liberados pelo 
desenvolvimento. Todos os itens de configuração devem ser identificados, 
analisados, corrigidos, aprovados e armazenados no repositório de itens de 
configuração, para posteriormente serem enviados para as áreas de produção. 
Todos os módulos de um repositório de itens de configuração só poderão 
ser alterados após uma solicitação de alteração formalmente aprovada pelo 
gerente de configuração. Isso é importante para que somente pessoas realmente 
autorizadas possam acessar o módulo. Essa também é uma forma para garantir 
o controle sobre cada um dos itens de configuração, evitando alguma 
inconsistência. 
 
 
06 
3.1 Check in/Check out 
Check in/check out é o método utilizado para trabalhar com itens de 
configuração que já estão no repositório, ou seja, trata-se de uma conferência na 
entrada e uma conferência na saída do software do repositório central. Quando 
for necessária a alteração em algum item de configuração do repositório, uma 
cópia do item é colocada numa área de trabalho do desenvolvedor (“check out”). 
Nessa área exclusiva, o desenvolvedor tem total liberdade de trabalho e poderá 
realizar as alterações necessárias no módulo. Veja a figura a seguir: 
Figura 4 – Check out 
 
Após o final das alterações no módulo, ele será revisado e recolocado no 
repositório (“check in”). Uma nova data de alteração será criada para o módulo 
(versão), de modo que uma nova configuração contendo o módulo alterado será 
formada e congelada no repositório. A seguir, essa situação: 
Figura 5 – Check in/check out 
 
 
 
07 
TEMA 4 – CONTROLE DE MUDANÇAS 
Durante o processo de desenvolvimento de software, mudanças 
descontroladas podem levar rapidamente o projeto ao caos. Assim, devemos 
instituir na organização um processo que combine procedimentos humanos e 
ferramentas automatizadas para proporcionar um mecanismo de controle das 
mudanças. 
O processo de controle de mudanças deve ser implementado depois que 
temos as datas em que serão implantadas as modificações realizadas nos 
módulos. A seguir, um exemplo para ilustrar um processo de controle de 
mudanças que pode ser implementado. 
Figura 5 – Exemplo: organograma de processo de controle de mudanças 
 
Os procedimentos de controle das mudanças asseguram que as mudanças 
em um software sejam feitas de modo controlado, permitindo-se prever o efeito 
delas em todo o sistema. Procedimentos formais de organização e de controle das 
mudanças permitem que os pedidos de alteração possam ser considerados em 
conjunto com outros pedidos e isso não afete o ambiente produtivo dos sistemas. 
Também permite a organização e controle das mudanças de pedidos 
incompatíveis entre si ou que possam ser atribuídas prioridades aos pedidos e, 
de acordo com essas prioridades, possam ser gerados cronogramas. 
 
 
08 
4.1 Ferramentas de GCS 
Existem algumas ferramentas de software que podem auxiliar as atividades 
de gerenciamento de configuração de software. Exemplos de ferramentas: 
 CVS (Concurrent Versions System) : <http://www.cvshome.org/>; 
 RCS (Revision Control System): 
<http://www.gnu.org/software/rcs/rcs.html>; 
 SCCS (Source Code Control System): 
<http://www.cvshome.org/cyclic/cyclicpages/sccs.html>; 
 Source Forge (Web Pages Versions Management): 
<http://versionweb.sourceforge.net/>. 
Leitura complementar 
Engenharia de Software: uma abordagem profissional. 8. ed. Por Roger 
Pressman e Bruce Maxim. Capítulo 29. 
TEMA 5 – SEGURANÇA DA INFORMAÇÃO 
Segurança da Informação(SI) é a proteção de sistemas de informação 
contra desastres, erros e manipulação de modo a minimizar a probabilidade e 
impacto de incidentes. Se divide em duas categorias: 
 Ameaças: É a intenção da parte de alguém em causar dano a um 
indivíduo/organização. Nesse item, podemos incluir sabotagem de software 
ou hardware, roubo de informações, ataques a infraestrutura, ataques de 
hackers, incêndio e inundação. Nas ameaças, temos ações em potenciais 
que seguem o caminho de menor resistência, ou seja, mais vulnerável. 
Nesse caso, o risco é medido por meio da probabilidade de que uma 
ameaça pode acontecer e o dano que pode ser gerado à pessoa/empresa. 
 Vulnerabilidade: Aqui é a deficiência na infraestrutura e organização que 
expõem riscos a eventos imprevistos/indesejáveis. Isso pode ocorrer por 
má configuração do sistema operacional, sistema de banco de dados com 
defeito, falha em um programa de acesso a dados, firewall desatualizado e 
falta de um nobreak. 
Na prevenção dentro de SI, temos as seguintes situações. 
 
 
09 
5.1 Confidencialidade 
É a garantia de que a informação é acessível somente por pessoas 
autorizadas para não acontecer a divulgação intencional (ou não) de informações 
reservadas. Questões de confidencialidade surgem porque processos e 
informação sensíveis do negócio só devem ser divulgados para 
pessoal/programas autorizados. Para isso, é imprescindível um controle de 
acesso. 
5.2 Integridade 
Trata-se da garantia da exatidão e completude da informação e dos 
métodos de processamento da informação. As informações não devem ser 
modificadas por pessoas/processos desautorizados. As informações também não 
devem ser inconsistentes e o sistema deve garantir que elas são precisas e 
completas. 
5.3 Disponibilidade 
Nesse item, temos a garantia de que usuários autorizados obtenham 
acesso à informação e aos ativos correspondentes sempre que necessário. A 
informação e os serviços do negócio devem estar disponíveis sempre que forem 
solicitados. Para isso, existe a necessidade de controles para garantir 
confiabilidade dos serviços informatizados. 
5.4 Classificação dos riscos 
5.4.1 Financeiros 
São os riscos envolvidos no relacionamento entre uma organização e o seu 
ativo. Nessa situação, temos o indivíduo ou a organização, que estão expostos a 
riscos, ativos ou receitas, cuja destruição ou perda poderá causar prejuízo 
financeiro ou uma ameaça que possa causar algum tipo de perda à empresa. 
5.4.2 Não financeiros 
São os riscos representados por perdas não passíveis de mensuração 
financeira. Por exemplo, uma inundação em que milhões de acres de fazendas 
 
 
010 
foram destruídas, causando bilhões de dólares em perdas financeiras para os 
proprietários. Não há como mensurar as perdas financeiras resultantes da 
destruição de fauna e flora selvagem. 
5.5 Exemplos de falta de segurança 
 
 
5.6 Alguns cuidados que devemos ter 
 Utilizar senhas distintas e seguras para cada site ou serviço; 
 Não instalar softwares de fontes duvidosas; 
 Manter seus sistemas sempre atualizados, incluindo antivírus; 
 Evitar conectar pendrives e outros meios de armazenamento de terceiros; 
 Não acessar sites de origem duvidosa; 
 Proteger seus arquivos pessoais em HDs, pendrives e outros dispositivos 
de armazenamento usando soluções que impeçam que seus arquivos 
caiam em mãos erradas, mesmo que o dispositivo eletrônico seja perdido 
ou mesmo roubado; 
 Não clicar em links suspeitos como aqueles recebidos por e-mail ou vistos 
em sites como os de redes sociais; 
 
 
011 
 Não salvar senhas de acesso em navegadores; 
 Ter controle de acesso aos sistemas; 
 Ter logs para saber quem acessou o sistema e o porquê; 
 Trocas automáticas de senha de tempos em tempos. 
 Ter controle de acesso aos locais de desenvolvimento. 
Leitura complementar 
Engenharia de Software: uma abordagem profissional. 8. ed. Por Roger 
Pressman e Bruce Maxim. Capítulo 27. 
FINALIZANDO 
Os computadores são utilizados para realizar inúmeras tarefas, tais como 
transações financeiras, sejam elas bancárias ou mesmo compra de produtos e 
serviços para comunicação, por exemplo; por meio de e-mails e redes sociais 
também armazenamento de dados, sejam eles pessoais ou comerciais, etc. 
Muitos se perguntam o porquê de alguém tentar acessar os nossos computadores 
e sistemas. Sim há muitos motivos: utilizar seu computador em alguma atividade 
ilícita, para esconder a real identidade e localização do invasor, utilizar seu 
computador para lançar ataques contra outros computadores, utilizar seu disco 
rígido como repositório de dados, furtar dados do seu computador. Só por isso 
vemos o quanto é importante a questão da segurança da informação e como 
devemos trabalhar para implementá-la. Uma das formas de fazê-la também é 
termos um consistente sistema de configuração de software em que qualquer 
mudança seja bem implementada e segura dentro do contexto em que ela foi 
solicitada. 
 
 
 
012 
REFERÊNCIAS 
PRESSMAN, R.; MAXIM, B. Engenharia de Software: uma abordagem 
profissional. 8. ed. Porto Alegre: McGraw-Hill, 2016.