Tec. Em Analise e desenvolv. De Sistemas Análise e projeto de sistemas Aula 13

1. Tec. Em Analise e desenvolv. De SistemasAnálise e projeto de sistemas Aula 13 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

2. AGENDA GERENCIAMENTO DE PROJETOS Tecnicas e conhecimentos (PMI) Testes de software & Qualidade CMM / CMMI Bibliografia Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

3. Questões importantes Por que as organizações usam gerenciamento de projetos ? • O que é um projeto ? • O que Gerenciamento de Projetos ? • Quais são os principais papéis desempenhados em um projeto e como eles se inter-relacionam ? • Quais são os principais elementos de um projeto e como eles se inter-relacionam ? • O que é o corpo de conhecimento de gerenciamento de projetos ? Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

4. Por que as organizações usam Gerenciamento de Projetos ? Melhor comunicação entre os participantes do projeto Melhor compreensão sobre o projeto e seus objetivos Capacidade de definir e controlar o escopo do projeto Capacidade de identificar, monitorar e acompanhar os marcos do projeto Projeção correta das necessidades de recursos Melhor avaliação e mitigação dos riscos do projeto Capacidade e mecanismos para medir a performance Identificação e comunicação das áreas de problemas Esclarecimento e alinhamento com os objetivos da organização Priorização das atividades funcionais e do projeto Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

5. O que é um Projeto ? Um projeto é um esforço temporário empreendido para criar um produto ou serviço único Os gerentes de projeto devem identificar e aprender sobre as similaridades dos projetos Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

6. O que é Gerenciamento de Projetos ? As atividades tipicamente envolvem: Demandas exigentes para : escopo, tempo, custo, riscos, qualidade Interessados no projeto com necessidades e expectativas diferentes Requisitos identificados e muitas vezes evolutivos A aplicação de técnicas, habilidades, ferramentas e técnicas às atividades do projeto para atender os requisitos do projeto Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

7. Quais são os principais papéis em um projeto ecomo eles se inter-relacionam ? Gerentes Funcionais Gerente Projeto Patrocinador Participantes do projeto Membros da equipe Interessados Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

8. Quais são os elementos principais de um Projeto como eles se inter-relacionam ? Como e quanto tempo será necessário para gerar os produtos? ESCOPO TEMPO O que estamos entregando QUALIDADE Seguindo quais padrões de qualidade estamos produzindo os resultados ? CUSTO O quão seguros estamos das condições e eventos que envolvem o projeto e que conseguimos completa-lo de acordo com o planejado ? Quem é necessário para completar o projeto ? Quanto precisamos de cada recurso ? Quanto custará cada recurso ? Membros da equipe Interessados RISCOS Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

9. Interessados no Projeto Clientes Usuários finais Acionistas Departamentos de suporte e manutenção Representantes de serviços a clientes Grupo de pessoas e/ou corporações envolvidas no projeto ou afetadas pelas atividades do projeto Qualquer um que tenha algum interesse... • Departamentos de produção e operação • Membros da equipe do projeto • Patrocinadores • Gerentes funcionais • Gerentes de projeto Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

10. O que é o Corpo de Conhecimento emGerenciamento de Projetos ? O PMBOK é um termo abrangente e que descreve a soma de conhecimentos inerentes à profissão de gerenciamento de projetos. Como em muitas outras profissões, o corpo de conhecimento depende dos praticantes e estudiosos para aplicá-lo e evoluí-lo. O corpo de conhecimento completo abrange práticas já aprovadas e de uso comum, além de outras inovadoras e avançadas, que possam até ter sido menos utilizadas. Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

11. O que é o Guia do Corpo de Conhecimentoem Gerenciamento de Projetos ? Identifica a descreve o sub-sistema do corpo de conhecimento em gerenciamento de projetos que é geralmente aceito Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

12. O que é o Guia do Corpo de Conhecimentoem Gerenciamento de Projetos ? Identifica a descreve o sub-sistema do corpo de conhecimento em gerenciamento de projetos que é geralmente aceito Conhecimentos e práticas aceitas para Gerenciamento de Projetos São conhecimentos e práticas aplicáveis na maioria dos projetos de todos os tipos Há um consenso geral sobre os seus valores e benefícios Conhecimentos necessários para executar o projeto na sua area específica (industrial, técnica, serviços, construção, etc)‏ Conhecimentos e práticas das Áreas de Conhecimento Conhecimentos e práticas de Gerenciamento É composto pelo planejamento, organização, recrutamento, execução e controle das operações da empresa Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

13. Grupos de processos e áreas de conhecimento Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

14. Processo baseado em PMI • Exemplo de processo Praxis (Desenvolvimento de software) • Gestao de Projetos tem quatro atividades principais: • Planejamento de Projeto • Controle de Projeto • Resolução de Problemas • Aquisição Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

15. Processo baseado em PMI • Ativação do Projeto • Ações necessarias para começar : Dados iniciais, lista de funções, beneficios esperados • Planejamento preliminar • Determinar viabilidade atraves de estimativa alto nivel de tamanho, custos esforços e prazos • Planejamento Geral do Projeto • Visa o escopo do projeto, equipe, recursos tecnicos, custos, prazos, tratamento de riscos Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

16. Processo baseado em PMI • Controle de Projeto • Gestão detalhada • Gerir dia a dia das tarefas • Retrospectiva • Reunião para revisão de problemas, pontos positivos e proposição de resolução • Relato • Criar e manter relatorio do projeto para acompanhamento executivo. Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

17. Processo baseado em PMI • Resolução de problemas • Identificação • Análise • Negociação • Execução de ação • Verificação de resolução Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

18. Testes & Qualidade de Software Validação e Qualidade estão profundamente relacionados. Validação objetiva garantir aderencia aos requisitos, inexistencia de erros, confiabilidade, disponibilidade ou seja muito mais do que achar erros através de testes Qualidade Satisfazer especificações Assegurar fácil manutenção É agregada durante todo o processo 05/08/2011 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

19. Testes & Qualidade de Software Independencia Gerencial Necessaria existir entre desenvolvimento e SQA Testes Garantem que software atenda os requisitos especificados, usa estrategia de testes aplicada por todo o ciclo de vida do projeto (unitario, sistema,integração, regressão e de aceitação do usuario (UAT)) 05/08/2011 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

20. Testes & Qualidade de Software • Testes que nao se baseiam em execução. • Walkthroughs • Tecnica de Revisão • Baseia-se na revisao por diferentes individuos que nao sejam autores do documento (projeto de software) • Equipe formada por 4 a 6 individuos, pelo menos um representante da equipe de elaboração das especificações, gerente responsavel pelo fluxo de trabalho, cliente ou area de negocios, SQA deve presidir o grupo • Inspeções • Mais complexa que Walkthroughs com cinco etapas formais: • Visao Geral do documento inspecionado • Preparação – Participantes devem entender o documento • Inspeção - Encontrar e documentar imperfeições • Reformulação – resolve imperfeições e problemas achados. • Acompanhamento – Moderador garante que questões levantadas sejam resolvidas. 05/08/2011 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

21. Testes & Qualidade de Software • Comparação entre Inspeções e Walkthroughs • Walktroughs – Duas etapas, preparação seguida de analise do documento pela equipe. • Inspeções processo de 5 etapas ( Visao Geral, preparação, inspeção reformulação e acompanhamento) • Testes baseados em execução • Baseiam-se na execução do sistema com verificação de seu comportamento e resultados obtidos. • Apesar dos esforços com esse tipo nao garante 100% de inexistencia de erros. 05/08/2011 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

22. Testes & Qualidade de Software • O que deve ser testado? • Utilidade • Confiabilidade • Robustez • Desempenho • Correção 05/08/2011 Professor Leomir J. Borba- professor.leomir@gmail.com –http://professorleomir.wordpress.com

23. CMM -Histórico • O SW-CMM (Capability Maturity Model for Software) é um modelo de capacitação de processos de software, desenvolvido pelo SEI (Software Engineering Institute) e patrocinado pelo Departamento de Defesa Americano (DoD), para a avaliação da capacidade dos fornecedores de software deste último. • Início dos trabalhos deu-se em 1986, tendo sido publicada a versão 1.0 do SW-CMM em agosto de 1991. • Em fevereiro de 1993, foi publicada a versão 1.1.

24. CMM – Histórico cont. • Por ser específico para a área de software, o SW-CMM não contemplava outras áreas importantes das organizações, tais como Recursos Humanos e Engenharia de Sistemas. • Com o sucesso do SW-CMM, outros modelos semelhantes foram criados para outras áreas, tais como Gestão de Recursos Humanos (People-CMM), Aquisição de Software (SA-CMM) e Engenharia de Sistemas (SE-CMM). • Entretanto, os diversos modelos apresentavam estruturas, formatos e termos diferentes, dificultando sua aplicação conjunta.

25. Histórico • Proliferação de Modelos e Padrões em diversas áreas • Diferentes estruturas, formatos, termos, maneiras de medir maturidade • Causa confusão, especialmente quando mais de um modelo é utilizado • Difícil de integrar em um único programa de melhoria SoftwareAcquisition CMM Software CMM Systems SecurityEngineering CMM SystemsEngineering CMM SECM (EIA 731) Integrated Product Development CMM People CMM

26. CMMI - Histórico • O CMMI (Capability Maturity Model Integration) foi criado, então, com a finalidade de integrar os diversos modelos CMM. • Em 1999, foi publicado o esboço (draft), versão 0.2: CMMI-SE/SW (Capability Maturity Model -Integrated – System / Software Engineering). • Versões do CMMI: • Versão 1.0: Agosto de 2000 • Versão 1.1: Março de 2002 • Versão 1.2: Agosto de 2006 (CMMI for Development)

27. SW-CMM • Modelo de Maturidade de Capacitação para Software • Objetivo Principal: guiar organizações a conhecerem e melhorarem seus processos de software. • Identifica práticas para um processo de software maduro, definindo as características de um processo de software efetivo. • Descreve como as práticas de engenharia de software evoluem sob certas condições. • Organiza os estágios de evolução da melhoria dos processos em cinco níveis de maturidade.

28. SW-CMM: Estrutura • Cada nível de maturidade, com exceção do primeiro, é composto por áreas-chave de processo (Key Process Areas – KPAs). • Cada KPA identifica atividades relacionadas que, quando executadas adequadamente, atingem determinados objetivos considerados importantes para o aumento da capacidade do processo. • As KPAs são os requisitos para a obtenção de um nível no CMM. • As KPAs são cumulativas, isto é, para uma organização atingir um determinado nível de maturidade, ela deve satisfazer todas as KPAs daquele nível e de seus inferiores.

29. SW-CMM: Estrutura • Cada KPA é descrita em termos de práticas-chave (Key Practices). • Uma prática-chave descreve as atividades e a infra-estrutura necessárias para a efetiva implementação e institucionalização de uma KPA. • Uma prática-chave descreve “o quê” deve ser feito, e não “como” deve ser feito. Tópicos Especiais - Qualidade de Software 2008/2

30. SW-CMM: Estrutura • Para cada KPA há metas a serem alcançadas, que caracterizam o seu conteúdo, escopo e limite. • Metas são usadas para determinar se a organização ou projeto efetivamente implantou a KPA em questão. • Em uma avaliação de conformidade com o CMM, o mais importante é verificar se todas as metas da KPA foram atingidas

31. SW-CMM – Níveis de Maturidade • Um nível de maturidade é um patamar evolutivo bem definido, que visa a alcançar um processo de software maduro. • Os níveis são uma forma de priorizar as ações de melhoria, de tal forma que se aumente a maturidade do processo de software. • No nível 2 por exemplo, são focados aspectos gerenciais dos projetos.

32. Processo continuamente melhorado 5- Otimizado 4- Gerenciado Processo previsível e controlado 3- Definido Processo consistente e padronizado 2- Repetível Processo disciplinado 1- Inicial Processoimprevisível e sem controle SW-CMM – Níveis de Maturidade • O conceito de maturidade é baseado na noção de que alguns processos provêem mais estrutura e controle do que outros.

33. entrada saída SW-CMM: Nível 1 (Inicial) • O processo de software é caracterizado como sendo imprevisível e ocasionalmente caótico. • Poucos processos são definidos e o sucesso depende de esforços individuais e, muitas vezes, heróicos. • O processo de software é uma caixa preta, de forma que somente as entradas e os produtos finais podem ser vistos com clareza.

34. SW-CMM: Nível 1 • Organizações no nível 1 apresentam deficiências de planejamento e enfrentam dificuldades ao realizarem previsões. • Cronogramas e planos são irrealistas. • Como não há credibilidade no planejamento, mesmo aquilo que foi planejado não é seguido. • Não há controle de requisitos e o cliente só os avalia na entrega do produto. • É comum passar diretamente dos requisitos à codificação. • A documentação é encarada como algo inútil. • São comuns reações intransigentes à coleta de dados e ao uso de padrões, documentação e ferramentas.

35. entrada saída SW-CMM: Nível 2 (Repetível) • Processos básicos de gerência de projetos são estabelecidos para controle de custos, prazos e escopo. • É possível repetir sucessos de projetos anteriores em aplicações similares. • Ao invés do processo ser uma única caixa preta, ele passa a ser uma seqüência de caixas pretas que asseguram a visibilidade em determinados pontos, os marcos do projeto.

36. SW-CMM: Nível 2 • Neste nível, organizações têm maior probabilidade de cumprir compromissos de requisitos, prazos e custos, mas desde que sejam semelhantes a outros realizados anteriormente. • A organização é disciplinada, mas não está bem preparada para mudanças. • Há preocupação com a gerência do projeto. Os gerentes acompanham custos, cronogramas e funcionalidades de cada um dos projetos. Porém, a gerência ainda não é pró-ativa, tomando ações normalmente quando se está diante de uma crise. • Os projetos podem ter processos diferentes. No entanto, existe uma política para guiar os projetos no estabelecimento desses processos. • Controla-se a evolução dos requisitos, permitindo avaliações ao final de cada marco do projeto, e controla-se, também, a evolução das configurações do software.

37. SW-CMM: KPAs do Nível 2 • Gerência de Requisitos • Planejamento de Projetos • Supervisão e Acompanhamento de Projetos • Gerência da Subcontratação de Software • Garantia da Qualidade de Software • Gerência de Configuração de Software Tópicos Especiais - Qualidade de Software 2008/2

38. entrada saída SW-CMM: Nível 3 (Definido) • Um processo de software, composto por atividades de gerência e engenharia, é documentado, padronizado e integrado em um processo de software padrão da organização. • Todos os projetos utilizam uma versão aprovada e adaptada do processo organizacional para desenvolvimento e manutenção de software. • A organização interna das tarefas está definida e visível Tópicos Especiais - Qualidade de Software 2008/2

39. SW-CMM: Nível 3 • Processos utilizados são estabelecidos e padronizados em toda a organização. • Os processos pertencem à organização e não aos projetos. • O Grupo de Processos (Software Engineering Process Group - SEPG) é responsável pelos processos da organização. • Apesar da padronização, é possível adaptar os processos para as necessidades particulares de um projeto. • Processos de engenharia de software são considerados ao lado dos processos gerenciais. • Há treinamento técnico e gerencial. • A organização consegue se manter dentro do processo mesmo em períodos de crise. • Como o processo é bem definido, caso um desenvolvedor abandone o projeto antes de seu término, o impacto é relativamente menor que nos níveis anteriores. • Passagem do nível 2 para o 3: a padronização realizada é a oportunidade de escolher as melhores práticas existentes na organização.

40. SW-CMM: KPAs do Nível 3 • Foco no Processo da Organização • Definição do Processo da Organização • Programa de Treinamento • Gerência de Software Integrada • Coordenação entre grupos • Engenharia de Produtos de Software • Revisão por Pares

41. entrada saída SW-CMM: Nível 4 (Gerenciado) • Métricas detalhadas do processo de software e da qualidade do produto são coletadas. • Tanto o processo como o produto de software são quantitativamente compreendidos e controlados.

42. SW-CMM: Nível 4 • A organização estabelece metas quantitativas de qualidade e produtividade para as atividades do processo e para os produtos produzidos são estabelecidas para cada projeto. • Medidas de qualidade e produtividade são coletadas em todos os projetos como parte de um processo organizacional de medição e estabelecem uma base quantitativa para que os gerentes possam avaliar o progresso do desenvolvimento e a ocorrência de problemas. • Os projetos melhoram o seu controle sobre os produtos e processos e a variância das medidas é diminuída. • É estabelecido o controle estatístico de processos. • Uma organização no nível 4 passa a ter uma gestão feita com bases quantitativas.

43. SW-CMM: KPAs do Nível 4 • Gerência Quantitativa dos Processos • Gerência da Qualidade de Software

44. SW-CMM: Nível 5 (Otimizado) • A melhoria contínua do processo é estabelecida por meio de sua avaliação quantitativa, e da implantação planejada e controlada de tecnologias e idéias inovadoras. saída entrada

45. SW-CMM: Nível 5 • A organização está engajada na melhoria contínua de seus processos, possuindo meios para identificar fraquezas e fortalecer o processo de forma pró-ativa, prevenindo defeitos. • O entendimento do processo ultrapassa os processos praticados, possibilitando compreender os efeitos de alterações potenciais no processo. • Melhorias em processos e tecnologias são planejadas e executadas como parte das atividades de rotina. • Mudanças mais significativas de processos ou de tecnologias são feitas a partir de análises de custo / benefício com base em dados quantitativos cuja coleta iniciou-se no nível 4. Tópicos Especiais - Qualidade de Software 2008/2

46. SW-CMM: KPAs do Nível 5 • Prevenção de Defeitos • Gerência da Evolução dos Processos • Gerência da Evolução das Tecnologias

47. CMMI • É um modelo que descreve orientações para a definição e implantação de processos. • O modelo não descreve processo algum, são orientações definidas através das práticas especificadas. • Método de avaliação utilizado: SCAMPI (Standard CMMI Assessment Method for Process Improvement) • Método que reúne as melhores práticas do CBA-PI e SCE (métodos amplamente utilizados pelo SW-CMM e outros modelos de melhoria de processos)

48. CMMI – Cont. • Proposta de um modelo integrado que pode ser utilizado em várias disciplinas. • Disciplinas do CMMI • Engenharia de Software • Engenharia de sistemas: abordagem interdisciplinar cujo objetivo é o desenvolvimento bem-sucedido de sistemas como um todo, envolvendo software ou não. • Desenvolvimento integrado do produto e processo: abordagem sistemática que utiliza a colaboração dos stakeholders para melhor satisfazer as expectativas e requisitos dos clientes. Usada em conjunto com práticas de produção de um produto específico. • Fontes de Aquisição: aquisição de produtos de fornecedores.

49. Objetivos do CMMI • Além da integração dos modelos e redução dos custos com melhorias de processo, os seguintes objetivos também fazem parte do projeto CMMI: • Aumento do foco das atividades • Integração dos processos existentes • Eliminar inconsistências • Reduzir duplicações • Fornecer terminologia comum • Assegurar consistência com a norma ISO 15504 • Flexibilidade e extensão para outras disciplinas

50. CMMI: Conceitos Básicos • Área de Processo (Process Area – PA): práticas relacionadas em uma área que, quando executadas de forma coletiva, satisfazem um conjunto de metas consideradas importantes para trazer uma melhoria nessa área. • Metas Específicas: se aplicam a uma PA e tratam de características que descrevem o que deve ser implementado para satisfazer essa PA. São utilizadas nas avaliações para auxiliar a determinar se a PA está sendo satisfeita.