Gerenciamento de Projetos de Governança em TI

Transcrição

1 Gerenciamento de Projetos de Governança em TI Universidade Veiga de Almeida Luiz Antônio Vivacqua Corrêa Meyer

2 Sumário Qualidade de software Motivação Conceito de Qualidade Definição Garantia de Qualidade Controle de Qualidade Métricas Modelos e Padrões de Qualidade de Software Normas ISO CMM CMMI

3 Motivação Qualidade na engenharia de software é similar a qualidade em outra engenharias. Semelhanças: 1. definição do produto que se deseja construir; 2. Análise dos requisitos 3. Definição da arquitetura macro e construção do projeto detalhado; 4. Fabricação ou desenvolvimento; 5. Entrega Diferenças: 1. Software é intangível 2. Mais sujeito ao erro humano => dada uma especificação de software a 2 programadores o resultado será igual?

4 Motivação Grande utilização de software nas mais diversas áreas A complexidade dos sistemas aumentando Concorrência de fornecedores de SW Preocupação crescente em desenvolver Software com QUALIDADE!

5 Conceito de Qualidade DEFINIÇÕES: A totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas ISO9126 Necessidades explícitas são as condições e objetivos propostos por aqueles que produzem o software. Necessidades implícitas são as necessidades subjetivas dos usuários, também chamadas de fatores externos, e podem ser percebidas tanto pelos desenvolvedores como pelos usuários.

6 Conceito de Qualidade DEFINIÇÕES: A conformidade com requisitos funcionais e de desempenho explicitamente declarados, normas de desenvolvimento explicitamente documentadas e características implícitas, que são esperadas em todo software desenvolvido profissionalmente PRESSMAN qualidade em conformidade com requitos funcionais e não funcionais presentes nos documentos de especificação do sistema.

7 Conceito de Qualidade Requisitos funcionais: um requisito de sistema de software que especifica uma função que o sistema ou componente deve ser capaz de realizar. Estes são requisitos de software que definem o comportamento do sistema, ou seja, o processo ou transformação que componentes de software ou hardware efetuam sobre as entradas para gerar as saídas. Esses requisitos capturam as funcionalidade sob o ponto de vista do usuário.

8 Conceito de Qualidade Requisitos funcionais Exemplo: O sistema deve permitir a inclusão, alteração e remoção de funcionários com os seguintes atributos: nome, endereço, cidade,etc). O usuário deve ser capaz de buscar todo o conjunto inicial do BD ou selecionar um subconjunto a partir dele. O sistema fornecerá telas apropriadas para o usuário ler documentos. Cada pedido tem um único identificador.

9 Conceito de Qualidade Requisito não funcional Um requisito não funcional de software é aquele que descreve não o que o sistema fará, mas como ele fará. Assim, por exemplo, têm-se requisitos de desempenho, requisitos da interface externa do sistema, restrições de projeto e atributos da qualidade. A avaliação dos requisitos não funcionais é feita, em parte, por meio de testes, enquanto que outra parte é avaliada de maneira subjetiva.

10 Conceito de Qualidade Requisitos não funcionais: Organizacionais: refere-se a políticas e procedimentos nas organizações do cliente e do desenvolvedor. de entrega, de implementação, padrões de processo Externos: refere-se a fatores externos ao sistema e ao seu processo de desenvolvimento. interoperabilidade (interação do sistema com outros), éticos, legais (privacidade e de segurança) De produto: especificam o comportamento do produto. eficiência (desempenho, espaço, rapidez, memória), confiabilidade, portabilidade.

11 Conceito de Qualidade Requisitos não funcionais Exemplo: Organizacional: o processo de desenvolvimento de sistema e os documentos a serem entregues deverão estar de acordo com o processo e os produtos a serem entregues definidos em XYZKL. Externo: o sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes. De produto: toda comunicação necessária entre o ambiente X e o usuário deve ser expressa no conjunto padrão de caracteres ANSI.

12 Qualidade Os requisitos de um software são a base para a avaliação da qualidade do sistema desenvolvido. Mesmo que o produto final não apresente erros do ponto de vista da codificação em si, se o software não tem uma boa relação com o efetivamente esperado pelo usuário, ele apresenta baixa qualidade. Normas de desenvolvimento auxiliam o processo de desenvolvimento de software, uma vez que reúnem a partir de um conjunto de experiências anteriores, técnicas e métodos que tem por objetivo a garantia de construção de software com qualidade.

13 Garantia de Qualidade FOCO: PREVENÇÃO DE ERROS - é o conjunto de atividades sistemáticas a serem realizadas visando assegurar a adequação do artefato como um todo Sob o ponto de vista da qualidade de software compreende uma série de ações que visam medir o grau de qualidade encontrado no produto avaliado e assegurar que atenda às especificações explícitas e implícitas. As atividades de garantia de qualidade de software são focadas na prevenção de defeitos e problemas.

14 Controle de Qualidade Foco: DETECÇÃO e CORREÇÃO - Compreende atividades de monitoração de resultados específicos do projeto, com a finalidade de determinar sua aderência a padrões de qualidade e identificar causas de resultados insatisfatórios. Deve ser executado ao longo do desenvolvimento do software por membros da equipe de desenvolvimento ou (idealmente) por pessoas que tenham independência com relação a equipe de desenvolvimento de software. Uma das principais atividades são os testes, as inspeções e as revisões

15 Métricas Uma métrica útil sempre tem um cliente. O cliente dessa métrica é a pessoa, ou pessoas, que irá tomar decisões com base na informação gerada pela métrica. Se uma métrica não tem um cliente, ou seja, se não existe uma pessoa que vai utilizá-la para tomada de decisão, então a métrica não tem sentido para a organização. Em outras palavras, é preciso responder à seguinte pergunta: Quem precisa da informação? Quem irá usar esta métrica?

16 Métricas Importante para medir a qualidade do software Estratégia Goal-Question-Metric (GQM) Basili Define um modelo de medição de SW em 3 níveis: meta, pergunta e métrica Meta => é o que se deseja atingir ao aplicar o modelo, um objetivo mensurável. Por exemplo, deseja-se melhorar a usabilidade do software, diminuir a quantidade de bugs encontrados e melhorar a performance do sistema.

17 Métricas Pergunta => é representada por uma série de questões que visam verificar o resultado do trabalho. Por exemplo: a usabilidade do software melhorou para os clientes? O número de bugs reportados diminuiu? A performance do sistema melhorou na última iteração? Métrica => deve estar associada à pergunta a ser respondida para que esta possa ser respondida de uma maneira mensurável. Podem ser objetivas (quando não dependem da interpretação de uma pessoa) ou subjetivas

18 Métricas EXEMPLOS: Levando-se em consideração a meta: garantir que todos os defeitos conhecidos sejam solucionados antes da liberação do produto, perguntas a serem definidas podem ser: Quantos defeitos nós temos por produto? Qual o status de cada defeito? Neste caso, métricas podem ser definidas como Número de defeitos e Número de defeitos por status

19 Métricas EXEMPLOS: Avaliação dos usuários em relação a usabilidade do software; Quantidade de bugs encontrados na última iteração comparado a quantidade média de bugs por iteração; Tempo de resposta do sistema para uma determinada tarefa em relação a este tempo algumas iterações atrás.

20 Modelos e Padrões de Qualidade de Software Diversos modelos de qualidade de software vêm sendo propostos ao longo dos últimos anos Normas ISO International Organization for Standarddization é uma organização não governamental fundada em 1947 com sede na Suiça. Motivação => necessidade de referências internacionais para regulamentar obrigações contratuais entre fornecedores e compradores, que focalizassem a garantia de manutenção e uniformidade da qualidade de produtos.

21 Normas ISO para Suporte ao Desenvolvimento de Software Nome Norma ISO/IEC 9126(NBR 13596) Norma ISO/IEC Norma ISO/IEC Norma ISO/IEC Norma ISO/IEC Norma ISO15504 Descrição Define as características de qualidade de software que devem estar presentes em todos os produtos (Funcionalidade, Confiabilidade, Eficiência, Usabilidade, Manutenibilidade e Portabilidade); Estabelece os requisitos de qualidade para pacotes de software; Define um processo de avaliação da qualidade de produto de software; Define um processo de ciclo de vida de software; Apresenta diretrizes para a aplicação da ISO 9001 por organizações que desenvolvem software ao desenvolvimento, fornecimento e manutenção de software; Aprovada como norma em 2003 é focada na avaliação de processos organizacionais.

22 Norma ISO/IEC 9126(NBR 13596) Especifica 3 níveis de qualidade: Qualidade Interna É a totalidade das características do produto de software do ponto de vista interno. Ela é medida e avaliada com relação aos requisitos de qualidade interna que podem incluir modelos estáticos e dinâmicos, outros documentos e código-fonte. Qualidade externa É a totalidade das características do produto de software do ponto de vista externo. É a qualidade quando o software é executado, o qual é medido e avaliado enquanto está sendo testado num ambiente simulado.

23 Norma ISO/IEC 9126(NBR 13596) Especifica 3 níveis de qualidade: Qualidade em uso É a visão da qualidade do produto de software do ponto de vista do usuário, quando este produto é usado em um ambiente e contexto de uso especificados. Ela mede o quanto os usuários podem atingir seus objetivos num determinado ambiente e não as propriedades do software em si

24 Norma ISO/IEC 9126(NBR 13596) Modelo de qualidade para qualidade externa e interna

25 Norma ISO/IEC 9126(NBR 13596) Funcionalidade Capacidade do produto de software de prover funções que atendam às necessidades explícitas e implícitas, quando o software estiver sendo usado sob condições especificadas. Sub-Característica Significado Adequação Acurácia Interoperabilidade Segurança de acesso Conformidade Capacidade do produto de software de prover um conjunto apropriado de funções para tarefas e objetivos do usuário especificados. Capacidade do produto de software de prover com grau de precisão necessário, resultados ou efeitos corretos ou conforme acordados. Capacidade do produto de software de interagir com um ou mais sistemas especificados Capacidade do produto de software de proteger informações e dados de forma que sistemas ou pessoas não autorizados não possam lê-los nem modifica-los. Capacidade do produto de software de estar de acordo com normas, convenções ou regulamentações previstas em lei.

26 Norma ISO/IEC 9126(NBR 13596) Funcionalidade Capacidade do produto de software de prover funções que atendam às necessidades explícitas e implícitas, quando o software estiver sendo usado sob condições especificadas. Notas:

27 Norma ISO/IEC 9126(NBR 13596) Confiabilidade Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas. Sub-Característica Maturidade Tolerância a falhas Recuperabilidade Significado Capacidade do produto de software evitar falhas decorrentes de defeitos no software. Capacidade do produto de software de manter um nível de desempenho especificado em casos de defeitos no software ou violação de sua interface. Capacidade do produto de software de restabelecer seu nível de desempenho especificado e recuperar os dados diretamente afetados no caso de uma falha.

28 Norma ISO/IEC 9126(NBR 13596) Confiabilidade Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas. Notas:

29 Norma ISO/IEC 9126(NBR 13596) Usabilidade Capacidade do produto de software ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas. Sub-Característica Inteligibilidade Apreensibilidade Operacionabilidade Atratividade Significado Capacidade do produto de software de possibilitar ao usuário compreender se o software é apropriado e como ele pode ser usado para tarefas e condições de uso específicas. Capacidade do produto de software de possibilitar ao usuário aprender sua aplicação. Capacidade do produto de software de possibilitar ao usuário operá-lo e controlá-lo. Capacidade do produto de software de ser atraente ao usuário

30 Norma ISO/IEC 9126(NBR 13596) Usabilidade Capacidade do produto de software ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas. Notas:

31 Norma ISO/IEC 9126(NBR 13596) Eficiência Capacidade do produto de software de apresentar desempenho apropriado, relativo a quantidade de recursos usados, sob condições especificados. Sub-Característica Comportamento em relação ao tempo Utilização de recursos Significado Capacidade do produto de software de fornecer tempos de resposta e de processamento, além de taxas de transferência apropriados, quando o software executa suas funções, sob condições estabelecidas. Capacidade do produto de software de utilizar tipos e quantidades apropriados de recursos, quando o software executa suas funções, sob condições estabelecidas.

32 Norma ISO/IEC 9126(NBR 13596) Eficiência Capacidade do produto de software de apresentar desempenho apropriado, relativo a quantidade de recursos usados, sob condições especificados. Notas:

33 Norma ISO/IEC 9126(NBR 13596) Manutenibilidade Capacidade do produto de software de ser modificado. As modificações podem incluir correções, melhorias ou adaptações do software devido a mudança no ambiente e nos seus requisitos ou especificações funcionais. Sub-Característica Significado Analisabilidade Modificabilidade Estabilidade Capacidade do produto de software de permitir o diagnóstico de deficiências ou causas de falhas no software, ou a identificaçãode partes a serem modificadas. Capacidade do produto de software de permitir que uma modificação especificada seja implementada Capacidade do produto de software de evitar efeitos inesperados decorrentes de modificações no software Testabilidade Capacidade do produto de software de permitir que o software, quando modificado, seja validado.

34 Norma ISO/IEC 9126(NBR 13596) Manutenibilidade Capacidade do produto de software de ser modificado. As modificações podem incluir correções, melhorias ou adaptações do software devido a mudança no ambiente e nos seus requisitos ou especificações funcionais. Notas:

35 Norma ISO/IEC 9126(NBR 13596) Portabilidade Capacidade do produto de software de ser transferido de um ambiente para outro. O ambiente pode ser organizacional, de hardware ou software Sub-Característica Significado Adaptabilidade Capacidade para ser instalado Coexistência Capacidade para substituir Capacidade do produto de software de ser adaptado para diferentes ambientes sem necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade Capacidade do produto de software para ser instalado em um ambiente especificado Capacidade do produto de software de coexistir com outros produtos de software independentes, em um ambiente comum, compartilhando recursos comuns. Capacidade do produto de software de ser usado em substituição a outro produto de software especificado, com o mesmo propósito e no mesmo ambiente

36 Norma ISO/IEC 9126(NBR 13596) Portabilidade Capacidade do produto de software de ser transferido de um ambiente para outro. O ambiente pode ser organizacional, de hardware ou software Notas:

37 Norma ISO/IEC 9126(NBR 13596)

38 Norma ISO/IEC 9126(NBR 13596) Qualidade em uso Capacidade do produto de software de permitir que usuários especificados atinjam metas especificadas com eficácia, produtividade, segurança e satisfação em contextos de uso especificados. Eficácia Capacidade do produto de software de permitir que usuários atinjam metas especificads com acurácia e completitude, em um contexto especificado. Produtividade - Capacidade do produto de software de permitir que seus usuários empreguem quantidade apropriada de recursos em relação à eficácia obtida, em um contexto especificado. OBS: recursos relevantes podem incluir tempo para completar a tarefa, esforço do usuário, materiais ou custos financeiros.

39 Norma ISO/IEC 9126(NBR 13596) Qualidade em uso Segurança Capacidade do produto de software de apresentar níveis aceitáveis de riscos de danos a pessoas, negócios, software, propriedades ou ao ambiente, em um contexto de uso especificado. OBS: Geralmente, os riscos são decorrentes das deficiências na funcionalidade (incluindo segurança de acesso), confiabilidade, usabilidade ou manutenibilidade Satisfação - Capacidade do produto de software de satisfazer usuários, em um contexto de uso especificado. OBS: satisfação é a resposta do usuário à interação com o produto e inclui atitudes relacionadas ao uso do produto.

40 CMM Capability Maturity Model Conceitos sobre maturidade de processos Processo de software conjunto de atividades, métodos, práticas e transformações usados para desenvolver e manter software. Maturidade do processo de software é a extensão em que um processo específico é explicitamente definido, gerenciado, medido, controlado e efetivo.

41 CMM Capability Maturity Model O CMM tem seu foco no processo de software por entender que a qualidade de um sistema de software é fortemente influenciada pela qualidade do processo utilizado para desenvolvê-lo e mantê-lo. Portanto, uma premissa do CMM é o foco no "processo" da mesma forma que no "produto", pois enfocando apenas o "produto" se perde o conhecimento de como produzí-lo melhor por não se ter desenhado, conhecido e, constantemente, melhorado o processo utilizado para desenvolver o produto.

42 CMM Capability Maturity Model Criado pelo Software Engineering Institute (SEI) é uma metodologia usada para desenvolver e refinar o processo de desenvolvimento de software de uma organização. define cinco níveis de maturidade de processos de software: Inicial Repetível Definido Gerenciado Otimizado

43 CMM Capability Maturity Model Cada nível é composto por várias áreas-chave de processo (key process áreas KPA) que descrevem as questões que devem ser abordadas e resolvidas para se atingir um determinado nível. Uma área-chave de processo busca objetivos e é organizada por cinco características comuns que incluem: compromisso para realizar (políticas e responsabilidades); capacidade para realizar (recursos, estruturas e treinamento); atividades realizadas (procedimentos e ações corretivas); mensuração e análise (medidas e avaliações); verificação da implantação (revisões e auditorias) que observam se a áreachave de processo é eficiente, repetível e duradoura. Cada característica comum contém práticas chaves (Key Practices KP) que descrevem as atividades do processo de desenvolvimento, cujo atendimento contribui para a satisfação dos objetivos de cada área chave de processo

44 CMM Capability Maturity Model

45 CMM Capability Maturity Model Nível 1 - nível inicial (CMM 1) o processo é quase que caótico, com custos, prazos, qualidade e performances imprevisíveis, onde o sucesso está basicamente apoiado no esforço individual. Pode-se desenvolver software de qualidade, de acordo com o desempenho e capacidade da equipe, ou seja, é uma caixa preta onde apenas as entradas e o produto final podem ser vistos claramente.

46 CMM Capability Maturity Model Nível 1 - nível inicial (CMM 1) Características: Dificuldade de visualizar e gerenciar o progresso e as atividades do projeto(caixa preta) O cliente somente verifica se os seus requisitos foram atendidos na entrega do produto. O sucesso nessas organizações depende da competência e heroísmo dos seus funcionários e não no uso de processos estruturados. Devido ao imediatismo, o nível 1 de maturidade produz produtos e serviços que em geral funcionam, mas frequentemente excedem o orçamento e o prazo dos projetos.

47 CMM Capability Maturity Model Nível 2 - nível repetível (CMM 2) são estabelecidos procedimentos básicos para gerenciamento dos processos, de modo a rastrear prazos, custos e funcionalidade. Capacitação do processo é melhorada, projeto a projeto com o estabelecimento de disciplinas de gerência de processo, logo os métodos de gerenciamento são documentados e acompanhados. Práticas bem sucedidas desenvolvidas em projetos anteriores podem ser repetidas.

48 CMM Capability Maturity Model Nível 2 - nível repetível (CMM 2) Características: O controle gerencial permite visibilidade em ocasiões definidas. O cliente pode analisar o produto durante o processo de software. Diferentemente do nivel 1, o processo de desenvolvimento passa a ter uma sequencia de caixas pretas permitindo verificar se o projeto está conforme o estabelecido. Técnicas de gerenciamento de projetos são estabelecidas para mapear custos, prazos, e funcionalidades. Um mínimo de disciplina nos processos é estabelecido para que se possa repetir sucessos anteriores em projetos com escopo e aplicação similares. Ainda há um risco significativo de exceder as estimativas de custos e o prazo de desenvolvimento

49 CMM Capability Maturity Model Nível 2

50 CMM Capability Maturity Model Nível 2 - KPA

51 CMM Capability Maturity Model Nível 2 - KPA

52 CMM Capability Maturity Model Nível 2 - KPA

53 CMM Capability Maturity Model Nível 2 - KPA

54 CMM Capability Maturity Model Nível 2 - KPA

55 CMM Capability Maturity Model Nível 2 - KPA

56 CMM Capability Maturity Model Nível 3 - nível definido (CMM 3) os processos tanto para as atividades de gerenciamento, quanto de engenharia estão documentados, padronizados e integrados em um padrão de desenvolvimento compreendido pela organização. A organização possui um conjunto de padrões de processos, os quais são a base do nível 3. Estes estão estabelecidos e são melhorados periodicamente.

57 CMM Capability Maturity Model Nível 4 - nível gerenciado(cmm 4) a organização estabelece metas quantitativas relativas à qualidade do processo e do produto. Medições detalhadas do processo de software e qualidade do produto são coletados. Características: Uma distinção crítica entre o nível de maturidade 3 e 4 é a previsibilidade do desempenho do processo. No nível 4, o desempenho do processo é controlado usando técnicas estatísticas e quantitativas, e é previsível quantitativamente. No nível 3, os processos são somente previsíveis qualitativamente.

58 CMM Capability Maturity Model Nível 5 - nível otimizado (CMM 5) toda a organização é focada na melhoria contínua do processo, além das mudanças no processo e na tecnologia serem planejadas e gerenciadas. A melhoria contínua é feita através do feedback quantitativo dos processos e das aplicações de novas ideias e tecnologias.

59 CMMI Capability Maturity Model Integration Pode ser traduzido como Projeto de Integração dos Modelos de Maturidade da Capacidade. Representa a consolidação dos seguintes modelos: Capability Maturity Model for Software (SW-CMM), Systems Engineering Systems Engineering Capability Model (SECM) e Integrated Product Development Capability Maturity Model (IPD-CMM), além de incorporar melhorias aprendidas com o próprio uso do CMM e alinhar-se com a norma ISO/IEC A arquitetura do CMMI é composta basicamente pela definição de um conjunto de áreas de processo, organizadas em duas representações diferentes: uma como um modelo por estágio, semelhante ao SW-CMM, e outra como um modelo contínuo, semelhante a ISSO

60 CMMI Capability Maturity Model Integration

61 CMMI Capability Maturity Model Integration Nível 1 - Inicial: os processos normalmente estão envoltos num caos decorrente da não obediência ou ainda, inexistência de padrões; Nível 2 - Gerenciado: os projetos têm seus requisitos gerenciados neste ponto. Além disso, há o planejamento, a medição e o controle dos diferentes processos; Nível 3 - Definido: os processos já estão claramente definidos e são compreendidos dentro da organização. Os procedimentos se encontram padronizados, além de ser preciso prever sua aplicação em diferentes projetos; Nível 4 - Gerenciado Quantitativamente: ocorre o aumento da previsibilidade do desempenho de diferentes processos, uma vez que os mesmos já são controlados quantitativamente; Nível 5 - Otimizado: existe uma melhoria contínua dos processos.

62 CMMI Capability Maturity Model Integration

63 CMMI Capability Maturity Model Integration

64 CMMI Capability Maturity Model Integration

65 CMMI Capability Maturity Model Integration

66 MPS-BR Significa Melhoria do Processo de Software Brasileiro Criado pelo Softex (Associação para a Promoção da Excelência do Software Brasileiro) e patrocinado pelo MCT Adaptação dos 5 níveis do CMMI em 7 no MPS-BR Objetivo => proporcionar uma estrutura para a melhoria dos processos de desenvolvimento e manutenção de software para as empresas brasileiras

67 MPS-BR Niveis de maturidade do MPS-BR

68 MPS-BR Em cada nível de maturação, o processo possui 9 capacidades a serem analisadas: AP 1.1 O processo é executado AP 2.1 O processo é gerenciado AP 2.2 Os produtos de trabalho do processo são gerenciados AP 3.1 O processo é definido AP 3.2 O processo está implementado AP 4.1 O processo é medido AP 4.2 O processo é controlado AP 5.1 O processo é objeto de inovações AP 5.2 O processo é otimizado continuamente

69 MPS-BR Vantagens: Por ter um número maior de níveis, sua implantação é mais gradual e adequada a pequenas e médias empresas Avaliação periódica a cada 2 anos visando a manutenção do certificado ou a evolução para um outro nível Aceite em licitações. Custo mais acessível Desvantagem: Apesar do foco ser um meio para as pequenas e médias empresas alcançarem qualidade nos processos e produtos desenvolvidos, a certificação não é o suficiente para tornar a empresa competitiva internacionalmente.