Engenharia de Software

Transcrição

1 Prof. Ms. Luiz Alberto Contato: Engenharia de Software Definição O CMMI é um conjunto de boas práticas de gerenciamento e de melhoria da qualidade a serem aplicadas criteriosamente no processo de desenvolvimento e manutenção de software. O CMMI foi criado para melhorar e quantificar a capacidade de desenvolvimento de aplicações em organizações que trabalham com tecnologias de software. Prof. 1 Luiz Alberto - Definição O modelo CMMI descreve como as práticas de Engenharia de Software evoluem sob certas condições: O trabalho realizado é organizado e visto como um processo; A evolução do processo é sistematicamente gerenciada. Definição Uma das premissas do modelo é "A qualidade é influenciada pelo processo", e seu foco é "Melhorar processo de uma empresa". Prof. 2 Luiz Alberto - Prof. 3 Luiz Alberto -

2 Certificação As empresas podem ser avaliadas quanto ao CMMI, recebendo certificados emitidos pelo SEI (Software Engineering Institute). Os níveis de maturidades e capacidades são reconhecidos e aceitos pelo mercado, sendo válidos para comparações tanto dentro de uma organização, como entre organizações. A obtenção de uma certificação CMMI é uma demonstração da capacidade do processo, tomando por base o nível de maturidade atingido, facilitando a contratação da empresa. Disciplinas Engenharia de Software (SW) Cobre o desenvolvimento de sistemas de software Aplicação de abordagens sistemáticas, disciplinadas e quantificáveis ao desenvolvimento, operação, e manutenção de software Engenharia de Sistemas (SE) Cobre o desenvolvimento de sistemas completos, que pode ou não incluir software Transformação das necessidades, expectativas e restrições dos clientes em soluções de produto e suporte a essas soluções ao longo da vida do produto Prof. 4 Luiz Alberto - Prof. 5 Luiz Alberto - Disciplinas Histórico Desenvolvimento Integrado de Produto e Processo (IPPD) Colaboração oportuna das partes interessadas relevantes durante a vida do produto para melhor satisfazer às necessidades, expectativas e requisitos do cliente Gestão de Fornecedores (SS) Projetos podem utilizar fornecedores para implementar funções ou incorporar modificações aos produtos que são especificamente demandados pelo projeto Quando essas atividades são críticas, o projeto se beneficia com atividades de análise e monitoramento de fornecedor antes da entrega do produto 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 Em fevereiro de 1993, foi publicada a versão 1.1. Prof. 6 Luiz Alberto - Prof. 7 Luiz Alberto -

3 Histórico 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. SECM (EIA 731) Histórico Proliferação de Modelos e Padrões em diversas áreas Software CMM Systems Engineering CMM Integrated Product Development CMM Software Acquisition CMM Systems Security Engineering CMM People CMM 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 Prof. 8 Luiz Alberto - Prof. 9 Luiz Alberto - Histórico SW-CMM 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) Versão 1.3: Outubro de 2010 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. Prof. 10 Luiz Alberto - Prof. 11 Luiz Alberto -

4 CMMI Conceitos: Modelo de Maturidade e Capacidade Modelos A versão atual do CMMI (versão 1.3) foi publicada em 27 de outubro de 2010 e apresenta três modelos: CMMI for Development (CMMI-DEV), voltado ao desenvolvimento de produtos e serviços. CMMI for Acquisition (CMMI-ACQ), voltado a aquisição e terceirização de bens e serviços. CMMI for Services (CMMI-SVC), voltado a empresas prestadoras de serviços. Prof. 12 Luiz Alberto - Prof. 13 Luiz Alberto - Representações Dimensões do CMMI O CMMI foi construído considerando três dimensões principais: Pessoas Ferramentas Procedimentos Visando atender aos diversos tamanhos das organizações o CMMI possui duas abordagens de implementação: Abordagem por Estágios Abordagem Contínua Prof. 14 Luiz Alberto - Prof. 15 Luiz Alberto -

5 Representações Uma das principais características do CMMI é permitir à organização que o adota a escolha entre as duas formas distintas de representação. A abordagem contínua permite à empresa escolher as áreas de processos para as quais deseja ser avaliada, conferindo-lhe liberdade para aperfeiçoar os seus processos na ordem que mais lhe for conveniente, seja para atender aos objetivos de negócio, seja para a redução dos riscos da organização. Representações A abordagem por estágios, por sua vez, serve para classificar a empresa em um determinado nível de maturidade, em número de cinco. Para alcançar determinado nível de maturidade, a empresa deverá realizar um determinado conjunto de áreas de processos préselecionados. Prof. 16 Luiz Alberto - Prof. 17 Luiz Alberto - Disponibiliza uma sequência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels): Nível 1: Inicial (Ad-hoc) Nível 2: Gerenciado / Gerido Nível 3: Definido Nível 4: Quantitativamente gerenciado / Gerido quantitativamente Nível 5: Em otimização Nível 1: Inicial (Ad-hoc) Geralmente os processos são ad-hoc e caóticos. Esse tipo de organização não fornece um ambiente estável para apoiar os processos. 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. Prof. 18 Luiz Alberto - Prof. 19 Luiz Alberto -

6 Nível 1: Inicial (Ad-hoc) 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. Nível 2: Gerenciado / Gerido Os projetos da organização têm a garantia de que os processos são planejados e executados de acordo com uma política; Os projetos empregam pessoas experientes que possuem recursos adequados para produzir saídas controladas; Envolvem partes interessadas relevantes; São monitorados, controlados e revisados; e são avaliados para verificar sua aderência em relação à descrição de processo. Prof. 20 Luiz Alberto - Prof. 21 Luiz Alberto - Nível 2: Gerenciado / Gerido 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. entrada saída Nível 2: Gerenciado / Gerido 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. Prof. 22 Luiz Alberto - Prof. 23 Luiz Alberto -

7 Nível 3: Definido Os processos são bem caracterizados e entendidos, e são descritos em padrões, procedimentos, ferramentas e métodos. 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 entrada saída 24 Prof. 25 Luiz Alberto - 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

8 Nível 4: Quantitativamente gerenciado / Gerido quantitativamente A organização e os projetos estabelecem objetivos quantitativos para qualidade e para desempenho de processo, utilizando-os como critérios na gestão de processos. 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. entrada saída 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. Prof. 28 Luiz Alberto - 29 Nível 5: Em otimização (ou otimizado) Uma organização melhora continuamente seus processos com base no entendimento quantitativo das causas comuns de variação inerentes ao processo. 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. entrada saída 30 Prof. 31 Luiz Alberto -

9 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 iniciouse no nível Estrutura (por estágios) Nesta representação a maturidade é medida por um conjunto de processos. Assim é necessário que todos os processos atinjam nível de maturidade dois para que a empresa seja certificada com nível dois. Se quase todos os processos forem nível três, mas apenas um deles estiver no nível dois a empresa não irá conseguir obter o nível de maturidade três. Prof. 34 Luiz Alberto - Prof. 35 Luiz Alberto -

10 Esta representação é indicada quando a empresa já utiliza algum modelo de maturidade por estágios, quando deseja utilizar o nível de maturidade alcançado para comparação com outras empresas ou quando pretende usar o nível de conhecimento obtido por outros para sua área de atuação. Estruturado em 5 níveis de maturidade, o CMMI abrange 22 áreas de processo divididas em 4 categorias: Gerenciamento de projetos; Gerenciamento de processos; Engenharia; Suporte. Prof. 36 Luiz Alberto - Prof. 37 Luiz Alberto - Prof. 38 Luiz Alberto - 39

11 Representação Contínua Possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade (Capability Levels): Nível 0: Incompleto (Ad-hoc) Nível 1: Executado Nível 2: Gerenciado / Gerido Nível 3: Definido Nível 4: Gerenciado Quantitativamente (abolido no CMMI 1.3) Nível 5: Em otimização (ou otimizado) (abolido no CMMI 1.3) Níveis de Capacidade Nível 0: Incompleto (Ad-hoc) Um processo que não é executado ou é executado parcialmente. Nível 1: Executado Satisfaz às metas específicas da área de processo. Prof. 40 Luiz Alberto - Prof. 41 Luiz Alberto - Níveis de Capacidade Nível 2: Gerenciado / Gerido É planejado e executado de acordo com uma política; Emprega pessoas experientes que possuem recursos adequados para produzir saídas controladas; Envolve partes interessadas relevantes; É monitorado, controlado e revisado; e sua aderência em relação à descrição de processo é avaliada. Níveis de Capacidade Nível 3: Definido É um processo gerenciado (nível de capacidade 2), adaptado a partir do conjunto de processos-padrão da organização de acordo com as diretrizes para adaptação da organização, e contribui com produtos de trabalho, medidas e outras informações de melhoria de processo para os ativos de processo da organização. Prof. 42 Luiz Alberto - Prof. 43 Luiz Alberto -

12 Níveis de Capacidade Nível 4: Gerenciado Quantitativamente (abolido no CMMI 1.3) É um processo definido (nível de capacidade 3), controlado por meio de técnicas estatísticas e outras técnicas quantitativas. Níveis de Capacidade Nível 5: Em otimização (ou otimizado) (abolido no CMMI 1.3) é um processo gerenciado quantitativamente (nível de capacidade 4) e melhorado com base no entendimento das causas comuns de variação inerentes ao processo. Prof. 44 Luiz Alberto - Prof. 45 Luiz Alberto - Representação Contínua Representação Contínua Nesta representação a capacidade é medida por processos separadamente, onde é possível ter um processo com nível um e outro processo com nível cinco, variando de acordo com os interesses da empresa. É indicada quando a empresa deseja tornar apenas alguns processos mais maduros, quando já utiliza algum modelo de maturidade contínua ou quando não pretende usar a maturidade alcançada como modelo de comparação com outras empresas. Prof. 46 Luiz Alberto - Prof. 47 Luiz Alberto -

13 Representação Contínua Visibilidade da Gerência Prof. 48 Luiz Alberto - 49 Prof. 50 Luiz Alberto - Prof. 51 Luiz Alberto -

14 Comparando as Representações Comparando as Representações Prof. 52 Luiz Alberto - Prof. 53 Luiz Alberto - CMM em relação a PESSOAS CMM em relação a TECNOLOGIA 54 55

15 CMM em relação a MÉTRICAS CMMI - Fatores de limitação Vários são os fatores que limitam as organizações a adotarem o CMMI, tais como : Falta de recursos financeiros; Falta de mão de obra especializada; Prioridade para o manter, pouco foco no empreender. Gestores despreparados, muitas vezes com bagagem defasada; CMMI não está alinhado às exigências dos clientes; Divergência com os interesses dos acionistas; Resistência a mudanças culturais (problemas com a institucionalização); 56 Prof. 57 Luiz Alberto - CMM Panorama Brasil CMMI Panorama Brasil 58 59

16 CMMI Panorama Brasil CMMI Panorama Brasil CMMI mundo 2010 CMMI mundo

17 CMMI mundo 2012 CMMI mundo CMMI tempo obtenção CMMI tamanho 66 67