Protifolio 5º semestre individual unopar analise de sistemas

1. SISTEMA DE ENSINO À DISTÂNCIA - UNOPAR
PROGRAMA DE GRADUAÇÃO
UNOPAR
PRODUÇÃO TEXTUAL INTERDICIPLINAR
Cidade

2. 2
2014
Nome
PRODUÇÃO TEXTUAL INTERDICIPLINAR
Trabalho apresentado as disciplinas de
Programação Web 1; Projetos de Sistemas;
Interface Home-Computador. do 5º. Semestre do
Curso de Análise e Desenvolvimento de Sistemas
da Universidade Norte do Paraná - UNOPAR
Profs.: Veronice de Freitas
Marco Ikuro Hisatomi
Adriane A Loper
Cidade

3. 3
2013
SUMÁRIO
1. Capa............................................................................................01
2.Introdução.....................................................................................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 Segurança na WEB...................................................................11
5. Conclusão....................................................................................16
6. Referências..................................................................................17

4. 4
2. INTRODUÇÃO
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 características dos gráficos
de Gantt e do WBS, falaremos a respeito de segurança na WEB e um breve
esboço sobre interfaces Homem-Computador.

5. 5
3. OBJETIVO
Este trabalho tem por objetivo mostrar um planejamento
hipotético sobre a implantação 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
consideração os riscos, custos e o tempo limitado que a equipe tem para se
dedicar a este projeto.

6. 6
4. DESENVOLVIMENTO
4.1 Escolha um Ciclo de Vida para o projeto
O modelo escolhido foi o Espiral, pois O modelo espiral
procura através do desenvolvimento de protótipos em ciclos, entrega um
produto mais próximo à necessidade/realidade do cliente com a utilização dos
seguintes passos:
1 – Identificar os stakeholders;
2 – Identificar os requisitos que satisfaçam os stakeholders;
3 – Planejar/Estabelecer objetivos, restrições e alternativas;
4 – Avaliar os riscos, restrições 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 decisão e na garantia de
alcance de metas/objetivos.
Modelo Espiral

7. 7
Por se tratar de um modelo evolutivo, uma das suas vantagens é ter um maior
controle sobre os riscos do projeto, tornando o processo de construção 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.

8. 8
1 VocêAluga
1.1 Iniciação
1.1.1 Necessidade / Oportunidade
1.1.2 Escopo geral
1.1.3 Objetivos
1.1.4 Premissas e restrições
1.1.5 Principais Stakeholders
1.1.6 Identificação 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 Alocação de Recrsos
1.2.4 Análise de Custos
1.2.5 Comunicação
1.2.6 Qualidade
1.2.7 Riscos
1.2.8 Suprimentos
1.2.9 Recursos Humanos
1.3 Execução
1.3.1 Verificação do Escopo
1.3.2 Mudanças de Escopo
1.3.3 Design
1.3.4 Desenvolvimento do Sistema
1.3.5 Testes Via Prototipação
1.3.6 Revisão
1.3.7 Publicação
1.4 Controle
1.4.1 Tempo
1.4.2 Custo
1.4.3 Qualidade
1.4.4 Risco
1.4.5 Ações Corretivas e Preventivas
1.4.6 Detecção de Anormalidades
1.5 Entrega
1.5.1 Avaliação Interna ou Externa
1.5.2 Discussção das Falhas
1.5.3 Aceitação do Projeto
1.5.4 Manutenção

9. 9
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 genéricos,
associando tarefas comuns e nomes de uma equipe inventada para deixar o
exemplo mais próximo da realidade.
Em modo de tabela simples temos:
Nome da tarefa Duração Início Término Predecessoras Nomes dos recursos
Pré Projeto 34,33 dias
Qua
21/05/14
Sex
06/06/14
Equipe
Reunião 7 dias
Qua
21/05/14
Sex
23/05/14
Equipe
Coleta de dados 7 dias
Qua
21/05/14
Sex
23/05/14
2II Paulo
Definição de provedor 7 dias Qui Seg 3TT Paulo e Julia

10. 10
22/05/14 26/05/14
Definição de escopo 14 dias
Sex
23/05/14
Sex
30/05/14
4 Julia
Alocação de recursos 14 dias
Ter
27/05/14
Ter
03/06/14
5 Julia
Analise de custos
riscos e suprimentos
14 dias
Ter
27/05/14
Ter
03/06/14
6II Equipe
Definição dos prazos e
cronograma
21 dias
Qua
28/05/14
Sex
06/06/14
7 Paulo
Execução 45 dias
Seg
02/06/14
Ter
24/06/14
8 Fernanda e João
Criação do design 14 dias
Seg
02/06/14
Seg
09/06/14
Fernanda
Criação de diagramas
de classe
14 dias
Ter
03/06/14
Ter
10/06/14
10 João
Criação do banco de
dados
21 dias
Qui
05/06/14
Seg
16/06/14
11 João
Criação código 30 dias
Sex
06/06/14
Seg
23/06/14
12 Fernanda
criação de folha de
estilos
21 dias
Ter
10/06/14
Qui
19/06/14
13TT João
Revisão 21 dias
Sex
13/06/14
Ter
24/06/14
14 Fernanda e João
Prototipação 21 dias
Sex
06/06/14
Ter
17/06/14
11 Fernanda
Entrega/Publicação 7 dias
Seg
16/06/14
Qua
18/06/14
16 Equipe
Entrega 17,67 dias
Seg
16/06/14
Ter
24/06/14
17 Paulo
Avaliação Interna ou
Externa
7 dias
Seg
16/06/14
Qua
18/06/14
Julia
Discussão de falhas 14 dias
Ter
17/06/14
Ter
24/06/14
19
Paulo, Julia, João
e Fernanda
Aceitação do Projeto 7 dias
Qui
19/06/14
Seg
23/06/14
20 Cliente
Manutenção 7 dias
Sex
20/06/14
Ter
24/06/14
21 João e Fernanda
Controle 43,33 dias
Seg
02/06/14
Ter
24/06/14
Paulo, Julia, João
e Fernanda
Analise do tempo 14 dias
Seg
02/06/14
Seg
09/06/14
João e Paulo
Analise dos custos 14 dias
Seg
02/06/14
Seg
09/06/14
24II Julia
Riscos 21 dias
Seg
02/06/14
Qua
11/06/14
25II Julia
controle de qualidade 30 dias
Seg
02/06/14
Ter
17/06/14
26II;10II Paulo e João
Detecção de 30 dias Seg Ter 26 Paulo, Julia, João

11. 11
anomalias 09/06/14 24/06/14 e Fernanda
Ações preventivas e
Seg
Ter
30 dias
28II Julia
corretivas
09/06/14
24/06/14
4.4 Aspectos do IHC
O termo usabilidade faz parte do vocabulário técnico da Ciência da
Computação, na área de Interação Humano-Computador (IHC), se refere à
qualidade da interação entre sistemas e usuários e depende de vários
aspectos, como a facilidade em aprender, a eficiência, a satisfação do usuário,
para citar alguns. Pesquisas são realizadas há mais de 20 anos nesta área,
elas tratam principalmente de técnicas de avaliação de usabilidade, que
demonstram tanto os resultados do emprego destas técnicas, como a medida
da eficiência das mesmas. Desta forma, com a validação e qualificação dos
processos de avaliação, busca-se a identificação dos principais problemas de
usabilidade de sistemas e a indicação de como tratá-los.
Neste contexto, destaca-se o Nielsen Norman Group que realiza testes
para avaliar a usabilidade de sistemas Web desde 1994. Publicações recentes
do grupo apontam que os usuários desses sistemas estão menos tolerantes,
pois de uma forma geral têm menos barreiras e atrasos na obtenção do que
querem na Web. Isto, em parte por causa dos sites de busca, que oferecem
uma lista de endereços que podem resolver o problema do usuário.
Em parte também, porque o acesso a páginas Web é algo rotineiro e o
número de sites e páginas disponíveis aumentou. Por isso, pensar a
usabilidade de sistemas Web comerciais é importante, este atributo de
qualidade pode cativar ou afastar usuários, que neste caso, são 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
concepção, avaliação e implementação de sistemas computacionais
interativos, para uso humano, e o estudo das principais questões relacionadas
a estes sistemas. Assim, a IHC tem por objetivo fornecer aos pesquisadores e
desenvolvedores de sistemas explicações e previsões para fenômenos da
interação usuário-sistema. Com resultados práticos que possibilitam
antecipadamente determinar se o design e a interface do sistema satisfazem as
necessidades de usabilidade, aplicabilidade e comunicabilidade dos usuários.
Nielsen apresenta um conceito relacionado à IHC, o de aceitabilidade do
sistema, como uma combinação da aceitabilidade social - que diz respeito
principalmente aos benefícios ou “incômodos” sociais que o software pode
prover aos seus usuários, por exemplo, os sistemas de controle das portas de
entrada em bancos, que apesar de benéficos, não são aceitos socialmente,
pois dificultam a entrada das pessoas no banco; e da aceitabilidade prática que
se refere às qualidades técnicas do software, como confiabilidade, custo,
compatibilidade, e também a utilidade e a usabilidade do sistema.

12. 12
4.5 Segurança na WEB
Aspectos de Segurança na Web
A Web foi projetada sem muita preocupação, ou quase nenhuma, com
segurança. O objetivo principal era disponibilizar informações de uma forma
mais amigável que os recursos disponíveis na época. Com o rápido
crescimento da Web e com a diversificação de sua utilização, a segurança se
tornou um ponto de importância crucial, principalmente para quem tem a Web
como um dos principais apelos comerciais. Aqui abordamos alguns itens de
segurança que devem ser levados em consideração em um servidor Web.
As Ameaças na Web
Atualmente, a Web enfrenta diferentes formas de ameaça que foram
surgindo ao longo de sua evolução. A Web não introduziu muito mais ameaças
de segurança do que já existia na Internet. A Internet funciona para a Web
como seu mecanismo de transporte e, portanto, herda suas vulnerabilidades de
segurança. Devido à pressa na construção de novas funcionalidades em todo o
ambiente, projetistas não consideraram o impacto em segurança que esta nova
tecnologia causaria, deixaram de ver importantes pontos de possíveis ataques
e vulnerabilidades. A Web não demorou muito em caminhar da comunidade
científica para o mundo comercial. Neste ponto, as ameaças tornaram-se mais
sérias. Uma nova tecnologia encontrava-se disponível e muito atrativa para os
atacantes. A seguir apresentamos uma comparação das principais formas de
ameaças.
Ameaças:
- modificação de dados do usuário
- browser cavalo de Tróia
- modificação de memória
- modificação de mensagens em trânsito
- eavesdropping
- roubo de informações/dado do servidor/cliente
- informação da configuração da rede/máquinas
- informação de qual cliente "conversa" com servidor em trânsito

13. 13
- bloqueio da conexão
- inundação da máquina com solicitações
- isolamento máquina por ataques a DNS
- personificação de usuários legítimos
- falsificação de dados
Consequências
- perda de dados
- compromete a máquina
- vulnerabilidade para outras ameaças
- perda de informações
- perda de privacidade
- interrupção
- aborrecimento
- impedir usuário realizar seu trabalho
- má representação do usuário
- crença que informação falsa é verdadeira
Integridade
Ataques contra integridade consistem em alterações maliciosas de
dados, programas, mensagens e até mesmo informações da memória. 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 informações confidenciais para terceiros. Um
atacante pode tentar obter estas informações na máquina do usuário ou no
servidor. Normalmente, assumimos que informações em nossas máquinas
locais são privadas, mas poucos têm ciência de que uma vez que você esteja
conectado à Internet estas informações podem não se tornar tão confidenciais
assim. Por exemplo, os "browsers" normalmente mantém caches locais de

14. 14
visitas efetuadas pelos usuários a servidores Web que podem revelar alguns
"hábitos" deste usuário.
Negação de Serviço
Esta é uma das mais sérias ameaças na Web e a mais difícil de
prevenir. Este tipo de ataque consiste em ações maliciosas que desviam
acessos a um determinado serviço que se encontra disponível. Web spoofing é
um exemplo típico deste tipo de ataque, acessos feitos a determinado servidor
Web são desviados para um outro servidor, normalmente um clone.
Veja o exemplo abaixo:
Suponha que um competidor de uma empresa X deseja "roubar"
informações ou parte das transações da empresa Y. A empresa Y tem um
servidor Web: com IP: 1.2.3.4. O competidor que tem um servidor Web com
aparência idêntica a do primeiro e envia (fazendo "spoofing" no DNS) o
endereço IP 5.6.7.8( de sua empresa, Y).
O usuário 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
transações e não percebe que efetuou a compra em um site falso ou
simplesmente, este site informa preços elevados, o que faz o usuário procurar
a empresa concorrente da empresa X (a própria empresa "intrusa" neste caso).
Autenticação
Neste caso, o atacante se faz passar por outro, obtendo a senha do
usuário por algum método qualquer, como por exemplo, filtrando pacotes na
rede e capturando senhas não criptografadas.
Segurança no Servidor
Em um ambiente cliente/servidor as atenções normalmente estão
direcionadas para o servidor, onde residem as informações e, portanto, foco de
ameaças. Os clientes na Web estão fora de nossa guarda e assim fora do
nosso controle. A proteção do cliente, não é o grande objetivo, a não ser
quando se trata de sua privacidade. Segurança no servidor Web consiste, em
geral, em um ponto crítico em relação para algumas organizações que tem a
Web a sua principal fonte de renda.
Os assuntos de segurança tratados aqui são direcionados ao servidor
Apache em ambiente Unix por ser o mais utilizado na Internet. Mas, a maioria
das recomendações, tópicos, sugestões, etc. mencionada é válida para outros
servidores Web.
Configurações Básicas
Um dos maiores problemas de segurança, assim como com outros
serviços de rede, é o mau gerenciamento. Sistemas distribuídos com uma má
configuração pode significar um desastre. Sistemas crescem e também

15. 15
crescem em sua complexidade. Se não se tem uma boa configuração torna-se
difícil o emprego de uma política de gerenciamento satisfatória.
Como são organizadas estas configurações?
Arquivos de configurações contêm diretivas que são tratadas pelo
daemon httpd. Estas diretivas controlam o comportamento de funções do
servidor, como: controle de acesso a páginas (nomes e senhas),
disponibilização 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 consideração: saiba o que já
vem previamente configurado em seu servidor ao instalá-lo; comente (iniba) o
desnecessário e conheça bem o que você tem configurado em seu servidor
Web; configure seu servidor para tratar acessos indevidos; não se esqueça de
checar seus logs constantemente, etc.
Estrutura de Diretórios
A estrutura hierárquica de diretórios de um servidor Web é composta de
dois diretórios.
Os diretórios:
Raiz do servidor: tem informações de controle do servidor, como:
arquivos de configurações, aplicações adicionais, etc.
Raiz de Documentos (o Web space do servidor): contém o conteúdo
"público" (informações disponibilizadas via conexões HTTP). Geralmente este é
um sub-diretório do diretório raiz do servidor.
Ao se "disparar" um servidor Web, todas as informações abaixo da raiz
do diretório de documentos poderão ser disponibilizadas publicamente a menos
que se tenha alguma restrição de acesso. Um dos erros mais comuns é se
executar o servidor Web como "root", o que trás algumas vulnerabilidades para
seus sistemas. Uma solução muitas vezes adotada é rodar o servidor Web
como usuário "nobody", que também trás vulnerabilidades. Algumas aplicações
também podem estar sendo executadas como "nobody" e portanto o servidor
Web passa a ter seus mesmos privilégios. Uma boa estratégia é criar um
usuário qualquer (e também um grupo) específico para o servidor Web
(exemplos: web, www, webserver, etc...). Assim, acessos ao sistema de
arquivo serão restringidos a este usuário, e também eventuais ataques feitos
ao servidor também seriam afetados ao usuário Web específico do servidor.
Server-Side Include (SSI)
SSI é um código HTML que "injeta" a saída de um comando ou um
arquivo dentro da página quando enviada pelo servidor para o browser. A
formatação HTML é um conteúdo estático, SSI é um conteúdo dinâmico.
SSIs são bastante úteis, mas podem também ser "caros"
computacionalmente, acabam com a portabilidade e podem abrir sérios furos
de segurança. Se esta funcionalidade não é necessária para o seu servidor, é
melhor desabilitá-la.

16. 16
Autenticação
Em geral, serviços Web são muito dependentes de servidores de nomes.
Se um servidor de nome é atacado, servidores Web dependentes deste serviço
podem ter sua autenticação comprometida.
Autenticação Básica
Um serviço que provê autenticação básica utiliza a identificação do
usuário (username) e a senha, que passa as claras (sem criptografia) pela
rede. No máximo, em alguns casos, alguns pequenos "mascaramentos" são
utilizados como o redirecionamento para uuencode do Unix. Algumas restrições
de acesso podem ser utilizadas via arquivo .htaccess. Este arquivo contém
diretivas, palavras chaves que norteiam o acesso do httpd.
Uma vez autenticado, temos a autorização. Existem dois tipos de
autorização: por diretório e por servidor.
Por diretório, significa restrição de acesso a um determinado diretório
dentro de sua árvore do seu web space.
Autorizações por servidor somente muda a localização das diretivas,
agora definidas no servidor, que podem ser sobrepostas por outras por
diretório.
Digest Authentication
Diferentemente do que ocorre em Autenticação Básica, em DA a senha
não passa pela rede as claras. A comunicação entre as partes envolvidas,
neste esquema, contém um checksum, por default MD5, o username, a senha,
o método HTTP, e um autenticador único (geralmente um número randômico
longo), além da URL requisitada. O objetivo é melhorar a segurança de senhas.
CGI Scripts
Quase todo servidor Web que se visita utiliza algum tipo de conteúdo
ativo. Common Gateway Interface (CGI), é um tipo de matalinguagem ou
middleware, que permite a interoperabilidade requerida por este conteúdo. É
um mecanismo independente de plataforma provido pelo servidores Web que
permitem executar programas/scripts a partir de uma URL. Estes scripts são
geralmente escritos em Perl, Shell, Tcl, Java, Python ou C (maioria escritos em
linguagem interpretadas) e localizados normalmente em um diretório /cgi-bin.
Aplicações CGI escritas sem cuidados com segurança podem causar
sérios problemas a vulnerabilidades de servidores Web.
Um CGI script sendo executado sob o mesmo UID do servidor Web não
é necessariamente um fato ruim, mas se alguma aplicação CGI possui um furo
de segurança que permite que um atacante execute programas sob UID do
servidor Web, isso pode acarretar um problema bastante sério 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 usuários escrevem independentemente
aplicações CGI, é uma boa estratégia isolá-los um dos outros, isto é,
implementar mecanismos em seu servidor de maneira que acessos de scripts
de um usuário não venham a interferir em dados de outros usuários. A

17. 17
ferramenta suEXEC, resolve este problema (existem outras ferramentas que
também tratam este problema) fazendo com que aplicações CGIs sejam
executadas sob o UID do próprio usuário, isto é, o dono da aplicação CGI.
5. CONCLUSÃO
Pudemos, com esse trabalho por em pratica o conhecimento adquirido
ao longo do semestre, como a criação de um cronograma e a elaboração de
um gráfico de Gantt. É muito interessante que, ao desenvolvermos esse
trabalho, visando a pré-produção de um software pudemos relembrar
conteúdos que vimos desde o inicio do curso, e empregamos com
funcionalidade e objetividade.

18. 18
6. Referências
ABBAGNANO, N. Dicionário de Filosofia. Trad. de Alfredo Bosi (Org.). São
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.