O slideshow foi denunciado.
PLANO DO PROJETO DE SOFTWARE OO                       para produtos da Lacertae SW1.0 INTRODUÇÃO     1.1 Âmbito do Projeto...
então  é  decidido  se  este  será  aprovado  ou  não.  A  terceira,  acontece  no   momento  em  que  chega  a  data  pel...
○ Consulta a Situação da Unidade;● Para o Perfil Propesp:      ○ Avaliar Documentação de PCDT ;      ○ Avaliar Pedidos ;  ...
o  Framework  de  desenvolvimento  de  software  para  web  para  a   linguagem PHP chamado CodeIgneiter;○ O PIC Eletrônic...
 2.0 ESTIMATIVAS DO PROJETO       Nesta  seção  será  apresentado  o  cálculo  para  estimativa  da  duração  totaldo  pro...
de  suporte)  pelo  número  médio  de  unidades  de  trabalho              (dias­pessoa)  por  classe.  Lorenz  &  Kidd  s...
5.  A quantidade de dias­pessoas adotada da sugestão de  Lorenz &       Kidd  foi  de  19   dias,  numa  escala  entre  15...
abrangendo  projetos/programas.  É  dividido  em  iterações de  (geralmente) 30  dias  chamados  sprints,  onde  se  traba...
○ Desenvolvedor;   ○ Testador.Janiel Medeiros   ○ Scrum Master;   ○ Desenvolvedor;   ○ Testador.Kirmayr  Tomaz   ○ Scrum M...
dados e outros.Sistema  Operacional  Ubuntu  ­  Sistema  operacional de  código livre,  queserá utilizado pela equpe.Googl...
Browser  Chrome  versão  22  ou  Firefox  versão  18  ­  Utilizados  para      visualizar o que foi desenvolvido.      Dri...
­ Falta da presença do cliente na definição dos requisitos;­ O  fato do cliente não oferecer suporte ao projeto;­ A equipe...
Risco                Probabilidade    ImpactoMudança de Tecnologia               10%         CatastróficoA  tecnologia  é ...
Uso  de  novos  métodos  em               50%                     MarginalEngenharia de SoftwareNão  ser  estabelecido    ...
Estratégia  de  redução:  Validação  com  o  cliente  a  respeito  do  ambiente  em      que  o sistema final  irá rodar  ...
Risco:  Os  engenheiros Prob: 50%                       Impacto: Crítico de     softwares   não compreendem  bem  os requi...
Plano  de  Contigência:  Buscar  nas  próximas  iterações  do  projeto  definir      melhor os requisitos  e  validar­los ...
Descrição:  O  risco  diz  respeito  a  entrega de  um produto ou de um incremento      que  não  atenda  completamente  a...
Responsável: Scrum Master Status: Ocorrido.  Risco:      Falta   de Prob: 30%                          Impacto: Crítico.  ...
desenvolvido  utilizando  a  metodologia  de  desenvolvimento  ágil  conhecidacomo  SCRUM,  tal  metodologia  trabalha  co...
treinamento  e  estudo  a  respeito  das  tecnologias  definidas         para o projeto.             ● Definição  das   te...
detalhamento  maior  por  conta  de  se  entender  que nessa fase   é  feita  a  construção  do  produto  que  será  entre...
4.2 Diagrama de Gantt       O  Diagrama  de  Gantt (em  anexo ao projeto de  software)  detalha asatividades planejadas pa...
 5.0 ORGANIZAÇÃO DO PESSOAL       Na  seção  2.4.1  desse  documento  é  apresentada  a  metodologia dedesenvolvimento  em...
○ Programador 1:Urique Hoffmann   ○ Programador 2 : Alison Medeiros   ○ Testador:Kirmayr Tomaz 5.2 Mecanismos de comunicaç...
6.0    PRECAUÇÕES          TOMADAS         PARA      ASSEGURAR  ECONTROLAR A QUALIDADE DO PRODUTO DE SW         É  realiza...
atividades e o status de execução destas.Análise de Riscos       Identificação,  análise  e controle dos riscos, elaborand...
Próximos SlideShares
Carregando em…5
×

Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2

718 visualizações

Publicada em

Projeto de Software feito no contexto da disciplina de gerencia de projetos pelos alunos Urique Hoffmann, Janiel Medeiros, Alison Lemos e Kirmayr Costa. Alunos de Sistema de Informação da Universidade Federal do Amazonas.

Publicada em: Educação
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Projeto de Software - PIC Eletrônico - Gerência de Projetos UFAM 2012/2

  1. 1. PLANO DO PROJETO DE SOFTWARE OO para produtos da Lacertae SW1.0 INTRODUÇÃO  1.1 Âmbito do Projeto Este  projeto  de  software  aborda  um  sistema  que  está  sendo desenvolvido  pelos  graduandos  Alison  Garantizado,  Janiel  Medeiros, Kirmayr  Costa  e  Urique  Hoffmann  do  curso  de  Sistemas de Informação do sexto  período   da  Universidade  Federal  do  Amazonas.  É  um  resultado  de uma  parceria  entre  o  Instituto  de Computação e a Pró­Reitoria de Pesquisa e  Pós­Graduação  (Propesp).  Está  inserido  em  uma  abordagem multidisciplinar envolvendo quatro  disciplinas  cursadas nesse período pelos alunos  envolvidos.  Tem  o  objetivo  de  capacitar  os  alunos  e  ao  mesmo tempo suprir necessidades da Universidade Federal do Amazonas. O  sistema  que  está   sendo  desenvolvido   se  intitula  PIC  Eletrônico. Este  tem  o  objetivo  de  dar  suporte  ao  Plano  Instituicional de Capacitação (PIC) da Universidade Federal do Amazonas. O  PIC  é  gerido  pela  Propesp  e  acontece  durante  triênios.  Este  tem como  objetivo  viabilizar   o  acesso  à  educação  para  servidores  da Universidade  Federal  do  Amazonas  (UFAM)  para  um  desenvolvimento melhor  de  suas   atividades  dentro  da  instituição.  Esse  programa  acontece em  quatro  etapas.  Na  primeira,  há  o  Pedido  de  Capacitação  Docente Técnico  (PCDT)  de cada unidade para a Propesp. A segunda, é a etapa de avaliação  desses  pedidos,  cada  um  deles  é  avaliado  individualmente  e 1
  2. 2. então  é  decidido  se  este  será  aprovado  ou  não.  A  terceira,  acontece  no momento  em  que  chega  a  data  pela   qual  o  servidor  aprovado  na  etapa anterior  se  afastará  para  a  capacitação.  Esta  etapa  consiste  no preenchimento  e  na  avaliação  de  alguns  dados  relevantes  a  sua  ausência durante  o  período  de  capacitação. A última etapa do programa é a parte de execução da capacitação. O  sistema  de  PIC  Eletrônico  abrangerá  três  das  quatro  etapas citadas anteriormente, não abrangendo a última etapa.  1.2 Funções principais do produto de software O  PIC  Eletrônico  está   inserido  em  um  cenário  que  possui  a participação de três perfis de usuários, administrador, unidade e propesp. O  perfil  de  Administrador  diz  respeito  ao  ator  do  sistema responsável  por  configurar e  manter  o sistema bem como  a alimentação de dados.  O  perfil  de  Unidade diz  respeito  ao ator  do  sistema  que representa as unidades que utilizarão o  software.  O perfil  Propesp  diz respeito  ao ator do sistema que fará  a  avaliação de dados e pedidos enviados por usuários do perfil unidade. Seu escopo está dividido da seguinte forma:● Para o Perfil de Administrador: ○ Gerência de Usuários; ○ Gerência de Unidades; ○ Gerência de Servidores; ○ Gerência de PIC;● Para o Perfil Unidade: ○ Solicitar PCDT; ○ Geração de Relatórios; ○ Consulta a Histórico de PIC; 2
  3. 3. ○ Consulta a Situação da Unidade;● Para o Perfil Propesp: ○ Avaliar Documentação de PCDT ; ○ Avaliar Pedidos ; ○ Consultar Diagnóstico de Unidade; ○ Geração de Relatórios;  1.3 Requisitos comportamentais ou de performance O  sistema  terá  que apresentar  uma  interface amigável  visando  sua máxima  utilização  por  diferentes  perfis  de  usuário,  os  quais  nem  sempre dispõem de conhecimento sobre informática e/ou tecnologias web. Em  relação  aos  requisitos  comportamentais  o  sistema  não apresenta  nenhuma funcionalidade  crítica.  Para  a impressão dos  relatórios o  sistema  necessita  esta  sincronizado  com  uma  impressora.  Algumas funcionalidades  do  sistema  estarão  disponíveis  apenas  quando  a  data (para  a  disponibilidade  da  funcionalidade)  previamente  estabelecida  pelo administrador  esteja  vigente,  fora  desta  data   o  sistema  alertara  aos  seus usuários que a funcionalidade esta indisponível.  1.4 Gestão e Restrições Técnicas Abaixo  seguem  algumas  questões  técnicas  e  restrições  que  o  PIC Eletrônico está inserido. São elas: ○ O  PIC  Eletrônico  deverá  importar dados  contidos  na base de dados do Sistema de Informações para o Ensino (SIE) da UFAM; ○ O PIC Eletrônico deverá rodar na plataforma Web; ○ O  PIC  Eletrônico  deverá ser construído utilizando a tecnologia PHP e 3
  4. 4. o  Framework  de  desenvolvimento  de  software  para  web  para  a linguagem PHP chamado CodeIgneiter;○ O PIC Eletrônico deverá conter uma abordagem sólida em testes;○ A  equipe  não  possui  experiência  prática   com  as  ferramentas  e métodos utilizados para o desenvolvimento;○ O  PIC  Eletrônico  será  desenvolvido  em  um  contexto  de Desenvolvimento Distribuído de Software (DDS);○ Haverá  Rotatividade  de  papéis  durante  todo  o  processo  de desenvolvimento.○ O  PIC  Eletrônico  deverá  ser  desenvolvido  utilizando  uma metodologia de desenvolvimento ágil. 4
  5. 5.  2.0 ESTIMATIVAS DO PROJETO Nesta  seção  será  apresentado  o  cálculo  para  estimativa  da  duração  totaldo  projeto  em  dias.  Para encontrar  esse  tempo  é  necessário aplicar uma  técnicade  estimativa  e  neste  caso  iremos  utilizar  a  métrica  adotada  pela  LacertaeSoftware: Lorenz & Kidd;  2.1 Dados históricos utilizados para as estimativas Não  possuímos  dados  históricos  para  serem  utilizados  nas estimativas.  2.2 Técnicas de estimativa e resultados A métrica utilizada para encontrar o prazo total de duração do projeto em  dias  foi  a  Lorentz  &  Kidd.  É uma métrica  orientada a classes  adotada pela  Lacertae   Software  para  realizar  a  estimativa  do  prazo  total  deste projeto.  2.2.1 Técnica de estimativa. Foi  utilizada  a  técnica  de  estimativa  que  segue as regras da métrica de Lorenz & Kidd adaptada pela Lacertae Software. Seguiu­se os seguintes passos: 1.  Definir o número de classes chave; 2.  Encontrar  o  número  de  classes  de suporte,  classificar o tipo de interface  do  produto  e  desenvolver um multiplicador para as classes de suporte; 3.  Multiplicar a quantidade de classes­chave pelo multiplicador para obter uma estimativa do número de classes de suporte; 4.  Logo  após,  calcula­se  a  quantidade  total  de  classes,  somando o nº de classes­chaves com o nº de classes de suporte;  5.  Multiplicar a quantidade total de classes (classes­chave + classes 5
  6. 6. de  suporte)  pelo  número  médio  de  unidades  de  trabalho (dias­pessoa)  por  classe.  Lorenz  &  Kidd  sugere  entre 15 e 20  dias pessoa  por  classe.   Escolher  um  número  entre 15  e  20  dias pessoa por classe e justificar a escolha. 6.  Determinar a quantidade de esforço estimada; 7.  Calcular o tempo previsto para a elaboração do projeto. A  tabela  abaixo  mostra  os  fatores  de multiplicação  indicados pela  métrica  para  encontrar  a  quantidade  de  classes de  suporte.  O projeto  possui  uma  interface  do  tipo  GUI  complexo  com  um  fator multiplicador de 3,0. Interface MultiplicadorNão gráfica 2baseada em texto 2,25GUI 2,5GUI complexo 3,0 2.3 Resultados De  acordo  com  a   métrica  descrita  acima  obteve­se  os seguintes resultados: 1.  Quantidade de classes chaves = 6; 2.  É  um  sistema  web que utiliza a interface gráfica GUI com um  fator multiplicador igual a 3,0; 3.  Classes  chaves  x  multiplicador (6  x  3) = 18 classes de  suporte; 4. Classes  chaves  +  classes  de  suporte  (6  +  18)  =   24  classes projetadas para o sistema; 6
  7. 7. 5.  A quantidade de dias­pessoas adotada da sugestão de  Lorenz & Kidd  foi  de  19   dias,  numa  escala  entre  15  e  20  dias.  Levou­se  em conta  a  falta  de  experiência  no  método  de  desenvolvimento  e  do framework por toda  a equipe e a falta  de conhecimento e prática em programação web por parte da equipe. 6.  Calculou­se  a  quantidade  de  esforço  estimada:  (24  x  19)  = 456  dias  de trabalho; 7.  A  equipe  de  desenvolvimento  deste  projeto  possui  quatro membros.  Calculou­se  a   distribuição  dos  dias  de  trabalho  por pessoa  :  456  ÷   4  =  114  dias  sendo  que  foram  trabalhados efetivamente 78  dias,  indicando que  o projeto foi realizado dentro do prazo.  Supondo  o  valor  de  15  dias  para  a  quantidade  de dias­pessoas,  o  valor  de  dias  trabalhados  será  de  360  dias,  que dividido  pelos   quatro  membros:  360  ÷   4  =  90  dias  por  pessoa. Desta  forma,  com  a  redução  dos  dias  por  pessoa  adotada  da sugestão  da  métrica  Lorenz  &  Kidd,  a  estimativa  do  tempo  do projeto ficou mais próxima da real. 2.4 Recursos do projeto Os  recursos  do  sistema  foram  separados  em  três  partes:  recursoshumanos, recursos de software e recursos de hardware:2.4.1 Recursos Humanos A  equipe  utilizará  o  método  SCRUM.  Uma  metodologia  quenormalmente  é  utilizada  em  processos  considerados  imprevisíveis  (  éimpossível predizer  tudo o  que  irá ocorrer ). Desenvolvido inicialmente parao  gerenciamento  de  projetos  de  software,  SCRUM  também  é  utilizado  namanutenção  de  software  e  para  o  gerenciamento  de  forma  global, 7
  8. 8. abrangendo  projetos/programas.  É  dividido  em  iterações de  (geralmente) 30  dias  chamados  sprints,  onde  se  trabalha  para  alcançar  objetivos   bem definidos.  Estes   objetivos  são  representados  por  uma  lista  de funcionalidades  que  é  atualizada  e  repriorizada  a  cada  nova  sprint.  Os papéis principais em equipes SCRUM são:● Product Owner: responsável pela visão de negócios do projeto.● Scrum Master: é uma mistura  de  gerente, facilitador  e mediador daequipe de desenvolvimento● Desenvolvedor: responsável por implementar o sistema.● Testador: responsável por realizar os testes no sistema.  A dinâmica seguida pelo SCRUM é a seguinte: ● Realiza­se  uma  reunião  para  definir  quais  funcionalidades  serão desenvolvidas na sprint ● Durante  a  sprint  são  realizadas  reuniões  diárias, com o objetivo de avaliar  o  que  foi  feito  no  dia  anterior,  identificar  quais  impedimentos surgiram e priorizar o trabalho a ser desenvolvido no dia seguinte. ● No  fim  da  sprint  é  apresentado  aos  Stakholders,  o  conjunto  de funcionalidades  que  foram  desenvolvidas,  para  que  estas  possam  ser aprovadas,  e  por  fim   é  feita  uma  reunião  para  planejar  a  próxima  sprint, fechando assim o circulo A  equipe  é  formada  por  4  integrantes   ,  os  componentes da equipe assumem  diferentes  papéis  a  cada  sprint.  Esses   papéis  são  de  1(um) scrum  master,  2  (dois)  programadores  ,  1(um)  testador  e  2  (dois)  product owner.  Cada  ciclo  da  sprint  é  de  3  (três)  semanas  e  após  isso  os integrantes  sofrem  rotatividade  da  equipe  na  seção  5.1  será  detalhado como acontecerá, veja abaixo os papéis que cada integrante pode assumir: Alison Lemos ○ Scrum Master; 8
  9. 9. ○ Desenvolvedor; ○ Testador.Janiel Medeiros ○ Scrum Master; ○ Desenvolvedor; ○ Testador.Kirmayr  Tomaz ○ Scrum Master; ○ Desenvolvedor; ○ Testador.Urique Hoffmann ○ Scrum Master; ○ Desenvolvedor; ○ Testador.2.4.2 Recursos de Software:NetBeans 7.2  ­  Apoio  ao  desenvolvimento  da  linguagem PHP, Javascript ,Ajax , Json e Jquery.PHP  ­  Linguagem  procedural  executada  no  servidor,  essencial  para  odesenvolvimento WEBFramework  CodeIgniter  ­  Utiliza  o  padrão  MVC,  fácil  apredizado  paraequipes inexperientes, além de possuir uma vasta documentação na web.Json  ­ Objeto criado  dinamicamente para comunicação  do  servidor com  ocliente de forma assíncrona.Jquery ­ Utilizado para melhorar a interação com o HTML.Javascript  ­  Utilizado  para  validações  de  campos,  funções  de  envio  de 9
  10. 10. dados e outros.Sistema  Operacional  Ubuntu  ­  Sistema  operacional de  código livre,  queserá utilizado pela equpe.Google  Docs  ­  Utilizado  para  a  documentação  das  estórias,procedimentos  para  desenvolvimento  do  sistema,  regras  de  negócio  equalquer outra documentação necessária.Dropbox  ­  Utilizado  para  armazenar  todo  o  conteúdo  necessário  para  osistema.  Formulários  do  cliente,  gravação  da  reunião   com  product  owner,protótipos , estórias e o que for necessário.Pencil  ­  Programa  utilizado  para  a  criação  de  protótipos  do  sistemabaseando­se nas estórias que forem criadas.Artisteer ­ Programa para criação de templates WEB e sistemas CMS.Gmail ­ Sistema de Email utilizado pelos integrantes do grupo.Gtalk  ­  Sistema  de  Comunicação  via  chat  quando houver necessidade dedesenvolvimento distribuído de software.RedMine  ­  Utlizado  para  gerenciar  o  projeto,  sistema  web  que  facilita  ogrupo a visualizar  suas  tarefas  especificas que cada um deve realizar, alémde  possuir  uma   opção  para  adicionar  os  bugs que  vem sendo  encontradono sistema.  Contém  também  o  gráfico  de gantt e a percentagem de tarefasrealizadas, ajudando na representação visual do projeto e seus deadlines.Subversion ­ Software SCV(Sistema de controle de versão).Apache  ­  servidor  web  livre,  utilizado  para  executar  as  página  para  osusuários via protocolo HTTP  e HTTPS.PostgreSQL ­ Serviço de banco de dados que será utilizado.pgAdmin  1.14.2  ­  Serviço  de  gerenciamento  do  banco   de  dadosPostgreSQL. 10
  11. 11. Browser  Chrome  versão  22  ou  Firefox  versão  18  ­  Utilizados  para visualizar o que foi desenvolvido. Drive  de  comunicação  do  Apache  com  o  PostgreSQL  ­  pgsql  ­  Necessário para  a  comunicação  entre  o  Apache  e  PostgreSQL,  sem  isso  o  sistema não poderá ser executado, gerando uma falha no sistema. 2.4.3 Recursos de Hardware: Computador Servidor para SVN e Redmine. Processador: Core I3. Memória RAM: 4 Gigas de RAM. HD : 320 Gigas no mínimo. Computador para desenvolvimento : Processador: Core I3. Memória RAM: 4 Gigas de RAM. HD : 320 Gigas no mínimo.3.0 ANÁLISE E GESTÃO DE RISCOS Nesta  seção  serão   tratados  os  riscos  identificados  que  precisam  sermonitorados durante o projeto.  3.1 Riscos do projeto ­ Custos associados a entrega; ­ Custos associados a um produto defeituoso; 11
  12. 12. ­ Falta da presença do cliente na definição dos requisitos;­ O  fato do cliente não oferecer suporte ao projeto;­ A equipe não tem experiência na metodologia adotada;­ Cliente e gestor ausentes;­ Requisitos vagos;­ Mudança de tecnologia;­ Falta de integração com dados do SIE;­  A tecnologia é nova para a equipe;­ Os engenheiros de software não compreendem os requisitos;­ Os engenheiros de software não tem a competência requerida;­  Uso  de  Ferramentas  de  auxílio  ao  processo  de desenvolvimento que nãoestejam integradas gerando assim mais trabalho­ Usuario com poucas habilidades;­ Uso de novos métodos em Engenharia de Software;­ Não ser estabelecido padrões de documentação e codificação;­ Falta de dedicação exclusiva da equipe. 3.2 Tabela de riscosTabela  com  os  riscos  identificados  e  a sua  probabilidade  de  ocorrência  eimpacto esperado. 12
  13. 13. Risco Probabilidade ImpactoMudança de Tecnologia 10% CatastróficoA  tecnologia  é   nova  para 50% CríticoequipeOs  engenheiros  de software 50% Críticonão  compreendem  osrequisitosRequisitos Vagos 45% CríticoCustos  associados  a 30% CríticoentregaCustos  associados  a  um 30% Críticoproduto defeituosoCliente e Gestor ausentes 30% CríticoFalta  de  Integração  dos 30% Críticodados com o SIEOs  engenheiros  de software 20% Críticonão  tem  a  competênciarequeridaFalta  da  presença  do 10% Críticocliente  na  definição  dosrequisitos Ponto de CorteO  cliente  não  oferecer 90% Marginalsuporte ao projetoFalta  de  dedicação 90% Marginalexclusiva da equipeA  equipe  não  tem 50% Marginalexperiência  na metodologiade  desenvolvimentoadotada 13
  14. 14. Uso  de  novos  métodos  em 50% MarginalEngenharia de SoftwareNão  ser  estabelecido 50% Marginalpadrões  de  documentaçãoe codificaçãoUso  de  Ferramentas  de 10% Marginalauxílio  ao  processo  dedesenvolvimento  que  nãoestejam  integradas gerandoassim mais trabalhoUsuário  com  poucas 90% Despresívelhabilidades Os  riscos  considerados  catastróficos  e  críticos  serão  gerenciados  com mais  atenção  representando  assim  o  ponto  de  corte  para  os  riscos identificados acima.  3.3 Redução e Gestão do Risco   Selecionados  oito  riscos de  maior  impacto  e  probabilidade, para  serem levantados  as  respectivas  atividades  de  redução,  supervisão  e  gestão  de riscos: Risco:  Mudança  de Prob: 10% Impacto: Catrastrófico TecnologiaDescrição:  Durante  a  construção  do  sistema  pode  haver  a  necessidade  de mudança  de  tecnologia  de  desenvolvimento  devido  as  restrições  de manutenção e implantação do sistema. 14
  15. 15. Estratégia  de  redução:  Validação  com  o  cliente  a  respeito  do  ambiente  em que  o sistema final  irá rodar  bem  como  saber  quais os conhecimentos  e limitações  de  tecnologia da pessoas  que farão a manutenção do sistema após construído e implantado.Plano  de  Contigência:  Buscar  pessoas   capacitadas  na nova  tecnologia  para apoiar  o  desenvolvimento  do  sistema  na  nova  tecnologia  o  mais  rápido possível.Responsável: Toda a equipe.Status: Não ocorrido. Risco:  A  tecnologia   é Prob: 50% Impacto: Crítico nova para equipe;Descrição:  Durante  o  inicio  do projeto ao realizar  a  organização  da  equipe  do projeto.  O grupo na reunião,  verifica  que possui  um  carência com a nova tecnologia utilizada para o desenvolvimento deste sistema.Estratégia  de  redução:  Compra   de  documentação  necessária  para  o aprendizado dos membros, e a  busca de cursos para ajuda nos estudos.Plano  de  Contigência:  Caso  algum  ciclo  de uma  sprint  já esteja  realizado  , o Scrum  master  deve  diminuir  a  quantidade  de  tarefas  que  devem  ser realizadas  para  esta  pessoa que tem muita carência de conhecimento da nova  tecnologia,  e  procurar  algum  membro  do  grupo  que  tem  um  maior experiência com a tecnologia para ajudar nesta necessidade.Responsável:  Toda a equipe.Status: Ocorrido. 15
  16. 16. Risco:  Os  engenheiros Prob: 50% Impacto: Crítico de  softwares  não compreendem  bem  os requisitos;Descrição:  Após  a  análise  dos  requisitos  com  o  cliente,  os  engenheiros  de software  que  efetuaram  esta, possuem dificuldades  em compreender de como deve ser desenvolvido e modelado o sistema.Estratégia  de  redução: Procurar  os engenheiros de software mais experientes com  a  analise dos requisitos. Uma  vez  a  análise feita,  deve ser realizado um  levantamento  dos  requisitos  e  outra  reunião  com  o  cliente  para  que possa  mostrar  quais  requisitos  são  necessários  e  quais  deveriam  ser incluídos na lista.Plano  de  Contigência:  Utilização  de  protótipos  das  tela  para  o  cliente, podendo ser realizado ao punho livre ou mockups.Responsável:  Toda a equipe.Status: Não ocorrido. Risco:Requisitos vagos Prob: 45% Impacto: críticoDescrição:  Requisitos  dos  sistema  mal  definidos  pelo  cliente  e/ou  pouco compreendidos  pelos engenheiros de  software do projeto bem como falta de  definição  de  regras  de  negócio  dificultando  ainda  mais  o desenvolvimento  do  sistema  para  atender  as  exigências  estabelecidas pelo cliente.Estratégia  de  redução:  Prototipação  e  reuniões  constantes  com  os stakeholders  do   projeto  bem  como  fazer  uma  análise  do  processo  em que  o  sistema será inserido ou estudando  documentações  referentes  ao domínio do problema. 16
  17. 17. Plano  de  Contigência:  Buscar  nas  próximas  iterações  do  projeto  definir melhor os requisitos  e  validar­los  com  os  stakeholders  do sistema. Fazer reuniões  imediatas  com  o  cliente  para  poder  sanar  tal  problema  e diminuir o impacto.Responsável: Toda a equipe.Status: Ocorrido. Risco:Custos Prob: 30% Impacto: Crítico associados a entrega.Descrição:  O  risco  está  associado  a  não  entrega  do  produto  no  período combinado  com  o  cliente,  podendo  gerar assim  custos associado a isso como prejuízos para a equipe.Estratégia  de  redução:  Reuniões  diárias  com  a  equipe   para  saber  o andamento  do projeto,  e  se  houver  algum impedimento  buscar  resolver o mais  rápido  possível.  Buscar  seguir  o  planejamento  feito  em  cada iteração do projeto.Plano  de  Contigência:  Aceitar  o  atraso  e  buscar  negociar  com o cliente  um meio de  diminuir  os  impactos  associados  ao  atraso na entrega para que nenhuma das partes saia prejudicada, principalmente o cliente.Responsável:  Toda a equipeStatus: Não ocorrido. Risco:  Custos Prob: 30% Impacto: Crítico associados  a  um  produto defeituoso; 17
  18. 18. Descrição:  O  risco  diz  respeito  a  entrega de  um produto ou de um incremento que  não  atenda  completamente  ao  que  foi  negociado,  ou  não atenda as necessidades do cliente.Estratégia  de  redução:  Buscar  manter  o  cliente  o  mais  próximo  possível  do desenvolvimento,   e  haver  constantes  reuniões  de  apresentação  e validação do  que  está  sendo  feito  , para que  o  cliente  entenda  e  diga  se isso está ou não de acordo com suas necessidades.Plano  de Contigência: Se ocorrer em uma iteração do sistema que não seja a ultima,  o  que deve  ser feito é a correção  da parte  defeituosa  no próximo incremento. Acelerar o Processo de desenvolvimento da próxima iteração para  conseguir  corrigir  esse  erro  e  não  atrasar  o andamento do projeto. Se  acontecer  na  ultima  entrega  do  sistema,  negociar  com o  cliente uma nova iteração para a correção do erro em questão.Responsável:  Toda a equipeStatus: Não ocorrido. Risco:  Cliente  e  gestor Prob: 30% Impacto: crítico ausentes.Descrição:  Durante   os  processo  de  desenvolvimento  do  software  ambos stakeholders não  estiverem presentes  para  resolver  as dúvidas e auxiliar na gestão.Estratégia  de  redução:  Encontrar  diversas  formas  de  comunicação  com ambos  para  que  sempre  seja  realizada  essa  interação,  sem a perda  de contatoPlano  de  Contigência:  Formalizar o contato com os stakeholders por meio de documentação formal. 18
  19. 19. Responsável: Scrum Master Status: Ocorrido. Risco:  Falta  de Prob: 30% Impacto: Crítico. integração  com  dados do SIE; Descrição:  Na  última  etapa  de  desenvolvimento  do  sistema,  não  ser  possível realizar a integração dos sistemas Estratégia  de  redução: Buscar  desenvolver a estrutura do  banco  de dados  do sistema  de  forma  similar  à  utilizada  pelo  SIE,  realizar  esta  integração o mais rápido possivél. Plano  de  Contigência:  Acessar  a  base   dados  existente  por  meio  de Web­Service. Responsável:  Toda a equipe. Status: Não ocorrido.4.0 PLANEJAMENTO TEMPORAL Aqui  são  apresentadas  as  tarefas  do  projeto  e  suas  dependências  bemcomo  o  planejamento  temporal  feito para cada uma dessas tarefas e como ficou oplanejamento do projeto.  4.1 Conjunto de Tarefas do Projeto Como apresentado na  seção  2.4.1 desse  documento, o projeto será 19
  20. 20. desenvolvido  utilizando  a  metodologia  de  desenvolvimento  ágil  conhecidacomo  SCRUM,  tal  metodologia  trabalha  com  entregas  parciais  eincrementais  do  sistema em iterações chamadas sprints.  A equipe planejaque  o  projeto   seja  desenvolvido  em  5  sprints,  sendo que  a  primeira  sprintchamada  de  sprint  0  é  uma  sprint  de  configuração,  planejamento  edefinições  para  a  continuidade do  projeto. A partir  da sprint 1 até a sprint 4o  clico  de  atividades  é  o  mesmo,  portanto  abaixo  é  listado  apenas  asmacro  atividades  das  sprints  0  e  1. Cada macro  atividade  é  composta porsubatividades  que  não  serão  descritas  nessa  seção  no  entanto é possívelidentificá­las na próxima seção através do diagrama de Gantt.As atividades são as seguintes: ○ Sprint 0: ■ Planejamento  do  Projeto  em  Geral:  Essa  atividade  diz respeito  do  planejamento  inicial  do  projeto,  aqui  é  feito  a reunião  inicial  com  o   cliente,  a  definição  do  escopo  do sistema,  definição  do  Product  Backlog  bem  como  a definição  dos  papéis  dos  membros  da  equipe  em  cada iteração do projeto e a rotatividade desses papéis. ● Gestão  de  risco  do  projeto:  A  gestão  de  risco  do projeto  é  uma  das  subatividades  do  Planejamento  do projeto  em  geral,  esta  é  uma  subatividades  divididas em  outras atividades menores.  Aqui  é  feito a  definição dos riscos do  projeto  e  um  planejamento  de  mitigação e contingência para os riscos identificados. ■ Configuração  do  ambiente  de  desenvolvimento:  Essa  macro atividade  é  dividida  em  configurar  e  definir  quais  serão  as tecnologias  utilizadas  no  projeto, a ambientação, treinamento e  configuração   das  ferramentas.  Além  da  configuração  do ambiente  está  inserido  aqui  também  atividades  de 20
  21. 21. treinamento  e  estudo  a  respeito  das  tecnologias  definidas para o projeto. ● Definição  das   tecnologias  e  ferramentas  utilizadas: Essa  macro  atividade  diz  respeito  em  definir  a tecnologia  de desenvolvimento de software, ferramenta de  gerenciamento  de  projeto,  ferramenta  de  controle de versão,  definição do SGBD, ferramenta para testes, hardwares utilizados.○ Sprints 1,2,3 e 4 ■ Planejamento  e  análise  da  sprint:  cada   uma  das  4  sprints precisa de  um planejamento que  norteará as atividades feitas nessa  sprint.  Esse  planejamento  da  sprint  depende  do planejamento  geral feito na sprint 0 e do  sucesso  das sprints anteriores.  As  subatividades  relacionadas  são  atividades como  reunião   de  planejamento  da  sprint,  definição  do  sprint backlog,  reunião  com  o  product  owner  para  a  validação  da sprint backlog entre outros. ● Análise  e  projeto  da  sprint:  Um  das  subatividades  do planejamento  da  sprint  é a análise  e  projeto  da  sprint. Nessa  etapa  da  sprint  são  feitas  as  descrições  das estórias  dos usuários, criação dos diagramas UML e  a modelagem  do  banco  de  dados  relacionado  a  sprint em  questão.  Nessa  etapa  incluem­se  também atividades  de  reunião  de  apresentação  dos  modelos criados  para  os   desenvolvedores  e  se  necessário inspeções  dos artefatos  de software  produzidos nessa etapa  bem  como  o  versionamento  de  tudo  o  que  foi feito até o momento na sprint. ■ Codificação:  A  atividade  de  codificação  não  precisa  de  um 21
  22. 22. detalhamento  maior  por  conta  de  se  entender  que nessa fase é  feita  a  construção  do  produto  que  será  entregue  na  sprint, esta  possui  algumas  subatividades  relacionadas  tais  como: produção  de   protótipos para as estórias,  codificação  dessas estórias,  testes  de  unidade  e  o  versionamento  dos  artefatos produzidos durante essa fase da sprint.■ Testes:  Esta  atividade  engloba:  as  criações  dos  recursos necessários  para  a  execução  dos  testes  como  os  casos  de teste  para  as  estórias  da  sprint  e  os  scripts  de  teste.   Além disso  esta  inserido  nesta  atividade  a  execução  dos  testes e por  fim  a  documentação  dos  bugs encontrados na execução dos testes. Esta atividade ocorre nas quatro sprints. ● Retrabalho:  Esta  subatividade  constitui­se   das correções  dos  bugs  reportados  nos  testes,  da execução  dos  testes  de  regressão,  que  são os testes realizados  após  as  correções  feitas  e  por  fim  do versionamento  dos  artefatos  produzidos  na  atividade de testes.■ Finalização  e  entrega  do  produto  produzido  na  sprint:  Esta macro  atividade   refere­se  as  reuniões  de  finalização  e  de retrospective  da  sprint  além  do  versionamento,  apresentação e configuração do produto produzido. 22
  23. 23. 4.2 Diagrama de Gantt O  Diagrama  de  Gantt (em  anexo ao projeto de  software)  detalha asatividades planejadas para o projeto. No  diagrama  são  descritos  o  nome das atividades,  a  estimativa  deduração  para  cada  uma  delas,  a  data  de  início  e  fim,  qual(is) atividade(s)predece(em)  cada  atividade  e  o(s)  responsável(is)  por   cada  uma  dastarefas descritas no documento. 23
  24. 24.  5.0 ORGANIZAÇÃO DO PESSOAL Na  seção  2.4.1  desse  documento  é  apresentada  a  metodologia dedesenvolvimento  em  que  o  projeto de software  está  inserido, ali é possívelidentificar  que  será  adotado  o  SCRUM  como  metodologia.  Foi  possívelentender  o  papel  de  cada  um  dos  componente  da  equipe  no  projeto,  noentanto  não  foi  identificado  em  que  momento  cada  um  componente  daequipe  assumiria   qual  papel  durante  o  processo  de  desenvolvimento,abaixo  é  descrito  como  acontecerá  a  rotatividade  dos  membros  e  seusrespectivos papéis em cada uma das sprints do SCRUM.5.1 Estrutura da equipaSprint 1 ○  Scrum Master : Alison Lemos ○ Programador 1: Janiel Medeiros ○ Programador 2 : Kirmayr Tomaz ○ Testador: Urique HoffmannSprint 2: ○  Scrum Master : Kirmayr Tomaz ○ Programador 1: Urique Hoffmann ○ Programador 2 : Alison Lemos ○ Testador:Janiel MedeirosSprint 3: ○  Scrum Master :Urique Hoffmann ○ Programador 1: Janiel Medeiros ○ Programador 2 : Kirmayr Tomaz ○ Testador:Alison LemosSprint 4: ○ Scrum Master : Janiel Medeiros 24
  25. 25. ○ Programador 1:Urique Hoffmann ○ Programador 2 : Alison Medeiros ○ Testador:Kirmayr Tomaz 5.2 Mecanismos de comunicação A  equipe  utiliza  como meios  de  comunicação  diversas  ferramentas.Além  da  comunicação face a face que é  feita diariamente em reuniões queacontecem, a equipe utiliza redes sociais  como o  Facebook e o Google+  ,chats  na  web  como   o  Google  Talk,  telefones  e   algumas  ferramentas  alémdessas.  As  ferramentas  adicionais  utilizadas  são:  Google  Drive,  utilizadopara  compartilhar  arquivos,  e  o  Redmine,  uma  ferramenta  degerenciamento que a  equipe  utiliza para o acompanhamento do andamentodas  atividades  realizadas  e  onde  é  registrado  o  Daily  Meeting,  a  reuniãodiária  que  a  equipe  faz  seguindo  os  padrões  do  processo   SCRUM  ondesão respondidas  três questões básicas,  são  elas: O  que  eu fiz hoje? O quevou  fazer  amanhã?  Existe  algum  impedimento para realização das minhasatividades?5.3 Uso do Edu­blog como ferramenta de apoio O  uso  do  Edu­blog  pode  ter  algumas  interações:  A  facilidade  deaprendizado  de  determinados  assuntos  encontrados  em  outros  blogsadjacentes. Uma forma  também  de compartilhar os assuntos para o públicogeral,  sem  a  necessidade  de  algo  complicado  e  de  difícil  acesso  eauxiliando também na comunicação entre o professor e o aluno. Facilidade  para  encontrar  o  material  da  disciplina,  documentosantigos,  turmas  que  já  realizaram  a  disciplina  e  assim  um  ponto  dereferência  para  qual  caminho  devemos  seguir  e  que  melhorias  devemostomar com estes aprendizado. 25
  26. 26. 6.0  PRECAUÇÕES  TOMADAS  PARA  ASSEGURAR  ECONTROLAR A QUALIDADE DO PRODUTO DE SW É  realizado  um  acompanhamento  para  assegurar  e  controlar  asatividades  que  estão  sendo  executadas  no  projeto,  tais  serão  descritasbaixo:Revisões Técnicas Formais As  revisões  formais  existentes  são  as  revisões  técnicas,  inspeção,walkthrough  e  revisões  gerenciais.  No  contexto  do  SCRUM  optamos  poralgo  que  seja  rápido,  e  ajude  na  qualidade  do  produto.  De  forma  que  seráutilizada  a  técnica  de  revisões  gerenciais ,  realizada  em  cada sprint  quenecessite  da  atualização  da  documentação  dos  requisitos  do  sistema,  ouseja, em  cada sprint o sistema passará pôr uma revisão gerencial com focoda garantia desta qualidade .Gestão de Configuração do SW A  cada  sprint  o  sistema   passa  por  um  controle  de  versão  dasestórias do sistema, casos de teste e da codificação.Produção de Documentação Para  o  controle  de  qualidade  do  processo  de  desenvolvimento,  foielaborada documentação nas etapas de Análise, Projeto e Teste.Registro de Atividades Com  registro  das  atividades  por  meio  de  um  software  de  gerênciade  Projetos(Redmine)  ,consegue  assim,  por  meio  desta,  estabelecer  as 26
  27. 27. atividades e o status de execução destas.Análise de Riscos Identificação,  análise  e controle dos riscos, elaborando­se planos deredução e de contingência, conforme citádo no capítulo 3 deste documento.Testes Após  toda  a   análise  do  que  será  realizado  pelo  sistema.  Serádefinido  alguns  critérios  da  realização  do  teste  de  software.  Na forma  queterá  a  cada  sprint  um   planejamento  dos  tipos  de  teste  que  devem  serrealizado  em  cada  sprint,  em  que  ponto  os  testes  são  necessários  parar,dependendo  do  que  o  cliente  solicitou  assim  como  os  testes  caixa  pretaque serão executados no  sistema. Casos de teste, procedimentos de teste,testes de integração  também serão realizados. 27

×