1. O documento apresenta o plano de projeto para o desenvolvimento de um sistema de controle de estágio.
2. É descrito o escopo do projeto, as estimativas de tempo e custo, análise de riscos, planejamento e a equipe envolvida.
3. O projeto tem previsão de conclusão entre 4,5 a 5 meses e envolve o desenvolvimento de um sistema web para gestão de estágios de estudantes.
PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW
Projeto de sw revisado
1. UNIVERSIDADE FEDERAL DE SERGIPE
PRÓ-REITORIA DE PÓS-GRADUAÇÃO E PESQUISA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
ENGENHARIA DE SOFTWARE
PLANO DE PROJETO DE SOFTWARE
SISTEMA DE CONTROLE DE ESTÁGIO
Equipe:
José Jorge Barreto Torres
Igor Peterson Oliveira Santos
Wenderson Campos Pereira
São Cristóvão,SE
2014
2. Sumário
1. INTRODUÇÃO ........................................................................................................................ 1
1.1. Âmbito do Projeto......................................................................................................... 1
1.2. Principais Funções do Produto de Software ................................................................. 1
1.3. Requisitos Comportamentais ou de Performance........................................................ 1
1.4. Gestão e Restrições Técnicas ........................................................................................ 2
2. ESTIMATIVA DO PROJETO ..................................................................................................... 3
2.1. Dados históricos utilizados para as estimativas................................................................. 3
2.2. Técnicas de estimativa e resultados................................................................................... 3
2.2.1. Técnica de estimativa.................................................................................................. 3
2.2.2. Resultados................................................................................................................... 4
2.3. Recursos do projeto ........................................................................................................... 4
2.3.1. Recursos humanos ...................................................................................................... 4
2.3.2. Recursos de software.................................................................................................. 5
2.3.3. Recursos de hardware................................................................................................. 5
2.3.4. Ferramentas de apoio ................................................................................................. 5
3. ANÁLISE E GESTÃO DE RISCOS .............................................................................................. 6
3.1. Riscos do projeto................................................................................................................ 6
3.1.1. Avaliação Global dos Riscos ........................................................................................ 6
3.2. Tabela de riscos.................................................................................................................. 7
3.3. Redução e gestão dos riscos .............................................................................................. 8
4. PLANEJAMENTO TEMPORAL............................................................................................... 11
4.1. Conjunto de Tarefas do Projeto ....................................................................................... 11
4.2. Diagrama de Gantt........................................................................................................... 11
5. ORGANIZAÇÃO DO PESSOAL ............................................................................................... 13
5.1. Estrutura da equipe.......................................................................................................... 13
5.2. Mecanismos de comunicação.......................................................................................... 13
5.3. Uso do edu-blog como ferramenta de apoio................................................................... 14
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE
SOFTWARE .................................................................................................................................. 15
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................................... 16
3. 1
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
1. INTRODUÇÃO
Aqui descreve-se o projeto de software começando pelo seu âmbito, seguido
das principais funções que o sistema deve prover. Os requisitos de tempo e
comportamento da aplicação também são enumerados além de esboçar acerca das
restrições técnicas e temporais do projeto.
1.1. Âmbito do Projeto
Ao observar a necessidade de várias empresas do ramo educacional, a
respeito da gerência e do controle no fornecimento de estagiários às empresas
coligadas, assim como as alocações e acompanhamentos desses estagiários, a
Lacertae SW decide lançar um produto de controle de estágio que efetua todo
cadastro e manutenção dos objetos envolvidos, além de emitir relatórios gerenciais.
Os usuários que utilizam o sistema possuem a característica de estarem
ligados a departamentos de recursos humanos, gente e carreira ou até centrais de
estágio especializadas em empresas do segmento educacional que fornecem
estagiários a outras empresas, inclusive como pré-requisito de formação curricular.
1.2. Principais Funções do Produto de Software
As principais funções que o sistema deve garantir são:
Controle dos estagiários, dosestabelecimentos educacionais e das empresas
vinculadas.
A capacidade de qualificar os estagiários, de acordo com suas áreas de
atuação.
O registro de acompanhamento das horas de estágio.
O histórico de alocação de vagas dos estagiários nas empresas.
Uma empresa pode estar ligada a um ramo de atuação específico e pode
possuir vários estabelecimentos que serão os destinos das alocações de
vagas.
Uma alocação de vaga deve ter o registro temporal de início e fim, bem como
informações referentes à quantidade e o valor das horas alocadas.
1.3. Requisitos Comportamentais ou de Performance
É solicitado que a interface da aplicação seja de fácil utilização, sem cores
chamativas e com suporte a dispositivos móveis. O desempenho deve ser compatível
com o de um sistema web comum. Também utilizar recursos interativos na carga de
campos do website, a fim de se evitar pageloads excessivos, tornando a experiência
do cliente mais agradável e a utilização do canal de comunicação mais leve.
Quanto aos requisitos comportamentais, toda aplicação deve estar completa,
sem faltar nenhuma funcionalidade - incluindo relatórios - antes de entrar em
produção.
4. 2
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
1.4. Gestão e Restrições Técnicas
a. Restrições Técnicas
No que diz respeito a hardware, a equipe de desenvolvimento pode
efetuar os testes de acesso através dos próprios PCs e dispositivos
móveis.
Em software, torna-se necessária uma IDE –
IntegratedDevelopmentEnvironment – eos sistemas de apoio, que são
obtidos através da MSDNAA gratuitamente, incluindo o sistema
operacional para abrigar a ferramenta.
b. Restrições Temporais
O prazo para conclusão do projeto poderá afetar a equipe, visto que o
mesmo é insuficiente para que seja realizado o desenvolvimento e o
conjunto de testes de homologação.
Os participantes do projeto estão alocados em outras atividades
extracurriculares, o que pode resultar em um desempenho insatisfatório
com relação ao empenho dos mesmos no desenvolvimento do projeto
como um todo.
5. 3
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
2. ESTIMATIVA DO PROJETO
As estimativassão úteis para o acompanhamento geral e detalhado do projeto
por todos os membros da equipe. Os cálculos de tempo desprendido em cada fase
são levados em consideração para mensurar e provisionar tal alocação.
2.1. Dados históricos utilizados para as estimativas
Um sistema semelhante sem utilização de interfacewebmulti-plataforma já foi
criado por uma equipe de desenvolvimento um pouco maior que a da Lacertae. Esse
projeto levou cerca três meses até ser colocado em produção para o usuário final.
2.2. Técnicas de estimativa e resultados
Aqui, descreve-se o método de medição e provisionamento de tempo do
projeto através de uma técnica de estimativacomum adotada pela Lacertae SW.
2.2.1. Técnica de estimativa
A técnica de estimativa de tempo eleita pela Lacertae SW é orientada a
classes e de fácil utilização, conhecida como métrica de Lorenz &Kidd (Pressman,
2011). Esta métrica envolve as classes-chave do modelo e as classes de suporte que
são calculadas através de um multiplicador que varia de acordo com o tipo de interface
utilizada no desenvolvimento da aplicação. Os fatores multiplicadores podem ser:
a. Interface não gráfica: x2
b. Baseada em texto: x2,25
c. GUI: x2,5
d. GUI complexa: x3
O cálculo das classes de suporte é realizado multiplicando-se a quantidade
de classes chaves pelo fator multiplicador correspondente ao tipo de interface
adotada. Em seguida é obtido o total de classes somando-se as classes-chave e as
classes de suporte para finalmente multiplicar o valor total de classes pelo “número
médio de unidades de trabalho” (dias/pessoa) por classe. A métrica de Lorenz &Kidd
sugere um número de 15 a 20 dias / pessoa. Segue a fórmula:
[Ch + (Ch x Mu)] x Dp onde,
Ch = Quantidade de classes-chave
Mu = Fator multiplicador
Dp = Número de dias/pessoa (15 a 20)
6. 4
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
2.2.2. Resultados
Pelo fato de existir uma restrição temporal a respeito da alocação dos
integrantes do desenvolvimento do produto de softwareem outros projetos, utiliza-se o
fator dias/pessoa em 20. A aplicação, como já mencionado anteriormente, deve
possuir interface web com suporte a diversas plataformas, tornando a GUI –
GraphicalUser Interface – complexae consequentemente adotando o fator
multiplicador em três (Mu=3). São identificadas no projeto, quatro classes-chave
(Ch=4). São elas: vaga, estabelecimento educacional, estagiário e alocação. Por
fim, o cálculo fica em:
[4 + (4 x 3)] x 20 = 320dias/pessoa
Já que a equipe é formada de três membros, a quantidade de tempo
estimado para o projeto é de 107 dias. Levando em consideração que um mês possui
22 dias úteis, o projeto tem uma previsão de conclusão de quatro meses e meio a
cinco meses.
Com a informação que o projeto tem uma duração total prevista para 320 dias
úteis, dividimos o tempo estimado da forma 40-20-40:
Planejamento: 3% = aprox. 9 dias.
Requisitos, análise, desenho: 39% = aprox. 125 dias.
Geração de código: 20% = 64 dias.
Testes: 38% = aprox. 122 dias.
2.3. Recursos do projeto
2.3.1. Recursos humanos
A equipe de desenvolvimento de software é formada por três profissionais
extremamente capacitados em suas áreas:
José Jorge Barreto Torres
o Gerente de projetos
o Certificado Project Management Professional – PMP
o Engenheiro de Software
Igor Peterson Oliveira Santos
o Coordenador de desenvolvimento
o Microsoft CertifiedSolutionsDeveloper – MCSD
o Engenheiro de software
Wenderson Campos Pereira
o Coordenador de testes
o Certificação Brasileira de Teste de Software – CBTS
o Microsoft CertifiedSolutionsDeveloper – MCSD
o Engenheiro de testes e de software
7. 5
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
2.3.2. Recursos de software
Alguns dos softwares envolvidos, desde o desenvolvimento da aplicação até
a publicação em um ambiente de produção,são adquiridos através da licença
acadêmica MSDNAA e estão descritos a seguir:
Visual Studio 2010 Professional: Contém toda suíte de desenvolvimento
e testes necessária para o andamento do projeto.
Visual Studio 2010 Team Foundation Server: Ambiente de integração do
desenvolvimento de software, contendo diversas ferramentas
colaborativas, incluindo controle de versão.
Windows Server 2008 Enterprise: Sistema operacional que abriga os
servidores de desenvolvimento, homologação e produção. Os serviços
de apoio como IIS e outras bibliotecas adicionais estão incluídos no
S.O.
Oracle Database11gR2 Enterprise Edition: Banco de dados para
armazenamento dos objetos do sistema, com suporte a recursos de
compactação de dados, particionamento de tabelas e backup avançado.
2.3.3. Recursos de hardware
Em uma blade HP, possuímostrês servidores virtualizados no VMWare ESX
para os ambientes de testes, homologação e produção. A configuração do hardwareda
bladeé: BL 465C Gen 8 6378 (2P), com dois processadores 16-core de 2.4 GHz, 64GB
RAM e dois discos SAS de 256GB em RAID 1.
2.3.4. Ferramentas de apoio
Nas fases de concepção e planejamento do projeto, utilizamos as seguintes
ferramentas de modelagem e gerência de projetos:
Oracle SQL Developer: utilizada para criar os modelos conceituais e
lógicos de banco de dados, além de geração dos objetos físicos.
StarUML: Modelagem dos diagramas de classes e casos de uso do
sistema.
Microsoft Project: Gerência do projeto, alocação de recursos,
estimativas de tempo, etc.
8. 6
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
3. ANÁLISE E GESTÃO DE RISCOS
Segundo (Pressman,2011) (Sommerville, 2007), o gerenciamento de riscos
consiste em prever os riscos que podem afetar o cronograma do projeto ou a
qualidade do software que está sendo desenvolvido e tomar providências para evitar
riscos que possam vir a acontecer. Um gerenciamento eficiente de riscos torna mais
fácil lidar com os problemas e assegurar que eles não conduzam a um orçamento
inaceitável ou atraso no cronograma.
O gerenciamento de riscos é particularmente importante para projetos de
software, devido às incertezas inerentes à maioria dos projetos. Eles se originam de
requisitos mal definidos, dificuldades na estimativa de prazos e recursos necessários
para o desenvolvimento de software, dependência de habilidades individuais e
mudanças de requisitos devido às mudanças nas necessidades dos
clientes(Sommerville, 2007).
Diante disso, as próximas seções apresentam riscos detectados para o
projeto do software deste documento, Sistema de Controle de Estágio, assim como o
plano de redução, supervisão e gestão de risco (RSGR).
3.1. Riscos do projeto
Risco Projeto Técnico Negócio Comum Especial
Retenção de talentos X X
Custo associado com atraso na
entrega
X X X
O cliente não tem ideia
completa do produto
X X
Problemas em detectar
Requisitos governamentais
X X X
Garantia de disponibilidade do
software
X
Subestimativas do esforço X X
Tabela 1: Identificação dos Riscos do Projeto
3.1.1. Avaliação Global dos Riscos
A seguir estão algumas perguntase respostas, quanto à avaliação global dos
Riscos.
a) O gestor de Software dá suporte ao projeto?
Sim. O gestor é fundamental para o andamento do projeto.
b) Os clientes estão entusiasmados com o projeto e o produto?
Sim. Afinal, eles são os principais beneficiados com os recursos e
facilidades que o software propõe.
c) Os engenheiros de Software compreenderam bem os requisitos?
9. 7
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
Sim. O processo de análise de requisitos é definido em conjunto com
todas as partes envolvidas do software, o que contribui, dessa forma,
para um conhecimento geral de como o software deve ser concebido.
d) Os clientes estiveram envolvidos na definição de requisitos?
Sim. Como foi respondido anteriormente, os clientes e usuários finais
estão envolvidos e aptos a ajudar para a criação do software.
e) O âmbito do projeto é estável?
Até o momento, sim. Mesmo que os requisitos possam ser modificados
e riscos possam ocorrer, estamos atentos e preparados para possíveis
modificações do projeto.
f) Os engenheiros de softwarepossuem as competências requeridas?
Sim. Os engenheiros têm experiências no mercado e a soma dessas
experiências contribuirá para o bom desenvolvimento do projeto.
g) Os requisitos do projeto estão estáveis?
Os principais requisitos se encontram estáveis, mas esses e outros
podem vir a sofrer modificações a depender de processos futuros no
desenvolvimento ou na detecção de novos requisitos fundamentais
para o projeto.
h) A equipe de desenvolvimento tem experiência na tecnologia que será
utilizada?
A equipe tem experiência com boa parte das tecnologias adotadas,
embora estejam sempre propensos a aprender e agregar
conhecimento para o projeto.
i) É adequado o número de pessoas da equipe de trabalho?
Sim. Afinal, o tamanho do projeto condiz com o prazo estimado para o
desenvolvimento do software. Dessa forma, a equipe de trabalho
trabalhará focada na qualidade e no prazo do projeto.
3.2. Tabela de riscos
Os riscos do projeto são identificados através das seguintes categorias:
tamanho do produto, impacto de negócio, cliente, maturidade do software, tecnologia e
pessoas.Estes riscos podem ser vistos na Tabela 2, e estão organizadosem ordem
decrescente de impactos e probabilidades:
Risco Categoria Probabilidade Impacto
R_01:Garantir a alta disponibilidade Tecnológico 50% Catastrófico
R_02:Ausência de equipe de testes
dedicada
Maturidade do
SW
90% Crítico
R_03:Número de clientes que utilizam
o produto
Negócio 70% Crítico
R_04:Comportamento duvidoso em Tecnológico 60% Crítico
10. 8
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
sistemas móveis
R_05:Problemas de consistência de
dados
Tamanho do
Produto
60% Crítico
R_06:Garantia da performance em
caso de muitos acessos simultâneos
Tecnológico 40% Crítico
R_07:Custo associado com atraso na
entrega
Negócio 40% Crítico
R_08:Retenção de talentos Pessoas 40% Crítico
R_09:Requisitos governamentais Negócio 20% Crítico
R_10:Não acompanhar as fases do
projeto
Cliente 90% Moderado
R_11:Tem pouco tempo para dedicar
no projeto
Cliente 90% Moderado
R_12:Não entende os requisitos
técnicos
Cliente 90% Moderado
R_13:Falta de acompanhamento da
qualidade de software por equipe
especializada
Maturidade do
SW
90% Moderado
R_14:O cliente não tem ideia
completa do produto
Cliente 80% Moderado
R_15:Custo associado com produto
defeituoso
Negócio 50% Moderado
R_16:Número de usuários do produto
Tamanho do
Produto
60% Moderado
R_17:Reutilização de código de SW
Tamanho do
Produto
30% Marginal
R_18:Condições ruins de ambiente de
trabalho
Pessoas 20% Marginal
R_19:Recrutamento de especialistas
com habilidades
Pessoas 20% Marginal
R_20:Não conhece o processo de
E.S.
Cliente 90% Desprezível
Tabela 2: Riscos do Projeto
3.3. Redução e gestão dos riscos
Para a elaboração de um plano de redução, supervisão e gestão de riscos
(RSGR), define-se um ponto de corte dos nove primeiros riscos identificados na
Tabela 2. Estes são apresentados a seguir.
R_01: Garantira alta disponibilidade
RISCO: 01-2014 PROB: 50% IMPACTO: Catastrófico
Descrição: Garantia que o software esteja sempredisponível.
Estratégia de Redução: Monitoramento constante da saúde dos serviços de infraestrutura.
Plano de contingência: Adoção de um sistema de Clusters de Alta Disponibilidade.
Pessoa responsável: José Jorge Barreto Torres
Status: Analisando propostas de fornecedores em (12/04/2014).
11. 9
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
R_02: Ausência de equipe de testes dedicada
RISCO: 02-2014 PROB: 90% IMPACTO: Crítico
Descrição: Não possui equipe de testes especializada e/ou pessoas alocadas para se dedicar
a testes do software.
Estratégia de Redução:Dedicar mais horas relativas ao teste de softwarepor parte dos
desenvolvedores
Plano de contingência: Contratação de testadores certificados.
Pessoa responsável: José Jorge Barreto Torres.
Status: Efetuando pesquisa de mercado por recursos humanos especializadosem
(12/04/2014).
R_03: Número de clientes que utilizam o produto
RISCO: 03-2014 PROB: 70% IMPACTO: Crítico
Descrição: Grande quantidade de clientes utilizando o produto ao mesmo tempo.
Estratégia de Redução: Efetuar testes de stress para detectar os limites de utilização do
produto e realizar tunning dos serviços.
Plano de contingência: Adaptar hardware dos servidores quando o tunning não fizer mais
diferença no desempenho.
Pessoa responsável: José Jorge Barreto Torres
Status:Implementandotunning de performanceem (12/04/2014).
R_04: Comportamento duvidoso em sistemas móveis
RISCO: 04-2014 PROB: 60% IMPACTO: Crítico
Descrição:Falhas no acesso e uso do software ou dos dados da aplicação móvel.
Estratégia de Redução: Monitorar o sistema nos diferentes tipos de Sistemas Operacionais e
realizar casos de testes para detectar as diversas falhas que possam surgir.
Plano de contingência: Disponibilizar outro sistema, temporariamente, com as
funcionalidades principais e mais utilizadas.
Pessoa responsável:Wenderson Campos Pereira
Status: Analisando as informações de uso do sistema em (15/04/2014).
R_05: Problemas de consistência de dados
RISCO: 05-2014 PROB: 60% IMPACTO: Crítico
Descrição: Problemas de consistência no banco de dados do software.
Estratégia de Redução: Monitorar periodicamente a qualidade dos dados que são inseridos
no banco de dados.
Plano de contingência: Fazer a restauração do banco de dados.
Pessoa responsável:Wenderson Campos Pereira
Status: Verificando as informações inseridas pelos usuáriosem (15/04/2014).
R_06: Garantia da performance em caso de muitos acessos simultâneos
RISCO: 06-2014 PROB: 40% IMPACTO: Crítico
Descrição: Garantir o bom desempenho do software quando houver vários acessos
simultâneos no software.
Estratégia de Redução: Habilitar a compressão GZIP (GNU Zip) para o conteúdo das
páginas web do sistema antes de enviar para o usuário.
Plano de contingência: Diminuir a quantidade de dados trafegando pelo canal de
comunicação com a finalidade de evitar sobrecarga.
Pessoa responsável:Wenderson Campos Pereira
Status: Avaliando os resultados de resposta das páginas do sistemaem (15/04/2014).
12. 10
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
R_07: Custo associado com atraso na entrega
RISCO: 07-2014 PROB: 40% IMPACTO: Crítico
Descrição:Problemas em adicional de custo do software associado com atraso na entrega do
mesmo.
Estratégia de Redução: Monitoramento constante do projeto e de suas tarefas.
Plano de contingência: Ter parceiros terceirizados para desenvolvimento de parte do projeto.
Pessoa responsável: Igor Peterson Oliveira Santos
Status: Monitorando projeto em (16/04/2014).
R_08: Retenção de talentos
RISCO: 08-2014 PROB: 40% IMPACTO: Crítico
Descrição:Busca contínua em manter os talentos das diversas áreas do desenvolvimento do
software.
Estratégia de Redução: Verificar ambiente de trabalho e ofertas de emprego fora da
companhia.
Plano de contingência: Criar planos de motivação para os funcionários.
Pessoa responsável: Igor Peterson Oliveira Santos
Status: Desenvolvendo planos de motivação e ambiente de trabalho em (16/04/2014).
R_09: Requisitos governamentais
RISCO: 09-2014 PROB:20% IMPACTO:Crítico
Descrição:Atividades de estágio não compatíveis com o que é descrito na Lei nº 11.788
(2008).
Estratégia de Redução:Buscar sempre ficar atualizado quanto à lei que regulariza as
atividades dos estagiários.
Plano de contingência:Alocar e concentrar desenvolvedores para adequar o sistema as
mudanças na lei de forma imediata.
Pessoa responsável: Igor Peterson Oliveira Santos
Status:Colhendo informações sobre a lei no portal do MEC (Ministério da Educação) de forma
periódica.
13. 11
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
4. PLANEJAMENTO TEMPORAL
Nesta seção descreve-se o conjunto de tarefas do projeto. Após isso, as
datas e os responsáveis pela execução dessas tarefas são representados através do
Diagrama de Gantt.
4.1. Conjunto de Tarefas do Projeto
Na subseção de resultados da estimativa do projeto, estima-se um tempo de
320 dias para o desenvolvimento completo do sistema. Embora esse tempo seja
calculado para uma pessoa somente,uma equipe de três compõe o desenvolvimento
do projeto. Conclui-se que o tempoprevisto para conclusão do sistema é reduzido
para,aproximadamente, 107 dias úteis. A divisão de tarefas pela porcentagem é
apresentada na Tabela 3.
Tarefas Porcentagem do
Tempo
Dias úteis de
atividade
Planejamento 3% 3
Requisitos, análise, desenho 39% 41
Geração de código 20% 22
Testes 38% 41
Tabela 3: Divisão das tarefas
4.2. Diagrama de Gantt
O Diagrama de Gantt é responsável pela programação de cada atividade.
Além disso, as tarefas estão associadas a um ou mais elementos do projeto. Na
Figura 1, está a representação do Diagrama de Gantt para o projeto do Sistema de
Controle de Estágio.
No Diagrama podemos destacar a etapa de Requisitos, Análise e Desenhono
qual possui uma duração de 41 dias.Inicialmente, realiza-se o levantamento dos
requisitos necessários para o desenvolvimento do sistema, que tem uma duração de
10 dias. Os próximos 5 dias ficam dedicados para a Definição de Casos de Uso dos
sistema e para o desenvolvimento do Diagrama de Classes. Após isso, aloca-se um
período de 18 dias para oprojeto do Banco de Dados para, por fim, realizar e
apresentar os Protótipos do Sistema em 8 dias.
Na etapa de Construção, estão definidas as quatro classes-chave do projeto,
as quais servem de base para mensuração do tempo de duração do projeto.
Sãoalocados22 dias para o desenvolvimento dessas classes.A mesma quantidade de
dias está definida para o gerenciamento de controle de versões.
Para o período de Testes e Transição do Sistema,há uma dedicação de41
dias. Nesteperíodo a quantidade de dias é maior que o de desenvolvimento,pois trata-
se de uma etapa onde é averiguada a qualidade do que foi desenvolvido até o
14. 12
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
momento. Para isso, está definido um período de 22 dias para os Casos de Testes. O
processo final do projeto faz parte da implantação do sistema, que é uma parte bem
delicada e que merece atenção, que possui duração de 15 dias úteis.
Figura 1: Diagrama de Gantt do projeto
15. 13
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
5. ORGANIZAÇÃO DO PESSOAL
A equipe realiza um bom trabalho em conjunto do início ao fim do projeto. As
delegações das tarefas são tomadas em consenso e a comunicação entre os
membros faz com que se organizem a ponto de produzir um projeto com melhor
qualidade.
5.1. Estrutura da equipe
A equipe é formada por três membros, descritos abaixo com as respectivas
funções:
Nome E-mail Função
José Jorge Barreto Torres jorgesamango@gmail.com Engenheiro de
Software e Gerente
de Projetos
Igor Peterson igorpeterson@gmail.com Engenheiro de
Software e Analista
de Sistemas
Wenderson Campos Pereira wendersonse@gmail.com Engenheiro de
Software e Analista
de Testes
Tabela 4: Membros da equipe, contato e suas funções.
Segue abaixo a descrição breve de cada função:
Engenheiro de Software: Responsável pelo projeto, design da
aplicação e implementação do sistema.
Gerente de Projetos: Gerenciar e controlar todo o projeto, delegar
funções aos membros da equipe com prazos, realizar controle de
qualidade e também verificar cada etapa do projeto.
Analista de Sistemas: Realiza o levantamento e análise de requisitos
do software.
Analista de Testes: Responsável pela definição do ambiente de
testes e planejamentos e execução dos casos de testes, bem comoo
reporte dos erros e defeitos encontrados.
5.2. Mecanismos de comunicação
O processo de comunicação do timeocorreatravés da utilização de
ferramentas colaborativas e de comunicação como Skype e Google Drive. Pelo menos
duas vezes por semanaacompanha-se o andamento do projeto de forma
semipresencial, a fim de discuti-lo, solucionar problemase delegar tarefas.
16. 14
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
5.3. Uso do edu-blog como ferramenta de apoio
A ferramenta Edu-blogé fundamental durante todo projeto, pois oferece
umadinâmica entre o professor e os alunos da disciplina. Além disso, através dessa
ferramenta é possível organizar todo o conteúdo da disciplina em um só lugar. Tanto o
material ofertado pelo professor quanto os links para os blogs de outros alunos com as
atividades e projetos de cada grupo estão disponíveis a todos.
17. 15
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SOFTWARE
A equipe utiliza os seguintes itens com o intuito de garantir e controlar a
qualidade do produto de software:
a) Gestão de Projeto de Software–Realiza-se um acompanhamento
constante das atividades desenvolvidas por parte de todos os
envolvidos no projeto.
b) Revisões Técnicas Formais - As revisões são executadas por
pessoas capacitadas durante todo o ciclo, visando à identificação de
erros nas fases iniciais do projeto onde o custo para a manutenção é
reduzido.
c) Gestão de Configuração do Software - Conjunto de atividades
projetadas para controlar inúmeras correções, extensões e
adaptações aplicadas durante o ciclo de vida do software de forma a
assegurar um processo de desenvolvimento e evolução sistemático e
rastreável.
d) Métricas de Qualidade - São realizadas medições para verificar o
quanto o software atende aos requisitos impostos pelo usuário.
e) Análise de Riscos - Identificar, analisar e controlar os riscos,
elaborando planos de redução e de contingência.
f) Testes–Realizar testes dentro de um processo definido, com o
objetivo de fornecer informações sobre sua qualidade em relação ao
contexto em que ele deve operar. Além disso, identificar possíveis
erros antes que estes se transformem em defeitos e tornem-se riscos,
trazendo prejuízos para a empresa.
18. 16
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
REFERÊNCIAS BIBLIOGRÁFICAS
PRESSMAN, Roger S.Engenharia de Software. 7° ed. McGraw-Hill. 2011.
SOMMERVILLE, Ian. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison-Wesley,
2007.