Plano de Projeto de Software

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
DISCIPLINA: Gerência de Projetos
PERÍODO: 2015.2
PLANO DE PROJETO DE SOFTWARE
para produtos da Lacertae SW
Matheus Mendonça Menezes
Ytallo Augusto Lima
Vanderson Sampaio
São Cristóvão – Sergipe
2016

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
DISCIPLINA: Gerência de Projetos
PERÍODO: 2015.2
PLANO DE PROJETO DE SOFTWARE
para produtos da Lacertae SW
Matheus Mendonça Menezes
Ytallo Augusto Lima
Vanderson Sampaio
São Cristóvão – Sergipe
2016
Trabalho apresentado ao Prof. Dr. Rogério
Patrício Chagas do Nascimento como nota
para disciplina Gerência de Projetos do curso
de graduação em Sistemas de Informação –
Bacharelado da Universidade Federal de
Sergipe (UFS).

Índice
1. INTRODUÇÃO................................................................................................................................4
1.1 Âmbito do Projeto......................................................................................................................4
1.2 Funções principais do produto de software............................................................................... 4
1.3 Requisitos comportamentais ou de performance.......................................................................5
1.4 Gestão e Restrições Técnicas.....................................................................................................6
2. ESTIMAÇÕES DO PROJETO........................................................................................................ 6
2.1 Dados históricos utilizados para as estimações......................................................................... 6
2.2 Técnicas de estimação e resultados............................................................................................6
2.2.1 Técnica de estimação......................................................................................................... 6
2.3 Resultados..................................................................................................................................7
2.4 Recursos do Projeto................................................................................................................... 8
2.4.1 Recursos Humanos.............................................................................................................8
2.4.2 Hardware Necessário......................................................................................................... 9
2.4.3 Software de Suporte...........................................................................................................9
3. ANÁLISE E GESTÃO DE RISCOS................................................................................................9
3.1 Riscos do Projeto....................................................................................................................... 9
3.2 Tabela de Riscos.......................................................................................................................11
3.3 Redução e Gestão de Riscos.................................................................................................... 13
4. PLANEJAMENTO TEMPORAL.................................................................................................. 17
4.1 Conjunto de Tarefas Macro do Projeto.................................................................................... 17
4.2 Diagrama de Gantt...................................................................................................................18
5. ORGANIZAÇÃO DO PESSOAL..................................................................................................22
5.1 Estrutura da Equipe..................................................................................................................22
5.2 Mecanismos de Comunicação................................................................................................. 22
5.3 Uso do Edu-blog como ferramenta de apoio........................................................................... 23
6. PRECAUÇÕES TOMADAS PARAASSEGURAR E CONTROLAR A QUALIDADE DO
PRODUTO DE SOFTWARE.............................................................................................................23
7. Referências..................................................................................................................................... 24
Índice de figuras
Figura 1: Diagrama Caso de Uso do Sistema de Controle de Frequência............................................5
Figura 2: Multiplicadores para interfaces.............................................................................................7
Figura 3: Diagrama de Classes de Domínio do Sistema de Controle de Frequência...........................8
Figura 4: Lista de Tarefas - Sistema de Controle de Frequência........................................................18
Figura 5: Diagrama de Gantt - Sistema de Controle de Frequência...................................................21
Índice de tabelas
Tabela 1: Enquadramento dos Riscos do Projeto Sistema de Controle de Frequência......................11
Tabela 2: Impactos e Probabilidades dos Riscos do Sistema de Controle de Frequência..................13
Tabela 3: Integrantes da equipe e atribuições.....................................................................................22

Índice de Quadros
Quadro 1: Proibição de Utilização.....................................................................................................13
Quadro 2: Negação de Recursos para Integração...............................................................................13
Quadro 3: Atualizações do Sistema....................................................................................................14
Quadro 4: Risco de Política da Universidade.....................................................................................14
Quadro 5: Atividades Paralelas ao Projeto.........................................................................................14
Quadro 6: Congestionamento de Servidores......................................................................................15
Quadro 7: Atendimento à Exigência Tecnológica..............................................................................15
Quadro 8: Exclusão de Usuários........................................................................................................15
Quadro 9: Falta de Ferramentas de Testes.........................................................................................16
Quadro 10: Abandono de Disciplina..................................................................................................16
Quadro 11: Falta de conhecimento acerca das ferramentas a serem utilizadas.................................17

1. INTRODUÇÃO
O Sistema de Controle de Frequência para dispositivos móveis destina-se aos
professores da Universidade Federal de Sergipe. Trata-se de uma alternativa ao
cumprimento dos deveres laborais desses professores, no que diz respeito à atualização
da frequência dos seus alunos, junto ao Sistema Integrado de Gestão Acadêmica (SIGAA,
como será chamado daqui em diante).
Este documento especifica os requisitos funcionais do Sistema de Controle de
Frequência. Tais requisitos foram levantados após entrevista com o cliente. Foram
também consequência da observação e análise da situação atual do ambiente do cliente.
Os requisitos levantados dão base para o desenvolvimento do Sistema de Controle de
Frequência para dispositivos móveis. O Sistema será criado para a plataforma Android, de
modo a atender a uma maior parcela de usuários em sua primeira versão.
1.1 Âmbito do Projeto
O Software permite que o usuário, qualquer professor da Universidade Federal de
Sergipe, cadastre as presenças e ausências dos seus alunos em suas turmas em
qualquer dispositivo Android. Dessa maneira os professores não ficariam mais reféns da
interface WEB provida pelo SIGAA. Isso se torna bastante útil principalmente quando da
necessidade de aulas em campo. Nessas aulas não há computadores com acesso à
internet disponíveis para que o professor cadastre as presenças e ausências no momento
da aula.
Além disso é possível também criar anotações referentes a cada aula, que o
professor julgue necessárias para a melhoria do seu trabalho.
1.2 Funções principais do produto de software
A Figura 1 mostra um diagrama de caso de uso que ilustra os atores que atuam no
Sistema de controle de frequência, como também os requisitos funcionais do Sistema.
4

Figura 1: Diagrama Caso de Uso do Sistema de Controle de Frequência
Na figura acima podem ser observados os atores representados como Professor e
SIGAA. Os atores são aqueles que executam funções no Sistema. Há também o registro
dos requisitos funcionais do Sistema, são eles: Selecionar Aula, Efetuar Chamada, Manter
Parâmetros, Informar Anotações, Cadastrar Usuário, Sincronizar Disciplina, Atualizar
Presença e Efetuar Login.
Vale ressaltar que vários desses requisitos dependem do Efetuar Login. Devido a
citada dependência, tais requisitos aparecem na Figura 1 ligados por uma linha pontilhada
ao requisito Efetuar Login. O parâmetro <<include>> é usado para ressaltar a
dependência.
1.3 Requisitos comportamentais ou de performance
O Sistema apresentado deve ser compatível com o maior número possível de
dispositivos Android ativos e presentes no mercado. Para tal o mesmo foi desenvolvido
tendo como requisito mínimo a versão 4.1 do Android, Jelly Bean. Dessa forma e de
acordo com dados providos pela IDE de desenvolvimento oficial do Android, Android
Studio, o sistema em questão atende a mais de 86% dos dispositivos Android ativos e
presentes atualmente no mercado.
5

O acesso ao Sistema se dará via cadastro de usuário no próprio Sistema. A
segurança será provida através de senha para acesso às funcionalidades do Sistema. Os
requisitos de hardware para uso do Sistema são:
- Smartphone compatível com sistema Android a partir da versão 4.1.x (Jelly Bean); -
Sistema Android 4.1.x ou superior instalado;
1.4 Gestão e Restrições Técnicas
Algumas restrições técnicas estão listadas abaixo:
 O Sistema de Controle de Frequência será́ desenvolvido com a linguagem de
programação Java, com a IDE de desenvolvimento Android Studio;
 O sistema de banco de dados a utilizado será o SQLite;
 O sistema requer gosto por parte do usuário para com o uso de sistemas móveis;
 O Sistema será uma aplicação mobile para dispositivos Android.
2. ESTIMAÇÕES DO PROJETO
2.1 Dados históricos utilizados para as estimações
Tendo em vista que este projeto é o primeiro a ser realizado pelos integrantes da
equipe, não será possível utilizar dados históricos para as estimações do mesmo.
2.2 Técnicas de estimação e resultados
2.2.1 Técnica de estimação
A técnica utilizada para a estimação e resultados foi a técnica de Lorenz & Kidd.
Trata-se de uma técnica orientada a classes que dá como resultado uma estimativa do
esforço necessário para desenvolver o software. O que se faz nessa técnica basicamente
é decompor os esforços usando como parâmetros o número de classes-chave do
Sistema. Essas classes são responsáveis pela estimativa de esforço final. Há também as
classes de suporte, que são classes que não fazem parte do domínio do problema,
geralmente representam janelas, botões, caixas de diálogo, etc.
Um quesito importante desta técnica é a classificação da interface do produto, que
resultará no multiplicador para as classes de suporte, de acordo com a Figura 2 abaixo.
6

Em seguida, são retratados os resultados obtidos ao aplicar-se a técnica
supracitada no projeto do Sistema de Controle de Frequência.
2.3 Resultados
Com base na técnica de Lorenz & Kidd e tendo sido utilizado o diagrama de
classes de domínio, exibido na Figura 3.
7
Figura 2: Multiplicadores para interfaces

Figura 3: Diagrama de Classes de Domínio do Sistema de Controle de Frequência
Foram obtidas as seguintes informações:
❏ Classes chaves: 8 classes: Aluno, Aula, EfetuarChamada, Frequência,
AtualizarFrequência, Anotacao, Usuario, Sincronizador;
❏ Tipo de interface: GUI Complexa;
❏ Classes de suporte: 8 (classes de domínio) X 3 (fator multiplicador) = 24 classes;
❏ Total de classes: 8 (classes chaves) + 24 (classes de suporte) = 32 classes;
❏ Como unidade média de trabalho por classe, utilizaremos 15 dias por pessoa,
totalizando 480 dias por pessoa.
❏ A equipe possui três membros, estimando um prazo de 160 dias para conclusão do
projeto. Nesses dias estão inclusos os sábados e domingos.
2.4 Recursos do Projeto
2.4.1 Recursos Humanos
A equipe é composta por um gestor de projetos, um arquiteto de software e um
analista de sistemas, tendo todos a atribuição de codificar e testar o sistema.
8

2.4.2 Hardware Necessário
❏ Smartphone compatível com sistema Android a partir da versão 4.1.x (Jelly Bean);
❏ Sistema Android 4.1.x ou superior instalado;
❏ 512KB de espaço livre em disco;
❏ Dispositivo capaz de acesso à internet.
2.4.3 Software de Suporte
O sistema será desenvolvido na plataforma padrão de desenvolvimento do Google
para o sistema Android, Android Studio, serão usadas a linguagem Java (padrão para o
ambiente de desenvolvimento em questão) e o banco de dados SQLite. Maiores
informações acerca desse banco de dados podem ser obtidas no seguinte endereço
eletrônico: http://www.sqlite.org/.
3. ANÁLISE E GESTÃO DE RISCOS
3.1 Riscos do Projeto
A Tabela 1 descreve os riscos identificados no projeto do Sistema de Controle de
Frequência.
9

Especial Comum Negócio Técnico Projeto Risco
x x
A Universidade pode não
dar a autorização para
que o software possa se
utilizado.
x
Não disponibilização de
recursos para integração.
x x
P o d e m h a v e r
atualizações do sistema
operacional Android que
tornem o aplicativo ou
i n c o m p a t í v e l o u
i n a d e q u a d o à n o v a
versão.
x
Politica da Universidade
p o d e i n v i a b i l i z a r a
utilização do software.
x
Trabalhos paralelos,
profissionais ou da
Universidade.
x
Número de acessos ao
Sistema poderá causar
congestionamento.
x x
Como os clientes são
p e s s o a s , t o d o s
diferentes, alguns são
tecnologicamente mais
exigentes que outros.
x
O S i s t e m a f o i
desenvolvido apenas
p a r a a p l a t a f o r m a
Android, i s s o p o d e
prejudicar usuários de
outras plataformas.
x
Não foram estabelecidas
ferramentas automáticas
de teste.
x
Algum aluno abandonar a
disciplina.
x Falta de conhecimento
aprofundado por parte
10

dos desenvolvedores
acerca das ferramentas a
serem utilizadas.
Tabela 1: Enquadramento dos Riscos do Projeto Sistema de Controle de Frequência
3.2 Tabela de Riscos
A Tabela 2 apresenta os riscos, o impacto que eles ocasionam e a probabilidade de
que ocorram.
11

Impacto % Probabilidade Risco
Catastrófico 80 A Universidade pode não
dar a autorização para
que o software possa se
utilizado.
Catastrófico 70 Não disponibilização de
recursos para integração.
Catastrófico 20 P o d e m h a v e r
atualizações do sistema
operacional Android que
tornem o aplicativo ou
i n c o m p a t í v e l o u
i n a d e q u a d o à n o v a
versão.
Catastrófico 20 Politica da Universidade
p o d e i n v i a b i l i z a r a
utilização do software.
Crítico 60 Trabalhos paralelos,
p r o f i s s i o n a i s o u d a
Universidade.
Crítico 30 Número de acessos ao
sistema poderá causar
congestionamento.
Moderado 50 Como os clientes são
pessoas, todos diferentes,
a l g u n s s ã o
tecnologicamente mais
exigentes que outros.
Moderado 50 O s i s t e m a f o i
desenvolvido apenas para
a plataforma Android, isso
pode prejudicar usuários
de outras plataformas.
Moderado 30 Não foram estabelecidas
ferramentas automáticas
de teste.
Marginal 50 Algum aluno abandonar a
disciplina.
Marginal 20 Falta de conhecimento
aprofundado por parte
dos desenvolvedores
12

acerca das ferramentas a
serem utilizadas.
Tabela 2: Impactos e Probabilidades dos Riscos do Sistema de Controle de Frequência
3.3 Redução e Gestão de Riscos
Com base nos riscos já elencados, as seguintes estratégias de contingência foram
elaboradas:
RISCO: 01 - Proibição de
Utilização
Probabilidade: 80% Impacto: 5
Descrição: A Universidade pode não dar a autorização para que o software possa
ser utilizado.
Estratégia de redução: Apresentar as funcionalidades do software aos gestores
da Universidade Federal de Sergipe. Convidar professores interessados a
conversarem com a Universidade.
Plano de contingência: Apresentar o Sistema para outras Universidades que
utilizem sistema de controle de frequência eletrônico.
Pessoa responsável: Vanderson Sampaio.
Status: Aguardando reunião com responsáveis pelo SIGAA na UFS.
Quadro 1 – Risco: Proibição de Utilização
RISCO: 02 – Negação de
Recursos para Integração
Descrição: O setor responsável da Universidade pode não disponibilizar recursos
para integração entre o sistema legado e o Sistema de Controle de Frequência.
Estratégia de redução: Guardar os dados em base de dados local, para que não
sejam perdidos enquanto se aguarda a liberação dos recursos necessários.
Plano de contingência: Prover funcionalidades de exportação dos dados para
tabelas, permitir salvar dados na nuvem, de modo que o usuário possa acessar
tais dados em outros dispositivos ou até mesmo desktops.
Quadro 2 - Negação de Recursos para Integração
13

RISCO: 03 – Atualizações
de Sistema
Descrição: Podem haver atualizações do sistema operacional Android que tornem
o aplicativo incompatível ou inadequado à nova versão.
Estratégia de redução: Acompanhar atualizações regulares do sistema
operacional Android e verificar a necessidade de ajustes para adaptação.
Plano de contingência: Lançar atualização de aplicativo com as mudanças
requeridas pela nova versão do sistema operacional Android.
Pessoa responsável: Matheus Mendonça.
Status: Aguardando atualizações de sistema.
Quadro 3 – Atualizações de Sistema
RISCO: 04 – Risco de
Política da Universidade
Descrição: Política da universidade pode inviabilizar a utilização do software.
Estratégia de redução: Mostrar que o software é seguro e não oferecerá brechas
de segurança para com a base de dados da Universidade, além de tornar mais
prático o trabalho dos professores. Convidar professores interessados a
conversarem com a Universidade.
Plano de contingência: Apresentar o Sistema para outras Universidades que
utilizem sistema de controle de frequência eletrônico.
Quadro 4 - Risco de Política da Universidade
RISCO: 05 – Atividades
paralelas ao Projeto
Descrição: Trabalhos paralelos, profissionais ou da Universidade.
Estratégia de redução: Dividir as tarefas adequadamente entre os integrantes.
Plano de contingência: Um integrante pode vir a ser responsável por tarefa(s) de
outro(s), em eventuais necessidades identificadas pelo gestor, para cumprir os
prazos do Projeto.
Status: Aguardando início dos trabalhos.
Quadro 5 - Atividades paralelas ao Projeto
14

RISCO: 06 –
Congestionamento de
Servidores
Descrição: Número de acessos simultâneos ao sistema poderá causar
congestionamento.
Estratégia de redução: Solicitar ao administrador de redes uma configuração
para que os acessos sejam feitos paralelamente entre os servidores.
Plano de contingência: Instalação de novos servidores.
Pessoa responsável: Ytallo Lima.
Status: Configurando os servidores para o acesso ao sistema.
Quadro 6 – Congestionamento de Servidores
RISCO: 07 – Atendimento
à Exigência Tecnológica
Descrição: O Sistema é destinado aos mais diversos usuários, alguns
tecnologicamente mais exigentes que outros.
Estratégia de redução: Tornar a interface amigável e autodidata ao usuário.
Plano de contingência: Observar as avaliações, reclamações e sugestões dos
usuários na Google Play. Aplicar alterações buscando atender a maior parte dos
usuários.
Status: Modelos de interface em análise.
Quadro 7 - Atendimento à Exigência Tecnológica
RISCO: 08 – Exclusão de
Usuários
Descrição: O sistema foi desenvolvido apenas para a plataforma Android, isso
pode fazer com que usuários de outras plataformas sintam-se excluídos.
Estratégia de redução: Realizar uma pesquisa a fim de identificar quais SO são
mais utilizados pelos clientes.
Plano de contingência: Solicitar aos desenvolvedores a criação de um sistema
com maior portabilidade.
Status: Pesquisa com os clientes a ser agendada.
Quadro 8 - Exclusão de Usuários
15

RISCO: 09 – Falta de
Ferramentas de Teste
Descrição: Não foram estabelecidas ferramentas automáticas de teste.
Estratégia de redução: Solicitar a aquisição de novas ferramentas automáticas
de Teste. Solicitar aos testadores que incluam essas ferramentas no processo de
teste.
Plano de contingência: Executar testes dentre uma amostra de usuários e anotar
o feedback provido por eles.
Pessoa responsável: Ytallo Lima.
Status: Seleção de novas ferramentas automáticas de teste.
Quadro 9 - Falta de Ferramentas de Teste
RISCO: 10 – Abandono
de Disciplina
Descrição: Algum aluno pode abandonar a disciplina Gerência de Projetos.
Estratégia de redução: Tentar convencer o possível desistente, mostrar como
pode ser prejudicial uma desistência ao seu histórico.
Plano de contingência: Realocar as atividades do Projeto dentre os membros
restantes da equipe.
Pessoa responsável: Ytallo Lima
Status: Seleção de pessoas para pesquisar os motivos de evasão.
Quadro 10 – Abandono de Disciplina
16

RISCO: 11 – Falta de
conhecimento acerca das
ferramentas a serem
utilizas
Descrição: Falta de conhecimento aprofundado por parte dos desenvolvedores
acerca das ferramentas a serem utilizadas no desenvolvimento do Sistema de
Controle de Frequência.
Estratégia de redução: Solicitar que os desenvolvedores dediquem algum tempo
para um maior conhecimento da ferramenta através de tutoriais online.
Plano de contingência: Contratar empresa especializada para realização de um
treinamento.
Pessoa responsável: Ytallo Lima
Status: Integrantes estudando ferramentas através de tutoriais.
Quadro 11 - Falta de conhecimento acerca das ferramentas a serem utilizas
4. PLANEJAMENTO TEMPORAL
4.1 Conjunto de Tarefas Macro do Projeto
Dias de Trabalho Porcentagem Tarefas Macro
7 4% Planejamento
61 38% Análise de Requisitos e
Modelagem
30 19% Codificação
62 39% Testes
Tabela 3: Relação das tarefas macro e dias de trabalho
Total de 160 dias para a execução do projeto.
17

4.2 Diagrama de Gantt
Na Figura 4, são apresentadas todas as tarefas e sub-tarefas que serão realizadas
durante o desenvolvimento o produto de software. A fase de planejamento é composta
pelo levantamento de requisitos e validação de requisitos.
Levantamento de requisitos corresponde à etapa de compreensão do problema
aplicada ao desenvolvimento de software (BEZERRA, 2006). A fase de levantamento de
18
Figura 4: Lista de Tarefas - Sistema de Controle de Frequência

requisitos foi dividida em: Entrevista com clientes, acompanhamento da rotina dos
usuários e reunião com os responsáveis técnicos.
Na entrevista com o cliente, procura-se extrair o que o cliente quer e como são
desenvolvidas suas atividades, mas o mais importante é definir o que ele realmente
precisa. Na fase de acompanhamento da rotina dos usuários, como o próprio nome já diz,
é observar as atividades do usuário para que haja uma maior certeza sobre o que será
desenvolvido.
Na reunião com os responsáveis técnicos, serão apresentadas todas as
informações extraídas nas fases anteriores (entrevista com o cliente e acompanhamento
da rotina do usuário) com o objetivo de validá-las. A validação de requisitos é o processo
pelo qual se verifica se os requisitos definem o sistema que o cliente realmente quer
(SOMMERVILLE, 2011).
A fase de análise e projeto foi subdividida em seis fases:
● Criação de casos de uso;
● Criação de diagramas de classe de domínio;
● Definição da arquitetura do projeto;
● Criação do diagrama de classes de projeto;
● Criação do diagrama de sequência;
● Prototipação.
Segundo Bezerra (2006), é a especificação de uma sequência de interações que
ocorrem entre o sistema e os agentes externos que utilizam o sistema. Com a criação dos
casos de uso, será mais fácil a visualização das interações que deverão ocorrer.
O diagrama de classes é usado no desenvolvimento de um modelo de sistema
orientado a objetos para mostrar as classes de um sistema e as associações entre essas
classes (SOMMERVILLE, 2011). O diagrama de sequência é utilizado para indicar a
comunicações dinâmicas entre os objetos durante a execução de uma tarefa
(PRESSMAN,2011).
Na fase de prototipação serão construídos esboços de algumas partes do sistema,
com o intuito de permitir a visualização do cliente de como ficará a parte específica que
está sendo mostrada, dando uma maior segurança aos desenvolvedores, já que com o
aval do cliente, não haverá necessidade de retrabalho.
A fase de codificação será utilizada para o desenvolvimento das funcionalidades do
sistema. Ela está dividida em:
● Cadastrar Usuário;
● Efetuar Login;
● Manter parâmetros;
● Selecionar Disciplinas;
● Selecionar Aula;
● Informar anotações;
● Efetuar Chamada;
19

● Atualizar presença.
Por último mas não menos importante, é apresentada a fase de testes. Essa fase
também é dividida em vários tipos de testes, para que possam dá uma maior segurança
ao software desenvolvido. A fase de teste foi dividida em:
● Teste unitário: tipo de teste que é realizado em nível de componente ou classe;
● Teste de integração: teste realizado entre um ou mais componentes para verificar
se eles combinados funcionam de forma correta;
● Teste de performance: teste onde é verificado se o tempo de resposta é o desejado
para o momento de utilização da aplicação.
● Teste de carga: responsável por verificar o funcionamento da aplicação com a
utilização de uma quantidade grande de usuário simultâneos;
● Teste de aceitação dos usuários: nesse teste é verificado se a solução será bem
vista pelo usuário;
● Teste de configuração: testa se a aplicação funciona corretamente em diferentes
ambientes de hardware ou de software;
● Teste de segurança: como o próprio nome diz, testa a segurança da aplicação em
suas diversas formas. São testados os perfis, permissões, papéis utilizados para
navegar no sistema.
A Figura 5 abaixo traz o Diagrama de Gantt para o Sistema de Controle de
Frequência. Todas as tarefas listadas na Figura 4 estão presentes no diagrama em
questão. Ao lado esquerdo de cada tarefa está o nome da mesma. Ao lado direito de cada
tarefa está a duração, em dias, da mesma.
20

21
Figura 5: Diagrama de Gantt - Sistema de Controle de Frequência

5. ORGANIZAÇÃO DO PESSOAL
Aqui será explanado a repeito de como serão distribuídos os recursos humanos
disponíveis para a elaboração do projeto.
5.1 Estrutura da Equipe
A equipe é composta por: Matheus Mendonça, Ytallo Lima e Vanderson Sampaio, a
tabela abaixo destrincha as funções a serem exercidas por cada um.
Integrante Função Sumário de atividades
Vanderson Sampaio Gestor do projeto Definir papéis e funções dos
demais integrantes do projeto.
Acompanhar e gerir o trabalho de
todos os envolvidos no projeto.
Ytallo Lima Analista de sistema Definir os requisitos do sistema
Matheus Mendonça Arquiteto de software Desenvolver a arquitetura do
sistema, inclusive os diagramas
de projeto.
Vanderson Sampaio
Ytallo Lima
Matheus Mendonça
Programadores Desenvolver o código do
sistema.
Vanderson Sampaio
Ytallo Lima
Matheus Mendonça
Testadores Testar os casos de uso do
software
Tabela 3: Integrantes da equipe e atribuições
5.2 Mecanismos de Comunicação
Os mecanismos de comunicação utilizados pela equipe foram: e-mail, WhatsApp e
Gtalk. Tais meios foram utilizados para troca de mensagens e informações inerentes ao
projeto em questão.
A plataforma Google Docs foi utilizada como ferramente colaborativa para a
execução deste documento, de modo a minimizar a necessidade de encontros in loco
para execução do mesmo.
22

5.3 Uso do Edu-blog como ferramenta de apoio
O Edu-blog serviu principalmente para:
• Disseminação do conhecimento;
• Troca de informações entre equipes diferentes;
• Aprendizado de ferramentas que ajudaram no desenvolvimento do trabalho da
equipe;
• Compartilhamento de novidades e curiosidades que mostraram-se bastante úteis à
execução do projeto em questão.
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E
CONTROLAR A QUALIDADE DO PRODUTO DE
SOFTWARE
A primeira preocupação foi diretamente com o cliente. O mesmo foi envolvido em
conversas com os integrantes da equipe acerca das necessidades e obrigações dos
professores para com a Universidade Federal de Sergipe.
Foram levadas em consideração também os testes a serem aplicados no
desenvolvimento: unitário, interação, performance, carga, aceitação do usuário,
configuração, segurança.
As reuniões entre os membros da equipe responsável pelo Projeto foram
constantes. Tais reuniões foram também bastante úteis quanto ao esclarecimento de
dúvidas sobre o Projeto. A documentação e diagramas do sistema foram alteradas no
decorrer das reuniões, buscou-se entretanto manter os integrantes sempre a par de tais
mudanças em tempo hábil de evitar maiores dúvidas.
23

7. Referências
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas Com Uml. 2. ed. São
Paulo: Campus, 2006
PRESSMAN, Roger. Engenharia de Software: Uma abordagem profissional. 7. ed.
São Paulo: Bookman, 2011.
24

Plano de Projeto de Software

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (19)

Semelhante a Plano de Projeto de Software

Semelhante a Plano de Projeto de Software (20)

Último

Último (20)

Plano de Projeto de Software