mineração de dados - webnode.com.br · 2016. 9. 23. · norma iso/iec 14598-5 define um processo...

Gerenciamento de Projetos de Governança em TI

Universidade Veiga de AlmeidaLuiz Antônio Vivacqua Corrêa Meyer

[email protected]

http://vivacquabd.webnode.com.br

mailto:[email protected]

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

MotivaçãoQualidade 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 requisitos3. Definição da arquitetura macro e construção do

projeto detalhado;4. Fabricação ou desenvolvimento;5. EntregaDiferenças:1. Software é intangível2. Mais sujeito ao erro humano => dada uma

especificação de software a 2 programadores o resultado será igual?

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!

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.


• 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 funcionaise não funcionais presentes nos documentos de especificação do sistema.


• 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 asfuncionalidade sob o ponto de vista do usuário.


• 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.


• Requisito não funcional– Um requisito não funcional de software é aquele

que descreve não o que o sistema fará, mas comoele 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.


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.


• 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.

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.

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.

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

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?

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.

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

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

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.

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.

Normas ISO para Suporte ao Desenvolvimento de Software

Nome Descrição

Norma ISO/IEC 9126(NBR 13596) Define as características de qualidade de software que devem estar presentes em todos os produtos(Funcionalidade, Confiabilidade, Eficiência, Usabilidade, Manutenibilidade e Portabilidade);

Norma ISO/IEC 12119 Estabelece os requisitos de qualidade para pacotes de software;

Norma ISO/IEC 14598-5 Define um processo de avaliação da qualidade de produto de software;

Norma ISO/IEC 12207 Define um processo de ciclo de vida de software;

Norma ISO/IEC 9000-3 Apresenta diretrizes para a aplicação da ISO 9001 por organizações que desenvolvem software aodesenvolvimento, fornecimento e manutenção de software;

Norma ISO15504 Aprovada como norma em 2003 é focada na avaliação de processos organizacionais.

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.


• 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


Modelo de qualidade para qualidade externa e interna


• 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 Capacidade do produto de software de prover um conjunto apropriado de

funções para tarefas e objetivos do usuário especificados.

Acurácia Capacidade do produto de software de prover com grau de precisão

necessário, resultados ou efeitos corretos ou conforme acordados.

Interoperabilidade Capacidade do produto de software de interagir com um ou mais sistemas

especificados

Segurança de acesso 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.

Conformidade Capacidade do produto de software de estar de acordo com normas,

convenções ou regulamentações previstas em lei.


• 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:


• Confiabilidade– Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas.


Maturidade Capacidade do produto de software evitar falhas decorrentes de defeitos no

software.

Tolerância a falhas 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.

Recuperabilidade Capacidade do produto de software de restabelecer seu nível de

desempenho especificado e recuperar os dados diretamente afetados no

caso de uma falha.


• Confiabilidade– Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas.

Notas:


• Usabilidade– Capacidade do produto de software ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas.


Inteligibilidade 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.

Apreensibilidade Capacidade do produto de software de possibilitar ao usuário aprender sua

aplicação.

Operacionabilidade Capacidade do produto de software de possibilitar ao usuário operá-lo e

controlá-lo.

Atratividade Capacidade do produto de software de ser atraente ao usuário

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:


• Eficiência– Capacidade do produto de software de apresentar desempenho apropriado, relativo a quantidade de recursos usados, sob condições especificados.


Comportamento em

relação ao tempo

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.

Utilização de recursos Capacidade do produto de software de utilizar tipos e quantidades

apropriados de recursos, quando o software executa suas funções , sob

condições estabelecidas.


• Eficiência– Capacidade do produto de software de apresentar desempenho apropriado, relativo a quantidade de recursos usados, sob condições especificados.

Notas:


• 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.


Analisabilidade 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.

Modificabilidade Capacidade do produto de software de permitir que uma modificação

especificada seja implementada

Estabilidade 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.


• 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:


• Portabilidade– Capacidade do produto de software de ser transferido de um ambiente para outro. O ambiente pode ser organizacional, de hardware ou software


Adaptabilidade 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 para ser

instalado

Capacidade do produto de software para ser instalado em um ambiente

especificado

Coexistência Capacidade do produto de software de coexistir com outros produtos de

software independentes, em um ambiente comum, compartilhando recursos

comuns.

Capacidade para

substituir

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


• Portabilidade– Capacidade do produto de software de ser transferido de um ambiente para outro. O ambiente pode ser organizacional, de hardware ou software

Notas:

• 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çãoem 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.


• 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.


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.


• 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.


• 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

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 área-chave 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

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.


• 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.

https://pt.wikipedia.org/wiki/Or%C3%A7amento


• 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.

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

https://pt.wikipedia.org/wiki/Escopo


Nível 2


Nível 2 - KPA


• 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.

• 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.



• 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.

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 15504.

• 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 15504.


• 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.

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

MPS-BR

Niveis de maturidade do MPS-BR

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

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.

mineração de dados - webnode.com.br · 2016. 9. 23. · norma iso/iec 14598-5 define um processo...

Documents