apresentação1

35
ANÁLISE DE ATENDIMENTO ÀS ÁREAS DE PROCESSO CMMI – NÍVEL 2 Departamento de Gestão de Tecnologia da Informação

Upload: tamires-guedes

Post on 09-Dec-2014

264 views

Category:

Documents


0 download

DESCRIPTION

Apresentação

TRANSCRIPT

Page 1: Apresentação1

ANÁLISE DE ATENDIMENTO ÀS ÁREAS DE PROCESSO CMMI – NÍVEL 2Departamento de Gestão de Tecnologia da Informação

Page 2: Apresentação1

Equipe• Amilton Luiz• Hugo Magalhães• Lucas Fábio• Márcia Maria• Rhaissa Santos• Rodrigo Venâncio• Tamires Guedes

Page 3: Apresentação1

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

Page 4: Apresentação1

Metodologia• Entrevista com Gestor de TI• 04 entrevistadores• 49 perguntas• Cada integrante da equipe analisa uma área

Page 5: Apresentação1

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.

Page 6: Apresentação1

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.

Page 7: Apresentação1

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.

Page 8: Apresentação1

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.

Page 9: Apresentação1

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.

Page 10: Apresentação1

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.

Page 11: Apresentação1

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.

Page 12: Apresentação1

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.

Page 13: Apresentação1

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.

Page 14: Apresentação1

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.

Page 15: Apresentação1

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.

Page 16: Apresentação1

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.

Page 17: Apresentação1

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?

Page 18: Apresentação1

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

Page 19: Apresentação1

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ãoR. Temos um procedimento, mas não algo rígido, que toda mudança deve seguir. Temos um modelo de solicitação de mudança.

Page 20: Apresentação1

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ãoR. 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ãoR. Usamos SVN e os documentos já citados.

Page 21: Apresentação1

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ãoR. Usamos SVN e os documentos já citados.

CM05 – É utilizada alguma ferramenta para gerenciar testes?[ ] Sim. Qual?[X] NãoR. Temos a intenção de utilizar o Test Link.

Page 22: Apresentação1

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.

Page 23: Apresentação1

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

Page 24: Apresentação1

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.

Page 25: Apresentação1

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?

Page 26: Apresentação1

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

Page 27: Apresentação1

Medição e Análise (Lucas)• Pontos a serem analisados:

• Há monitoramento do desempenho das equipes;• A empresa conhece o andamento de seus projetos.

Page 28: Apresentação1

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;

Page 29: Apresentação1

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;

Page 30: Apresentação1

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;

Page 31: Apresentação1

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.

Page 32: Apresentação1

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

Page 33: Apresentação1

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

Page 34: Apresentação1

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.

Page 35: Apresentação1

ANÁLISE DE ATENDIMENTO ÀS ÁREAS DE PROCESSO CMMI – NÍVEL 2Departamento de Gestão de Tecnologia da Informação