Vous êtes sur la page 1sur 18

0

SISTEMA DE ENSINO DISTNCIA - UNOPAR


PROGRAMA DE GRADUAO
UNOPAR

PRODUO TEXTUAL INTERDICIPLINAR

Cidade
2014

Nome

PRODUO TEXTUAL INTERDICIPLINAR

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

Este trabalho tem por objetivo mostrar um planejamento


hipottico sobre a implantao de um software em uma empresa locadora de
carros. Aqui abordamos o melhor ciclo de vida para tal, apresentamos um
estudo WBS sobre os aspectos do projeto e criamos um cronograma, onde a
equipe seguir os passos para o desenvolvimento do software, levando em
considerao os riscos, custos e o tempo limitado que a equipe tem para se
dedicar a este projeto.

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.

4.2 Desenvolver um WBS

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

4.3 Desenvolvimento de um cronograma do projeto


Para tal foi utilizada a ferramenta Microsoft Project 2010

O cronograma foi desenvolvido levando em conta projetos genricos,


associando tarefas comuns e nomes de uma equipe inventada para deixar o
exemplo mais prximo da realidade.

Em modo de tabela simples temos:

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

Predecessora Nomes dos


s
recursos

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

Analise do tempo 14 dias

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

4.4 Aspectos do IHC


O termo usabilidade faz parte do vocabulrio tcnico da Cincia da
Computao, na rea de Interao Humano-Computador (IHC), se refere
qualidade da interao entre sistemas e usurios e depende de vrios
aspectos, como a facilidade em aprender, a eficincia, a satisfao do usurio,
para citar alguns. Pesquisas so realizadas h mais de 20 anos nesta rea,
elas tratam principalmente de tcnicas de avaliao de usabilidade, que
demonstram tanto os resultados do emprego destas tcnicas, como a medida
da eficincia das mesmas. Desta forma, com a validao e qualificao dos
processos de avaliao, busca-se a identificao dos principais problemas de
usabilidade de sistemas e a indicao de como trat-los.
Neste contexto, destaca-se o Nielsen Norman Group que realiza testes
para avaliar a usabilidade de sistemas Web desde 1994. Publicaes recentes
do grupo apontam que os usurios desses sistemas esto menos tolerantes,
pois de uma forma geral tm menos barreiras e atrasos na obteno do que
querem na Web. Isto, em parte por causa dos sites de busca, que oferecem
uma lista de endereos que podem resolver o problema do usurio.
Em parte tambm, porque o acesso a pginas Web algo rotineiro e o
nmero de sites e pginas disponveis aumentou. Por isso, pensar a
usabilidade de sistemas Web comerciais importante, este atributo de
qualidade pode cativar ou afastar usurios, que neste caso, so clientes em
potencial.
Para a Association for Computing Machinery Special Interest Group on
Computer-Human Interaction ACM SIGCHI , a IHC uma rea que abrange a
concepo, avaliao e implementao de sistemas computacionais
interativos, para uso humano, e o estudo das principais questes relacionadas
a estes sistemas. Assim, a IHC tem por objetivo fornecer aos pesquisadores e
desenvolvedores de sistemas explicaes e previses para fenmenos da
interao usurio-sistema. Com resultados prticos que possibilitam
antecipadamente determinar se o design e a interface do sistema satisfazem as
necessidades de usabilidade, aplicabilidade e comunicabilidade dos usurios.
Nielsen apresenta um conceito relacionado IHC, o de aceitabilidade do
sistema, como uma combinao da aceitabilidade social - que diz respeito
principalmente aos benefcios ou incmodos sociais que o software pode
prover aos seus usurios, por exemplo, os sistemas de controle das portas de
entrada em bancos, que apesar de benficos, no so aceitos socialmente,
pois dificultam a entrada das pessoas no banco; e da aceitabilidade prtica que
se refere s qualidades tcnicas do software, como confiabilidade, custo,
compatibilidade, e tambm a utilidade e a usabilidade do sistema.

11

4.5 Segurana na WEB


Aspectos de Segurana na Web
A Web foi projetada sem muita preocupao, ou quase nenhuma, com
segurana. O objetivo principal era disponibilizar informaes de uma forma
mais amigvel que os recursos disponveis na poca. Com o rpido
crescimento da Web e com a diversificao de sua utilizao, a segurana se
tornou um ponto de importncia crucial, principalmente para quem tem a Web
como um dos principais apelos comerciais. Aqui abordamos alguns itens de
segurana que devem ser levados em considerao em um servidor Web.
As Ameaas na Web
Atualmente, a Web enfrenta diferentes formas de ameaa que foram
surgindo ao longo de sua evoluo. A Web no introduziu muito mais ameaas
de segurana do que j existia na Internet. A Internet funciona para a Web
como seu mecanismo de transporte e, portanto, herda suas vulnerabilidades de
segurana. Devido pressa na construo de novas funcionalidades em todo o
ambiente, projetistas no consideraram o impacto em segurana que esta nova
tecnologia causaria, deixaram de ver importantes pontos de possveis ataques
e vulnerabilidades. A Web no demorou muito em caminhar da comunidade
cientfica para o mundo comercial. Neste ponto, as ameaas tornaram-se mais
srias. Uma nova tecnologia encontrava-se disponvel e muito atrativa para os
atacantes. A seguir apresentamos uma comparao das principais formas de
ameaas.
Ameaas:
- modificao de dados do usurio
- browser cavalo de Tria
- modificao de memria
- modificao de mensagens em trnsito
- eavesdropping
- roubo de informaes/dado do servidor/cliente
- informao da configurao da rede/mquinas
- informao de qual cliente "conversa" com servidor em trnsito

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

crescem em sua complexidade. Se no se tem uma boa configurao torna-se


difcil o emprego de uma poltica de gerenciamento satisfatria.
Como so organizadas estas configuraes?
Arquivos de configuraes contm diretivas que so tratadas pelo
daemon httpd. Estas diretivas controlam o comportamento de funes do
servidor, como: controle de acesso a pginas (nomes e senhas),
disponibilizao de recursos, etc.
Um exemplo: uma diretiva que bloqueia acessos indevidos (bloqueia
acessos ao arquivo de senha /etc/passwd)
Alguns cuidados devem ser levados em considerao: saiba o que j
vem previamente configurado em seu servidor ao instal-lo; comente (iniba) o
desnecessrio e conhea bem o que voc tem configurado em seu servidor
Web; configure seu servidor para tratar acessos indevidos; no se esquea de
checar seus logs constantemente, etc.
Estrutura de Diretrios
A estrutura hierrquica de diretrios de um servidor Web composta de
dois diretrios.
Os diretrios:
Raiz do servidor: tem informaes de controle do servidor, como:
arquivos de configuraes, aplicaes adicionais, etc.
Raiz de Documentos (o Web space do servidor): contm o contedo
"pblico" (informaes disponibilizadas via conexes HTTP). Geralmente este
um sub-diretrio do diretrio raiz do servidor.
Ao se "disparar" um servidor Web, todas as informaes abaixo da raiz
do diretrio de documentos podero ser disponibilizadas publicamente a menos
que se tenha alguma restrio de acesso. Um dos erros mais comuns se
executar o servidor Web como "root", o que trs algumas vulnerabilidades para
seus sistemas. Uma soluo muitas vezes adotada rodar o servidor Web
como usurio "nobody", que tambm trs vulnerabilidades. Algumas aplicaes
tambm podem estar sendo executadas como "nobody" e portanto o servidor
Web passa a ter seus mesmos privilgios. Uma boa estratgia criar um
usurio qualquer (e tambm um grupo) especfico para o servidor Web
(exemplos: web, www, webserver, etc...). Assim, acessos ao sistema de arquivo
sero restringidos a este usurio, e tambm eventuais ataques feitos ao
servidor tambm seriam afetados ao usurio Web especfico do servidor.
Server-Side Include (SSI)
SSI um cdigo HTML que "injeta" a sada de um comando ou um
arquivo dentro da pgina quando enviada pelo servidor para o browser. A
formatao HTML um contedo esttico, SSI um contedo dinmico.
SSIs so bastante teis, mas podem tambm ser "caros"
computacionalmente, acabam com a portabilidade e podem abrir srios furos
de segurana. Se esta funcionalidade no necessria para o seu servidor,
melhor desabilit-la.

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

ferramenta suEXEC, resolve este problema (existem outras ferramentas que


tambm tratam este problema) fazendo com que aplicaes CGIs sejam
executadas sob o UID do prprio usurio, isto , o dono da aplicao CGI.

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.

Vous aimerez peut-être aussi