Académique Documents
Professionnel Documents
Culture Documents
Cidade
2014
Nome
Trabalho
apresentado
as
disciplinas
de
Programao Web 1; Projetos de Sistemas;
Interface Home-Computador. do 5. Semestre do
Curso de Anlise e Desenvolvimento de Sistemas
da Universidade Norte do Paran - UNOPAR
Profs.:
Cidade
2013
Veronice de Freitas
Marco Ikuro Hisatomi
Adriane A Loper
SUMRIO
1. Capa............................................................................................01
2.Introduo.....................................................................................03
3. Objetivo........................................................................................04
4. Desenvolvimento.........................................................................05
4.1. Escolha um Ciclo de Vida para o projeto..................................05
4.2. Desenvolver um WBS...............................................................06
4.3. Desenvolvimento de um cronograma do projeto......................08
4.4 Aspectos do IHC........................................................................10
4.5 Segurana na WEB...................................................................11
5. Concluso....................................................................................16
6. Referncias..................................................................................17
2. INTRODUO
Fundamental para qualquer projeto, incluindo projetos de
software, o planejamento onde podemos medir gasto, despesas, tempo e o
principal, o lucro que obteremos. Aqui abordaremos caractersticas dos grficos
de Gantt e do WBS, falaremos a respeito de segurana na WEB e um breve
esboo sobre interfaces Homem-Computador.
3. OBJETIVO
4. DESENVOLVIMENTO
4.1 Escolha um Ciclo de Vida para o projeto
O modelo escolhido foi o Espiral, pois O modelo espiral
procura atravs do desenvolvimento de prottipos em ciclos, entrega um
produto mais prximo necessidade/realidade do cliente com a utilizao dos
seguintes passos:
1 Identificar os stakeholders;
2 Identificar os requisitos que satisfaam os stakeholders;
3 Planejar/Estabelecer objetivos, restries e alternativas;
4 Avaliar os riscos, restries e alternativas;
5 Definir o produto e o processo;
6 Validar o produto e o processo;
7 Revisar;
Estes passos se assemelham ao ciclo PDCA (Plan, Do, Check, Act),
ferramenta gerencial que auxilia na tomada de deciso e na garantia de
alcance de metas/objetivos.
Modelo Espiral
Por se tratar de um modelo evolutivo, uma das suas vantagens ter um maior
controle sobre os riscos do projeto, tornando o processo de construo de um
produto complexo de uma maneira mais segura.
Para tal, foi utilizada a ferramenta gratuita WBS Tool do site www.wbstool.com.
1 VocAluga
1.1 Iniciao
1.1.1 Necessidade / Oportunidade
1.1.2 Escopo geral
1.1.3 Objetivos
1.1.4 Premissas e restries
1.1.5 Principais Stakeholders
1.1.6 Identificao dos riscos
1.1.7 Estimativa de prazo
1.1.8 Estimativa de custo
1.2 Planejamento
1.2.1 Cronogramas
1.2.2 Atividades Interdependentes
1.2.3 Alocao de Recrsos
1.2.4 Anlise de Custos
1.2.5 Comunicao
1.2.6 Qualidade
1.2.7 Riscos
1.2.8 Suprimentos
1.2.9 Recursos Humanos
1.3 Execuo
1.3.1 Verificao do Escopo
1.3.2 Mudanas de Escopo
1.3.3 Design
1.3.4 Desenvolvimento do Sistema
1.3.5 Testes Via Prototipao
1.3.6 Reviso
1.3.7 Publicao
1.4 Controle
1.4.1 Tempo
1.4.2 Custo
1.4.3 Qualidade
1.4.4 Risco
1.4.5 Aes Corretivas e Preventivas
1.4.6 Deteco de Anormalidades
1.5 Entrega
1.5.1 Avaliao Interna ou Externa
1.5.2 Discusso das Falhas
1.5.3 Aceitao do Projeto
1.5.4 Manuteno
Nome da tarefa
Durao Incio
Trmino
34,33
dias
Sex
06/06/14
Sex
23/05/14
Sex
23/05/14
Seg
26/05/14
Sex
30/05/14
Ter
Qua
21/05/14
Qua
Reunio
7 dias
21/05/14
Qua
Coleta de dados 7 dias
21/05/14
Definio de
Qui
7 dias
provedor
22/05/14
Definio de
Sex
14 dias
escopo
23/05/14
Alocao de
14 dias Ter
Pr Projeto
Equipe
Equipe
2II
Paulo
3TT
Paulo e Julia
Julia
Julia
9
recursos
27/05/14 03/06/14
Analise de custos
Ter
Ter
riscos e
14 dias
27/05/14 03/06/14
suprimentos
Definio dos
Qua
Sex
prazos e
21 dias
28/05/14 06/06/14
cronograma
Seg
Ter
Execuo
45 dias
02/06/14 24/06/14
Criao do
Seg
Seg
14 dias
design
02/06/14 09/06/14
Criao de
Ter
Ter
diagramas de
14 dias
03/06/14 10/06/14
classe
Criao do banco
Qui
Seg
21 dias
de dados
05/06/14 16/06/14
Sex
Seg
Criao cdigo
30 dias
06/06/14 23/06/14
criao de folha
Ter
Qui
21 dias
de estilos
10/06/14 19/06/14
Sex
Ter
Reviso
21 dias
13/06/14 24/06/14
Sex
Ter
Prototipao
21 dias
06/06/14 17/06/14
Seg
Qua
7 dias
Entrega/Publicao
16/06/14 18/06/14
17,67 Seg
Ter
Entrega
dias
16/06/14 24/06/14
Avaliao Interna
Seg
Qua
7 dias
ou Externa
16/06/14 18/06/14
Discusso de
falhas
14 dias
Aceitao do
Projeto
7 dias
Manuteno
7 dias
Controle
43,33
dias
Analise dos
custos
Riscos
controle de
qualidade
Deteco de
anomalias
30 dias
Equipe
Paulo
Fernanda e
Joo
Fernanda
10
Joo
11
Joo
12
Fernanda
13TT
Joo
14
Fernanda e
Joo
11
Fernanda
16
Equipe
17
Paulo
Ter
Ter
19
17/06/14 24/06/14
Qui
19/06/14
Sex
20/06/14
Seg
20
23/06/14
Ter
21
24/06/14
Seg
Ter
02/06/14 24/06/14
Seg
02/06/14
Seg
14 dias
02/06/14
Seg
21 dias
02/06/14
Seg
30 dias
02/06/14
6II
Seg
09/06/14
Seg
24II
09/06/14
Qua
25II
11/06/14
Ter
26II;10II
17/06/14
Seg
Ter
26
09/06/14 24/06/14
Julia
Paulo, Julia,
Joo e
Fernanda
Cliente
Joo e
Fernanda
Paulo, Julia,
Joo e
Fernanda
Joo e Paulo
Julia
Julia
Paulo e Joo
Paulo, Julia,
Joo e
Fernanda
10
Aes
preventivas e
corretivas
30 dias
Seg
Ter
28II
09/06/14 24/06/14
Julia
11
12
- bloqueio da conexo
- inundao da mquina com solicitaes
- isolamento mquina por ataques a DNS
- personificao de usurios legtimos
- falsificao de dados
Consequncias
- perda de dados
- compromete a mquina
- vulnerabilidade para outras ameaas
- perda de informaes
- perda de privacidade
- interrupo
- aborrecimento
- impedir usurio realizar seu trabalho
- m representao do usurio
- crena que informao falsa verdadeira
Integridade
Ataques contra integridade consistem em alteraes maliciosas de
dados, programas, mensagens e at mesmo informaes da memria. Este
tipo de ataque devastador. Na maioria dos sistemas, este tipo de ataque
permite ao atacante ler/modificar/remover qualquer arquivo, enviar mensagem,
etc. Enfim ter total controle de seu computador.
Confidencialidade
Este ataque tenta revelar informaes confidenciais para terceiros. Um
atacante pode tentar obter estas informaes na mquina do usurio ou no
servidor. Normalmente, assumimos que informaes em nossas mquinas
locais so privadas, mas poucos tm cincia de que uma vez que voc esteja
conectado Internet estas informaes podem no se tornar to confidenciais
assim. Por exemplo, os "browsers" normalmente mantm caches locais de
13
visitas efetuadas pelos usurios a servidores Web que podem revelar alguns
"hbitos" deste usurio.
Negao de Servio
Esta uma das mais srias ameaas na Web e a mais difcil de prevenir.
Este tipo de ataque consiste em aes maliciosas que desviam acessos a um
determinado servio que se encontra disponvel. Web spoofing um exemplo
tpico deste tipo de ataque, acessos feitos a determinado servidor Web so
desviados para um outro servidor, normalmente um clone.
Veja o exemplo abaixo:
Suponha que um competidor de uma empresa X deseja "roubar"
informaes ou parte das transaes da empresa Y. A empresa Y tem um
servidor Web: com IP: 1.2.3.4. O competidor que tem um servidor Web com
aparncia idntica a do primeiro e envia (fazendo "spoofing" no DNS) o
endereo IP 5.6.7.8( de sua empresa, Y).
O usurio que tenta se conectar no site da empresa X, na verdade est
conectando com o servidor em 5.6.7.8 (o falso servidor Web). Efetua suas
transaes e no percebe que efetuou a compra em um site falso ou
simplesmente, este site informa preos elevados, o que faz o usurio procurar
a empresa concorrente da empresa X (a prpria empresa "intrusa" neste caso).
Autenticao
Neste caso, o atacante se faz passar por outro, obtendo a senha do
usurio por algum mtodo qualquer, como por exemplo, filtrando pacotes na
rede e capturando senhas no criptografadas.
Segurana no Servidor
Em um ambiente cliente/servidor as atenes normalmente esto
direcionadas para o servidor, onde residem as informaes e, portanto, foco de
ameaas. Os clientes na Web esto fora de nossa guarda e assim fora do
nosso controle. A proteo do cliente, no o grande objetivo, a no ser
quando se trata de sua privacidade. Segurana no servidor Web consiste, em
geral, em um ponto crtico em relao para algumas organizaes que tem a
Web a sua principal fonte de renda.
Os assuntos de segurana tratados aqui so direcionados ao servidor
Apache em ambiente Unix por ser o mais utilizado na Internet. Mas, a maioria
das recomendaes, tpicos, sugestes, etc. mencionada vlida para outros
servidores Web.
Configuraes Bsicas
Um dos maiores problemas de segurana, assim como com outros
servios de rede, o mau gerenciamento. Sistemas distribudos com uma m
configurao pode significar um desastre. Sistemas crescem e tambm
14
15
Autenticao
Em geral, servios Web so muito dependentes de servidores de nomes.
Se um servidor de nome atacado, servidores Web dependentes deste servio
podem ter sua autenticao comprometida.
Autenticao Bsica
Um servio que prov autenticao bsica utiliza a identificao do
usurio (username) e a senha, que passa as claras (sem criptografia) pela
rede. No mximo, em alguns casos, alguns pequenos "mascaramentos" so
utilizados como o redirecionamento para uuencode do Unix. Algumas restries
de acesso podem ser utilizadas via arquivo .htaccess. Este arquivo contm
diretivas, palavras chaves que norteiam o acesso do httpd.
Uma vez autenticado, temos a autorizao. Existem dois tipos de
autorizao: por diretrio e por servidor.
Por diretrio, significa restrio de acesso a um determinado diretrio
dentro de sua rvore do seu web space.
Autorizaes por servidor somente muda a localizao das diretivas,
agora definidas no servidor, que podem ser sobrepostas por outras por
diretrio.
Digest Authentication
Diferentemente do que ocorre em Autenticao Bsica, em DA a senha
no passa pela rede as claras. A comunicao entre as partes envolvidas,
neste esquema, contm um checksum, por default MD5, o username, a senha,
o mtodo HTTP, e um autenticador nico (geralmente um nmero randmico
longo), alm da URL requisitada. O objetivo melhorar a segurana de senhas.
CGI Scripts
Quase todo servidor Web que se visita utiliza algum tipo de contedo
ativo. Common Gateway Interface (CGI), um tipo de matalinguagem ou
middleware, que permite a interoperabilidade requerida por este contedo.
um mecanismo independente de plataforma provido pelo servidores Web que
permitem executar programas/scripts a partir de uma URL. Estes scripts so
geralmente escritos em Perl, Shell, Tcl, Java, Python ou C (maioria escritos em
linguagem interpretadas) e localizados normalmente em um diretrio /cgi-bin.
Aplicaes CGI escritas sem cuidados com segurana podem causar
srios problemas a vulnerabilidades de servidores Web.
Um CGI script sendo executado sob o mesmo UID do servidor Web no
necessariamente um fato ruim, mas se alguma aplicao CGI possui um furo
de segurana que permite que um atacante execute programas sob UID do
servidor Web, isso pode acarretar um problema bastante srio ao seu site.
Uma maneira de contornar este problema via "wrappers", isto ,
programas que envolvem outros programas afim de alterar a maneira que estes
operam. Assim, em ambientes onde usurios escrevem independentemente
aplicaes CGI, uma boa estratgia isol-los um dos outros, isto ,
implementar mecanismos em seu servidor de maneira que acessos de scripts
de um usurio no venham a interferir em dados de outros usurios. A
16
5. CONCLUSO
Pudemos, com esse trabalho por em pratica o conhecimento adquirido
ao longo do semestre, como a criao de um cronograma e a elaborao de
um grfico de Gantt. muito interessante que, ao desenvolvermos esse
trabalho, visando a pr-produo de um software pudemos relembrar
contedos que vimos desde o inicio do curso, e empregamos com
funcionalidade e objetividade.
17
6. Referncias
ABBAGNANO, N. Dicionrio de Filosofia. Trad. de Alfredo Bosi (Org.). So
Paulo: Martins Fontes, 1999.
Dentro da Linguagem de Modelagem Unificada , Material da Rational
A.D. Rubin, D. Geer, and M.J. Ranum, Web Security Sourcebook, John Wiley &
Sons, New York, 1997.
A.D. Rubin, D. Geer, A Survey of Web Security, Computer, September 1998, pp
34-41.