Portfólio Individual VI Semestre - Análise e Desenvolvimento de Sistemas - Unopar

Prévia do material em texto

Itaberaba - Ba
2019
FELIPE DA SILVA SANTANA
SISTEMA DE ENSINO PRESENCIAL CONECTADO
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
ENGENHARIA DE SOFTWARE E GESTÃO DE PROJETOS:
Caminhos para a Qualidade no Desenvolvimento de Sistemas de
Software
Itaberaba - Ba
2019
ENGENHARIA DE SOFTWARE E GESTÃO DE PROJETOS:
Caminhos para a Qualidade no Desenvolvimento de Sistemas de
Software
Trabalho apresentado ao Curso de Análise e
Desenvolvimento de Sistemas da Universidade Pitágoras
Unopar, como requisito parcial para a obtenção de média
semestral nas disciplinas de Engenharia e Projeto de
Software, Projeto Orientado à Objetos, Programação
para Web II e Seminários V. Orientador: Prof. Anderson
Emídio de Macedo Gonçalves; Everson Matias de
Morais; Adriano Sepe; e Merris Mozer. 
FELIPE DA SILVA SANTANA
SUMÁRIO
1 INTRODUÇÃO..........................................................................................................3
2 DESENVOLVIMENTO...............................................................................................4
2.1 Prototipação………………………………………..…………………………………….4
2.1.1 Diagrama de Casos de Uso………………………………………………………….5
2.1.2 Descrição de Casos de Uso………………………………………………………….5
2.1.3 Prototipação de Interface Gráfica de Usuário……………………………………...9
2.2 Plano de Projeto………………………………………………………………………..12
2.2.1 Objetivo……………………………………………………………………………….12
2.2.2 Justificativa……………………………………………………………………………13
2.2.3 Escopo………………………………………………………………………………...13
2.2.3.1 EAP – Estrutura Analítica do Projeto……………………………………………14
2.2.4 Mapa Mental………………………………………………………………………….14
2.2.5 Gerenciamento do Tempo………………..………………………………………...15
2.2.6 RUP (Rational Unified Process)……………………………………………………17
2.2.7 Plano de Qualidade……………………….……………………………..…………..20
2.2.8 Business Process Engineering……………………………………………………..21
2.2.9 Plano de Desenvolvimento………………………………………………………….21
2.2.9.1 Diagrama de Casos de Uso………………………………………………………22
2.2.9.2 Diagrama de Classes……………………………….…………………………….22
2.2.9.3 Mapeamento de Requisitos Funcionais e Não Funcionais…………………...23
2.2.9.4 Arquitetura do Sistema……...…………………………………………………….24
2.2.9.4.1 Arquitetura Física………………………………………………………………..24
2.2.9.4.2 Arquitetura Lógica……………………………………………………………….25
2.2.9.5 Padrões de Projetos………………………………………………………..……..26
2.2.9.6 Tecnologias Aplicadas…………………………………………………………….27
2.2.9.7 Frameworks………………………………………………………………………...27
2.2.9.8 Ferramentas...……………………………………………………………………...27
2.2.9.9 Página de Recarga de Pulseira………………………………………………….28
3 CONCLUSÃO..........................................................................................................28
 REFERÊNCIAS..........................................................................................................30
1 INTRODUÇÃO
A empresa Startup PulseADS trabalha com o desenvolvimento de
soluções tecnológicas especializadas para grandes parques em todo Brasil. Através
da tecnologia de RFID - Radio Frequency Identification - conhecida em português
como identificação via radiofrequência; a mesma desenvolveu pulseiras especiais
que visam proporcionar uma melhor eficiência nos processos de negócio dos
parques e consequentemente entregar mais segurança aos seus clientes.
As pulseiras funcionam como um sistema de pagamento pré-pago,
onde é possível realizar operações de crédito e débito, ou seja, o cliente, ao chegar
no parque, irá carregar sua pulseira com um determinado valor e consumirá seus
créditos enquanto lá estiver.
Em consequência do aumento de sua clientela, surgiu a
necessidade do desenvolvimento de um sistema que integrasse a tecnologia das
pulseiras às operações de controle de acesso e consumo dos parques.
Partindo-se dessa premissa, a equipe de desenvolvimento da
Startup PulseADS iniciou o planejamento e desenvolvimento do projeto de software
PulseConsumo, onde a mesma utiliza das boas práticas da Engenharia de Software
e Gestão de Projetos para que seja possível o desenvolvimento de um produto de
alta qualidade e que atenda as reais necessidades de seus clientes.
Ao decorrer deste trabalho serão apresentados alguns conceitos,
processos e técnicas utilizadas para o desenvolvimento de software gerenciável e de
qualidade, focado na entrega dentro do prazo estabelecido, mantendo os custos
gerais dentro do orçamento, obedecendo assim as principais restrições de projeto,
como: escopo, cronograma, custo, qualidade, recursos e risco.
3
2 DESENVOLVIMENTO
Desde a então “crise de software” do final da década de 60, os
cientistas e engenheiros da computação têm alocado esforços no desenvolvimento
de técnicas que auxiliem o desenvolvimento de software de qualidade e que de fato
atenda às exepectativas do cliente. Surge então a área da Engenharia de Software.
Engenharia de software, segundo Bauer (apud PRESSMANN, 2011,
p.29), é “o estabelecimento e o emprego de sólidos princípios da engenharia de
modo a obter software de maneira econômica, que seja confiável e funcione de
forma eficiente em máquinas reais”.
Na engenharia de software existem processos conhecidos como
processos de software. Um processo de software é um conjunto de atividades
relacionadadas que levam à produção de um produto de software. 
2.1 Prototipação
Segundo Sommerville (2011, p. 30), “um protótipo é uma versão
incial de um sistema de software, usado para demonstrar conceitos, experimentar
opções de projeto e descobrir mais sobre o problema e suas possíveis soluções”.
A prototipação é uma técnica que pode ser utilizada para definir
aspectos importantes do sistema, abstraindo as principais funcionalidades e
auxiliando na elicitação de requisitos da atividade de Análise do processo.
Geralmente, os protótipos são baseados em sistemas existentes.
Diante disso, a equipe da Startup PulseADS desenvolveu um plano
de prototipação com base nas seguintes fucionalidades:
a) cadastro de pulseira - realiza o cadastro de uma nova pulseira;
b) cadastro de cliente – realiza o cadastro de um novo cliente;
c) cadastro de funcionário – realiza o cadastro de um novo
funcionário;
d) recarga de pulseira – realiza operação de crédito sobre saldo
atual da pulseira.
4
2.1.1 Diagrama de Casos de Uso
Para uma representação de alto nível dessas posíveis
funcionalidades, criou-se um Diagrama de Casos de Uso. O Diagrama de Casos de
Uso é uma ferramenta gráfica pertencente aos diagramas comportamentais da UML
(Linguagem de Modelagem Unificada) e tem como propósito representar cenários
de interação entre atores externos (usuários) e o sistema em si. É composto por
atores, casos de uso e suas associações.
Na Figura 1 abaixo, é possível visualizar o diagrama de casos de
uso criado para o protótipo.
2.1.2 Descrição de Casos de Uso
Apesar do diagrama de casos de uso ser uma ótima ferramenta para
elucidar funcionalidades do sistema e portanto facilitar a atividade de elicitação de
requisitos, o mesmo não fornece detalhes suficientes para prosseguir com a
implementação. É necessário a especificação destes casos de uso, através da
atividade de documentação ou descrição de casos de uso.
Existem diversos modelos de descrição de casos de uso que podem
5
Figura 1: Diagrama de Casos de Uso. Fonte: autor.
ser utilizados, cada organização deve utilizar àquele que melhor atender as suas
necessidades. Nas Figuras 2 e 3, vemos um exemplo das descrições dos casos de
uso das funcionalidades anteriormente citadas, respectivamente.
6
Figura 2: Descrição de Caso de Uso Cadastrar Pulseira. Fonte:
autor.
7
Figura 3: Descrição do Caso de Uso Cadastrar Cliente.Fonte:
autor.
8
Figura 4: Descrição de Caso de Uso Cadastrar Funcionário. Fonte:
autor.
2.1.3 Prototipação de Interface Gráfica de Usuário
A atividade de prototipação de inferface gráfica de usuário é muito
importante para aceitação de um software pelo usuário final, pois é nela que se
definem os componentes visuais e interativos que serão dispostos em tela para que
9
Figura 5: Descrição do Caso de Uso Realizar Recarga. Fonte: autor.
sejam vistos e interpretados pelo usuário.
Portanto, deve-se ater a requisitos não funcionais como usabilidade
e ergonomia, de forma a oferecer uma interface gráfica agradável e intuitiva.
Realizando um estudo da descrição dos cenários de interação
(casos de uso), é possível abstrair alguns campos necessários para a prototipação
das telas anteriormente propostas.
10
Figura 6: Tela Cadastrar Pulseira. Fonte: autor.
11
Figura 7: Tela Cadastrar Cliente. Fonte: autor.
Figura 8: Tela Cadastar Funcionário. Fonte: autor.
2.2 Plano de Projeto
Quando se fala em desenvolvimento profissional de software, tem-se
em mente a aplicação de diversas técnicas e metodologias para se obter um
resultado satisfatório. O plano de projeto é uma dessas técnicas, e está relacionada
a gestão de projetos. 
Afinal, é imprescindível o controle e monitoramento das atividades
relacionadas ao projeto para que se tenha uma ampla visão sobre questões como
prazos, recursos e custos.
O plano de projeto serve como um guia para equipe do projeto. Ele
descreve as ações necessárias para definir, coordenar e integrar todos os planos
auxiliares do projeto. 
2.2.1 Objetivo
Este documento objetiva definir detalhadamente aspectos relevantes
de planejamento, execução e acompanhamento do desenvolvimento do projeto
PulseConsumo, que será realizado pela empresa Startup PulseADS. Estes aspectos
envolvem principalmente escopo, prazos, recursos, qualidade e riscos.
12
Figura 9: Tela Nova Recarga. Fonte: autor.
2.2.2 Justificativa
O principal objetivo deste documento é o planejamento de
desenvolvimento do sistema de informação PulseConsumo. Portanto, o mesmo visa,
por meio dos artefatos aqui gerados, estabelecer uma estrutura global de
comunicação e registro entre os stakeholders, analistas de negócio, gerentes de
projeto, equipes de desenvolvimento e engenheiros de teste.
2.2.3 Escopo
O sistema PulseConsumo tem como propósito realizar o controle de
acesso e consumo em parques, utilizando-se da tecnologia RFID (identificação por
radiofrequência) aplicada a pulseiras especiais. Desta forma, visa proporcionar uma
melhor eficiência aos processos de negócio e fornecer maior segurança aos
usuários. O sistema em questão deve permitir:
1. Autenticação de funcionários: permitir que os funcionários
acessem as funcionalidades a partir de usuário/senha;
2. Registrar operação de venda: consiste em gerar um débito no
saldo da pulseira utilizada pelo cliente, bem como a baixa no
estoque de mercadorias;
3. Consultar saldo: possibilitar que o cliente consiga consultar o
saldo existente em sua pulseira.
O gerenciamento de escopo envolve processos essencias para a
garantia de que apenas o que foi definido seja realizado. Partindo-se dessa
premissa, o gerenciamento de escopo busca proporcionar uma visão comum de
projeto - onde aqueles envolvidos, possam compreender o que já foi feito e o que
ainda há de ser feito. Para auxiliar nessa proposta, utiliza-se uma EAP para
representação gráfica e hierárquica de etapas e atividades.
2.2.3.1 EAP – Estrutura Analítica de Projeto
A EAP (Estrutura Analítica de Projeto) é uma ferramenta, ou melhor,
um diagrama que busca auxiliar no controle e gestão para que o planejamento seja
executado, estabelecendo um transcurso de prazo, a fim de concluir as tarefas.
13
Atém-se a definição de metas e objetivos.
2.2.4 Mapa Mental
O mapa mental é uma ferramenta para a representação de ideias de
forma fragmentada, onde os elementos são representados por tópicos e seus
subtópicos, assim formando uma estrutura hierárquica de conceitos. Apesar de os
diagramas da UML serem comuns para a modelagem de requisitos, o mapa mental
por sua simplicidade e praticidade, pode ser usado para se ter uma visão abstrata e
geral dos aspectos principais de um projeto/sistema.
Portanto, para alcançar este fim, elaborou-se o mapa mental do
sistema PulseConsumo, onde o mesmo poder ser visto na Figura 11 abaixo.
14
Figura 10: Estrutura Analítica do Projeto. Fonte: autor.
2.2.5 Gerenciamento do tempo
A necessidade de se medir o tempo sempre esteve presente na
história da humanidade, tendo como um dos percursores, o relógio como uma
ferramenta de medição de tempo.
Devido as exigências do mercado em produzir mais, com menos
custos e em menos tempo, a adoção de boas práticas do gerenciamento de tempo
se tornou essencial para uma boa gestão. 
É nítido que quando não se há um controle sobre as atividades,
temos uma rotina desorganizada e cansativa - perde-se a produtividade e eficiência
com a execução de atividades que muitas vezes não agregam valor. 
Portanto, tratando-se de projeto, existe um conjunto de técnicas e
ferramentas que auxiliam na prática de gerenciamento do tempo. Segundo o Guia
PMBOK® Quinta Edição, o gerenciamento do tempo inclui os processos requeridos
para assegurar a conclusão do projeto no prazo previsto.
Dessa forma, o gerencimento de tempo foca no estabelecimento de
15
Figura 11: Mapa mental. Fonte: autor. <https://www.mindmeister.com>.
boas práticas tendo como objetivo a realização de atividades eficientemente,
designando cada tarefa àquele responsável por sua execução. Definindo uma rotina
coesa e saudável pensando no bem-estar de todos envolvidos e como resultado,
atingir objetivos satisfatoriamente, obedecendo prazos e orçamentos previstos.
Como exemplo de ferramentas utilizadas na gestão do tempo, temos
a lista de atividades ou cronograma e o Diagrama de Grantt, que podem ser vistos
nas imagens Figura 12 e Figura 13, respectivamente. A lista de atividades
representa o cronograma de atividades executadas durante o processo de
desenvolvimento, estabelecendo assim, os responsáveis por sua realização e o
prazo de início e fim das mesmas.
Já o Diagrama de Gantt é um gráfico utilizado para visualização do
avanço das diferentes etapas de um projeto. Logo, preocupa-se com o intervalo de
tempo gasto entre o início e o fim de cada fase. Por ser simples, é de fácil
entendimento pelos integrantes do projeto, facilitando a comunicação não só da
equipe interna, como também com o cliente, permitindo-lhes o acompanhamento do
atual progresso do projeto.
16
Figura 12: Lista de atividades. Fonte: autor. <https://artia.com/>.
2.2.6 RUP (Rational Unified Process)
O desenvolvimento profissional de software exije um planejamento
estratégico de etapas e atividades para que se obtenha um processo de qualidade e
consequentemente, um produto de qualidade. As linhas ou cronogramas de
execução que permeiam o desenvolvimento dessas etapas e atividades são
conhecidas como processo de software.
Os processos de software podem ser classificados em metodologias
dirigidas à planos e metodologias ágeis. As metodologias dirigidas à planos
(metodologias tradicionais) determinam um conjunto de etapas fixas, onde deve-se
obedecer uma ordem cronológica, ou seja, para avançar para a próxima etapa é
necessária a conclusão das atividades da etapa atual – o que inviabiliza a
flexibilidade e aumenta os possíveis riscosde desenvolvimento. Visto que todo o
projeto de software é realizado antes de qualquer etapa de implementação,
dificultando o gerenciamento de riscos e mudanças. Dentre as metologias
tradicionais, podemos citar o modelo em cascata, que pode ser visto na Figura 14.
Já as metodologias ágeis surgiram justamente para poder realizar a
17
Figura 13: Diagrama de Gantt. Fonte: autor. <https://artia.com/>.
integração entre as atividade, criando um ciclo de vida evolutivo, e por fim,
proporcionando uma maior flexibilidade na execução das mesmas, tendo como
objetivo o desenvolvimento iterativo e incremental. Aplica-se da ideia de que para
resolução eficiente de um problema complexo, é necessário dividi-lo em problemas
menores. Tem como foco principal os relacionamentos.
Após um estudo sobre os tipos e as vantagens das metodologias
disponíveis e os desafios proporcionados pelo projeto atual, a Startup PulseADS
optou pela adoção da filosofia de desenvolvimento do RUP, ou melhor, Rational
Unified Process (Processo Unificado da Rational).
O UP – Unified Process; é um processo proprietário de software que
foi criado pela Rational Software Corporation, posteriormente adquirida pela IBM e
portanto reformulado e renomeado para RUP.
Composto pelas fases de Concepção, Elaboração, Construção e
Transição, o RUP busca englobar algumas das melhores práticas das metodologias
de desenvolvimento, utilizando-se dos paradigmas da POO (Programação Orientada
à Objetos) atrelada as ferramentas da UML. 
Além das fases, O RUP tem como principais características, as suas
iterações e workflows. As iterações representam a evolução do projeto em relação
ao tempo, abordam algumas poucas funções do sistema e geralmente são de curta-
média duração – o que reduz o impacto de possíveis mudanças.
Junto às fases, temos os workflows – que são sequências de
atividades relacionadas a um aspecto importante do projeto. A Figura 15 demonstra
o esforço alocado para cada etapa do projeto.
18
19
Figura 15: Ciclo iterativo do RUP. Fonte:
<https://pt.wikipedia.org/wiki/IBM_Rational_Unified_Proce
ss>.
Figura 14: Modelo em Cascata. Fonte:
<https://casadaconsultoria.com.br/modelo-cascata/.
2.2.7 Plano de qualidade
Assim como o plano de projeto busca em seu núcleo a especificação
e estabelecimento de padrões para se alcançar um produto ideal, o plano de
qualidade é o que vai garantir que as exigências especificadas para a qualidade
desejada sejam alcançadas.
O plano de qualidade documenta procedimentos, recursos e
atividades relevantes para a construção de um determinado projeto, produto ou
serviço.
Portanto, visando oferecer a padronização e assim aplicar-se do
melhoramento contínuo para alcançar metas de qualidade, desenvolveu-se um
plano de qualidade para o projeto PulseConsume tendo como base o método PDCA.
O PDCA – Plan, Do, Check, Act – é um método iterativo utilizado
para gestão da qualidade que visa o controle e o melhoramento contínuo de
processos, produtos ou serviços. É representado por um ciclo em quatro fases:
a) Plan (Planejar) - é a fase onde um processo ou atividade é
estudado visando identificar possíveis melhorias e assim elaborar
metas e portanto, definir os métodos utilizados para alcançá-las;
b) Do (Executar) – consiste em pôr em prática o plano elaborado
na fase anterior, realizando o acompanhamento do progresso;
c) Check (Verificar) – é a fase onde os resultados das atividades
executadas até então são analisados com objetivo de identificar
divergências entre o que foi planejado e o realizado;
a) Act (Agir) – está atrelada a tomada de decisão, ou seja, atuar
corretivamente sobre as divergências identificadas, caso haja.
Caso contrário, estabelecer a padronização dos processos e
então concluir o plano.
Diante do apresentado, para cada realização de uma atividade
presente no plano de projeto, será efetuado o seu monitoramento para análise do
atual progresso, e após a sua conclusão, caso seja identificadas divergências do
que foi anteriormente planejado, serão realizadas reuniões entre a equipe para a
discussão dos problemas decorrentes e as possíveis ações corretivas a serem
tomadas. Desta forma, busca-se estabelecer um ambiente de transparência, onde
todos estão cientes da atual situação do projeto e colaboram para um objetivo
20
comum: a qualidade de seu produto e a satisifação de seus clientes.
Quanto ao controle de qualidade do produto, são realizados planos
de teste a cada iteração, possibilitando a compreensão de seu funcionamento e se o
mesmo atende ao que foi anteriormente proposto. Aplicando-se do conceito de
gerenciamento de riscos, também elabora-se o plano de gestão de riscos, que tem
como objetivo mapear riscos que podem ameaçar o andamento e
consequentemente a qualidade do projeto e as propostas de solução para os
mesmos. Desta forma, busca-se a prevenção de “gargalos” e o retrabalho.
2.2.8 Business Process Reenginering
BPR ou Business Process Reeginering (Reegenharia de Processos
de Negócio) é uma metodologia, ou melhor, uma filosofia que preocupa-se com a
otimização contínua de processos dentro de uma organização. Portanto, visa a
redução de custos, melhoria da performance operacional, alinhamento estratégico e
o relacionamento com o cliente (CRM – Customer Relationship Management).
Contudo, é necessário o redesenho de processos, aplicando-se da
padronização, simplificação, fluxo estruturado, automação, distribuição equilibrada
de atividade, especialização e centralização. Buscando-se apoiar nas melhores
práticas de mercado.
É certo que processos de negócio ágeis e eficazes permitem rápida
adaptação frente às demandas e mudanças de rumo, daí a importância de se ater à
aspectos fundamentais de um projeto como o escopo, custo e tempo. Pois estes
mesmos aspectos regem e influenciam o resultado do processo produtivo.
2.2.9 Plano de Desenvolvimento
Durante a atividade de Projeto, é necessário a elaboração de
artefatos que abordem diferentes visões do sistema. Diante dos conceitos
apresentados, para a documentação e projeto do sistema PulseConsumo será
utilizado alguns diagramas da UML em conjunto a algumas técnicas para descrição
de requisitos. 
A UML é uma linguagem de modelagem unificada que dispõe de um
conjunto de ferramentas de notação gráfica que visam especificar, documentar,
21
visualizar e construir artefatos ao longo do processo de desenvolvimento de
software. Apoia-se no desenvolvimento incremental aplicado ao paradigma da
orientação a objetos.
2.2.9.1 Diagrama de Casos de Uso
O Diagrama de Casos de Uso pertence ao grupo dos Diagramas
Comportamentais da UML e já foi apresentado anteriormente no plano de protótipo
desenvolvido para o projeto. No entanto, a Figura 16 abaixo, demonstra uma versão
mais completa e que melhor descreve as necessidades dos usuários do sistema.
2.2.9.2 Diagrama de Classes
O Diagrama de Classes pertence ao grupo dos Diagramas
Estruturais da UML e portanto representa aspectos estáticos do sistema. Através de
elementos próprios, como Classes e Relacionamentos, entre outros, é possível
definir a arquitetura do sistema e as relações de seus componentes. Apoia-se no
paradigma da Orientação à Objetos.
22
Figura 16: Diagrama de Casos de Uso. Fonte: autor.
2.2.9.3 Mapeamento de Requisitos Funcionais e Não Funcionais
Como o próprio nome sugere, o mapeamento de requisitos é a tarefa
de mapear e documentar os requisitos através de algumatécnica de descrição, seja
por linguagem natural ou visual. Aproveitando-se do mapa mental anteriormente
construído, pode-se observar os requisitos funcionais e não funcionais do sistema.
Os requisitos funcionais descrevem as funcionalidades que o
sistema deve prover aos seus usuários. Já os requisitos não funcionais são as
restrições que permeiam a execução dessas funcionalidades, como por exemplo, o
desempenho, confiabilidade, usabilidade e políticas. Portanto, os requisitos não
funcionais estão diretamente relacionados ao comportamento do sistema.
23
Figura 17: Diagrama de Classes. Fonte. autor.
2.2.9.4 Arquitetura do Sistema
A arquitetura de um sistema define como os seus componentes,
físicos (arquitetura física) ou lógicos (arquitetura lógica) são distribuídos e
organizados e como se relacionam entre si. Portanto, visando atingir propriedades
de manutenibilidade e disponibilidade, definiu-se que o sistema PulseConsumo será
baseado em sistemas web. O que o torna acessível por qualquer dispositivo que
tenha acesso à Internet.
2.2.9.4.1 Arquitetura Física
A arquitetura física define os elementos físicos necessários para o
perfeito funcionamento do sistema, onde cada um possui uma responsabilidade no
processo de execução do mesmo. Por vezes, estão relacionados ao ambiente de
operação do sistema. 
Por se tratar de um sistema web, definiu-se como arquitetura física o
modelo de arquitetura cliente-servidor - onde o cliente (navegador ou aplicação) faz
uma requisição (página web, como exemplo) a um servidor através de algum
protocolo de comunicação web (HTTP – HyperText Transfer Protocol, por exemplo)
e o servidor retorna a página correspondente como resposta. A figura abaixo
representa a estrutura desse modelo.
24
Figure 18: Requisitos Funcionais e Não Funcionais. Fonte: autor.
2.2.9.4.2 Arquitetura Lógica
A arquitetura lógica como o próprio nome sugere, define a estrutura
lógica de um sistema, seja através da organização de classes em pacotes ou
componentes por camadas. Tratando-se de camadas, existe um padrão de
arquitetura muito utilizado na web chamado MVC.
O MVC ou Model-View-Controller (Modelo-Visão-Controlador)
separa a responsabilidade de componenentes por camadas, facilitando assim a sua
manutenção. As camadas são dividas em Model – camada responsável por realizar
operações da regra de negócio e persistência aos dados; View – responsável pela
apresentação visual dos dados ao usuário e támbém responder a eventos de
entrada do mesmo; e Controller – responsável pela intermediação entre as duas
camadas anteriores, ou seja, ela realiza a atribuição ou direcionamento de tarefas à
camada responsável por executá-la.
25
Figura 19: Arquitetura Cliente-Servidor. Fonte: <https://www.youtube.com/watch?
v=Y1n7GscW_pg>.
2.2.9.5 Padrões de Projeto
Os padrões de projeto são extremamente importantes para a
resolução de problemas comuns no desenvolvimento, pois oferecem soluções já
testadas e acolhidas pelo mercado. Além disso, facilita a comunicação entre a
equipe de desenvolvimento, pois utiliza-se de conceitos já conhecidos pelos
profissionais.
Para este projeto em específico, utilizou-se os seguintes padrões de
projetos:
1. Abstract Factory: auxilia na criação de famílias ou conjuntos
de objetos relacionados ou dependentes sem mesmo
especificar suas classes concretas;
2. Decorator: permite a atribuição de novas funcionalidades a
um objeto já existente em tempo de execução. Dessa forma,
agrega novas responsabilidades ao objeto;
3. Repository: define interfaces responsáveis por realizar a
persistência de dados, separando-as dos modelos de
negócio;
26
Figure 20: Arquitetura MVC - Model-View-Controller.
Fonte: Google Imagens.
4. Singleton: é indicado para uso quando há a necessidade de
criar e manter uma única instância de determinada classe,
acessível globalmente;
2.2.9.6 Tecnologias Aplicadas
Para o desenvolvimento do sistema em questão, definiu-se a PHP –
PHP HyperText Preprocessor – como linguagem de programação principal. O PHP
trabalha diretamente do lado do servidor e portanto realiza procedimentos internos
que exigem comunicação entre serviços diversos, como por exemplo, banco de
dados e gerenciamento de arquivos.
Como solução para o SGBD – Sistema de Gerenciamento de Banco
de Dados - definiu-se o MySQL. O MySQL é um SGBD que utiliza a linguagem SQL
– Structured Query Language (Linguagem de Consulta Estruturada) - como
interface e por causa de suas caracterísicas como: simplicidade, portabilidade e
compatibilidade; é um dos SGBDs mais populares do mercado.
2.2.9.7 Frameworks
Um framework pode ser considerado como uma abstração, e
através de suas interfaces e componentes, provê funcionalidades genéricas. Por
terem alta influência na produtividade, são muitos utilizados em projetos de software.
Para este projeto, utilizou-se os seguintes frameworks:
a) CakePHP – oferece diversos componentes para funcionalidades
comuns como autenticação, gerenciamento de seções e segurança;
b) Bootstrap – framework para desenvolvimento ágil de interfaces
gráficas para aplicações web.
2.2.9.8 Ferramentas
Todo projeto de software exige um ambiente para desenvolvimento,
onde reúne-se as principais ferramentas utilizadas para simplifcar e facilitar o
processo de construção do produto, desde a etapa de projeto à implementação e
27
testes. Para o desenvolvimento do sistema PulseConsumo montou-se um ambiente
de desenvolvimento contendo o Apache Server como servidor, Visual Studio Code
como editor de códigos e o phpMyAdmin como sistema para administração de banco
de dados.
Quanto a ferramenta CASE – Computer Aided Software Egineering
– utilizou-se o software StarUML para elaboração dos diagramas da UML.
2.3 Página de Recarga de Pulseira
Abaixo, podemos ver a página para recarga de pulseiras,
desenvolvida com a ajuda das ferramentas e tecnologias supracitadas. Essa página
realiza a leitura para identificação via radiofrequência através da comunicação com o
leitor. Dessa forma, caso a pulseira esteja cadastrada no sistema, seus dados são
exibidos em tela, permitindo ao atendente realizar a recarga através da confirmação
do valor e do formulário.
28
Figura 21: Página de Recarga de Pulseira. Fonte: autor.
3 CONCLUSÃO
O mercado de desenvolvimento de soluções tecnológicas
inevitavelmente, se torna mais exigente a cada dia. A demanda por tecnologias cada
vez mais sofisticadas e eficientes proporciona um cenário produtivo e desafiador,
onde são estabelecidas as melhores práticas para o desenvolvimento profissional de
software, com o intuito de oferecer qualidade ao produto e satisfação ao usuário
final.
Diante deste fato, a adoção de práticas padronizadas e o
acompanhamento do projeto são fundamentais para evitar problemas futuros
resultantes de uma má gestão como: superfaturamento e o estouro de prazos. Visto
que estes participam das principais restrições que permeiam o desenvolvimento de
um projeto de sucesso, segundo o Guia PMBOK® Quinta Edição.
 Portanto, para auxiliar neste objetivo, existem as metodologias de
desenvolvimento de software, classificadas em metodologias tradicionais ou
dirigidas à plano e as metodologias ágeis, na qual cada uma aborda diferentes
perspectivas de desenvolvimento adequadas para diferentes tipos de organização e
projetos. Como resultado de alguma das etapas e atividades destas metodologias e
seus respectivos processos, obtemos artefatos – que são extremamente importantespara documentar e construir a “história” de um software.
Um software bem documentado reflete a qualidade e a confiança de
um produto final de software. Logo, os esforços exigidos para sua evolução e
manutenção podem ser reduzidos quando tem-se em mente o controle e o
monitoramento dos processos regentes.
Ao término deste trabalho, evidencia-se que a arte do
desenvolvimento de software profissional possui em seu núcleo a síntese de várias
áreas do conhecimento que trabalham em conjunto para a resolução de problemas
muitas vezes complexos. E devido ao crescimento contínuo de dependência da
sociedade por sistemas complexos, é necessário a produção de sistemas confiáveis
de forma econômica e rápida. Assim, objetiva a Engenharia de Software.
29
REFERÊNCIAS
Alessandro. Conheça os Padrões de Projeto. 2005. Disponível em:
<https://www.devmedia.com.br/conheca-os-padroes-de-projeto/957>. Acesso em: 11
mai. 2019.
ARTIA. Gestão de Projetos: o que é e TUDO sobre como gerenciar projetos .
Disponível em: <https://artia.com/blog/gestao-de-projetos-o-que-e-para-que-serve/>.
Acesso em: 11 mai. 2019.
CAMARGO, Robson. EAP e cronograma de projetos: entenda tudo. 2018.
Disponível em: <https://robsoncamargo.com.br/blog/EAP-e-cronograma-de-projetos-
entenda-tudo>. Acesso em: 11 mai. 2019.
Daiany. Gestão de Projetos: O Gerenciamento de Escopo. 2015. Disponível em:
<https://blogdaqualidade.com.br/gestao-de-projetos-o-gerenciamento-de-escopo/>.
Acesso em: 11 mai. 2019.
HIGA, Paulo. O que é XAMPP e para que serve. 2012. Disponível em:
<https://www.techtudo.com.br/dicas-e-tutoriais/noticia/2012/02/o-que-e-xampp-e-
para-que-serve.html>. Acesso em: 11 mai. 2019.
LIBERATO, Rafael. Como fazer um gerenciamento de tempo de forma eficaz.
2018. Disponível em: <https://www.senior.com.br/blog/como-fazer-um-
gerenciamento-de-tempo-de-forma-eficaz/>. Acesso em: 11 mai. 2019.
MAITINO NETO, Roque. Engenharia de software. Lodrina: Editora e Distribuidora
Educacional S.A., 2016. 216p.
MONTES, Eduardo. Plano de gerenciamento de qualidade. 2018. Disponível em:
<https://escritoriodeprojetos.com.br/plano-de-gerenciamento-da-qualidade>. Acesso
em: 11 mai. 2019.
Professor Digital. Levantamento e análise de requisitos funcionais e não
funcionais. Disponível em: <https://www.luis.blog.br/levantamento-analise-
requisitos-funcionais-nao-funcionais/>. Acesso em: 11 mai. 2019.
Project Management Institute. Um guia do conhecimento em gerenciamento de
projetos (guia PMBOK©). 5. ed. São Paulo: Saraiva, 2014.
SILVA JUSTO, Andreia. O que é um Escopo do Produto e Escopo de Projeto?.
2018. Disponível em: <https://www.euax.com.br/2018/08/o-que-e-escopo-de-projeto-
escopo-do-produto/>. Acesso em: 11 mai. 2019.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson Prentice
Hall, 2011.
30
TERRA, Paulo Henrique. Projeto orientado a objetos. Londrina: Editora e
Distribuidora Educacional S.A., 2018. 144p.
VENTURA, Plínio. O que é UML – o que é, quando usar, e muito mais!. 2019.
Disponível em: <https://www.ateomomento.com.br/diagramas-uml/>. Acesso em: 11
mai. 2019.
31
	SUMÁRIO
	1 INTRODUÇÃO
	2 DESENVOLVIMENTO
	2.1 Prototipação
	2.1.1 Diagrama de Casos de Uso
	2.1.2 Descrição de Casos de Uso
	2.1.3 Prototipação de Interface Gráfica de Usuário
	2.2 Plano de Projeto
	2.2.1 Objetivo
	2.2.2 Justificativa
	2.2.3 Escopo
	2.2.3.1 EAP – Estrutura Analítica de Projeto
	2.2.4 Mapa Mental
	2.2.5 Gerenciamento do tempo
	2.2.6 RUP (Rational Unified Process)
	2.2.7 Plano de qualidade
	2.2.8 Business Process Reenginering
	2.2.9 Plano de Desenvolvimento
	2.2.9.1 Diagrama de Casos de Uso
	2.2.9.2 Diagrama de Classes
	2.2.9.3 Mapeamento de Requisitos Funcionais e Não Funcionais
	2.2.9.4 Arquitetura do Sistema
	2.2.9.4.1 Arquitetura Física
	2.2.9.4.2 Arquitetura Lógica
	2.2.9.5 Padrões de Projeto
	2.2.9.6 Tecnologias Aplicadas
	2.2.9.7 Frameworks
	2.2.9.8 Ferramentas
	2.3 Página de Recarga de Pulseira
	3 CONCLUSÃO
	REFERÊNCIAS