• Nenhum resultado encontrado

Aula 6- CMMI

N/A
N/A
Protected

Academic year: 2021

Share "Aula 6- CMMI"

Copied!
42
0
0

Texto

(1)

Gerencia de Qualidade de

Software

CMMI

https://sites.google.com/site/thiagoaalves/

(2)

Conteúdo Programático

 Apresentação da disciplina e metodologia de trabalho. Apresentação do Plano de Estudo e Aprendizagem. Introdução à Qualidade de Software.

 Estudo dos fatores técnicos e humanos que influenciam a qualidade de um software.

 Garantia da Qualidade de Software (SQA): conceito, importância e apresentação das técnicas.

(3)

Conteúdo Programático

 Garantia da Qualidade de Software (SQA): Impactos de um sistema de má qualidade.  CMMI. Introdução, diferenciação entre

qualidade de software e de processo. Estudo dos níveis CMMI. Abordagem das Key

Process Areas (KPA)

 CMMI: abordagem dos aspectos práticos de implantação do modelo. Apresentação de casos de sucesso na implantação, níveis

obtidos pelas principais empresas de TI ou não.

(4)

Conteúdo Programático

 Norma ISO 15504 (Spice): conceituação,

utilização, metodologia de avaliação.

 Normas MPS:BR e ISO 12207.

 Modelos de Processo Pessoal e de Equipe

na Melhoria da Qualidade do processo de desenvolvimento de Software

(5)

Conteúdo Programático

 Métricas de software: conceituação, motivos para medição de um produto de software. Principais tipos e utilizações.

 Métricas de software: apresentação da métrica de Pontos por Função.

 Qualidade de código. Programação: Fatores de qualidade

 Atividades de revisão de conteúdo e/ou apresentação de trabalhos em grupo

(6)

Reflexão

 O que é Maturidade?

(7)

Maturidade

1. estado, condição (de estrutura, forma, função

ou organismo) num estágio adulto; condição de plenitude em arte, saber ou habilidade adquirida.

2.termo último de desenvolvimento.

3.período da vida compreendido entre a

juventude e a velhice.

4.experiência ou ponderação própria da idade

madura.

5.estado ou qualidade de maduro.

6.o segundo dos três principais estágios num

ciclo de erosão ou numa outra mudança geológica.

(8)

Maturidade

 Uma empresa Imatura:

◦ Processos são improvisados ou não são seguidos;

◦ O Trabalho é feito em regime de emergência(apagar incêndio); ◦ Compromissos de prazo e custo não são cumpridos;

◦ O planejamento não é feito com base em estimativas realistas; ◦ Como os processos não são bem definidos todas as iniciativas

de melhoria não se sustentam e não se perpetuam;

◦ O Sucesso de um Projeto depende de especialistas (“Herois”) para resolver grandes problemas;

◦ Frequentemente novas tecnologias são adotadas como soluções milagrosas.

◦ Como a “moda” a empresa adota todas as “tendências de mercado.”

(9)

Maturidade

 Exemplo para Analogia: Time de Várzea:

◦ Sem Coordenação;

◦ Alguns Correm desordenadamente enquanto outros só observam.

 Mas, mesmo empresas imaturas podem

produzir bons produtos:

◦ Podem ter “Jogadores Excepcionais”;

◦ Porém com resultados imprevisíveis e custos fora do controle;

(10)

Maturidade

 Para tentar “acabar” ou diminuir as

ocorrências muitas empresas adotam modelos de maturidade. Inicialmente

veremos o Modelo CMM e sua evolução o CMMI.

(11)

CMM

 A causa mais comum do insucesso dos projetos

de desenvolvimento de software é a má utilização ou a completa indiferença aos métodos e

ferramentas orientados à concepção;

 O modelo CMM — Capability Maturity Model —

foi definido pelo SEI — Software Engineering Institute — com o ojetivo de estabelecer

conceitos relacionados aos níveis de maturidade das empresas de desenvolvimento de software, com respeito ao grau de evolução que estas se encontram nos seus processos de

(12)

CMM

 O modelo estabelece também quais

providências as empresas podem tomar para aumentarem, gradualmente o seu grau de maturidade, melhorando, por conseqüência, sua produtividade e a qualidade do produto de software.

(13)

CMM

 Proposta:

◦ ser baseado em experiência prática de empresas de software;

◦ atender as necessidades daqueles que

realizam melhoria do processo de software e avaliação do processo de software;

◦ ser documentado e estar disponível publicamente

(14)

CMM

Um Processo de Desenvolvimento

de Software corresponde ao conjunto

de atividades, métodos, práticas e

transformações que uma equipe utiliza para desenvolver e manter software e seus produtos associados (planos de

projeto, documentos de projeto, código, casos de teste e manuais de usuário).

(15)

CMM

Uma empresa é considerada num maior

grau de maturidade quanto mais evoluído for o seu processo de

(16)

CMM

A Capabilidade de um processo de

software está relacionada aos resultados que podem ser obtidos pela sua utilização num ou em vários projetos. Esta definição permite estabelecer uma estimação de

(17)

CMM

O Desempenho de um processo de

software representa os resultados que são correntemente obtidos pela sua

utilização. A diferença básica entre estes dois conceitos está no fato de que,

enquanto o primeiro, está relacionado aos resultados “esperados”, o segundo,

relaciona-se aos resultados que foram efetivamente obtidos.

(18)

Reflexão

 Qual a Principal diferença entre

Capabilidade e Desempenho?

 Capabilidade: O que se espera.  Desempenho: O que se obteve.

(19)

CMM

A Maturidade de um processo de

software estabelece os meios pelos quais ele é definido, gerenciado, medido,

controlado e efetivo, implicando num potencial de evolução da capabilidade.

(20)

CMM

 Numa empresa com alto grau de

maturidade, o processo de

desenvolvimento de software é bem

entendido por todo o staff técnico, graças à existência de documentação e políticas de treinamento, e que este é

continuamente monitorado e aperfeiçoado por seus usuários.

(21)

CMM

 O modelo CMM define cinco níveis de

maturidade no que diz respeito ao

processo de desenvolvimento de software adotado a nível das empresas,

estabelecendo uma escala ordinal que conduz as empresas ao longo de seu aperfeiçoamento.

(22)

CMM

 A ideia e que uma empresa

“Desorganizada” fique “Organizada”,

passando por cada nível e ao chegar no ultimo ela se seja uma empresa Madura e de Qualidade.

(23)

CMM

 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 evolui sob certas condições;

◦ Organiza os estágios de evolução da melhoria dos processos;

◦ Descreve um Caminho evolucionário que vai de um processo indisplinado para um processo disciplinado;

(24)

CMM

 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 obtenção de

(25)

CMM

 Para se chegar em determinado nível uma

empresa tem que atender todas as KPAs.

 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

(26)

CMM

 Cada KPA é descrita em termos de

práticas-chave (Key Pratices).

 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

(27)

CMM

 Por Exemplo:

Temos uma KA que define que a empresa deve possuir uma metodologia para

gestão e trabalho com seus projetos -> O quê.

 Se a empresa vai utilizar as melhores

praticas do PMBOK, RBC, Scrum dentre varias outas. -> Como.

(28)

CMM

 Para cada KPA existem metas a serem

alcançadas, que caracterizam o seu conteúdo, escopo e limite.

 Metas sã 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 fora atingidas.

(29)
(30)

30

Nível 1 - Inicial

 Processo de software ad hoc – imprevisível e

quase sem controle;

 Resultados dependem de posturas individuais;  O processo é uma caixa preta!!

(31)

Nível 2 - Repetitivo

 Processos básicos de gerenciamento de

projetos estabelecidos para fazer o “tracking” de custos, cronograma e funcionalidades;

 Sequência de caixas pretas (tarefas);

 Planejamento e gerência de novos projetos

baseados em experiências adquiridas com projetos similares já realizados;

(32)

Nível 3 - Definido

 Processo de software documentado,

padronizado e integrado em um processo de software padrão para a organização;

 Todos os projetos usam uma versão adaptada e

aprovada do processo padrão da organização;

(33)

Nível 4 - Gerenciado

 Processos de software instrumentalizados e

controlados quantitativamente;

 Base quantitativa para tomada de decisões;

 Permite prever tendências em processos e em

(34)

Nível 5 – Em otimização

 Foco na melhoria do processo;

 A organização tem meios para identificar

fraquezas e fortalecer o processo de forma pró-ativa, prevenindo a ocorrência de defeitos;

(35)
(36)

CMM

 Em resumo com a adoção do modelo

(37)
(38)

Estudo de Caso – 30 Minutos

 Em grupo pense no seu ambiente

organizacional, no seu local de trabalho. Pense em todas as atividades que são planejadas mas não são cumpridas. Pense nos métodos e

processos que são estipulados e não são

seguidos dentro da organização. Elaborem uma lista com as 7 piores praticas adotadas pelas empresas.

 Ex: Na empresa XYZ temos reuniões no

começo de cada projeto para definição do

Cronograma. O Problema e que não seguimos esse cronograma definido. (este exemplo não pode ser utilizado).

(39)

Resolução Turma da Manha

1. Improviso e Gambiarras , viver apagando incêndios;

2. A inexistência de documentação e a ausência de relatórios; 3. A inexistência de padrões e os que existem não são

seguidos;

4. A falta de recursos tecnológicos e estruturais para a

realização das atividades;

5. A inexistência de comunicação efetiva entre os membros

da equipe dentro do ambiente organizacional;

6. A existência de individualismo dentro do ambiente

corporativo;

7. A falta de treinamento coorporativo para o entendimento

(40)
(41)

Referencias

 http://pt.slideshare.net/RonneyMoreirade

Castro/cmm-e-cmmi

 http://slideplayer.com.br/slide/395733/  http://slideplayer.com.br/slide/2263468/

(42)

Referências

Documentos relacionados

Este estudo, assim, aproveitou uma estrutura útil (categorização) para organizar dados o que facilitou a sistematização das conclusões. Em se tratando do alinhamento dos

Somente na classe Aberta Jr e Sr, nas modalidades de Apartação, Rédeas e Working Cow Horse, que será na mesma passada dessas categorias e os resultados serão separados. O

c.4) Não ocorrerá o cancelamento do contrato de seguro cujo prêmio tenha sido pago a vista, mediante financiamento obtido junto a instituições financeiras, no

a) O polícia disse um palavrão, após ter saído da casa de Adrian. Corrige as falsas.. A mãe também está com gripe. “Quase que não consegui ficar calado quando vi que não

Para atingir este fim, foram adotados diversos métodos: busca bibliográfica sobre os conceitos envolvidos na relação do desenvolvimento de software com

Objetivo: Garantir estimativas mais realistas e precisas para o projeto, ao considerar nesta estimativa o esforço necessário (em horas ou percentual do projeto) para

auxiliar na criação de KPI’s. Fonte: Elaborado pela autora com base nos Quadros de 1 a 10 dessa dissertação.. O Quadro 13 apresenta os resultados trabalhados e que possuem

Para disciplinar o processo de desenvolvimento, a Engenharia de Usabilidade, também conceituada e descrita neste capítulo, descreve os métodos estruturados, a