Qualidade de Software

Qualidade de software
Prof. PhD. Samyr Vale
Avaliao de Qualidade
Aps Revoluo Industrial Medio de Qualidade de produtos produzidos em srie Para produtos concretos avalia-se peso, volume, dimenses, resistncia, ... Para produtos abstratos, como o Software, necessrio identificar atributos que permitam tornar o produto visvel. Ex.: Nmero de erros de entrada sada Dificuldades na avaliao de qualidade o mesmo produto pode ser avaliada de diferentes maneiras por pessoas diferentes.
Qualidade de Software
Modelos de Qualidade Permite tomadas de decises com segurana Preparao para competitividade Diminuio de riscos Qualidade de software => qualidade na Empresa Melhoria no desempenho e aumento na produtividade Resolver os problemas da Indstria do software Instituto de Engenharia de Software (SEI), prope: i) CMM (Capability Maturity Model) ii) PSP (Personal Software Process)
Padres, normas e unidades de medida tem sido largamente utilizados como medidas de qualidade de software Em 1930, A. Shewhart apresenta o controle estatstico de qualidade Aps II Guerra, o aumento da produo e do consumo impulsiona a busca por melhorias na fabricao de produtos e na realizao de servios Os nveis de qualidade forma definidos em: i) Inspeo do Produto identificao de defeitos ii) Controle de Qualidade taxas de defeitos iii) Melhoria dos Processos minimizar a taxa de defeitos
Hoje, a qualidade tem nos processos e produtos tornouse condio de sobrevivncia Existe uma grande quantidade tcnicas, modelos e escolas de qualidade Teoria de Frederick Taylor (1950) Administrao cientfica (os processos repetidos podem ser controlados) Teoria de Edwards Deming (1982) Controle Estatstico (qualidade um grau previsvel de uniformidade) Teoria de Armand Feigenbaum (1950) Qualidade Total (compromisso com a excelncia, participao de todos LIDERANA TECNOLOGIA - COMPROMISSO)
Teoria de Josef Juran (1950) arquiteto da revoluo da qualidade: - qualidade orientada pelas caractersticas do produto que satisfazem as necessidades do cliente - qualidade orientada pelo custo (reduo de desperdcios) - planejamento da qualidade (equipes) - controle da qualidade (inspeo) - melhoria da qualidade (identificao de melhorias)
Teoria de Philip Crosby (1960) Defeito zero Engenharia com responsabilidade Adotada no Japo e nos EUA, anos 60 Responsabilidade atribuda ao trabalhador Motivao
Gerenciamento da Qualidade
A responsabilidade do gerenciamento da qualidade garantir que o nvel esperado de qualidade do processo, produto ou servio seja alcanado. Definio de padres, procedimentos e modelos Verificao de execuo destes padres Tcnicas de Gerenciamento de Qualidade: PDCA (Plan Do Check Act) proposto por Deming e Shewhart Pode ser usado em todas as fases do ciclo de vida de um produto ou processo
Tcnicas de Gerenciamento de Qualidade:
Act Check
Do Plan
Tcnicas de Gerenciamento de Qualidade Melhoria da qualidade (Deming) um processo permanente que visa: - Prevenir e corrigir problemas - Reduzir custos e prazos - Melhorar a qualidade dos produtos e servios - Evitar defeitos e retrabalho - Aumento da competitividade
Tcnicas de Gerenciamento de Qualidade Gerenciamento da Qualidade Total TQM Filosofia melhorar continuamente a produtividade em todos os nveis operacionais e reas funcionais de uma empresa Utilizao de todos os recursos disponveis Integrao de todos os empregados, fornecedores e usurios da empresa
Qualidade de Software SQA (Software Quality Assurance) Diferentes conceitos de qualidade de software No h consenso Exemplos de Definies: Software sem defeitos Software adequado ao uso Software que atende as especificaes Software desenvolvido por empresa que possui certificado ISO 9000 Software que possui confiabilidade / usabilidade / manutenibilidade
Qualidade de Software Pessoas com diferentes vises do software possuem diferentes conceitos de qualidade Cliente considera qualidade se o software atende suas necessidades Desenvolvedores consideram qualidade se medidas de comparao das propriedades do software com certos indicadores so atendidas Empresas consideram qualidade fatores como custo mnimo e reutilizao com pouco re-trabalho Para Yourdon (1995) um software de qualidade tem que funcionar, fazer o que o cliente espera, ficar pronto no prazo, ser confivel, ser modificado e mantido.
Qualidade de Software O que acontece na prtica ? Pouca qualidade Prazos no cumpridos Problemas concentrados na mo do expert Software sem projeto Ausncia da cultura de boas prticas de programao Ausncia de padres
Qualidade de Software O que fazer? Minimizar nmero de defeitos Criar mecanismos para controlar o desenvolvimento Utilizao de Metodologias, Paradigmas e Padres Preservar prazos e custos Garantia Verses futuras
Qualidade de Software A qualidade inserida no software atravs: - da capacitao de profissionais - de investimentos em tecnologia - de disciplina gerencial - da utilizao de padres A realizao da fase de teste considerada por vrias empresas como garantia de qualidade. Somente o produto final testado. Necessidade de teste com processos.
Qualidade de Software Os processos devem ser realizados de forma a permitir boa visibilidade em todas as suas fases. Deming sugere a utilizao de grficos. Padres de software fornecem critrios especficos para se medir a qualidade e avaliar a aceitabilidade dos produtos de software. Baixa qualidade = erros, problemas de performance, no atendimento aos requisitos, sem manuteno. Somente o uso de padres no garante qualidade, mas um processo eficiente e um produto sem erros.
Qualidade de Software Cada atividade deve observar caractersticas de qualidade.
Padres Medidas de Medidas de Qualidade Qualidade
Requisitos
Anlise e Projeto
Implementao
Teste
Implantao
Controle do Produto (Software) e do Processo (Desenvolvimento). Controlar o produto atravs de mtricas de qualidade: manutenibilidade, confiabilidade, flexibilidade, correo, testabilidade, portabilidade, reusabilidade, eficincia, integridade e interoperabilidade. Controlar o processo significa medir e avaliar o desempenho da qualidade nas fases de desenvolvimento do software. Como? Analisando a situao atual do processo. Experimentando e avaliando novas tecnologias. Implantando atravs de uma melhoria comprovada.
CMM (Capability Maturity Model)

Modelo de maturidade da capacidade ou da capabilidade um norma Internacional da ISO (International Organization for Standardization) Desenvolvido pelo SEI (Software Engineering Institute) Baseia-se no conceito de maturidade dos processos de software. Os cinco nveis de maturidade permitem, em uma escala crescente, controle e visibilidade sobre os processos e resultados.
Esses cinco nveis apresentam uma escala mensurvel de maturidade.

O CMM prope-se a:
a) Ser baseado em experincia prtica de empresas de software, b) Refletir o melhor do estado da prtica, c) Atender as necessidades dos que realizam a melhoria dos processos e avalio. d) Ser documentado.

Caractersticas de uma empresa imatura: - O trabalho feito em regime de emergncia; - Prazos e custos no so cumpridos; - sem planejamento com bases em estimativas realistas; - no h uma boa definio de processos; - eventuais iniciativas de melhoria no avanam; - expirao de prazos = reduo de qualidade e problemas de funcionalidade; - o sucesso do projeto depende de poucos especialistas; - implantao de novas tecnologias sem estudo e testes.

O CMM desenvolvido a partir do conceito de processos. Um processo executa uma sequncia de atividades que transformam determinadas entradas em determinadas sadas. Um processo integra pessoas, ferramentas e mtodos para executar uma sequncia de atividades com um objetivo prdefinido. Em CMM um processo s assim chamado se puder ser executado. Enquanto no puder ser executado apenas uma descrio. A qualidade de um produto medida pela qualidade dos processos utilizados na sua produo e manuteno.

Nos pilares que sustentam o processo (pessoas, ferramentas e mtodos) todos os componentes tem grande importncia. O CMM baseado em Princpios do TQM (Total Quality Model) Muitas empresas colocam grande nfase em treinamentos (pessoas) e ferramentas. Esta abordagem satura-se rapidamente se nada for feito visando a aplicao de mtodos. Na medida em que a maturidade dos processos evolui, os processos passam a ser melhor definidos e mais institucionalizados. Ocorre uma maior equilbrio entre os componentes (pessoas, ferramentas e mtodos).

A maturidade de um processo de desenvolvimento de software analisada pela medida em que ele pode ser: definido, gerenciado, medido, controlado e executado de maneira eficaz. O processo de maturidade surgiu atravs de estudos sobre os modelos de Shewhart (PDCA), Deming e Juran aplicados ao setor do desenvolvimento do software.

Nveis de maturidade: Inicial(1), Repetvel(2) Definido(3) Gerenciado (4) Otimizado(5)

Nveis de Maturidade: Nvel 1 (Inicial): A organizao no tem responsabilidades dos seus processos; Assume compromissos que no consegue cumprir (em prazos e custos); Resulta em uma srie de crises; Abandona qualquer tentativa de manter procedimentos disciplinados; Concentra-se no que considerado fundamental: codificar As chances de sucesso dependem de habilidades pessoais de alguns ou de um especialista; Desenvolvimento sob presso; O ciclo de desenvolvimento abreviado.

Nveis de Maturidade: Nvel 1 (Inicial): No nvel 1 a qualidade depende exclusivamente da capacidade de algumas pessoas e no da equipe envolvida no processo como um todo. No existem boas prticas no desenvolvimento do software. Cronogramas, funcionalidades, custos e consequentemente a qualidade imprevisvel. Chamado de catico.

Nveis de Maturidade: Nvel 2 (Repetvel): As polticas e procedimentos essenciais para gerenciar o desenvolvimento do software esto definidos e so obedecidos. O planejamento de novos projetos baseado na experincia de projetos anteriores. Aprendizado com projetos semelhantes, maneira formalizada e no intuitiva. Os projetos usam processos que so definidos, documentados, usados, disseminados, medidos, fiscalizados e com rotinas de melhoria.

Nveis de Maturidade: Nvel 2 (Repetvel): Os compromissos so assumidos com bases realistas na experincia e nos documentos; O desenvolvimento acompanhado e os planos so revisados de maneira regular quantos aos: Prazos, custos, estimativas e funcionalidades. Existem mecanismos formais para a correo de desvios. A anlise de requisitos formal permite um controle de relacionamento com o cliente (necessidades e expectativas). O relacionamento com fornecedores subcontratados controlado e gerenciado.

Nveis de Maturidade: Nvel 2 (Repetvel): A definio e o estabelecimento dos processos, no nvel 2, so realizados por projeto. Existe uma clara visibilidade e controle de todos os aspectos gerenciais do desenvolvimento do software. Os processos podem ser repetidos com resultados previsveis. No existe utilizao de Padres.

Nveis de Maturidade: Nvel 3 (Definido): Os processos utilizados so estabelecidos e padronizados em toda a organizao. Os processos tcnicos da Engenharia de Software so considerados ao lado dos processo gerenciais. Na passagem do nvel 2 para o nvel 3, a padronizao realizada. Escolha das melhores prticas existentes na organizao. Criao de um grupo responsvel pelos processos da organizao. Treinamento do pessoal tcnico e gerencial. Garantia do Conhecimento e de Habilidades necessrias.

Nveis de Maturidade: Nvel 3 (Definido): Apesar da padronizao, existem necessidades de adaptao dos processos para as necessidades particulares de um projeto. A adaptao deve ser feita de maneira ordenada, disciplinada e formal.

Nveis de Maturidade: Nvel 4 (Gerenciado): A organizao estabelece metas quantitativas para seus produtos e processos. Medidas de qualidade e produtividade so coletadas em todos os projetos. Estas medidas so armazenadas em uma base de dados corporativa, permitindo anlise contnua do seu desempenho. Os projetos melhoram seu controle sobre os produtos e processos. A varincia das medidas diminuda. estabelecido o controle estatstico de processos.

Nveis de Maturidade: Nvel 4 (Gerenciado): Uma organizao no nvel 4 passa a ter uma gesto feita com bases quantitativas. Nvel 5 (Em otimizao): A organizao est engajada na melhoria contnua de seus processos. Fase de otimizao (optmizing) A organizao capaz de identificar seus pontos fracos. Aes so realizadas de forma preventiva. Problemas so evitados.

Nveis de Maturidade: Nvel 5 (Em otimizao): Mudanas (tecnolgicas e de processos) so realizadas a partir de processos de anlises de custo/benefcios. Fundamentao em dados quantitativos iniciados no nvel 4. A anlise de defeitos permite ao eficaz de ajustes diretamente nas suas causas. Reduo considervel de retrabalho e desperdcio. Melhoria considervel de produtividade. Melhorias em processos e tecnologias so planejadas e executadas como parte das atividades de rotina.

Visibilidade do Processo de Software: Um dos objetivos principais do CMM proporcionar visibilidade apropriada do processo de desenvolvimento: NVEL 1(Inicial): O projeto comporta-se como uma caixapreta e os envolvidos tm grande dificuldade em observar e controlar pontos internos dos processos. O produto gerado no final do desenvolvimento, mas com prazos e custos fora de controle.

Visibilidade do Processo de Software: NVEL 2(Repetvel) : Existem fases que permitem o controle de custos e prazos nos produtos intermedirios. No h visibilidade sobre os pontos internos, existem pontos de verificao intermediria (checkpoints) na sada de cada fase. Permite a tomada de aes corretivas e um razovel controle sobre os resultados finais.

Visibilidade do Processo de Software: NVEL 3(Definido) : Os processos de Engenharia de Software comeam a ser considerados e cada fase passa a ter certa visibilidade em funo da definio dos processos tcnicos.

Visibilidade do Processo de Software: NVEL 4(Gerenciado) : No nvel gerenciado, quando a maioria das prticas de medida institucionalizada, existem vrios pontos de verificao, internos e externos a cada fase, durante as quais so possveis a monitorao e o controle.

Visibilidade do Processo de Software: NVEL 5(Em otimizao) : Neste nvel possvel a evoluo de processos e de tecnologias de maneira controlada. Fases completas podem ser substitudas por outras com impacto controlado (melhorias).

Visibilidade do Processo de Software: Evoluo dos Processos Nvel de: Pessoas: Nvel 1: o sucesso depende da habilidade de um ou de alguns indivduos. Regime constante de emergncia. O relacionamento entre grupos descoordenado e muitas vezes conflitante. Nvel 2: O sucesso ainda depende de indivduos, mas passam a contar com o apoio gerencial. Os compromissos so compreendidos e gerenciados. Nvel 3: Os grupos de projetos trabalham de maneira coordenada. O treinamento planejado de acordo com as necessidades de cada papel e aplicado convenientemente.

Visibilidade do Processo de Software: Evoluo dos Processos Nvel de: Pessoas: Nvel 4: Existe um forte sentido de trabalho em equipe. Nvel 5: Alm do trabalho em equipe, todos esto engajados em atividades de melhoria contnua. Tecnologia: Nvel 1: A introduo de novas tecnologias arriscado. Nvel 2: Atividades bem definidas facilitam a introduo de novas tecnologias. Nvel 3: Novas tecnologias so avaliadas qualitativamente.

Visibilidade do Processo de Software: Evoluo dos Processos Nvel de: Tecnologia: Nvel 4: Novas tecnologias so avaliadas quantitativamente. Nvel 5: Novas tecnologias so planejadas e introduzidas com total controle. Medidas: Nvel 1: A coleta de dados feita de maneira ad hoc. Nvel 2: A coleta de dados de atividades de planejamento e acompanhamento feita de maneira sistemtica. Nvel 3: Todos os processos definidos tm coleta sistemtica de dados.

Visibilidade do Processo de Software: Evoluo dos Processos Nvel de: Medidas: Nvel 4: A definio e coleta de dados so padronizadas na organizao. Os dados so usados para entender os processos de maneira quantitativa e estabiliz-los. Nvel 5: Os dados coletados so usados para avaliar e selecionar possibilidades de melhoria de processos.

Os componentes do Modelo CMM e os 5 nveis Cada nvel de maturidade indica uma capacidade de processo e composto por vrias reas-chave de processo KPA. Cada KPA permite alcanar um conjunto de metas ou objetivos. A satisfao destes objetivos permite dizer se a organizao atingiu um determinado nvel de maturidade. Cada KPA dividida em um conjunto de prticas que foram classificadas de acordo com caractersticas comuns.

Os componentes do Modelo CMM e os 5 nveis
indica Capacidade atinge Metas trata Implementa o Nvel de Maturidade contm KPA organizado em Caracterstica comum contm Prtica base
descreve
Atividade ou Infraestrutura

Os componentes do Modelo CMM e os 5 nveis Caracterstica comum: a) comprometimento: as prticas agrupadas nessa classe referem-se s aes da alta gerncia da organizao. b) habilidades: as prticas agrupadas nessa classe referem-se capacitao de pessoas e disponibilizao de recursos humanos e materiais. c) Atividades: tarefas necessrias para atingir os objetivos e metas da KPA. d) Medidas: feitas para monitorar quantitativamente a situao do processo e usadas para controle e melhorias. e) verificao: atividades que permitem comparar os estabelecido nos procedimentos com a prtica realizada.

Os componentes do Modelo CMM e os 5 nveis As KPAs: Em otimizao 1. Process Change Management; 2. Technology Change Management; 3. Defect Prevention. Gerenciado: 1. Software Quality Management; 2. Quantitive Process; 3. Management.

Os componentes do Modelo CMM e os 5 nveis As KPAs: Definido: 1. Peer Reviews; 2. Intergroup Coordination; 3. Software Product Engineering; 4. Integrated Software Management; 5. Training Program; 6. Organization Process Definition; 7. Organization Process Focus.

Os componentes do Modelo CMM e os 5 nveis As KPAs: Repetvel: 1.Software Configuration Management; 2. Software Quality Assurance; 3. Software Subcontract Management; 4. Software Project Tacking and Oversight 5. Software Project Planning 6. Requirements Management.

Aspectos gerenciais para implantao do CMM Gerentes: CMM menciona vrios tipos de gerentes. Gerente de projeto, Gerente Senior, Gerente de Infra-estrutura. Lder: responsvel por uma tarefa no ciclo do desenvolvimento. Desenvolvedores: algumas vezes designados no modelo como grupo de engenharia de software. Organizao: contexto da aplicao de prticas. Diviso, departamento.

Aspectos gerenciais para implantao do CMM Grupo de Engenharia de Software: pessoas com a responsabilidade de conduzir atividades de desenvolvimento e manuteno de software. Grupo de Processos de Engenharia de Software SEPG: grupo responsvel pela definio e manuteno de processos. Grupo de Teste: reponsvel pela implementao de polticas de teste no produto de software. Grupo de Qualidade de Software SQA: garantia de que processos e prticas so bem obedecidas. Grupo de Configurao de Software: grupo responsvel pelas atividades de gesto de configurao de software.

Interpretao dos Requisitos em CMM Avaliao da Organizao Interpretao das necessidades da empresa Ajustar os requisitos realidade da empresa Entender o modelo de negcio da empresa Dimensionar a complexidade Aplicar bom senso Estabelecer metas e objetivos Utilizar mtodos Melhorar os processos de acordo com a necessidade Recomendar melhorias No questionar apenas o expert no assunto

Interpretao dos Requisitos em CMM Estabelecer uma linha de base para desenvolvimento e para gerncia. Os planos de desenvolvimento e as atividades devem ser mantidos em consistncia com os requisitos do software. Estabelecer dilogo com o cliente.

Melhoria de Processos e Avaliaes segundo CMM Necessidade de Identificao do estado atual da Empresa Estabelecer objetivos Traar um plano de ao Estabelecer modelos de avaliao Modelos de Avaliao do CMM: Modelo IDEAL (Initiating, Diagnosing, Establishing, Acting and Leveraging) baseado no PDCA Software Process Assessment SPA (avaliao de processo de software) Software Capability Evaluation (avaliao da capacidade dos processos de software)

Melhoria de Processos e Avaliaes segundo CMM Etapas do processo de implantao de melhorias: 1) definio dos objetivos 2) comprometimento dos gerentes 3) formao de equipe de avaliao 4) aplicao de um questionrio de avaliao de maturidade 5) anlise de documentos e entrevistas 6) anlise de resultados 7) apresentao dos resultados

Melhoria de Processos e Avaliaes segundo CMM medida que as respostas so processadas e analisadas elas evoluem da seguinte maneira: A) notas: respostas iniciais classificadas como ponto forte ou fraco; B) observaes: confirmao correo da informao por pelo menos duas fontes independentes; C) validade: construda a partir da verificao da preciso da observao e de sua consistncia. D) finding: concluso juzo sobre uma prtica bsica.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Requirements Management 4. Software Project Tacking and Oversight 5. Software Project Planning O objetivo da KPA RM esta6. Requirements Management. belecer mecanismos para que o produto de software reflita a expectativa do cliente. Os requisitos so controlados para estabelecer uma baseline tanto para desenvolvimento quanto para atividades de gerncia. Atividade Externa. Os planos de desenvolvimento, os produtos e todas as atividades so mantidos em consistncia com os requisitos do software. Atividade Interna.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Requirements Management 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de base 6. Requirements Management. Commitment to perform (Comprometimento Organizacional) O projeto segue uma poltica escrita e institucionalizada na organizao para gerenciar os requisitos de software. Requisitos documentados e verificados Implantao de medidas para manter os produtos internos consistentes com as mudanas de requisitos.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Requirements Management 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de base 6. Requirements Management. Ability to perform (Habilidades necessrias) Deve ser estabelecida claramente a responsabilidade para analisar os requisitos do sistema e aloc-los para o SW, HW e outros componentes. Devem ser alocados recursos financeiros, humanos e materiais necessrios para a gesto dos requisitos. Experincia e conhecimento.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Requirements Management 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de base 6. Requirements Management. Activities Performed (Atividades e Tarefas) Os requisitos so analisados e revistos pelos desenvolvedores antes da elaborao do projeto. Requisitos- clareza, consistncia, representao da realidade, testveis. Requisitos base para o projeto e desenvolvimento. Anlise de impacto de mudanas. Alocao de recursos. Estimativa de Amplitude e Riscos.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Requirements Management 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de base 6. Requirements Management. Measurement and Analysis (Medidas e Anlises) As atividades de gesto de requisitos devem ser medidas. Ex. de Medidas: Situao de cada Requisito. Frequncia de Mudanas. Nmero de Requisitos Recebidos. Requisitos mudados, aceitos, rejeitados e em implementao.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Requirements Management 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de base 6. Requirements Management. Verifying Implementation (Verificao) As atividades de gesto de requisitos so analisadas periodicamente pela alta gerncia. As atividades de gesto de requisitos so analisadas pelo gerente de projeto, periodicamente e em eventos predefinidos. Produo de relatrios a partir de anlises e auditoria das atividades de gesto de requisitos e dos produtos associados. Negociao com demais grupos afetados.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Software Project Planning - SPP 4. Software Project Tacking and Oversight O objetivo da KPA SPP estabele- 5. Software Project Planning 6. Requirements Management. cer planos efetivos para servirem como base para as atividades de desenvolvimento de software e de gerncia. As estimativas de software so documentadas para uso no planejamento e acompanhamento do projeto. O projeto de software tem suas atividades e compromissos, associados e planejados. Os grupos e indivduos que tenham alguma relao com o desenvolvimento do software conhecem os compromissos assumidos e concordam com eles.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Software Project Planning - SPP 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de Base 6. Requirements Management. Commitment to Perform (Comprometimento Organizacional) Gerente de projeto exerce as funes de negociao de compromissos e elaborao do plano de desenvolvimento do SW. O projeto segue uma poltica escrita e institucionalizada na Organizao. Como os requisitos so usados na elaborao do plano.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Software Project Planning - SPP 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de Base 6. Requirements Management. Ability to Perform (Habilidades Necessrias) Existe um plano de trabalho, documentado e aprovado a ser usado como base para o desenvolvimento. Atribuio de responsabilidades no desenvolvimento. Devem ser alocados os recursos financeiros, humanos e materiais necessrios. Experincia e Conhecimento. Produo de estimativas.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Software Project Planning - SPP 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de Base 6. Requirements Management. Activities Performed (Atividades e Tarefas) O gerente apresenta a proposta de desenvolvimento equipe. SW deve ser planejado em paralelo HW e componentes. Contribuio de desenvolvedores com outros grupos. Ciclo de Vida do Projeto Compromissos com indivduos externos sob a superviso da gerncia.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Software Project Planning - SPP 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de Base 6. Requirements Management. Activities Performed (cont...) (Atividades e Tarefas) Gerenciamento do tempo. Elaborao de padres, normas e prticas. Critrios de relacionamento. Esquema de reviso. Plano de desenvolvimento com: objetivos, ciclo de vida, normas, prticas aplicveis, identificao dos produtos de trabalho, estimativas de esforo, custo, recursos e cronograma.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Software Project Planning - SPP 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de Base 6. Requirements Management. Activities Performed (cont...) (Atividades e Tarefas) Estimativa de crescimento. Granularidade da decomposio. Registro de hipteses. Produtividade. Basear-se em experincias acumuladas e documentadas.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Software Project Planning - SPP 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de Base 6. Requirements Management. Measurement and Analysis (Medidas e Anlises) Acompanhamento de prazos de planejamento. Superviso. Planejamento: trabalho j executado e remanescente.

O contexto de Aplicao do CMM KPAs 1.Software Configuration Management; NIVEL 2: Repetvel 2. Software Quality Assurance; 3. Software Subcontract Management; Software Project Planning - SPP 4. Software Project Tacking and Oversight 5. Software Project Planning Prticas de Base 6. Requirements Management. Verifying Implementation (Verificao) As atividades de planejamento so verificas periodicamente. Sob o controle da gerncia. Realizao de reunies pr-estabelecidas. Produo de Relatrios. Auditoria.

O contexto de Aplicao do CMM KPAs 1. Peer Reviews; NIVEL 3: Definido 2. Intergroup Coordination; 3. Software Product Engineering; Organization Process Focus 4. Integrated Software Management; 5. Training Program; Tem por objetivo estabelecer as 6. Organization Process Definition; responsabilidades organizacionais 7. Organization Process Focus. para as atividades de processo de software que podem melhorar a capacidade de processo da organizao. Trata do estabelecimento da infra-estrutura e dos comprometimentos organizacionais.

O contexto de Aplicao do CMM KPAs 1. Peer Reviews; NIVEL 3: Definido 2. Intergroup Coordination; 3. Software Product Engineering; Organization Process Definition 4. Integrated Software Management;
5. Training Program; 6. Organization Process Definition; 7. Organization Process Focus.
Tem por objetivo desenvolver e manter um conjunto utilizvel de processos de software. Os processos tratam das questes da engenharia de software propriamente dita, ao contrio das prticas gerenciais do nvel 2. Existe prticas que definem os critrios para adaptao de processos para um domnio especfico. Os padres podem ser flexibilizados, desde que os procedimentos sejam seguidos.

O contexto de Aplicao do CMM KPAs 1. Peer Reviews; NIVEL 3: Definido 2. Intergroup Coordination; 3. Software Product Engineering; Training Program 4. Integrated Software Management;
Tem por objetivo desenvolver a capacitao necessria para todo o pessoal envolvido no desenvolvimento. Os treinamento saem do mbito da gerncia de projetos e passam s atividades da engenharia de software.

O contexto de Aplicao do CMM KPAs 1. Peer Reviews; NIVEL 3: Definido 2. Intergroup Coordination; Software Integrated Software Management 3. IntegratedProduct Engineering; 4. Software Management;
Tem por objetivo integrar as atividades de gesto e de engenharia de software em um processo de software integrado. considerado uma evoluo do SPP do nvel 2. Alm da identificao de problemas e correo, esta KPA fornece uma ateno preveno de problemas.

O contexto de Aplicao do CMM KPAs 1. Peer Reviews; NIVEL 3: Definido 2. Intergroup Coordination; 3. Software Product Engineering; Software Product Engineering 4. Integrated Software Management;
Tem por objetivo permitir a execuo de um processo de engenharia consistente e bem definido que integre todas as atividades de Engenharia de Software visando a gerao de produtos de software de maneira eficaz e eficiente.

O contexto de Aplicao do CMM KPAs 1. Peer Reviews; NIVEL 3: Definido 2. Intergroup Coordination; 3. Software Product Engineering; Intergroup Coordination 4. Integrated Software Management;
Tem por objetivo estabelecer meios para que o grupo de desenvolvedores e outros grupos de engenharia de software atuem de maneira cooperativa visando a satisfao das necessidades dos clientes.

O contexto de Aplicao do CMM KPAs 1. Peer Reviews; NIVEL 3: Definido 2. Intergroup Coordination; 3. Software Product Engineering; Peer Reviews 4. Integrated Software Management;
Tem por objetivo remover defeitos dos produtos de trabalho de software de maneira precoce e eficiente. Um importante benefcio desta KPA a viso que se ganha dos produtos de trabalho e de como os defeitos podem ser prevenidos.

O contexto de Aplicao do CMM KPAs 1. Quantitative Process Management NIVEL 4: Gerenciado 2. Software Quality Management Quantitative Process Management
Tem por objetivo controlar os resultados dos processos relevantes de maneira quantitativa.

O contexto de Aplicao do CMM KPAs 1. Quantitative Process Management NIVEL 4: Gerenciado 2. Software Quality Management Software Quality Management
Tem por objetivo desenvolver uma percepo quantitativa da qualidade dos produtos de software e alcanar metas especficas da qualidade.

O contexto de Aplicao do CMM KPAs 1. Defect Prevention NIVEL 5: Em otimizao 2. Technology change management 3. Process change management Defect Prevention
Tem por objetivo a identificao das causas dos defeitos e a tomada de medidas preventivas para que eles no voltem a ocorrer.

O contexto de Aplicao do CMM KPAs 1. Defect Prevention NIVEL 5: Em otimizao 2. Technology change management 3. Process change management Technology change management
Tem por objetivo identificas novas tecnologias (ferramentas, mtodos e processos) e implant-las na organizao de uma maneira controlada e com efeitos previsveis.

O contexto de Aplicao do CMM KPAs 1. Defect Prevention NIVEL 5: Em otimizao 2. Technology change management 3. Process change management Process change management
Tem por objetivo a melhoria contnua de processos usados na organizao, visando aumentar a produtividade e a qualidade dos produtos e reduzir o tempo do desenvolvimento.
QUALIDADE DE PRODUTO E A ISO/IEC 9126

Introduo Antes: A qualidade do software estava centrada no produto final. Controle de qualidade = resoluo de bugs do sistema Hoje: Fortalecimento do foco no cliente. Aumento dos recursos de avaliao de qualidade do produto, alm da simples correo de funcionamento. Exs.: Disponibilidade de Interface grfica amigvel, suporte ps-venda. ISO/IEC 9126 avaliao da qualidade do software

Introduo ISO/IEC 9126 conjunto de atributos que tem impacto na capacidade de software de manter seu nvel de desempenho dentro de condies estabelecidas por um dado perodo de tempo. Verso brasileira- NBR ISO 13596 Este modelo de qualidade fornece maior visibilidade ao processo de avaliao do produto de software, desde a sequncia de atividades empregadas at as mtricas para pontuao.

Caractersticas de Qualidade da ISO/IEC 9126 Funcionalidade: conjunto de funes especficas e suas propriedades. As funes devem satisfazer as necessidades implcitas e explcitas do usurio. caracterizado por O QUE o software faz para satisfazer estas necessidades. Confiabilidade: medida da capacidade do software de manter seu nvel de desempenho dentro de condies estabelecidas por um dado perodo de tempo. Usabilidade: medida dos esforo necessrio para o uso do software por um usurio de perfil determinado. Eficincia: relao entre o nvel de desempenho do software e a quantidade de recursos utilizada, sob condies de uso prestabelecidas.

Caractersticas de Qualidade da ISO/IEC 9126 Manutenibilidade: medida do esforo necessrio para fazer alteraes no produto do software. Portabilidade: medida da facilidade do produto de software ser transferido para outro ambiente operacional.

As Sub-caractersticas da Qualidade Funcionalidade: - Adequao: presena das funes especificadas. -Preciso: o produto gera resultados precisos ou dentro do esperado. - Interoperabilidade: capacidade de interagir e interoperar com outros sistemas, de acordo com o especificado. - Conformidade : observncia a padres, convenes ou regras. Segurana de Acesso: capacidade de impedir o acesso no autorizado.

As Sub-caractersticas da Qualidade Confiabilidade: - Maturidade: Indicao de baixa frequncia de falhas. - Tolerncia a Falhas: capacidade do produto para manter determinados nveis de desempenho mesmo na presena de problemas. Recuperabilidade: capacidade do produto para reestabelecer o nvel de desempenho desejado e recuperar dados em caso de ocorrncia de falhas.

As Sub-caractersticas da Qualidade Usabilidade: - Inteligibilidade: medida da facilidade do usurio para reconhecer a lgica de funcionamento do produto e sua aplicao. - Apreensibilidade: medida da facilidade encontrada pelo usurio para aprender a utilizar o produto. - Operacionalidade: medida da facilidade para operar o produto.

As Sub-caractersticas da Qualidade Eficincia: - Comportamento/tempo: medida do tempo de resposta e de processamento ao executar funes especficas. - Comportamento/recursos: medida da quantidade de recursos necessrios (CPU, disco, memria) e a durao do ser uso a executar as funes especificadas.

As Sub-caractersticas da Qualidade Manutenibilidade: - Analisabilidade: medida do esforo necessrio para diagnosticar deficincias ou causas de falhas, ou localizar as partes a serem modificadas para corrigir problemas. - Modificabilidade: medida do esforo necessrio para realizar alteraes, remover falhas ou para adequar o produto a eventuais mudanas de ambiente operacional. - Estabilidade: medida do risco de efeitos inesperados proveniente de modificaes. - Testabilidade: medida do esforo necessrio para testar o software alterado.

As Sub-caractersticas da Qualidade Portabilidade: - Adaptabilidade: medida da facilidade de se adaptar o produto para funcionar em outros ambientes operacionais diferentes do originalmente especificado. Facilidade de instalao: medida do esforo necessrio para se instalar o produto. Capacidade para co-existir: medida do nvel de conformidade do produto com padres referentes a portabilidade. Facilidade para substituir: medida do esforo necessrio para usar o produto em substituio a outro produto, previamente especificado.

As vises de qualidade (usurio x desenvolvedor x gerente) Usurio medidas externas de qualidade: As funes especificadas esto disponveis? Qual a confiabilidade? fcil de operar? portvel?

As vises de qualidade (usurio x desenvolvedor x gerente) Desenvolvedor medidas internas: Atende aos requisitos? eficaz? Qual o tempo de resposta?

As vises de qualidade (usurio x desenvolvedor x gerente) Gerente objetivos do negcio: Cronograma? Previses de custo? Qualidade?

Procedimentos de Avaliao Trs estgios: 1. Definio dos Requisitos de qualidade: Dependente do domnio da aplicao. 2. Preparao da Avaliao: Seleo das mtricas de qualidade; Definio dos nveis de pontuao; Definio dos critrios de avaliao. 3. Procedimento de Avaliao: Medida: aplicao das mtricas; Pontuao: determinao de valores; Avaliao: determinao do resultado em termos de aceitao ou no do produto em relao qualidade.
SPICE ISO/IEC 15504

Introduo SPICE Software Process Improvement and Capability Determination Mais recente proposta da ISO Padro Internacional Verso mais genrica, compatvel com outros modelos de qualidade existentes Organizao estruturada de Processos usado para a realizao de avaliaes com dois objetivos: a melhoria dos processos e a determinao da capacidade dos processos de uma organizao.
SPICE ISO/IEC 15504

Objetivos Se o objetivo for a melhoria de processos, a organizao realiza a avaliao gerando um perfil de processos que ser usado para elaborao de um plano de ao de melhorias. A organizao deve definir os objetivos e contextos para a avaliao, escolher o modelos e o mtodo para a avaliao e definir os objetivos da melhoria. Se o objetivo for a determinao da capacidade dos processos, a empresa tem de avaliar um fornecedor em potencial, obtendo seu perfil de capacidade. Para isto, ela deve definir os objetivos e contextos da avaliao, os modelos e mtodos de avaliao e os requisitos esperados. O perfil de capacidade permite ao contratante estimar o risco associado contratao daquele fornecedor em potencial .
SPICE ISO/IEC 15504

Partes O projeto SPICE foi dividido em 9 partes. Dentre estas nove partes, apenas as partes 2 e 3 so normativas, sendo as demais informativas: Parte 1: Conceitos e Guia Introdutrio Parte 2 (normativa): Modelo de Referncia para Processos e Capacidade Parte 3 (normativa): Realizao de Avaliao Parte 4: Guia para a realizao de uma avaliao Parte 5: Modelo para avaliao e guia de indicadores Parte 6: Guia para a qualificao de avaliadores Parte 7: Guia para a melhoria de processos Parte 8: Guia para a determinao de capacidade de fornecedor Parte 9: Vocabulrio

Qualidade de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Qualidade de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Qualidade de software

Prof. PhD. Samyr Vale

CMM (Capability Maturity Model)

Esses cinco nveis apresentam uma escala mensurvel de maturidade.

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)

CMM (Capability Maturity Model)