SUMRIO

INTRODUO
Objetivos
1

Ciclo de Vida do Software

1.1

Ciclo de Vida Iterativo-Incremental

1.1.1

Vantagens:7

1.1.2

Desvantagens:

1.2
2

WBS do Projeto: o que ?

WBS Texto

2.2

WBS Imagem

9
10

Cronograma do Projeto

11

3.1

Cronograma em Texto

3.2

Cronograma em Grfico de GANTT

11

Anlise de Usabilidade

Anlise de Segurana Web 15

5.1
6

13

Cuidados com Autenticao: SSL 16

CONCLUSO 17

BIBLIOGRAFIA

Motivos da escolha deste ciclo

2.1
3

18

12

INTRODUO
Um Projeto de Sistemas demanda um trabalho de anlise mui
elaborado, profundo e detalhado, pois somente com esse cuidado no planejamento
o produto final traz as qualidades necessrias para destacar-se no mercado
competitivo atual.
Ainda mais quando falamos em aplicao Web, pois pelo fato de o
desenvolvimento Web ser tecnicamente mais fcil, existem mais pessoas com baixo
nvel de capacitao produzindo aplicaes, o que resulta em um cenrio mal
planejado, com problemas de estrutura, usabilidade, segurana, e at projetos no
concludos, exatamente por falta de planejamento.
O nico meio de debelar essa cultura do meia-boca, a educao;
e com essa finalidade que ser desenvolvido este trabalho.

OBJETIVOS
O objetivo deste trabalho, alm de dar continuidade na proposta de
integrao interdisciplinar do Portfolio da Unopar, desenvolver um Projeto de
Sistemas com o uso das matrias estudadas este semestre, como Programao
Web, Interface Humano-Computador, e mesmo gerenciamento de projetos, de uma
forma mais prtica.
Atravs de um estudo de caso, e aplicando as teorias estudadas, ser
escolhido um Ciclo de Vida para controle do projeto de Software. Na sequncia,
sero elaborados alguns documentos auxiliares do projeto, como a WBS (Work
Breakdown Structure) ou EAP (Estrutura Analtica do Projeto), e o Cronograma, com
sua visualizao em grfico de Gantt.
A seguir, sero apresentados os conceitos de IHC (Interface HumanoComputador) e Usabilidade, e aplicados ao estudo deste caso.
Ser considerada a segurana do aplicativo no que diz respeito
autenticao de criptografia dos dados da conexo, bem como sero apresentados
alguns riscos inerentes s aplicaes Web.
De todas estas formas, aplicaremos a teoria em um caso prtico para
possibilitar o melhor entendimento das matrias estudadas visualizando-as no mudo
real.

1 CICLO DE VIDA DO SOFTWARE

Todo projeto de Desenvolvimento de Software, quando bem
orientado, necessita da definio de um modelo de SLDC Software Development
Life Cycle, ou Ciclo de Vida de Desenvolvimento de Software, em traduo livre.
A necessidade do entendimento e da aplicao desse conceito parte
do fato de que o desenvolvimento de um software um projeto, com incio, meio e
fim, complexo, e com problemticas prprias, no existentes em outros tipos de
projeto, como por exemplo o projeto de uma construo civil, onde a planta j define,
desde o incio, como ficar o produto final.
Em um Software, existe notadamente o problema de redefinio de
escopo e requisitos, que gera dificuldade na medio da produtividade, e na
previso dos prazos de entrega.
O SLDC se prope a formalizar algumas fases de projeto, normas e
procedimentos que facilitaro o controle, a previsibilidade de prazos e o trabalho em
equipe para solucionar os problemas do projeto.
1.1 CICLO DE VIDA ITERATIVO-INCREMENTAL
Para este projeto foi escolhido como SLDC o Ciclo IterativoIncremental, uma derivao do modelo Cascata, muito utilizada pelas metodologias
geis de programao, como XP, Agile, RUP.
Este modelo foi criado para resolver os problemas do modelo
Cascata, tido como muito burocrtico e pouco flexvel, visto que no modelo Cascata
o Levantamento de Requisitos, Anlise de Requisitos, Projeto, Implementao e
Testes, so executados uma nica vez.
J no modelo Iterativo Incremental, o projeto dividido em ciclos, e
em cada ciclo ocorrem as fases de levantamento, anlise, projeto, implementao e
testes, de forma que em cada ciclo considerado um novo subconjunto de
requisitos, para anlise, implementao, etc.
Dessa forma, cada novo ciclo (ou interao) entrega um produto
mais completo (ou incrementado), com extenses ou melhoramentos sobre o
incremento anterior, at que todo o sistema esteja construdo.
Este modelo tem vantagens e desvantagens, como todos os

modelos. Algumas destas vantagens e desvantagens so detalhadas a seguir:

1.1.1 Vantagens:

Ao entregar o sistema em partes, fica facilitada a identificao

de mudanas de requisito, possibilitando o desenvolvimento
de novos requisitos em incrementos posteriores.

A diviso em incrementos facilita tambm a identificao de

erros e sua correo.

Cada iterao produz itens utilizveis.

A equipe de desenvolvimento pode ser menor que a

necessria para um modelo em Cascata.

A equipe tem em mente objetivos mais prximos, e portanto,

estes so melhor definidos e melhor executados.

O risco envolvido em um nico incremento menor que o

risco do projeto. Caso se torne necessrio repetir o ciclo, a
perda do esforo ser restrita apenas ao esforo de uma
iterao, no do projeto todo.

1.1.2 Desvantagens:

No possvel definir, no incio, a quantidade total de

iteraes que sero necessrias.

Geralmente no possvel definir um prazo de concluso

realista.

O gerenciamento do projeto se torna mais complexo, pois

vrios ciclos podem estar ocorrendo no mesmo momento.

O fato de ser possvel a concomitncia de ciclos, em fases

distintas mas no mesmo momento, aumenta tambm a
complexidade

do

controle

dos

gerenciamento de erros e testes.

custos,

bem

como

1.2 MOTIVOS DA ESCOLHA DESTE CICLO

Foi escolhido o ciclo Iterativo-Incremental, porque entendemos que o
pequeno tamanho, relativamente, do projeto, bem como a pouca disponibilidade de
recursos humanos (apenas 3 horas por semana) minoram o risco de ocorrncia das
desvantagens citadas.
Alm disso, estes motivos acima so tambm motivos pelos quais
mais indicado utilizar este modelo em lugar do modelo Cascata, por exemplo.
Colabora tambm para esta escolha o fato de os requisitos serem
conhecidos porm no estarem formalmente descritos, o que aumenta as
possibilidades de alterao dos requisitos no meio do processo de desenvolvimento,
evento que melhor gerenciado pelo modelo Iterativo-Incremental.

2 WBS DO PROJETO: O QUE ?

A WBS (Work Breakdown Structure), ou em portugus EAP, que significa
Estrutura Analtica de Projeto, um processo de subdiviso do trabalho em entregas
menores, e portanto mais facilmente gerenciveis.
Geralmente, essa subdiviso representada em formado de lista hierrquica,
ou mesmo por meio de fluxogramas.
Neste caso, para melhor compreenso, utilizaremos ambas as formas de
representao.

2.1 WBS TEXTO

Inicialmente, temos a estrutura em formato de texto, ou lista hierrquica:
Nmero Nome da tarefa
1
SISTEMA VOC ALUGA
1.1
Gerenciamento de Projeto
1.1.1
Anlise do Negcio
1.1.2
Definio de Escopo
1.1.3
EAP
1.1.4
Cronograma
1.1.5
Atribuio de Responsabilidades
1.1.6
Mapeamento de Recursos
1.2
Ciclo Padro (Iterativo Incremental)
1.2.1
Anlise de Requisitos
1.2.1.1
Requisitos de Infra
1.2.1.2
Requisitos Funcionais
1.2.1.3
Requisitos No-Funcionais
1.2.1.4
Requisitos de Performance
1.2.1.5
Analisado
1.2.2
Desenvolvimento
1.2.2.1
Definio de Metodologia
1.2.2.2
Definio de Ferramentas
1.2.2.3
Definio de Linguangens
1.2.2.4
Definio de Banco de Dados
1.2.2.5
Programao e Testes
1.2.2.6
Documentao
1.2.2.7
Desenvolvido
1.2.3
Homologao
1.2.3.1
Homologao
1.2.3.2
Homologado
1.2.4
Implantao
1.2.4.1
Piloto
1.2.4.2
Treinamento
1.2.4.3
Produo
1.2.4.4
Incremento em Operao

10

2.2 WBS IMAGEM

Podemos representar a mesma estrutura em formato de imagem, ou
fluxograma:

11

3 CRONOGRAMA DO PROJETO
Depois de definida a EAP ou WBS do projeto, passamos a estabelecer
precedncias e duraes das tarefas, definindo qual ser executada em primeiro
lugar, e qual ser a sequncia de tarefas depois dela.
Passamos a atribuir as tarefas aos recursos que as executaro, verificando
ento a superalocao de recursos, que configurada quando um recurso
atribudo a mais que uma tarefa ao mesmo tempo.
O resultado desse trabalho o cronograma, que usualmente representado
em formado de texto, e tambm em formado grfico.
3.1 CRONOGRAMA EM TEXTO
Segue o cronograma em formato texto:
Nme
Nome da tarefa
ro
1
1.1

Predecesso
Durao Incio
ras
613,33
dias

SISTEMA VOC ALUGA

Gerenciamento de Projeto

40 dias

1.1.1

Anlise do Negcio

1.1.2

Definio de Escopo

4 hrs

1.1.3

EAP

4 hrs

1.1.4

Cronograma

4 hrs

4 hrs

4 hrs

1.1.5
1.1.6
1.2
1.2.1

Atribuio de
Responsabilidades
Mapeamento de Recursos

4 hrs

Ciclo Padro (Iterativo

Incremental)

573,33
dias
26,67
dias

Anlise de Requisitos

1.2.1.1

Requisitos de Infra

4 hrs

1.2.1.2

Requisitos Funcionais

11

4 hrs

1.2.1.3

Requisitos No-Funcionais

12

4 hrs

1.2.1.4

Requisitos de Performance 13

4 hrs

1.2.1.5

Analisado

0 dias

1.2.2

14

Desenvolvimento

320 dias

1.2.2.1

Definio de Metodologia

14

8 hrs

1.2.2.2

Definio de Ferramentas

17

8 hrs

1.2.2.3

Definio de Linguangens

18

8 hrs

Qui
15/05/14
Qui
15/05/14
Qui
15/05/14
Qui
15/05/14
Sex
16/05/14
Sex
16/05/14
Seg
19/05/14
Seg
19/05/14
Ter
20/05/14
Ter
20/05/14
Ter
20/05/14
Ter
20/05/14
Qua
21/05/14
Qua
21/05/14
Qui
22/05/14
Qui
22/05/14
Qui
22/05/14
Sex
23/05/14
Seg

Trmino
Qui
17/07/14
Seg
19/05/14
Qui
15/05/14
Qui
15/05/14
Sex
16/05/14
Sex
16/05/14
Seg
19/05/14
Seg
19/05/14
Qui
17/07/14
Qui
22/05/14
Ter
20/05/14
Ter
20/05/14
Qua
21/05/14
Qua
21/05/14
Qui
22/05/14
Ter
24/06/14
Qui
22/05/14
Sex
23/05/14
Seg

Recursos

Gerente de Projeto
Gerente de Projeto
Gerente de Projeto
Gerente de Projeto
Gerente de Projeto
Gerente de Projeto

Analista
Analista
Analista
Analista

Programador
Programador
Programador

12

Definio de Banco de
1.2.2.4
Dados

19

8 hrs

1.2.2.5

Programao e Testes

20

120 hrs

1.2.2.6

Documentao

21

40 hrs

1.2.2.7

Desenvolvido

22

0 dias

1.2.3

66,67
dias

Homologao

1.2.3.1

Homologao

22

40 hrs

1.2.3.2

Homologado

25

0 dias

1.2.4

Implantao

160 dias

1.2.4.1

Piloto

25

24 hrs

1.2.4.2

Treinamento

28

36 hrs

1.2.4.3

Produo

29

36 hrs

1.2.4.4

Incremento em Operao

30

0 dias

26/05/14
Ter
27/05/14
Qua
28/05/14
Qua
18/06/14
Ter
24/06/14
Qua
25/06/14
Qua
25/06/14
Ter
01/07/14
Qua
02/07/14
Qua
02/07/14
Seg
07/07/14
Sex
11/07/14
Qui
17/07/14

26/05/14
Ter
27/05/14
Ter
17/06/14
Ter
24/06/14
Ter
24/06/14
Ter
01/07/14
Ter
01/07/14
Ter
01/07/14
Qui
17/07/14
Sex
04/07/14
Sex
11/07/14
Qui
17/07/14
Qui
17/07/14

Programador
Programador
Programador

Homologador

Consultor
Consultor
Consultor

3.2 CRONOGRAMA EM GRFICO DE GANTT

Podemos tambm representar o cronograma em formato grfico, utilizando
um diagrama conhecido por Grfico de Gantt, por ter sido criado em 1917 pelo
engenheiro Henry Gantt. Este diagrama se prope a representar a durao das
tarefas no tempo. Para melhor visualizao a imagem est em duas partes:

13

Segunda parte da imagem:

14

4 ANLISE DE USABILIDADE
Como qualquer sistema de informao, o sistema da Voc Aluga deve ser
utilizado por pessoas. Isto naturalmente requisita o uso da matria de anlise
chamada de IHC (Interao Humano-Computador), que o estudo da interao
entre o ser humano e o computador.
Um dos focos de anlise da IHC a anlise de Usabilidade, que o termo
tcnico para descrever a qualidade de uma interface. Esta qualidade geralmente
associada aos seguintes princpios:

Facilidade de aprendizado do usurio

Facilidade de lembrar como utilizar aps um perodo sem uso

Rapidez para desenvolver as tarefas no aplicativo

Menor quantidade de erros

Satisfao do usurio

A avaliao de IHC normatizada no Brasil por meio da norma ISO 9241-11,

mas Rocha e Baranuskas (2000), agrupam os mtodos de avaliao nos seguintes
grupos:

De Inspeo de Usabilidade, que so baseados em normas reconhecidas,

e podem ser aplicados a qualquer momento durante o ciclo de
desenvolvimento;

Testes de Usabilidade efetuados pelo usurio, que demandam o uso

efetivo do usurio e o feedback deste a respeito da sua experincia;

Testes Controlados: So os testes de laboratrio, efetuados no sistema,

com hipteses, cenrios e variveis, e os resultados dos testes so
coletados e analisados estatisticamente;

Mtodos Interpretativos: Dependem do usurio e de sua interpretao a

respeito da interface, geralmente coletados por meio de observao e
entrevistas.

Neste caso, deste projeto, podemos destacar como caracterstica de

Usabilidade necessria para o aplicativo, a facilidade de compreenso, por parte do
usurio, dos dias e horrios em que a locao de determinado veculo, em

15

determinada loja, est disponvel.

Em sua maioria, os aplicativos web existentes que tratam de calendrios e
agendamentos, pecam no quesito de navegabilidade, pois se o usurio solicitar um
agendamento para determinada data e local, e eventualmente esse agendamento
no estiver disponvel, no disponibilizado ao usurio outra opo de data
prxima, ou algo similar.
Nesse caso o usurio deve selecionar outra data, e pesquisar novamente.
Seria um exemplo de facilidade de acesso informao mostrar datas prximas com
agendamentos disponveis para o mesmo veculo, ou mostrar classes de veculos
prximas que estivessem disponveis na data, para casos em que a classe solicitada
no estivesse disponvel.

16

5 ANLISE DE SEGURANA WEB

Nosso aplicativo, alm de estar em ambiente web, trata com dados
confidenciais e financeiros dos clientes, pois estes devem realizar uma PrAutorizao em seus cartes de crdito para poder efetivar reservas de veculos.
Toda aplicao deve ser estruturada de forma a garantir a segurana e
confidencialidade dos dados que por ela trafegam ou nela so armazenados, mas
aplicaes web, pela natureza pblica do ambiente em que esto inseridas, esto
muito mais sujeitas a ataques maliciosos que aplicaes desktop, por exemplo.
Motivo pelo qual a preocupao com a segurana, em aplicaes web, deve
ser maior ainda do que para aplicaes desktop.
Existem diversos tipos de ameaas, que se aproveitam de algumas
caractersticas inerentes natureza da Internet. A tabela abaixo relaciona alguns
tipos de ameaas, bem como seus efeitos e as medidas que podem ser tomadas
para debel-las:
Integridade
- modificao de
dados do usurio
- browser cavalo
de Tria
Ameaas

- modificao de
memria
- modificao de
mensagens em
trnsito
- perda de info

Consequncias

Medidas

Confidenciabilidade
- eavesdropping
- roubo de info/dado do
servidor/cliente

- inundao da
mquina com
- info da configurao da solicitaes bogus
rede/mquinas...
- isolamento
mquina por
- info de qual cliente
"conversa" com servidor ataques a DNS
em trnsito
- perda de informao
- perda de privacidade

- compromete a
mquina
- vulnerabilidade
para outras
ameaas
- checksums
criptogrfico

Negao de
Servio
- bloqueio da
conexo

- interrupo
- aborrecimento
- impedir usurio
realizar seu
trabalho

- encriptao, Web
proxies

Fonte: http://www.ccuec.unicamp.br/revista/infotec/admsis/admsis6-1.html

- difcil prevenir

Autenticao
- personificao
de usurios
legtimos
- falsificao de
dados

- m
representao do
usurio
- crena que
informao falsa
verdadeira

- tcnicas
criptogrficas

17

5.1 CUIDADOS COM AUTENTICAO: SSL

Como visto, so muitos os aspectos em que um bom aplicativo web deve se
preocupar com segurana, mas para o escopo deste trabalho, citaremos apenas o
recurso de conexo criptografada, conhecido como protocolo SSL (Secure Socket
Layer).
Este protocolo consiste, resumidamente, em um conjunto de aes ou passos
que o Browser (cliente) executa junto ao Site (servidor), no incio de uma conexo,
para garantir que todos os dados trocados durante o restante dessa conexo sejam
mantidos confidenciais, de forma que somente as partes legitimamente interessadas
na informao possam ter acesso a ela.
Em nosso exemplo, no sistema Voc Aluga, uma das vantagens da aplicao
de tal protocolo seria que os dados de usurio, e seus cartes de crdito,
permaneceriam privados, inacessveis a qualquer outra pessoa ou sistema que
interceptasse ilegalmente o trfego da internet ou rede. Esse protocolo consiste dos
seguintes passos:

No incio da conexo, o Browser solicita ao Site um Certificado Digital que

garanta a autenticidade do Site.

Aps receber o certificado, o Browser verifica se um certificado vlido, e

se pertence ao site que se deseja acessar.

Caso o Site seja mesmo quem deveria ser, o Browser envia ao Servidor
do Site uma Chave de Criptografia pblica.

A partir da, antes de enviar qualquer informao para este Servidor, o

Browser criptografa essa informao com a Chave de Criptografia Privada
correspondente (simtrica) quela Pblica enviada ao Servidor.

Somente o detentor da chave correta pode descriptografar a mensagem e

ler os dados que ela contm, de forma que qualquer outro aplicativo que
interceptar a mensagem no poder ler seu contedo.

Uma evidncia bem conhecida pelo usurio comum de que o navegador est
utilizando o SSL, a letra s depois do prefixo //http dos endereos de sites.
Outra, a figura de um cadeado, no rodap da pgina ou na barra de endereos do
navegador.

18

6 CONCLUSO
Neste semestre, o trabalho de Portfolio, bem como o restante das
matrias, possibilitou colocar em prtica muitas das teorias estudadas durante o
curso, evidenciando sua utilidade para a prtica profissional da profisso de Analista
de Sistemas.
Fomos introduzidos tambm Programao Web, e s suas
particularidades, como Segurana Web, arquitetura Cliente-Servidor, etc.
Uma das matrias inesperadas, e muito bem aproveitadas, foi a
Interface Homem-Computador, que trouxe tona um vis da Anlise ainda no
conhecida por ns, e que aps estudada, nos possibilitou ter uma viso mais crtica
na utilizao de todos os aplicativos, sistemas e sites da vida diria.
A qualidade do trabalho de Anlise de Sistema, a cada nova matria
estudada, melhora mais; o que no inesperado, pois um dos objetivos do estudo
esse.

19

BIBLIOGRAFIA

CAMARA, Fbio; SLDC Software Development Life Cycle. 2008. Disponvel em:
<http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=1708> Acesso em 14/05/2014.
CATARINA, Instituto Federal Santa; Ciclo de Vida Iterativo e Incremental. 2006.
Disponvel em:
<http://wiki.sj.ifsc.edu.br/wiki/index.php/Ciclo_de_Vida_Iterativo_e_Incremental>. Acesso em
14/05/2014.
FIGUEIREDO, Antoio; Administrao de Sistemas e Segurana WEB. 1999. Disponvel
em: <http://www.ccuec.unicamp.br/revista/infotec/admsis/admsis6-1.html>. Acesso em:
16/05/2014.
HISATOMI, Marco Ikuro; Projeto de Sistemas. Pearson, So Paulo, 2014.
LASKOSKI, Felipe Cys, Lucas Falco Radaelli; Desenvolvimento de Software: Modelo
Incremental. Disponvel em:
<http://www.inf.ufpr.br/lmperes/ciclos_vida/ModeloIncremental.pdf> . Acesso e 14/05/2013
LOPES, Guilherme Baiestero; MARCHI, Kssia R. C; Segurana no desenvolvimento web
utilizando framework spring security. 2013. Disponvel em:
<http://ftp.unipar.br/~seinpar/2013/artigos/Guilherme%20Baiestero%20Lopes.pdf>. Acesso
em: abr. 2014.
MARTINS, Eliane; O que SSL?. 2009. Disponvel em:
<http://www.tecmundo.com.br/seguranca/1896-o-que-e-ssl-.htm>. Acesso em 16/05/2014.
ROCHA Rocha, Heloisa V. da; BARANUSKAS, Maria C. C.; Design e avaliao de
interfaces humano-computador. IME-SP, So Paulo, 2000.
RODRIGUES, Eli; Como fazer um cronograma no MS-Project. 2011. Disponvel
em:<http://www.elirodrigues.com/gestao-de-projetos/serie-como-fazer-um-cronograma/parte1-como-fazer-um-cronograma-no-ms-project/> Acesso em 15/05/2014
SOLER, Luciano; MORAES, Everson Matias de; Desenvolvimento de Aplicao Web.
Pearson, So Paulo, 2014.

SOTILLE, Mauro A; Gerenciamento do Escopo em projetos. 2. Ed. Rio de Janeiro,

Fundao Getlio Vargas, 2009. Disponvel em:
<http://www.bitavel.com/portal/fotos/itavel_3605.pdf>. Acesso em 15/05/2014.
TYSON, Jeff; Chave Pblica: SSL. Disponvel em:
<http://tecnologia.hsw.uol.com.br/criptografia4.htm>. Acesso em 16/05/2014.

20

UCHA, Juliana Prado; Evoluo da Metodologia de Desenvolvimento de Sistemas.

2014. Disponvel em: < http://www.linhadecodigo.com.br/artigo/2108/evolucao-dametodologia-do-desenvolvimento-de-sistemas.aspx> Acesso em 14/05/2014.
WINCKLER, Marco; PIMENTA, Marcelo Soares; Avaliao de Usabilidade de Sites WEB.
2002. Disponvel em: <http://www.irit.fr/~Marco.Winckler/2002-winckler-pimenta-ERI-2002cap3.pdf>. Acesso em 16/05/2014