Epígrafe

“Que todo o nosso esforço esteja sempre focado no desafio à impossibilidade. Todas
as grandes conquistas humanas vieram daquilo que parecia impossível.”

_______________

Charles Chaplin

Página | I
Dedicatória

Dedico este trabalho em primeiro lugar a Deus, o maior orientador da minha vida, ele
nunca me abandonou nos momentos de necessidade. Ao professor Nelson José que
me auxiliou na germinação das ideias e durante todo o processo de desenvolvimento
deste presente trabalho.

Aos meus pais em especial a minha querida mãe Teresa Manuel (1958 - 2021), cujo
empenho em me educar sempre veio em primeiro lugar. Aqui estão os resultados dos
seus esforços. Com muita gratidão. E por último aos meus amigos e colegas que
ajudaram na possível concretização deste trabalho.

Página | II
Agradecimento

A Deus, pela minha vida, e por me permitir ultrapassar todos os obstáculos

encontrados ao longo da realização deste trabalho. Aos meus pais e irmãos, que me
incentivaram nos momentos difíceis e compreenderam a minha ausência enquanto eu
me dedicava à realização deste trabalho. Aos professores, pelas correções e
ensinamentos que me permitiram apresentar um melhor desempenho no meu
processo de formação profissional ao longo do curso.

Aos meus colegas de curso, com quem convivi intensamente durante os últimos anos,
pelo companheirismo e pela troca de experiências que me permitiram crescer não só
como pessoa, mas também como formando. À instituição de ensino essencial no meu
processo de formação profissional, pela dedicação, e por tudo o que aprendi ao longo
dos anos do curso.

Página | III
índice

Epígrafe ....................................................................................................................... I

Dedicatória ................................................................................................................. II

Agradecimento .......................................................................................................... III

Resumo ................................................................................................................... XIII

Abstract ................................................................................................................... XIV

INTRODUÇÃO ........................................................................................................... 1

Problemática ........................................................................................................... 2

Hipótese .................................................................................................................. 2

Justificativa ............................................................................................................. 3

Objectivo Geral ....................................................................................................... 4

Objectivos Específicos ........................................................................................ 4

Delimitação ............................................................................................................. 4

Limitações ............................................................................................................... 4

Estrutura do Trabalho ............................................................................................. 5

CAPÍTULO I - ENQUADRAMENTO TEÓRICO .......................................................... 6

1.1. Sites e Sistema Web ..................................................................................... 6

1.2. Desenvolver um sistema web ........................................................................ 7

1.3. Funcionamento da Web ................................................................................ 7

1.3.1. Padrões da Web .................................................................................. 8

1.3.2. Navegador .............................................................................................. 8

1.3.3. HTTP ...................................................................................................... 9

1.3.4. HTTPS .................................................................................................... 9

1.3.5. Base de Dados ....................................................................................... 9

1.4. Etapa do desenvolvimento do sistema ........................................................ 10

1.4.1. Levantamento e Análise de Requisitos ................................................. 10

Página | IV
 1.4.2. Projecto ................................................................................................. 11

1.4.3. Implementação ..................................................................................... 12

1.4.4. Testes ................................................................................................... 12

1.4.5. Implantação e Manutenção ................................................................... 13

1.5. Vantagens de um Sistema de Gestão ......................................................... 13

1.5.1 Facilidade de acesso ............................................................................ 14

1.5.1 Segurança das informações ................................................................. 14

1.5.2 Mobilidade............................................................................................. 14

1.5.3 Controle da organização empresarial ................................................... 14

1.5.4 Copia de segurança de dados .............................................................. 14

1.6 Estudo de caso ............................................................................................ 15

1.6.1 Sobre a Instituição ................................................................................ 15

1.6.2 Serviços Disponibilizados ..................................................................... 16

1.6.3 Polícia Nacional de Angola ................................................................... 17

1.6.4 Definição e Natureza ............................................................................ 17

1.6.5 Dependência ......................................................................................... 18

1.6.6 Princípios e Valores .............................................................................. 18

1.6.7 Posicionamento Estratégico.................................................................. 18

1.6.8 Atribuições Essenciais .......................................................................... 19

1.6.9 Organigrama ......................................................................................... 19

1.6.10 Distintivos .......................................................................................... 20

1.6.11 Localização........................................................................................ 20

CAPÍTULO II- METODOLOGIA E FERRAMENTAS................................................. 21

2.1 Metodologia ................................................................................................. 21

2.2 Tipo de Pesquisa ......................................................................................... 21

2.3 Técnica para a Colecta de Dados ............................................................... 21

Página | V
 2.3.1 Pesquisa Bibliográfica ........................................................................... 22

2.3.2 Pesquisa Documental ........................................................................... 22

2.3.3 Levantamento de requisito .................................................................... 22

2.4 Identificação dos interessados no sistema .................................................. 24

2.5 Características do sistema .......................................................................... 24

2.6 Requisitos do Software ................................................................................ 24

2.6.1 Requisitos Funcionais ........................................................................... 25

2.6.2 Requisitos não funcionais ..................................................................... 26

2.7 Requisitos homem máquina ........................................................................ 26

2.8 Implementação do sistema .......................................................................... 27

2.8.1 HTML .................................................................................................... 27

2.8.2 PHP ...................................................................................................... 28

2.8.3 Astah ..................................................................................................... 29

2.8.4 UML ...................................................................................................... 29

2.9 Ferramentas ................................................................................................ 30

2.9.1 Visual Studio Code ............................................................................... 30

2.9.2 Sublime Text ......................................................................................... 30

2.9.3 XAMPP ................................................................................................. 31

2.9.4 MySQL .................................................................................................. 31

2.9.5 Bootstrap............................................................................................... 32

2.9.6 Laravel .................................................................................................. 32

2.10 Modelação do sistema: Engenharia de software...................................... 33

2.10.1 Processo de software ........................................................................ 33

2.10.2 Modelo de processo genérico ............................................................ 34

2.10.3 Modelo de processo evolucionário prototipação ................................ 34

2.11 Diagrama de caso de uso ........................................................................ 34

Página | VI
 2.11.1 Diagrama caso de uso administrador ................................................ 35

2.11.2 Diagrama caso de uso policia ............................................................ 35

2.11.3 Diagrama caso de uso condutor ........................................................ 36

2.11.4 Diagrama caso de uso proprietario .................................................... 36

2.11.5 Diagrama de caso de uso Login ........................................................ 37

2.12 Narração caso de uso .............................................................................. 38

2.12.1 Caso de uso login .............................................................................. 38

2.13 Diagrama de sequência ........................................................................... 39

2.13.1 Diagrama de sequência login ............................................................ 40

2.13.2 Diagrama de sequência criar utilizador .............................................. 41

2.13.3 Diagrama de sequência excluir utilizador .......................................... 42

2.14 Diagrama de actividade............................................................................ 43

2.14.1 Diagrama de actividade login ............................................................ 43

2.15 Diagrama de classe.................................................................................. 43

2.16 Teste ........................................................................................................ 44

2.16.1 Teste de caixa preta .......................................................................... 44

2.16.2 Teste de caixa branca ....................................................................... 46

2.17 Segurança ................................................................................................ 48

CAPÍTULO III- RESULTADOS ................................................................................. 49

3.1 Interfaces..................................................................................................... 49

3.1.1 Página inicial do sistema....................................................................... 49

3.1.2 Tela de login ......................................................................................... 49

3.1.3 Página de cadastro de proprietário de veículos .................................... 50

3.1.4 Página de cadastro do condutor ........................................................... 51

3.1.5 Página de inserção do veículo ao sistema ............................................ 51

3.1.6 Página de associar veículo ao condutor ............................................... 52

Página | VII
 3.1.7 Página de cadastro de polícia ao sistema............................................. 52

3.1.8 Página de adição de multas .................................................................. 53

CONCLUSÃO ........................................................................................................... 54

BIBLIOGRAFIA ......................................................................................................... 55

APÊNDICE A – CRONOGRAMA DAS ACTIVIDADES ............................................ 58

APÊNDICE B – TABELA DE CUSTOS .................................................................... 59

Página | VIII
Índice de Figuras

Figura 1- Esquema de funcionamento da web ........................................................... 7

Figura 2- Diferentes tipos de navegadores ................................................................. 8

Figura 3- Base de dados ............................................................................................ 9

Figura 4-Sistema de gestão...................................................................................... 13

Figura 5-Organigrama da instituição......................................................................... 19

Figura 6- Classe dos distintivos ................................................................................ 20

Figura 7- Logotipo HTML .......................................................................................... 27

Figura 8- Logotipo PHP ............................................................................................ 28

Figura 9- Logotipo Astah .......................................................................................... 29

Figura 10- Logotipo UML .......................................................................................... 29

Figura 11- Logotipo VS-Code ................................................................................... 30

Figura 12- Logotipo Sublime Text ............................................................................. 30

Figura 13- Logotipo XAMPP ..................................................................................... 31

Figura 14- Logotipo MySQL...................................................................................... 31

Figura 15- Logotipo Bootstrap .................................................................................. 32

Figura 16- Logotipo Laravel ...................................................................................... 32

Figura 17- Modelo de processo evolucionário prototipação ..................................... 34

Figura 18- Caso de uso Adm .................................................................................... 35

Figura 19- Caso de uso polícia ................................................................................. 35

Figura 20- Caso de uso condutor ............................................................................. 36

Figura 21- caso de uso proprietário .......................................................................... 36

Figura 22- Caso de uso login.................................................................................... 37

Figura 23- Diagrama de sequência login .................................................................. 40

Figura 24- Diagrama de sequência criar utilizador ................................................... 41

Figura 25- Diagrama de sequência excluir utilizador ................................................ 42

Página | IX
Figura 26- Diagrama de actividade login .................................................................. 43

Figura 27-Diagrama de Classe ................................................................................. 44

Figura 28- Página inicial ........................................................................................... 49

Figura 29- login......................................................................................................... 50

Figura 30- cadastro de proprietário de veículos ....................................................... 50

Figura 31- cadastro do condutor ............................................................................... 51

Figura 32- inserção do veículo ao sistema ............................................................... 51

Figura 33- associar veículo ao condutor ................................................................... 52

Figura 34- cadastro de polícia ao sistema ................................................................ 52

Figura 35- adição de multas ..................................................................................... 53

Figura 36- Cronograma ............................................................................................ 58

Página | X
Índice de tabelas

Tabela 1- Nível de restrição...................................................................................... 37

Tabela 2-Caso de uso login ...................................................................................... 38

Tabela 3- Teste de caixa preta administrador do sistema ........................................ 45

Tabela 4- Teste de caixa preta cadastrar utilizador .................................................. 46

Tabela 5-Teste de caixa branca verificação dos campos ......................................... 47

Tabela 6- Custo ........................................................................................................ 59

Página | XI
Lista de siglas e Abreviaturas

BD – Bancos de dados;

CB – Caixa Branca;

CERN – Conseil Européen pour la Recherche Nucléaire;

CP – Caixa Preta;

CSS - Cascading Style Sheets;

DNS – Domain Name System;

FTP – File Tranfer Protocol;

HTML – Hyper Text Markup Language;

HTTP – Hypertext Transfer Protocol;

HTTPS – HyperText Transfer Protocol Secure;

IP – Internet Protocol;

JS – JavaScript;

OSI – Open Systems Interconnection;

PHP – Hipertext Pre-Processor;

SGBD – Sistema Gestor de Base de Dados;

SQL – Strutured Query Language (Linguagem de Consulta Estruturada);

SSL – Secure Sockets Layer;

TCP – Transmission Control Protocol;

TLS – Transport Layer Security;

UML – Unified Modeling Language;

URL – Uniform Resource Locator;

Página | XII
Resumo

O presente projecto apresenta o desenvolvimento e implementação de um sistema

web de identificação automática de condutores para a Direção Nacional de Viação e
Transito. Com a finalidade de armazenar todas as informações dos condutores, para
se saber a legalização e evitar outros constrangimentos, também o sistema tem a
capacidade de denuncia onde poderá se fazer denuncias anonimas sobre os
condutores, e uma área onde os condutores poderão informar sobre as condições das
vias de transito. O sistema permitira com que a polícia de transito fazer a visualização
dos dados dos condutores, declarações e outros. O sistema será eficiente e de
interface amigável, para uso interno da Direção Nacional de Viação e Transito. Tendo
em conta a confidencialidade, integridade e restrições da informação, bem como a
implementação de uma tecnologia de comunicação segura e actual para certificar a
segurança e estabilidade do sistema. O sistema será desenvolvido em PHP.

Palavra-chave: Sistema; Condutores; PHP; Web.

Página | XIII
Abstract

The present project presents the development and implementation of a web-based

automatic driver identification system for the National Directorate of Traffic and
Transportation. With the purpose of storing all the information of the drivers, to know
the legalization and to avoid other constraints, the system also has the capacity to
report where anonymous reports can be made about the drivers, and an area where
the drivers can inform about the conditions of the transit routes. The system will allow
the traffic police to view driver data, statements and others. The system will be efficient
and user-friendly, for internal use by the National Traffic and Transportation
Directorate. Taking into account the confidentiality, integrity and restrictions of the
information, as well as the implementation of a secure and current communication
technology to certify the security and stability of the system. The system will be
developed in PHP.

Keyword: System; Conductors; PHP; Web.

Página | XIV
INTRODUÇÃO

Com o mundo cada vez mais tecnológico e informatizado, as empresas estão

buscando a melhor forma de desenvolver suas funções perante o mercado e a
sociedade em que estão envolvidas. É sabido que o uso da tecnologia dá velocidade
e precisão no gerenciamento de processos internos, facilitando a organização das
empresas.

A tecnologia está presente em quase tudo no cotidiano, um dos indícios desse cenário
é a possibilidade de resolver a maioria dos problemas via internet. Dessa forma, é
preciso que as empresas se adaptem à essa realidade, redefinindo a sua organização
interna.

Neste projecto vamos resolver e facilitar o trabalho e serviço da Direção Nacional de

Viação e Transito para melhorar os procedimentos administrativos e a lentidão na
interpelação policial.

Página | 1
Problemática

As metodologias de interpelação policial já não são aplicáveis em tempo actuais onde

a tecnologia está a se estabelecer em todos os sectores, assim propomos novos
métodos e mecanismos de interpelação policial.

Como é sabido que a gestão da informação por intermédio de papéis, traz muitos
transtornos tais como: perda de informação, perda de tempo, trabalho desnecessário
na interpelação policial para colher informações do condutor a DNVT encontra-se
nestas condições. Também um dos problemas que tem se deparado esta em fazer
denuncia de alguns condutores e em saber/informar o estado de algumas vias de
transito.

Com esses problemas detectados teremos que impor todo o conhecimento aprendido
para trazer uma solução viável, rápida e segura para a solução deste problema, de
forma que a DNVT possa interpelar melhor os condutores, as denuncias anonimas
dos condutores sejam feitas de forma eficaz e que os condutores saibam o estado
das vias de transito.

Que benefícios serão observados, após a implementação do sistema de identificação

automática de condutores?

Hipótese

Desenvolver um sistema de identificação automática de condutores pode permitir a

optimização na interpelação policial, na denuncia anonima de condutores e na troca
de informação sobre as condições das vias de transito, de modo que haja redução do
tempo gasto na realização de algumas tarefas.

Na perspectiva do ADM o sistema possibilitará ter os dados de todos os condutores,

de forma a identificar a veracidade dos seus dados e se realmente estão legalizados,
permitindo também saber o proprietário de uma determinada viatura e os condutores
autorizados a circular com a viatura.

Na perspectiva do condutor o sistema possibilitará a organização dos seus dados e a

possibilidade de fazer denuncias concernentes a outros condutores ou mesmo de
agentes da ordem, o sistema possibilitará também que ele informe sobre a condição
das vias de transito.

Página | 2
Justificativa

Tendo em vista a evolução tecnológica em diferentes sectores, surge a necessidade

de melhoria na forma como são feitas as identificações dos condutores, bem como os
condutores podem efectuar as suas denuncias e saber/informar sobre a condição das
vias de transito, já que o software fornecerá diversas informações e métodos quanto
ao controle e armazenamento de informações.

Para a área académica o tema é relevante porque muitos sistemas são desenvolvidos
e actualizados devido a legados deixados, o tema aumentará o conhecimento sobre
sistemas de identificação automática já que bibliografias sobre o assunto é limitado
no território nacional.

Para a sociedade o impacto que o tema terá consistirá na forma de se adaptar as

inovações tecnológicas vendo que tudo agora esta sendo digitalizado para uma
melhor disponibilidade e segurança da informação.

Para a vida pessoal o tema em questão resolve constrangimento concernente ao

tempo que as interpelações policiais levam mesmo o condutor estando devidamente
legalizado, como se diz na gíria tempo é dinheiro e será de extrema importância saber
o estado de algumas vias de transito.

Página | 3
Objectivo Geral

• Desenvolver e implementar um sistema de identificação automática de

condutores para a Direção Nacional de Viação e Transito.

Objectivos Específicos

• Desenvolver um sistema web;

• Realizar cadastro de condutores/policia/proprietários;

• Realizar cadastro de informações do veículo;

• Permitir a troca de informações sobre as condições das vias de transito;

• Criar formulário de denuncias de condutores / polícia;

Delimitação

A presente pesquisa estará estratificada em fazer a gestão das informações

relacionadas com os condutores naquilo que é automatizar a sua identificação.
Também será organizado em uma base de dados as informações concernentes aos
automóveis e o seu proprietário. Bem como as informações sobre condições das vias
de transito e denuncias anonimas.

Limitações

Durante a Elaboração do trabalho, foram encontradas algumas limitações como por

exemplo:

• Restrições na aquisição das informações necessárias, concernente á DNVT,

dado ao provável sigilo interno e o estado pandémico que o país se encontra.

• Escassez de bibliografia que falam de sistema Web, mais especificamente

sobre a identificação automática de condutores, para se poder buscar itens
para o melhoramento da pesquisa e o futuro funcionamento do sistema em si.

Página | 4
Estrutura do Trabalho

O trabalho foi elaborado em três (3) capítulos:

• Enquadramento teórico;

o Capítulo I – Neste capítulo é apresentado conceitos teóricos relacionados

com o tema, engenharia de software e sistemas de base de dados
relacionais, dentre outros. Neste capítulo é apresentado o estudo de caso,
os conceitos relativos a generalidade, Visão, Missão, Valores e Áreas de
actuação.

• Metodologia e Ferramentas;

o Capítulo II – Neste capítulo é apresentado a metodologia de pesquisa e de

desenvolvimento utilizadas para a elaboração deste trabalho e as
ferramentas que foram utilizadas na concepção do sistema. Neste capítulo
são apresentados os requisitos da aplicação, diagramas caso de uso,
actividade e de sequência, dentre outros.

• Resultados;

o Capítulo III – Neste capítulo são apresentados os resultados do projecto

desenvolvido, em forma de imagens da aplicação em funcionamento e com
esclarecimentos precisos.

Página | 5
CAPÍTULO I - ENQUADRAMENTO TEÓRICO

Também conhecido como embasamento teórico ou revisão bibliográfica, para fazer

um referencial teórico é necessário consultar as referências bibliográficas que são
condizentes a área de estudo a ser trabalhada, ou seja, verificar as pesquisas
previamente feitas por alguns autores sobre a temática escolhida para ser
desenvolvida. O enquadramento teórico faz parte dos trabalhos científicos e
académicos, e consiste num resumo de discussões já feitas por outros autores sobre
determinado assunto, servindo como base para o desenvolvimento de um tema
específico, no enquadramento teórico também são apresentados os mais importantes
conceitos, justificativas e características sobre o assunto abordado, do ponto de vista
da análise feita por outros autores. (Brainly, 2021)

1.1. Sites e Sistema Web

Normalmente, as pessoas utilizam o termo site quando se referem a blogs, sites de

notícias, sites institucionais, portais, lojas virtuais, entre outros. Já a denominação
Sistema web é muito utilizada para sistemas de gestão empresarial que são
acessados através de navegadores (browsers). Não há uma definição exacta que
diferencie claramente sites e sistemas web. Alguns defendem que os sites são read-
only (somente leitura) enquanto os sistemas web são read-write (leitura e escrita).
Nessa definição, os sites apenas fornecem conteúdo enquanto os sistemas web
podem fornecer e/ou receber conteúdo. Seguindo essa linha de raciocínio, algumas
pessoas gostam de utilizar o grau de interactividade com os utilizadores para
classificar como site ou sistema web. Nessa visão, sistemas web seriam mais
interactivas e os sites menos interativos. Contudo, não há uma medida definida para
calcular esse grau de interatividade e com isso aplicar de forma objetiva essa
classificação. (K19, 2013)

Página | 6
1.2. Desenvolver um sistema web

Para a camada de apresentação, é essencial que o Web Designer conheça

principalmente HTML, CSS e ao menos o básico de JavaScript. Para as linguagens
de programação de lógica, as opções disponíveis no mercado são muitas e com isso
fica muito difícil dominar todas as linguagens, por isso é importante, pelo menos a
princípio, focar em alguma delas como PHP, ASP ou .NET, apesar de existir várias
outras, um editor de texto (Visual Studio Code, bloco de notas, Notepad++, Sublime
Text), um sistema gerenciador de base de dados (no caso de armazenamento de
informações ex: Sql server, mysql). (Portal Web Designer , 2021)

1.3. Funcionamento da Web

Figura 1- Esquema de funcionamento da web

Fonte: ([Link]

Para visualizar uma página web ou outro recurso disponibilizado, normalmente inicia-
se ao digitar uma URL (Uniform Resource Locator) traduzido em português por
localizador padrão de recursos. Porem, a parte da URL referente ao servidor web é
separada e transformada em um endereço IP (Internet Protocol), por um banco de
dados da internet chamado domínio do inglês DNS (Domain Name System). O
navegador estabelece então uma conexão TCP (Transmission Control Protocol) com
o servidor web localizado no endereço IP enviado. Seguidamente o navegador envia
uma requisição HTTP (Hypertext Transfer Protocol) ao servidor solicitando o recurso
indicado pela parte restante da URL. No caso de uma página web típica, o texto HTML
(Hypetext Markup Language) é recebido e interpretado pelo navegador, que realiza
então requisições adicionais para figuras, arquivos de formatação, arquivos de script
e outros recursos que fazem parte da página, o navegador então redireciona a página

Página | 7
para o ecrã do utilizador, de acordo com as descrições dos arquivos que a compõe.
(TANENBAUM, 2003)

1.3.1. Padrões da Web

A funcionalidade da Web é baseada em três padrões:

• Uniform Resource Locator (URL), um sistema que especifica como cada página
de informação recebe um endereço onde pode ser encontrada.

• Hypertext Transfer Protocol (HTTP), um protocolo que especifica como o

navegador e o servidor web comunicam entre si.

• Hypetext Markup Language (HTML), uma linguagem de marcação para

codificar a informação de modo que possa ser exibida em uma grande
quantidade de dispositivos.

1.3.2. Navegador
Figura 2- Diferentes tipos de navegadores

Fonte: ([Link]

O navegador é um programa de computador usado para visualizar recursos da WEB,

como páginas, imagens e vídeos. Também é possível comunicar com o servidor web
a fim de receber ou enviar informações. O primeiro navegador desenvolvido no CERN
(Conseil Européen pour la Recherche Nucléaire) foi a World Wide Web, criado pelo
próprio TIM Berners Lee, em 1990. Mais adiante surgiram outros navegadores como
o Viola, arena, cello, cyberDog, mosaic, webRouser, navegadores que já não são
usados em nossos dias. (Portal Educação, 2021)

Página | 8
1.3.3. HTTP

Conforme TANENBAUM (2003), o HTTP é um protocolo da camada de aplicação do

modelo (OSI) Open Systems Interconnection, utilizado para transferência de dados na
rede mundial de computadores, a World Wide Web.

Este protocolo, utiliza a porta 80 e é usado para a comunicação de aplicações Web

cuja comunicação é feita na linguagem HTML.

Para que haja comunicação com o servidor, utiliza-se comandos próprios, os quais
não estão na linguagem HTML.

1.3.4. HTTPS

Segundo VARRELA (2008), Protocolo de transferência de hipertexto seguro do inglês

HyperText Transfer Protocol Secure (HTTPS) é uma implementação do protocolo
HTTP sobre uma camada de segurança Secure Sockets Layer (SSL) ou do Transport
Layer Security (TLS), essa camada adicional permite que os dados sejam transmitidos
através de uma conexão criptografada e que se verifique a autenticidade do servidor
e do cliente através de certificados digitais. A porta TCP usada por norma para o
protocolo HTTPS é a 443. O protocolo HTTPS é normalmente utilizado quando se
deseja evitar que a informação transmitida entre o cliente e o servidor seja visualizada
por terceiros, como por exemplo no caso de compras on-line ou no envio de qualquer
informação confidencial.

1.3.5. Base de Dados

Figura 3- Base de dados

Fonte: ([Link]

Página | 9
De acordo com Abraham (2012.p.42), “Uma base de dados é um local onde pode ser
guardada informação. A informação pode ser consultada, alterada, apagada, na
totalidade ou parcialmente, através de uma aplicação conhecida como Sistema de
Gestão de Base de Dados (SGBD)”.

Ao contrário dos documentos de diversos tipos, em que a informação é colocada

conforme o utilizador entender, numa base de dados a informação encontra-se
estruturada, facilitando assim a utilidade e longevidade da informação, que de outra
forma faria sentido para um utilizador num dado momento, e assim poderá ser útil para
muitos utilizadores num período mais longo de tempo. Uma base de dados pode ter
diversos modelos que definem como a informação é organizada internamente, os mais
comuns são:

[Link]. Modelo hierárquico

Em que cada registo possui um e um só pai, tal como os ficheiros e pastas no

computador, não podendo um registo possuir mais que um pai.

[Link]. Modelo em rede

São idênticos ao modelo hierárquico, mas cada registo pode possuir mais que um pai.

[Link]. Modelo relacional

Para modelo relacional são definidas para cada tipo de entidade uma tabela, e para
cada atributo de uma entidade uma coluna na tabela. As entidades em si são
colocadas em linhas na tabela correspondente, com o valor de cada atributo na
respectiva coluna.

1.4. Etapa do desenvolvimento do sistema

De acordo com P. Jalote (2008:p.66), diz que “existem 5 etapas no desenvolvimento

de um sistema” que são:

1.4.1. Levantamento e Análise de Requisitos

Esta actividade tem como objectivo, compreender o problema, dando aos

desenvolvedores e utilizadores, a mesma visão do que deve ser construído para
resolução do problema. Desenvolvedores e clientes, em conjunto, buscam levantar e
priorizar as necessidades dos futuros utilizadores do software (necessidades essas
denominadas como requisitos).
Página | 10
O Levantamento de Requisitos é a etapa mais importante, no que diz respeito ao
retorno de investimentos no projecto. Vários projectos são abandonados pelo baixo
levantamento de requisitos, ou seja, membros da equipe não disponibilizaram tempo
suficiente para essa fase do projecto, em compreender as necessidades dos clientes
em relação ao sistema a ser desenvolvido.

E como um sistema de informações geralmente é utilizado para automatizar

processos de negócio em uma organização, esses processos da organização devem
ser bem compreendidos para que o restante das actividades do processo de
desenvolvimento flua de acordo com as reais necessidades do cliente.

Na análise de Requisitos esta etapa, também chamada de especificação de

requisitos, é onde os desenvolvedores fazem um estudo detalhado dos dados
levantados na actividade anterior. De onde são construídos modelos a fim de
representar o sistema de software a ser desenvolvido.

O interesse nessa actividade é criar uma estratégia de solução, sem se preocupar

como essa estratégia será realizada, ou seja, utilizar as necessidades dos clientes,
depois de compreendido o problema, para resolução do problema solicitado. Assim é
necessário definir o que o sistema deve fazer, antes de definir como o sistema irá
fazer. O que acontece com frequência, é quando as equipes de
desenvolvimento partem para a solução do problema do software, sem antes ter
definido completamente o problema em questão.

Nesta fase deve-se então realizar a validação e verificação dos modelos construídos,
antes de partir para solução do problema.

Validação: tem por objectivo, assegurar que o sistema de software está atendendo às
reais necessidades do cliente;

Verificação: verifica se os modelos construídos na análise estão em conformidade

com os requisitos do cliente.

1.4.2. Projecto

Nesta fase é que deve ser considerado, como o sistema funcionará internamente, para
que os requisitos do cliente possam ser atendidos. Alguns aspectos devem ser
considerados nessa fase de projecto do sistema, como: arquitectura do

Página | 11
sistema, linguagem de programação utilizada, Sistema Gerenciador de Banco de
Dados (SGBD) utilizado, padrão de interface gráfica, entre outros.

No projecto é gerada uma descrição computacional, mencionando o que o software

deve fazer, e deve ser coerente com a descrição realizada na fase de análise de
requisitos.

O projecto possui duas actividades básicas:

• Projecto da arquitectura (ou projecto de alto nível);

• E projecto detalhado (ou projecto de baixo nível).
Em um processo de desenvolvimento orientado a objectos, o projecto da arquitectura
normalmente é realizado por um arquitecto de software. O projecto da
arquitectura visa distribuir as classes de objectos relacionados do sistema em
subsistemas e seus componentes, distribuindo também esses componentes pelos
recursos de hardware disponíveis.

Já no projecto detalhado, são modeladas as relações de cada módulo com o objectivo

de realizar as funcionalidades do módulo. Além de desenvolver o projecto de interface
com o utilizador e o projecto de banco de dados.

1.4.3. Implementação

Nessa etapa, o sistema é codificado a partir da descrição computacional da fase de

projecto em uma outra linguagem, onde se torna possível a compilação e geração do
código executável para o desenvolvimento do software.

Pode-se também utilizar na implementação ferramentas de software e bibliotecas de

classes preexistentes para agilizar a actividade, como também o uso de ferramentas
CASE (ferramentas automatizadas que tem como objectivo auxiliar o desenvolvedor
de sistemas em uma ou várias etapas do ciclo, de desenvolvimento de software), que
dinamizam o processo de desenvolvimento, nas várias actividades, onde inclui-se
geração de código fonte e documentação.

1.4.4. Testes

Diversas actividades de testes são executadas a fim de se validar o produto de

software, testando cada funcionalidade de cada módulo, buscando, levando em
consideração a especificação feita na fase de projecto. Onde o principal resultado é o

Página | 12
relatório de testes, que contém as informações relevantes sobre erros encontrados no
sistema, e seu comportamento em vários aspectos. Ao final dessa actividade, os
diversos módulos do sistema são integrados, resultando no produto de software.

1.4.5. Implantação e Manutenção

Por fim a implantação compreende a instalação do software no ambiente do utilizador.

O que inclui os manuais do sistema, importação dos dados para o novo sistema e
treinamento dos utilizadores para o uso correcto e adequado do sistema. Em alguns
casos quando da existência de um software anterior, também é realizada a migração
de dados anteriores desse software.

Manutenção é a última etapa do processo de desenvolvimento de sistemas é a

manutenção. Ela inicia logo após a implantação e não terá fim, ou seja, existirá
enquanto o sistema existir.

A manutenção é uma etapa de muitas controvérsias, por isto é importante existir um

documento que regulamente o que é manutenção, quais as responsabilidades de
clientes, utilizadores e desenvolvedores, bem como os custos envolvidos nessas
actividades.

1.5. Vantagens de um Sistema de Gestão

Figura 4-Sistema de gestão

Fonte: ([Link]

Um sistema de gestão empresarial que integra diferentes áreas facilitando o trabalho

de toda a equipe da empresa. Veja abaixo algumas vantagens que fazem um sistema
de gestão ser uma óptima escolha para empresas que desejam reduzir custos, ter um
maior controlo gerêncial e sincronia de dados e informações.

Página | 13
1.5.1 Facilidade de acesso

O acesso a informações armazenado num sistema de gestão é feito de uma maneira

muito rápido directamente no computador, notebook ou tablet, via internet
(remotamente).

1.5.1 Segurança das informações

Com um sistema de gestão os dados têm mais segurança uma vez que nem todos
terão acesso as informações sem permissão uma vez que terá de digitar o seu nome
de utilizador e a sua palavra passe (fazer autenticação) para ter acesso ao sistema
terá de ser cadastrado antes e só assim terá o acesso ao sistema fazendo o login.

1.5.2 Mobilidade

Os colaboradores de uma empresa podem a cessar um software em qualquer lugar e

qualquer momento (remotamente), necessitando apenas ter acesso à internet e
licença da empresa.

1.5.3 Controle da organização empresarial

Os gestores da empresa ganham um maior controlo, podendo a cessar informações

de qualquer lugar a qualquer momento (remotamente).

1.5.4 Copia de segurança de dados

Com o Sistema de gestão a cópia de segurança das informações é feito de forma

automática, evitando a perda de documentos e a necessidade de guardar arquivos
impressos.

Página | 14
1.6 Estudo de caso

1.6.1 Sobre a Instituição

A funcionalidade da Direcção Nacional de Viação e Trânsito (DNVT) está

regulamentada no Estatuto Orgânico da Polícia Nacional de Angola, aprovado pelo
decreto 152/19, de 15 de Maio.

Incumbe, entre outras competências, à DNVT, zelar pelo cumprimento:

• Das leis do trânsito, segurança e prevenção rodoviária;

• Emissão de licenças para condução de veículos automóveis;
• Organização do cadastro de condutores, cobrança, registo e controlo de taxas
de circulação e multas;
• Licenciamento, inspecção e controlo das escolas de condução e atribuição de
matrículas a viaturas;

As profundas alterações verificadas no país, quer a nível político, como social e

económico, quer ao nível da realidade rodoviária, da evolução da própia indústria
automóvel de forma particular, ditaram uma alteração profunda do código de Estrada
e seu Regulamento.

Consequentemente, as atribuições da DNVT, mostraram-se desajustadas à actual

realidade estrutural e operacional da Polícia Nacional, o que levou a uma revisão e
actualização do Regulamento Orgânico antes em vigor.

Por outro lado, a optimização do funcionamento da DNVT, através da informação,

adopção de tecnologia moderna nos serviços, criação de um banco de dados nacional
e desconcentração administrativa, obrigou também à reestruturação deste Órgão
Institucional.

Assim sendo, o rigoroso cumprimento das incumbências acima mencionadas

encontra-se estabelecido em total conformidade com os novos procedimentos
administrativos em vigor.

Página | 15
1.6.2 Serviços Disponibilizados

Na estrutura orgânica da DNVT existe várias direcções que disponibilizam vários

serviços tais como:

Carta de condução:

• Habilitação para conduzir (exame);

• Renovação por caducidade;
• Substituição por mau estado de conservação;
• Alteração do nome;
• Mudança de residência;
• Pedido de 2ª via;
• Troca da carta estrangeira;
• Autenticidade e certidão da carta de condução;
• Abertura de escola de condução.

Livrete de circulação:

• Registo inicial / solicitação de matrícula;

• Inspecção;
• Livrete;
• Cancelamento de matrícula.

Outros Serviços:

• Pedido de transladação de veículo para o exterior;

• Inspecção de veículos para licença de aluguer;
• Pedido de autorização especial (transportes dos trabalhadores);
• Declaração para transladação para as províncias.

Página | 16
1.6.3 Polícia Nacional de Angola

A garantia da ordem, a defesa da segurança e tranquilidade públicas, o

asseguramento e protecção das instituições, dos cidadãos e os respectivos bens,
contra criminalidade violenta ou organizada e outros tipos de ameaças e riscos, são
fundamentos de valor sobre a existência da Polícia Nacional de Angola. Enquanto
Órgão de Estado, a Constituição da República estatui no Artigo 210.º a Polícia
Nacional de Angola como uma instituição nacional, permanente, regular e apartidária,
organizada na base da hierarquia e da discíplina, incumbida da protecção e
asseguramento policial do País, no estrito respeito pela Constituição e pelas leis, bem
como pelas convenções internacionais de que Angola seja parte. A Polícia Nacional é
composta exclusivamente por cidadãos angolanos, sendo a sua organização única
para todo o território nacional. Lei própria regula a organização e o funcionamento
da Polícia Nacional.

1.6.4 Definição e Natureza

A Polícia Nacional de Angola nos termos do Artigo 2.º do Decreto Presidencial nº

152/19, de 15 Maio, que aprova o seu Estatuto Orgânico, abreviadamente designada
por «PNA» é uma força militarizada, uniformizada e armada, com natureza de força
de segurança pública, dotada de autonomia operacional, administrativa, financeira e
patrimonial, e tem por missão fundamental:

a) Assegurar e defender a legalidade democrática;

b) Garantir a segurança pública e o exercício dos direitos e liberdades
fundamentais dos cidadãos;
c) Manter a ordem e tranquilidade públicas;
d) Colaborar na execução da política de defesa nacional, nos termos da
Constituição e da lei.

A PNA é constituida por pessoal militarizado e por pessoal civil.

Página | 17
1.6.5 Dependência

A PNA, enquanto força de segurança, é dirigida pelo Presidente da República na

qualidade de Comandante-em-Chefe das Forças Armadas Angolanas, e compete ao
Departamento Ministerial responsável pela ordem interna e segurança pública (
Ministério do Interior) auxiliar o Presidente da República na condução e direção da
PNA. A PNA, enquanto órgão de segurança e ordem interna, está sujeita à
fiscalização política, administrativa e judicial, nos termos da Constituição e da Lei.

1.6.6 Princípios e Valores

A PNA, no exercício das suas funções, observa especialmente os seguintes

princípios:

• Princípio da Legalidade;
• Princípio do Apartidarismo; Princípio da Proporcionalidade, da Necessidade e
da Proibição de Excesso;
• Princípio da Imparcialidade e da Neutralidade;
• Princípio da Probidade Pública;
• Princípio da Colaboração com os Particulares;
• Princípio da Aproximação dos Serviços aos Cidadãos;
• Princípio da Prossecução do Interesse Público;
• Princípio da Integridade e da Responsabilidade Solidária;
• Princípio da Cortesia e da Urbanidade;
• Princípio da Reserva e da Descrição;
• Princípio da Lealdade às Instituições e Entidades Públicas e aos Superiores
Interesses do Estado.

1.6.7 Posicionamento Estratégico

A PNA, enquanto Órgão da Administração Pública, assume tarefas de índole

administrativa, no âmbito da manuntenção da ordem interna e da tranquilidade
públicas, no asseguramento policial nacional fronteiriço e marítimo, bem como no
respeito pelo regular exercício dos direitos fundamentais dos cidadãos.

Página | 18
1.6.8 Atribuições Essenciais

Em situações de normalidade constitucional, as atribuições da PNA são as constantes

no seu Estatuto Orgânico (Decreto Presidencial nº 152/19, de 15 de Maio) e demais
legislação aplicável, e em situações de excepção, resultantes da legislação sobre a
Defesa Nacional e sobre os estados de guerra, de sítio e de emergências.

1.6.9 Organigrama
Figura 5-Organigrama da instituição

Fonte: A instituição

Página | 19
1.6.10 Distintivos

Figura 6- Classe dos distintivos

Fonte: A instituição

1.6.11 Localização

Província de Luanda, Avenida Pedro de Castro Van-Dúnem "Loy", Bairro Palanca.

Página | 20
CAPÍTULO II- METODOLOGIA E FERRAMENTAS

Neste ponto desenrola-se as técnicas que serão utilizadas para colecta e análise dos
dados.

2.1 Metodologia

A metodologia usada na realização do projecto foi o método indutivo, raciocínio

indutivo ou simplesmente indução, que é um tipo de argumento utilizado em diversas
áreas do conhecimento. Esse método tem o intuito de chegar a uma conclusão. O
método indutivo tem como ponto de partida a observação para, daí, elaborar uma
teoria.

Sendo assim, ele é muito utilizado nas ciências no qual parte de premissas
verdadeiras para chegar em conclusões que podem ou não serem verdadeiras. Nesse
sentido, a indução acrescenta informações novas nas premissas que foram dadas
anteriormente.

2.2 Tipo de Pesquisa

De acordo com MARCONI (2003: p.28) Considera que “pesquisa científica é um

conjunto de procedimento sistemático, baseados no raciocínio lógico, que tem por
objectivo encontrar soluções para os problemas propostos mediante o emprego dos
métodos científicos”.

Por outro lado, associada a determinação do tipo de pesquisa que assenta na

natureza dos dados que podem ser recolhidos. Temos assim para elaboração deste
trabalho os tipos de pesquisas.

2.3 Técnica para a Colecta de Dados

Para SILVESTRE (2012: p. 141) diz que:

A escolha das técnicas de recolha de dados implica um conjunto de decisões

que exigem capacidades, prática e criatividade por parte do pesquisador
facilitadas pelo conhecimento dos limites e vantagem a elas associadas. Ainda
segundo o mesmo autor faz menção de duas técnicas de recolha de dados que
são as técnicas de dados qualitativos e quantitativos. Para a conclusão deste
trabalho utilizamos a técnica de dados qualitativos uma vez que nos permite
entregar e compreender os factos sociais que pretendemos estudar e analisar
através de consultas de fontes bibliográficas, cultura geral, apontamentos nas
aulas e também a consultas pela internet como teses, monografias, artigos e
manuais de carácter científicos.

Página | 21
Para a realização do projecto apresentado no presente relatório foram utilizados os
seguintes métodos:

Na fase de análise do sistema a metodologia utilizada para a recolha de dados

baseou-se:

1. A pesquisa bibliográfica;

2. Pesquisa documental;

3. Visita de campo e entrevistas;

4. Levantamento de requisitos;

5. Estudo de caso.

2.3.1 Pesquisa Bibliográfica

De acordo ALVES (2012: P. 41), “É quando um investigador desenvolve a sua

investigação a partir de estudos já efectuados por outros investigadores, ou seja, o
investigador deve conhecer a bibliografia publicada dentro da área de pesquisa”.

2.3.2 Pesquisa Documental

Para ALVES (2012: p.40), “Este tipo de pesquisa utiliza fontes de informação que
ainda não receberam nenhum tipo de tratamento e nunca foram publicadas, como por
exemplo: Relatório de Empresas, fotografias, correspondência pessoal ou
institucional, documentos arquivados em instituições públicas ou privadas”.

2.3.3 Levantamento de requisito

No ponto sobre o levantamento de requisitos será abordado os mecanismos

necessários para o desenvolvimento do SIdAC que tem como finalidade de realizar o
registro de condutores, proprietários e policias, para que tal facto fosse uma realidade
foi necessário marcar entrevistas com alguns dos funcionários da DNVT, a fim de
saber o que é que eles esperam do sistema que vai ser desenvolvido.

O objectivo do levantamento de requisitos visa saber o que é, que os gestores

pretendem que seja feito quer através do diálogo entre o gestor e os desenvolvedores,
quer dizer saber o que os vários interessados desejam do sistema que esta ser
desenvolvido.

Página | 22
Seguindo regras e procedimentos de levantamento de requisito tendo resultado as
seguintes questões:

Desenvolvedor: Qual é a situação actual da empresa em termos de sistemas de

identificação automática de condutores?

Gestor: actualmente é nulo, porque não temos um sistema, que realiza tais
operações.

Desenvolvedor: já teve a empresa um programa ou sistema do género?

Gestor: nunca, este será o primeiro passo.

Desenvolvedor: porque desta decisão agora?

Gestor: uma vez que as tecnologias existem para dar solução dos problemas
apresentados, para melhor gestão da empresa e não só, para garantir a satisfação,
eis a necessidade de recorrermos a estes serviços.

Desenvolvedores: O que é que um funcionário necessita para registar um

proprietário de um veículo e um condutor?

Gestor: o funcionário necessita de um sistema que tenha informações primordiais dos

dados dos proprietários e dos condutores propriamente falando do nome, morada e a
matrícula do veículo.

Desenvolvedores: Quais são as funções que desejam na aplicação web que vai ser
desenvolvido?

Gestor: desejamos que tenha a função de autenticação de utilizadores de acordo com

o perfil e área de acesso de cada utilizador, que o sistema tenha a função de registar
multas e denuncias, consultar e registar os condutores e proprietários dos veículos.

Desenvolvedores: como desejam que seja feito o controle e o cadastramento de

policias e proprietários?

Gestor: O controle será feito pelos funcionários da DNVT, com o perfil de

administrador.

Desenvolvedor: grato pela informação prestada e disponibilidade, continuação de um

bom dia.

Página | 23
2.4 Identificação dos interessados no sistema

Interessados: São os funcionários que de algum modo são afectados pelo sistema
que será desenvolvido no caso funcionários da DNVT (que terá o papel de
administrador ou policiais), os proprietários de veículos e os condutores.

Suporte: o pessoal de suporte são os funcionários da área de informática, que Tem

a necessidade de um sistema bem documentado e flexível há manutenções e
evoluções, a eles cabe a responsabilidade de fazer o acompanhamento do sistema
durante sua vida útil, administrando os bancos de dados, e configurações de redes.

Os administradores têm as seguintes necessidades:

• Visualizar dados dos condutores/proprietários/policias

• Visualizar reclamação das vias;
• Controle de utilizador (cadastrar, visualizar, editar e eliminar);
• Visualizar denuncias

2.5 Características do sistema

O sistema a ser desenvolvido é destinado para a Direção Nacional de Viação e

Transito (DNVT) o sistema proposto devera ser portável para diferentes plataformas
de Hardware e Sistema operacional, de modo a garantir a escalabilidade da solução.

2.6 Requisitos do Software

O projecto de criação de um sistema web designado SIdAC, faz parte da disciplina de

Dissertação do Plano Curricular do Curso de Engenharia informática da Universidade
Independente de Angola (UnIA).

Seguindo todas as referências anteriores sobre o processo de desenvolvimento da

aplicação web vamos a apresentar os requisitos necessários para execução do
projecto.

Estes requisitos estão agrupados da seguinte forma: funcionais e não funcionais.

Página | 24
2.6.1 Requisitos Funcionais

Os requisitos funcionais mostram o que o sistema deve fazer:

• Só terão acesso ao sistema os utilizadores com direitos de acesso.

• Dentre os utilizadores com estes direitos, existem perfis de acesso.
• O sistema vai permitir registo de condutores, proprietários e polícia, consultar
os utilizadores do sistema, alterar a conta e sair do sistema, entre outros
serviços.

RF01 – O sistema deve permitir que, o administrador cadastre novos utilizadores e

estabeleça os perfis de acesso dos utilizadores no sistema. Para sua identificação,
nome, e-mail, senha e perfil.

RF02 – Administrador – Os utilizadores com perfil de administrador podem efectuar

as seguintes tarefas: consultar polícia, consultar condutor/proprietários, consultar
denuncias, registrar polícia e proprietários, consultar reclamação das vias de transito,
criar novos utilizadores.

RF03 – Polícia – Os utilizadores com perfil de polícia podem efectuar as seguintes

tarefas: efectuar multas, consultar dados do condutor, consultar denuncias feitas,
consultar multas feitas.

RF04 – Proprietário – Os utilizadores com perfil de proprietário podem efectuar as

seguintes tarefas: consultar e registar veículo, IVM, seguro e condutor, consultar
multa, remover condutor.

RF05 – Condutor – Os utilizadores com perfil de condutor podem efectuar as seguintes

tarefas: consultar seus dados, consultar reclamação das vias de transito, consultar
multa, efectuar reclamação das vias de transito, efectuar denuncias.

Página | 25
2.6.2 Requisitos não funcionais

Esses requisitos estão relacionados com as características de qualidade que o

sistema deve possuir:

• O sistema tem de ter menos restrições possíveis na sua arquitectura (diferentes

arquitecturas de hardware).
• O sistema será muito fácil de manusear, graças a interface gráfica.
• Tendo em conta que é um sistema de grande envergadura funcional, a
tecnologia a utilizar tem, que facilitar a sua manutenção.

RNF01 – O sistema deve operar 24x24, com garantia de 95% de disponibilidade.

RNF02 – O sistema deve conter áreas de acesso por meio de login e senha. O
utilizador poderá acessar apenas as informações que seu perfil necessita para realizar
suas actividades, sendo impedido de acessar às demais.

RNF03 – O SIdAC não é um sistema crítico, mas é fundamental a realização de

backups periódicos.

RNF04 – O sistema deve ser uma aplicação Web e oferecer suporte aos browsers
Firefox, Chrome e Internet Explorer.

2.7 Requisitos homem máquina

Existem ainda os requisitos para a interface homem-máquina. A aplicação terá que

satisfazer os seguintes requisitos:

• Tem de ser de fácil acesso, e navegabilidade.

O acesso à aplicação, e aos dados será via Browser, com verificação de palavra passe
de acesso.

Página | 26
2.8 Implementação do sistema

Neste ponto abordaremos sobre a tecnologia utilizada para desenvolver o nosso

sistema. A plataforma utilizada foi selecionada criteriosamente observando os
sistemas mais actuais em uso para desenvolvimento de sistemas semelhantes.

Para o desenvolvimento do nosso sistema designado SIdAC, foram utilizadas as

ferramentas UML para execução dos diagramas, mysql para desenho da base de
dados, para o desenvolvimento do sistema foi utilizado a linguagem de programação
Web, que permitisse a criação de páginas dinâmicas e oferecesse suporte para o
acesso a banco de dados.

Assim para implementação do provedor de serviços, foi utilizada a linguagem PHP,

que oferece funções para interacção com diversos bancos de dados, dentre eles o
mysql. Escolhemos o banco de dados mysql e a linguagem de programação PHP
associado com o framework para o desenvolvimento do sistema devido a sua
funcionalidade uma vez que em HTML só podem ser geradas páginas estáticas.
Assim, usamos o PHP e o mysql por serem gratuitos, de código aberto e portáveis
podem trabalhar em ambiente Windows ou Linux.

2.8.1 HTML

Figura 7- Logotipo HTML

Fonte: ([Link]

HTML é a sigla de (HyperText Markup Language) expressão inglesa que significa

Linguagem de Marcação de Hipertexto. Consiste em uma linguagem de marcação
utilizada para produção de páginas na web, que permite a criação de documentos que
podem ser lidos em praticamente qualquer tipo de computador e transmitidos pela
internet. O código-fonte pode ser escrito usando o mais simples dos editores de texto.

Página | 27
Até o programa bloco de notas (NotePad) do Windows pode ser usado. Contudo, a
forma mais prática e produtiva para escrever uma página Web é usar um editor HTML.
(Passei Direto, 2021)

Quando um browser (navegador) exibe uma página Web, ele lê o texto da página e
procura símbolos especiais denominados tags, que dizem como o texto ou a
informação devem ser exibidos.

Além do aspecto físico do texto, uma tag pode indicar o que um determinado trecho
representa, na verdade, o endereço de outras páginas, que devem ser a cessadas no
caso de o texto ser clicado.

2.8.2 PHP
Figura 8- Logotipo PHP

Fonte: ([Link]

PHP – (Hypertext Pre-Processor) é uma linguagem que permite criar sites web
dinâmicos, possibilitando uma interacção com o utilizador através de formulários,
parâmetros da url e links. A diferença de PHP com relação a linguagens semelhantes
a Javascript é que o código PHP é executado no servidor, sendo enviado para o cliente
apenas HTML puro. Desta maneira é possível interagir com bancos de dados e
aplicações existentes no servidor, com a vantagem de não expor o código fonte para
o cliente. Isso pode ser útil quando o programa está lidando com senhas ou qualquer
tipo de informação confidencial. (Monografias Brasil Escola, 2021)

Esta linguagem de programação está preparada para realizar muitos tipos de

aplicações web graças à extensa livraria de funções com a qual está dotada.

O PHP possui suporte a um grande número de banco de dados, como dBase,

Interbase, mSQL, mySQL, Oracle, Sybase, PostgreSQL e vários outros. Construir um
sistema baseada em banco de dados torna-se uma tarefa extremamente simples.

Página | 28
2.8.3 Astah

Figura 9- Logotipo Astah

Fonte: ([Link]

Astah é uma ferramenta case engenharia de software assistida por computador (do
inglês Computer-Aided Software Engineering) vastamente utilizada para a
modelagem de soluções de software fazendo uso da UML. O Astah é desenvolvido
na plataforma JAVA e permite que seja modelado soluções de software fazendo uso
de uma linguagem que seja mais próxima do pensamento humano. ( Neto, 2017)

2.8.4 UML

Figura 10- Logotipo UML

Fonte: ([Link]

A UML Linguagem de Modelagem Unificada (do inglês, UML - Unified Modeling

Language) é uma linguagem padrão para a elaboração da estrutura de projectos de
software. não é uma metodologia de desenvolvimento, o que significa que ela não diz
para o desenvolvedor o que fazer primeiro e em seguida ou como projectar seu
sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre os
objectos e em certos casos a identificação dos processos. (Escola, 2021)

Página | 29
2.9 Ferramentas

2.9.1 Visual Studio Code

Figura 11- Logotipo VS-Code

Fonte: ([Link]

Diferentemente do que o nome pode sugerir em um primeiro momento, o VSCode não

é uma versão do Visual Studio, em sua essência ele é um editor de código semelhante
ao Sublime Text, Brackets e Atom, com funcionalidades otimizadas para certas
tarefas.

É um editor de código-fonte desenvolvido pela Microsoft para Windows, Linux e

macOS. Ele inclui suporte para depuração, controle de versionamento Git
incorporado, realce de sintaxe, complementação inteligente de código, snippets e
refatoração de código. Ele é customizável, permitindo que os utilizadores possam
mudar o tema do editor, teclas de atalho e preferências. Ele é um software livre e de
código aberto, apesar do download oficial estar sob uma licença proprietária.

2.9.2 Sublime Text

Figura 12- Logotipo Sublime Text

Fonte: ([Link]

Página | 30
Para manter a produtividade no seu dia a dia, o desenvolvedor precisa de um editor
de códigos eficiente e, dentre tantos ambientes de desenvolvimento robustos e
gratuitos, como o Eclipse, o Sublime Text destaca-se justamente pela simplicidade e
facilidade de uso, além de leve. Além disso, ele aceita diversas linguagens de
programação e personalizável.

O Sublime foi desenvolvido em Python e foi feito para ser simples. É um editor de texto
bastante fácil de usar, mas com muitos recursos e funcionalidades que podem ser
adicionadas para complementar seu uso.

2.9.3 XAMPP

Figura 13- Logotipo XAMPP

Fonte: ([Link]

O XAMPP - é um pacote com os principais servidores de código aberto do mercado,

incluindo FTP, base de dados MySQL e Apache com suporte as linguagens PHP e
Perl. Com ele, é possível rodar sistemas como WordPress e Drupal localmente, o que
facilita e agiliza o desenvolvimento. Como o conteúdo estará armazenado numa rede
local, o acesso aos arquivos é realizado instantaneamente. O pacote de servidores é
baixado cerca de 600 mil vezes por mês, de acordo com dados do SourceForge.

2.9.4 MySQL
Figura 14- Logotipo MySQL

Fonte: ([Link]

O MySQL - é um sistema de gerenciamento de base de dados (SGBD), que utiliza a

linguagem SQL (Linguagem de Consulta Estruturada, do inglês Structured Query
Language) como interface. É actualmente um dos sistemas de gerenciamento de base

Página | 31
de dados mais populares da Oracle Corporation, com mais de 10 milhões de
instalações pelo mundo. Entre os utilizadores do base de dados MySQL estão:

NASA, Friendster, Banco Bradesco, Dataprev, HP, Nokia, Sony, Lufthansa, U.S.
Army, U.S. Federal Reserve Bank, Associated Press, Alcatel, Slashdot, Cisco
Systems, Google, entre outros.

2.9.5 Bootstrap
Figura 15- Logotipo Bootstrap

Fonte: ([Link]

Esse framework costuma figurar em quase todas as listas de ferramentas para

desenvolvedores, e não é por acaso. Com o Bootstrap não há mais a complicação de
criar um site responsivo sem descuidar do layout. Você pode comprar temas e utilizar
quando quiser, além dos arquivos e padrões, JS, CSS e HTML.

2.9.6 Laravel
Figura 16- Logotipo Laravel

Fonte: ([Link]

O Laravel é um framework de código aberto, disponível ao público no Github. Seu

principal objetivo é permitir que os programadores que o utilizam, consigam trabalhar
de forma rápida e organizada, mantendo um código enxuto e funcional. A principal
premissa do Laravel é manter um código bonito, tanto é que seu slogan diz: “O
framework PHP para artesãos da web”. para conseguir alcançar esse seu objetivo, ele

Página | 32
faz uso da arquitetura de desenvolvimento MVC (Model, View, Controller) e do padrão
de desenvolvimento PSR-2 que tem como foco a escrita de código limpo e com boa
legibilidade, além disso o framework tem como objetivo aumentar a velocidade de
codificação, sem esquecer características importantes como a segurança e
performance da aplicação.

2.10 Modelação do sistema: Engenharia de software

A engenharia de software é uma área de computação dedicada à concepção,

especificação, desenvolvimento e manutenção de sistemas de software, aplicando
tecnologias e práticas de gerências de projectos.

Segundo Roger S. Pressman (2002), engenharia de software preocupa-se em facilitar

o desenvolvimento e manutenção de produtos de Software complexos, aplicando para
isso métodos, técnicas, ferramentas, e modelos específicos.

Esta área de computação se encontra nos aspectos práticos da produção de um

sistema de software com tecnologias e práticas que envolvem as linguagens de
programação, banco de dados, ferramentas, plataforma, bibliotecas, padrões e
processos.

2.10.1 Processo de software

Segundo Jalote (2009) processo de software é um conjunto de actividades ligadas por

padrões de relacionamento entre ela, pelas quais se as actividades operarem
correctamente e de acordo com os padrões requeridos, o resultado desejado é
produzido.

Página | 33
2.10.2 Modelo de processo genérico

O modelo de um processo genérico estabelece cinco actividades metodológicas que

são:

• Comunicação;
• Planeamento;
• Modelagem;
• Construção;
• Entrega.
2.10.3 Modelo de processo evolucionário prototipação

O modelo utilizado na realização do sistema foi o modelo de processo evolucionário e

prototipação que visa entender os requisitos do cliente e assim, obter uma melhor
definição dos requisitos do sistema. Possibilita que o desenvolvedor crie um modelo
protótipo do software que deve ser construído apropriado para quando o cliente não
definiu detalhadamente os requisitos.
Figura 17- Modelo de processo evolucionário prototipação

Fonte: ([Link]

2.11 Diagrama de caso de uso

O diagrama de caso de uso descreve as principais funcionalidades do sistema e a

interação dessas funcionalidades com os utilizadores do mesmo sistema. Para o
Administrador (Adm).

Página | 34
2.11.1 Diagrama caso de uso administrador

Figura 18- Caso de uso Adm

A figura 18 ilustra o diagrama de caso de uso do administrador do sistema com as

possiveis tarefas que ele podera efectuar.

2.11.2 Diagrama caso de uso policia

Figura 19- Caso de uso polícia

A figura 19 ilustra o diagrama de caso de uso do Policia com as possiveis tarefas que
ele podera efectuar.

Página | 35
2.11.3 Diagrama caso de uso condutor

Figura 20- Caso de uso condutor

A figura 20 ilustra o diagrama de caso de uso do condutor com as possiveis tarefas

que ele podera efectuar.

2.11.4 Diagrama caso de uso proprietario

Figura 21- caso de uso proprietário

A figura 21 ilustra o diagrama de caso de uso do proprietario com as possiveis tarefas

que ele podera efectuar.

Página | 36
2.11.5 Diagrama de caso de uso Login

O diagrama de login descreve os actores do sistema que efectuam o login.

Figura 22- Caso de uso login

A tabela 1 indica o nível de restrição de cada actor do sistema:

Tabela 1- Nível de restrição

ACTOR JUSTIFICAÇÃO

É aquele que se encarrega de manter toda a informação

Administrador necessária para os outros utilizadores do sistema. E gere todos os
novos dados e utilizadores no sistema.

Realiza operações no sistema segundo as suas actividades e nível

Condutor
de acesso.

Realiza operações no sistema segundo as suas actividades e nível

Proprietário
de acesso. Tem funções mais elevadas em relação ao condutor.

Realiza operações no sistema segundo as suas actividades e nível

Polícia de acesso. Tem funções mais elevadas em relação ao condutor e
o proprietário.

Página | 37
2.12 Narração caso de uso

A narração do caso de uso faz uma descrição detalhada das acções que o actor pode
tomar e como o sistema responderá a esta acção. A narrativa inclui acções dos
actores e respostas do sistema, até o objectivo do actor ser alcançado. Tecnicamente,
é importante realçar que a narrativa de um caso de uso limita-se a descrever o que o
sistema responderá e não como ele obtém a resposta.

2.12.1 Caso de uso login

Tabela 2-Caso de uso login

Caso de Uso
Login
1

Requisitos
Requisitos Funcionais 01
funcionais

Actores Adm, Condutor, Proprietário, Polícia.

Garantir que apenas os utilizadores cadastrados têm acesso aos

serviços, e verificar o nível de acesso para restringir as operações
Objectivo que os utilizadores terão acesso.

Por questões de segurança, ao terminar a sessão o sistemas não

permite entrar novamente sem fazer o login.

Pré-
Ter utilizador cadastrado
requisitos

1. O actor inicia esse caso de uso clicando no canto superior direito

Fluxo da página inicial onde encontra-se o botão para se logar, vai
principal abrir a tela do login para que ele digite a sua palavra passe e o
e-mail.

Página | 38
 2. O sistema exibirá a tela principal do utilizador do sistema, onde
terá uma barra de menu que lhe dará acesso a qualquer
funcionalidade a que ele tem privilégios.

3. O actor (Administrador) inicia esse caso de uso clicando no

canto superior direito da página inicial onde encontra-se o botão
para se logar, vai abrir a tela do login para que ele digite a sua
palavra passe e o e-mail.

4. O sistema exibirá a tela principal do utilizador do sistema, onde

terá uma barra de menu que lhe dará acesso a qualquer
funcionalidade a que ele tem privilégios.

5. O actor deverá digitar o E-Mail e a Palavra Passe de acesso

nos respectivos campos.

6. O sistema fará uma consulta à base de dados para verificar se

os dados digitados pelo actor estão corretos.

6.1. Se os dados estiverem corretos, o sistema verifica qual o

Nível de Acesso do Utilizador que está a entrar no sistema.

7. O sistema exibe a tela principal do utilizador do sistema e o

menu com as operações permitidas para o Utilizador conforme
o Nível de Acesso.

Se os dados não estiverem corretos, o sistema emitirá a

Fluxos
mensagem “O Nome do Utilizador ou a Palavra Passe
alternativos
digitadas estão incorrectos” e retornará ao passo 2.

2.13 Diagrama de sequência

O diagrama de sequência preocupa-se com a ordem temporal em que as mensagens

são trocadas baseia-se em um caso de uso costuma identificar o evento gerador do
processo modelado, bem como o actor responsável por este evento, e determina
como o processo deve se desenrolar e ser concluído por meio do envio de mensagens
que em geral disparam métodos entre os objectos.

Página | 39
2.13.1 Diagrama de sequência login

O diagrama de sequência login da figura 23 apresenta os passos necessários para o

acesso ao sistema.

Figura 23- Diagrama de sequência login

Página | 40
2.13.2 Diagrama de sequência criar utilizador

O diagrama de sequência criar utilizador da figura 24 apresenta como funciona o

processo de criação de utilizador na nossa aplicação web.

Figura 24- Diagrama de sequência criar utilizador

Página | 41
2.13.3 Diagrama de sequência excluir utilizador

O diagrama de sequência excluir utilizador da figura 25 apresenta como funciona o

processo de exclusão de utilizador na nossa aplicação web:
Figura 25- Diagrama de sequência excluir utilizador

Página | 42
2.14 Diagrama de actividade

O diagrama de Actividade se preocupa em descrever os passos a serem percorridos

para a conclusão de uma actividade específica, muitas vezes representada por um
método ou algoritmo com um certo grau de complexidade, podendo, no entanto,
modelar um processo completo. Concentra-se na representação do fluxo de controle
e no fluxo de objecto de uma actividade.

2.14.1 Diagrama de actividade login

Figura 26- Diagrama de actividade login

2.15 Diagrama de classe

O diagrama de classe é uma representação da estrutura e relações das classes que

servem de modelos para objectos, ou seja, é um conjunto de objectos com as mesmas
características, assim podemos identificar objectos e agrupá-los de forma a encontrar
as respectivas classes.

A figura 27, ilustra o diagrama de classe do sistema desenvolvido a nível da base de

dados.

Página | 43
 Figura 27-Diagrama de Classe

2.16 Teste

O teste do software é o processo de execução de um produto para determinar se ele

atingiu suas especificações e funciona correctamente dentro do ambiente para o qual
foi projectado. O seu objectivo é buscar falhas em um produto, para que as causas
dessas falhas sejam identificadas e possam ser corrigidas pela equipe de
desenvolvimento antes da entrega final. Para este fim foram usados dos tipos de
testes para verificar a funcionalidade do sistema, a mencionar: Teste de caixa preta e
teste de caixa branca.

2.16.1 Teste de caixa preta

O teste de caixa preta é a técnica de teste em que o componente de software a ser

testado é abordado como se fosse uma caixa preta, ou seja, não se considera o
comportamento interno do mesmo.

Página | 44
Dados de entrada são fornecidos, o teste é executado e o resultado obtido é
comparado a um resultado esperado previamente conhecido. É considerado teste de
sucesso se o resultado obtido for igual ao resultado esperado.

O componente de software a ser testado pode ser um método, uma função interna,
um programa, um componente, ou uma funcionalidade. Para mais entendimento sobre
o teste de caixa preta foram efectuados os seguintes testes abaixo:
Tabela 3- Teste de caixa preta administrador do sistema

Caso de teste: Autenticação como Administrador no Sistema

Descrição: O utilizador deve aceder o Sistema como administrador

Responsável: Mauro Lombo

Abordagem: Caixa Preta

Técnica: Manual

Pré-condições: Nenhuma

Passos:

1. Abrir a Tela de Autenticação;

2. Inserir dados de utilizador e palavra-passe;
3. Confirmar no botão Entrar para Autenticação.

Pós-condições:

1. Se o utilizador e a palavra-passe forem validados, deve

encaminhar para a página principal do sistema;
2. Caso as informações digitadas não confiram, o utilizador
receberá uma mensagem de “O nome de Utilizador ou a Palavra
Passe esta incorrecta”.

Página | 45
 Tabela 4- Teste de caixa preta cadastrar utilizador

Caso de teste: Cadastrar Utilizador

Descrição: O utilizador deve aceder o Sistema como administrador

Responsável: Mauro Lombo

Abordagem: Caixa Preta

Técnica: Manual

Pré-condições: Ter privilégios

Passos:

1. Abrir a Tela de Autenticação;

2. Efectuar a Autenticação;
3. Entrar na Página principal;
4. Clicar no Menu Utilizadores e depois no Submenu Proprietário ou no
menu Polícia;
5. Digitar os dados do Utilizador no Formulario;
6. Confirmar os dados do Utilizador no Formulario;
7. Gravar.

Pós-condições:

8. Sair do sistema após a criação do utilizador.

2.16.2 Teste de caixa branca

Teste de caixa branca é a técnica de avaliar o comportamento interno do componente

de software. Trabalha directamente sobre o código-fonte do componente de software
para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de
ciclos e teste de caminhos lógicos.

Página | 46
Por outra o teste de caixa branca também pode ser definido como a técnica de teste
que usa a perspectiva interna do sistema para modelar os casos de teste. No teste de
software.

Esta técnica visa testar os seguintes itens:

• Funções de validação de campo

• Fluxo dos dados

Tabela 5-Teste de caixa branca verificação dos campos

Caso de teste: Verificação dos Campos em formulários

Descrição: O utilizador deve aceder o Sistema como administrador.

Responsável: Mauro Lombo

Abordagem: Caixa Branca

Técnica: Automática.

Pré-condições: Rotina de validação dos campos

Passos:

1. O utilizador efectua o preenchimento de um formulário;

2. Ao submeter os dados, será verificado se existe algum campo vazio,
ou diferente no caso do campo senha e confirmar senha.

Pós-condições:

1. Se existir algum campo vazio os dados não são cadastrados, se o

campo senha e confirmar senha estiver vazio é exibido uma
mensagem de erro ao utilizador;
2. Se não for verificada a existência de um campo vazio, os dados são
salvos e registados na respectiva tabela.

Página | 47
2.17 Segurança

Para garantir a segurança do sistema foram aplicadas políticas tanto no

desenvolvimento do software, na IDE, como também na base de dados, no SGBD e
em outras diversas áreas. Abaixo podemos ver algumas práticas implementadas para
que a informação se mantenha segura:

➢ Foram criadas contas de utilizadores com permissões específicas para aceder

a área administrativa do sistema, de modos a garantir que somente os Adm e
Polícia tenham acesso a informação restrita;

➢ Ao terminar a sessão, por questões de segurança o sistema não te permitira

entrar novamente sem fazer o login

➢ Validações de dados foram criados a nível do sistema de modos a garantir a

integridade e consistência dos dados a serem registados na base de dados;

➢ No cadastro de novos utilizadores as senhas exigem de 8 caracteres para cima;

➢ Foram validados os campos de e-mail, de formas a que não sejam permitidos

e-mails que não contêm “@”.

➢ A nível do banco de dados foram encriptadas as senhas por questão de

segurança de modos que os Administradores não tenham acesso a elas.

➢ Foram validados os campos de inserção de senhas, de formas a que não seja

permitido senhas diferentes, nos campos senha e confirmar senha.

Página | 48
CAPÍTULO III- RESULTADOS

3.1 Interfaces

Nesta secção serão apresentadas algumas interfaces em funcionamento para

podermos ver o resultado final do sistema, assim serão apresentadas algumas
interfaces que constituem o sistema e a explicação de algumas funcionalidades do
sistema.

3.1.1 Página inicial do sistema

A figura 28 ilustrada abaixo monstra a página inicial do sistema, aonde podemos

encontrar menu, cadastrar ao sistema e efectuar o login.
Figura 28- Página inicial

3.1.2 Tela de login

Para que se tenha acesso a área administrativa do sistema, e os utilizadores

efectuarem uma acção no sistema é importante que se faça a devida autenticação,
esta autenticação passa por inserir um e-mail e uma senha válida.

A figura 29 ilustra a tela de login de acesso do sistema:

Página | 49
 Figura 29- login

3.1.3 Página de cadastro de proprietário de veículos

Para que a identificação de condutores seja dinâmica é necessário que se saiba os

proprietários dos veículos para uma questão de organização, bem como os seus
dados para que se saiba quem é o proprietário do veículo que o condutor usa.

A figura 30 ilustra a tela de cadastro do proprietário:

Figura 30- cadastro de proprietário de veículos

Página | 50
3.1.4 Página de cadastro do condutor

Para uma questão de organização o sistema só permite que o cadastro do condutor

seja feito pelo proprietário cadastrado ao sistema, e para caso de confiabilidade das
informações inseridas é necessário que o proprietário faça o anexo da declaração que
permita com que o seu condutor possa circular com o seu veículo A figura 31 ilustra a
tela de cadastro do condutor:
Figura 31- cadastro do condutor

3.1.5 Página de inserção do veículo ao sistema

No acto do proprietário adicionar um veículo há dados obrigatórios como o anexo do

IVM, seguro e livrete. A figura 32 ilustra a tela de inserção do veículo:
Figura 32- inserção do veículo ao sistema

Página | 51
3.1.6 Página de associar veículo ao condutor

Cada proprietário so poderá associar condutores aos veículos por ele cadastrado ao
sistema como ilustra a figura 33 abaixo:

Figura 33- associar veículo ao condutor

3.1.7 Página de cadastro de polícia ao sistema

O cadastro de policias ao sistema somente é feito pelo administrador do sistema.

Figura 34- cadastro de polícia ao sistema

Página | 52
3.1.8 Página de adição de multas

A multa aos condutores somente é feita pelos policiais cadastrados no sistema com o
seu login devidamente feito como ilustra a figura 35:

Figura 35- adição de multas

Página | 53
CONCLUSÃO

O desenvolvimento de aplicações web não é de facto fácil, mas com muito trabalho e
esforço concluímos que também não é impossível. Fazendo uso de tecnologias para
o objectivo traçado e ferramentas adequadas, o resultado foi satisfatório. Quanto a
aplicação desenvolvida, conclui-se que a mesma cumpriu com os requisitos pré-
estabelecidos, embora ela não esteja isenta de melhorias e actualizações de acordo
as necessidades que forem surgindo com o tempo. É importante saber que o
desenvolvimento desta aplicação trará vantagens consideráveis tanto para a
organização em questão como para os seus associados.

Por mais completa esteja a nossa aplicação a nível de funcionalidades, uma aplicação
será sempre um produto inacabado pois diariamente surgem inovações e novos
requisitos que colocam em causa às especificações das aplicações existentes
correndo o risco de serem extintas caso não se faça actualizações. Esta aplicação
não é excepção ficando a cargo das futuras gerações ou em próximas versões a
implementação de novas funcionalidades conforme foi detalhado nas perspectivas
futuras deste trabalho de conclusão de curso.

Página | 54
BIBLIOGRAFIA

Neto, M. F. (2017). Tutorial da ferramenta de.

(28 de Maio de 2021). Obtido de Devmedia: [Link]

framework-php-codeigniter

(28 de Maio de 2021). Obtido de Estudo Pratico:

[Link]
producao-de-um-sistema-de-software

(7 de Junho de 2021). Obtido de Brainly: [Link]

(7 de julho de 2021). Obtido de Portal Web Designer :

[Link]

(7 de julho de 2021). Obtido de Portal Educação:

[Link]
sao-e-para-que-servem/37905

(7 de Julho de 2021). Obtido de Passei Direto:

[Link]
semipresencial

(7 de Julho de 2021). Obtido de Monografias Brasil Escola:

[Link]
[Link]

ALVES, M. (2012). Metodologia Cientifica. Lisboa: Escolar Editora.

Escola, I. (7 de julho de 2021). Obtido de Info Escola: [Link]

de-software/uml/

Henry F. Korth, A. (1995). Sistema de Banco de Dados; Silberschatz. Makro Books.

K19. (2013). DesenvolvimentoWeb com HTML, CSS e Javascript.

LAKATOS, E., & MARCONI, M. (2003). Fundamentos de Metodologia Cientifica. 5ª Edição.

Editora Atlas S.A.

P., J., & P., J. (2008). Engenharia de Software edição:09.

Página | 55
PRESSMAN, R. (2005). “Software Engineering: A Practitioner’s Approach”6th ed. Nova
York,: McGraw-Hill.

S. B., N., & R., E. (2011). Sistemas de Banco de Dados, 6ª edição. São Paulo: Pearson Addison
Wesley.

TANENBAUM, A. (2003). Computer Networks 4ª ed. Editora CAMPOS.

VARRELA, V. (2008). Sistema de Gestão de Conteúdos – Estudo do Caso “Projecto de

Desenvolvimento do Site do Ministério da Saúde”.

Página | 56
APÊNDICE

Página | 57
APÊNDICE A – CRONOGRAMA DAS ACTIVIDADES

Figura 36- Cronograma

Página | 58
 APÊNDICE B – TABELA DE CUSTOS

Tabela 6- Custo

ID HORAS VALOR p/
DESCRIÇÃO VALOR p/ Hora
TRABALHADAS ÍTEM
1 Análise do Projecto 3000 Akz/h 176 528.000 Akz

2 Modelagem da B.D 3000 Akz/h 176 528.000 Akz

3 Implementação 3000 Akz/h 176 528.000 Akz

4 Testes de Segurança 3000 Akz/h 176 528.000 Akz

5 Valor Total 12.000 Akz/h 704 2.112.000 Akz

Página | 59