Post on 23-Jun-2015
UNIVERSIDADE FEDERAL DE SERGIPEPRÓ-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
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
1
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, dos estabelecimentos 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.
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
2
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 – Integrated Development Environment – e os 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.
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
3
2. ESTIMATIVA DO PROJETO
As estimativas sã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 interface web multi-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 estimativa comum 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)
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
4
2.2.2. Resultados
Pelo fato de existir uma restrição temporal a respeito da alocação dos integrantes do desenvolvimento do produto de software em 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 – Graphical User Interface – complexa e 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 Torreso Gerente de projetos
o Certificado Project Management Professional – PMP
o Engenheiro de Software
Igor Peterson Oliveira Santoso Coordenador de desenvolvimento
o Microsoft Certified Solutions Developer – MCSD
o Engenheiro de software
Wenderson Campos Pereirao Coordenador de testes
o Certificação Brasileira de Teste de Software – CBTS
o Microsoft Certified Solutions Developer – MCSD
o Engenheiro de testes e de software
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
5
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ímos três servidores virtualizados no VMWare ESX para os ambientes de testes, homologação e produção. A configuração do hardware da 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.
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
6
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écnicoNegóci
oComum Especial
Retenção de talentos X XCusto 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 XTabela 1: Identificação dos Riscos do Projeto
3.1.1. Avaliação Global dos Riscos
A seguir estão algumas perguntas e 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?
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
7
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 software possuem 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 organizados em ordem decrescente de impactos e probabilidades:
Risco CategoriaProbabilidad
eImpacto
R_01:Garantir a alta disponibilidade Tecnológico 50% CatastróficoR_02:Ausência de equipe de testes dedicada
Maturidade do SW
90% Crítico
R_03:Número de clientes que utilizam Negócio 70% Crítico
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
8
o produtoR_04:Comportamento duvidoso em sistemas móveis
Tecnológico 60% Crítico
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íticoR_09:Requisitos governamentais Negócio 20% CríticoR_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 disponibilidadeRISCO: 01-2014 PROB: 50% IMPACTO: CatastróficoDescrição: Garantia que o software esteja sempre disponí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 TorresStatus: Analisando propostas de fornecedores em (12/04/2014).
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
9
R_02: Ausência de equipe de testes dedicadaRISCO: 02-2014 PROB: 90% IMPACTO: CríticoDescriçã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 software por parte dos desenvolvedoresPlano de contingência: Contratação de testadores certificados.Pessoa responsável: José Jorge Barreto Torres.Status: Efetuando pesquisa de mercado por recursos humanos especializados em (12/04/2014).
R_03: Número de clientes que utilizam o produtoRISCO: 03-2014 PROB: 70% IMPACTO: CríticoDescriçã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 TorresStatus: Implementando tunning de performance em (12/04/2014).
R_04: Comportamento duvidoso em sistemas móveisRISCO: 04-2014 PROB: 60% IMPACTO: CríticoDescriçã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 PereiraStatus: Analisando as informações de uso do sistema em (15/04/2014).
R_05: Problemas de consistência de dadosRISCO: 05-2014 PROB: 60% IMPACTO: CríticoDescriçã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 PereiraStatus: Verificando as informações inseridas pelos usuários em (15/04/2014).
R_06: Garantia da performance em caso de muitos acessos simultâneosRISCO: 06-2014 PROB: 40% IMPACTO: CríticoDescriçã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 PereiraStatus: Avaliando os resultados de resposta das páginas do sistema em (15/04/2014).
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
10
R_07: Custo associado com atraso na entregaRISCO: 07-2014 PROB: 40% IMPACTO: CríticoDescriçã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 SantosStatus: Monitorando projeto em (16/04/2014).
R_08: Retenção de talentosRISCO: 08-2014 PROB: 40% IMPACTO: CríticoDescriçã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 SantosStatus: Desenvolvendo planos de motivação e ambiente de trabalho em (16/04/2014).
R_09: Requisitos governamentaisRISCO: 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 SantosStatus: Colhendo informações sobre a lei no portal do MEC (Ministério da Educação) de forma periódica.
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
11
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 tempo previsto 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 Desenho no 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 o projeto 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ão alocados 22 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 de 41 dias. Neste período a quantidade de dias é maior que o de desenvolvimento, pois
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
12
trata-se de uma etapa onde é averiguada a qualidade do que foi desenvolvido até o 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
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
13
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çãoJosé 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 time ocorre através da utilização de ferramentas colaborativas e de comunicação como Skype e Google Drive. Pelo menos duas vezes por semana acompanha-se o andamento do projeto de forma semipresencial, a fim de discuti-lo, solucionar problemas e delegar tarefas.
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
14
5.3. Uso do edu-blog como ferramenta de apoio
A ferramenta Edu-blog é fundamental durante todo projeto, pois oferece uma dinâ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.
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
15
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.
Plano de Projeto Versão 1.1Última atualização: 25/04/2014
16
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.
Plano de Projeto Versão 1.1Última atualização: 25/04/2014