Prof. Emiliano S. Monteiro

Transcrição

1 Prof. Emiliano S. Monteiro

2 Nível 1: caótico, a empresa não possui processos. Todo o serviço é realizado sob demanda conforme as tarefas vão chegando e os problemas aparecendo vivem fazendo coisas pra ontem e apagando fogo, existem porque o mercado de software aceita a má qualidade de produtos. Nível 2: repetitivo, são empresas que operam baseadas em processos documentados ou rotinas operacionais, adotam o que já funcionou antes pode ser usado novamente. Nível 3: definido, aplica os processos corretos para cada tipo de projeto, não possui heróis, as pessoas entendem os processos, sua utilidade e importância. Microsoft PowerBI Qlik Tableau

3 Nível 4: gerenciado, possui a capacidade de prever problemas que irão surgir, detectam durante o desenvolvimento tendências que mostram a variação do rumo, possuem planos de contingência e percebem quando um problema se instalou no projeto. Nível 5: otimizado, acrescentam a qualidade como um valor agregado ao produto ou serviço, que é parte essencial da natureza da empresa. Sempre procura alternativas para melhorar, inclui o uso de bancos de dados de projetos e coleta de dados sobre seus processos.

4 Contém melhores práticas. Que são utilizadas na diversas etapas dos processos de desenvolvimento. O CMMI é uma evolução do CMM. Tenta estabelecer um modelo unificado de processo. Ver: TOGAF - The Open Group Architecture Framework

5

6 ISO/IEC define processo de Engenharia de Software (evolução da ISO/IEC 12207) ISO/IEC ou Spice + Modelos de maturidade

7 Foco em Melhoria do processo e determinação da capacidade do processo : Consiste de um framework de avaliação, contendo: Facilita o auto-julgamento Desperta consciência do contexto Produz um perfil do processo Direciona a adequação das atividades Apropriado para organizações de diversos tamanhos As empresas poderão identificar quais os processos que devem melhorar, o que deverá ser feito para este fim e deduzir onde devem investir em primeiro lugar, com vista à obtenção de retornos rápidos e significativos.

8 O SPICE é composto por 9 partes: parte 1: Conceitos e Guia Introdutório parte 2: Modelo de Gerenciamento de Processo parte 3: Avaliação do Processo parte 4: Guia para Condução de uma Avaliação parte 5: Construção, Seleção e Uso das Ferramentas de Avaliação parte 6: Qualificação e Treinamento dos Avaliadores parte 7: Guia para o Processo de Melhoria parte 8: Guia para Orientação da Determinação da Capacidade do Processo parte 9: Dicionários

9

10

11

12 Tecnologia da Informação - A avaliação de processos, também denominada Melhoria de Processo de Software e Determinação de Capacidade (SPICE), é um conjunto de documentos de normas técnicas para o processo de desenvolvimento de software de computador e funções relacionadas de gestão de negócios. ISO / IEC é o modelo de referência para os modelos de maturidade. A ISO / IEC contém um modelo de referência. O modelo de referência define uma dimensão de processo e uma dimensão de capacidade.

13 É uma norma internacional É composta de cinco partes É genérica, não é mais dedicada apenas ao software Contém o conceito de modelo de referência. O modelo de referência de processo é contém uma descrição de escopo e uma descrição de requisitos. Tais requisitos estabelecem os resultados esperados da execução de cada processo.

14 A dimensão do processo define processos divididos em cinco categorias de processo: Fornecedor e cliente Engenharia Apoio/suporte Gestão/administração organização

15 Processos da categoria cliente tem impacto direto sobre os consumidores. Processos da categoria engenharia estão relacionados com a implementação do produto. Processos da categoria suporte estão relacionados com solução de problemas Processos da categoria gestão estão relacionados com a administração de todos os processos e projetos. Processos da categoria organização estão relacionados com o funcionamento da empresa como um todo.

16 1.1. Execução 2.1. Administração do processo 2.2. Administração dos produtos obtidos do processo 3.1. Definição 3.2. Implementação 4.1. Medição 4.2. Controle 5.1. Inovação 5.2. Otimização

17 0 incompleto 1 executado 2 gerenciado 3 estabelecido 4 previsível 5 otimizado

18 0% a 15% - Não atingido - N 16 a 50% - Parcialmente atingido - P 51 a 85% - largamente atingido - L 86 a 100% - totalmente atingido - T

19

20

21 ISO: Organização Internacional de Normalização (International Organization for Standardization). IEC: International Electrotechnical Commission, IEC) é uma organização internacional de padronização de tecnologias elétricas, eletrônicas e relacionadas

22 Systems and software engineering Software life cycle processes. É um padrão para o ciclo de vida de processos de software. É o padrão que define todas as tarefas necessárias para o desenvolvimento e manutenção de software. Não define um ciclo de vida em especial, mas uma linha geral para que um determinado ciclo de vida possa ser adotado... Por exemplo: não define que uma empresa deva usar RUP ou SCRUM!

23 Seus principais processos estão agrupados nas seguintes 3 categorias: primários, suporte/apoio e organizacional:

24 1. Aquisição: Compra de componentes ou compra de software de prateleira 2. Fornecimento: É voltado para o fornecedor e sua necessidade de preparar uma proposta para atender um pedido ou contrato de desenvolvimento. 3. Desenvolvimento: levantamento, análise, projeto, codificação, integração, etc. 4. Operação: utilização do sistema como atividades de suporte aos usuários. 5. Manutenção: é executado quando o software necessita passar por melhorias e adaptações.

25 1. Documentação: É o registro de atividades produzidas por quaisquer outros processos do ciclo de vida. Inclusive editar documentos para os stakeholders 2. Gerencia da configuração: Gerenciar os artefatos produzidos e suas diversas versões. Mantendo um repositório de códigos, documentação e diagramas. Manter o change log. 3. Gerencia da Qualidade: É a verificação da satisfação com os clientes sobre os produtos entregues e sua conformidade com o que foi planejado. 4. Processo de verificação: Verificação de qualidades estáticas do programa, ou seja, independem do mesmo estar em execução ou não, são analisados diagramas, contratos, pedidos, requisitos, códigos, etc.

26 5. Validação: Determina se o produto final cumpre o que foi solicitado. 6. Revisão conjunta: São avaliados tanto as atividades do processo como o que esta sendo produzido, é uma tarefa executada tanto pelo executor como por um terceiro. 7. Auditoria: Inclui atividades para garantir que os produtos fora, testados corretamente e que correspondem a documentação, garante que todos os testes foram executados para avaliação cada requisito. 8. Resolução de problemas: Inclui resolver problemas de qualquer natureza entre eles os de não conformidade localizadas em produtos, especificações e processos.

27 1. Processos de gerência: Quaisquer atividades e tarefas genéricas utilizadas para gerenciar os demais processos. Exemplo: planejamento, distribuição de atividades, estimativas de risco e controle de qualidade. 2. Processos de infraestrutura: criar e manter uma infraestrutura mínima para a execução das atividades: hardware, software, comunicação, etc. 3. Processos de melhoria: inclui atividades de análise para identificar pontos fracos e chances de melhorias nos demais processos. 4. Processos de treinamento: treinamento na norma, treinamentos no ciclo de vida adotado.

28 1. Processos de gerência: Quaisquer atividades e tarefas genéricas utilizadas para gerenciar os demais processos. Exemplo: planejamento, distribuição de atividades, estimativas de risco e controle de qualidade. 2. Processos de infraestrutura: criar e manter uma infraestrutura mínima para a execução das atividades: hardware, software, comunicação, etc. 3. Processos de melhoria: inclui atividades de análise para identificar pontos fracos e chances de melhorias nos demais processos. 4. Processos de treinamento: treinamento na norma, treinamentos no ciclo de vida adotado.

29 SQuaRE Software product Quality Requirements and Evaluations. Divisões da SQuaRE: 1. ISO/IEC 2500n Divisão de Gestão da Qualidade 2. ISO/IEC 2501n Divisão de Modelo de Qualidade 3. ISO/IEC 2502n Divisão de Medição de Qualidade 4. ISO/IEC 2503n Divisão de Requisitos de Qualidade 5. ISO/IEC 2504n Divisão de Avaliação da Qualidade

30 A SQuaRE envolve amplamente a avaliação de vários tipos de softwares independente de sua finalidade e criam um modelo para realizar uma avaliação. Seus documentos são didáticos e com vários exemplos. As divisões são as seguintes: 1. Gerenciamento: são documentos voltados para todos os usuários envolvidos na aplicação desta norma, apresenta uma introdução geral a todo o conjunto da norma.

31 2. Modelo de qualidade: Define conceitos de qualidade externa e interna ao produto. Permite orientar perspectivas de avaliação. Por exemplo: o ponto de vista dos programadores, dos clientes e usuários. Cada ator envolvido fornece seu ponto de vista. 3. Medição: Definição de medição e como realizar a tarefa de medição. 4. Requisitos de qualidade: É necessário que valores sejam estabelecidos como parâmetros para avaliação, não adianta apenas medir, estes valores vem dos requisitos. 5. Avaliação: o término da avaliação de qualidade é uma comparação entre o que foi medido e os que foi especificado pelo usuário.

32 Qualidade de uso: é o ponto de vista do usuário, refere-se ao a utilização do sistema em execução. Qualidade externa: Testes de funcionamento do sistema, desde subrotinas até módulos completos. Qualidade interna: arquitetura interna do produto, qualidade do código, complexidade, etc.

33 Qualidade externa/interna Funcionalidade Manutenibilidade Usabilidade Confiabilidade Eficiência Portabilidade Segurança Precisão Interoperabilidade Adequabilidade Testabilidade Estabilidade Modificabilidade Analisabilidade Atratividade Compreensibilidade Apreensibili-dade Operabilidade Maturidade Tolerância a falhas Recuperabilidade Comportamento temporal Utilização de recursos Adaptabilidade Instalabilidade Co-existência Substitutibilidade Qualidade em uso!

34 CMMI ISO ISO Governo através do Softex + empresas privadas + universidades MPS.BR Modelo de referência Modelo de avaliação Modelo de Negócio

35 Melhoria de Processo de Software Brasileiro Desenvolvida pela SOFTEX. Segue as principais abordagens internacionais para: definição, avaliação e melhoria de processos de software. Possui 7 níveis de maturidade Compatível com o CMMI Criados no Brasil Custo acessível Avaliação bienal de empresas certificadas. Contém os requisitos que as empresas devem cumprir para serem certificadas.

36 Melhor A Em otimização B Gerenciado quantitativamente C Definido D Largamente definido E Parcialmente definido F Gerenciado G Parcialmente Gerenciado Pior

37 Melhor A B C D E F G Inovação e implantação na organização Análise de causas e resolução Desempenho do processo organizacional Gerência quantitativa do projeto Análise de decisão e resolução Gerência de riscos Desenvolvimento de requisitos Solução técnicas Integração de produto Instalação de produto Liberação de produto Verificação Validação Treinamento Avaliação e melhoria do processo organizacional Definição do processo organizacional Adaptação do processo para gerência de projeto Medição Gerência de configuração Aquisição Garantia da qualidade Gerência de requisitos Gerência de projetos Pior

38

39 1. TOGAF - The Open Group Architecture Framework 2. COBIT - Control Objectives for Information and related Technology 3. ITIL - Information Technology Infrasructure Library 4. MOF - Microsoft Operations Framework

40

41

42 Administrador Gerente Desenvolvedor Relator Visualizador

43

44

45

46

47

48

49

50

51

52

53

54 Novo - Este é o status de chegada de novos problemas. As questões permanecem neste status até que sejam atribuídas, reconhecidas, confirmadas ou resolvidas. O próximo status pode ser reconhecido", "confirmado", "atribuído" ou "resolvido". Reconhecido/Admitido - Este status é usado pela equipe de desenvolvimento para refletir seu acordo com a solicitação de recurso sugerida. Ou para concordar com o que o técnico/analista está sugerindo em um relatório sobre o assunto, embora eles ainda não tentaram reproduzir o que o técnico/analista está se referindo. O próximo status é tipicamente "atribuído" ou "confirmado". Confirmado - Este status é normalmente usado pela equipe de desenvolvimento para mencionar que eles concordam com o que o técnico/analista está sugerindo na questão e que eles confirmaram e reproduziram a questão. O próximo status é tipicamente "atribuído".

55 Atribuído - Esse status é usado para refletir que o problema foi atribuído a um dos membros da equipe e que esse membro da equipe está trabalhando ativamente no problema. O próximo status normalmente é "resolvido". Resolvido - Este status é usado para refletir que o problema foi resolvido. Um problema pode ser resolvido com uma de muitas resoluções (personalizável). Por exemplo, um problema pode ser resolvido como "fixo", "duplicado", "não irá corrigir", "nenhuma alteração necessária", etc. Os status seguintes são tipicamente "fechados" ou no caso de o problema ser reaberto, Então seria "feedback". Fechado - Este status reflete que o problema está completamente fechado e não são necessárias ações adicionais sobre ele. Também normalmente oculta o problema da página Exibir problemas. Algumas equipes usam "fechado" para refletir a assinatura do técnico/analista e outros o usam para refletir o fato de que a correção foi liberada para os clientes.

56 Novo Fechado Retorno Admi -tido Atribuído Comfirmado Resolvido

57 Novo Fech ado Fechado Retorno (Reaberto) Retor no Resol vido Admi tido Atrib uído Confir mado

58

59

60