Qualidade, uma questão de Gestão
PSP - Personal Software Process.
TSP - Team Software Process.
CMMI - Capability Maturity Model Integration (SE/SW e AS-CMM).
ITIL - Information Technology Infrastructure Library.

Três Níveis

CMM -> Capacitação Organizacional
TSP -> Capacitação de Equipes
PSP -> Capacitação de Indivíduos

O CMM diz “o que” deve ser feito
– Desenhado para ser amplo e duradouro
– Não entra em detalhes de técnicas específicas
O PSP e o TSP dizem também “como”
– Sugerem técnicas e dão alternativas

PSP – Personal Software Process

Mensagem a reter

– O PSP é um processo definido para ajudar o desenvolvedor a fazer melhor seu trabalho.
– O PSP ensina e recomenda técnicas que podem ser utilizadas também no âmbito da equipe (TSP) e da organização (CMMI)

Princípios do PSP

A qualidade de um software é governada pela qualidade de seus piores componentes
A qualidade de um componente de software é governada pelo indivíduo que o desenvolveu
– Conhecimento
– Disciplina
– Comprometimento
O profissional de software deve conhecer sua própria performance – Medir, acompanhar e analisar seu trabalho
– Aprender das variações na performance
– Incorporar estas lições em suas práticas pessoais
A qualidade de um software é governada pela qualidade de seus piores componentes

O Modelo PSP

Um modelo desenvolvido pelo SEI para melhoria e otimização do processo individual de trabalho.
Estruturado como um curso, onde os conceitos, metodologia e documentação são introduzidos gradativamente via treinamento.
Baseado no CMMI, possui também níveis de maturidade. O PSP representa para o indivíduo, enquanto processo de amadurecimento, o que o CMMI é para a empresa.
Os níveis representam fases de evolução a ser seguidas até se alcançar o pleno controle sobre as atividades de desenvolvimento.

O Processo Pessoal de Software (PSP)

O PSP permite ao desenvolvedor
– Preencher a lacuna deixada pelos modelos de processo de software, com relação ao processo pessoal.
– Estimar e planejar o trabalho a ser feito
– Cumprir compromissos
– Resistir a pressões por compromissos irreais
– Compreender sua habilidade
– Estar mais apto a melhorar sua forma de trabalho
– Enfim, tornar o trabalho mais produtivo, adequado e satisfatório ao desenvolvimento de sistemas em escala individual, fazendo com que o próprio engenheiro de software encontre os seus limites.
O PSP estabelece
– Uma base testada e comprovada para o desenvolvimento e uso de disciplinas pessoais de alcance industrial
– Uma disciplina que mostra como o processo pessoal pode ser melhorado
– Os dados necessários para a melhoria contínua da produtividade, qualidade e previsibilidade do trabalho do desenvolvedor
Características
– Suporta desenvolvimento individual.
– Possibilita que o próprio engenheiro encontre seu processo de desenvolvimento.
– Institucionaliza o controle total das atividades.

Estratégia do PSP

Identificação de métodos e técnicas utilizados em sistemas de grande escala que possam ser úteis para os sistemas individuais.
Definição de um subconjunto destes métodos e técnicas para serem aplicados no desenvolvimento de pequenos programas.
Estruturação destes métodos para que sejam gradualmente introduzidos.
Fornecimento de um conjunto de exercícios a serem realizados, possibilitando o aprendizado do PSP.

Visão Geral do PSP

PSP0 - A performance atual é medida e estabelecida – Baseline
PSP1 - São elaborados planos de tamanho, recursos e tempos gastos no trabalho – Gerenciamento de Projetos.
PSP2 - É realizado o gerenciamento de defeitos e rendimento – Gerenciamento do Processo e da Qualidade
PSP3 - Os métodos do PSP são ampliados para projetos maiores –
Escalabilidade do Processo

PSP0 - Medição Pessoal

Construir uma base (baseline) de medidas para suporte à evolução, com foco na medição do tempo gasto, defeitos inseridos e encontrados.
– Utiliza tabelas para medição e documentação
– Base para todo o processo de melhoria
– Coleta de dados
tempo
defeitos
– Delineação do perfil do engenheiro
– Basicamente uma fase de coleta de informações

PSP1 - Planejamento Pessoal

Adiciona planejamento ao PSP0 com base nos dados históricos
Registro de teste e estimativa de tamanho e recursos.
– Perceber a relação entre o tamanho do programa desenvolvido e o tempo gasto para desenvolvê-lo.
– Ajudar o engenheiro de software a só assumir compromissos que possa cumprir.
– Fornecer um planejamento ordenado das tarefas a serem cumpridas.
– Fornecer dados para avaliação do trabalho realizado.
Adiciona planejamento ao PSP0 com base nos dados históricos
Registro de teste e estimativa de tamanho e recursos.
– Perceber a relação entre o tamanho do programa desenvolvido e o tempo gasto para desenvolvê-lo.
– Ajudar o engenheiro de software a só assumir compromissos que possa cumprir.
– Fornecer um planejamento ordenado das tarefas a serem cumpridas.
– Fornecer dados para avaliação do trabalho realizado.

PSP2 - Qualidade Pessoal

Foco em técnicas de revisão de código para encontrar possíveis defeitos, antes que seja tarde demais para consertá-los.
Principais dados gerados nas revisões:
– Tamanho do programa.
– Tempo de revisão.
– Número total de defeitos encontrados.
– Número de erros encontrados após a revisão.
– Número médio encontrado por hora de revisão.
– Número médio de linhas de código revistas por hora.

PSP3 - Processo Cíclico

Estratégia
– desenvolver programas incrementalmente. A cada iteração, o processo de PSP2 é completado, incluindo desenvolvimento, codificação, revisão e teste.
Objetivos
– Tornar o PSP aplicável a tarefas médias e grandes.
– Melhoria contínua através de avaliações sucessivas.

CMM – Capability Maturity Model

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.
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.
Proliferação de Modelos e Padrões em diversas áreas

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:

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.

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.
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.
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.

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.
O conceito de maturidade é baseado na noção de que alguns processos provêem mais estrutura e controle do que outros.

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, heroicos.
O processo de software é uma caixa preta, de forma que somente as entradas e os produtos finais podem ser vistos com clareza.
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.

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 sequência de caixas pretas que asseguram a visibilidade em determinados pontos, os marcos do projeto.

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

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

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

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.

KPAs do Nível 4

Gerência Quantitativa dos Processos
Gerência da Qualidade de Software

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 ideias inovadoras.

KPAs do Nível 5

Prevenção de Defeitos
Gerência da Evolução dos Processos
Gerência da Evolução das Tecnologias

TSP – Team Software Process

O que é o TSP?

O TSP (Team Software Process) é uma estrutura para a melhoria quantitativa de processo de software que ajuda equipes a desenvolver produtos de software de modo eficaz
Baseia-se nos conceitos do CMM
Supõe que os membros da equipe tenham sido treinados no PSP

Conceitos e Estrutura

Equipes auto-gerenciadas
– A gerência provê orientação e suporte
– A equipe planeja o próprio trabalho, acompanha o progresso e gerencia as tarefas do dia-a-dia.
Cada membro da equipe tem papéis e responsabilidades definidos
Todos os membros participam do planejamento do projeto e da tomada de decisões-chave
A equipe é proprietária dos seus processos e pode mudá-los sempre que necessário
Os processos da equipe são baseados em sua
– experiência
– conhecimento
– maturidade
As equipes aplicam práticas do Nível 5 do CMM
O TSP provê um conjunto de
– scripts de processos
– formulários
– métodos
– métricas
Estes elementos guiam os desenvolvedores em
– criar equipes eficazes
– estabelecer metas e planos para a equipe
– acompanhar e reportar o trabalho
TSPi
– Versão simplificada do TSP para equipes e projetos menores

O Design do TSPi

Estrutura simples construída sobre o PSP
Desenvolvimento incremental
Métricas padronizadas de qualidade e performance
Métricas precisas para equipes e indivíduos
Uso de avaliações de papéis e de time
Exigência de disciplina de processo
Aconselhamento nos problemas do trabalho em equipe

Estrutura e Fluxo

O Processo do TSPi

Cada ciclo inclui as seguintes fases
– Lançamento (launch)
– Estratégia
– Planejamento
– Requisitos
– Design
– Implementação
– Teste
– Postmortem
O processo inclui
– Scripts
– Formulários
– Padrões

Para Quê o Launch?

A construção de equipes não ocorre por acaso
Um lançamento inicial permite
– Estabelecer as relações de trabalho
– Definir e distribuir os papéis pelos membros da equipe
– Chegar a um acordo sobre as metas da equipe

Planejar Antes

Porquê planejar antes de conhecer o produto em detalhes?
– Porque é assim na vida real
– Porque ao desenvolver o plano a equipe adquire uma melhor compreensão comum do trabalho a ser feito
– Porque um plano é a base para acompanhar o trabalho
– Porque, sem um plano, a equipe acabará se comprometendo com o prazo imposto pela gerência ou o cliente, acredite ou não que será capaz de cumpri-lo
Daí a necessidade de iniciar pela Estratégia

O Quê é uma Estratégia?

A Estratégia define a ordem na qual as funções do produto serão definidas, desenhadas, implementadas e testadas
O processo de desenvolvimento do TSPi é cíclico
– Cada ciclo produz uma versão operacional do produto
– Ciclos subseqüentes incrementam a funcionalidade do produto
– Este processo é também conhecido como “ciclo de vida incremental”
– A equipe decide o conteúdo de cada ciclo (no curso) ou negocia este conteúdo com o usuário / cliente, com base no prazo e recursos disponíveis

Planejamento

Passos
– Liste os produtos a serem desenvolvidos no ciclo e estime seustamanhos
– Produza a lista de tarefas
– Produza o cronograma
– Produza o plano de qualidade
– Produza os planos individuais dos desenvolvedores
– Realize o balanceamento da carga
– Produza e distribua o planos

Para Quê o Postmortem?

Sem uma fase específica para analisar o trabalho feito, pouco se aprende e não se pode fazer melhoria contínua.
– O Postmortem é uma forma estruturada de aprender e melhorar
– Compara-se o planejado com o que realmente aconteceu
– Procuram-se oportunidades de melhoria
Mudanças no processo para o próximo projeto ou ciclo

Por Quê Papéis?

Para distribuir a carga de trabalho associada ao desenvolvimento que vão além da construção do produto
Para permitir o desenvolvimento de diferentes habilidades pelos desenvolvedores
Para explicitar as responsabilidades pelas tarefas
Para explicitar a necessidade de tarefas associadas ao desenvolvimento que normalmente são ignoradas pelas equipes

Escolha dos papéis

Cada membro da equipe atua ao mesmo tempo como desenvolvedor e assume um dos papéis do TSPi
Os papéis devem ser escolhidos / distribuídos
– Conforme o interesse dos membros da equipe
– De acordo com suas habilidades
Convém haver rodízio de papéis a cada novo ciclo / projeto
Cada pessoa deveria especializar-se em dois ou três papéis

Os Papéis do TSPi

Líder da Equipe
Gerente de Desenvolvimento
Gerente de Planejamento
Gerente de Qualidade / Processo
Gerente de Suporte

Conclusão

São quatro as lições do TSP
1. A maior parte do desenvolvimento de software é e será feita porequipes
2. Equipes com as habilidades apropriadas e em que todos os membros trabalham juntos cooperativamente e efetivamente podem produzir resultados extraordinários
3. Um trabalho em equipe efetivo requer oito coisas
1. Metas da equipe com que todos concordam
2. Papéis estabelecidos
3. Um ambiente de trabalho adequado
4. Um processo de trabalho comum
5. Um plano para o trabalho
6. O compromisso mútuo com as metas, papéis e o plano.
7. Comunicação aberta entre todos os membros do time
8. Respeito mútuo e suporte de todos os membros do grupo
4. Quando times encontram essas condições, produzem um trabalho superior, são mais produtivos e apreciam o seu trabalho.

ITIL – IT Infrastructure Library

O que é o ITIL ®?
ITIL é a abreviação de "IT Infrastructure Library", guias (livros) desenvolvidos originalmente para o governo britânico (Escritório de Comércio) no final da década de 80 (!) para ter referências na medição da qualidade de seus serviços de IT. Hoje, ITIL é um padrão global na área de gerência de serviço.

ITIL não é uma Metodologia: é um conjunto de Melhores Práticas
– Metodologia
Esclarece exatamente o quê, para quê, por quê, como, etc...
– Melhores Práticas.
Forma de fazer algo, baseado em como outros já fizeram com sucesso
Serve de Inspiração
Sugere para quê
Sugere por quê
Sugere o quê
A utilização de Melhores Práticas nos dá uma forma de executar ações baseadas no que é comumente visto e aceito como a melhor forma de fazer algo
Modo mais aceito no mundo para Gestão de Serviços de TI
– Provenientes do setor público e privado, internacionalmente.
– Livros de Domínio público, não proprietários.
Fornece orientação, não é manual de passo-a-passo.
ITIL não é Objetivo.
– O objetivo é o Gerenciamento de Serviços de TI (ITSM)
Information
Technology
Infrastructure
Library
Os 2 volumes principais são:
– Suporte a Serviços (Service Support) e
– Entrega de Serviços (Service Delivery)

Processos ITIL – Service Support

Service Support
– Suporte dos serviços de TI no dia-a-dia da operação
– De natureza operacional
– Fornece o controle e estabilidade à Infra-estrutura de TI mantendo-se flexível para acomodar as mudanças do negócio, de tempo e às demandas do mercado

Processos ITIL – Service Delivery

Service Delivery
– Provê qualidade na entrega dos serviços de TI
– De natureza mais estratégica, com algumas atividades operacionais
– Não pode ser efetiva sem os processos do Service Support
– Planejamento a longo prazo

Service Support
Service Desk

Objetivos:
– Agir como o ponto central do contato entre o usuário e o serviço de TI
– Atendimento de primeiro nível para todas: Ligações, perguntas, solicitações, reclamações, etc.
– Restaurar o serviço o mais rápido possível
– Gerenciar o ciclo de vida do incidente, coordenando a resolução
– Dar suporte para as atividades do negócio
– Tratar todos os Incidentes, Problemas, Requisições de Mudança e Questões relacionadas com os serviços de TI
– Restaurar o serviço o mais rápido possível, para minimizar o impacto nos negócios e para garantir o melhor nível de serviço, no tocante a qualidade e disponibilidade.
– Garantir o melhor uso dos recursos para o suporte dos negócios
– Desenvolver e manter as informações relevantes relacionadas aos incidentes
– Aplicar uma abordagem consistente para todos os incidentes reportados
– Minimizar o impacto dos incidentes e problemas nos negócios
– Buscar a causa raiz do incidente e sua consequente solução e prevenção
– Estabilizar os serviços de TI
Minimizar as conseqüências dos incidentes
Remover as causas dos incidentes
Prevenir incidentes e problemas
Melhorar o uso produtivo dos recursos
– Avaliar as Requisições de Mudanças solicitadas
– Implementar mudanças aprovadas de maneira eficiente, a um custo efetivo, com um mínimo risco à infra-estrutura de TI existente e à nova
– Balanço entre Necessidade e Impacto
– Garantir métodos padronizados, onde os procedimentos são usados de forma eficiente para todas as mudanças, no intuito de minimizar o impacto de incidentes relacionados às ocorrências das mudanças, na direção da qualidade dos serviços
Nota: Decide e Coordena - Não executa
– Distribuição de uma Requisição de Mudança Autorizada / Aprovada
– Prover um modelo lógico de toda a infra-estrutura de TI existente, identificando, controlando, mantendo e verificando os itens de configuração (IC) existentes
– Contabilizar todos os recursos e configurações com a organização dos serviços
– Prover informações precisas sobre as configurações
– Permitir o controle da infra-estrutura através da monitoração e manutenção da informação sobre:
Todos os recursos necessários para o fornecimento do serviço
Estado (status) do IC e seu histórico
Relacionamentos dos IC
– Criar e manter o banco de dados de configuração (CMDB)

ITIL – v3 – A Evolução