plano de projeto de software

UNIVERSIDADE FEDERAL DE SERGIPECENTRO DE CIÊNCIAS EXATAS E TECNOLOGIADEPARTAMENTO DE COMPUTAÇÃODISCIPLINA: Gerência de ProjetosPERÍODO: 2015.2

PLANO DE PROJETO DE SOFTWAREpara produtos da Lacertae SW

Matheus Mendonça MenezesYtallo Augusto LimaVanderson Sampaio

São Cristóvão – Sergipe2016

UNIVERSIDADE FEDERAL DE SERGIPECENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAÇÃODISCIPLINA: Gerência de Projetos

PERÍODO: 2015.2

PLANO DE PROJETO DE SOFTWAREpara produtos da Lacertae SW

Matheus Mendonça MenezesYtallo Augusto LimaVanderson Sampaio

São Cristóvão – Sergipe2016

Trabalho apresentado ao Prof. Dr. RogerioPatricio Chagas do Nascimento como notapara disciplina Gerencia de Projetos do cursode graduacao em Sistemas de Informacao –Bacharelado da Universidade Federal deSergipe (UFS).

Índice1. INTRODUCAO................................................................................................................................4

1.1 Ambito do Projeto......................................................................................................................41.2 Funcoes principais do produto de software............................................................................... 41.3 Requisitos comportamentais ou de performance....................................................................... 51.4 Gestao e Restricoes Tecnicas.....................................................................................................6

2. ESTIMACÕES DO PROJETO........................................................................................................ 62.1 Dados historicos utilizados para as estimacoes......................................................................... 62.2 Tecnicas de estimacao e resultados............................................................................................6

2.2.1 Tecnica de estimacao......................................................................................................... 62.3 Resultados..................................................................................................................................72.4 Recursos do Projeto................................................................................................................... 8

2.4.1 Recursos Humanos.............................................................................................................82.4.2 Hardware Necessário......................................................................................................... 92.4.3 Software de Suporte........................................................................................................... 9

3. ANÁLISE E GESTAO DE RISCOS................................................................................................93.1 Riscos do Projeto....................................................................................................................... 93.2 Tabela de Riscos.......................................................................................................................113.3 Reducao e Gestao de Riscos.................................................................................................... 13

4. PLANEJAMENTO TEMPORAL.................................................................................................. 174.1 Conjunto de Tarefas Macro do Projeto.................................................................................... 174.2 Diagrama de Gantt................................................................................................................... 18

5. ORGANIZACAO DO PESSOAL..................................................................................................225.1 Estrutura da Equipe..................................................................................................................225.2 Mecanismos de Comunicacao................................................................................................. 225.3 Uso do Edu-blog como ferramenta de apoio........................................................................... 23

6. PRECAUCÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE.............................................................................................................237. Referências..................................................................................................................................... 24

Índice de figurasFigura 1: Diagrama Caso de Uso do Sistema de Controle de Frequência............................................5Figura 2: Multiplicadores para interfaces.............................................................................................7Figura 3: Diagrama de Classes de Domínio do Sistema de Controle de Frequência...........................8Figura 4: Lista de Tarefas - Sistema de Controle de Frequência........................................................18Figura 5: Diagrama de Gantt - Sistema de Controle de Frequência...................................................21

Índice de tabelasTabela 1: Enquadramento dos Riscos do Projeto Sistema de Controle de Frequência......................11Tabela 2: Impactos e Probabilidades dos Riscos do Sistema de Controle de Frequência..................13Tabela 3: Integrantes da equipe e atribuicoes.....................................................................................22

Índice de QuadrosQuadro 1: Proibicao de Utilizacao.....................................................................................................13Quadro 2: Negacao de Recursos para Integracao...............................................................................13Quadro 3: Atualizacoes do Sistema....................................................................................................14Quadro 4: Risco de Política da Universidade.....................................................................................14Quadro 5: Atividades Paralelas ao Projeto.........................................................................................14Quadro 6: Congestionamento de Servidores......................................................................................15Quadro 7: Atendimento à Exigência Tecnologica..............................................................................15Quadro 8: Exclusao de Usuários........................................................................................................15Quadro 9: Falta de Ferramentas de Testes.........................................................................................16Quadro 10: Abandono de Disciplina..................................................................................................16Quadro 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 aosprofessores da Universidade Federal de Sergipe. Trata-se de uma alternativa aocumprimento dos deveres laborais desses professores, no que diz respeito a atualizacaoda frequência dos seus alunos, junto ao Sistema Integrado de Gestao 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. Foramtambém consequência da observacao e analise da situacao atual do ambiente do cliente.Os requisitos levantados dao base para o desenvolvimento do Sistema de Controle deFrequência para dispositivos móveis. O Sistema sera criado para a plataforma Android, demodo a atender a uma maior parcela de usuarios em sua primeira versao.

1.1 Ambito do Projeto

O Software permite que o usuario, qualquer professor da Universidade Federal deSergipe, cadastre as presencas e ausências dos seus alunos em suas turmas emqualquer dispositivo Android. Dessa maneira os professores nao ficariam mais reféns dainterface WEB provida pelo SIGAA. Isso se torna bastante útil principalmente quando danecessidade de aulas em campo. Nessas aulas nao ha computadores com acesso ainternet disponíveis para que o professor cadastre as presencas e ausências no momentoda aula.

Além disso é possível também criar anotacões referentes a cada aula, que oprofessor julgue necessarias para a melhoria do seu trabalho.

1.2 Funçoes principais do produto de software

A Figura 1 mostra um diagrama de caso de uso que ilustra os atores que atuam noSistema 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 eSIGAA. Os atores sao aqueles que executam funcões no Sistema. Ha também o registrodos requisitos funcionais do Sistema, sao eles: Selecionar Aula, Efetuar Chamada, ManterParâmetros, Informar Anotacões, Cadastrar Usuario, Sincronizar Disciplina, AtualizarPresenca e Efetuar Login.

Vale ressaltar que varios desses requisitos dependem do Efetuar Login. Devido acitada dependência, tais requisitos aparecem na Figura 1 ligados por uma linha pontilhadaao requisito Efetuar Login. O parâmetro <<include>> é usado para ressaltar adependência.

1.3 Requisitos comportamentais ou de performance

O Sistema apresentado deve ser compatível com o maior número possível dedispositivos Android ativos e presentes no mercado. Para tal o mesmo foi desenvolvidotendo como requisito mínimo a versao 4.1 do Android, Jelly Bean. Dessa forma e deacordo com dados providos pela IDE de desenvolvimento oficial do Android, AndroidStudio, o sistema em questao atende a mais de 86% dos dispositivos Android ativos epresentes atualmente no mercado.

5

O acesso ao Sistema se dara via cadastro de usuario no próprio Sistema. Aseguranca sera provida através de senha para acesso as funcionalidades do Sistema. Osrequisitos de hardware para uso do Sistema sao:

- Smartphone compatível com sistema Android a partir da versao 4.1.x (Jelly Bean); -Sistema Android 4.1.x ou superior instalado;

1.4 Gestão e Restriçoes Tecnicas

Algumas restricões técnicas estao listadas abaixo:

O Sistema de Controle de Frequência sera desenvolvido com a linguagem deprogramacao 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 usuario para com o uso de sistemas móveis; O Sistema sera uma aplicacao mobile para dispositivos Android.

2. ESTIMAÇÕES DO PROJETO

2.1 Dados históricos utilizados para as estimaçoes

Tendo em vista que este projeto é o primeiro a ser realizado pelos integrantes daequipe, nao sera possível utilizar dados históricos para as estimacões do mesmo.

2.2 Tecnicas de estimação e resultados

2.2.1 Tecnica de estimação

A técnica utilizada para a estimacao e resultados foi a técnica de Lorenz & Kidd.Trata-se de uma técnica orientada a classes que da como resultado uma estimativa doesforco necessario para desenvolver o software. O que se faz nessa técnica basicamenteé decompor os esforcos usando como parâmetros o número de classes-chave doSistema. Essas classes sao responsaveis pela estimativa de esforco final. Ha também asclasses de suporte, que sao classes que nao fazem parte do domínio do problema,geralmente representam janelas, botões, caixas de dialogo, etc.

Um quesito importante desta técnica é a classificacao da interface do produto, queresultara no multiplicador para as classes de suporte, de acordo com a Figura 2 abaixo.

6

Em seguida, sao retratados os resultados obtidos ao aplicar-se a técnicasupracitada 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 declasses 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 conclusao do

projeto. Nesses dias estao inclusos os sabados 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 umanalista de sistemas, tendo todos a atribuicao de codificar e testar o sistema.

8

2.4.2 Hardware Necessário

❏ Smartphone compatível com sistema Android a partir da versao 4.1.x (Jelly Bean);❏ Sistema Android 4.1.x ou superior instalado;❏ 512KB de espaco livre em disco;❏ Dispositivo capaz de acesso a internet.

2.4.3 Software de Suporte

O sistema sera desenvolvido na plataforma padrao de desenvolvimento do Googlepara o sistema Android, Android Studio, serao usadas a linguagem Java (padrao para oambiente de desenvolvimento em questao) e o banco de dados SQLite. Maioresinformacões acerca desse banco de dados podem ser obtidas no seguinte enderecoeletrônico: http://www.sqlite.org/.

3. ANÁLISE E GESTÃO DE RISCOS

3.1 Riscos do ProjetoA Tabela 1 descreve os riscos identificados no projeto do Sistema de Controle de

Frequência.

9

http://www.sqlite.org/

Especial Comum Negócio Tecnico Projeto Risco

x x

A Universidade pode naodar a autorizacao paraque o software possa seutilizado.

xNao disponibilizacao derecursos para integracao.

x x

P o d e m h a v e ratualizacões do sistemaoperacional Android quetornem o aplicativo oui n c o m p a t í v e l o ui n a d e q u a d o a n o v aversao.

xPolitica da Universidadep o d e i n v i a b i l i z a r autilizacao do software.

xTrabalhos para le los ,p r o f i s s i o n a i s o u d aUniversidade.

xNúmero de acessos aoSistema podera causarcongestionamento.

x x

Como os clientes saop e s s o a s , t o d o sdiferentes, alguns saotecnologicamente maisexigentes que outros.

x

O S i s t e m a f o idesenvolvido apenasp a r a a p l a t a f o r m aAndroid, i s s o p o d eprejudicar usuarios deoutras plataformas.

xNao foram estabelecidasferramentas automaticasde teste.

xAlgum aluno abandonar adisciplina.

x Falta de conhecimentoaprofundado por parte

10

dos desenvolvedoresacerca das ferramentas aserem 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 deque ocorram.

11

Impacto % Probabilidade Risco

Catastrófico 80 A Universidade pode naodar a autorizacao paraque o software possa seutilizado.

Catastrófico 70 Nao disponibilizacao derecursos para integracao.

Catastrófico 20 P o d e m h a v e ratualizacões do sistemaoperacional Android quetornem o aplicativo oui n c o m p a t í v e l o ui n a d e q u a d o a n o v aversao.

Catastrófico 20 Politica da Universidadep o d e i n v i a b i l i z a r autilizacao do software.

Crítico 60 Traba lhos para le los ,p r o f i s s i o n a i s o u d aUniversidade.

Crítico 30 Número de acessos aosistema podera causarcongestionamento.

Moderado 50 Como os clientes saopessoas, todos diferentes,a l g u n s s a otecnologicamente maisexigentes que outros.

Moderado 50 O s i s t e m a f o idesenvolvido apenas paraa plataforma Android, issopode prejudicar usuariosde outras plataformas.

Moderado 30 Nao foram estabelecidasferramentas automaticasde teste.

Marginal 50 Algum aluno abandonar adisciplina.

Marginal 20 Falta de conhecimentoaprofundado por partedos desenvolvedores

12

acerca das ferramentas aserem 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 foramelaboradas:

RISCO: 01 - Proibicao de Utilizacao

Probabilidade: 80% Impacto: 5

Descrição: A Universidade pode nao dar a autorizacao para que o software possa ser utilizado.

Estrategia 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 reuniao com responsaveis pelo SIGAA na UFS.

Quadro 1 – Risco: Proibicao de Utilizacao

RISCO: 02 – Negacao de Recursos para Integracao


Descrição: O setor responsavel da Universidade pode nao disponibilizar recursos para integracao entre o sistema legado e o Sistema de Controle de Frequência.

Estrategia de redução: Guardar os dados em base de dados local, para que nao sejam perdidos enquanto se aguarda a liberacao dos recursos necessarios.

Plano de contingência: Prover funcionalidades de exportacao dos dados para tabelas, permitir salvar dados na nuvem, de modo que o usuario possa acessar tais dados em outros dispositivos ou até mesmo desktops.



Quadro 2 - Negacao de Recursos para Integracao

13

RISCO: 03 – Atualizacõesde Sistema


Descrição: Podem haver atualizacões do sistema operacional Android que tornemo aplicativo incompatível ou inadequado a nova versao.

Estrategia de redução: Acompanhar atualizacões regulares do sistema operacional Android e verificar a necessidade de ajustes para adaptacao.

Plano de contingência: Lancar atualizacao de aplicativo com as mudancas requeridas pela nova versao do sistema operacional Android.

Pessoa responsável: Matheus Mendonca.

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 utilizacao do software.

Estrategia de redução: Mostrar que o software é seguro e nao oferecera brechas de seguranca para com a base de dados da Universidade, além de tornar mais pratico 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.

Estrategia de redução: Dividir as tarefas adequadamente entre os integrantes.

Plano de contingência: Um integrante pode vir a ser responsavel por tarefa(s) deoutro(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.

Estrategia de redução: Solicitar ao administrador de redes uma configuracao para que os acessos sejam feitos paralelamente entre os servidores.

Plano de contingência: Instalacao de novos servidores.

Pessoa responsável: Ytallo Lima.

Status: Configurando os servidores para o acesso ao sistema.

Quadro 6 – Congestionamento de Servidores

RISCO: 07 – Atendimentoa Exigência Tecnológica


Descrição: O Sistema é destinado aos mais diversos usuarios, alguns tecnologicamente mais exigentes que outros.

Estrategia de redução: Tornar a interface amigavel e autodidata ao usuario.

Plano de contingência: Observar as avaliacões, reclamacões e sugestões dos usuarios na Google Play. Aplicar alteracões buscando atender a maior parte dos usuarios.


Status: Modelos de interface em analise.

Quadro 7 - Atendimento a Exigência Tecnológica

RISCO: 08 – Exclusao de Usuarios


Descrição: O sistema foi desenvolvido apenas para a plataforma Android, isso pode fazer com que usuarios de outras plataformas sintam-se excluídos.

Estrategia de redução: Realizar uma pesquisa a fim de identificar quais SO sao mais utilizados pelos clientes.

Plano de contingência: Solicitar aos desenvolvedores a criacao de um sistema com maior portabilidade.


Status: Pesquisa com os clientes a ser agendada.

Quadro 8 - Exclusao de Usuarios

15

RISCO: 09 – Falta de Ferramentas de Teste


Descrição: Nao foram estabelecidas ferramentas automaticas de teste.

Estrategia de redução: Solicitar a aquisicao de novas ferramentas automaticas de Teste. Solicitar aos testadores que incluam essas ferramentas no processo de teste.

Plano de contingência: Executar testes dentre uma amostra de usuarios e anotaro feedback provido por eles.

Pessoa responsável: Ytallo Lima.

Status: Selecao de novas ferramentas automaticas 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.

Estrategia 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: Selecao de pessoas para pesquisar os motivos de evasao.

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.

Estrategia 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 realizacao 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% Analise de Requisitos e Modelagem

30 19% Codificacao

62 39% Testes

Tabela 3: Relacao das tarefas macro e dias de trabalho

Total de 160 dias para a execucao do projeto.

17

4.2 Diagrama de Gantt

Na Figura 4, sao apresentadas todas as tarefas e sub-tarefas que serao realizadasdurante o desenvolvimento o produto de software. A fase de planejamento é compostapelo levantamento de requisitos e validacao de requisitos.

Levantamento de requisitos corresponde a etapa de compreensao do problemaaplicada 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 dosusuarios e reuniao com os responsaveis técnicos.

Na entrevista com o cliente, procura-se extrair o que o cliente quer e como saodesenvolvidas suas atividades, mas o mais importante é definir o que ele realmenteprecisa. Na fase de acompanhamento da rotina dos usuarios, como o próprio nome ja diz,é observar as atividades do usuario para que haja uma maior certeza sobre o que seradesenvolvido.

Na reuniao com os responsaveis técnicos, serao apresentadas todas asinformacões extraídas nas fases anteriores (entrevista com o cliente e acompanhamentoda rotina do usuario) com o objetivo de valida-las. A validacao de requisitos é o processopelo qual se verifica se os requisitos definem o sistema que o cliente realmente quer(SOMMERVILLE, 2011).

A fase de analise e projeto foi subdividida em seis fases:

● Criacao de casos de uso;● Criacao de diagramas de classe de domínio;● Definicao da arquitetura do projeto;● Criacao do diagrama de classes de projeto;● Criacao do diagrama de sequência;● Prototipacao.

Segundo Bezerra (2006), é a especificacao de uma sequência de interacões queocorrem entre o sistema e os agentes externos que utilizam o sistema. Com a criacao doscasos de uso, sera mais facil a visualizacao das interacões que deverao ocorrer.

O diagrama de classes é usado no desenvolvimento de um modelo de sistemaorientado a objetos para mostrar as classes de um sistema e as associacões entre essasclasses (SOMMERVILLE, 2011). O diagrama de sequência é utilizado para indicar acomunicacões dinâmicas entre os objetos durante a execucao de uma tarefa(PRESSMAN,2011).

Na fase de prototipacao serao construídos esbocos de algumas partes do sistema,com o intuito de permitir a visualizacao do cliente de como ficara a parte específica queesta sendo mostrada, dando uma maior seguranca aos desenvolvedores, ja que com oaval do cliente, nao havera necessidade de retrabalho.

A fase de codificacao sera utilizada para o desenvolvimento das funcionalidades dosistema. Ela esta dividida em:

● Cadastrar Usuario;● Efetuar Login;● Manter parâmetros;● Selecionar Disciplinas;● Selecionar Aula;● Informar anotacões;● Efetuar Chamada;

19

● Atualizar presenca.Por último mas nao menos importante, é apresentada a fase de testes. Essa fase

também é dividida em varios tipos de testes, para que possam da uma maior segurancaao software desenvolvido. A fase de teste foi dividida em:

● Teste unitario: tipo de teste que é realizado em nível de componente ou classe;● Teste de integracao: 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 utilizacao da aplicacao.● Teste de carga: responsavel por verificar o funcionamento da aplicacao com a

utilizacao de uma quantidade grande de usuario simultâneos;● Teste de aceitacao dos usuarios: nesse teste é verificado se a solucao sera bem

vista pelo usuario;● Teste de configuracao: testa se a aplicacao funciona corretamente em diferentes

ambientes de hardware ou de software;● Teste de seguranca: como o próprio nome diz, testa a seguranca da aplicacao em

suas diversas formas. Sao testados os perfis, permissões, papéis utilizados paranavegar no sistema.

A Figura 5 abaixo traz o Diagrama de Gantt para o Sistema de Controle deFrequência. Todas as tarefas listadas na Figura 4 estao presentes no diagrama emquestao. Ao lado esquerdo de cada tarefa esta o nome da mesma. Ao lado direito de cadatarefa esta a duracao, 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 serao distribuídos os recursos humanosdisponíveis para a elaboracao do projeto.

5.1 Estrutura da Equipe

A equipe é composta por: Matheus Mendonca, Ytallo Lima e Vanderson Sampaio, atabela abaixo destrincha as funcões a serem exercidas por cada um.

Integrante Funcao Sumario de atividades

Vanderson Sampaio Gestor do projeto Definir papéis e funcões dosdemais integrantes do projeto.

Acompanhar e gerir o trabalho detodos os envolvidos no projeto.

Ytallo Lima Analista de sistema Definir os requisitos do sistema

Matheus Mendonca Arquiteto de software Desenvolver a arquitetura dosistema, inclusive os diagramas

de projeto.

Vanderson SampaioYtallo Lima

Matheus Mendonca

Programadores Desenvolver o código dosistema.

Vanderson SampaioYtallo Lima

Matheus Mendonca

Testadores Testar os casos de uso dosoftware

Tabela 3: Integrantes da equipe e atribuições

5.2 Mecanismos de Comunicação Os mecanismos de comunicacao utilizados pela equipe foram: e-mail, WhatsApp e

Gtalk. Tais meios foram utilizados para troca de mensagens e informacões inerentes aoprojeto em questao.

A plataforma Google Docs foi utilizada como ferramente colaborativa para aexecucao deste documento, de modo a minimizar a necessidade de encontros in locopara execucao do mesmo.

22

5.3 Uso do Edu-blog como ferramenta de apoioO Edu-blog serviu principalmente para:

• Disseminacao 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

execucao do projeto em questao.

6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SOFTWARE

A primeira preocupacao foi diretamente com o cliente. O mesmo foi envolvido emconversas com os integrantes da equipe acerca das necessidades e obrigacões dosprofessores para com a Universidade Federal de Sergipe.

Foram levadas em consideracao também os testes a serem aplicados nodesenvolvimento: unitario, interacao, performance, carga, aceitacao do usuario,configuracao, seguranca.

As reuniões entre os membros da equipe responsavel pelo Projeto foramconstantes. Tais reuniões foram também bastante úteis quanto ao esclarecimento dedúvidas sobre o Projeto. A documentacao e diagramas do sistema foram alteradas nodecorrer das reuniões, buscou-se entretanto manter os integrantes sempre a par de taismudancas em tempo habil de evitar maiores dúvidas.

23

7. ReferênciasSOMMERVILLE, Ian. Engenharia de Software. 9. ed. Sao Paulo: Pearson, 2011.

BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas Com Uml. 2. ed. SaoPaulo: Campus, 2006

PRESSMAN, Roger. Engenharia de Software: Uma abordagem profissional. 7. ed.Sao Paulo: Bookman, 2011.

24

plano de projeto de software

Education