Desenvolvimento e qualidade de software utilizando metodos Ageis

Gerência de Configuração de Software

eQualidade de SoftwareFagner Souza e Eurípedes Silva

São Paulo IPT, 28 de Abril de 2011

2

Agenda

1. Introdução1. Objetivo2. Referências Bibliográficas3. Premissas e Restrições

2. Gerência de Configuração de Software1. Hipóteses2. Recapitulando o estudo de caso3. Modelo de Processo4. Arquitetura de Software5. Plano de Gerência de Configuração6. Infraestrutura de Gerência de Configuração

3. Qualidade de Software1. Hipóteses2. Modelo de Processo3. Plano de Garantia da Qualidade

28 de Abril de 2011 Estudo de Caso - Restaurante DaGinoFagner Souza e Eurípedes Silva

3

Objetivo

• Proposta para um plano de Gerência de Configuração do Processo de Software.

• Proposta para um plano de Garantia da Qualidade.


4

Referências Bibliográficas• [SWEBOK2004] IEEE SWEBOK 2004, IEEE Guide to the Software Engineering Body of Knowledge

2004 Version.• [IEEE12207] IEEE/EIA 12207.0TM-1996, IEEE Standard for Information Technology Software Life

Cycle Processes.• [IEEE828-2005] IEEE Std 828 TM-2005, IEEE Standard for Software Configuration Management

Plans.• [IEEE730-2002] IEEE Std 730TM-2002, IEEE Standard for Software Quality Assurance Plans.• [IEEE610-1990] IEEE Std 610.12TM-1990, IEEE Standard Glossary of Software Engineering

Terminology.• [Whi02] White, B.A. Software Configuration Management Strategies and Rational ClearCase.

Addison-Wesley 2000.• [Fai09] Fairley, R.E. Managing And Leading Software Projects. Wiley-IEEE Computer Society Press

2009.• [Bec99] Beck , K.. Extreme Programming Explained. Addison-Wesley 1999.• [App04] Appleton, B.. Agile Configuration Management Environments. Chicago SPIN, 2004.• [Has02] Hass, A.M.J. Configuration Management Principles and Practice. Addison-Wesley 2000.• [Ast03] Astels, D. Test-Driven Development: A Practical Guide. Prentice Hall PTR 2003.• [Lew04] Lewis, W. E. Software Testing and Continuous Quality Improvement 2 edition. 2004.• [PMBOK2004] Project Management Body Of knowledge. Project Management Institute 2004.• [ISO] International Organization for Standardization - Séries 9000 e

14000, 9001:2000, 12207, 15504, 28 de Abril de 2011 Estudo de Caso - Restaurante DaGino

Fagner Souza e Eurípedes Silva

• Consultoria de TI E & F Systems Tecnologia da Informação está contratada para a implementação do Sistema GMS GinoManagmentSystem, (denominação, conforme apresentação do Grupo G3); bem como a prestação de serviços de suporte e manutenção pós- implantação, incluindo Qualidade de software.

A Empresa Restaturantes DaGino não é da Área de Tecnologia da Informação e portanto não tem “expertise” técnico nesta área;

A Gestão de Qualidade, conforme contrato estabelecido entre as partes vai prestar serviços de controle de qualidade e garantia de qualidade exclusivamente para o projeto de implementação e manutenção do GMS, estando fora os processos organizacionais da Empresa.

Os trabalhos apresentados pelos grupos anteriores foram adaptados e parcialmente incorporados ao planejamento da E & F Systems TI.


Premissas e Restrições

6

Premissas e Restrições• O Desenvolvimento será local e na E & F Systems, conforme definições do

Planejamento do projeto. Este trabalho foi baseado em alguns aspectos de apresentações anteriores (não em todos).

• O contrato entre a E & F Systems e Restaturantes DaGino está assinado pela Direção das Empresas e é composto de documento de Termo de Confidencialidade de informações e Acordo de nível de Serviços estabelecido entre as partes.

• A Empresa Restaurantes DaGino está ciente da metodologia de Desenvolvimento e Homologação de Softwares, Gestão de projetos da E & F fundamentadas nas recomendações da IEEE SWEBOK 2004 e ] IEEE/EIA 12207.0TM-1996

• Não é escopo desse trabalho apresentar e detalhar metodologias ou métodos Ágeis e Qualidade em termos organizacionais.


7

Restrições• Custo do projeto:

Para a implementação e fases de suporte e manutenção o orçamento não deverá ultrapassar o valor definido em reunião da Direção das Empresas DaGino e E & F Systems.

28 de Abril de 2011 Estudo de Caso - Restaurante DaGinoFagner Souza, Eurípede, Alan

Gerência de Configuração do Software

Estudo de caso: Restaurante DaGino

9

Hipóteses

• Modelo de processo de software.• Arquitetura de Software.


10

HipótesesModelo de processo de software

28 de Abril de 2011

Extreme Programming

Estudo de Caso - Restaurante DaGinoFagner Souza e Eurípedes Silva

11

Recapitulando o estudo de caso


COZINHASALÃO

Reservar mesa

Application Server

Pedir prato

Display de Pedidos

Terminal de Cozinha

Pedidos prontos

RECEPÇÃO

Fechar mesa

Pocket PC

12

HipótesesArquitetura de Software

28 de Abril de 2011

Sistema DaGino


13

• É um time ágil (XP). Composto por:– 1 Líder;– 2 Desenvolvedores Plenos;– 4 Desenvolvedores Juniores;

• !!!!!Todos são desenvolvedores!!!!!

28 de Abril de 2011

HipótesesO time de desenvolvimento do sistema DaGino


14

Software Configuration Management PlanO que é?

28 de Abril de 2011

É um documento que define as estratégias para o controle de alterações no software.


15

No escopo da 12207


16

O que há no plano?

• Definição dos itens da configuração;• Versionamento desses itens ao longo do

tempo;• Ferramentas para controle das versões dos

itens de configuração;• Ferramentas para controle das requisições de

alterações nos itens da configuração;• ...enfim, controle da MUDANÇA.


17

Por que eu preciso disso?

• Porque o software muda (evolui);• Porque o time muda (as pessoas vão e vem);• Porque a empresa muda (estratégia,

processo);• Porque até você muda (se você estiver

aprendendo, então você também evolui);


18

Aplicando para o DaGinoIdentificando os ICS

• Item de Configuração de Software (ICS): conjunto de software que é designado para GC e tratado como uma entidade única no PGC (IEEE610-1990).

• Exemplos típicos: planos, especificações, documentação de design, material de teste, ferramentas de software, código fonte (.java, .c, .html e etc) e executáveis (.class, .jar, .exe, .so e etc), bibliotecas (.h, .jar, e etc), dados e dicionário de dados, documentação para instalação, manutenção e operação e uso do software (SWEBOK2004).


19



20


28 de Abril de 2011 Estudo de Caso - Restaurante DaGinoFagner Souza, Eurípedes, Alan

• User Stories: requisitos do sistema;• Achitectural Spike: System Metaphor, ou arquitetura

do sistema;• Release Plan: plano de liberação, contendo quais

User Stories estarão presentes no trabalho a ser realizado na iteração seguinte;

• Acceptance Tests: testes de aceitação;• Small Releases: versões finalizadas e aprovadas pelo

cliente. São compostas por um ou mais dos módulos presentes na arquitetura do sistema;

21

O objetivo deste documento é descrever quais ICs devem ser armazenados e versionados, bem como estabelecer as regras para alteração desses itens. O documento é destinado aos desenvolvedores, cliente e demais pessoas diretamente envolvida no desenvolvimento do Software DaGino para o Restaurante DaGino.

28 de Abril de 2011

Aplicando para o DaGinoPlano de Gestão de Configuração de Software

Introdução: Propósito


22

a) O projeto a que este documento se refere é software para automação das atividades de reserva de mesa, pedido de pratos, controle de receitas de pagamento do restaurante DaGino.b) Os seguintes itens de configuração fazem parte desse projeto: User Stories, System Metaphor, Software releases e etc;c) Os seguintes sistemas de apoio constam do plano e das atividades realizadas no processo de desenvolvimento: JUnit, Subversion, Redmine e etc;d)Este plano relaciona-se com o PGCH na medida que funcionalidade do sistema de software dependem de características específicas disponíveis e controladas pelas diversas versões do hardware. Sempre que esse for o caso, o PGCH deverá ser citado, e uma relação entre o IC do PGCH e de sua contraparte no PGCS devem ser claramente relacionadas.e) O grau de formalidade deste plano será limitado ao permitido pelo paradigma ágil, e o controle de alteração não envolverá nenhum tipo de autorização senão aqueles já previstos no processo de desenvolvimento XP.f) Nenhuma limitação.g) Nenhuma questão adicional;

28 de Abril de 2011


Introdução: Escopo


23

• IC: Item de Configuração.• ICS: Item de Configuração de Software.• PGCS: Plano de Gestão de Configuração de Software.• Pocket PC: Computador de mão, utilizado na solução de software a que se

refere este documento;• PVRT: Plano de Validação de Resultados de Testes;• EF: Especificação Funcional;• ...

28 de Abril de 2011


Introdução: Glossário


24

• [SWEBOK2004] IEEE SWEBOK 2004, IEEE Guide to the Software Engineering Body of Knowledge 2004 Version.

• [IEEE12207] IEEE/EIA 12207.0TM-1996, IEEE Standard for Information Technology Software Life Cycle Processes.

• [IEEE828-2005] IEEE Std 828 TM-2005, IEEE Standard for Software Configuration Management Plans.

• [IEEE730-2002] IEEE Std 730TM-2002, IEEE Standard for Software Quality Assurance Plans.

• [IEEE610-1990] IEEE Std 610.12TM-1990, IEEE Standard Glossary of Software Engineering Terminology.

• …

28 de Abril de 2011


Introdução: Referências


25

Desenvolvimento

Cliente

Desenvolvedores

Gerente do Projeto

Manutenção

Cliente

Desenvolvedores

28 de Abril de 2011


GCS Gestão: Organização


26

Papeis

28 de Abril de 2011

Desenvolvimento

Cliente

Desenvolvedores

Gerente do Projeto

• Solicita novos requisitos (User Stories)• Aprova o resultado das iterações

• Desenvolvem requisitos

• Aprova novos requisitos (User Stories)


GCS Gestão: Organização | Papeis - Desenvolvimento


27

Papeis

28 de Abril de 2011

Manutenção


GCS Gestão: Organização | Papeis - Manutenção

Cliente

Desenvolvedores

• Reporta falhas no software• Aprova o resultado das iterações

• Desenvolvem correções para as falhas


28

• …

28 de Abril de 2011


GCS Gestão: Responsabilidades


ResponsabilidadesUnidade

Cliente

Desenvolvedores

Gerente do Projeto

• Aprova o resultado das iterações. A Baseline é estabelecida após aprovação da Iteração 0

• Decide prioridade das User Stories e Change Requests

• Aprova novos requisitos (User Stories):• Somente alterações funcionais na Baseline

passam por aprovação

• Estima esforço para cada User Story e Change Request;• Implementa as User Stories e Change requests

29

• O time de desenvolvimento é ágil (XP) e PGCS deve ser leve o suficiente para permitir que o time continue sendo (ágil). As principais características do time estão listadas abaixo e devem ser usadas como restrição a aplicação do PGCS:– Projetos ágeis dependem de: um bom diálogo com o usuário, entrega

da execução, código testado a cada duas a doze semanas e frequente feedback sobre a qualidade de requisitos e projeto.

28 de Abril de 2011


GCS Gestão: Políticas, diretrizes e procedimentos


[Has02]

30

• Os seguintes termos e conceitos no PGCS devem ser considerados com base nas restrições definidas aqui:– Controle de Alteração, começa no primeiro dia de projeto para o time ágil, e é baseado

na comunicação com o usuários e clientes. Com isso os requisitos são extraídos ou na forma de novas funcionalidades ou na forma de change requests de funcionalidades já desenvolvidas. O time estima o esforço e o cliente estima a prioridade de cada solicitação para a próxima iteração; Esse processo é dinâmico, constante e é o equivalente ágil para o CCB.

– Autorização para Alteração. O time tem autorização automática para alterar o código em duas situações: • Implementar novas características (ex. User Stories), já aprovadas;• Refactoring para melhorar a simplicidade do código (leitura e manunteção);

– Identificação, armazenamento, integração e build. Releases e marcos importantes dos builds são facilitados pelo recurso “tag” da ferramenta de controle de versão; O desenvolvedor executa testes unitários, realizam builds privados do sistema e executa Smoke Tests antes de realizar commits de seu ambiente privado para o repositório de desenvolvimento do time. Builds de integração devem passar nos testes de regressão e serem reconstruídos do zero antes de serem submetidos aos testes de aceitação (funcional).

28 de Abril de 2011


GCS Gestão: Políticas, diretrizes e procedimentos | Termos e efeitos


[Has02]

31

• …

28 de Abril de 2011


GCS Gestão: Gestão do processo de GCS


3228 de Abril de 2011


GCS Atividades: Identificação da Configuração| Composição da Baseline


BASELINE

MÓDULO ESTOQUE

MÓDULO RECEPÇÃO

MÓDULO COZINHA

MÓDULO CAIXA

COM

POSI

ÇÃO

codes release plansuser stories ...



GCS Atividades: Identificação da Configuração | Evolução da Mudança


[App04]

34

Tipo do arquivo

Convenção Example

User Story Ticket Eletrônico https://redmine.dagino.com.br/userstories/2774

Achitectural Spike ACH_MMNN.doc ACH_0101.doc

Acceptance Tests TST_ACC_Modulo_Funcionalidade_MMNN.doc TST_ACC_Caixa_CadastrarUsuario_0211.doc

Release Plan RPL_MMNN.doc RPL_0101.doc

Manual do Usuário UMN_Modulo_SubModulo_MMNN.doc UMN_Caixa_Cadastro_0109.doc

Change Request Ticket Eletrônico https://redmine.dagino.com.br/changerequests/2885

Release Note RSN_MMNN.doc RSN_0101.doc

28 de Abril de 2011


GCS Atividades: Nomeando Cis | Sistema para identificação


MMNN é um número composto da seguinte maneira: MM : running number NN : número da iteração

https://redmine.dagino.com.br/userstories/2774

https://redmine.dagino.com.br/changerequests/2885



GCS Atividades: Nomeando Cis | Sistema para identificação | Ticket Eletrônico


User StoriesTicket number: 2774 Título: Garçon reserva mesa para cliente Descrição: cliente solicita mesa ao garçon e esse aloca a mesa no local de escolha do clienteIteração: 0 Data: 23/04/2011 Cliente: Dino Desenvolvedor: Fagner Souza Status: Pendente Owner: Project Manager Detalhes: 1 - Cliente chega ao restaurante e solicita reserva de mesa para x pessoas; 2- Garçon consulta sistema para verificar mesas disponíveis; 3- Cliente escolhe a mesa; 4- Garçon marca a mesa como alocada para cliente;

Status Owner Descrição

Pendente Project Manager Falta liberação para o desenvolvimento

Analise Desenvolvedor Falta levantamento de dados: esforço, etc.

Liberado Cliente Falta aprovação do clienteAceito Cliente Requisito em produção



GCS Atividades: Nomeando Cis | Sistema para identificação | Ticket Eletrônico


Change RequestTicket number: 2885 Título: Messagem de erro ao excluir usuárioTipo: CorreçãoMódulo: Caixa Data: 23/04/2011 Cliente: Gino Status: Pendente Detalhes: Ao tentar excluir usuário do cadastro do Caixa, exibe mensagem de erro contendo os seguintes dados: DaoExceptionError! Mod=Caixa,Sub=Cadastro,id=12345

Tipo Descrição

Correção Falha verificada junto a uma funcionalidade entregue

Funcionalidade Mudança junto a uma funcionalidade e solicitada pelo cliente

Status Descrição

Pendente Falta liberação para o desenvolvimento

Analise Falta levantamento de dados: esforço, etc.

Liberado Falta aprovação do cliente

Aceito Pronto para produção

37

• …

28 de Abril de 2011


GCS Atividades: Aquisição dos itens de configuração


38

• Autorização para desenvolvedores fazerem alterações precisam ser instantâneas:– Uma vez que o desenvolvedor tenha sido definido, ele não deveria ter

que esperar para começar a fazer check out de itens do repositório;– Se um bug quebra o build ou um teste de requisito falha, o

desenvolvimento deve ser capaz de realizar o reparo sem ter que aguardar qualquer período de tempo para receber “Autorização”;

– Nenhuma permissão adicional é requerida para o refactoring;

28 de Abril de 2011


GCS Atividades: Controle da configuração


[App04]

• É necessário autorização da gerência de projeto na definição de quais User Stories serão produzidas ao longo do projeto;

39

• Atendimento através das ferramentas de apoio e infra-estrutura para GCS:– Sistema de Controle de Versão, através de Check-in documentado. Ex.:

– Ferramenta para gestão através de Tickets Eletrônicos, através da geração automática de relatórios de quantidades de falhas registradas para um IC, tempo gasto para a correção das falhas, tempo gasto no desenvolvimento de User Stories e etc;

28 de Abril de 2011


GCS Atividades: Estado da configuração | Relatórios


User ID.........: fagnerls.Issue ID........: 2885.Description..: Messagem de erro ao excluir usuário.Solution.......: Corrigido nome da tabela no select principal.Comments....: atualização replicada para o teste unitário.

40

• Deverá ser atendido em face do Plano de Garantia da Qualidade;

• A revisão será feita com base nas User Stories armazenadas no sistema de controle por tickets, e cada não conformidade deve ser registrada no ticket relativo a User Story avaliada, sendo que seu status deve ser alterado para refletir sua nova condição para que a equipe de desenvolvimento possa atuar;

28 de Abril de 2011


GCS Atividades: Revisão da configuração


41

• …

28 de Abril de 2011


GCS Atividades: Interface de Controle


42

• …

28 de Abril de 2011


GCS Atividades: Controle de Subcontrato


43

• …

28 de Abril de 2011


GCS Atividades: Gerenciamento de Entrega


44

• …

28 de Abril de 2011


GCS Agendamentos: .


45

• …

28 de Abril de 2011


GCS Manutenção do Plano: .


46

O que mais poderia fazer parte do Plano?

o conjunto de software em execução nesses equipamentos, como SO, plataformas de execução (VM), plugins, firmwares e etc:– Pocket PC;– Servidor de aplicação;– Workstation;


Qualidade de Software

Estudo de caso: Restaurante DaGino

48

O que é qualidade ?• Qualidade é estar em conformidade com os requisitos dos clientes

• Qualidade é antecipar e satisfazer os desejos dos clientes

• Segundo a atual norma brasileira sobre o assunto (NBR ISO 8402), qualidade é:– A totalidade das características de uma entidade– que lhe confere a capacidade de satisfazer– às necessidades explícitas e implícitas.


49

Qualidade Segundo os “Gurus• Crosby• Conformidade com as especificações• “Fazer certo da primeira vez”• O gerenciamento da qualidade deve ser feito desde o início• Evitar defeitos e diminuir o retrabalho• Juran• “Adequação ao uso”• As expectativas dos clientes são atendidas ou até excedidas• Qualidade obrigatória: o produto faz o que devia fazer• Qualidade atrativa: o produto oferece algo que o cliente nem imaginava, mas que ele gostou• Weinberg• “Valor para alguma pessoa”• Deming• “Qualidade é orgulho da manufatura”• 85% do custo da qualidade é um problema de gerenciamento


TQM (Total Quality Management), amplamente usado nas organizações

• Kan (2002)

28 de Abril de 2011 50Estudo de Caso - Restaurante DaGinoFagner Souza e Eurípedes Silva

51

Complexidade na definição

28 de Abril de 2011

"Criar um conjunto de atividades que irão ajudar a garantir que cada produto de trabalho da engenharia de software exiba alta qualidade"; (PRESSMAN, 2005, p. 193)

"Realizar atividades de segurança da qualidade em cada projeto de software";(PRESSMAN, 2005, p. 193)

"Usar métricas para desenvolver estratégias para a melhoria de processo de software e, como conseqüência, a qualidade no produto final"; (PRESSMAN, 2005, p. 193)


52

Os Fatores da Qualidade de McCall


53

Qualidade de Software segundo a ISO 9126-1• Funcionalidade(Satisfação das Necessidades): É a capacidade do produto de

software de prover funcionalidades que irão satisfazer as necessidades quando o software está em uso dentro das condições especificadas.

• Confiabilidade(Imunidade a Falhas): É a capacidade do produto de software de manter um nível especificado de performance quando o software está em uso dentro das condições especificadas.

• Usabilidade(Facilidade de Uso): É a capacidade do produto de software de ser entendido, aprendido, usado e atrativo quando o software está em uso dentro das condições especificadas.

• Eficiência(Rápido e "Enxuto"): É a capacidade do produto de software de prover performance apropriada, relativa ao conjunto de recursos usados quando o software está em uso dentro das condições especificadas.

• Manutenibilidade(Facilidade de Manutenção): É a capacidade do produto de software de ser mudado. Modificações incluem correções, melhorias ou adaptações do software de mudar em um ambiente, e em requisitos e especificações funcionais.

• Portabilidade(Uso em outros Ambientes): É a capacidade do produto de software de ser transferido de um ambiente para outro.


54

Outras normas da série ISO 9126

• ISO/IEC 9126-2 - Métricas Externas: Podem ser aplicadas para um produto não executável durante os estágios de desenvolvimento. Medem a qualidade de produtos intermediários e predizem a qualidade do produto final.

• ISO/IEC 9126-3 - Métricas Internas: Utilizadas para medir a qualidade do software através do comportamento do sistema ou de parte dele. Só podem ser usadas durante a fase de testes do ciclo de vida e durante a operação do sistema.

• ISO/IEC 9126-4 - Métricas da Qualidade do Uso: medem se o produto atende ou não as necessidades dos usuários, fazendo-os atingir seus objetivos com efetividade, produtividade, segurança e satisfação. Só podem ser usadas no ambiente real ou em uma aproximação do ambiente real.


55

A Qualidade segundo o PMBOK

28 de Abril de 2011

[PMBOK2004]


CMMI 1.2

Nível

5 EmOtimização

4 GerenciadoQuantitativam.

Foco

MelhoriaContínua do

Processo

GerênciaQuantitativa

Áreas de Processos

Inovação e Implantação OrganizacionalAnálise e Prevenção de Defeitos

Gerenciamento Quantitativo do ProjetoPerformance do Processo Organizacional

Desenvolvimento de RequisitosSolução TécnicaIntegração de ProdutosVerificaçãoValidaçãoFoco no Processo OrganizacionalDefinição do Processo OrganizacionalTreinamento OrganizacionalGerência Integrada de ProjetoGerência de RiscosAnálise e Tomada de Decisão

Gerência de RequisitosPlanejamento de ProjetoMonitoramento e Controle de ProjetoGerência de Acordos com FornecedoresMedição e AnáliseGarantia da Qualidade do Processo e do ProdutoGerência de Configuração

ProdutividadeQualidade

3 Definido Padronizaçãodo Processo

2 GerenciadoGerênciaBásica deProjetos

1 Inicial

14/04/2007

RiscoRetrabalho

© 2007

57

Qualidade do Processo e do Produto

• Qualidade do produto está ligada às características do resultado do processo, geralmente especificadas na forma de requisitos

Requisitos de negócio, de usuário, funcionais, não-funcionais,técnicos

• Qualidade do processo está ligada à forma como o produto é feito

Monitoramento da execução, uso adequado dos artefatos eferramentas, seqüência das tarefas


58

Diferenças entre Garantia da Qualidade e Controle da Qualidade

Quality Assurance Quality Control 1. Garantia da qualidade garante que o processo é definido e apropriado. 2. Metodologia e padrões de desenvolvimento são exemplos de garantia da qualidade. 3. Garantia da qualidade é orientada a processo. 4. Garantia da qualidade é orientada a prevenção. 5. Foco em monitoração e melhoria de processo. 6. As atividades são focadas no inicio das fases no ciclo de vida de desenvolvimento de software. 7. Garantia da qualidade garante que você está fazendo certo as coisas e da maneira correta.

1. As atividades de controle da qualidade focam na descoberta de defeitos em itens específicos. 2. Um exemplo de controle da qualidade poderia ser: "Os requisitos definidos são os requisitos certos?". 3. Controle da qualidade é orientado a produto. 4. Controle da qualidade é orientado a detecção. 5. Inspeções e garantia de que o produto de trabalho atenda aos requisitos especificados. 6. As atividades são focadas no final das fases no ciclo de vida de desenvolvimento de software. 7. Controle da qualidade garante que os resultados do seu trabalho são os esperados conforme requisitos.


59

Qualidade de Software - SWEBOKSWEBOK(Software Engineering Body of Knowledge) versão 2004


60

Técnicas de Gestão de qualidade de Software

• Técnicas estáticas,• Analíticas• Dinâmicas


61

Métricas – Qualidade de software

• Estatistica ( Análise Pareto, gráficos• Gráfico de dispersão, distribuição normal)• Testes estatísticos (binomial)• Análise de Tendência• Modelos de confiabilidade


62

Âmbito da ISO12207

[ISO12207-95 p.17]

Garantia da Qualidade


63

Processos de gestão da qualidade de Software (SQM)

• Garantia da qualidade• Verificação• Validação• Revisão• Auditoria

28 de Abril de 2011 [IEEE12207.0-96] Estudo de Caso - Restaurante DaGinoFagner Souza e Eurípedes Silva

64

PADRÃO IEEE Std 730-2002

• O objetivo desta norma é fornecer uniformes, os requisitos mínimos aceitáveis para a preparação econteúdo dos planos de software de qualidade.Ao considerar a adopção desta norma, as entidades reguladoras devem estar cientes de que a aplicação específica destepadrão já pode ser coberta por um ou mais documentos ou IEEE padrões ANSI relativos à qualidadegarantia, as definições, ou outros assuntos.


65

Custo da Qualidade de Software

• custo de qualidade de software proposto por Bartié (2002)• a) Custo da Detecção de Defeitos:• Revisões de requisitos; modelagem, planos de testes, inspeções• Custo da Prevenção de Defeitos• Definição de Metodologias; • - Treinamentos; • - Ferramentas de apoio ao processo de desenvolvimento; • - Definição de Políticas; • - Procedimentos;

• Custo da Não-Conformidade:• Re-reviões; • - Re-testes; • - Correções de código-fonte e documentação muito constantes;


66

Gestão da qualidade de processo de software

• Gestão da qualidade de software se aplica a todas perspectivas de processos de software, produtos e recursos. Define processos, os responsáveis pelo processo, e osrequisitos para os processos, as medições dacanais de processo as saídas e feedback.

28 de Abril de 2011 Estudo de Caso - Restaurante DaGinoFagner Souza, Eurípedes, Alan

67

Hipóteses

Modelo de processo de software para oestudo de caso Restaurantes DaGino Foco: Gerência da qualidade do software.

28 de Abril de 2011

• modelo de processo.• a aplicação de um plano de garantia da qualidade – garantia do produto e do processo – para o estudo de caso.

Justificativas.



Projeto DaGino - XP e Qualidade

69

Qualidade: modelos ágeis

• A aferição da qualidade do produto está totalmente atrelada a inspeção do processo.No caso do XP, podemos considerar que a programação pareada como um forma de inspeção e isto associado a outras práticas tais como uso de TDD (Desenvolvido orientado a Testes) podem dar a qualidade ao produto.


70

TDD – Test Driven Development


71

TDD

• ● Desenho Simplificado e Evolucionário• ● Refatoração• ● Feedback Constante• ● Suíte de Testes (Regressão)• ● Documentação Para Programadores


Artigo XP e CMM - Mark Paulk

28 de Abril de 2011 72Estudo de Caso - Restaurante DaGinoFagner Souza e Eurípedes Silva

Responsabilidades da equipe de garantia

Interargir com Equipe do projeto

Rever planos e artefatos

Facilitar reuniões e revisões

Auditar atividades e artefatos do projeto

Coletar, analisar e reportar dados de medição

Trabalhar com o grupo de processos para assegurarque os processos são úteis e utilizáveis

14/04/2007 © 2007

• Composto por:– Coordenador de Garantia de Qualidade;– 1 Analista de Controle de Qualidade;

• Reporte externo ao Gerente de Qualidade da Consultoria

28 de Abril de 2011 74

Hipóteses Projeto GMS DaGinoO Equipe de garantia de Qualidade para o projeto


Justificativas• As características do projeto requerem uma equipe

dinâmica, uma vez que o projeto em grande parte será na sede da Consultoria.

• Projeto considerado de médio porte, conforme documentação anterior.

• Comunicação• Simplicidade • Feedback constante

[ISO12207-95, Anexos A e B]


76

PLANO DE GARANTIA DE QUALIDADE DE SOFTWARE Std 730-2002

• 1) Finalidade2) documentos de referência3) Gestão4) Documentação5) As normas, práticas, convenções e métricas6) Software opiniões8) o relatório de problemas e ações corretivas9) Ferramentas, técnicas e metodologias10) controle de mídia11) controle de fornecedores12) A recolha Records, manutenção e conservação13 Formação)14 A gestão de riscos)15 Glossário)16) SQAP processo de mudança e história


77

Glóssário

28 de Abril de 2011

CMMi Capability Maturity Model Integrated COTS Commercial Off-the-shelf Software Plano PDCA Plan, Do, Check, Act SQA Garantia da Qualidade de Software SQM Gestão da Qualidade de Software TQM Gestão da Qualidade Total V & V Verificação e Validação


78

Considerações Finais

• Qualidade não deve ser só inspecionada, mas embutida!

• Antes de questionar o custo da qualidade, questione o custo da falta de qualidade

• Lembre-se que a qualidade é um dos 4 principais compromissos do projeto

• As ferramentas devem ser as aliadas da qualidade nos processos

• Pessoas + Processos + Ferramentas = Sucesso28 de Abril de 2011 Estudo de Caso - Restaurante DaGino

Fagner Souza e Eurípedes Silva

Obrigado ;)

Fagner Souza e Eurípedes