• Nenhum resultado encontrado

Aula Qualidade

N/A
N/A
Protected

Academic year: 2021

Share "Aula Qualidade"

Copied!
86
0
0

Texto

(1)

Aula Qualidade

(2)

Qualidade de Software

Qualidade segundo o MICHAELIS:

Atributo, condição natural,

propriedade pela qual algo ou alguém

se individualiza, distinguindo-se dos

demais; maneira de ser, essência,

natureza.

Grau de perfeição, de precisão, de

conformidade a um certo padrão.

Conjunto de aspectos sensíveis da

percepção resultantes de uma síntese

efetuada pelo espírito.

(3)

Qualidade de Software

Segundo Somerville Software

“Programas de computador e

documentação associada. Os

produtos de software podem ser

desenvolvidos para um cliente

específico ou para um mercado

geral”.

(4)

Qualidade de Software

Qualidade e igual para todos?

O que é considerado um Software

de qualidade?

E um software que funciona?

Que foi entregue no prazo e

(5)

Qualidade de Software

Conceitos de Qualidade em

Software:

Qualidade é um conceito subjetivo,

que varia para cada local, época,

tipo de produto e pessoa que está

avaliando.

(6)

Qualidade de Software

Uma rápida reflexão:

A qualidade é relativa. O que é

qualidade para uma pessoa pode ser

falta de qualidade para outra.

(7)

Qualidade de Software

Reflexão:

Qualidade é:

Superar as expectativas;

Produto sem defeito;

Fazer melhor com menos recursos;

Adequação ao uso ;

Produzido por empresa certificada;

Qualidade é o que cada cliente percebe

(8)

Qualidade

"Qualidade nada mais é do que

satisfazer a necessidade do

cliente dentro do projeto." -

Ricardo Vargas.

O que o Autor Ricardo Vargas

(9)

Qualidade de Software

A qualidade esta associada as

necessidades do cliente. Vai ser

um produto de qualidade aquele

que apresentar os requisitos

(10)

Qualidade de Software

“Existem empresas que já estão na versão

5 de seu software, mas tem clientes que

ainda usam a versão 3, porque os clientes

morrem de medo de atualizar, por causa

dos históricos de erros em novas

versões – eles preferem os problemas já

conhecidos. Empresas que levam o

software ao cliente e uma tela não

funciona, ou uma correção de um

problema que afetou outro lugar no

(11)

Qualidade de Software

Alguns Fatores que levam a erros na

qualidade de Software:

◦Não existem requisitos ou documentação;

◦Não existe a fase de projeto de software;

Controle de mudanças e de versões

inadequadas (ou inexistentes);

Foco na entrega;

◦Inexistência de um time de testes (ou mesmo a fase de testes);

(12)

Qualidade de Software

Podemos definir a Qualidade de

Software como:

“Qualidade de software e atender as

necessidades do cliente, trabalhando

em cima dos requisitos passados e

trabalhados. Qualidade também pode

ser considerado a entrega de um

produto no tempo especificado

atendendo os requisitos

(13)

Reflexão 3 Perguntas

Básicas

A realidade da empresa reflete na

qualidade dos seus funcionários?

A realidade do Funcionário deve

ser Refletida dentro da Empresa?

Qualidade de vida tem que ser

pensado nestes momentos??

Quand

o não

se pre

ocupa

com o

s

Funcio

nários

temos

uma B

omba

Relógi

o.

(14)

Reflexão

Uma empresa que possuiu uma alta

rotatividade de funcionários e uma

empresa que apresenta qualidade?

(15)

CMM

Um Processo de

Desenvolvimento de Software

corresponde ao conjunto de

atividades, métodos, práticas e

transformações que uma equipe

utiliza para desenvolver e manter

software e seus produtos associados

(planos de projeto, documentos de

projeto, código, casos de teste e

(16)

CMM

Uma empresa é considerada

num maior grau de

maturidade quanto mais

evoluído for o seu processo

de desenvolvimento de

(17)

CMM

O modelo CMM define cinco níveis de

maturidade no que diz respeito ao

processo de desenvolvimento de

software adotado a nível das

empresas, estabelecendo uma escala

ordinal que conduz as empresas ao

longo de seu aperfeiçoamento.

(18)

CMM

A ideia e que uma empresa

“Desorganizada” fique

“Organizada”, passando por cada

nível e ao chegar no ultimo ela se

seja uma empresa Madura e de

(19)

CMM

 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 evolui sob certas condições;

◦Organiza os estágios de evolução da melhoria dos processos;

◦Descreve um Caminho evolucionário que vai de um processo indisplinado para um processo

(20)

CMM

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 obtenção

(21)

CMM

Cada KPA é descrita em termos de

práticas-chave (Key Pratices).

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.

(22)
(23)

23

Nível 1 - Inicial

Processo de software ad hoc –

imprevisível e quase sem controle;

Resultados dependem de posturas

individuais;

(24)

Nível 2 - Repetitivo

Processos básicos de gerenciamento

de projetos estabelecidos para fazer o

“tracking” de custos, cronograma e

funcionalidades;

Sequência de caixas pretas (tarefas);

Planejamento e gerência de novos

projetos baseados em experiências

adquiridas com projetos similares já

realizados;

(25)

Nível 3 - Definido

Processo de software documentado,

padronizado e integrado em um

processo de software padrão para a

organização;

Todos os projetos usam uma versão

adaptada e aprovada do processo

padrão da organização;

(26)

Nível 4 - Gerenciado

Processos de software

instrumentalizados e controlados

quantitativamente;

Base quantitativa para tomada de

decisões;

Permite prever tendências em

processos e em qualidade de

produtos;

(27)

Nível 5 – Em otimização

Foco na melhoria do processo;

A organização tem meios para

identificar fraquezas e fortalecer o

processo de forma pró-ativa,

(28)
(29)

CMM

Em resumo com a adoção do

modelo uma empresa sai do Caos

para Ordem.

(30)
(31)

Relembrando

Mas...

Por ser um padrão Internacional

apresenta algumas desvantagens:

◦E Caro... Por se um padrão internacional o seu preço e vinculado a moedas

internacionais ;

◦Apresenta um elevado custo para implementação e recursos;

◦Não apresenta a realidade da região em que esta sendo implementada;

◦Para pequenas empresas não e uma realidade...

(32)

Reflexão

Uma pequena empresa brasileira

que deseje se certificar em

qualidade tem condições de

inicialmente tentar alcançar o

nível 2 do CMM?

(33)
(34)

MPS.BR: Objetivo e Metas

Objetivo:

Melhoria de processos de

software nas micros, pequenas e médias

empresas (PMEs), a um custo acessível,

em diversos locais do país.

Como?

Desenvolvimento e Aprimoramento do

Modelo MPS.BR.

Implementação e Avaliação do Modelo

MPS.BR em empresas, com foco em

grupos de empresas.

(35)

MPS.BR Realidade das Empresas Brasileiras ISO /IEC 12207 ISO /IEC 15504 CMMI SOFTEX Governo Universidades Base Técnica

MPS.BR: Desenvolvimento e

Aprimoramento

(36)

Base Técnica do MPS.BR

MPS.BR CMMI Complementação de Processos ISO/IEC 12207 Definição de Processos Propósitos e Resultados ISO/IEC 15504 Definição da Capacidade de Processos Requisitos de Avaliação

(37)

Níveis de Maturidade

 São uma combinação entre processos e sua

capacidade.

 O progresso e o alcance de um determinado

nível de maturidade do MR-MPS se obtém quando são atendidos os propósitos e todos os resultados esperados dos respectivos

processos e dos atributos de processo estabelecidos para aquele nível.

 Os níveis de maturidade estabelecem

patamares de evolução de processos, caracterizando estágios de melhoria da

(38)

Níveis de Maturidade

O MR-MPS define 7 níveis de

maturidade:

G. Parcialmente Gerenciado

F. Gerenciado

E. Parcialmente Definido

D. Largamente Definido

C. Definido

B. Gerenciado Quantitativamente

A. Em Otimização

(39)

Equivalência com CMMI

Nível MPS.BR Nível CMMI

G 2 F E 3 D C B 4 A 5

(40)

Níveis de Maturidade e

Processos

Garantia da Qualidade / Medição

Aquisição / Gerência de Configuração

Avaliação e Melhoria do Processo Organizacional / Definição do Processo Organizacional / Gerência de Recursos Humanos / Gerência de Reutilização / Gerência de Projetos (evolução)

Desenvolvimento de Requisitos / Integração do Produto/ Projeto e Construção do Produto / Verificação / Validação

Análise de Decisão e Resolução / Gerência de Reutilização (evolução) / Desenvolvimento para Reutilização / Gerência de Riscos G F E D C Gerência de Requisitos Gerência de Projeto

Gerência de Projeto (evolução)

Análise de Causas de Problemas e Resolução A B Parcialmente Gerenciado Gerenciado Parcialmente Definido Largamente Definido Definido Gerenciado Quantitativamente Em Otimização

(41)

Capacidade e Atributos de

Processo

Atributos de Processo (AP):

AP 1.1 – O processo é executado

Este atributo é uma medida do quanto o processo atinge

o seu propósito;

AP 2.1 – O processo é gerenciado

Este atributo é uma medida do quanto a execução do

(42)

Atributos de Processos

AP 2.2 – Os produtos de trabalho do

processo são gerenciados

Este atributo é uma medida do quanto os produtos de

trabalho produzidos pelo processo são gerenciados apropriadamente;

AP 3.1 – O processo é definido

Este atributo é uma medida do quanto um processo padrão

é mantido para apoiar a implementação do processo definido;

AP 3.2 – O processo está implementado

Este atributo é uma medida do quanto o processo padrão é

efetivamente implementado como um possesso definido para atingir seus resultados;

(43)

Capacidade e Atributos de

Processo

AP 4.1 – O processo é medido

Este atributo é uma medida do quanto os resultados de

medição são usados para assegurar que o desempenho do processo apoia o alcance dos objetivos de

desempenho relevantes como apoio aos objetivos de negócio definidos;

AP 4.2 – O processo é controlado

Este atributo é uma medida do quanto o processo é

controlado estatisticamente para produzir u processo estável, capaz e previsível de limites estabelecidos;

(44)

Capacidade e Atributos de

Processo

AP 5.1 – O processo é objeto de

inovações

Este atributo é uma medida do quanto as

mudanças no processo são identificadas a partir da análise do desempenho e da

investigação de enfoques inovadores para a definição e implementação do processo;

AP 5.2 – O processo é otimizado

continuamente

Este atributo é uma medida do quanto as

mudanças na definição, gerência e

desempenho do processo têm impacto efetivo para o alcance dos objetivos relevantes de

(45)

Relembrando

Nas duas ultimas aulas vimos os 2

modelos básicos para Qualidade

de Software o CMM e o MPS.BR.

Mas somente conhecer os 2 não e

o suficiente para alcançar os

(46)

Relembrando

Tem que adotar cada modelo e

verificar se o requisitos solicitados

por cada modelo estão sendo

implementados.

Para isso deve se definir um

conjunto de métricas para auxiliar

no trabalho.

(47)

Métricas da qualidade de

software

Objetivos

o

Entender porque medição é importante para

avaliação e garantia da qualidade de software.

Entender as abordagens principais de métricas

e como elas são utilizadas.

Conhecer algumas métricas e suas aplicações.

Entender o que é um Plano de Métricas e como

(48)

Métricas da qualidade de

software

Motivação

Um dos objetivos básicos da Engenharia de Software é: a

transformação da criação de sistemas software de uma maneira artística, indisciplinada e pouco entendível para uma forma

devidamente controlada, quantificada e previsível

“Métricas de Software” é um assunto discutido há mais de 20 anos na engenharia de software ... e no entanto não é verificada sua

utilização, na prática, pela grande maioria dos projetos de construção de software

Pesquisas realizadas em empresas de software indicam que mais da metade de grandes projetos de software se deparam com algum tipo de atraso, excesso de custo ou prazo ou algum fracasso na execução quando implantado Falta

(49)

Métricas da qualidade de

software

Motivação

“Não se pode gerenciar o que não se pode

medir”.

Tom De Marco

“Se você não sabe para onde você quer ir,

qualquer caminho você pode seguir. Se você

não sabe onde você está, um mapa não vai

ajudar!”.

(50)

O que são métricas de software?

Uma métrica é a medição de um atributo

(propriedades ou características ) de uma

determinada entidade (produto, processo ou

recursos). Exemplos:

 Tamanho do produto de software (ex: Número de Linhas de código);

 Número de pessoas necessárias para implementar um caso de uso;  Número de defeitos encontrados por fase de desenvolvimento;

 Esforço para a realização de uma tarefa;  Tempo para a realização de uma tarefa;  Custo para a realização de uma tarefa;

 Grau de satisfação do cliente (ex: adequação do produto ao propósito, conformidade do produto com a especificação);

(51)

Por que medir software?

Entender e aperfeiçoar o processo de

desenvolvimento;

Melhorar a gerência de projetos e o

relacionamento com clientes;

Reduzir frustrações e pressões de cronograma;

(52)

Por que medir software?

Indicar a qualidade de um produto de software;

Avaliar a produtividade do processo;

Avaliar

os

benefícios

(em

termos

de

produtividade e qualidade) de novos métodos e

ferramentas de engenharia de software;

(53)

Por que medir software?

Identificar

as

melhores

práticas

de

desenvolvimento de software;

Embasar solicitações de novas ferramentas e

treinamento;

Avaliar o impacto da variação de um ou mais

atributos do produto ou do processo na

qualidade e/ou produtividade;

(54)

Por que medir software?

Formar uma baseline para estimativas;

Melhorar a exatidão das estimativas;

Oferecer dados qualitativos e quantitativos ao

gerenciamento de desenvolvimento de software,

de forma a realizar melhorias em todo o

processo de desenvolvimento de software;

(55)

Propriedades desejadas de uma

métrica

Facilmente calculada, entendida e testada;

Passível de estudos estatísticos;

Expressa em alguma unidade;

Obtida o mais cedo possível no ciclo de vida do

software;

Passível de automação;

Repetível e independente do observador;

Sugere uma estratégia de melhoria;

(56)

Métrica

Uma métrica deve ser:

Válida: quantifica o que queremos medir;

Confiável: produz os mesmos resultados

dadas as mesmas condições;

Prática: barata, fácil de computar e fácil de

interpretar;

Dois contextos para medição de software:

Processo. Ex: produtividade;

(57)

Categorização das métrica

Métricas diretas (fundamentais ou básicas);

Métricas indiretas (derivadas);

Métricas orientadas a tamanho;

Métricas orientadas por função;

Métricas de produtividade;

Métricas de qualidade;

Métricas técnicas;

(58)

Categorização das métrica

Métricas diretas (fundamentais ou básicas)

 Medida realizada em termos de atributos observados

(usualmente determinada pela contagem)

 Ex.: custo, esforço, no. linhas de código, capacidade

de memória, no. páginas, no. diagramas, etc.

Métricas indiretas (derivadas)

 Medidas obtidas a partir de outras métricas

 Ex.: complexidade, eficiência, confiabilidade,

(59)

Categorização das métrica

Métricas orientadas a tamanho

 São medidas diretas do tamanho dos artefatos de

software associados ao processo por meio do qual o software é desenvolvido.

 Ex.: esforço, custo, no. KLOC, nº páginas de

documentação, nº de Erros

Métricas orientadas por função

 Consiste em um método para medição de software

do ponto de vista do usuário, determinando de forma consistente o tamanho e a complexidade de um software.

(60)

Categorização das métrica

Métricas de produtividade

 Concentram-se na saída do processo de engenharia

de software.

 Ex: nº de casos de uso/iteração.

Métricas de qualidade

 Oferecem uma indicação de quanto o software se

adequa às exigências implícitas e explícitas do cliente.

(61)

Categorização das métrica

Métricas técnicas

 Concentram-se nas características do software e não

no processo por meio do qual o software foi desenvolvido.

(62)

Possíveis problemas com

métricas

Um exemplo: Comparar a produtividade de

engenheiros em termos de linha de código.

 Está sendo utilizado a mesma unidade de medida?

 O que é uma linha de código válida?

 O contexto considerado é o mesmo?

Todos os engenheiros são familiarizados com a

linguagem de programação?

 O que se quer realmente é o tamanho do código?

 E a qualidade do código?

 Como o resultado será interpretado?

 Produtividade média de um engenheiro?

 O que se quer com o resultado?

(63)

Problemas com métricas

Teoria sobre métricas pode ajudar a resolver

estes problemas.

Teoria da medição

Como se deve medir

Escalas utilizadas

(64)

Relações Empíricas

Ajudam a observar as relações do tipo

verdadeiro/falso entre entidades do mundo real

Ex: Relações empíricas entre o atributo peso

das pessoas

Binária: O João é mais pesado do que José

Unária: O João é pesado

Ternária: O João é mais pesado que José e

Antônio

(65)

Medida

Medida é uma função de mapeamento

João José Antônio 110 Kg 90 Kg 85 Kg Atributos do mundo real (domínio) Um símbolo em um conjunto com relações matemáticas

(66)

Medição

É a atribuição de uma medida (através de um

símbolo) a um atributo do mundo real

Propósito: manipular símbolos na faixa

=> determinar conclusões sobre os atributos do domínio

Para ser precisa, a medição deve especificar

 Domínio: Será medido a largura ou peso das

pessoas?

 Faixa: A medida do peso foi feita em Kg ou g ?

 Regras de mapeamento: Será permitido pesar

(67)

Escala

Representa os símbolos na faixa de uma

medida mais as manipulações permitidas

Exemplo de manipulações:

Mapeamento: transformar símbolos em um

conjunto em outros símbolos em outro

conjunto.

(68)

Tipos de escalas

Kelvin, tamanho, largura Diferença entre qualquer par

consecutivo de valores é

preservada. Possui 0 absoluto.

Ratio (razão)

Celsius e Fahrenheit Diferença entre qualquer par

consecutivo de valores é preservada Intervalar {simples, médio, complexo} Símbolos ordenados Ordinal {verdadeiro, falso} Símbolos não ordenados

Nominal

Exemplos Características

(69)

Os quatro papéis da

medição

 Segundo Humphrey, são quatro os principais papéis de

Medições de Software: Processos, Produtos e Serviços de Software Entender Avaliar Prever Controlar

(70)

Os quatro papéis da

medição

Entender

 Métricas ajudam a entender o comportamento e

funcionamento de processos, produtos e serviços de software

Avaliar

 Métricas podem ser utilizadas para tomar decisões e

determinar o estabelecimento de padrões, metas e critérios de aceitação

(71)

Os quatro papéis da

medição

Controlar

 Métricas podem ser utilizadas para controlar

processos, produtos e serviços de software

Prever

 Métricas podem ser utilizadas para prever valores de

(72)

Os quatro papéis da

medição

Controlar

 Métricas podem ser utilizadas para controlar

processos, produtos e serviços de software

Prever

 Métricas podem ser utilizadas para prever valores de

(73)

Criando uma Métrica

Para se criar uma métrica tem que se entender

primeiro o objetivo do que se deseja realizar,

vamos pegar o seguinte exemplo para

trabalharmos em um conjunto de métricas:

(74)

Criando uma Métrica

 “A PMZ, uma desenvolvedora com 25 anos de

experiência no desenvolvimento de sistemas esta com um problema. Atualmente a sua etapa de requisitos esta muito caótica, sendo que o processo esta sendo realizado fracamente ou não é realizado. Basicamente a etapa opera da seguinte forma: Os analistas entram em contato com o Cliente, Marcão uma reunião com o cliente, comparecem a reunião com o Formulário XYZ, retornar a empresa com o Formulário XYZ, apresentam o Formulário para equipe de desenvolvimento. A equipe da um Parecer e o Analista Retornar para o cliente os resultados esperados”

(75)

Criando uma Métrica

 O foco e verificar se o processo de requisitos esta sendo

realizado de acordo com o definido pela politica da empresa. Para isso vamos pegar cada parte importante do processo e associar a uma pergunta.

(76)

Criando uma Métrica

1. A equipe de analise entrou em contato com o Cliente? 2. A equipe de analise marcou uma reunião com o

Cliente?

3. A equipe ou o Analista encarregado compareceu a

reunião?

4. A equipe ou o Analista encarregado levou o Formulário

XYZ?

5. A equipe ou o Analista encarregado retornou para

empresa com Formulário XYZ?

6. O Formulário XYZ foi apresentado a equipe de

desenvolvimento?

7. A equipe de desenvolvimento deu um parecer?

8. A equipe ou o Analista encarregado retornou para o

(77)

Criando uma Métrica

Métrica Sim Não Não

Aplicável

A equipe de analise entrou em contato com o

Cliente? X

A equipe de analise marcou uma reunião com o

Cliente? X

A equipe ou o Analista encarregado compareceu

a reunião? X

A equipe ou o Analista encarregado levou o Formulário XYZ?

X A equipe ou o Analista encarregado retornou

para empresa com Formulário XYZ? X O Formulário XYZ foi apresentado a equipe de

desenvolvimento? x

A equipe de desenvolvimento deu um parecer? X A equipe ou o Analista encarregado retornou

(78)

Criando uma Métrica

 No exemplo anterior foi adotado um CheckList, o

objetivo e ver se todos os pontos do processo estão sendo contemplados, e em cada ponto existe uma nota associada aquele ponto. No caso do Exemplo anterior temos:

 Sim;  Não;

(79)

Criando uma Métrica

 Um CheckList e muito útil para entendimento do

processo como um todo.

 Através dele consegue verificar as atividades realizadas

e se elas estão realmente sendo realizadas.

 Permite uma visão mais clara e ampla do processo

(80)

CheckList

 Um CheckList e um conjunto de perguntas( métricas) e

as respostas para cada pergunta.

 Não fica preso somente a ideia de sim e não podendo

ser utilizado de varias formas diferentes, veja o exemplo de um para a Gestão de projetos em uma pequena empresa:

(81)
(82)

Criando uma Métrica - Cuidados

 Cuidados ao se criar métricas:

1) Elas devem ter relação com o objetivo; 2) Tem que ter pontos em Comum;

3) Tem que ser de fácil entendimento para quem esta

respondendo;

4) Se for para uma comparação, deve apresentar as

(83)

Estudo de Caso 1 – 20 Minutos

 A SPM LTDA uma empresa no ramo de

transportes, contratou a sua empresa para o desenvolvimento de um sistema para controle da sua frota. O foco e manter informações dos Veículos, Rotas, Clientes e Fornecedores. Os Requisitos passados pela SPM estão

incompletos e ambíguos levando sua equipe de analistas a realizar varias interpretações.

 O projeto não pode ser entregue depois de

31/12/2016 devido a questões legais.

 Realize o Levantamento dos principais

problemas de qualidade que podem acontecer neste projeto.

(84)

Estudo de Caso 2 – 20 minutos

Faça um comentário sobre a solução adotada pelo Analista.

Levante os pontos Positivos e Negativos.

 Previsões

◦O analista de sistemas Ubiratã está desenvolvendo seu software, tentando ser o mais eficaz possível. Quando o gerente aparece:

Em quanto tempo você acha que consegue implementar

relatórios com consultas por data e valor?

Não sei ainda, preciso ver quando teremos acesso ao mainframe.

No ambiente de desenvolvimento nossa aplicação funciona, em produção, não temos acesso às tabelas necessárias. Preciso conversar com os analistas do sistema ABC sobre isso.

Não quero saber, preciso isso agora. Quanto tempo você leva?Ele pensa: “vou levar umas 4h no máximo:”, mas responde:Vou precisar de 5 dias

Ok, vou lançar isso no cronograma

◦No final do dia estava pronto. Ele usou os outros 4 dias documentando e testando a aplicação inteira, coisas que ainda não tinha feito por falta de tempo

(85)

Estudo de Caso 3 – 30

Minutos

Em grupo pense no seu ambiente

organizacional, no seu local de trabalho.

Pense em todas as atividades que são

planejadas mas não são cumpridas. Pense

nos métodos e processos que são

estipulados e não são seguidos dentro da

organização. Elaborem uma lista com as 7

piores praticas adotadas pelas empresas.

Ex: Na empresa XYZ temos reuniões no

começo de cada projeto para definição do

Cronograma. O Problema e que não

seguimos esse cronograma definido. (este

exemplo não pode ser utilizado).

(86)

Exercício – 30 minutos

 Crie um conjunto de métricas(mínimo de 5) para atender

o seguinte KPA do nível 2 do CMM:

“Gerência de Requisitos - Os requisitos do sistema são controlados de forma a estabelecer um perfil mínimo a ser utilizado pela engenharia de software e pela administração. Os planos, produtos e atividades do software são sempre consistentes com os requisitos de sistema.”

Referências

Documentos relacionados

As plantas de Rottboelia exaltata apre- sentaram acúmulo de biomassa seca crescente aos 133 dias após a emergência, acumulando 87,18 g/planta; a seqüência em ordem de

 Descreve a arquitetura de processos de ciclo de vida de software mas não especifica os detalhes de como implementar ou realizar as atividades e tarefas incluídas nos processo..

Segundo Lewis (2004), "O plano de garantia da qualidade de software é um resumo ou esboço das medidas de qualidade para garantir níveis de. qualidade dentro do esforço

A estabilidade do corpo docente permanente permite atribuir o conceito muito bom, segundo os parâmetros da área, para o item 2.2 (pelo menos 75% dos docentes permanentes foram

Dessa forma, o Artigo II intitulado “Validação da World Health Organization Disability Assessment Schedule (WHODAS 2.0) na Versão Brasileira para Uso em Pessoas com

VIVIANE APARECIDA LOPES OLIVEIRA 0002087. WECERLY PIRES

O objetivo deste trabalho é apresentar os resultados de ensaios de tração realizados para corpos de prova retirados das camadas metálicas de uma linha flexível rugosa de 4”.. O

1. Etnografia Concorrente: São realizados estudos curtos e interativos antes do inicio do desenvolvimento, para que sejam colhidos os requisitos iniciais e a geração dos