SISTEMA DE ENSINO À DISTÂNCIA - UNOPAR

PROGRAMA DE GRADUAÇÃO

UNOPAR

PRODUÇÃO TEXTUAL INTERDICIPLINAR

Cidade

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

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

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

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

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

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

1 VocêAluga1.1 Iniciação1.1.1 Necessidade / Oportunidade1.1.2 Escopo geral1.1.3 Objetivos1.1.4 Premissas e restrições1.1.5 Principais Stakeholders1.1.6 Identificação dos riscos1.1.7 Estimativa de prazo1.1.8 Estimativa de custo1.2 Planejamento1.2.1 Cronogramas1.2.2 Atividades Interdependentes1.2.3 Alocação de Recrsos1.2.4 Análise de Custos1.2.5 Comunicação1.2.6 Qualidade1.2.7 Riscos1.2.8 Suprimentos1.2.9 Recursos Humanos1.3 Execução1.3.1 Verificação do Escopo1.3.2 Mudanças de Escopo1.3.3 Design1.3.4 Desenvolvimento do Sistema1.3.5 Testes Via Prototipação1.3.6 Revisão1.3.7 Publicação1.4 Controle1.4.1 Tempo1.4.2 Custo1.4.3 Qualidade1.4.4 Risco1.4.5 Ações Corretivas e Preventivas1.4.6 Detecção de Anormalidades1.5 Entrega1.5.1 Avaliação Interna ou Externa1.5.2 Discussção das Falhas1.5.3 Aceitação do Projeto1.5.4 Manutenção

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 diasQua 21/05/14

Sex 06/06/14

Equipe

Reunião 7 diasQua 21/05/14

Sex 23/05/14

Equipe

Coleta de dados 7 diasQua 21/05/14

Sex 23/05/14

2II Paulo

Definição de provedor 7 dias Qui Seg 3TT Paulo e Julia

10

22/05/14 26/05/14

Definição de escopo 14 diasSex 23/05/14

Sex 30/05/14

4 Julia

Alocação de recursos 14 diasTer 27/05/14

Ter 03/06/14

5 Julia

Analise de custos riscos e suprimentos

14 diasTer 27/05/14

Ter 03/06/14

6II Equipe

Definição dos prazos e cronograma

21 diasQua 28/05/14

Sex 06/06/14

7 Paulo

Execução 45 diasSeg 02/06/14

Ter 24/06/14

8 Fernanda e João

Criação do design 14 diasSeg 02/06/14

Seg 09/06/14

Fernanda

Criação de diagramas de classe

14 diasTer 03/06/14

Ter 10/06/14

10 João

Criação do banco de dados

21 diasQui 05/06/14

Seg 16/06/14

11 João

Criação código 30 diasSex 06/06/14

Seg 23/06/14

12 Fernanda

criação de folha de estilos

21 diasTer 10/06/14

Qui 19/06/14

13TT João

Revisão 21 diasSex 13/06/14

Ter 24/06/14

14 Fernanda e João

Prototipação 21 diasSex 06/06/14

Ter 17/06/14

11 Fernanda

Entrega/Publicação 7 diasSeg 16/06/14

Qua 18/06/14

16 Equipe

Entrega 17,67 diasSeg 16/06/14

Ter 24/06/14

17 Paulo

Avaliação Interna ou Externa

7 diasSeg 16/06/14

Qua 18/06/14

Julia

Discussão de falhas 14 diasTer 17/06/14

Ter 24/06/14

19Paulo, Julia, João e Fernanda

Aceitação do Projeto 7 diasQui 19/06/14

Seg 23/06/14

20 Cliente

Manutenção 7 diasSex 20/06/14

Ter 24/06/14

21 João e Fernanda

Controle 43,33 diasSeg 02/06/14

Ter 24/06/14

Paulo, Julia, João e Fernanda

Analise do tempo 14 diasSeg 02/06/14

Seg 09/06/14

João e Paulo

Analise dos custos 14 diasSeg 02/06/14

Seg 09/06/14

24II Julia

Riscos 21 diasSeg 02/06/14

Qua 11/06/14

25II Julia

controle de qualidade 30 diasSeg 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

anomalias 09/06/14 24/06/14 e Fernanda Ações preventivas e corretivas

30 diasSeg 09/06/14

Ter 24/06/14

28II Julia

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

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

- 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

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

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

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

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

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 RationalA.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.