UNIVERSIDADE FEDERAL DE SERGIPECENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICASDEPARTAMENTO DE SISTEMAS DE INFORMAÇÃO

Fernando Lucas de Oliveira FariasJairo Charnoski do Nascimento

PLANO DE PROJETO DE SOFTWARE

CENTRO DE FORMAÇÃO DE CONDUTORES

São Cristóvão, 13 de Abril de 2016

1

SUMÁRIO

1. INTRODUÇÃO1.1.DESCRIÇÃO DO PROJETO

1.1.1.Finalidade1.1.2. Definições, Acrônimos e Abreviações1.1.3. Referências

2. POSICIONAMENTO2.1. Oportunidade de Negócios2.2. Descrição do Problema2.3. Sentença de Posição do Produto3. DESCRIÇÕES DOS ENVOLVIDOS E DOS CLIENTES3.1. Demografia dos Mercados3.2. Resumo dos Envolvidos3.3. Resumo dos Clientes3.4. Ambiente dos Clientes3.5. Perfis dos Envolvidos

3.5.13.5.2

3.6. Principais Necessidades dos Envolvidos ou dos Clientes3.7. Alternativas e Concorrência4. PRINCIPAIS FUNÇÕES DO SISTEMA4.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ÇÕES6. ESTIMATIVAS DO PROJETO6.1 DADOS HISTÓRICOS6.2 TÉCNICAS DE ESTIMATIVAS E RESULTADOS

6.2.1 TÉCNICAS DE ESTIMATIVA6.3 RESULTADOS6.4 RECURSOS DO PROJETO6.5 DIAGRAMA DE GANTT7. ANÁLISE E GESTÃO DE RISCOS7.1 RISCOS DO PROJETO7.2 TABELA DE RISCOS7.3 REDUÇÃO E GESTÃO DE RISCOS8. ORGANIZAÇÃO DO PESSOAL8.1 ESTRUTURA DA EQUIPE

2

8.2 MECANISMOS DE COMUNICAÇÃO8.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO

3

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

4

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

5

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.

6

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.

7

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.

8

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;

9

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;

10

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,...);

11

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;

12

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 MultiplicadorNão gráfica 2Baseada em texto 2,25GUI 2,5GUI 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.

13

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 trabalhoPlanejamento 2 – 3% 3% 287 x 3% 9

Requisito-Analise-Desenho 40% 40% 287 x 40% 115Geração de código 20% 20% 287 x 20% 57

Testes 37-38% 37% 287 x 37% 106Resultado 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 SoftwareJairo· 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.· Mozila Firefox, browser de Internet.· Google Chrome, browser de Internet.

14

. 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

15

7. ANÁLISE E GESTÃO DE RISCOSA análise de riscos é importante para um projeto, pois assim o gestor pode se prevenir para saber administrá-los.

7.1 RISCOS DO PROJETOExiste 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écnico

Negócio Comum Especial

Equipamento não disponivel XRequisitos incompletos X XUso de metodologias especiais X XProblemas na busca da confiabilidade requerida

X X

Retenção de pessoas chave X XSub-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.

16

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 RISCOSSegue abaixo a lista dos riscos identificados no projeto:

Risco Categoria Probabilidade ImpactoInsuficiê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% MarginalRotatividade de pessoal

Pessoal 20% Catastrófico

Conflitos Pessoal 20% MarginalTecnologia e infraestrutura (danos)

Técnico 10% Catastrófico

Capacidade da equipe Pessoal 10% CríticoTabela dos riscos encontrados no projeto

7.3 REDUÇÃO E GESTÃO DE RISCOSDos 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.

17

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 equipeRisco:001 Probabilidade: 60% Impacto: CríticoDescriçã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 FariasStatus: 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 requisitosRisco:002 Probabilidade: 10% Impacto: CríticoDescriçã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 FariasStatus: 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.

18

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

19

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