Plano do projeto de software

1
UNIVERSIDADE FEDERAL DE SERGIPE – UFS
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA - CCET
DEPARTAMENTO DE COMPUTAÇÃO - DCOMP
CAMPUS SÃO CRISTÓVÃO
ALEF MENEZES DOS SANTOS
ANDRÉ TEIXEIRA DE FRADES
DANILO GOIS DOS ANJOS
EDTON DE OLIVEIRA LEMOS
LEANDRO DOS SANTOS NETO
PLANO DO PROJETO DE SOFTWARE OO
PARA PRODUTOS DA LACERTAE SW
Prof. Dr. Rogério Patrício Chagas do Nascimento
SÃO CRISTÓVÃO - SE
2017

2
UNIVERSIDADE FEDERAL DE SERGIPE – UFS
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA - CCET
DEPARTAMENTO DE COMPUTAÇÃO - DCOMP
CAMPUS SÃO CRISTÓVÃO
ALEF MENEZES DOS SANTOS
ANDRÉ TEIXEIRA
DANILO GOIS DOS ANJOS
EDTON LEMOS
LEANDRO NETO
PLANO DO PROJETO DE SOFTWARE OO
PARA PRODUTOS DA LACERTAE SW
Sistema Painel de Estoque
Prof. Dr. Rogério Patrício Chagas do Nascimento
SÃO CRISTÓVÃO - SE
2017

3
SUMÁRIO
1. INTRODUÇÃO ....................................................................................................... 4
1.1. ÂMBITO DO PROJETO .......................................................................................... 4
1.2. FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE .................................. 4
1.3. REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE....................... 5
1.4. GESTÃO E RESTRIÇÕES TÉCNICAS .................................................................. 6
2. ESTIMAÇÕES DO PROJETO ............................................................................. 7
2.1. TÉCNICAS DE ESTIMAÇÃO E RESULTADOS .................................................. 7
2.2. RESULTADOS......................................................................................................... 7
2.3. RECURSOS DO PROJETO ..................................................................................... 9
3. ANALISE E GESTÃO DE RISCOS ................................................................... 11
3.1. RISCOS DO PROJETO .......................................................................................... 11
3.2. TABELAS DE RISCOS.......................................................................................... 11
3.3. REDUÇÃO E GESTÃO DO RISCO...................................................................... 12
4. PLANEJAMENTO TEMPORAL ....................................................................... 18
4.1. CONJUNTO DE TAREFAS DO PROJETO.......................................................... 18
4.2. DIAGRAMA DE GANTT ...................................................................................... 20
5. ORGANIZAÇÃO DO PESSOAL........................................................................ 22
5.1. ESTRUTURA DA EQUIPE ................................................................................... 22
5.2. MECANISMOS DE COMUNICAÇÃO................................................................. 22
5.3. USO DO EDU-BLOG COMO FERRAMENTA DE APOIO ................................ 23
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SW............................................................... 24
REFERÊNCIAS .................................................................................................... 25

4
1. INTRODUÇÃO
Este documento especifica os requisitos funcionais do sistema Painel de
Estoque. Tais requisitos foram levantados após entrevista com o cliente. Foi também
levado em consideração a análise da situação atual do ambiente do cliente. Os requisitos
levantados, servem de base para o desenvolvimento sistema Painel de Estoque, para ser
utilizado através da plataforma/interface Web.
As características do sistema Painel de Estoque são observados nos serviços
oferecidos e suas restrições. Ele ainda propõe uma solução para determinado problema
ou de otimização para a determinada tarefa que é a gestão do estoque farmacêutico o
Hospital Universitário.
1.1. ÂMBITO DO PROJETO
O sistema Painel de Estoque deve permitir que funcionários do Hospital
Universitário, como do setor: financeiro, diretoria, farmácia e almoxarifado, visualizem
a situação atual do estoque. Isso se dará, através de gráfico de Curva ABC, indicadores
do estoque (atual e já concretizado), além de gerar relatórios para que seja possível a
documentação física da movimentação dos medicamentos. O acesso deve ocorrer
através da interface Web, que será hospedada em servidor próprio do Hospital
Universitário. Os dados devem estar dispostos em forma de dashboard (painéis), de
modo a ter um entendimento visual intuitivo, de forma rápida e clara.
1.2. FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE
Na Figura 1 mostra-se o diagrama de caso de uso que ilustra os atores, que
podem interagir com o Painel de Estoque, como também os requisitos funcionais do
sistema.

5
Figura 1 - Diagrama de caso de uso.
Fonte: Autores, 2017.
Na Figura 1 podem ser observados os atores representados Funcionário
(Financeiro, Diretoria, Farmácia e Almoxarifado) e Banco de Dados HU. Os atores são
aqueles que executam funções no sistema. Há também o registro dos requisitos
funcionais do sistema, são eles: Gerar Relatório, Gerar Curva ABC, Gerar Indicadores,
Escolher Indicador, Exibir Detalhes e Manter Dados.
Vale ressaltar que o Painel de Estoque é totalmente dependente dos dados
provenientes do banco de dados do Hospital Universitário, visto que não será efetuado
qualquer cadastro de dados pelo mesmo. Ou seja, o Painel de Estoque, só irá refletir
dados que já constam no banco de dados, utilizando apenas seleções especificas para
tratamento dos dados.
1.3. REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE

6
O sistema Painel de Estoque deve ser compatível com a interface Web e respeitar
padrões de usabilidade. Para tal, o mesmo possui uma lista de requisitos de comportamento ou
performance denominados requisitos não-funcionais, tais como:
a) Usabilidade: interface simples, de fácil e rápida compreensão;
b) Confiabilidade: integridade da informação, condizendo com o que está no banco de dados;
c) Desempenho: carregamento dos dados, mantendo a aplicação atualizada a cada 15 minutos; e
d) Implantação: utilização em ambientes operacionais do Windows e Linux.
1.4. GESTÃO E RESTRIÇÕES TÉCNICAS
Algumas restrições foram levadas em considerações, providas através do ambiente,
tecnologias e solicitações do cliente, tais como:
a) O sistema Painel de Estoque será desenvolvimento com a linguagem de programação Java,
com IDE de desenvolvimento Eclipse;
b) O sistema de banco de dados a ser utilizado deve ser o PostgreSQL;
c) O sistema será utilizado através da Web por navegadores específicos, como: Google Chrome
e Mozilla Firefox; e
d) O sistema não deve alterar dados contidos no banco de dados do Hospital Universitário;

7
2. ESTIMAÇÕES DO PROJETO
Essa seção contém a descrição e o detalhamento da técnica utilizada para
estimar o tempo do desenvolvimento do software. Sendo este o primeiro projeto desta
equipe, não existem dados históricos a serem utilizado para as estimações.
2.1. TÉCNICAS DE ESTIMAÇÃO E RESULTADOS
Para estimar o tempo é necessária a utilização de uma técnica de estimativa. A
técnica escolhida para o nosso projeto foi a de Lorenz & Kidd (1994), Orientada a
Objetos, adotada pela Lacertae Software.
Trata-se de uma técnica orientada a classes que dá como resultado uma
estimativa do esforço necessário para desenvolver o software. O que se faz nessa técnica
basicamente é decompor os esforços usando como parâmetros o número de classes-
chave do Sistema. Essas classes são responsáveis pela estimativa de esforço final. Há
também as classes de suporte, que são classes que não fazem parte do domínio do
problema, geralmente representam janelas, botões, caixas de diálogo, etc.
Um quesito importante dessa técnica é a classificação da interface do produto,
que resultará no multiplicador para as classes de suporte, de acordo com o Quadro 1.
Quadro 1 - Multiplicadores para interfaces.
Interface Multiplicador
Não gráfica 2,0
Baseada em
texto
2,25
GUI 2,5
GUI complexa 3,0
Fonte: Lorenz & Kidd, 1994.
2.2. RESULTADOS
Para a realização das estimações por meio da técnica de Lorenz & Kidd (1994)
utilizamos o diagrama de Classes de Domínio na Figura 2.

8
Figura 2 - Diagrama de classes de domínio.

9
Após a análise do diagrama e das considerações da técnica utilizada, foi
possível obter as seguintes conclusões:
1. Quantidade de classes chave: 4 (Material, Relatório, CurvaAbc e Indicador);
2. Tipo de interface: GUI;
3. Valor multiplicador: 2,5;
4. Classes de suporte: 4 (classes chave) X 2,5 (valor multiplicador) = 10 classes;
5. Total de classes: 4 (classes chave) + 10 (classes de suporte) = 14 classes;
6. Unidade média de trabalho por classe, utilizaremos 17 dias por pessoa, totalizando
238 dias por pessoa; e
7. A equipe possui cinco membros, estimando um prazo de 48 dias para a conclusão do
projeto. Estando inclusos sábados, domingos e feriados.
2.3. RECURSOS DO PROJETO
2.3.1. Recursos Humanos
A equipe é composta por dois gestores de projetos/programadores, um analista
de sistema, um arquiteto de software e um testador. Na seção 4.1 está detalhando a
atribuição de cada membro da equipe.
2.3.2. Hardware Necessário
Será necessário a utilização de um servidor para disponibilizar o acesso a todos
os usuários do sistema.
a) Requisitos mínimos de hardware: processador de 1GHz ou superior e memória RAM
de 1 GB ou superior; e
b) Periféricos: mouse, teclado e Monitor.
2.3.3. Software de suporte
São todos os softwares necessários para manter a aplicação em seu pleno
funcionamento.
a) Sistema de gerenciamento de banco de dados PostgreSql 8;
b) Servidor Java Web Tomcat 7;

10
c) Navegador multi-plataforma Chrome 50.0.2661.94 m (ou superior) ou Mozilla
Firefox 27.0.q (ou superior);
d) Sistema Operacional Windows 7 ou 8; e
e) Plataforma computacional Java 8.

11
3. ANALISE E GESTÃO DE RISCOS
3.1. RISCOS DO PROJETO
No Quadro 2 são listados os riscos identificados no projeto do sistema Painel
de Estoque.
Quadro 2 – Riscos do projeto.
Especial Comum Negócio Técnico Projeto Risco
X
Custos associados a defeitos
do produto.
X X
Número de mudança dos
requisitos.
X X
As melhores pessoas estão
disponíveis.
X
A equipe tem as habilidades
necessárias.
X X
Quantidade de pessoas
suficiente.
X X
A equipe recebeu
treinamento necessário.
X X
Visibilidade pelo gestor
sênior.
X X
Custos associados ao atraso
da entrega.
X X
Condução de revisões
formais.
X
Tamanho estimado do
produto em LOC, FP.
X X
Estabilizado um processo
comum de framework.
X
Abordagem proativa de
SQA.
X A equipe sempre contribuiu.
X X Restrições governamentais.
X X
Clientes participando das
revisões.
3.2. TABELAS DE RISCOS
No Quadro 3 são listados os riscos, a probabilidade de que ocorram e o
impacto que eles ocasionariam.

12
Quadro 3 – Probabilidade e Impacto dos riscos.
Risco Probabilidade Impacto
Custos associados a defeitos do produto. 80,0% Catastrófico
Número de mudança dos requisitos. 80,0% Crítico
As melhores pessoas estão disponíveis. 80,0% Crítico
A equipe tem as habilidades necessárias. 80,0% Crítico
Quantidade de pessoas suficiente. 80,0% Crítico
A equipe recebeu treinamento necessário. 80,0% Crítico
Visibilidade pelo gestor sênior. 70,0% Crítico
Custos associados ao atraso da entrega. 70,0% Crítico
Condução de revisões formais. 70,0% Crítico
Tamanho estimado do produto em LOC, FP. 60,0% Crítico
Estabilizado um processo comum de framework. 60,0% Crítico
Abordagem proativa de SQA. 70,0% Moderado
A equipe sempre contribuiu. 60,0% Moderado
Restrições governamentais. 50,0% Moderado
Clientes participando das revisões. 50,0% Moderado
Os riscos identificados passaram por um ponto de corte, restando aqueles com
maior probabilidade de acontecer (acima de 50%) e que trariam um impacto maior.
3.3. REDUÇÃO E GESTÃO DO RISCO
Levando em consideração os riscos listados nas subseções anteriores, a seguir
são descritos os planos para redução de risco, supervisão e contingência.
Quadro 4 - Custos associados a defeitos do produto.
Custos associados a defeitos do produto
Risco: 001 Probabilidade: 80% Impacto: Catastrófico
Descrição: A equipe pode não ter as habilidades e conhecimento necessários na
concepção do projeto.
Estratégia de Redução: Membros da equipe devem dedicar tempo para praticar suas
habilidades, devem utilizar padrões e boas práticas.
Plano de Supervisão: Verificar se os membros estão seguindo os padrões e boas
práticas, realizado pelo Gestor de Projetos.
Plano de Contingência: Pessoas que participaram do projeto ficam responsáveis pela
correção de defeitos, evitando desperdício de horas em entendimento da regra do
negócio e especificidades do projeto.
Pessoa Responsável: Alef Menezes dos Santos

13
Quadro 5 - Número de mudança dos requisitos.
Número de mudança dos requisitos
Risco: 002 Probabilidade: 80% Impacto: Crítico
Descrição: Caso seja necessário a mudança em requisitos.
Estratégia de Redução: Deve-se possuir um contrato com os requisitos definidos e
assinados pelo cliente, com cláusulas de exceções de alteração para somente o
necessário, onde o mesmo deve-se delimitado pelo Gestor de Projetos.
Plano de Supervisão: Verificar se os requisitos implementados condizem com os
solicitados.
Plano de Contingência: Avaliar se a solicitação afeta custos e prazos, caso afete
renegociar com o cliente, conforme definido no contrato.
Quadro 6 - As melhores pessoas estão disponíveis.
As melhores pessoas estão disponíveis
Descrição: As pessoas com as melhores habilidades ou com perfil mais adequado a
participarem do projeto podem não estar disponíveis.
Estratégia de Redução: Membros da equipe devem dedicar tempo para praticar suas
habilidades.
Plano de Supervisão: Verificar a desenvoltura dos membros nas práticas.
Plano de Contingência: Incentivar a qualificação por meio de cursos, palestras e
quaisquer meio de manutenção e atualização dos membros.
Quadro 7 - A equipe tem as habilidades necessárias.
A equipe tem as habilidades necessárias
Descrição: A equipe pode não ter as habilidades necessárias para execução do projeto.
Estratégia de Redução: Membros da equipe deverão obrigatoriamente dedicar tempo
para praticar suas habilidades.
Plano de Supervisão: Verificar a desenvoltura dos membros nas práticas.
Plano de Contingência: Intensificar em horas extras a prática em desenvolvimento.
Pessoa Responsável: André Teixeira de Frades.
Quadro 8 - Quantidade de pessoas suficiente.
Quantidade de pessoas suficiente
Descrição: A equipe conta com pequena quantidade de pessoas.
Estratégia de Redução: Delegar as atividades de acordo com a quantidade de pessoas
envolvidas e cobrar comprometimento dos mesmos.
Plano de Supervisão: Verificar a participação efetiva de todos os membros.
Plano de Contingência: Adicionar um novo membro que possa colaborar no
desenvolvimento. Renegociar prazos e priorizar entregas.

14
Quadro 9 - A equipe recebeu treinamento necessário.
A equipe recebeu treinamento necessário
Descrição: A equipe não foi devidamente treinada para execução do projeto.
Estratégia de Redução: Membros da equipe devem dedicar tempo para estudo
individual das tecnologias e regras de negócio.
Plano de Supervisão: Acompanhar domínio da equipe em relação as tecnologias
utilizadas e regras de negócio.
Plano de Contingência: Contratação de empresa especializada para treinamento das
tecnologias e ou regras de negócio.
Quadro 10 - Visibilidade pelo gestor sênior.
Visibilidade pelo gestor sênior
Descrição: O gestor sênior não está presente acompanhando o projeto.
Estratégia de Redução: Utilização de ferramentas que auxiliem a comunicação interna,
como exemplo o Slack, que reduz a burocracia na comunicação entre a equipe,
melhorando o desenvolvimento do produto.
Plano de Supervisão: Propor reuniões diárias e semanais para o nivelamento das
informações e acompanhar a evolução do projeto pela equipe.
Plano de Contingência: Possuir planos reserva, em caso da não possibilidade do gestor
sênior estar presente, o gestor ou supervisor possa dar prosseguimento ao
andamento/execução do projeto.
Pessoa Responsável: Danilo Gois dos Anjos.
Quadro 11 - Custos associados ao atraso da entrega.
Custos associados ao atraso da entrega
Descrição: Custos que podem ou não extrapolar o valor total previsto no planejamento,
causados pelo não cumprimento de entregas dentro prazo.
Estratégia de Redução: Escolher o time de acordo com as habilidades e experiências
anteriores individuais necessárias para a garantia do prazo e da qualidade do projeto.
Plano de Supervisão: Acompanhar a evolução do desenvolvimento por meio do Mapa
de Gantt ou painéis de acompanhamento, afim de verificar se o time está seguindo o
cronograma.
Plano de Contingência: Entrar em acordo com o cliente para que sejam feitas múltiplas
entregas, com uma ou mais funcionalidades a cada entrega.

15
Quadro 12 - Condução de revisões formais.
Condução de revisões formais
Descrição: Execução dos testes fora do padrão adotado na empresa.
Estratégia de Redução: Possuir uma equipe de testes bem qualificada. Fazer uso de
testes automatizados quando possível.
Plano de Supervisão: Verificar se os testes estão sendo executados conforme padrões
adotados pela empresa.
Plano de Contingência: Avaliar a possibilidade de contratar uma empresa
especializada em testes de software.
Quadro 13 - Tamanho estimado do produto em LOC, FP.
Tamanho estimado do produto em LOC, FP
Descrição: O tamanho do código software ou a falta de padrões ou notações possa
afetar pontos como o desempenho, legibilidade e qualidade do software.
Estratégia de Redução: Utilização de padrões de projetos e de boas práticas de
desenvolvimento de software.
Plano de Supervisão: Realizar análise estática e dinâmica do código para verificar
conformidade com os padrões definidos e treinar os desenvolvedores para seguir os
padrões ou notações definidas pela empresa.
Plano de Contingência: Treinar os programadores para aplicar mais padrões de
projetos e reuso no software. Verificar o código para apontar o que pode ser reduzido.
Pessoa Responsável: Edton de Oliveira Lemos
Quadro 14 – Framework comum de processo.
Estabilizar um framework comum de processo
Descrição: Equipe não está seguindo um processo de desenvolvimento bem definido.
Estratégia de Redução: Classificar os Processos em grupos de processos relacionados
e aplicar uma metodologia para estabelecer uma linguagem comum entre os grupos.
Plano de Supervisão: Verificar o andamento do projeto e de suas respectivas atividades
em reuniões semanais.
Plano de Contingência: Investir em treinamento da equipe em uma metodologia de
desenvolvimento ou contratar um profissional para capacitar a equipe.

16
Quadro 15 - Abordagem proativa de SQA.
Abordagem proativa de SQA
Risco: 012 Probabilidade: 70% Impacto: Moderado
Descrição: Desenvolvedores não estão seguindo métodos de Engenharia de Software
para garantir a qualidade.
Estratégia de Redução: Seguir padrões ou normas para conformidade da qualidade do
processo, como a norma SPICE, o CMMI ou o MPS.BR.
Plano de Supervisão: Controle de código-fonte, revisões de código, gerenciamento de
configuração de software, testes, gerenciamento de lançamento e integração de
produtos.
Plano de Contingência: Treinar os desenvolvedores com as boas práticas de
desenvolvimento de software ou investir em uma certificação para a empresa ou
profissional da equipe.
Quadro 16 - A equipe sempre contribuiu.
A equipe sempre contribuiu
Descrição: Nem todos os membros da equipe contribui para o andamento do projeto.
Estratégia de Redução: Reuniões para definição de tarefas e redução de erros no
produto.
Plano de Supervisão: Lista de frequência e de conclusões das atribuições dadas a cada
membro da equipe.
Plano de Contingência: Distribuir entre as equipes, membros que não estão
conseguindo contribuir além disto, indicar em cada equipe um integrante com
conhecimentos avançados para auxiliar estas pessoas com grau de desenvolvimento
lento.
Pessoa Responsável: Leandro dos Santos Neto
Quadro 17 - Restrições governamentais.
Restrições governamentais
Descrição: Questões legais podem impedir que os dados sejam acessíveis.
Estratégia de Redução: Avaliar a legislação no que se refere a painel de estoque na
administração pública.
Plano de Supervisão: Acompanhar as questões legais à medida que o projeto evolui,
verificando se de alguma forma a legislação pública é ferida.
Plano de Contingência: Reavaliar requisitos funcionais do projeto. Negociar novos
prazos.
Pessoa Responsável: Leandro dos Santos Neto.

17
Quadro 18 - Clientes participando das revisões.
Clientes participando das revisões
Descrição: O cliente não participa das revisões do desenvolvimento do produto.
Estratégia de Redução: Reuniões semanais para acompanhamento do desenvolvimento
do produto.
Plano de Supervisão: Acompanhar através de relatórios como as reuniões semanais
com o cliente procedeu.
Plano de Contingência: Ir até o cliente para mostrar o andamento do desenvolvimento
do projeto.
Pessoa Responsável: Leandro dos Santos Neto.

18
4. PLANEJAMENTO TEMPORAL
Nesta seção é apresentado o planejamento temporal do projeto, onde são
definidas as tarefas, as datas, e a sequência de atividades que foram escolhidas para o
desenvolvimento do software. Além disso, são apresentados o(s) responsável(eis) por
cada atividade estabelecida. A importância desse planejamento está alinhada à
mensuração do andamento do projeto e de seu cumprimento em relação aos prazos
estabelecidos.
4.1. CONJUNTO DE TAREFAS DO PROJETO
O modelo de processo de desenvolvimento de software adotado para
desenvolver o sistema Painel de Estoque foi o Scrum, um framework de
desenvolvimento ágil para gestão e planejamento de projetos de software. No Scrum, os
projetos são divididos em ciclos chamados de Sprints e por se tratar de uma
metodologia ágil de desenvolvimento, elas são iterativas, ou seja, o trabalho é dividido
em iterações que são completadas ao final de cada Sprint.
O projeto começou em 04/01/2017 e tem previsão de ser entregue em
20/02/2017, totalizando os 48 dias que foram definidos para desenvolver o sistema
utilizando as métricas da seção 2. Os papéis definidos para este projeto foram:
 Projeto: Sistema Painel de Estoque;
 Product Owner: Hospital Universitário – UFS;
 Scrum Master: André Teixeira;
 Time de Desenvolvimento: Alef Menezes, André Teixeira, Danilo Gois,
Edton Lemos e Leandro Neto.
O processo foi dividido em 4 fases: Planejamento, Especificação do Projeto,
Desenvolvimento e Testes e Validação. Na fase de Desenvolvimento foram definidas 4
Sprints para entregar uma funcionalidade a cada iteração. Na Figura 3 são definidas as
fases e suas respectivas tarefas bem como o tempo de trabalho necessário e os
respectivos responsáveis.

19
Figura 3 - Tarefas do Projeto.

20
Na Tabela 3 é detalhado o tempo gasto nas tarefas do projeto em relação aos
dias. Foi respeitado cerca de 4% do tempo (dias) para a fase de planejamento. Seguindo
uma distribuição de esforço adequada para uma boa gestão, foi considerada a
distribuição de 40/20/40 (ou 4/2/4) entre as fases restantes de nosso projeto. Conforme a
realidade do nosso sistema, um tempo de trabalho de cerca de 39% foi definido para a
fase de Especificação do Projeto, 20% para o Desenvolvimento e 37% para Testes e
Validação.
Tabela 3 – Dias de trabalho por fase do projeto.
Fase Dias de Trabalho (úteis)
Porcentagem Trabalho
(%/aproximada)
Planejamento 2 4%
Especificação do Projeto 18 39%
Desenvolvimento 10 20%
Testes e Validação 15 37%
Total de dias 48 100%
4.2. DIAGRAMA DE GANTT
O diagrama de Gantt presente na Figura 4 apresenta a distribuição das tarefas
conforme o tempo do projeto, bem como a sua sequência.

21
Figura 4 – Diagrama de Gantt do projeto.

22
5. ORGANIZAÇÃO DO PESSOAL
Esta seção descreve como foi a distribuição dos recursos humanos disponíveis
para o desenvolvimento do projeto.
5.1. ESTRUTURA DA EQUIPE
A equipe é composta por cinco pessoas, Alef Menezes, André Teixeira, Danilo
Gois, Edton Lemos e Leandro Neto. Foram delegadas funções para cada integrante
conforme Quadro 19.
Quadro 19 – Integrantes e suas funções.
Integrante Função Atividades Realizadas
Danilo Gois e Alef
Menezes
Gestor do Projeto Definir papéis e funções
dos integrantes da equipe
do projeto. Acompanhar e
gerir o trabalho de todos
os envolvidos.
André Teixeira Analista de Sistema Definir os requisitos do
sistema.
Edton Lemos Arquiteto de Software Desenvolver a arquitetura
do sistema, inclusive os
diagramas de projeto.
Danilo Gois e Alef
Menezes
Programador Codificação do sistema.
Leandro Neto Testador Desenvolver e realizar os
casos de teste do sistema.
É importante ressaltar que essas funções não foram fixas, os integrantes da
equipe durante a execução do projeto em algumas ocasiões desempenharam funções as
quais não lhe foram inicialmente atribuídas.
5.2. MECANISMOS DE COMUNICAÇÃO
Para comunicação durante o desenvolvimento do projeto foram utilizados
mecanismos de comunicação como: e-mail, WhatsApp, Facebook e Skype. Tais meios
foram utilizados para troca de mensagens e informações inerentes ao projeto em
questão.

23
Para elaboração deste documento foi utilizado a ferramenta Dropbox de modo
a minimizar a necessidade de encontros in loco e agilizar a execução do mesmo.
5.3. USO DO EDU-BLOG COMO FERRAMENTA DE APOIO
A colaboração trazida pela adoção do Edu-blog serviu principalmente para:
a) Disseminação do conhecimento;
b) Troca de informações entre equipes diferentes;
c) Aprendizado de ferramentas que ajudaram no desenvolvimento do trabalho da
equipe;
d) Compartilhamento de novidades e curiosidades que mostraram-se bastante úteis à
execuç ão do projeto em questão.

24
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SW
A primeira precaução foi envolver o cliente em conversas com os integrantes
da equipe das necessidades e obrigações dos professores para com a Universidade
Federal de Sergipe.
Foram levados em consideração também os testes a serem aplicados no
desenvolvimento: unitário, interação, desempenho, carga, stress, aceitação do usuário,
configuração e segurança.
As reuniões entre os membros da equipe responsável pelo Projeto foram
constantes, sendo bastante úteis quanto ao esclarecimento de dúvidas sobre o Projeto.
No decorrer das reuniões, a documentação e diagramas do sistema foram alterados
quando necessário, buscou-se então, manter os integrantes sempre atualizados sobre tais
mudanças em tempo hábil de evitar dúvidas e equívocos.

25
REFERÊNCIAS
LORENZ, Mark; KIDD, Jeff. Object-oriented software metrics: a practical guide.
Prentice-Hall, Inc., 1994.

Plano do projeto de software

Mais conteúdo relacionado

Mais procurados

Semelhante a Plano do projeto de software

Plano do projeto de software