1.

Planificação
1.1. Escopo do Projecto
1.1.2. Objectivo do Projecto
O objectivo do sistema PDC.PLUS é desenvolver uma rede social e alguns serviços
associados concretizando a aplicação PDC.PLUS que permite criar, gerir, e utilizar uma rede social.
1.1.3. Descrição Geral
O projecto serve para criar uma solução computacional que facilite a interação entre os
funcionários e estudantes no seu dia-a-dia no Departamento da Ciência da Computação. A solução
deve incluir uma aplicação para compra e venda conveniente aos materiais didáticos, e de dois
serviços associados: PAGAMIGO e LARGA CAIXA.
Todas as entidades do domínio geridas pelo sistema têm um identificador único. Os
identificadores únicos que são administrados pelo sistema são gerados sequencialmente e começam
do zero. Sempre que for necessário produzir listas, por omissão, a ordem é determinada pelos
identificadores das entidades.
1.1.4. Premissas

 Os desenvolvedores deverão trabalhar 3 horas por dia na primeira quinzena.

 Qualquer dúvida levantada pela equipe do projeto deverá ser respondida pela
equipe do cliente em até 1 dia útil;
 O cliente deve estar disponível para uma reunião duas vezes por semana ao longo do
projeto.
 O financiamento deverá estar disponível 15 dias antes do início do projeto.

1.1.5. Restrições
 O projecto terá início na segunda quinzena do mês de outubro do ano corrente;
 Como o ambiente da empresa sofre manutenção aos finais de semana, esses dias
não poderão ser considerados no cronograma;
 Somente serão utilizados softwares genuínos para o desenvolvimento da aplicação.
 O projeto terá de ser realizado no máximo até o fim de Janeiro de 2019.
 Somente serão utilizados softwares genuínos para o desenvolvimento da aplicação.
 As entregas dos macros deverão ser feitas pontualmente nas datas destritas.

1
 1.2. Viabilidade do Projecto

Estudo do caso
A PDC-PLUS desejá implementar no Departamento da computação da faculdade de
ciência um projecto que consiste na criação de uma rede social com objectivo de garantir a
comunicação e partilha de recursos entre seus utilizadores. Os Estudantes(35) e Funcionarios(15)
deste departamento trocam comunicação atravês de ligação e mensagem de voz gastando em media
por mês 2900 kz equivalente a 415 utts,tendo um gasto anual de 1,305,000kz anul(9mês de ano
lectivo).algumas vezes desloca-se desnecessariamente em busca de informação interna perdendo
tempo quando é possivel fazer isto sem houver necessidade de deslocamento, gastam tambem papeis
e impressão. A rede social trára inumeros beneficios para os funcionarios e estudantes do
departamento pois ela facilitara a comunicação e partilha de informação aos seus utilizadores,
garantira melhor intercambio. sistema será acessado por meio de uma internet,mudara o ambiente do
trabalho dos funcionarios do Departamento e facilitara a vida dos estudantes da computação o
mesmo será facil de ser usado e eficiente

Analise Custo-Beneficio
I. Custo da Construção do sistema

Custos Qtd Valor unitario(kz) Valor total(kz)

Programador 1 50.000kz 150.000kz
Analista sistema 1 50.000kz 150.000kz
Design web 1 40.000kz 120.000kz
Gestor do projecto 1 60.000kz 180.000kz
Transporte 4 40.000kz 120.000kz
Alimentação 4 24.000kz 72.000kz

Ferramentas Modelagem 2 10.000 kz 10.000 kz

Pendrive 4 1000 kz 4000 kz
Internet 2 8.000 kz 20.000 kz
GB
Aluguel de Computadores 3 15.000 kz 45.000 kz

Ferramentas 2 5.000 kz 15.000 kz

Desenvolvimento

Total

II. Custo da Construção por Mês

MÊS VALOR TOTAL

1º Mês 4.582kz
2º Mês 4.582kz
3º Mês 4.582kz

2
 Total 13.746

III. Custo da Implantação

Custos Valores anual

Contrato com provedora de Serviço 450.000kz

Suporte e manutenção 80.000kz

Licença de Uso 50.000kz
Hospedagem de Alta disponibilidade e backup.
Garantia de actualização 40.000kz

Total 580.000kz

IV. Custo Gerais

Custos Valores
Custo de Desenvolvimento 13.746kz

Custo de implantação 580.000kz

Custo da Construção

Total 593.746 Kz

V. Benefício Tangíveis
 Diminuição de custo de internet na busca de imformação
Os professores e os estudantes perdem muito tempo e gastam muito para partilhar
informações utilizando em medía 3 horas diaria, procurando e partilhado informação com a
implantação da ferramenta a rede Social pode reduzir 25% para efeito usamos a taxa de redução de
10% economia actual de 157,500 kz anual.

 Redução de tempo no Uso de Serviço E-mail

Perde-se muito tempo no envio e recebimento de e-mail E as vezes não se consegue ter
acesso ao e-mail referenciado a instituição. A implantação da rede social reduzira a quantidades de
e-mail trocados , e propocionara um ambiente mais propício para discussões, e diminuição de custo
de internet pois os utilizadores podem ter acesso a um conteudo gratuitamente ou compra-lo a preço
reduzido de 40% do valor para ter acesso ao mesmo conteudo. 5minutos diario podem gerar prejuizo
de 1000 kz mensal tendo uma perda de 9000kz anual em cada utilizador, tendo em medía
450,000kz por todos os (50) utilizadores durante o ano lectivo.

 Diminuição de Gasto para compra de saldo de voz.

3
 Gasta-se muito com as contas telefonicas. Com a implantação da rede social os gastos irão
diminuir pois no lugar de fazer ligações para se comunicar com colegas e até mesmo professores
podem resolver por meio do chat grupos, mensagens privadas mural de notícias. Reduzindo o gasto
anual de 450.000kz em saldo de voz. Com a Pdc-Plus pode-se gerar a redução de 10% resultando no
desconto de 225,000kz por ano.

 Diminuição de papel e tinta de impressora usada no departamento.

Gasta-se muito na compra de papel e tinta para imprimir anuncio e materias academicas
quando na verdade estes gastos podem ser reduzido com uso da ferramenta pois ela permite a
publicação destes anúncios e materias.

 Redução do valor taxi até a faculdade para ter acesso a informação e encontros
em grupos.
A rede social consegue viablizar o dinheiro que os estudantes e funcionarios do
departamento gastam para ter acesso a informação interna da instituição e aos encontros em grupos

VI. Benefício Intangíveis

 Melhoria na comunicação e maior satisfação dos estudantes e funcionarios.
 Redução de esforço fisico para ter acesso a informação
 Oferece maior integração e melhoria do clima estudantil.
 Criação de grupos e identificação de lideranças.
 Oferece inovação.

VII. Benefícios Tangíveis

Beneficios Custo anual

E-mail 10min/hora 450,000kz

Busca informação 3hora/dia 157,500 kz

Telefone Por ano 225,000kz

Total 832.5 kz

VIII. Relação Custo/Benefício

Tendo já quantificado os custos e Benefícios do projecto temos apresentado o resumo do

custo e benefício no período de 3 anos de uso da ferramenta.
Ano Custo Beneficio Beneficio Neto
1 593.746kz 832.5 kz 238.754kz
2 580.000kz 832.5 kz 252.5kz
3 580.000kz 832.5kz 252.5kz
Total 1.753.746kz 2,497.5

4
 Nota: o ponto de equilíbrio consegue-se no segundo ano do projecto
Custo/Benefício
2.497.5./1.753.746 = 4,2 (Projecto viável)

IX. Retorno Sobre Investimento

O cálculo do ROI das redes sociais está relacionado com o montante economizado ou
otimizado com ajuda da ferramenta Duante 3 anos de uso.Ou seja: a economia gerada com ajuda de
uma plataforma do tipo deve ser maior que o investimento necessário para mantê-la. Nesse caso, a
fórmula de medição de ROI ficaria:

¿ Quantia poupada coma implantação

ROI= *100%
valor investido

¿ 832.5
ROI= *100%
580,000
ROI=1,4%

1.3. Riscos Identificados

Nº Tipo de risco Descrição dos riscos

1 A metodologia nunca foi usada em outros projeto realizados
Complecidade do projecto
por nos;
2 Risco do projeto(relacionado ao
processo de desenvolvimento)
3 Risco do projeto(relacionados ao Os membros da equipe não são treinados no uso de todas as
ambiente de desenvolvimento) ferramentas.
4 Risco do projeto(relacionado Não existe representantes do usuarios disponiveis
cliente/usuario)
5 Risco do projeto(relacionado O cliente não esta disposto a participar de reuniões/revissões
cliente/Utilizador)

6 Riscos técnico A tecnologia a ser utilizada é nova para a equipe de

desenvolvimento

1.3.1 Tratamento dos Riscos

5
Risco Clas Proba Valo Valor M
sificação do bilidade r da faixa do da faixa da agnitudo
Impacto do impacto do probabilidade do
do risco risco do risco
risco risco
A metodologia mod Possi 2 3 M
nunca foi usada erado vel EDIO
em outros projeto
A equipe nunca insi Possi 1 3
utilizou a gnificante vel M
metodologia antes EDIO
Os membros da Mo Possi 2 3
equipe não são derado vel
treinado no uso M
da ferramenta EDIO
Não existe Mai Alto 3 4 A
representantes do or LTO
usuarios
disponiveis
O cliente Mai Alto 3 4 A
não esta disposto or LTO
a participar de
reuniões/revissões
A Mo Possi 2 3 M
tecnologia a ser derado vel EDIO
utilizada é nova
para a equipe de
desenvolvimento

1.4. Recursos Necessarios

4.1-Recursos Humanos
Para o desenvolvimento da aplicação precisaremos de 4 especialista em diversas áreas :
 1 Gestor de Projecto
 1 Analista de Sistema

6
 Web Designer
 3 Programadores

4.2-Recursos Ambientais
4.3-Recursos de Softwares
 Ferramenta de Modelagem(Enterprise Architect).
 Ferramenta para Base dados mysql –PhpMyAdmin e JetBrains DataGrip.
 Aplicativo Para Desenvolvimento(JetBrains PhpStorm, Netbens 8.1).
 Ferramenta para Documentação(Microsoft word, excel, Visio).

4.4-Recursos de Hardware
 3 Computadores
 4 pentrav
 1 moden

1.5. Estimativas do Custo e mão de Obra

1.6. Cronograma do Projecto

7
 2. FASE DE INÍCIO
2.1. Introdução
O PDC.REST, é um portal de restaurantes, uma solução computacional, flexível, preparada
para aumentar a eficiência em qualquer tipo de restaurante, e que facilita as pessoas no seu dia-a-dia
nos demais pontos do país a comprar suas refeições.
O sector de restauração tem inúmeras especificidade e as empresas distinguem-se quase
sempre pela qualidade de atendimento. Assim sendo, é fundamental que um mercado de forte
concorrência e de grande rotatividade, o aumento das exigências legais e fiscais não comprometam
as margens de negócio e a oferta dos serviços.
Tendo em conta o contexto acima descrito a equipa usou o processo unificado de
desenvolvimento RUP para documentar todo processo envolvente na concepção do Portal de
restaurantes PDC.REST.
2.2. Participantes do Projecto
1. Esperança Kiala Mbala
2. Francelina Paím
3. Mande Manuel Paulo
4. Zandiath de Andrade

2.3. Descrição do Problema

Normalmente os estudantes, docentes e funcionários têm encarado dificuldades quanto a

aquisição de refeição, o que requer deslocação dos mesmos até aos locais onde estão situados os
restaurantes, e muitos destes restaurantes estão distantes do CampusUniversitário. A fronteira pode
não estar apenas limitada ao ambiente do CampusUniversitário, mas às demais pessoas em qualquer
ponto do país.

2.4. Objectivos do Sistema

O objectivo do projecto PDC.REST consiste na criação de um portal de restaurantes, onde
poderão ser cadastrados restaurantes e os gestores associados, o portal permitirá a venda de
refeições a clientes registados no portal.

2.5. Fluxo de Requisitos

8
 Requisitos funcionais
RF0 O Sistema permite ao utilizador registar-se como Agentes de interação ou de
1 administração
RF0 O agente efectua login ao Sistema.
2
RF0 O agente gere as suas publicações no sistema.
3
RF0 O agente cria publicações no sistema(texto ou conteúdo).
4
RF0 O agente visualiza as publicações criadas ao sistema.
5
RF0 O sistema permite ao agente visualizar perfil.
6
RF0 O agente aceita ou recusa o pedido de ligação feito por um agente.
7
RF0 O agente aceita ou recusa o pedido de ligação feito por um agente.
8
RF0 O sistema permite ao agente efectuar compra de conteudo.
9
RF1 O sistema permite ao agente pontuar publicações.
0
RF1 O sistema permite ao agente comentar publicações.
1
RF1 O sistema permite ao agente efectuar o pagamento do conteudo comprado.
2
RF1 O agente defini permissões especificas acesso a informação, associadas ao seu
3 perfil e publicações.
RF1 O agente defini permissões de omissão de acesso a informação, associadas ao seu
4 perfil e publicações.

Requisitos não funcionais do Sistema

Requisitos de Produto
RNF01 Sistema deve ser estruturado em três camadas: Servidor Web, Servidor Aplicacional
e Servidor Base de dados.
RNF02 Os utilizadores devem ter um navegador web (por exemplo: Firefox, Google
Chrome, Baidu e outros).
RNF03 O sistema deve ser implementado em PHP 5, JavaScript com banco de dados
MySql, java web.
Requisitos Organizações
RNF04 O sistema deve ser compatível com qualquer sistema operacional que possuir
browser actualizado para a acesso à Internet.
RNF05 O sistema operacional para os servidores tem de ser de base Unix (MacOS,
Linux) ou Windows.
RNF06 O sistema deve ser construído usando as linguagens script PHP, JavaScript
e uma aplicação móvel cliente.
Requisitos Externos
RNF06 O sistema deve ser imune aos ataques de SQL Injection, PHP Injection, DoS,
Session Hijacking, XSS, Broken Authentication and Session Management, Insecure
Direct Object References, Cross-Site Request Forgery (CSRF).
RNF07 Informações pessoais do utilizador não devem ser compreendidas caso haja um
ataque man-in-the-midlle.

9
 RNF08 O sistema deve implementar o processo de assinatura e certificado digital para
garantir a integridade dos utilizadores.
RNF09 A criptografia das senhas deve ser feita usando mas de uma função hash, de modo a
ser imune a ataques do tipo Rainbow Table.
RNF10 As senhas de utilizadores devem ser armazenadas de forma criptografada
RNF11 O sistema deve registar em uma base de dados as operações críticas realizadas no
sistema para permitir auditoria.
RNF12 A rede social deve registar em um log as operações realizadas no sistema para
permitir auditoria.
RNF13 Impedir acesso ao sistema a Utilizadores desactivados.

3. FASE DE ELABORAÇÃO

3.1. Fluxo de Análise e Desenho

3.1.1. Modelo de Análise

i. Diagrama de Caso de Uso do Sistema

Especificação dos casos de uso

CASO DE USO - Fazer Login

Descrição Este caso de uso especifica a acção de autenticação que um

agente executa no sistema, com objetivo de se conectar na
aplicação.
Actor Agente
Actor Secundário
Pré-condição O actor deve estar cadastrado no sistema.
Pós-condição O actor fica habilitado a realizar acções na área restrita do
sitema.
Fluxo Principal
Accões do Actor Acções do Sistema
1.solicitar o login no sistema
2.Solicita as informacoes obrigatorias para o login (nome de
utilizador e Palavra-passe).
3.Informa os dados de login
4.Valida os dados de login
5.O sistema informa que o login foi realizada com sucesso
Fluxo alternativo
Acçõoes do Actor Acoes do Sistema
1. No passo 4 do fluxo principal, caso haja algum erro na
autenticação relacionado aos dados informados:
1. O sistema informa o erro ao actor.
2. O fluxo retorna ao passo 2 do fluxo principal.
Nome do caso de uso Cadastrar agente
Descrição Este caso de uso permite ao sistema ter o controlo dos

10
 registos dos agentes(organizacional e individual)
Actores Principal Agente
Resumo Esse caso de uso descreve as etapas percorridas por um
agente para registar-se no sistema.
Actor Secundário
Pré-condição Não ter ainda nenhum registo no sistema.
Pós-condição
Fluxo Principal
Acoes do Actor Acções do Sistema
1. Solicita abertura da conta
2. O sistema solicita as informações obrigatórias paro
Registo: nome completo, username, localidade, email, etc.
2. informa os dados solicitados
3. valida os dados de registo
4. O sistema regista em histórico o registo realizado pelo
actor. Os seguintes dados são armazenados:
6. O sistema habilita as ações relacionadas ao grupo de
Utilizador ao qual pertence o actor.
5. O sistema informa que o registo foi realizada com
sucesso e o caso de uso termina
Fluxo Alternativo
Acoes do Actor Acoes do Sistema
1.No passo 4 do fluxo principal, caso haja algum erro na
autenticação relacionado aos dados informados:
2. O sistema informa o erro ao actor.
3. O fluxo retorna ao passo 2 do fluxo principal.
Restricoes/validacoes Para abrir uma conta tem que ser maior de idade
Fluxo de Excecao – Utente Menor de
idade
Acoes do Actor Acoes do Sistema
1.Comunicar ao utente que este não possui a idade minima
para possuir uma conta no sistema
2.Recusar pedido de cadastro

11