O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Plano do projeto de software

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
1
UNIVERSIDADE FEDERAL DE SERGIPE – UFS
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA - CCET
DEPARTAMENTO DE COMPUTAÇÃO - DCOMP
C...
2
UNIVERSIDADE FEDERAL DE SERGIPE – UFS
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA - CCET
DEPARTAMENTO DE COMPUTAÇÃO - DCOMP
C...
3
SUMÁRIO
1. INTRODUÇÃO .....................................................................................................
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Próximos SlideShares
Slide apresentação CMMI-TOGAF
Slide apresentação CMMI-TOGAF
Carregando em…3
×

Confira estes a seguir

1 de 25 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Plano do projeto de software (20)

Anúncio

Mais recentes (20)

Plano do projeto de software

  1. 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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. 7. 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. 8. 8 Figura 2 - Diagrama de classes de domínio. Fonte: Autores, 2017.
  9. 9. 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. 10. 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. 11. 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. Fonte: Autores, 2017. 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. 12. 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 Fonte: Autores, 2017. 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 Fonte: Autores, 2017.
  13. 13. 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. Pessoa Responsável: Alef Menezes dos Santos Fonte: Autores, 2017. Quadro 6 - As melhores pessoas estão disponíveis. As melhores pessoas estão disponíveis Risco: 003 Probabilidade: 80% Impacto: Crítico 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. Pessoa Responsável: Alef Menezes dos Santos Fonte: Autores, 2017. Quadro 7 - A equipe tem as habilidades necessárias. A equipe tem as habilidades necessárias Risco: 004 Probabilidade: 80% Impacto: Crítico 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. Fonte: Autores, 2017. Quadro 8 - Quantidade de pessoas suficiente. Quantidade de pessoas suficiente Risco: 005 Probabilidade: 80% Impacto: Crítico 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. Pessoa Responsável: André Teixeira de Frades. Fonte: Autores, 2017.
  14. 14. 14 Quadro 9 - A equipe recebeu treinamento necessário. A equipe recebeu treinamento necessário Risco: 006 Probabilidade: 80% Impacto: Crítico 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. Pessoa Responsável: André Teixeira de Frades. Fonte: Autores, 2017. Quadro 10 - Visibilidade pelo gestor sênior. Visibilidade pelo gestor sênior Risco: 007 Probabilidade: 70% Impacto: Crítico 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. Fonte: Autores, 2017. Quadro 11 - Custos associados ao atraso da entrega. Custos associados ao atraso da entrega Risco: 008 Probabilidade: 70% Impacto: Crítico 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. Pessoa Responsável: Danilo Gois dos Anjos. Fonte: Autores, 2017.
  15. 15. 15 Quadro 12 - Condução de revisões formais. Condução de revisões formais Risco: 009 Probabilidade: 70% Impacto: Crítico 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. Pessoa Responsável: Danilo Gois dos Anjos. Fonte: Autores, 2017. Quadro 13 - Tamanho estimado do produto em LOC, FP. Tamanho estimado do produto em LOC, FP Risco: 010 Probabilidade: 60% Impacto: Crítico 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 Fonte: Autores, 2017. Quadro 14 – Framework comum de processo. Estabilizar um framework comum de processo Risco: 011 Probabilidade: 60% Impacto: Crítico 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. Pessoa Responsável: Edton de Oliveira Lemos Fonte: Autores, 2017.
  16. 16. 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. Pessoa Responsável: Edton de Oliveira Lemos Fonte: Autores, 2017. Quadro 16 - A equipe sempre contribuiu. A equipe sempre contribuiu Risco: 013 Probabilidade: 60% Impacto: Moderado 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 Fonte: Autores, 2017. Quadro 17 - Restrições governamentais. Restrições governamentais Risco: 014 Probabilidade: 50% Impacto: Moderado 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. Fonte: Autores, 2017.
  17. 17. 17 Quadro 18 - Clientes participando das revisões. Clientes participando das revisões Risco: 015 Probabilidade: 50% Impacto: Moderado 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. Fonte: Autores, 2017.
  18. 18. 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. 19. 19 Figura 3 - Tarefas do Projeto. Fonte: Autores, 2017.
  20. 20. 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% Fonte: Autores, 2017. 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. 21. 21 Figura 4 – Diagrama de Gantt do projeto. Fonte: Autores, 2017.
  22. 22. 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. Fonte: Autores, 2017. É 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. 23. 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 à execuç ão do projeto em questão.
  24. 24. 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. 25. 25 REFERÊNCIAS LORENZ, Mark; KIDD, Jeff. Object-oriented software metrics: a practical guide. Prentice-Hall, Inc., 1994.

×