SISTEMA DE ENSINO PRESENCIAL CONECTADO

CURSO SUPERIOR DE ANÁLISE E DESENVOLVIMENTO DE

SISTEMAS

XXXXXXXX

PRODUÇÃO TEXTUAL INTERDISCIPLINAR

xxxxxxxxxxxx
2017
 XXXXXXXX

Produção Textual Interdisciplinar - 4

Trabalho de Análise e Desenvolvimento de Sistemas

apresentado à Universidade Norte do Paraná - UNOPAR,
como requisito parcial para a obtenção de média
bimestral na disciplina De Projeto Orientado a Objetos,
Engenharia e Projeto de Software, Programação para
Web II.

Orientadores:

Prof.Iolanda C. S. Catarino
Prof.Adriane Ap. Loper
Prof. Roberto Y. Nishmura
Prof.Anderson E. M. Gonçalves
Prof.Cristiane R. Y. Mashuda

xxxxxxxxxxxx
2017
 SUMÁRIO

Introdução.....................................................................................................................3
Objetivo....................................................................................................................... 4
Estudo de Caso Locadora de Carros.......................................................................... 5
Ciclo de vido.................................................................................................................5
WBS – Work Breakdown Structure................................................................... 12
Cronograma...............................................................................................................12
Conclusão...................................................................................................................19
Referências...............................................................................................................20
 3

INTRODUÇÃO

Introdução 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 nós encontramos pessoas que possui pouco
tempo sobrando para dedicar-se à qualidade do seu serviço. S e pararmos
para simplesmente olhar um único ponto, enfatizando que devemos focar em
apenas um único objetivo, com certeza iremos ser esmagados pela correnteza
de turbilhões da vida em um mercado tão amargo. Deixando assim de lado
a concentração e observação de longo prazo, para nos aderir a rápidas
decisões e difíceis conclusões de ideias necessárias para a nossa realização
pessoal e empresarial. Sommerville (2003. P. 84) disse que “Em princípio, a
especificação de requisitos funcionais de um sistema deve ser completa e
consistente”. Não devemos simplesmente deixar as coisas passarem sem ao
menos nos preocuparmos com o amanhã, e forcarmos apenas no hoje, pois
precisamos nos precaver para não vermos nossos sonhos se desmoronarem
na nossa frente como uma montanha de neve se despencando em meio ao
vão. P ara isso em um mercado de trabalho tã o exigente e difícil existe
meios de elaborar projetos mais confiáveis e de boa qualidade. Um projeto
não é apenas uma palavra forte e admirável para ser dita e apreciada por
profissionais e clientes, mas um caminho para ser seguido e fortemente
enriquecido com o intuito de alcançar a tão sonhada qualidade. “O sistema é
uma ‘caixa-preta’ cujo comportamento somente pode ser determinado estudando-
se suas entradas e saídas relacionadas” (Sommerville , 2003, p. 378, grifo do
autor). O foco não está na perfeição, pois nós humanos já somos “perfeitos”,
em cima disso indago que o objetivo está nas mudanças. Desde o inicio o
mundo veio mudando, nós evoluindo, e o tempo passando, por isso é preciso
perseverança e não “atirar pedras no escuro”. Nós 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
espaço e realidade.
 4

1 OBJETIVO

Objetivo O projeto deve ter um inicio, meio e fim bem definidos, não
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 construção de uma página web, podemos usar etapas bem
definidas e de fácil elaboração. Um ciclo de vida deve ser escolhido, pois precisam
os saber como iremos proceder no decorrer do projeto, ou seja, o que faremos a
cada processo. Podemos também construir uma WBS – Work Br eakdown Structure
com o intuito de analisar o que será f eito em cada etapa do nosso ciclo de v
ida, mas com tudo isso é cobrado também um cronograma, pois os clientes querem
datas definidas. O objetivo desse projeto é pesquisar e analisar um possível sistema
em um a plataforma web que atenda as necessidades de uma empresa de locação
de carros. Irei abordar o ciclo de vida adequado para consecução das etapas, com
o objetivo de colher informações necessárias que se façam entender o que o
cliente deseja. Com os requisitos já levantados construirei uma WBS para
controlar as ações dos integrantes do projeto. Essa WBS irá auxiliar na
execução de cada etapa do ciclo de vida. Um cronograma é preciso, pois datas
são marcadas e precisão ser cumpridas. O cronograma é apenas para manter os
analistas, gerente e programadores atualizados e equilibrados perante o tempo,
afinal é necessário um foco, algo que mantenha a capacidade de cumprir prazos e
horários.
 5

Estudo de Caso Locadora de Carros

Empresa com 40 funcionários;. Cada agência é operada por um gerente e

um grupo de agentes de locação que tratam das locações de carros. A locadora
aluga carros aos clientes previamente cadastrados. Caso o cliente não esteja
cadastrado, esta atividade custodia é realizada, separadamente em outra atividade
do sistema. Caso um carro, disponível, seja escolhido pelo cliente este é alugado,
sendo registrada a data inicial junto ao aluguel. Para que o cliente possa alugar
um carro, este não pode estar com dívida p endente. Os carros são descritos
pela placa, ano, modelo, descrição, km, preço por km, situação (disponível, etc.),
taxa diária, observações(informações gerais) e sua imagem. Os clientes são
cadastrados pelo seu cpf, nome, endereço, telefone e dívida(reservado p ara
registrar pagamentos pendentes).Quando o cliente devolve o carro, a situação
do carro é mudada para “disponível”, o km é atualizado com o km atual do
carro e um recibo é emitido, baseado nos kms rodados e nos dias em que ficou
com o carro. Ainda n a atividade de devolução é removido o registro do
aluguel e, caso o cliente não possa pagar, a dívida do aluguel é registrada
junto ao cliente. Em que os dados são gerados por um sistema e usados por outro.
O repositório é passivo e o controle é de responsabilidade dos subsistemas que o
usam.
Também será necessária a utilização de modelos orientados a interrupções.
Isso será preciso para requisições em tempo real, nas quais as interrupções
externas são detectadas por um trator de interrupções. A vantagem dessa
abordagem é que ela permite respostas muito rápidas aos eventos a serem
implementados.
 6

Diagramas da UML Exemplo: Casos de Uso Objetivo: Fazer locação de

carros Restrição: Cliente não pode ter dividas pendentes Atores: Atendente Entidade
Custodial Candidatos a Casos de Usos: Cadastrar Cliente Cadastrar Carro Verificar
Dados Cliente
(Verificar Divida de o Cliente Verificar Disponibilidade Veiculo (Locar)
Entregar Veicula Devolução) Receber Veículo Emitir Recibo Registrar Divida
Candidatos a Classe: Veículos Clientes Divida do Cliente Locação Empregado
Atores: Atendente: Faz o atendimento ao cliente da Locadora Entidade Custodia:
Faz o cadastro da custódia do cliente Candidatos a Casos de Usos: Cadastrar
(Cliente e Carro) Verificar Dados Cliente (Se é cliente e se tem divida) Verificar
Disponibilidade Veiculo Entregar Veiculo Receber Veículo Emitir Recibo Registrar
Divida Candidatos a Classe: Veículo Dados do Cliente Divida do Cliente Locação
Empregado
 7

Cenário do Caso de Uso:

Verificar Dados Cliente
Nome: Verificar Dados Cliente
Objetivo: Verificar se Cliente está cadastro no Sistema e divida pendente
Pré-condição: Cliente solicitar uma locação Ator: Atendente Fluxo Normal:
1-O atendente solicita o número do CPF
2-Digita o CPF no sistema
3-O sistema verifica se cliente está cadastrado e se tem divida pendente
4-O sistema envia mensagem cliente cadastrado e não há divida Fluxo Alternativo
5-O sistema envia mensagem cliente não cadastrado
6-olicita o cadastro da custódia do cliente Fluxo Alternativo

.
 8

Diagrama de Sequência

É um diagrama que exibe a colaboração dinâmica entre os vários objetos de um

sistema. O principal aspecto deste diagrama é que a partir dele percebe-se a
sequência de mensagens enviadas entre os objetos. Ele mostra a interação entre
os objetos, algum evento que acontecerá em um ponto específico da execução do
sistema.

Este diagrama descreve em ordem cronológica as mensagens entre os objetos.

Neste momento estamos dizendo o como o Caso de Uso deve ser implementado.
 9

Diagrama de Colaboração
O que é Diagramas de Colaboração?
É um diagramas que mostra a colaboração dinâmica entre os objetos, semelhante
ao diagrama de sequência. No diagrama de colaboração, além de mostrar a troca
de mensagens entre os objetos, percebe-se também os objetos c om os seus
relacionamentos. A interação de mensagens é mostrada em ambos os diagramas.
Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o diagrama
de sequência, mas se a ênfase for o contexto do sistema, é melhor dar
prioridade ao diagrama d e colaboração. Podemos também escolher ambos. O
diagrama de colaboração é desenhado como um diagrama de objeto, onde os
diversos objetos são mostrados juntamente com seus relacionamentos. As setas
de mensagens são desenhadas entre os objetos para mostrar o flux o de
mensagens entre eles.
 1

As mensagens são nomeadas, que entre outras coisas mostram a ordem em que as
mensagens são enviadas. Também podem mostrar condições, interações, valores
de resposta, e etc. O diagrama de colaboração também pode conter objetos ativos,
que executam paralelamente com outros.
 11

Ciclo de Vida
A melhor abordagem para um determinado projeto depende, em
grande parte, da natureza do projeto e da natureza da organização. 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
organização onde se vai prestar o serviço para desenvolver o software.
Partindo para a prática, a prototipagem funciona melhor para projetos d e pequeno
e médio. 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 usuário focalizando a interface do usuário. Os estágios do projeto e de
desenvolvimento, no que concerne à interface de usuários, repetem-se até que
o usuário esteja satisfeito. A figura abaixo ilustra isso:
 1

Como se pode ver no diagrama existem seis processos básicos que

podemos usar no decorrer do projeto. Nota-se também que em uma parte do
projeto, graças às funcionalidades do ciclo de vida em prototipagem, podemos
volt ar no início do processo, ou seja, no levantamento das necessidades, ou
na segunda fase do processo, que é a analise de alternativas. Como os
envolvidos no projeto são 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 reunião, obter bons resultados
positivos. Pois o contato será diretamente com os usuários, podendo nos informar
rapidamente alguma dúvida ou insatisfação. Como os requisitos já são conhecidos,
só nós restará obter dados baseados no conhecimento empírico de cada usuário.
Como desenvolvimento WEB.
Poderemos mostrar e fazer testes onde estivermos, basta possuir
as ferramentas necessárias. 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 início do texto. No ciclo de vida em espiral
poderemos reservar uma versão teste para os clientes, e receberemos o feedback
através do e-mail. Mantendo contato com os clientes, sempre os informaremos
quando a atualização estiver pronta, e antes de coloca-la p ara funcionar,
basta usar um protótipo para fazer o teste e aplicar os procedimentos do ciclo de
vida prototipação. WBS – Work Breakd own Structure Antes de observar a WBS é
preciso ter uma ideia do que ela é , e para quê ela serve. Segundo definições do
Guia P MBOK “WBS é o processo de subdivisão das entregas e do trabalho
do projeto em componentes menores e de gerenciamento mais fácil. A W BS
é uma decomposição hierárquica orientada às entregas do trabalho a ser
executado pela equipe par a atingir os objetivos do projeto e criar as
 1

entregas requisitadas, sendo que cada nível descendente da WBS representa

uma definição gradualmente mais detalhada da definição do trabalho do
projeto. A W BS organiza e define o escopo total e representa o trabalho
especificado na atual declaração do Escopo do projeto aprovado. O trabalho
planejado é contido dentro dos componentes de nível mais baixo da WBS,
que são 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 o u entregas qu e são
resultado do esforço e não o próprio es forço”. PMOBOK®, Um guia do
Conhecimento em Gerenciamento de Projetos (Guia P MBOK®) – Quarta
Edição, PM I® – Project ManagementInstitute, ISBN: 978-1-933890-70-8. Segue
abaixo a WBS:
 1

Essa WBS é apenas a primeira analise, com o decorrer do projeto irá surgir
novas ideias que serão a crescidas na mesma. Uma WBS deve ser simples e ao
mesmo tempo robusta, ou seja, que não seja grande e n em complexa demais para
confundir os envolvidos no projeto, mas que seja precisa o suficiente para
capturar todas as etapas que devem ser cumpridas. Após seguirmos os passos
acima, teremos uma primeira versão 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 relatórios 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 desnecessários.
Acredito que com esse diagrama simples seremos capazes de pelo menos nos
familiarizar com o projeto, afinal resultados negativos também são aceitos
quando se trata de mudanças e melhoramento, pois é em cima deles que iremos
aprender.
Cronograma

É uma maneira de colocar as etapas do projeto de maneira cronológica, ou

seja, de uma forma que podemos segui-las, obedecendo às datas especificas para
cumpri-las. A vantagem de um cronograma é o f ato do gerente de projeto
poder manter a palavra com os seus clientes, afinal a coisa mais perturbadora
par a um usuário é receber s eu produto fora de data. Entregar o que foi
prometido fora do tempo, às vezes até muito atrasado, é constrangedor para
os responsáveis pelo desenvolvimento do sistema. O cronograma a seguir será
montado levando em conta as e tapas do ciclo de vida e da WBS, mostrarei
etapa por etapa. Ele foi montado na ferramenta C ASE GanttP roject. Como
comenta Heldman (2002, p. 213) “É fácil ler os gráficos de Gantt, usados, na
 1

maioria das vezes, para agendar atividades. Dependendo do s oftware utilizado

para gerá-lo, esse gráfico também pode exibir sequencias e as datas de inicio
e fim das atividades, alocações de recursos, dependências das atividades e o
caminho crítico”. Levantamento das Necessidades: é a fase onde serão
analisados os requisitos para proceder no desenvolvimento do sistema. Coletar
a partir de entrevista com os clientes toda a informação para elaborar o plano de
projeto.

Análise de Alternativas: a fase onde serão analisadas As regras de negócios da

empresa aplicadas ao sistema.
1
 1

Manutenção: essa fase é a última e a mais importante do nosso projeto,

pois é aqui que concluiremos todas as etapas finalizando com teste e aprovações.
 1

Para um gerente inexperiente elaborar um cronograma pode ser uma das coisas
mais difíceis em seu começo de carreira, afinal ele não possui ainda
nenhuma ideia de prazo s, isso pode acarretar em prazos maus definidos, por
isso é ideal sempre analisar e rever o cronograma. Aspectos com Padrões de
Segurança As organizações de tecnologia d e informação e de desenvolvimento
de software estão passando por uma mudança significativa na forma como
percebem o seu próprio problema. Até pouco tempo, se fosse perguntado às
empresas de médio porte a respeito da segurança de informação, a resposta
incluiria, provavelmente, a frase “segurança da rede”. Esse tipo de pensamento
faz parte do passado, pois em arquiteturas distribuídas, as aplicações
conduzem a maioria das decisões de segurança. Por exemplo, como se deve
permitir o acesso de um determinado cliente ou parceiro a dados particulares?
Como resultado, as organizações estão. Tendo que se adaptar rapidamente e
mudar o foco de uma visão de mundo centrada em redes de aplicação para
segurança de software. Esta tendência ocorre com uma maior frequência nas
tecnologias baseadas na Web, dando origem a uma demanda por tecnologias
que buscam segurança em aplicações Web e Web Servicos.De um modo geral,
segurança é uma palavra-chave no desenvolvimento de software. Notoriamente
essa importância tem aumentado, pois a maioria dos ataques a sistemas
exploram vulnerabilidades causadas por aplicativos mal projetados e
implementados. Em decorrência dessa situação, uma coleção de padrões de
segurança foi documentada para descrever soluções para problemas de
segurança e, portanto, podem ser adaptados a essa s dificuldades.

Padrões de segurança são soluções reutilizáveis aos problemas de segurança

que podem ser adaptadas a contextos específicos. Em bora muitos padrões de
 1

segurança e técnicas para usá-los estejam sendo propostos, é complexo

adaptá-los e integrá-los em cada fase do desenvolvimento de software.
Ultimamente, são desenvolvidos e melhorados cada vez mais padrões de
segurança, incluindo a estes, padrões para Web Services. Esses padrões são
complexos e detalhados, logo não é uma tarefa simples para os
desenvolvedores e usuários compreenderem seus pontos chaves. Com o
objetivo de projetar, desenvolver e implantar Web Services seguros, arquitetos e
desenvolvedores precisam compreender n ovas tecnologias e analisar as ameaças
associadas à exposição de funcionalidades em redes inseguras.
Sem uma definição clara de como os Web Services podem gerenciar e
estabelecer comunicações seguras em relações de confiança com outros
parceiros ou tecnologias, é difícil realizar qualquer tipo de interação. Um sistema
tradicional possui os dados necessários para conhecer a priori cada usuário
que o utiliza e o que cada um pode fazer. Um usuário também tem o
conhecimento prévio de quais sistemas vai acessar, já possuindo o s dados
necessários para cada autenticação, e com autorização prévia para realizar um
conjunto de operações em cada um deles. Para resguardar esses recursos, as
organizações precisam definir políticas de segurança, que são linhas de
orientação de alto nível que especificam em qual estado o sistema é considerado
seguro. Essas políticas precisam ser aplicadas por meio de mecanismos de
segurança. Para programar esses mecanismos é viável aplicar alguns padrões,
dentre os quais pode se destacar o uso do Authenticator e Authorization. Este
artigo descreve como a orientação a aspectos (AOP – As pect-Oriented
Programming) pode ser uti lizada para tratar requisitos de segurança como
preocupações transversais, ou seja, que estão espalhadas por tod a a
aplicação.

Conclusão
 2

Concluímos que em um projeto é preciso definir tarefas e etapas bem

detalhadas para a consecução 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 não o corram 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
não é possível 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 relação ao projeto. Entende-se que um
cronograma é onde definimos as nossas datas, os prazos de entrega e de
consecução dos processos envolvidos na WBS. Não 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 dedicarão
apenas a sua tarefa, apenas aquilo que lhe foi passado para fazer, pois isso
evita uma sobrecarga de serviço.

Referências
 2

Artigo Revista Java Magazine 93. Aspectos com Padrões de Segurança. Disponível
em:<http://www.devmedia.com.br/aspectos-com-padroes-de-seguranca-artigo-
revista-java-magazine-93/21654#ixzz30wDujpq2>.

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de

Janeiro: Campus, 2002.

FLORES, Emerson Ricardo. Linguagens e técnicas de programação III. São Paulo.

Editora Pearson, 2012.

MELO Ana Cristina. Desenvolvendo aplicações com U ML 2.0: do conceitual à

implementação - 2ºed. Rio de Janeiro: Brasport, 2006.

PMOBOK®, Um guia d o Conhecimento em Gerenciamento de Projetos (Guia

PMBOK®) – Quarta Edição, PMI® – Project Management Institute, ISBN: 978-1-
933890-70-8.

SANTOS, Ril do F. UML: Linguagem de Modelagem Unif icada . 2009

Disponível em: <http://pt.slideshare.net/Ridlo/uml-1858376> Acesso: 08/03/17.

Wikipédia enciclopédia livre. Banco de Dados Distribuídos. Disponível em <

http://pt.wikipedia.org/wiki/Banco_de_dados_distribu%C3%ADdos >
Acesso: 08/03/17