engenharia de software profa. juliana herbert centro de ciências exatas e tecnológicas...

Engenharia de SoftwareEngenharia de Software

Profa. Juliana HerbertProfa. Juliana Herbert

Centro de Ciências Exatas e TecnológicasCentro de Ciências Exatas e Tecnológicas

UNISINOSUNISINOS2003/12003/1

2

Engenharia de Software

Sobre a disciplina:Sobre a disciplina:Engenharia de SoftwareEngenharia de Software

Qualidade de software: conceitos, modelos e normas.

Conceito de “Engenharia de Software”.

Paradigmas de desenvolvimento.

Identificação de problemas no desenvolvimento de software.

Trabalho cooperativo.

Workflow.

Engenharia de requisitos.

Especificação semi-formal e formal de software.

Teste e depuração de software procedimental.

Teste e depuração de software orientado a objetos.

Projeto de interfaces.

Ferramentas CASE (Computer Aided Software Engineering).

Métricas de software.

Manutenção de software.

Outros tópicos sobre pesquisas atuais na área.

1. Qualidade1. Qualidade

Conceitos...Conceitos...

4


Primeiro ExercícioPrimeiro Exercício

Avaliação de qualidade.

Análise da escolha.

Identificação de critérios.

5


Qualidade X CustosQualidade X Custos

Qualidade melhor: imagem melhor;

custo de serviço menor;

custo de inspeção e testes menores;

custo de refugo e retrabalho menor;

reclamações menores;

estoques menores;

menos necessidade de competir em preço.

6


Conceito de QualidadeConceito de QualidadeNBR ISO 8402NBR ISO 8402

“Qualidade é a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer

às necessidades implícitas e explícitas”.

2. Qualidade de Software2. Qualidade de Software

8


Problemas do SoftwareProblemas do Software

Software não possui existência física.

“Clientes não sabem o que querem”.

“Clientes mudam de idéia”, durante o desenvolvimento de sistemas.

Mudanças de hardware e software de apoio durante o desenvolvimento.

Clientes possuem altas expectativas.

9


Definições de Qualidade de SoftwareDefinições de Qualidade de Software

Qualidade relacionada à conformidde do software com os requisitos: Problema: raramente os requisitos estão

completos.

Qualidade relacionada à satisfação do usuário:Problema: usuários diferentes.

Modelo de Boehm - Modelo de Boehm - 19781978

11


Utilidade Geral Utilidade

Confiabilidade

Independência de dispositivo

Auto-suficiência

Precisão

Completeza

Robusteza

Consistência

Justificabilidade

Eficiência do dispositivo

Acessabilidade

Comunicabilidade

Auto-descrição

Estruturação

Concisão

Legibilidade

Expansão

Portabilidade

Engenharia Humana

Eficiência

Testabilidade

Compreensibilidade

Modificabilidade

Manutenibilidade

12


Tratamento das CaracterísticasTratamento das Características

Classificação (Perry, 1987):

neutras: usabilidade X correteza;

diretas: interoperabilidade X usabilidade;

inversas:reusabilidade X eficiência.

13


Visões de Qualidade de SoftwareVisões de Qualidade de Software

usuárioFacilidade de Uso, Desempenho, Confiabilidade dos Resultados, Preço do Software, etc.

desenvolvedorTaxa de defeitos, Facilidade de Manutenção e Conformidade em relação aos Requisitos de Usuários, etc

organizaçãoCumprimento de Prazo, Boa Previsão de Custo, Boa Produtividade

14


Qualidade de Software Qualidade de Software Usuário:Usuário: avalia o software sem conhecer seus

aspectos internos, está apenas interessado na facilidade do uso, no desempenho, na confiabilidade dos resultados e no preço.

Desenvolvedores:Desenvolvedores: avaliam aspectos de conformidade em relação aos requisitos dos clientes e também aspectos internos do software

Organização:Organização: avalia aspectos de conformidade em relação aos requisitos dos clientes e desenvolvedores e também aspectos de custo e cronograma

3. Engenharia de Software3. Engenharia de Software

16


Evolução do SoftwareEvolução do Software

Software X hardware.

Grupos de desenvolvimento.

Alta rotatividade de empregos.

Manutenção é constante e problemática.

Programação “forma de arte”.

Maior concorrência - globalização.

17


““Crise” de SoftwareCrise” de Software

Crise: “momento, etapa ou evento decisivo e crucial”.

Mas a crise já dura mais de 20 anos!!

“Aflição crônica” de software:Aflição: algo que causa dor e sofrimento.

Crônica: que dura longo tempo ou retorna freqüentemente; que continua indefinidamente.

18



Definição de Fritz Bauer (1969):

“o estabelecimento e uso de sólidos princípios de engenharia para que se possa obter

economicamente um software que seja confiável e que funcione eficientemente em máquinas

reais.”

19


Elementos da Engenharia de Elementos da Engenharia de SoftwareSoftware

Métodos.

Ferramentas.

Procedimentos.

Objetivo comum: garantia da qualidade de software.

1. Qualidade do Produto 1. Qualidade do Produto de Softwarede Software

21


Primeiro ExercícioPrimeiro Exercício

Qualidade do produto “relógio”.

Análise de contexto.

Definição de estratégia de marketing.

22


Qualidade do Produto X Qualidade do Qualidade do Produto X Qualidade do ProcessoProcesso

Fabricação do relógio:hipótese 1;

hipótese 2.

Influência??

23


Qualidade do Produto X Qualidade do Qualidade do Produto X Qualidade do ProcessoProcesso

Produto final de software.

Lista de características avaliadas:____________________________

____________________________

____________________________

____________________________

____________________________

24


Qualidade do Produto de SoftwareQualidade do Produto de Software

NBR 13596 - ISO/IEC 9126: Tecnologia de Informação - Avaliação de produto de software - Características de qualidade e diretrizes para o seu uso.

NBR ISO/IEC 12119: Tecnologia de Informação - Pacotes de software - Teste e requisitos de qualidade.

2. NBR 135962. NBR 13596

ProdutoOK!!

26


NBR 13596NBR 13596

Tradução da norma ISO/IEC 9126/1991.

Tradução realizada pela ABNT - CE-21:101.01Comissão de Estudo de Qualidade de Software,

dentro do CB-21 (Comitê Brasileiro de Computadores e Processamento de Dados).

Válida a partir de 30 de maio de 1996.

27


NBR 13596NBR 13596

Palavras-chave: tecnologia de informação, processamento de dados, programa de computador, qualidade.

10 páginas.

Endereço da ABNT em Porto Alegre:Siqueira Campos, 1184 - Conjunto 906

Tel.: 224-2601 e 226-2537.

28


NBR 13596NBR 13596

ObjetivoObjetivo: “Esta Norma define seis subcaracterísticas que descrevem, com

um mínimo de sobreposição, qualidade de software. Estas características fornecem uma base para posterior refinamento e descrição de qualidade de software. As diretrizes descrevem o uso de características de qualidade para a avaliação da qualidade de software” (...) A definição das características e o modelo do processo de avaliação de qualidade correspondente, nesta Norma, são aplicáveis na especificação dos requisitos de produtos de software e na avaliação da sua qualidade ao longo do seu ciclo de vida”.

29


NBR 13596NBR 13596

Dirigida às pessoas envolvidas com aquisição, desenvolvimento, uso, suporte, manutenção ou auditoria de software.

Faz referências às normas:NBR ISO 8402/1994 - Gestão da qualidade e

garantia da qualidade - Terminologia.

ISO/IEC 2382-20/1990 - Information technology - Vocabulary - Part 20: Systems development.

30


NBR 13596NBR 13596 Definições:

Características de qualidade de softwareCaracterísticas de qualidade de software: conjunto de atributos de um produto de software, através do qual sua qualidade é descrita e avaliada. Uma característica pode ser detalhada em múltiplos níveis de subcaracterísticas.

Critério de julgamento de qualidade de softwareCritério de julgamento de qualidade de software: conjunto de regras e condições definidas e documentadas que são usadas para decidir se a qualidade total de um produto de software específico é aceitável ou não.

Métrica de qualidade de softwareMétrica de qualidade de software: método e uma escala quantitativa que podem ser usados para determinar o valor que uma particularidade (feature) recebe em um produto de software específico.

31


NBR 13596NBR 13596

Definições (continuação): Produto de softwareProduto de software: entidade de software disponível

para liberação do usuário.

QualidadeQualidade: totalidade das características de uma entidade, que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas. Em uma situação contratual, as necessidades são especificadas.

Qualidade de softwareQualidade de software: totalidade das características de um produto de software que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas.

32


NBR 13596NBR 13596

Características consideradas:funcionalidade;

confiabilidade;

usabilidade;

eficiência;

manutenibilidade;

portabilidade.

Exemplo: editor Microsoft Word.

33


NBR 13596NBR 13596

Funcionalidade:Funcionalidade:“Conjunto de atributos que evidenciam a

existência de um conjunto de funções e suas propriedades especificadas. As funções são as que satisfazem as necessidades explícitas ou implícitas”

34


NBR 13596NBR 13596

Confiabilidade:Confiabilidade:“Conjunto de atributos que evidenciam a

capacidade do software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo estabelecido.”

35


NBR 13596NBR 13596

Usabilidade:Usabilidade:“Conjunto de atributos que evidenciam o esforço

necessário para se poder utilizar o software, bem como o julgamento individual desse uso, por um conjunto explícito ou implícito de usuários.”

36


NBR 13596NBR 13596

Eficiência:Eficiência:“Conjunto de atributos que evidenciam o

relacionamento entre o nível de desempenho do software e a quantidade de recursos usados, sob condições estabelecidas.”

37


NBR 13596NBR 13596

Manutenibilidade:Manutenibilidade:“Conjunto de atributos que evidenciam o esforço

necessário para fazer modificações especificadas no software.”

38


NBR 13596NBR 13596

Portabilidade:Portabilidade:“Conjunto de atributos que evidenciam a

capacidade do software de ser transferido de um ambiente para outro.”

39


NBR 13596NBR 13596

Utilização: definição de requisitos de qualidade de um produto de

software;

avaliação de especificação de software, verificando se ele irá satisfazer aos requisitos de qualidade durante o desenvolvimento;

descrição de particularidades e atributos do software (por ex., em manuais de usuário);

avaliação de software antes da entrega, ou antes da aceitação.

40


NBR 13596NBR 13596

As organizações devem estabelecer os próprios modelos de avaliação e para a criação de métricas.

Caso não haja métricas, podem ser utilizadas descrições verbais ou regras empíricas.

Para uma avaliação, devem ser estabelecidos níveis de pontuação e critérios específicos para a organização.

Algumas características são mais importantes para algumas categorias de software.

41


Visão da Qualidade pelo UsuárioVisão da Qualidade pelo Usuário

O que é um produto de software de qualidade?Produto que atende às suas necessidades.

Produto fácil de usar.

Produto que funcione em seu ambiente.

Suporte técnico confiável.

Produto confiável e eficiente.

42


Visão da Qualidade pela Equipe de Visão da Qualidade pela Equipe de DesenvolvimentoDesenvolvimento

O que é um produto de software de qualidade?Qualidade de produtos intermediários.

Qualidade relacionada a características internas do produto (por exemplo, eficiência).

Produto manutenível.

Características desejadas pelo usuário.

43


Visão da Qualidade pelo GerenteVisão da Qualidade pelo Gerente

44


Modelo do Processo de AvaliaçãoModelo do Processo de Avaliação

Definição de requisitos de qualidade.

Preparação da avaliação.

Seleção de métricas de qualidade.

Definição dos níveis de pontuação.

Definição dos critérios de julgamento.

Procedimento de avaliação.

Medição.

Pontuação.

Julgamento.

3. NBR ISO/IEC 121193. NBR ISO/IEC 12119

46


NBR ISO/IEC 12119NBR ISO/IEC 12119

Tradução da norma ISO/IEC 12119/1994.

Tradução realizada pela ABNT - CE-21:101.01Comissão de Estudo de Qualidade de Software,

dentro do CB-21 (Comitê Brasileiro de Computadores e Processamento de Dados).

Válida a partir de 30 de novembro de 1998.

47



Palavras-chave: tecnologia de informação, processamento de dados, programas de computador, qualidade, pacotes de software.

13 páginas.

48



Objetivo:Objetivo: “Esta Norma é aplicável a pacotes de software.

(...) Esta Norma estabelece: os requisitos para pacotes de software (requisitos de qualidade); instruções de como testar um pacote de software com relação aos requisitos estabelecidos.

49



Dirige-se a:Dirige-se a: fornecedores que estejam:

especificando os requisitos para um pacote de software;

projetando um modelo para descrever produtos;

julgando seus próprios produtos;

emitindo declarações de conformidade;

submetendo produtos à certificação ou à obtenção de marcas de conformidade.

50



Dirige-se a:Dirige-se a: entidades de certificação que pretendem

estabelecer um esquema de certificação por terceira parte (internacional, nacional ou regional);

laboratórios de teste, que terão de seguir as instruções de teste durante a execução de testes para certificação ou para emissão de marca de conformidade;

51



Dirige-se a:Dirige-se a: entidades de credenciamento que credenciam

entidades de certificação e laboratórios de teste;

auditores quando julgam a competência de laboratórios de teste;

usuários que pretendam se beneficiar com produtos melhores;

52



Dirige-se a:Dirige-se a: compradores que pretendam:

comparar seus próprios requisitos com os descritos na Norma;

comparar os requisitos necessários para executar uma determinada tarefa com a informação presente nas descrições de produtos existentes;

procurar por produtos certificados;

verificar se os requisitos foram atendidos.

53



Definições:documento de requisitos:documento de requisitos: documento

contendo quaisquer combinações de recomendações, requisitos ou regulamentações a serem atendidas por um pacote de software;

descrição de produto:descrição de produto: documento expondo as propriedades de um pacote de software, com o principal objetivo de auxiliar os potenciais compradores na avaliação da adequação do produto antes de sua aquisição;

54



Definições (continuação):documentação de usuário:documentação de usuário: conjunto completo

de documentos, disponível na forma impressa ou não, que é fornecido para a utilização de um produto, sendo também uma parte integrante do produto;

documentação de pacote:documentação de pacote: descrição de produto e a documentação de usuário;

55



Definições (continuação):guia de teste guia de teste (test case(test case)):: instrução

documentada para o responsável pelo teste, que especifica como deve ou convém que seja testada uma função ou uma combinação de funções;

manutenção:manutenção: parte da manutenção de sistemas que está relacionada à modificação do pacote de software;

56



Descrição de produto:Descrição de produto: define o produto;

é parte do conjunto de documentação do produto;

ajuda o potencial usuário;

serve como base para testes;

deve estar disponível para pessoas interessadas no produto;

requisitos especificados na Norma.

DP

57


Segundo ExercícioSegundo Exercício

Estudo da “descrição do produto”.

Elaboração de uma “descrição do produto”.

58


Documentação de UsuárioDocumentação de Usuário

Características consideradas pela Norma:completitude;

correção;

consistência;

inteligibilidade;

apresentação e organização.

59


Programas e DadosProgramas e Dados Características consideradas pela Norma:

funcionalidade:

instalação;

presença de funções;

correção;

consistência;

confiabilidade;

usabilidade:

inteligibilidade;

apresentação e organização;

operacionalidade;

eficiência;

manutenibilidade;

portabilidade.

60


Instruções para TesteInstruções para Teste

Especificam como um produto deve ser testado em relação aos requisitos de qualidade, incluindo tanto o teste das propriedades necessárias a todos os produtos de mesmo tipo, quanto o teste das propriedades especificadas na descrição do produto. Também estão incluídos o teste por inspeção dos documentos e o teste caixa-preta.

61


Relatório de Teste ProduzidoRelatório de Teste Produzido

Estrutura sugerida pela Norma:Estrutura sugerida pela Norma: Identificação do produto.

Sistemas computacionais utilizados para o teste.

Documentos usados (com identificações).

Resultados dos testes de descrição de produto, documentação de usuário, programas e dados.

Lista das não-conformidades aos requisitos.

Lista das não-conformidades em relação às recomendações, ou uma lista das recomendações que não foram seguidas, ou uma declaração de que o produto não foi testado quanto à conformidade em relação às recomendações.

Data do encerramento do teste.

4. Método de Avaliação 4. Método de Avaliação MEDE-PROSMEDE-PROS

Fundação Centro Tecnológico para InformáticaFundação Centro Tecnológico para Informática

CTI - Campinas, SPCTI - Campinas, SP

Laboratório de Qualidade de Software - UNISINOSLaboratório de Qualidade de Software - UNISINOS

63


Autoria dos Slides sobre MEDE-Autoria dos Slides sobre MEDE-PROSPROS

Os próximos slides, referentes ao método de avaliação MEDE-PROS, são de autoria de Regina Colombo, da Fundação CTI, utilizados em apresentação realizada no Workshop de Qualidade que ocorreu no dia 19 de novembro de 1999, na UNISINOS.

64


Como saber se o produto é de Como saber se o produto é de qualidade segundo a visão do usuário?qualidade segundo a visão do usuário?

MEDE-PROSMEDE-PROS

Método de Avaliação deMétodo de Avaliação de

Qualidade de Produto de Qualidade de Produto de SoftwareSoftware

65


O que freqüentemente encontramos O que freqüentemente encontramos nos produtos avaliados?nos produtos avaliados?

Embalagem não consistente com o produto.

Descrição do produto incompleta.

Manual desatualizado ou incompleto.

Difícil de navegar, aprender e compreender.

Help não é sensível ao contexto.

Funcionalidade não implementada.

Erros fatais que levam à perda de dados.

...

66


Avaliar a qualidade de produto de software, segundo a visão do usuário, verificando o quanto ele está atendendo os padrões das Normas Internacionais de Qualidade.

Avaliação da Qualidade de Produto de Avaliação da Qualidade de Produto de SoftwareSoftware - MEDE-PROS - MEDE-PROS

ObjetivoObjetivo

67


Relatório de Avaliação aspectos de destaque positivo aspectos a serem revistos


ResultadoResultado

68


MEDE-PROSMEDE-PROS

Quem se BeneficiaQuem se Beneficia

Produtores Lançamento do Produto Aprimoramento do Produto

Marketing e Vendas Argumento de Venda

Usuários Verificar se o Produto é adequado às suas necessidades

Instituições de Incentivo a Produtores Financiamentos, Premiações, etc.

69


Base TeóricaBase Teórica

Qualidade de Pacotes de Software

NBR ISO/IEC12119

Definições de Qualidade

NBR 13596

ISO/IEC 9126-1Características da Q.Software

ISO/IEC 9126-2Métricas Externas

ISO/IEC 9126-3Métricas Internas

ISO/IEC 14598-1Visão Geral

ISO/IEC 14598-2Planej / Gerenciamento

ISO/IEC 14598-3Processo de Desenvolvimento

ISO/IEC 14598-4Processo de Aquisição

ISO/IEC 14598-5Processo p/ Avaliadores

ISO/IEC 14598-6Doc. Módulos de Avaliação

ISO/IEC 14598 ISO/IEC 12119

ISO/IEC 9126-4Qualidade em Uso

ISO/IEC 9126

Processo de Avaliação

70


NBR 13596NBR 13596

Totalidade de aspectos da qualidade de produto

Definição de 6 Características Mínimo de Sobreposição Sem Métodos para Medição

Qualquer tipo de Software

71


Estabelece os Requisitos de Qualidade para Pacotes de Software

Como Testar um Pacote de Software com Relação aos Requisitos Estabelecidos

Não trata do Processo de Desenvolvimento dos Pacotes de Software


72


Tecnologia de informação - Avaliação de produto de Tecnologia de informação - Avaliação de produto de

software - software - Parte 5: Processo para avaliadoresParte 5: Processo para avaliadores

Define atividades para: analisar requisitos da avaliação especificar projetar executar e concluir ações de avaliação

de qualquer tipo de produto de software.

ISO/IEC 14598-5ISO/IEC 14598-5

73


Análise deRequisitos da

Avaliação

Especificaçã

oda Avaliação

Projeto da Avaliação

Execução da Avaliação

Conclusão da Avaliação

Requisitos do Solicitante

Entradas do Solicitante

Relatório de AvaliaçãoFinal

Plano da Avaliação

Requisitos da Avaliação

Descrição do Produto

Especificação da Avaliação

Componentes do Produto

Pré-Relatório

ISO/IEC 14598-5ISO/IEC 14598-5 Processo para Avaliadores

74


MEDE-PROS® v 1/97MEDE-PROS® v 1/97

Manual doAvaliador

Manual doAvaliador

Modelo deRelatório

Modelo deRelatório

Lista deVerificação

Lista deVerificação

EstruturaEstrutura

75


ISO/IEC 9126(NBR 13596)

INTERFACE

DOCUMENTAÇÃO

SOFTWARE

DESCRIÇÃO DO PRODUTO EMBALAGEM NBR ISO/IEC 12119

ISO/IEC 9126(NBR 13596)

ISO/IEC 9126(NBR 13596)

ISO/IEC 9126(NBR 13596)

Lista de VerificaçãoLista de Verificação

NBR ISO/IEC 12119

76


Identificação Aspectos Visuais Aspectos de Robustez Aspectos Práticos.......


Componente: Embalagem

77


Identificação do documento Produto Produtor Requisitos de Hardware Requisitos de Software Interfaces com outros produtos Suporte técnico Manutenção .......


Componente: Descrição do Produto

78


Espelho da Descrição do Produto Clara, Precisa e Organizada Consistente Interna e Externamente Refletir a Interface Orientada ao Aprendizado do Usuário ...


Componente: Documentação

79


Facilidade de interação com o usuário Aspectos visuais Mensagens apresentadas Help e Tutorial Funções de Interface Consistência de dados de entrada ...


Componente: Interface

80


Funções implementadas corretamente Importação dos dados Exportação dos dados Instalação Desinstalação Falhas Cópia de Segurança Restauração dos dados ......

Lista de VerificaçãoLista de VerificaçãoComponente: Software

81


Explicação dos Procedimentos de Avaliação Explicação dos Procedimentos de Avaliação

Explicação detalhada das QuestõesExplicação detalhada das Questões

Postura do AvaliadorPostura do Avaliador

Regras e Obrigações

Confidencialidade

Termo de Compromisso

Manual do AvaliadorManual do Avaliador

82


EmbalagemDescrição do Produto

Documentação

Interface

Software

Itens AvaliadosItens Avaliados

83


Relatório de Avaliação Relatório de Avaliação do MEDE-PROSdo MEDE-PROS®®

É a resposta, que o solicitante precisa,É a resposta, que o solicitante precisa,

sobre a qualidade do produto de acordosobre a qualidade do produto de acordo

com a visão do usuário.com a visão do usuário.

É a resposta, que o solicitante precisa,É a resposta, que o solicitante precisa,

sobre a qualidade do produto de acordosobre a qualidade do produto de acordo

com a visão do usuário.com a visão do usuário.

84


Banco de Dados

Avaliação

Funcionalidades

Aplicação BMA

Bancode Dados

AAQPS - Ambiente de Avaliação daQualidade de Produto de Software


85


Características:Características:

• avaliação técnica

• só pacotes de software

• grande quantidade de produtos

• grande variedade de produtos


• avaliação técnica

• só pacotes de software

• grande quantidade de produtos

• grande variedade de produtos

Prêmio ASSESPRO: Melhor Prêmio ASSESPRO: Melhor Software do AnoSoftware do Ano

86


Chamada Nacional SOFTEX - 1997Chamada Nacional SOFTEX - 1997


• Coordenação do processo de avaliação:Coordenação do processo de avaliação: disponibilizar o MEDE-PROSdisponibilizar o MEDE-PROS®®;; treinar avaliadores;treinar avaliadores; revisar os Relatórios da Avaliação.revisar os Relatórios da Avaliação.

• Produtos de Produtos de SoftwareSoftware em diferentes estágios de em diferentes estágios de desenvolvimento.desenvolvimento.

• Grande número de produtos.Grande número de produtos.• Prazo curto de avaliação.Prazo curto de avaliação.• Diferentes categorias de produtos.Diferentes categorias de produtos.

• Coordenação do processo de avaliação:Coordenação do processo de avaliação: disponibilizar o MEDE-PROSdisponibilizar o MEDE-PROS®®;; treinar avaliadores;treinar avaliadores; revisar os Relatórios da Avaliação.revisar os Relatórios da Avaliação.

• Produtos de Produtos de SoftwareSoftware em diferentes estágios de em diferentes estágios de desenvolvimento.desenvolvimento.

• Grande número de produtos.Grande número de produtos.• Prazo curto de avaliação.Prazo curto de avaliação.• Diferentes categorias de produtos.Diferentes categorias de produtos.

87


Chamada Nacional SOFTEX - 1997Chamada Nacional SOFTEX - 1997

FortalezaFortalezaFortalezaFortaleza

# avaliadores: 6# avaliadores: 6# produtos: 16# produtos: 16

São CarlosSão CarlosSão CarlosSão Carlos


CampinasCampinasCampinasCampinas


Porto AlegrePorto AlegrePorto AlegrePorto Alegre # avaliadores: 10# avaliadores: 10# produtos: 28# produtos: 28

88


Laboratórios Credenciados Laboratórios Credenciados para Prestação de Serviço de para Prestação de Serviço de

Avaliação da Qualidade de Avaliação da Qualidade de Produto de Software utilizando Produto de Software utilizando

o MEDE-PROSo MEDE-PROS

Forta

leza

Juiz

de

Fora

São C

arlo

s

Campi

nas

Lond

rina

São L

eopo

ldo

89


Controle da QualidadeControle da Qualidade

Para continuar pensando... Etapas:

1. Definir as características de qualidade do produto ou serviço.

2. Definir como medir cada característica.

3. Estabelecer padrões de qualidade.

4. Controlar a qualidade pelos padrões.

5. Encontrar e corrigir causas de má qualidade.

6. Continuar a fazer melhoramentos.

90


1. Processo de Software1. Processo de Software

92


Processo de SoftwareProcesso de Software

ProcessoProcesso: uma seqüência de etapas realizadas com um determinado propósito (IEEE).

Processo de softwareProcesso de software: um conjunto de atividades, métodos, práticas e transformações que pessoas utilizam para desenvolver e manter sistemas de software e produtos associados (CMM/SEI).

93


Processo de SoftwareProcesso de Software

A D

C

B

Pessoas com habilidades, treinamento e motivação

Procedimentos e métodos definindo o relacionamento das tarefas

Ferramentas e equipamentos

Processo

94


Premissa do Gerenciamento do Premissa do Gerenciamento do Processo de Software - SEI/CMUProcesso de Software - SEI/CMU

A qualidade de um sistema de software é altamente influenciada pela qualidade do processo utilizado para desenvolvê-lo e mantê-lo.

A premissa sugere foco tanto no produto quanto no processo.

95


Um Processo Imaturo (SEI/CMU)Um Processo Imaturo (SEI/CMU) Ad-hoc: processo improvisado pelas pessoas

envolvidas em sua realização.

O processo não é rigorosamente seguido.

Altamente dependente das pessoas.

Baixa visibilidade do progresso e qualidade.

Funcionalidade e qualidade são freqüentemente comprometidas em relação a um cronograma.

A utilização de nova tecnologia envolve alto risco.

Retrabalho e custos de manutenção excessivos.

A qualidade é difícil de ser prevista.

96


Um Processo Maduro (SEI/CMU)Um Processo Maduro (SEI/CMU)

Consistente com a forma através da qual o trabalho é realizado.

Definido, documentado e continuamente aperfeiçoado.

Apoiado pela gerência, de forma explícita.

Controlado (através de métricas, por exemplo).

Introdução disciplinada de novas tecnologias.

97


Processo Institucionalizado Processo Institucionalizado (SEI/CMU)(SEI/CMU)

“Esta é a forma como nós fazemos as coisas aqui”.

Existência de uma infra-estrutura que contém processos aplicados de forma consistente em toda a organização.

A cultura organizacional conduz o processo.

A cultura é conduzida por distribuição de responsabilidades e recompensas.

Processos permanecem sendo utilizados, mesmo após as pessoas que os elaboraram não atuarem mais na organização.

98


Benefícios de um Processo Maduro Benefícios de um Processo Maduro (SEI/CMU)(SEI/CMU)

Aproximadamente 85% dos problemas são causados pelo processo, não pelas pessoas.

Pessoas desenvolvem melhor seu potencial e são mais efetivas na organização.

Definindo, medindo e controlando o processo, melhorias têm maior sucesso e continuidade.

2. CMM - 2. CMM - Cabability Cabability Maturity ModelMaturity Model

100


Missão Empresarial aos Estados Missão Empresarial aos Estados UnidosUnidos

Realizada de 9 a 17 de junho, de 2000.

Promovida pelo Instituto de Informática da UNISINOS.

Workshops de acompanhamento, promovidos pelo Laboratório de Qualidade de Software: julho;

setembro;

novembro.

Programa “Economia & Negócios”, da TV-COM.

101


Origem do CMMOrigem do CMM

Software Engineering Institute (SEI), da Universidade Carnegie Mellon - Pittsburgh.

Baseado nas idéias de Watts Humphrey.

Disponível em:http://www.sei.cmu.edu

102


Referência dos Slides sobre CMMReferência dos Slides sobre CMM

Slides baseados em:apresentações realizadas por Steve Master e

Edward Gebauer, do SEI/CMU, durante a Missão Empresarial aos Estados Unidos, em junho de 2000;

documentos disponíveis na home-page do SEI;

apresentação de Odisnei Galarraga, da DSI/UNISINOS, realizada durante o Workshop em Qualidade de Software, em 19 de novembro de 1999, na UNISINOS.

103


Níveis de maturidadeNíveis de maturidade

5

4

3

2

Inicial

Repetível

Definido

Gerenciado

Otimizando

Processo disciplinado

Processo padronizado, consistente

Processo previsível

Melhoria contínua

1

104


VisibilidadeVisibilidade

1 In Out

2 In Out

3 In Out

4 In Out

105


VisibilidadeVisibilidade

5 In Out

106


Nível de maturidade = capacidadeNível de maturidade = capacidadeP

roba

bilid

ade

1Alvo N

Tempo/$/...

O Cronograma e a previsão de custos normalmente “estouram” em organizações Nível 1

Pro

babi

lidad

e

2Alvo N+a

Tempo/$/...

Os planos baseados na performance do passado são mais realistas em organizações Nível 2

107



roba

bilid

ade

2Alvo N+a

Tempo/$/...

Os planos baseados na performance do passado são mais realistas em organizações Nível 2

Pro

babi

lidad

e

3Alvo N-x

Tempo/$/...

Com processos bem definidos, a performance aumenta em organizações Nível 3

108



roba

bilid

ade

3Alvo N-x

Tempo/$/...

Com processos bem definidos, a performance aumenta em organizações Nível 3

Pro

babi

lidad

e

4Alvo N-y

Tempo/$/...

Com base na análise quantitativa do processo e do produto, a performance continua a evoluir em organizações Nível 4

109



roba

bilid

ade

4Alvo N-y

Tempo/$/...

Com base na análise quantitativa do processo e do produto, a performance continua a evoluir em organizações Nível 4

Pro

babi

lidad

e

5Alvo N-z

Tempo/$/...

A performance evolui continuamente em organizações Nível 5

110


EstruturaEstruturaNíveis de maturidade

Key process areas

Contêm

Common features

São organizadas por

Key practices

Contêm

Indicam

Capacidade do processo Atingem

MetasLevam a

Implementação ou institucionalização Descrevem

Atividades ou infra-estrutura

111


Níveis de maturidade Níveis de maturidade (vistos anteriormente)(vistos anteriormente)

5

4

3

2

Inicial

Repetível

Definido

Gerenciado

Otimizando

Processo disciplinado

Processo padronizado, consistente

Processo previsível

Melhoria contínua

1

112



Key process areas

Contêm

Common features


Key practices

Contêm

Indicam


MetasLevam a



113


Key process areasKey process areas

Inicial1

Gerenciamento de requisitos Planejamento de projeto de software Acompanhamento e supervisão de projeto de software Gerenciamento de subcontratação (terceiros) Garantia da qualidade de software Gerenciamento de configuração de software

Repetível

2

114



Foco nos processos da organização Definição dos processos da organização Programa de treinamento Gerenciamento integrado de software Engenharia de produto de software Coordenação “interequipes” Revisão por pares

Definido

3

Repetitivo2

115



Gerenciamento quantitativo dos processos Gerenciamento da qualidade de software

Gerenciado

4

Definido3

116



Prevenção de defeitos Gerenciamento de mudanças tecnológicas Gerenciamento de mudanças no processo

Otimização

5

Gerenciado4

117



Key process areas

Contêm

Common features


Key practices

Contêm

Indicam


MetasLevam a



118


Metas: exemploMetas: exemplo Nível 2

Key process area: Planejamento de projeto de softwareMeta 1: Estimativas estão documentadas para

uso no planejamento e acompanhamento do projeto de software

Meta 2: Atividades e compromissos do projeto de software estão planejados e documentados

Meta 3: Grupos e indivíduos envolvidos concordam com seus compromissos relativos ao projeto de software

119



Key process areas

Contêm

Common features


Key practices

Contêm

Indicam


MetasLevam a



120


Common featuresCommon features

Compromisso de Executar (Commitment to Perform)

Capacidade para Executar (Ability to Perform)

Atividades Executadas (Activities Performed)

Medição e Análise (Measurement and Analysis)

Verificação da Implementação (Verifying Implementation)

121


Abordagem Abordagem IDEALIDEAL

Initiating

Diagnosing

Acting

Leveraging

Establishing

122


Motivos...Motivos...

Initiate (Iniciar)

Diagnose (Diagnosticar)

Establish (Estabelecer)

Act (Agir)

Leverage (Influenciar)

“Uma jornada de 10.000 milhas começa com nada mais do que um simples passo.”

“Se você não sabe onde está, um mapa não vai ajudá-lo.”

“Se você não sabe para onde está indo, qualquer caminho serve.”

“Se você não confere a rota, não saberá quando estiver fora do curso.”

“Se os pioneiros não relatam que o caminho é seguro, os colonizadores não vão segui-los.”

123


SEPG (SEPG (Software Engineering Software Engineering Process GroupProcess Group))

Grupo formado por profissionais da empresa.

Direciona e facilita a implantação dos processos dos níveis do CMM.

Diretamente relacionado ao aperfeiçoamento da qualidade dos processos de software em uma organização.

124


Estrutura: visão geralEstrutura: visão geralCMMCMM

1 2 3 4 55 níveis de maturidade

KPAKPAKPAKPAKPAKPA

0 6 7 2 30-7 KPAs por nível de maturidade

= 18 KPAs

Meta = 52 metas 2-4 metas por KPA

= 316 key practices1-n 1-n 1-n 1-n 1-n

Atividades que implementam os requisitos processuais e de infra-estrutura para institucionalizar o processo

5 common features por KPA com 1-n práticas cada


PERGUNTAS??PERGUNTAS??

Profa. Juliana Herbert - [email protected]. Juliana Herbert - [email protected]

Centro de Ciências Exatas e TecnológicasCentro de Ciências Exatas e Tecnológicas

UNISINOSUNISINOS

engenharia de software profa. juliana herbert centro de ciências exatas e tecnológicas...

Documents