Contents

Introdução.......................................................................................................................................................1
Objectivos do Trabalho ...................................................................................................................................2
Geral ............................................................................................................................................................2
Específicos ...................................................................................................................................................2
Métodos de Recolha de Dados ...................................................................................................................2
Descrição do Problema ...................................................................................................................................2
Estudo de viabilidade ......................................................................................................................................3
Viabilidade técnica e operacional ...................................................................................................................3
Ferramentas de software............................................................................................................................3
Equipamentos de hardware........................................................................................................................3
.Viabilidade Económica ...................................................................................................................................3
Ciclo de Vida do Desenvolvimento de um SI ..................................................................................................4
Fase de definição do problema ...................................................................................................................4
Fase de Desenvolvimento ...........................................................................................................................4
Fase de Manutenção...................................................................................................................................5
UML .................................................................................................................................................................5
Conceitos.........................................................................................................................................................7
Conceitos de Análise de Sistemas ...............................................................................................................7
Desenvolvimento do novo Sistema de Informação ........................................................................................8
Construção do modelo visual em UML .......................................................................................................8
. Análise de Requisitos ............................................................................................................................8
. Requisitos Funcionais ............................................................................................................................8
Requisitos não Funcionais.......................................................................................................................9
Actores (Utilizadores)............................................................................................................................11
Casos de uso por Actor .........................................................................................................................11
Análise .......................................................................................................................................................12
Diagrama de Classes .................................................................................................................................12
6.2.1. Diagrama de Sequência de Registo ...........................................................................................13
Conclusões ....................................................................................................................................................14

0
Introdução
No fim das aulas de Informatica e Telecomunicacoes tive nececidade de fazer um projecto
por qual usaria como trabalho do fim do curso para obter o sertificado.

Tendo pensado no projecto veio me a ideia de fazer um Sistema de Registo de Membros

de Quarteirao SRMQ.

Por enquanto nao ha registo dos membros do quarteirao excpto os responsaves de uma
determinada familia, para dizer que os chefes do Quarteirao nao tem capacidade de destinguir ou
reconhecer um determinado membro a nao ser que seja vizinho ou muito popular na zona, o que
nao e bom para um quarteirao, para pedir Declaraco do Bairro na ausencia do chefe do quarteirao
e obrigado a deixar teus dados pessoas e nao ha responsavel de garantir a seguranca dos tais
dados. Reconhecendo isso, procurei a resolução deste problema. criando um Sistema de Registo
de Membros de Quarteirao (SRMQ). A concepção deste trabalho contribuirá como o meu
trabalho de final do Curso.

A execução do trabalho consistiu nas seguintes fases:

Fase 1 - Desenvolvimento da aplicação;

Fase 2 - Testes da aplicação.

1
Objectivos do Trabalho

Geral
Garantir o control dos membros do Quarteirao

Específicos
Garantir que o outro chefe de quarteirao a ser Promovido tenha dados verdadeiros dos membros
do quarteirao

Métodos de Recolha de Dados

Um dos momentos mais importantes na fase de análise é a compreensão do problema. Tendo

procurado saber mas como e que o chefe do quarteirao reconhece os membros. A aplicação de
cada um destes critérios varia de acordo com o tipo de Sistema de Informação a ser desenvolvido.
E para a obtenção da informação do presente trabalho foram usadas a seguintes técnicas de
recolha de informação

 A entrevista – Esta foi feita ao chefe do Quarteirao e a um dos membros do quarteirao

Descrição do Problema

Resumindo o sistema usado no suporte da execução nas actividades do chefe do quarteirao

apresenta as seguintes desvantagens:

 Ineficácia do sistema Manual de registos;

 Inflexibilidade de disposição da informação ;
 Redundância de dados;

2
Estudo de viabilidade

Para a solução dos problemas acima mencionados propõe-se a criação de uma aplicação que
funcionará a base de SGBD (Sistema de Gestão de Base de Dados).

O novo Sistema de Informação trará as seguintes vantagens:

 Acesso fácil a informação

 Redução do tempo de procura de dados de um Membro;
.

Viabilidade técnica e operacional

Este estudo serviu para avaliar os conhecimentos técnicos e materias para o projecto, isto é,
verificar a capacidade técnica existente na organização para este projecto. Para a implementação
do presente sistema tive que ter certos requisitos que ditaram o bom funcionamento do sistema,
tais como, de software e hardware.

Ferramentas de software
 Sistema Operativo Windows 7
 Visual Studio 2010  SQLsever

Equipamentos de hardware
 Flash drive  Computador core i5

.Viabilidade Económica

Deve ser realizado sempre que um novo projecto esteja em fase de avaliação.. O grande
benefício desse tipo de análise é conseguir visualizar através de projecções e números, o real
potencial do investimento no projecto em questão e, portanto, decidir se as premissas estão
interessantes e se o projecto deve ir adiante ou não. Para a realização do presente projecto requer-
se um investimento de 59.400,00mt.

3
Descrição Quantidade Preço Unitário Preço total
Computador 1 24.000,00mt 24.000,00mt
Impressora 1 10.000,00mt 10.000,00mt
UPS 1 17.000,00mt 17.000,00mt
Dispositivo Cópia de 1 3.000,00mt 3.000,00mt
segurança
Subtotal 54.000,00mt
Contingências 10% 5.400,00mts
Valor total 59.400,00mts

Ciclo de Vida do Desenvolvimento de um SI

Pode se dizer que o Ciclo de Vida de Desenvolvimento de um Sistema de informação
compreende 3 fases, a saber:

Fase de definição do problema

Define-se que informação deve ser processada, que funções e desempenho são
pretendidos, que interfaces são necessários, que restrições devem ser consideradas
e que critérios devem ser utilizados na avaliação do projecto.

Tipicamente engloba dois tipos de tarefas:

o Estudo de viabilidade – definição do problema, identificação de soluções

alternativas e estimativa dos custos benefícios e prazo de entrega da solução
alternativa;
o Análise de requisitos – identificação e especificação dos requisitos funcionais de
desempenho, de interface, etc.

Fase de Desenvolvimento
Identifica-se a solução. Como é que as estruturas de dados, arquitectura do produto
e as funções serão realizadas; Como é que o desenho se traduzirá numa Linguagem
de Programação; e como serão efectuados os testes do produto.

Tipicamente engloba três tarefas:

4
 o Desenho – tradução dos requisitos um conjunto de representações (texto gráfico)
que descrevem a estrutura de dados, arquitectura e funções;
o Programação - tradução do desenho em instruções;
o Teste – procura e eliminação de defeitos na funcionalidade do produto.

Fase de Manutenção
Esta fase está focada nas alterações do produto, devidas a erros detectados nas
fases anteriores ou alterações propostas pelo cliente. Volta aplicar as fases de
definição e de desenvolvimento mas partindo do código já desenvolvido.

Tipicamente engloba três tipos de tarefas:

o Correcção - eliminação de erros;

o Adaptação - Modificação do produto devido a alterações no ambiente;
o Evolução - extensão do produto a pedido do cliente.

UML
UML significa (Unified Modeling Language) Linguagem de Modelação Unificada, que utiliza
uma notação padrão para especificar, construir, visualizar e documentar Sistemas de Informação
orientados a objectos com isso facilitando a integração de aspectos de natureza organizacional que
compõe o negócio e elementos de natureza tecnológica, assim ajuda a diminuir a complexidade de
regras de negócio e definir os processos e fluxos de informação.

O modelo em UML é constituído por um conjunto de 4 diagramas que representam aspectos

complementares de um Sistema de Informação. Em cada um dos diagramas em UML são usados
símbolos que representam os elementos que estão a ser modelados (abstracções) e linhas que
relacionam esses elementos, desses diagramas destacamos o diagrama de Casos de Usos e
diagrama de Classes.

NB: A UML não é uma metodologia, mais sim, uma linguagem de modelação que utiliza uma
notação padrão.

5
Diagrama de Casos de Usos - Este diagrama tem por objectivo identificar as fronteiras do
Sistema de Informação e descreve os serviços (Casos de Uso), que devem ser disponibilizados a
cada um dos diversos utilizadores (Actores) do Sistema de Informação.
Os Casos de Usos constituem, a técnica em UML para representar, levantamento ou
especificações de requisitos do Sistema de Informação.

Casos de Uso- cada acção executada pelo actor dentro do sistema.

Actor- todo aquele que executa uma acção dentro do sistema.

Diagrama de Classes - Este diagrama é usado para descrever a estrutura da informação, isto é,
Classes e as suas relações que são utilizadas no Sistema de Informação. O diagrama de classes
descreve o modelo geral da informação de um Sistema de Informação, ele é composto por classes
de objectos, relações de associação, generalização e multiplicidade.

A perspectiva estática fornecida pelos diagramas de classes tem como objectivo suportar os
requisitos do Sistema de Informação que foram identificados previamente. Deste modo o
diagrama de classes é o resultado da análise de requisitos fornecendo um modelo que mais tarde
será usado na fase de desenho para a definição dos componentes da aplicação.

Diagrama de Sequência - Este Diagrama é usado para ilustrar os objectos e as mensagens para
os casos de uso no nosso sistema, o qual descreve os processos pelo qual as actividades são
executadas no sistema. Os objectos que participam na sequência são colocados ao longo do topo
do diagrama usando actores a partir do diagrama de casos de uso e classes a partir do diagrama de
classes.

Para cada um dos objectos, o nome da classe da qual são uma instância aparece depois do objecto.

Diagrama de Actividades - Representa o fluxo de tarefas que podem ser executadas pelo sistema
ou por um actor.

6
Diagrama de Estado - Representa um conjunto de estados que um objecto pode estar que
estimulam a transição de um objecto de um estado para o outro

Conceitos

Conceitos de Análise de Sistemas

A Análise é entendida como um processo sistemático de aquisição e representação de
conhecimento, reveste-se de extrema importância, nomeadamente, quando se procura a excelência
de um software. A seguir irá apresentar os conceitos de análise no âmbito dos SI.

Sistema: Conjunto de partes organizadas ou estruturadas, que concorrem para atingir um ou

mais objectivos.

Sistemas de Informação (SI): Subsistema de uma organização cujas funções incluem a

recolha, armazenamento, tratamento e comunicação de informação para um propósito
específico, para que esta esteja disponível em qualquer momento ou local.

Análise: definida de um modo geral como estudo de um problema antes de passar à sua
resolução.

Análise de Sistemas: estudo de um Sistema de Informação, descrição das suas características

e funcionalidades. Envolve a caracterização de um sistema informático que a automatize.

Requisito - É uma característica considerada relevante na óptica do utilizador, o que o sistema

deve fazer.

Geralmente dividem-se em dois tipos: Funcionais e Não Funcionais.

Funcionais - Descrevem as funções, tarefas e subtarefas que se esperam que o sistema realize.
A identificação e definição dos requisitos funcionais não é um exercício de como o sistema
suportará as funções, actividades e tarefas, mas sim, um exercício detalhado de como o
sistema contemplará e perceberá os utilizadores. Os requisitos funcionais geralmente
distinguem-se entre orientados aos processos (funções que o sistema deve realizar) e
orientados a informação (informação que o sistema deve conter).

7
 Não Funcionais - São aqueles requisitos que não dizem especificamente respeito às
funcionalidades de um sistema. Eles colocam restrições no sistema a desenvolver e no
processo a usar e especificam as restrições externas às quais o produto deve obedecer.
Requisitos não funcionais incluem, entre outros requisitos de fiabilidade, segurança,
adaptabilidade, portabilidade e desempenho. Por vezes há necessidade de sacrificar requisitos
funcionais para respeitar os não funcionais, nomeadamente, por limitações de tecnologia. Os
requisitos não funcionais podem ser de âmbito geral, por vezes denominados de
suplementares ou estarem associados a um requisito ou subconjunto de requisitos funcionais.

Desenvolvimento do novo Sistema de Informação

Construção do modelo visual em UML

. Análise de Requisitos
Nesta fase se faz a descrição das intenções e necessidades dos utilizadores do sistema em
desenvolvimento pelo uso de funções chamadas de Casos de Uso. Também são apresentadas as
entidades externas ao sistema a ser desenvolvido, isto é, os utilizadores que interagem com o
sistema designados actores externos serão modelados entre as funções que eles requerem (Casos
de Uso) por meio de relacionamentos que possuem comunicação associativa entre eles.

Os Casos de Uso modelados serão descritos por meio de um texto que especifica os requisitos do
actor que utilizará o sistema em desenvolvimento.

. Requisitos Funcionais

1. RF1 2. Registar entrada

3. Descrição: 4. O sistema deve registar a entrada de dados, isto é, atribuir uma referência à ao5.
Membro .

8
 RF2 Registar detalhes do Membro

Descrição: O sistema deve registar o Responsavel da Familia, dados dos membros da familia
e dados de alguem que moreu numa determinada familia.,

R3 Registar detalhes do Membro

Descrição: O sistema deve registar os detalhes do Membro, Grau Parantestico, Familia,

Nome, Apelido, Sexo, Idade, Numero de BI, Numero da Casa, Numero de
Telefone, Quarteirao e sua Foto e Atribuimos a Ele um cogido unico.

RF4 Consultar nota de confirmação

Descrição: O sistema deve permitir a visualização de todos dados dos Membros

RF5 Consultar registos

Descrição: O sistema deve permitir a consulta de todos Membros que constam dos registos,
com restrições.

Requisitos não Funcionais

Descrição Casos de Uso

RNF2 Sistemas Operativos

9
 O sistema deve ser acessível no Computador de mesa e no laptop, por meio de
pelo menos os seguintes Sistemas Operativos:
 Windows 7 Não aplicavel
 Windows 8
 Windows 10

RNF3 Língua Não aplicável

O sistema deve estar disponível pelo menos em língua Portuguesa.
RNF4 Interface
A interface deve ser simples e amigável. A propriedade de fácil acesso deve
ser medida pelo número de clicks necessários para aceder a função desejada. Não aplicavel
Podendo ser um click para as funções frequentemente usadas e dois para o
contrário.
RNF5 Segurança Autenticar
O sistema deve identificar/verificar os utilizadores do sistema. Outras regras Usuário
também serão impostas de acordo com a hierarquia dos usuários dentro do
sistema.
RNF6 Linguagens de Programação Não aplicável
O sistema utilizará C# para implementação dos códigos do Sistema. Essas
tecnologias permitirão o desenvolvimento de um sistema robusto, pois são
estáveis e consistentes, além de suportarem a programação multiplataforma.
RNF7 Ferramentas de modelação e desenvolvimento Não aplicável
As ferramentas utilizadas serão:
 Rational Rose: Ferramenta CASE UML utilizada para a modelação
dos Casos de Uso, de Diagramas de Classes e outros aspectos do
projecto;

 SqlSever: Uma Ferramenta para o desenvolvimento de Base de Dados;

10
  Microsoft Visual Studio .Net: Um IDE para desenvolvimento de
aplicações C#, VB e outros.
RNF8 Privacidade Autenticar
O sistema deve permitir acesso a usuários autorizados. Para utilizadores Usuário
autorizados o sistema cria um historial de acesso e de registo.

Actores (Utilizadores)
Chefe do Quarteirao – Responsavel pelos Registos e Reconhecimento de dados

Casos de uso

 Registar Entrada do novo Membro .

 Consulta de Membros Registados.
 Consultar registos de RF, MQ,M;
 Registar detalhes do Membro;
 Registar a Data de entrada
 Consultar registos;

Casos de uso por Actor

Casos de uso Actores Referência

Autenticar  Chefe do Quarteirao RF1,RF2,RF3,RF4

usuario

Registar Membro  Chefe de Quarteirao RF1;RF2;RF3;RF4;

Consulta de  Chefe de Quarteirao RF1;RF2;RF3;RF4;

Memmbros Registados

11
Análise
Nesta fase se apresenta as primeiras abstracções, isto é, as classes e os objectos, bem como, os
mecanismos que estarão presentes no domínio do problema. Portanto, a seguir se apresenta o
diagrama de classes e seus relacionamentos que irão posteriormente gerar o modelação Base de
Dados pertencentes ao domínio principal do problema.

Diagrama de Classes
Por meio de um diagrama se faz a demonstração do que os actores, ou seja, os utilizadores do
futuro Sistema de Informação deverão esperar deste, dando uma visão geral de toda a sua
funcionalidade, no entanto sem se importar com a forma como este será implementada.

12
Resumindo, nesta fase fez-se o detalhamento das especificações para a fase de programação do
sistema em desenvolvimento.

6.2.1. Diagrama de Sequência de Registo

13
Conclusões
Neste trabalho foram expostos os conhecimentos Obtidos por modo Investigativo, no que se refere
à Análise de Sistemas. Usando como ferramenta o modelo visual UML foi possível descrever os
passos para a criação do SRMQ( Sistema de Registo de Membros de Quarteirao), o mesmo será
posteriormente criado e com objectivo de ser implementado no futuro. O Sistema de Registo de
Membros de Quarteirao devera satisfazer as necessidades dos Chefes de Quarteroes a saber:

 Registar todos Membros de quarteirao permanentes tambem os que dão entrada

no Bairro, bem como os que perdem as suas vidas;
 Obter resposta rápida em pesquisa de um determinado membro;

14