Your SlideShare is downloading. ×
Apresentação1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Apresentação1

114

Published on

Apresentação

Apresentação

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
114
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ANÁLISE DE ATENDIMENTO ÀS ÁREAS DE PROCESSO CMMI – NÍVEL 2 Departamento de Gestão de Tecnologia da Informação
  • 2. Equipe • Amilton Luiz • Hugo Magalhães • Lucas Fábio • Márcia Maria • Rhaissa Santos • Rodrigo Venâncio • Tamires Guedes
  • 3. Revisão • Áreas do processo CMMI Nível 02: • Planejamento de Projeto - PP • Acompanhamento e Controle de Projeto – PMC • Gerenciamento de Requisitos - REQM • Gerência de Configuração - CM • Gerenciamento de Acordo com Fornecedor - SAM • Medição e Análise – MA • Garantia da Qualidade de Processo e Produto – PPQA
  • 4. Metodologia • Entrevista com Gestor de TI • 04 entrevistadores • 49 perguntas • Cada integrante da equipe analisa uma área
  • 5. Planejamento de Projeto (Rhaissa) Primeiro há um contato com o cliente para verificar a complexidade, os requisitos, o escopo e o tempo necessário para desenvolver o projeto. O planejamento é composto pela definição de objetivos e todos os passos que devem ser tomados para que seja possível realizá-los. Por isso, esta etapa é tão importante para criar, gerenciar, executar e controlar qualquer projeto, permitindo que estes sejam executados com êxito.
  • 6. Planejamento de Projeto (Rhaissa) O projeto é repassado para a equipe de desenvolvimento, e de acordo com a demanda e/ou complexidade é definido se o mesmo será desenvolvido em equipe ou individualmente. O plano de ação utilizado é o PDTI juntamente atrelado ao PPI, instrumentos que a instituição tem para estabelecer metas que devem ser atingidas durante o ano.
  • 7. Planejamento de Projeto (Rhaissa) As metas são estabelecidas de acordo com o grau de dificuldade do software, da linguagem escolhida e a expertise da equipe. Metas sempre documentadas O acompanhamento do projeto é feito pelo dotProject. E “grande” parte dos softwares desenvolvidos são documentados.
  • 8. Planejamento de Projeto (Rhaissa) A definição de prazos é novamente de acordo com a complexidade do projeto, e a expertise dos recursos humanos disponíveis. Normalmente não há gestão de custo para os projetos desenvolvidos. As estimativas são para aquisição de produtos ou serviços. A responsabilidade é compartilhada entre o cliente, e a equipe.
  • 9. Planejamento de Projeto (Rhaissa) • O método utilizado para planejar os projetos é o SCRUM. Em relação a renegociação de prazo e equipe envolvida no desenvolvimento, o gerente de projeto fala diretamente com o solicitante, se não houver um acordo o repasse é para o Diretor Geral do Campus. Se ocorrer redução de recursos é levado em conta as prioridades dos projetos que o departamento tem no momento.
  • 10. Acompanhamento e Controle de Projeto (Márcia) • Para gerenciar a realização das tarefas é utilizada a ferramenta dotProject®. As tarefas a serem desenvolvidas para que as metas sejam atingidas são definidas pela própria equipe de desenvolvimento com base na análise feita através do levantamento de requisitos, tendo a equipe características de liberdade e autogerenciamento nesses aspectos.
  • 11. Acompanhamento e Controle de Projeto • Sempre há reuniões realizadas regularmente entre a equipe de desenvolvimento e gerente do projeto. • Sempre são tomadas ações corretivas quando os resultados diferem significativamente dos planos de software do projeto e o profissional responsável por acompanhar o andamento dos projetos é o próprio gerente de projetos.
  • 12. Gerenciamento de Requisitos (Rodrigo) • O projeto começa com o “project charter” (termo de abertura do projeto),que é o documento que autoriza formalmente o projeto. • Ele concede ao gerente do projeto a autoridade para utilizar os recursos da organização na execução das atividades do projeto. • O mesmo é utilizado para registrar os requisitos.
  • 13. Gerenciamento de Requisitos (Rodrigo) • Mesmo que o sistema seja muito simples, é importante ter algo documentado o mínimo de informações sobre o sistema, pois caso houver alguma mudança apos algum tempo, a equipe atual não iniciar a mudança sem nenhuma informação. Primeiro é feita uma reunião com o solicitante pra coleta de informações (requisitos) e é entrado em contato com o cliente sempre quando necessário. Todos os requisitos são documentados em um modelo de documento padrão, mas quando o sistema é pra própria DGTI ou é algo muito simples não há documentação.
  • 14. Gerenciamento de Requisitos (Rodrigo) • Seria importante ter alguma ferramenta que monitorasse a mudança dos requisitos: se, no futuro esses requisitos forem os mesmos num outro projeto e sendo os mesmos cadastrados, não seria perdido o tempo de desenvolver algo que vai ser mudado no futuro. As mudanças de requisitos são sempre documentadas e são sempre realizadas quando há realmente a necessidade de mudança. Os documentos mudam, o projeto muda. Além de que não existe um documento ou forma de monitorar as mudanças de requisitos. Quando alguma coisa é necessária ser mudada é feita uma reunião com o cliente para que a responsabilidade seja compartilhada.
  • 15. Gerência de Configuração (Amilton) • definição : Gerência de Configuração de Software é uma área da engenharia de software responsável por fornecer o apoio para o desenvolvimento de software. Suas principais atribuições são o controle de versão, o controle de mudança e a auditoria das configurações.
  • 16. Gerência de Configuração (Amilton) • definição por Roger Pressman : conjunto de atividades projetadas para controlar as mudanças pela identificação dos produtos do trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes versões destes produtos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas.
  • 17. Gerência de Configuração (Amilton) • Gerência de Configuração de Software tem como objetivo responder as seguintes perguntas: • O que mudou e quando? • Por que mudou? • Quem fez a mudança? • Podemos reproduzir esta mudança? • Quem fez a mudança e podemos reproduzir a mudança?
  • 18. Gerência de Configuração (Amilton) • O que mudou e quando? CM03 – Existe um profissional designado especialmente para tratar das questões relacionados à gerência de configuração dos projetos? [X] Sim. Qual? [ ] Não R. Usamos SVN e os documentos já citados. CM04 – É realizado controle de versão? [X] Sim. Como? [ ] Não R. Usamos SVN
  • 19. Gerência de Configuração (Amilton) • Por que mudou? CM02 – Existe um processo para controlar as solicitações de mudança feitas pelo cliente? (change request) [X] Sim. Descreva [ ] Não R. Temos um procedimento, mas não algo rígido, que toda mudança deve seguir. Temos um modelo de solicitação de mudança.
  • 20. Gerência de Configuração (Amilton) • Quem fez a mudança? CM02 – Existe um processo para controlar as solicitações de mudança feitas pelo cliente? (change request) [X] Sim. Descreva [ ] Não R. Temos um procedimento, mas não algo rígido, que toda mudança deve seguir. Temos um modelo de solicitação de mudança. CM03 – Existe um profissional designado especialmente para tratar das questões relacionados à gerência de configuração dos projetos? [X] Sim. Qual? [ ] Não R. Usamos SVN e os documentos já citados.
  • 21. Gerência de Configuração (Amilton) • Podemos reproduzir esta mudança? CM03 – Existe um profissional designado especialmente para tratar das questões relacionados à gerência de configuração dos projetos? [X] Sim. Qual? [ ] Não R. Usamos SVN e os documentos já citados. CM05 – É utilizada alguma ferramenta para gerenciar testes? [ ] Sim. Qual? [X] Não R. Temos a intenção de utilizar o Test Link.
  • 22. Gerenciamento de Acordo com Fornecedor (Tamires) • Uma entidade que entrega produtos ou executa serviços que estão sendo adquiridos • Um indivíduo, sociedade, companhia, corporação, associação ou outro serviço que tem um acordo (contrato) com um adquirente para o projeto, desenvolvimento, manufatura, manutenção, modificação ou fornecimento de itens sob os termos de um acordo (contrato) • O propósito da Gestão de Acordo com Fornecedores é gerenciar a aquisição de produtos de fornecedores.
  • 23. Gerenciamento de Acordo com Fornecedor (Tamires) • Determinação do tipo de aquisição que será utilizado para os produtos a serem adquiridos • Seleção de fornecedores • Estabelecimento e manutenção de acordos com fornecedores • Monitoramento de processos selecionados de fornecedores • Avaliação de produtos de trabalho selecionados de fornecedores • Execução do acordo com fornecedores • Aceitação da entrega de produtos adquiridos • Transição dos produtos adquiridos para o projeto
  • 24. Gerenciamento de Acordo com Fornecedor (Tamires) • A Lei de Licitações e Contratos, Lei Federal nº 8.666/93, prevê, nas entrelinhas de seus artigos, que o Administrador Público deve organizar e implantar em órgãos públicos um sistema de gestão de contratos, compreendendo o gerenciamento, o acompanhamento e a fiscalização da execução até o recebimento do objeto SAM03 – Como é feito o acompanhamento de execução de tarefas dos fornecedores? R. O setor de compras e licitação da escola é responsável por isso.
  • 25. Gerenciamento de Acordo com Fornecedor (Tamires) • É importante o gestor de tecnologia se apropriar dos trâmites para contratação de fornecedores • Como elicitar os requisitos da contratada? • Como acompanhar a execução do serviço ou entrega do produto? • Reportar regularmente ao setor de compras as necessidades do setor?
  • 26. Gerenciamento de Acordo com Fornecedor (Tamires) • Tarefas importantes • Listar prioridades e registrá-las junto aos gestores de compras da unidade organizacional • Estabelecimento de subrotinas de controle dos contratos • Elaborar instrumentos de transparência das contratações para a população • Buscar formação para a equipe
  • 27. Medição e Análise (Lucas) • Pontos a serem analisados: • Há monitoramento do desempenho das equipes; • A empresa conhece o andamento de seus projetos.
  • 28. Medição e Análise (Lucas) • Erros não são devidamente documentados: • Falta de controle de frequência de erros; • Falta de visão geral dos problemas ao longo do desenvolvimento; • Impossibilidade de gerar relatórios de erro com boa quantidade de detalhes; • Impossibilidade de analisar erros estatisticamente; • Impossibilidade de prever falhas no projeto; • A falta de documentação pode ocasionar retrabalho e atrasos em outros projetos causados por erros já solucionados pela equipe, já que não há quantitativo que ajude a orientá-los na busca por soluções;
  • 29. Medição e Análise (Lucas) • As análises de acompanhamento não foram bem definidas pela empresa: • Acompanhamento feito em formato de testes de software? • Não há medição da eficiência e eficácia da equipe; • O gerente de projeto acompanha devidamente o andamento dos projetos desenvolvidos pela empresa;
  • 30. Medição e Análise (Lucas) • A empresa analisa a viabilidade de seus projetos: • Informalidade; • Falta de documentos que atestem a veracidade da viabilidade do projeto;
  • 31. Garantia de Qualidade de Processo e Produto (Hugo) O proposito da Garantia de Qualidade de processo e Produto é prover aos especialistas e à gerencia com percepção objetiva dos processos e produtos de trabalhos associados.
  • 32. Garantia de Qualidade de Processo e Produto (Hugo) • Envolve: • Objetivamente Avaliar o desemprenho do processo, produtos de trabalho e serviço frente aos processos, padrões e procedimentos aplicáveis. • Identificar e documentar tópicos/questões não cumpridos. • Prover com visibilidade adequada e feedback os gerentes e membros dos projetos com resultados das atividades de garantia de qualidade. • Garantir que os tópicos/questões sejam adequadamente tratados
  • 33. Garantia de Qualidade de Processo e Produto (Hugo) • Requisitos do CMMI para o PPQA • Estabelecer uma Politica Organizacional • Planejar o Processo • Prover recursos • Designar responsabilidades • Treinar as pessoas • Gerenciar a configuração • Identificar e envolver os stakeholders relevantes • Monitorar e controlar o processo • Avaliar a aderência objetivamente • Analisar criticamente o status com a alta gerencia
  • 34. Garantia de Qualidade de Processo e Produto (Hugo) • PPQA07 – É utilizada alguma ferramenta de automatização de testes? [ ] Sim, em todos os projetos [ ] Sim, em alguns projetos [X] Não • Uma ferramenta de testes facilitaria a identificação e correção de erros, sendo assim minimizaria futuras correções após o sistema ser entregue ao cliente.
  • 35. ANÁLISE DE ATENDIMENTO ÀS ÁREAS DE PROCESSO CMMI – NÍVEL 2 Departamento de Gestão de Tecnologia da Informação

×