Prof. Guilherme Alexandre Monteiro Reinaldo Recife

Apresentação em tema: "Prof. Guilherme Alexandre Monteiro Reinaldo Recife"— Transcrição da apresentação:

1 Prof. Guilherme Alexandre Monteiro Reinaldo Recife
Qualidade de Software Prof. Guilherme Alexandre Monteiro Reinaldo Recife

2 Contatos Prof. Guilherme Alexandre Monteiro Reinaldo
Apelido: Alexandre Cordel /gtalk: Site: Celular: (81)

3 Agenda Contextualização/Introdução Visão Geral da norma
Composição da norma Modelo de Processo ( ) Avaliação de Processo ( e ) Melhoria de Processo ( ) Considerações Referências

4 Sucessos e Fracassos de Software Conflitos entre Teoria e Prática
Contexto Aumento da Importância do Software “Software está em tudo: Elemento crítico na infra-estrutura do mundo” Sucessos e Fracassos de Software Conflitos entre Teoria e Prática

5 Situação Atual da Maioria das Organizações de Software
Abandono de planos e procedimentos Produto funciona, mas com defeitos; prazo e custo maiores; e menos funcionalidade Acúmulo de trabalho Pouca repetibilidade Sucesso depende muito do esforço heróico das pessoas Clientes e funcionários insatisfeitos adaptado do ESI, 1998

6 Situação Atual da Maioria das Organizações de Software
Abandono de planos e procedimentos Produto funciona, mas com defeitos; prazo e custo maiores; e menos funcionalidade Acúmulo de trabalho Demanda por Melhor Qualidade! melhor qualidade inclui: menos prazos, custos, defeitos, insatisfações, mais qualidade dos produtos, previsibilidade, produtividade, competitividade, e melhores resultados de negócio (ROI) Pouca repetibilidade Sucesso depende muito do esforço heróico das pessoas Clientes e funcionários insatisfeitos adaptado do ESI, 1998

7 Situação Atual da Maioria das Organizações de Software
Abandono de planos e procedimentos Produto funciona, mas com defeitos; prazo e custo maiores; e menos funcionalidade Como as empresas de software podem obter a melhoria viável e necessária? Acúmulo de trabalho Pouca repetibilidade Sucesso depende muito do esforço heróico das pessoas Melhoria do Processo de Software baseada em Modelos Clientes e funcionários insatisfeitos adaptado do ESI, 1998

8 Processo de Software Melhoria busca processos:
É o que as pessoas fazem, utilizando métodos, ferramentas, etc., para adquirir, desenvolver, manter e melhorar software e produtos associados Melhoria busca processos: praticado = treinado = documentado, efetivo, eficiente, apropriado às pessoas, flexível, medido, gerenciado, controlado, melhorado constantemente.

9 Histórico Em 1993, a ISO (International Organization for Standardization) realizou um estudo sobre as necessidades e requisitos de um padrão internacional para avaliação de processos de software. Conclusões: Consenso sobre a necessidade de um padrão internacional para avaliação de processos de software; Os resultados deveriam ser utilizados o mais breve possível, garantindo que o padrão atendesse completamente a seus requisitos. Criado o projeto SPICE (Software Process Improvement and Capability dEtermination): equipe responsável pelo desenvolvimento das versões iniciais da norma e por coordenar a utilização destas na comunidade.

10 Histórico 1993: estudo da ISO sobre as necessidades e os requisitos de um padrão internacional para avaliação de processos de Software; : criação do projeto SPICE e elaboração da versão inicial; Realização de trials - Fase 1 (35 avaliações); 1996: Versão PDTR (Previous Draft Technical Report); 1997: Versão DTR (Draft Technical Report), Trials - Fase 2 (70 avaliações); 1998: Versão TR (Technical Report), denominada de ISO/IEC TR 15504: Information Technology - Software Process Assessment; : Transformação em Norma ISO/IEC 15504; 2003: Inicia a publicação como Norma ISO/IEC 15504, denominada de ISO/IEC 15504: Information Technology - Process Assessment. ISO – International Organization for Standardization IEC - International Electrotechnical Commission

11 Visão Geral da Norma ISO/IEC 15504
Framework: Define requisitos para Avaliação de Processo; Na prática, é utilizado com Modelo de Referência para Melhoria de Processo. Avaliação em 2 Contextos: Melhoria Contínua Entender o estado dos processos Avaliação identifica oportunidades de melhoria Foca na melhoria de processo Determinação da Capacidade Determinar a adequação dos processos Geralmente realizada para uma organização interessada em contratar a organização avaliada como fornecedor ISO/IEC 15504

12 Utilização da 15504

13 Modelo de Referência Um Modelo de Referência de Processo define basicamente um conjunto de processos que representam melhores práticas de um determinado domínio. Um exemplo de um modelo de referência de processo é a nova versão da Norma ISO/IEC

14 Modelo para Avaliação de Processo
Um Modelo para Avaliação de Processo deve ser: baseado em um Modelo de Referência de Processo, e detalhar os processos (todos ou alguns) de forma a viabilizar uma avaliação de processo e também detalhar a estrutura de medição. Exemplos: CMMI, ISO , OOSpice e MR-MPS

15 Método de Avaliação de Processos
Um método de avaliação de processo para ser conforme com a 15504, tem que satisfazer três requisitos básicos: ser verificada por um avaliador competente; ter como referência um modelo de avaliação de processo compatível (ex ); ser realizada seguindo um processo compatível. Exemplos: QuickLocus, SCAMPI, MA-MPS

16

17 Composição da ISO/IEC 15504 : Conceitos e Vocabulário (Concepts and Vocabulary) Normativo - Publicação 2004 : Executando uma Avaliação (Performing an Assessment) Normativo - Publicação 2003 : Guia sobre Executando uma Avaliação (Guidance on performing an assessment) Informativo - Publicação 2004 : Guia sobre Utilização do Resultado de Avaliação (Guidance on using assessment results) : Um Exemplo de Modelo de Avaliação de Processo (An exemplar process assessment model) Informativo - Publicação 2005

18 Modelo de Processo da ISO 15504
A arquitetura dos modelos é denominada de arquitetura contínua, com duas dimensões: dimensão de processo dimensão de capacidade de processo. nível de capacidade de processos pa pb pn processos A define um exemplo de um modelo compatível com a 15504: denominado de ISO/IEC , e representa um conjunto de melhores práticas para a engenharia de software.

19 Modelo de Processo da ISO 15504
A organiza estas em duas grandes categorias: aquelas relacionadas a “o que fazer”, organizadas em processos específicos; (“dimensão de processos”) aquelas relacionadas ao “quão bem fazer qualquer coisa que seja feita”, organizadas em níveis de capacidade genéricos. (“dimensão de capacidade”)

20 15504-5:Dimensão de Processos
48 processos que estão organizados em 3 categoria de processo e 10 grupos de processo. Fundamentais Organizacionais Aquisição Fornecimento Engenharia Operação Gerência Melhoria de Processo Recursos e Infra-estrutura Reuso Apoio Controle de Configuração Garantia da Qualidade

21 PROCESSOS ISO/IEC :2006

22 15504-5:Dimensão de Processos
Cada processo é descrito com os seguintes seis elementos: Identificação (process identifier); Nome (process name); Propósito (process purpose); Resultados (Outcomes); Práticas base (base practice): Produtos de trabalho (work-products).

23 15504-5:Dimensão de Processos
Resultados (Outcomes): Descreve os resultados esperados de uma implementação com sucesso deste processo. Práticas base (base practice): Atividade que quando executada de forma consistente, contribui para o atendimento do propósito de um processo. Para cada prática base estão relacionados os resultados (outcomes) que a prática ajuda a alcançar. Produtos de trabalho (work-products): Os produtos de trabalho de um processo são aqueles esperados de serem utilizados e/ou produzidos pela execução do processo. A lista de produtos de trabalho para cada processo deve ser utilizada como orientação para avaliação ou melhoria do processo.

24 Exemplo: Processo de Aquisição - The Acquisition Process Group (ACQ)
Identificação: ACQ.1 Nome: Prepara para aquisição (Acquisition preparation ) Propósito: estabelecer as necessidades e objetivos da aquisição e comunicá-los aos potenciais fornecedores. Resultados: R1 - o conceito ou a necessidade de aquisição, desenvolvimento ou melhoria é estabelecido; R2 - os requisitos de aquisição necessários, definindo as necessidades do projeto, são definidos e validados; R3 - os requisitos conhecidos do cliente são definidos e validados; R4 - uma estratégia de aquisição é desenvolvida; e R5 - os critérios de seleção do fornecedor são definidos. Práticas Base: ACQ.1.BP1: Establish the need. Establish a need to acquire, develop, or enhance a system, software product or service. [Outcome: 1] ACQ.1.BP2: Define the requirements. Identify the customer/stakeholder requirements for a system and/or software product or service. [Outcomes: 2, 3] ACQ.1.BP3: Review requirements. Analyze and validate the defined requirements against the identified needs. Validate the requirements to reduce risk of misunderstanding by the potential suppliers. [Outcome: 3] ACQ.1.BP4: Develop acquisition strategy. Develop a strategy for the acquisition of the product according to the acquisition needs. [Outcome: 4] Note 1: The strategy may include reference to the life cycle model, schedule and selection criteria. ACQ

25 Dimensão da Capacidade de Processo
Em uma organização vários processos podem ter níveis de capacidade variáveis A define 6 níveis de capacidade Seqüenciais e cumulativos Os níveis podem ser usados: para avaliar como uma organização está realizando um determinado processo Como guia para a melhoria Cada nível de capacidade é descrito basicamente por um nome, definição e atributos.

26 Níveis de Capacidade

27

28 E o que são Processos O Processo envolve uma entrada (input), um processamento e uma saída (output). A busca da melhoria no processo de desenvolvimento exige tomadas de decisão convenientes e com determinado propósito.

29 Tomadas de Decisão É o Processo pelo qual são escolhidas algumas ou apenas uma entre muitas alternativas para as ações a serem realizadas.

30 Decisão em Processos Os processos envolvem decisões que são as escolhas tomadas com base em propósitos, são ações orientadas para determinado objetivo e o alcance deste objetivo determina a eficiência do processo de tomada de decisão. A decisão pode ser tomada a partir de probabilidades, possibilidades e/ou alternativas. Para toda ação existe uma reação e, portanto, são nas reações que são baseadas as decisões.

31 Decisão em Processos A decisão é mais do que a simples escolha entre alternativas, sendo necessário prever os efeitos futuros da escolha, considerando todos os reflexos possíveis que ela pode causar no momento presente e no futuro. Modernamente entende-se que é impossível encontrar num processo de decisão a melhor alternativa o que faz com que sejam buscadas as alternativas satisfatórias, ou seja, na prática o que se busca é a alternativa que, mesmo não sendo a melhor, leve para o alcance do objetivo da decisão.

32 Tomada de Decisão Segundo Chiavenato (1997), as decisões possuem fundamentalmente seis elementos: Tomador de decisão – pessoa que faz a seleção entre várias alternativas de atuação. Objetivos – propósito ou finalidade que o tomador de decisão almeja alcançar com sua ação. Preferências – critérios com juízo de valor do tomador de decisão que vai distinguir a escolha. Estratégia – direção ou caminho que o tomador de decisão sugere para melhor atingir os objetivos e que depende dos recursos que se dispõe. Situação: aspectos ambientais dos quais vela-se o tomador de decisão, muitos dos quais fora do controle, conhecimento ou compreensão e que afetam a opção. Resultado: é a decorrência ou resultante de uma dada estratégia definida pelo decisor.

33 Tomada de Decisão Entende que o processo de decisão desenvolve-se em sete etapas, a saber: Percepção da situação que abrange algum problema; Diagnóstico e definição do problema; Definição dos objetivos; Busca de alternativas de solução ou de cursos de ação; Escolha da alternativa mais apropriada ao alcance dos objetivos; Avaliação e comparação dessas alternativas; Implementação da alternativa escolhida.

34 Dinâmica - Estratégia Problema do Desafio do Astronauta

35 Dinâmica - Resposta Em termos aéreos, 150 Km representa apenas poucos minutos. Em pouco tempo o avião será encontrado. Rapidamente será sentida a falta do avião. No máximo, em 5 horas, que era o tempo previsto para o vôo, as buscas começarão. A estratégia é: Manter todos juntos, próximos do avião, e aguardar o socorro. É fundamental: Estar preparado e orientar o resgate; Manter-se vivo; Manter a sobrevivência por um período maior, se for necessário.

36 Dinâmica - Estratégia O quadro a seguir estabelece a utilidade de cada um dos objetos para esta situação específica: Óculos - Sem utilidade prática. Se fosse na neve ele protegeria a visão Bússola - Idem, já que todos devem permanecer nas proximidades do avião Sal - Extremamente prejudicial à saúde, sal e sol é uma mistura explosiva Canivete - Sem utilidade aparente Água - Útil, mas o ser humano sobrevive alguns poucos dias sem ela. Cobertor - À noite no deserto o frio facilmente atinge a temperatura abaixo de zero Lona - Útil para proteger do sol escaldante do dia Espelho - Extremamente útil para dar sinal em caso de aproximação de socorro Comida - Útil, mas disponível uma vez que o socorro deverá chegar em breve Mapa - Desnecessário, uma vez que todos deverão permanecer juntos aguardando o socorro.

37 Dinâmica - Estratégia Assim, a ordem mais ou menos correta é: 1. Espelho 2. Lona 3. Cobertor 4. Água 5. Comida 6. Canivete 7. Óculos 8. Bússola 9. Mapa 10. Sal Para verificar a sua performance, calcule o seu desvio, fazendo a diferença absoluta da suas respostas com a referência da tabela acima.

38 Contextualização/Introdução
Visão Geral da norma Composição da norma Modelo de Processo (ISO ) Avaliação de Processo (ISO e ISO ) Melhoria de Processo (ISSO ) Considerações Referências

39 Avaliação de Processo com a ISO 15504
A define os requisitos para uma avaliação compatível com a E incluindo os principais elementos de um processo de avaliação de processo.

40 Elementos de um processo de avaliação de processo:

41 Requisitos para uma avaliação compatível com a 15504:

42 Pontuação de Atributo de Processo
Um valor tem que ser atribuído a cada atributo de processo, baseado nos dados validados. composta pelos seguintes quatro valores: “N”: o atributo não foi atingido pelo processo (Null) ; “P”: o atributo foi atingindo apenas parcialmente pelo processo (Parcial); “L”: o atributo foi atingido largamente pelo processo (Large); e “F”: o atributo foi atingido completamente (em inglês, fully) pelo processo. Para estar em um nível de capacidade, um processo tem que ter notas “L” ou “F” nos atributos do nível e “F” em todos os atributos dos níveis anteriores.

43 Exemplos de Pontuação de Atributos de Processo

44 Contextualização/Introdução
Visão Geral da norma Composição da norma Modelo de Processo (ISO ) Avaliação de Processo (ISO e ISO ) Melhoria de Processo (ISSO ) Considerações Referências

45 Melhoria de Processo (ISO 15504)
A ISO/IEC descreve um guia para orientação da melhoria de processo, tendo como referência um modelo de processo e como uma das etapas a realização de uma avaliação de processo

46 Melhoria de Processo ISSO/IEC 15504-4
8 - Monitorar desempenho 7 - Matem melhoria 6 - Confirmar melhoria 1 - Examinar necessidades da organização 5 -Implementa melhoria 2 - Inicia processo de melhoria 3 - Avalia Processo 4 - Planeja Melhoria

47 Considerações Finais Não pressupõe modelos de ciclo de vida de software, tecnologias de software ou metodologias de desenvolvimento. O ISO/IEC não define um método explícito de avaliação, define os requisitos para o Método de Avaliação de Processos. Na prática, uma avaliação de processos de software é conduzida utilizando o Modelo de Avaliação de Processos e não o Modelo de Referência de Processos.

48 MPS.Br

49 Qualidade em software via MPS.BR / Gerenciamento de Projetos
[ Qualidade do produto de software É obtida por meio de Qualidade do processo de desenvolvimento de software É alcançada mais facilmente se baseada em O que é MPS.BR? Modelo de maturidade (MPS.BR) Tem como base Gerenciamento de projetos

50 MPS.BR Modelo de Referência (MR-MPS) Método de Avaliação (MA-MPS)
O MPS.BR é um programa para Melhoria de Processo de Software Brasileiro e está dividido em 3 componentes: Modelo de Referência (MR-MPS) Método de Avaliação (MA-MPS) Modelo de Negócio (MN-MPS)

51 MR-MPS A B C D E F G 5 Em Otimização 4 Gerenciado Quantitativamente
2 3 4 5 Em Otimização B Gerenciado Quantitativamente C Definido D Largamente Definido E Parcialmente Definido F Gerenciado G Parcialmente Gerenciado Relacionamento com o CMMI MR-MPS

52 MN-MPS: Modelo de Negócio
II-MPS.BR & IA-MPS.BR Programa MPS.BR (SOFTEX) Convênio Contrato Contrato MNC MNE Convênio, se pertinente LEGENDA: II-MPS.BR – Instituição Implementadora do Modelo MPS.BR IA-MPS.BR – Instituição Avaliadora do Modelo MPS.BR MNE – Modelo de Negócio Específico para cada empresa (personalizado) MNC – Modelo de Negócio Cooperado em grupo de empresas (pacote)

53 Porque MPS.BR? Acesso à melhoria de processos a pequenas e médias em empresas em larga escala. Compatibilidade com os padrões de qualidade aceitos internacionalmente. Caminho evolutivo mais suave e incremental que outros modelos.

54 Referências Melhoria e Avaliação de Processo com ISO/IEC :2006, Clênio Figueiredo Salviano. – Lavras: UFLA, 2006. The International Organization for Standardization and the International Electrotechnical Commission, ISO/IEC Information Technology - Process Assessment