1. O documento descreve um plano de projeto de software para um sistema de gerenciamento de atividades administrativas de um Centro de Formação de Condutores. 2. As principais funções do sistema incluem cadastro de instrutores, alunos, veículos e aulas, além de relatórios gerenciais. 3. Estimativas de prazo, custo e esforço serão realizadas usando a métrica de Lorenz & Kidd.

1. 1
UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
DEPARTAMENTO DE SISTEMAS DE INFORMAÇÃO
Fernando Lucas de Oliveira Farias
Jairo Charnoski do Nascimento
PLANO DE PROJETO DE SOFTWARE
CENTRO DE FORMAÇÃO DE CONDUTORES
São Cristóvão, 13 de Abril de 2016

2. 2
SUMÁRIO
1. INTRODUÇÃO
1.1.DESCRIÇÃO DO PROJETO
1.1.1.Finalidade
1.1.2. Definições, Acrônimos e Abreviações
1.1.3. Referências
2. POSICIONAMENTO
2.1. Oportunidade de Negócios
2.2. Descrição do Problema
2.3. Sentença de Posição do Produto
3. DESCRIÇÕES DOS ENVOLVIDOS E DOS CLIENTES
3.1. Demografia dos Mercados
3.2. Resumo dos Envolvidos
3.3. Resumo dos Clientes
3.4. Ambiente dos Clientes
3.5. Perfis dos Envolvidos
3.5.1
3.5.2
3.6. Principais Necessidades dos Envolvidos ou dos Clientes
3.7. Alternativas e Concorrência
4. PRINCIPAIS FUNÇÕES DO SISTEMA
4.1.As principais funções são:
4.2.Cadastro de Instrutores;
4.3.Cadastro de Veículos;
4.4.Cadastro de Alunos;
4.5.Gerenciamento das aulas práticas por categoria da habilitação A,B,C, D e E;
4.6.Gerenciamento das aulas teóricas;
4.7.Relatórios;
5. RESTRIÇÕES
6. ESTIMATIVAS DO PROJETO
6.1 DADOS HISTÓRICOS
6.2 TÉCNICAS DE ESTIMATIVAS E RESULTADOS
6.2.1 TÉCNICAS DE ESTIMATIVA
6.3 RESULTADOS
6.4 RECURSOS DO PROJETO
6.5 DIAGRAMA DE GANTT
7. ANÁLISE E GESTÃO DE RISCOS
7.1 RISCOS DO PROJETO
7.2 TABELA DE RISCOS
7.3 REDUÇÃO E GESTÃO DE RISCOS
8. ORGANIZAÇÃO DO PESSOAL
8.1 ESTRUTURA DA EQUIPE

3. 3
8.2 MECANISMOS DE COMUNICAÇÃO
8.3 USO DO EDU-BLOGCOMO FERRAMENTA DE APOIO

4. 4
1. INTRODUÇÃO
Esta seção descreve uma visão geral sobre o projeto de software, elencando suas
principais funcionalidades, regras de negócio, restrições na implantação do software
CFCSYSTEM concebido com a finalidade de prover um sistema integrado para gerenciamento
de atividades administrativas de um Centro de Formação de Condutores.
1.1.DESCRIÇÃO DO PROJETO
1.1.1.Finalidade
Criar um sistema integrado de gerenciamento de atividades administrativas de
um Centro de Formação de Condutores, para auxiliar e melhorar a ação dos gestores e
colaboradores do referido estabelecimento. Criar estatísticas e relatórios para agilizar
processos bem como auxiliar na tomada de decisões.
1.1.2. Definições, Acrônimos e Abreviações
CFC - Centro de Formação de Condutores.
1.1.3. Referências
● Visão Geral do Negócio - disponível em
http://www.wthreex.com/rup/portugues/webtmpl/templates/req/rup_vision.htm e
acessado em 10/12/2012.
● L&C – Aplicação Delphi – Sistema da Auto Escola Lindomar e Cristina;
2. POSICIONAMENTO
2.1. Oportunidade de Negócios

5. 5
Os processos administrativos e gerenciais executados em um Centro de Formação de
Condutores são realizados de forma manuscrita, gerando atraso dos processos bem
como aumento de custo com materiais de escrituração.
Visto isso, imaginou-se um sistema de informação que gerencie e agilize todos os
processos executados no estabelecimento, sendo assim agregando valor ao negócio bem
como aumentando a satisfação dos clientes e usuários.
No momento não existem concorrentes para esse sistema, o que, aliado às suas
funcionalidades o torna um produto único e de grande valor para o cliente.
2.2. Descrição do Problema
O problema de Acúmulo de papelada, Atraso na execução de
processos administrativos, Carência de relatórios
que auxiliem na tomada de decisões.
Afeta Clientes, Colaboradores e Gestores do CFC.
Cujo impacto é Insatisfação dos clientes, desperdício de tempo e
sobrecarga dos colaboradores e prejuízos
financeiros.
Uma boa solução seria Automatização dos processos a fim de agilizar o
atendimento aos clientes; Controle eficaz dos
recursos (financeiros, humanos, etc), tornando assim
a organização mais diferenciada e competitiva.
2.3. Sentença de Posição do Produto

6. 6
Para Centros de Formação de Condutores (CFC).
Que Processos administrativos e gerenciais de um CFC.
O (nome do produto) Sistema de Gerenciamento de Atividades de um CFC.
Que Agiliza os processos de um CFC a fim de garantir o
melhor atendimento aos clientes, controlar de forma
eficaz os recursos (financeiros, humanos, etc),
tornando assim a organização mais diferenciada e
competitiva.
Diferente de Não existem produtos similares, até o momento.
Nosso produto Demanda por um sistema que auxilie no
gerenciamento das atividades de um CFC.
3. DESCRIÇÕES DOS ENVOLVIDOS E DOS CLIENTES
3.1. Demografia dos Mercados
Até o momento em Itabaiana e nas regiões circunvizinhas, não foi encontrado um CFC
que possui um sistema que atenda suas necessidades, pois ainda a maioria dos processos
é realizada de forma manuscrita, sendo assim desperdiçando tempo e gerando
desconforto para clientes e usuários finais. Para atender essa demanda, visou-se então o
desenvolvimento de um sistema que automatize todos os processos de um CFC a fim de
garantir maior rapidez no atendimento, maior confiabilidade da informação e tornar a
empresa mais competitiva.

7. 7
3.2. Resumo dos Envolvidos
Nome Descrição Responsabilidades
Desenvolvedores Alunos do Curso de
Sistemas de Informação -
Bacharelado e Ciência da
Computação
- assegurar que o sistema
poderá ser mantido.
- garantir a segurança da
informação.
- assegurar que haverá uma
demanda de mercado pelos
recursos do produto.
- monitora o andamento do
projeto.
3.3. Resumo dos Clientes
Nome Descrição Responsabilidades
Usuário do
sistema
Cadastrar as
informações dos
clientes, instrutores,
recursos (veículos),
aulas, exames.
- conceder informações precisas dos itens a
serem cadastrados.
- executar o trabalho.
- preparar relatórios que agilizem os
processos executados pelo mesmo.
Administrado
r
Analisa as
informações em
forma de relatório e
gráficos.
- preparar relatórios gerenciais para
melhoria da tomada de decisões.
- gerenciar o acesso dos usuários do
sistema.

8. 8
3.4. Ambiente dos Clientes
Atualmente em Itabaiana, um CFC possui, em média, cinco colaboradores para o setor
administrativo. Sendo que um colaborador atende, em média, quatro clientes em torno
de quarenta minutos. Todo o trabalho de escrituração é realizado manualmente, usando
formulários impressos em papel, tornando o processo demorado e sujeito a erros. Esses
colaboradores realizam o preenchimento do cadastro de clientes, agendamento de aulas
práticas e teóricas, preenchimento dos formulários de pagamento dos clientes, sendo
que todas essas atividades são realizadas de forma manuscrita.
3.5. Perfis dos Envolvidos
3.5.1
Representante Auxiliar Administrativo
Descrição Agente responsável pelo atendimento ao cliente em um
CFC.
Tipo Emissor / Executor.
Responsabilidades Cadastro de clientes e recursos; recebimento de
pagamento; agendamento das aulas práticas e teóricas.
Critérios de Sucesso Agilidade na execução dos processos e maior rendimento
profissional.
3.5.2
Representante Sócio-Administrador.

9. 9
Descrição Responsável direto pelo CFC.
Tipo Administrador.
Responsabilidades Relatórios gerenciais para a tomada de decisões e controle
de acesso aos usuários do sistema.
Critérios de Sucesso Ser um diferencial no mercado e agregar valor ao negócio.
3.6. Principais Necessidades dos Envolvidos ou dos Clientes
Agilidade, disponibilidade e funcionalidade dos serviços prestados pelo CFC.
3.7. Alternativas e Concorrência
Atualmente não existe um sistema para atender a essa demanda.
4. PRINCIPAIS FUNÇÕES DO SISTEMA
4.1.As principais funções são:
4.1.1. Adicionar, Editar, Excluir e Consultar Usuários;
4.1.2.4.1.Gerenciamento de usuários e perfis de acesso;
Adicionar, Editar, Excluir e Consultar Grupos;
4.1.3. Vincular Usuários a grupos;
4.1.4. Configurar Permissões de Grupos e/ou Usuários;
4.2.Cadastro de Instrutores;
4.2.1. Adicionar, Editar, Excluir e Consultar Instrutores;

10. 10
4.2.2. Adicionar, Editar, Excluir e Consultar Veículos conduzidos pelo instrutor;
4.2.3. Adicionar, Editar, Excluir e Consultar Alunos pertencentes ao mesmo;
4.2.4. Agenda do Instrutor;
4.2.4.1.Cronograma de Aulas Práticas;
4.2.4.2.Cronograma de Aulas Teóricas;
4.2.4.3.Relatório de Aulas (Semanal, Mensal, Período x de y);
4.3.Cadastro de Veículos;
4.4.Cadastro de Alunos;
4.4.1. 1ª Habilitação;
4.4.1.1.Exame Médico (Validade: 5 Anos);
4.4.1.2.Exame Psicotécnico (Validade: 5 Anos);
4.4.1.3.Curso Teórico (9 Aulas – 45h/aula);
4.4.1.4.Prova Teórica;
4.4.1.5.Aulas Práticas em vias públicas (20 Aulas – 20h/aula);
4.4.1.6.Prova Prática;
4.4.2. Adição de Categoria;
4.4.2.1.Exame Médico (Validade: 5 Anos);
4.4.2.2.Aulas Práticas em vias públicas (15 Aulas);
4.4.2.3.Prova Prática;
4.4.3. Mudança de Categoria
4.4.3.1.Exame Médico (Validade: 5 Anos);
4.4.3.2.Exame Psicotécnico (Validade: 5 Anos);
4.4.3.3.Aulas Práticas em vias públicas (15 Aulas);
4.4.3.4.Prova Prática;
4.4.4. Aulas Particulares;
4.4.4.1.Grade de Aulas;
4.5.Gerenciamento das aulas práticas por categoria da habilitação A,B,C, D e E;
4.5.1. Grade de Aulas;

11. 11
4.6.Gerenciamento das aulas teóricas;
4.6.1. Turmas;
4.6.2. Certificado;
4.7.Relatórios;
4.7.1.1.Alunos;
4.7.1.2.Tipo de Pagamento (À vista, prazo, boleto, cheque,...);
4.7.1.3.Serviços selecionados (1ª Habilitação, Adição de Categoria, ou Mudança de
Categoria,...);
4.7.1.4.Valor Total;
4.7.1.5.Alunos Curso Teórico;
4.7.1.5.1. Turmas Finalizadas;
4.7.1.5.2. Turmas em Andamentos;
4.7.1.5.3. Turmas Canceladas;
4.7.1.6.Alunos Curso Prático;
4.7.1.6.1. Categoria;
4.7.1.6.1.1.Grades em Aberto;
4.7.1.6.1.2.Grades Finalizadas;
4.7.2. Instrutores;
4.7.2.1.Relatório de aulas ministradas;
4.7.2.2.Valor hora/aula;
4.7.2.3.Valor a pagar por período;
4.7.3. Gerência
4.7.3.1.Relatório do Total de alunos matriculados;
4.7.3.2.Relatório das Receitas por serviço prestado (1ª Habilitação, Adição de Categoria,
ou Mudança de Categoria,...);
4.7.3.3.Relatório das despesas por Instrutor;
4.7.3.4.Relatório das receitas e despesas por veículo;
4.7.3.5.Relatório das receitas por tipo de pagamento (À vista, prazo, boleto, cheque,...);

12. 12
5. RESTRIÇÕES
O sistema deve estar disponível online 24/7/365. Garantia da segurança da
informação. Arquitetura Escalável de baixo acoplamento que permita customizar o
produto, conforme especificidades do cliente.
6. ESTIMATIVAS DO PROJETO
Nesta seção serão realizadas as estimativas de custo, esforços e tempo através da
implementação de práticas de gerenciamento que proporcionem uma melhor abordagem para
compreender e controlar os riscos deste projeto, ao tempo em que a cadeia de distribuição
(DIST) proverá o padrão necessário para comunicar as entradas do projeto e as incertezas das
saídas, de modo que os membros do projeto possam, de forma não ambígua, possam
compartilhar suas incertezas sobre prazos, custos e outros fatores com os gerentes de todos os
níveis e áreas.
6.1 DADOS HISTÓRICOS
Como se trata de um projeto desenvolvimento para fins didáticos e acadêmico, não há
dados históricos a serem compartilhados neste documento.
6.2 TÉCNICAS DE ESTIMATIVAS E RESULTADOS
É demonstrado aqui como efetuar o cálculo para encontrar o prazo total de duração do
projeto (em dias). Foi utilizada a métrica de Lorenz & Kidd, aconselhada pela Lacertae
Software para estimar o prazo total deste projeto.
6.2.1 TÉCNICAS DE ESTIMATIVA
Utilizamos uma técnica baseada em recomendações dos servidores do NTI da UFS, por
se tratar de uma métrica orientada a classes pelos aspecto simplório e pragmático, neste sentido,
seguem as regras da métrica de Lorenz & Kidd.
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;

13. 13
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. Calculo 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 de fator de multiplicação
6.3 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;
7. Agora vamos calcular os dias corridos para construir o sistema, incluindo os fins de
semana, fazendo a multiplicação dos dias de trabalho com os 30 dias do mês e dividindo
por 22 dias uteis: (420 x 30) = 12.600 ÷ 22 = 572,72 ≈ 573 dias corridos. Para saber os
meses corridos basta dividir o resultado por 30. (573 ÷ 30) = 19,1 ≈ 19 meses corridos.

14. 14
A equipe para desenvolvimento deste projeto contem 2 membros, posso
então calcular a distribuição dos dias de trabalho por pessoa. Com
isso tenho 573 ÷ 2 = 286,5 ≈ 287 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% 287 x 3% 9
Requisito-Analise-Desenho 40% 40% 287 x
40%
115
Geração de código 20% 20% 287 x
20%
57
Testes 37-38% 37% 287 x
37%
106
Resultado 287
Tabela dos dias para termino do projeto
6.4 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, são eles:
Fernando
· Gestor de Projeto
· Analista de sistemas
· Programador de Software
· Engenheiro de Software
Jairo
· Engenheiro de Software
· Programador de Software
· Testador de Software
Recursos de Software:
Para o desenvolvimento deste projeto serão utilizadas as seguintes ferramentas de software:
· Visual Studio 2010, software que dá apoio ao desenvolvimento em Linguagem de
programação C# e que utiliza o framework .NET e ASP.NET MVC.
· C#, linguagem de programação orientada a objetos, para a construção e manutenção dos
softwares com recursos para WEB.
· SQLServer, sistema de gerência de banco de dados relacional muito usado em empresas e por
grandes sistema corporativos.
· GanttProject, utilizado para facilitar a administração do projeto.
· GoogleDocs, para fazer documentações simples.
· Internet Explorer, browser de Internet.

15. 15
· Mozila Firefox, browser de Internet.
· Google Chrome, browser de Internet.
. Linux Ubuntu ou Debian, sistemas operacionais.
. Windows 7 ou 10, sistema operacional.
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
6.5 DIAGRAMA DE GANTT
O diagrama de Gantt é ilustrado a seguir, trata-se de um gráfico que mostra todas as tarefas
planejadas com suas datas de inicio e fim e os recursos utilizados.
Imagem do diagrama de Gantt

16. 16
7. 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.
7.1 RISCOS DO PROJETO
Existe um subconjunto de riscos que estão presentes em qualquer projeto de software, riscos
gerais, que são indicados na tabela seguinte:
Risco Projeto Técnic
o
Negócio Comum Especial
Equipamento não disponivel X
Requisitos incompletos X X
Uso de metodologias especiais X X
Problemas na busca da
confiabilidade requerida
X X
Retenção de pessoas chave X X
Sub-estimativa do esforço X X
Tabela de subconjunto de riscos
Avaliação global dos riscos:
1. O Gestor de Software dá suporte ao projeto?
Sim, Fornecendo os recursos necessários ao pleno desenvolvimento do projeto controlando sua
qualidade e disponibilizando informações técnicas, assim como, alocação dos líder e equipe em
cada etapa do projeto, gerenciando todo o projeto até o produto final.
2. Os Clientes estão entusiasmados com o projeto e o produto?
Sim, pois reduzirá o retrabalho em uma série de atividades administrativas da Autoescola e
principalmente por permitir uma gestão eletrônica, automatizada e eficiente.
3. Os Engenheiros de Software compreenderam bem os requisitos?
Inicialmente houve uma dificuldade na elicitação de alguns requisitos através da aplicação de
questionário, contudo, após a ampliação do processo com utilização de outras técnicas como
Brainstorming e etnografia a compreensão ocorrera com bem sucedida.
4. Os Clientes estiveram envolvidos na definição dos requisitos?
Sim, realizamos diversas reuniões para elicitação dos requisitos que incluíram Brainstorming,
entrevistas e Etnografia.

17. 17
5. O âmbito do projeto é estável?
Relativamente, ao tempo em que não há como emitir parecer com precisão diante do estágio
incipiente da solução em fase alfa.
6. Os engenheiros de Software têm as competências requeridas?
Sim, os engenheiros são bem capacitados para gerir as configurações e mudanças no sistema.
7. Os requisitos do projeto são estáveis?
Sim, de acordo com os treinamentos, os requisitos implantados, parecem não precisar de
mudanças, se alguma mudança for feita, será mais para acrescentar do que para tirar ou alterar.
8. A Equipe de Desenvolvimento tem experiência na tecnologia a implementar?
Sim, tendo em vista as diversas atividades de capacitação realizadas.
9. É adequado o número de pessoas da equipa de trabalho?
O número é reduzido em detrimento ao escopo da solução, desta forma, o cronograma teve ser
ampliado para adequação a esta peculiaridade.
7.2 TABELA DE RISCOS
Segue abaixo a lista dos riscos identificados no projeto:
Risco Categoria Probabilidade Impacto
Insuficiência de
pessoas na equipe
Pessoal 60% Crítico
Prazo para entrega
curto
Técnico 70% Crítico
Treinamento
Usuários
Características do
Cliente
30% Marginal
Mudanças nos
requisitos
Projeto 10% Crítico
Falta de Motivação Pessoal 60% Marginal
Rotatividade de
pessoal
Pessoal 20% Catastrófico
Conflitos Pessoal 20% Marginal
Tecnologia e
infraestrutura (danos)
Técnico 10% Catastrófico
Capacidade da equipe Pessoal 10% Crítico
Tabela dos riscos encontrados no projeto
7.3 REDUÇÃO E GESTÃO DE RISCOS
Dos itens elencados foram escolhidos dois com impacto critico e um com impacto
catastrófico para descrevermos as suas atividades de redução, supervisão e gestão do risco.

18. 18
Na empresa existe um número pequeno de profissionais de TI, a empresa não possui um
capital inicial, ficando a cargo do pagamento da empresa contratante o pagamento e
consequentemente a contratação de mais pessoal.
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: Como a empresa não possuí um capital inicial, devemos buscar
uma parceria com pessoal interessado no mesmo.
Plano de contingência: Havendo dificuldades na associação de novos parceiros, devemos
a.Estabelecer um adiantamento de 40% da estimativa inicial para execução do projeto, a
fim de capitalizar a empresa para alocação dos recursos necessários;
b. Recorrer financiamento privado para execução do projeto;
c. 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
Algumas mudanças de requisitos podem ocorrer, pois apesar de as instituições parecerem
devido as suas atividades fins, algumas mudanças locais podem acontecer.
Mudanças nos requisitos
Risco:002 Probabilidade: 10% Impacto: Crítico
Descrição: Os requisitos da empresa mudarem devido há alterações na legislação.
Estratégia de redução: sabendo da possível alteração na legislação, faremos um sistema
mais flexível, para adequar-se a possiveis mudanças.
Plano de contingência: o Gestor deve consultar um advogado especialista visando as
possíveis alterações.
Pessoa responsável: Fernando Lucas de Oliveira Farias
Status: Simulação Incompleta
8. ORGANIZAÇÃO DO PESSOAL
A nossa equipe segue uma estrutura descentralizada democrática, pois, apesar de termos um
gestor competente responsável pela organização dos trabalhos, as decisões são tomadas em
conjunto e com o consenso de todos e a comunicação é horizontal. Além disso, esta é a melhor
estrutura para problemas complexos e que requerem muita comunicação, além de ser a que
produz melhores ambientes e satisfação no trabalho.

19. 19
8.1 ESTRUTURA DA EQUIPE
A equipe é formada por dois elementos e logo no inicio dos trabalhos definimos claramente as
funções de cada um, sendo:
Fernando - Gestor de Projeto, Analista de sistemas, Engenheiro de Software e Programador;
Jairo - Engenheiro de Software, Programador de Software e Testador de software;
O gestor 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.
O 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.
O engenheiro de software estuda e seleciona tanto as ferramentas utilizadas como o hardware e
plataformas onde o software será utilizado.
Os programadores recebem o trabalho do analista e programam o código do novo sistema.
O testador no fim testa exaustivamente todo o sistema de forma a detectar erros na
implementação.
8.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 e
Whatsapp, e meios de comunicação telefônica.
8.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO
Achamos o Edu-blog uma excelente ferramenta de apoio à disciplina, pois é fácil e agradável de
utilizar, permite ao professor disponibilizar todo o material referente à disciplina e possibilita a
comunicação entre o docente e todos os alunos, sendo muito útil para cada um apresentar as
suas dúvidas e 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. No
entanto para comunicação entre os membros da equipe, utilizamos o Whatsapp e Chat do
Facebook.
ANEXO A - DIAGRAMAS DE CLASSE DE DOMÍNIO

20. 20