CURSO SUPERIOR DE TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE

SITEMAS
Portflio Individual 5 Semestre




PROJETO DE SOFTWARE


Nome

Willas Mar Gonzaga Silva

Professores

Adriane A. Loper
Luis C. Perini
Marco I. Hisatomi
Paulo K. Nishitani
Veronice de Freitas





Janaba MG
2013
WILLAS MAR GONZAGA SILVA





PROJETO DE SOFTWARE






Portflio individual apresentado UNOPAR
Universidade Norte do Paran, como requisito parcial
para obteno do ttulo de Analise e Desenvolvimento de
Sistemas.
Profs.: Adriane A. Loper, Luis C. Perini, Marco I.
Hisatomi, Paulo K. Nishitani, Veronice de Freitas.












Janaba MG
2013
Sumrio


Introduo .......................................................................................................... 4
Objetivo .............................................................................................................. 6
Estudo de Caso Locadora de Carros ................................................................. 7
Ciclo de Vida ................................................................................................... 7
WBS Work Breakdown Structure ................................................................. 9
Cronograma .................................................................................................... 9
Concluso ........................................................................................................ 20
Referncias ...................................................................................................... 21


1 Introduo


Sommerville (2003, p. 62) j comentava sobre o gerenciamento de um projeto
de software onde que O gerenciamento eficaz de um projeto de software depende
de um planejamento acurado do andamento do projeto.
Hoje estamos em um mercado competitivo e corrido.Em todas as reas no
mercado de trabalho ns encontramos pessoas que possui pouco tempo sobrando
para dedicar-se qualidade do seu servio. Se pararmos para simplesmente olhar
um nico ponto, enfatizando que devemos focar em apenas um nico objetivo, com
certeza iremos ser esmagados pela correnteza de turbilhes da vida em um
mercado to amargo. Deixando assim de lado a concentrao e observao de
longo prazo, para nos aderir a rpidas decises e difceis concluses de ideias
necessrias para a nossa realizao pessoal e empresarial.
Sommerville (2003. P. 84) disse que Em princpio, a especificao de
requisitos funcionais de um sistema deve ser completa e consistente.
No devemos simplesmente deixar as coisas passarem sem ao menos nos
preocuparmos com o amanh, e forcarmos apenas no hoje, pois precisamos nos
precaver para no vermos nossos sonhos se desmoronarem na nossa frente como
uma montanha de neve se despencando em meio ao vo. Para isso em um mercado
de trabalho to exigente e difcil existe meios de elaborar projetos mais confiveis e
de boa qualidade. Um projeto no apenas uma palavra forte e admirvel para ser
dita e apreciada por profissionais e clientes, mas um caminho para ser seguido e
fortemente enriquecido com o intuito de alcanar a to sonhada qualidade.
O sistema uma caixa-preta cujo comportamento somente pode ser
determinado estudando-se suas entradas e sadas relacionadas (Sommerville ,
2003, p. 378, grifo do autor).
O foco no est na perfeio, pois ns humanos j somos perfeitos, em
cima disso indago que o objetivo est nas mudanas. Desde o inicio o mundo veio
mudando, ns evoluindo, e o tempo passando, por isso preciso perseverana e
no atirar pedras no escuro. Ns sabemos que o tempo curto, e demora muito
para nos tornamos quem queremos ser. Devemos pensar no hoje, de tal forma que
reflita no amanh, sem perder o senso de espao e realidade. Pois a dificuldade
est naquilo que no foi planejado, afinal se algo pode ser previsto tambm pode ser
concretizado!

2 Objetivo


O projeto deve ter um inicio, meio e fim bem definidos, no importando o
tamanho ou a dificuldade do mesmo. Tarefas e atitudes devem ser pensadas,
devem ser esculpidas, analisadas minuciosamente. Em um projeto simples, como a
construo de uma pgina web, podemos usar etapas bem definidas e de fcil
elaborao. Um ciclo de vida deve ser escolhido, pois precisamos saber como
iremos proceder no decorrer do projeto, ou seja, o que faremos a cada processo.
Podemos tambm construir uma WBS Work Breakdown Structure com o intuito de
analisar o que ser feito em cada etapa do nosso ciclo de vida, mas com tudo isso
cobrado tambm um cronograma, pois os clientes querem datas definidas.
O objetivo desse projeto pesquisar e analisarum possvel sistema em uma
plataforma web que atenda as necessidades de uma empresa de locao de carros.
Irei abordar o ciclo de vida adequado para consecuo das etapas, com o objetivo
de colher informaes necessrias que se faam entender o que o cliente deseja.
Com os requisitos j levantados construirei uma WBS para controlar as aes dos
integrantes do projeto. Essa WBS ir auxiliar na execuo de cada etapa do ciclo de
vida. Um cronograma preciso, pois datas so marcadas e preciso ser cumpridas.
O cronograma apenas para manter os analistas, gerente e programadores
atualizados e equilibrados perante o tempo, afinal necessrio um foco, algo que
mantenha a capacidade de cumprir prazos e horrios.

3 Estudo de Caso Locadora de Carros

3.1 - Ciclo de Vida


A melhor abordagem para um determinado projeto depende, em grande parte,
da natureza do projeto e da natureza da organizao. A escolha de um ciclo de vida
errado pode atrasar a entrega do sistema ou at concluir um trabalho mau feito, por
isso preciso analisar os requisitos da organizao onde se vai prestar o servio
para desenvolver o software. Partindo para a prtica, a prototipagem funciona
melhor para projetos de pequeno e mdio porte. Ela funciona bem onde a cultura
suporta equipes funcionalmente mistas. A prototipagem pode ser combinada com a
abordagem em espiral e ser usada para um ou mais dos subprojetos em um
desenvolvimento em espiral.

A prototipagem descreve uma abordagem que tenta satisfazer as
necessidades do usurio focalizando a interface do usurio. Os estgios do projeto e
de desenvolvimento, no que concerne interface de usurios, repetem-se at que o
usurio esteja satisfeito. A figura abaixo ilustra isso:

Como se pode ver no diagrama existem seis processos bsicos que podemos
usar no decorrer do projeto. Nota-se tambm que em uma parte do projeto, graas
s funcionalidades do ciclo de vida em prototipagem, podemos voltar no incio do
processo, ou seja, no levantamento das necessidades, ou na segunda fase do
processo, que a analise de alternativas. Como os envolvidos no projeto so
extremamente ocupados, conseguindo apenas 3 horas semanais para se dedicarem
ao desenvolvimento do software, utilizando esse ciclo de vida conseguiremos, com o
pouco de tempo de reunio, obter bons resultados positivos.Pois o contato ser
diretamente com os usurios, podendo nos informar rapidamente alguma dvida ou
insatisfao. Como os requisitos j so conhecidos, s ns restar obter dados
baseados no conhecimento emprico de cada usurio. Com o desenvolvimento WEB
poderemos mostrar e fazer testes onde estivermos, basta possuir as ferramentas
necessrias. E o mais importante, com esse ciclo de vida os desenvolvedores do
sistema podem interagir juntamente com o ciclo de vida em espiral, como foi dito no
incio do texto. No ciclo de vida em espiral poderemos reservar uma verso teste
para os clientes, e receberemos o feedback atravs do e-mail. Mantendo contato
com os clientes, sempre os informaremos quando a atualizao estiver pronta, e
antes de coloca-la para funcionar, basta usar um prottipo para fazer o teste e
aplicar os procedimentos do ciclo de vida prototipao.


3.2 - WBS Work Breakdown Structure


Antes de observar a WBS preciso ter uma ideia do que ela , e para quela
serve. Segundo definies do Guia PMBOKWBS o processo de subdiviso das
entregas e do trabalho do projeto em componentes menores e de gerenciamento
mais fcil. A WBS uma decomposio hierrquica orientada s entregas do
trabalho a ser executado pela equipe para atingir os objetivos do projeto e criar as
entregas requisitadas, sendo que cada nvel descendente da WBS representa uma
definio gradualmente mais detalhada da definio do trabalho do projeto. A WBS
organiza e define o escopo total e representa o trabalho especificado na atual
declarao do Escopo do projeto aprovado. O trabalho planejado contido dentro
dos componentes de nvel mais baixo da WBS, que so chamados de pacotes de
trabalho. Um pacote de trabalho pode ser agendado, ter seu custo estimado,
monitorado e controlado. No contexto da WBS, o trabalho se refere a produtos de
trabalho ou entregas que so resultado do esforo e no o prprio
esforo.PMOBOK, Um guia do Conhecimento em Gerenciamento de
Projetos(Guia PMBOK) Quarta Edio, PMI Project Management Institute,
ISBN: 978-1-933890-70-8. Segue abaixo a WBS:



Essa WBS apenas a primeira analise, com o decorrer do projeto ir surgir
novas ideias que sero acrescidas na mesma. Uma WBS deve ser simples e ao
mesmo tempo robusta, ou seja, que no seja grande e nem complexa demais para
confundir os envolvidos no projeto, mas que seja precisa o suficiente para capturar
todas as etapas que devem ser cumpridas. Aps seguirmos os passos acima,
teremos uma primeira verso da WBS. Esta WBS ser utilizada como entrada para o
planejamento de outras reas do gerenciamento do projeto. Depois que concluirmos
o projeto, teremos os relatrios referentes a cada fase do processo que seguirmos,
isso no futuro nos levar a repensar se devemos mudar a WBS, acrescentar,
modificar ou retirar alguns passos desnecessrios. Acredito que com esse diagrama
simples seremos capazes de pelo menos nos familiarizar com o projeto, afinal
resultados negativos tambm so aceitos quando se trata de mudanas e
melhoramento, pois em cima deles que iremos aprender.


3.3 - Cronograma


Cronograma uma maneira de colocar as etapas do projeto de maneira
cronolgica, ou seja, de uma forma que podemos segui-las,obedecendo s datas
especificas para cumpri-las. A vantagem de um cronograma o fato do gerente de
projeto poder manter a palavra com os seus clientes, afinal a coisa mais
perturbadora para um usurio receber seu produto fora de data. Entregar o que foi
prometido fora do tempo, s vezes at muito atrasado, constrangedor para os
responsveis pelo desenvolvimento do sistema.
O cronograma a seguir ser montado levando em conta as etapas do ciclo de
vida e da WBS, mostrarei etapa por etapa. Ele foi montado na ferramenta CASE
GanttProject. Como comenta Heldman (2002, p. 213) fcil ler os grficos de
Gantt, usados, na maioria das vezes, para agendar atividades. Dependendo do
software utilizado para ger-lo, esse grfico tambm pode exibir sequencias e as
datas de inicio e fim das atividades, alocaes de recursos, dependncias das
atividades e o caminho crtico.

Levantamento das Necessidades: a fase onde ser analisado os
requisitos para proceder no desenvolvimento do sistema. Coletar a partir de
entrevista com os clientes toda a informao para elaborar o plano de projeto.

Anlise de Alternativas: a fase onde ser analisado as regras de negcios
da empresa aplicadas ao sistema.


Projeto: nesta fase ser elaborado e mostrado os relatrios obtidos com as
pesquisas tcnica, capacidade, plataforma, configurao, etc.


Desenvolvimento: onde comeamos a trabalhar em cima dos dados obtidos
transformando-os em resultados concretos, partindo da teoria para a prtica.

Implementao: partiremos para a fabricao do prottipo do nosso sistema
com o objetivo demostra ao cliente e obter uma resposta rpida.


Manuteno: essa fase a ltima e a mais importante do nosso projeto, pois
aqui que concluiremos todas as etapas finalizando com teste e aprovaes.


Para um gerente inexperiente elaborar um cronograma pode ser uma das
coisas mais difceis em seu comeo de carreira, afinal ele no possui ainda
nenhuma ideia de prazos, isso pode acarretar em prazos maus definidos, por isso
ideal sempre analisar e rever o cronograma.








4 USABILIDADE PARA DESENVOLVIMENTO WEB

Usabilidade um termo usado para definir a facilidade com que as
pessoas podem empregar uma ferramenta ou objeto a fim de realizar uma tarefa
especfica e importante. A usabilidade pode tambm se referir aos mtodos de
mensurao da usabilidade e ao estudo dos princpios por trs da eficincia
percebida de um objeto.
Na Interao Humano-computador e na Cincia da Computao,
usabilidade normalmente se refere simplicidade e facilidade com que
uma interface, um programa de computador ou um website pode ser utilizado. O
Termo tambm utilizado em contexto de produtos como aparelhos eletrnicos, em
reas da comunicao e produtos de transferncia de conhecimento, como manuais,
documentos e ajudas online. Tambm pode se referir a eficincia do design de
objetos como uma maaneta ou um martelo.
Um aspecto de usabilidade a ser desenvolvido para a locadora de
veculos a barra de menu principal na horizontal, facilitando o acesso do usurio a
todo os servios disponveis no website, com uma linguagem simples e direta sem
abreviaes ou jarges desnecessrios, um menu feito utilizando se da tecnologia
de CSS e HTML 5.


5 SEGURNA WEB

Cross-site scripting (XSS) um tipo de vulnerabilidade do sistema
de segurana de um computador, encontrado normalmente em aplicaes web que
activam ataques maliciosos ao injectarem client-side script dentro das pginas web
vistas por outros usurios. Um script de explorao de vulnerabilidade cross-site
pode ser usado pelos atacantes para escapar aos controles de acesso que usam a
poltica de mesma origem.
Atravs de um XSS, o Cracker injeta cdigos JavaScript em um
campo texto de uma pgina j existente e este JavaScript apresentado para outros
usurios, porque persiste na pgina.
Exemplo de ataque: Imaginem que o cracker insira em um frum de
um website alvo de ataque, um texto que contenha um trecho de JavaScript. Este
JavaScript poderia, por exemplo, simular a pgina de login do site, capturar os
valores digitados e envi-los a um site que os armazene. Quando o texto do frum
for apresentado a outros usurios, um site atacado pelo XSS exibir o trecho de
JavaScript digitado anteriormente nos browsers de todos os outros usurios,
provocando a brecha de ataque.
O invasor envia um script para o servidor:<script>malicious.js... =
SYN onde o servidor recebe o script e interpreta uma nova pgina inserindo o cdigo
como resposta da requisio ao atacante = SYN/ACK.
Por fim o atacante recebe a resposta em seu browser = ACK.
No existe uma classificao nica, padronizada de falhas de cross-
site scripting, mas a maioria dos especialistas distinguem pelo menos dois tipos
principais de XSS: no persistentes e persistentes. Algumas fontes dividem ainda
mais estes dois grupos em tradicional (causada por falhas de cdigo do lado do
servidor) e baseadas em DOM (no cdigo do lado do cliente).

No-persistente:

A vulnerabilidade cross-site scripting no persistente (ou refletida)
de longe o tipo mais comum. Estas falhas aparecem quando os dados fornecidos
por um cliente web, mais comumente em parmetros de consulta HTTP ou envios de
formulrios HTML, imediatamente utilizado pelos scripts do lado do servidor para
analisar e exibir uma pgina de resultados de e para o usurio, sem a limpeza
adequada do pedido. Como os documentos HTML tm uma estrutura plana e serial
que mistura instrues de controle, formatao e contedo real, todos os dados
fornecidos pelo usurio, no validados includos na pgina resultante sem
codificao HTML adequada, pode levar a injeo de marcao.
Um exemplo clssico de um potencial vetor um site com
mecanismo de busca: se algum procura por uma frase, a frase de busca
normalmente ser reexibida na ntegra na pgina de resultado para indicar que foi
procurado. Se essa resposta no for devidamente tratada ou rejeitar os caracteres
de controle de HTML, uma falha de script cross-site ir se aproveitar dessa resposta.
Um ataque refletido normalmente entregue via e-mail ou um site neutro. A isca
uma URL de aparncia inocente, apontando para um site confivel, mas contendo o
vetor de XSS. Se o site confivel vulnervel ao vetor, clicar no link pode fazer com
que o navegador da vtima execute o script injetado.

Persistente

A vulnerabilidade XSS persistente (ou armazenados) uma variante
mais devastadora de uma falha de script cross-site: ocorre quando os dados
fornecidos pelo atacante so salvos pelo servidor e, em seguida, exibidos em
pginas "normais" retornadas para outros usurios no curso de uma navegao
normal, sem HTML adequada.
Um exemplo clssico disso com fruns online onde permitido
enviar mensagens formatadas em HTML para que outros usurios possam ler.Por
exemplo, suponha que exista um site de namoro, onde os membros verificam os
perfis de outros membros para ver se eles parecem interessantes. Por razes de
privacidade, este site esconde o verdadeiro nome e e-mail de todos. Estes so
mantidos em segredo no servidor. A nica vez que o verdadeiro nome e e-mail de
um membro exibido no navegador quando o membro est logado, e eles no
podem ver os dados de mais ningum. Suponha que Mallory, um atacante, se
cadastra no site e quer descobrir os verdadeiros nomes das pessoas que ela v.
Para isso, ela escreve um script projetado para rodar nos navegadores das outras
pessoas quando visitam seu perfil. O script ento envia uma mensagem rpida para
o seu prprio servidor, que recolhe esta informao. Para fazer isso, para a pergunta
"Descreva o seu primeiro encontro ideal", Mallory d uma resposta curta (parece
normal), mas o texto no final da sua resposta seu script para roubar nomes e e-
mails. Se o script colocado dentro de um elemento <script>, no ser mostrada na
tela. Ento, suponha que Bob, um membro do site de namoro, chega no perfil de
Mallory, que tem a resposta para a pergunta de primeiro encontro. Seu script
executado automaticamente pelo navegador e rouba uma cpia do verdadeiro nome
e e-mail do Bob diretamente de sua prpria mquina.
XSS persistente pode ser mais significativo do que outros tipos
porque o script malicioso de um atacante processado automaticamente, sem a
necessidade de orientar as vtimas individualmente ou atra-los para um site de
terceiros. Particularmente no caso de sites de redes sociais, o cdigo seria mais
projetado para se auto-propagar atravs de contas, criando um tipo de verme do
lado do cliente. [14] Os mtodos de injeo podem variar muito, em alguns casos, o
atacante no precisa nem mesmo interagir diretamente com a funcionalidade web
para explorar esta vulnerabilidade. Todos os dados recebidos pela aplicao web
(via e-mail, logs de sistema, IM, etc), que podem ser controlados por um invasor
podem se tornar um vetor de injeo.
Exemplo de XSS persistente Uma vulnerabilidade persistente
multiplataforma cross-scripting juntamente com um worm de computador permitiu a
execuo de um cdigo arbitrrio e a listagem do contedo do sistema de arquivos
atravs de um filme QuickTime no MySpace.

Proteo

Apesar de vrias ocorrncias de XSS e das diferentes formas de
explorao, impedir a prpria vulnerabilidade conceitualmente simples. O que a
torna problemtica na prtica a dificuldade de identificar todos os campos da
aplicao onde h dados manipulados pelo usurio e que sero posteriormente
exibidos em tela. A causa do XSS refletido e persistente que estes dados so
inseridos em respostas da aplicao sem validao. Para eliminar tais
vulnerabilidades, o primeiro passo identificar todas as instncias dentro da
aplicao em que os dados so colocados nas respostas das requisies. Uma vez
identificados os locais destes dados, necessrio realizar os seguintes
procedimentos:
Validao de Entrada
Validao de Sada

Validao da entrada

Este o momento em que a aplicao recebe os dados fornecidos
pelo usurio, que podem ser apresentados em respostas futuras. necessrio que a
aplicao realize uma validao dentro do contexto daquele contedo, tornando-o
mais restrito possvel, por exemplo:
Limitando o tamanho do campo a ser inserido
Definindo o conjunto de caracteres aceito pela aplicao
Estabelecendo uma expresso regular para os dados
Estas regras de validaes variam de acordo com o campo e com o
contexto da aplicao, por exemplo, nomes, endereos de e-mails, nmeros de
contas e cartes, ou seja, de acordo com o tipo de informao, espera-se um
formato pr-determinado de contedo.

Validao da Sada

Agora a vez da aplicao copiar em suas respostas os dados que
originados por algum usurio ou at mesmo por terceiros. Estes dados devem ser
codificados em HTML para tratar potenciais caracteres maliciosos. Codificao em
HTML a tcnica de substituir os caracteres literais pela sua entidade HTML
correspondente. Isto garante que o navegador, browser, ir exibir, como sada, tais
caracteres de forma segura, tratando-o como parte do documento HTML e no da
sua estrutura. Alguns deste caracteres so:
" &quot;
' &apos;
& &amp;
< &lt;
> &gt;
Os caracteres tambm podem ser representados por seu cdigo
correspondente na tabela ASCII:
% &#37;
* &#42;
H algumas funes que fazem a codificao automaticamente para
o desenvolvedor:
PHP htmlspecialchars(), htmlentities()
ASP.NET Server.HTMLEncode()
Segue um exemplo de cdigo Java que faz o tratamento de
caracteres especiais, podendo sua lgica ser aplicada a outra linguagem de
programao:
public static String HTMLEncode(String s) {

StringBuffer out = new StringBuffer();

for (int i = 0; i < s.length(); i++) {
char c = s.charAt(i);

if(c > 0x7f || c== || c==& || c==< || c==>)
out.append(&# + (int) c + ;);
else out.append(c);

}
return out.toString();

}
O ideal que a aplicao combine ambas as tcnicas, oferecendo
assim, duas camadas de proteo, diminuindo as chances do invasor conseguir
burlar os filtros utilizados.































6 - Concluso


Conclumos que em um projeto preciso definir tarefas e etapas bem
detalhadas para a consecuo do sistema. Quando escolhemos um ciclo de vida
devemos analisar em primeiro lugar o tipo de sistema que iremos fornecer ao cliente,
o ambiente de trabalho para os envolvidos no projeto. As etapas do ciclo de vida
devem ser respeitadas para que no ocorram erros sutis, como atrasar ou construir
alguma ferramenta de mau funcionamento. Uma WBS primordial para separar as
etapas dentro de um ciclo de vida. Apenas com um ciclo de vida no possvel
saber o que se vai fazer em seguida, nesse momento que elaboramos uma WBS
com o intuito de esquematizar fases para etapas, processos mais detalhados em
relao ao projeto. Entende-se que um cronograma onde definimos as nossas
datas, os prazos de entrega e de consecuo dos processos envolvidos na WBS.
No precisamos de pressa, precisamos apenas de qualidade. Com todo um
esquema bem bolado podemos manter a palavra com os clientes, sem perder o foco
do projeto. Em cada fase do ciclo de vida os envolvidos no desenvolvimento do
sistema se dedicaro apenas a sua tarefa, apenas aquilo que lhe foi passado para
fazer, pois isso evita uma sobrecarga de servio.

7 - Referncias


Heldman (2002, p. 213).

PMOBOK, Um guia do Conhecimento em Gerenciamento de Projetos (Guia
PMBOK) Quarta Edio, PMI Project Management Institute, ISBN: 978-1-
933890-70-8.

Sommerville (2003, p. 62).

Sommerville (2003. P. 84).

Sommerville (2003, p. 378, grifo do autor).

http://pt.wikipedia.org/wiki/Cross-site_scripting
-----------------------------------------------------------------------------------------------------------------
ITEM (4) - http://falpcar.comze.com/ SITE ALUGUEL CARROS Menu
http://www.inf.puc-rio.br/~inf1403/docs/luciana2013_1/3WB-Aula23.pdf

ITEM (5) SEGURANA DA WEB
http://www.redesegura.com.br/2012/01/saiba-mais-sobre-o-cross-site-scripting-xss/