UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
SISTEMAS DE INFORMAÇÃO*
PLANO DE PROJETO DE SOFTWARE
para produtos da Lacertae SW
Fernando Lucas de Oliveira Farias – 200920001082
Jairo Charnosky do Nascimento - 200820005298
São Cristóvão
2016

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
SISTEMAS DE INFORMAÇÃO*
PLANO DE PROJETO DE SOFTWARE
para produtos da Lacertae SW
Projeto apresentado ao Prof. Dr. Rogério Patrício Chagas
do Nascimento como parte do processo de avaliação da
disciplina Gerência de Projetos no curso de graduação em
Sistemas de Informação – Bacharelado da Universidade
Federal de Sergipe
São Cristóvão
2016

SUMÁRIO
1. INTRODUÇÃO...................................................................................................................... 4
1.1 Âmbito do Projeto..................................................................................................................... 4
1.2 Funções principais do produto de software .............................................................................. 4
1.3 Requisitos comportamentais ou de performance...................................................................... 8
1.4 Gestão e Restrições Técnicas.................................................................................................... 8
2. ESTIMAÇÕES DO PROJETO................................................................................................... 8
2.1 Técnicas de estimação e resultados....................................................................................... 9
2.1.1 Técnica de estimação ..................................................................................................... 9
2.2 Resultados........................................................................................................................... 10
2.3 Recursos do projeto............................................................................................................. 11
3. ANÁLISE E GESTÃO DE RISCOS........................................................................................ 12
3.1 Riscos do projeto..................................................................................................................... 12
3.2 Tabela de riscos................................................................................................................... 13
3.3 Redução e Gestão do Risco................................................................................................. 13
4. PLANEAMENTO TEMPORAL.............................................................................................. 15
4.1 Conjunto de Tarefas do Projeto .......................................................................................... 15
4.2 Diagrama de Gantt .............................................................................................................. 15
5. ORGANIZAÇÃO DO PESSOAL............................................................................................ 18
5.1 Estrutura da equipe ............................................................................................................. 18
5.2 Mecanismos de comunicação ............................................................................................. 19
5.3 Uso do Edu-blog como ferramenta de apoio ...................................................................... 19
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SW ...................................................................................................................... 19
7. REFERÊNCIAS........................................................................................................................ 19

1. INTRODUÇÃO
1.1 Âmbito do Projeto
Criar um sistema integrado para gerenciamento das atividades administrativas de um
Centro de Formação de Condutores. Proporcionando melhorias no cotidiano dos gestores e
colaboradores destes estabelecimentos através do fornecimento de ferramentas e indicadores
KPI que auxiliem na gestão e apoio a decisões de cunho tático e/ou estratégico.
1.2 Funções principais do produto de software
As funcionalidades e seus respectivos usuários constam na tabela abaixo:
Funcionalidade Usuário
GerenciarAgendamentodeAulas Aluno
GerenciarAlunos Atendente
GerenciarTurmas Atendente
GerenciarVeiculos Administrador
GerenciarUsuarios Administrador
GerenciarPlanodeContas Administrador
Tabela 01 - Principais funcionalidades e usuários
Figura 1 – Diagrama de Casos de Uso

Figura 2 – Diagrama de Classes “Agendamento de Aulas”
Figura 3 – Diagrama de Classes “GerenciarAluno”

Figura 3 – Diagrama de Classes “GerenciarFuncionario”
Figura 4 – Diagrama de Classes “GerenciaTurmas”

Figura 5 – Diagrama de Classes “GerenciaUsuario”
Figura 6 – Diagrama de Classes “GerenciaVeiculo”

1.3 Requisitos comportamentais ou de performance
Os clientes necessitam que o sistema disponha dos seguintes requisitos:
 Interfaces deverão proporcionam uma experiência rica para usuário em termos de
ergonomia e usabilidade, ao tempo em que deverão considerar as heurísticas de nielsen;
 Usuários poderão operar o sistema e conseguir atingir seus objetivos sem dificuldade.
 O sistema deverá ter o menor número de falhas possível, e quando falhar ter formas de
auxiliar na solução do mesmo;
 Segurança Criptografada com conexão TLS/SSL 3.0;
 Permitir apenas o acesso as pessoas autorizadas;
 Implementar os princípios da segurança da informação (Confiabilidade, integridade e
disponibilidade);
 O sistema deverá operar 24h por dia todos os dias.
1.4 Gestão e Restrições Técnicas
Teremos as seguintes restrições técnicas:
● A linguagem de desenvolvimento será C#;
● Sistema de Gerenciamento do Banco de Dados será SQLServer 2012 ou superior.
● Cliente deverá ter acesso a internet para acessar o sistema.
● Arquitetura escalável de baixo acoplamento que permita customizar o produto, conforme
especificações do cliente.
2. ESTIMAÇÕES DO PROJETO
Para o desenvolvimento do sistema foi feita uma estimativa com base na métrica de
Lorenz & Kidd o qual se ajusta factivelmente ao projeto.

2.1 Técnicas de estimação e resultados
A técnica de estimação utilizada foi o Lorenz & Kidd que têm como base o cálculo
quantitativo de alguns aspectos fundamentais da Orientação a Objetos, como os atributos e
serviços, herança, coesão e acoplamento.
2.1.1 Técnica de estimação
Para usar esta métrica devemos seguir alguns passos:
1. Definir o número de classes chave;
2. Encontrar o número de classes de suporte, que para isso temos que classificar o tipo de
Interface do Produto e desenvolver um Multiplicador para as Classes de Suporte;
3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter uma estimativa
do número de classes de suporte;
4. Logo após, calcula-se a quantidade total de Classes, somando o nº de Classes-Chave com
o nº de Classes de Suporte;
5. Multiplicar a quantidade total de Classes (classes-chave + classes de suporte) pelo
“número médio de unidades de trabalho (dias-pessoa) por classe”. Lorenz & Kidd sugere entre
15 e 20 dias-pessoa por classe. Escolher um número entre 15-20 dias-pessoa e justificar a
escolha.
6. Determinar a quantidade de esforço estimada;
7. Cálculo do tempo previsto para a elaboração do projeto.
A tabela abaixo mostra os fatores de multiplicação para encontrar a quantidade de classes
de suporte:
Interface Multiplicador
Não gráfica 2
Baseada em texto 2,25
GUI 2,5
GUI complexa 3
Tabela 02 - Fator de multiplicação

2.2 Resultados
De acordo com a métrica descrita acima obtivemos os seguintes resultados:
1. Quantidade de classes chaves = 8;
a. GerenciarAluno;
b. GerenciarFuncionario;
c. GerenciarAgendamentodeAlulas;
d. GerenciarVeiculo;
e. GerenciarUsuario;
f. GerenciarTurmas;
g. GerenciarPagamentos;
h. Autenticacao;
2. Sistema WEB, então utilizaremos a interface gráfica GUI = 2,5;
3. Classes chaves x multiplicador (8 x 2,5) = 20 classes de suporte;
4. Classes chaves + classes de suporte (8 + 20) = 28 classes projetada para o sistema;
5. A nossa empresa possui os profissionais mais bem remunerados e capacitados do
mercado, logo será aplicado o melhor tempo possível de acordo com Lorenz & Kidd.
Neste caso 15 dias/pessoa;
6. Podemos agora calcular a quantidade de esforço estimada: (28 x 15) = 420 dias de
trabalho;
A equipe para desenvolvimento deste projeto contem 2 membros, podemos então calcular a
distribuição dos dias de trabalho por pessoa. Com isso tenho 420 ÷ 2 = 110 dias por pessoa.
Aplicando a distribuição dos dias de trabalho aos percentuais de cada fase tenho a seguinte
situação:

Modelo % modelo % projeto Cálculo Dias
trabalho
Planejamento 2 – 3% 3% 110 x 3% 4
Requisito-Analise-Desenho 40% 40% 110 x 40% 44
Geração de código 20% 20% 110 x 20% 22
Testes 37-38% 37% 110 x 37% 40
Resultado 110
Tabela 03 - Estimativa de cada etapa do projeto
2.3 Recursos do projeto
Os recursos usados para elaboração deste projeto serão: humanos, de software, hardware e
bibliográficos.
Recursos humanos:
A equipe de desenvolvimento do projeto é formada por dois membros, Fernando Lucas de
Oliveira Farias (Bacharelando do Curso de Ciência da Computação) e Jairo Charnosky do
Nascimento (Bacharelando do Curso de Sistemas de Informação).
Recursos de Software:
Para o desenvolvimento deste projeto serão utilizadas as seguintes ferramentas de software:
Visual Studio 2010: Software que fornece suporte ao desenvolvimento na Linguagem de
programação C# e que utiliza o framework .NET e ASP.NET MVC.
C#: Linguagem de programação orientada a objetos utilizada na construção e manutenção dos
softwares com recursos para WEB.
SQLServer: Sistema para gerência de banco de dados relacional muito usado em empresas e por
grandes sistemas corporativos.
GanttProject: Utilizado para gerenciamento da estrutura analítica do projeto (EAP).
GoogleDocs: Utilizada para elaboração da documentação técnica e colaboração entre os
membros do projeto.
Internet Explorer: Browser para homologação de funcionalidades do produto.
Mozila Firefox: Browser para homologação de funcionalidades do produto.
Google Chrome: Browser para homologação de funcionalidades do produto.
Linux Ubuntu ou Debian: Sistemas operacionais open source utilizado para homologação de
funcionalidades do produto.

Windows 7 ou 10: Sistemas operacionais proprietários utilizado para homologação de
funcionalidades do produto.
Recursos Hardware:
Os hardwares utilizados para elaboração do projeto são:
· Computadores Pessoais PC da Sony e Samsumg
· Impressora para testes de impressão
Recursos Bibliográficos:
O recurso bibliográfico utilizado foi o que segue:
PRESSMAN, Roger S. Engenharia de Software, 6ª edição, São Paulo, McGraw-Hill, 2006
3. ANÁLISE E GESTÃO DE RISCOS
A análise de riscos é importante para um projeto, pois assim o gestor pode se prevenir para saber
administrá-los.
3.1 Riscos do projeto
RISCO PROJETO TÉCNICO NEGÓCIO COMUM ESPECIAL
Insuficiência de pessoas na
equipe
X
Prazo para entrega curto X
Pouco tempo para
treinamento dos usuários
X X
Mudança nos requisitos
Rotatividade de Pessoal X X
Tecnologia e Infraestrutura
(Danos)
X
Quadro 1 – Riscos do Projeto

3.2 Tabela de riscos
RISCO CATEGORIA PROBABILIDADE IMPACTO
Insuficiência de pessoas na
equipe
Pessoal 60% Crítico
Prazo para entrega curto Técnico 70% Crítico
Pouco tempo para
treinamento dos usuários
Projeto 30% Marginal
Mudança nos requisitos Projeto 10% Crítico
Rotatividade de Pessoal Pessoal 20% Catastrófico
Tecnologia e Infraestrutura
(Danos)
Técnico 10% Catastrófico
3.3 Redução e Gestão do Risco
Apresentamos aqui as ações a serem tomadas para, prever, reduzir ou gerir os riscos
identificados.
Insuficiência de pessoas na equipe
Risco:001 Probabilidade: 60% Impacto: Crítico
Descrição: O numero de profissionais efetivos na nossa equipe é reduzido.
Estratégia de redução: Contratação de estagiários e trainners para serem capacitados
pelos profissionais mais experientes do projeto.
Plano de contingência:
a. Criação de um banco de talentoso para simplificar a contratação de profissionais
com perfil desejado;
b. Terceirização de mão-de-obra com pagamento condicionado as entregas
efetivamente realizadas e após aprovação do cliente.
Pessoa responsável: Fernando Lucas de Oliveira Farias
Status: Simulação completada
Prazo para entrega curto
Risco:002 Probabilidade: 70% Impacto: Crítico
Descrição: O cliente exigiu cumprimento do prazo em 50% do prazo calculado
Estratégia de redução: Ampliação da equipe permanente e terceirização de parte das
entregas do projeto.
Plano de contingência:
a. Contratação de profissionais freelancers conforme etapa do projeto;
b. Contratação de fábrica de software;

c. Renegociar o prazo do projeto com cliente.
Pessoa responsável: Fernando Lucas de Oliveira Farias
Status: Simulação Incompleta
Pouco Tempo para Treinamento dos Usuários
Risco:003 Probabilidade: 30% Impacto: Marginal
Descrição: Os treinamentos serão executados em turnos corridos de forma a reduzir
em 30% da carga horária originalmente definida
Estratégia de redução: Elaborar parte do conteúdo para ser disponibilizado
modalidade EAD para os participantes
Plano de contingência:
a. Estruturação de um Ambiente Virtual de Aprendizagem para disponibilizar partes do
treinamento;
b. Execução de dinâmicas de grupo e estudos dirigidos para simplificar o aprendizado
determinados conteúdos;
c. Disponibilização de videoaulas para redução do tempo das exposições teóricas.
Pessoa responsável: Fernando Lucas de Oliveira Farias
Status: Simulação completada
Mudanças nos requisitos
Risco:004 Probabilidade: 10% Impacto: Crítico
Descrição: A falta de conhecimento detalhado das regras de negócios por parte do
cliente pode resultado em mudanças nos requisitos do projeto
Estratégia de redução: Documentar a elicitação de requisitos com ateste por parte do
cliente
Plano de contingência:
a. Estabelecer fator de correção para custo e cronograma do projeto por pontos de
função alterados;
Pessoa responsável: Fernando Lucas de Oliveira Farias
Status: Simulação Completa
Rotatividade de Pessoal
Risco:005 Probabilidade: 20% Impacto: Catastrófico
Descrição: A perda de profissionais para o serviço público pode prejudicar a execução
do cronograma junto ao cliente
Estratégia de redução: Criação de plano de carreira com remuneração conforme
resultado e tempo na empresa
Plano de contingência:
a. Criar plano de carreira com cargos e salários;
b. Política agressiva de valorização dos profissionais pelo tempo na empresa
c. Contrato de permanência mínima na empresa independente de projetos.

Pessoa responsável: Fernando Lucas de Oliveira Farias
Status: Simulação completada
Tecnologia e Infraestrutura (Danos)
Risco:006 Probabilidade: 10% Impacto: Catastrófico
Descrição: Danos no hardware dos servidores de aplicação ou máquinas dos membros
da equipe podem comprometer os prazos e entregas planejadas
Estratégia de redução: Compra de máquinas e hardware sobressalentes e estrutura
redudante para servidores e serviços de missão crítica
Plano de contingência:
a. Compra de computadores sobressalentes
b. Compra de servidores redundantes
c. Contratação de link dedicado redundante de internet
Pessoa responsável: Fernando Lucas de Oliveira Farias
Status: Simulação completada
4. PLANEAMENTO TEMPORAL
4.1 Conjunto de Tarefas do Projeto
TAREFAS MACRO PORCENTAGEM TEMPO (DIAS DE TRABALHO)
Planejamento 3% 4
Análise de Requisitos e Modelagem 40 44
Codificação 20% 22
Testes 37% 40
4.2 Diagrama de Gantt
Na figura 1, são representadas todas as tarefas que serão realizadas durante o processo de
desenvolvimento do projeto e seu tempo de duração.

Figura 7 – Diagrama de Gantt - EAP do Projeto
A fase de planejamento foi dividida em:
● Levantamento de requisitos: Definindo e delimitando o problema.
○ Entrevista com os clientes: Forma inicial de obtenção de dados, onde utilizamos
de uma conversa direcionada ao problema através de “pergunta-resposta”.
○ Reunião com os administradores: Reunião com os administradores do negócio,
obtendo desta forma informações mais específicas do problema.
● Validação de requisitos: Sub fase onde validaremos o documento produzido com o
sistema que o cliente deseja.
A fase de análise e projeto foi dividida em:
● Criação de casos de uso: Cada caso de uso descreve a interação com o seu usuário, ou
outro sistema.
● Criação de diagramas de classe de domínio: As classes de domínio identificam os
conceitos relacionados a requisitos do sistema e analisa o problema sob a perspectiva
conceitual.
● Definição da arquitetura do projeto: A Arquitetura do Projeto é baseado no padrão MVC
pela predominância web da plataforma, permitindo abstrair as regras de negócios

(controller) da apresentação dos dados (Models e Views) simplicando customizações do
projeto.
● Criação do diagrama de classes de projeto: Representação dos objetos ou entidades do
projeto e seus relacionamentos a exemplo de funcionário, aluno, veículos, entre outros.
● Criação do diagrama de sequência: Utilizado para demonstrar a interação ou trocas de
mensagens entre vários objetos de um determinado contexto (Figura. 8).
Figura 8 – Diagrama de Sequência – Novo Agendamento
A fase de codificação foi dividida em:
● GerenciarAluno;
● GerenciarFuncionario;
● GerenciarAgendamentodeAlulas;
● GerenciarVeiculo;
● GerenciarUsuario;
● GerenciarTurmas;
● GerenciarPagamentos;
● Autenticacao;
A fase de testes foi dividida nos seguintes níveis:
● Teste de unidade: Tem por objetivo explorar a menor unidade do projeto, procurando
provocar falhas ocasionados por defeitos de lógica e de implementação de cada módulo,
separadamente.
● Teste de integração: Provocar falhas nas interfaces entre os módulos.
● Teste de sistema: Teste em busca de falhas como se fosse um usuário final.

● Teste de aceitação: Teste junto ao usuário final, validando a o comportamento do
software com o solicitado pelo cliente.
5. ORGANIZAÇÃO DO PESSOAL
5.1 Estrutura da equipe
A equipe é composta por: Fernando Lucas de Oliveira Farias e Jairo Charnosky do
Nascimento, a tabela abaixo destrincha as funções de cada um:
Integrante Função Sumário de atividades
Fernando Lucas
de Oliveira Farias
Gestor do projeto Tem a responsabilidade de coordenar todo
o desenvolvimento do projeto,
combinando reuniões, distribuindo tarefas,
resolver conflitos e manter a motivação e
bom ambiente no seio do grupo, alem de
ser responsável pelo planejamento
temporal do projeto compondo o diagrama
de Gantt.
Jairo Charnosky
do Nascimento e
Fernando Lucas
de Oliveira Farias
Analista de sistema tem a função de analisar o software e
desenhar os vários diagramas do sistema e
criar as classes e interfaces a implementar.
Fernando Lucas
de Oliveira Farias
Arquiteto do software Desenvolver a arquitetura do sistema,
inclusive os diagramas de projeto.
Jairo Charnosky
do Nascimento e
Fernando Lucas
de Oliveira Farias
Programadores Desenvolver o código do sistema.
Jairo Charnosky
do Nascimento e
Fernando Lucas
de Oliveira Farias
Testadores Testar os casos de uso do software.
Tabela 1 - Funções dos integrantes da equipe.

5.2 Mecanismos de comunicação
A comunicação entre todos os elementos da equipe é feita principalmente através de
reuniões periódicas, resolvem-se problemas em conjunto e distribuem-se tarefas. Além disso, são
também utilizados os meios de comunicação eletrônica, através de correio eletrônico,
mensageiros instantâneos e videoconferência.
5.3 Uso do Edu-blog como ferramenta de apoio
Edu-blog se mostrou uma excelente ferramenta de suporte à disciplina, pelo aspecto simplório,
interativo e agradável, permitindo ao docente disponibilizar o material de apoio a disciplina. Por
conseguinte, possibilitou a comunicação dinâmica entre o docente e todos os alunos, sendo muito
útil a cada discente na apresentação de suas dúvidas e/ou sugestões.
Em relação aos blogs de cada equipe, achamos que é também interessante na medida em que
permite a cada grupo partilhar com a comunidade o desenvolvimento do seu trabalho,
disponibilizando arquivos, bem como receber sugestões e criticas de qualquer pessoa.
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SW
Implementar uma gerência de configuração sólida e bem difundida entre os membros do
projeto com procedimentos bem documentados para realização de commit, branches e tags no
repositório do projeto que utilizará a ferramenta SVN.
Contratar um consultor em gerência de qualidade para aferição dos artefatos
desenvolvidos e auxiliar na normatização dos procedimentos
Instituir as boas práticas do CMMI no desenvolvimento do produto, tendo como meta
manter-se entre os níveis 3 (Definido) e 4 (Gerenciado quantitativamente) de maturidade.
7. REFERÊNCIAS
SOMMERVILLE, Ian. Engenharia de Software. 9 ed. São Paulo. Pearson, 2011.
PRESSMAN, Roger. Engenharia de Software. 6 ed. Macgraw-Hill Interamericana, 2006.