View
185
Download
1
Category
Preview:
Citation preview
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
Recommended