ads2018engenhariadesoftware2materialdeestudo

Engenharia de Software I

•

UNIP

Tiago Vieira da Silva

04/04/2018

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Aula 07 - ES2.pdf
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 07

CMMI: MODELO DE MATURIDADE EM CAPACITAÇÃO – INTEGRAÇÃO

 O CMMI surgiu durante a década de 80 como um modelo para avaliação de risco na
contratação de empresas de software pelo Dep. Dos EUA, que desejava ser capaz de avaliar
os processos de desenvolvimento utilizados pelas empresas que concorriam em licitações
como indicação da previsibilidade da qualidade, custos e prazos nos projetos contratados.
 Um modelo tem como objetivo estabelecer - com base em estudos, históricos e
conhecimento operacional - um conjunto de "melhores práticas" que devem ser utilizadas
para um fim específico.
 O CMMI foi construído considerando três dimensões principais: pessoas, ferramentas e
procedimentos. O processo serve para unir essas dimensões.
 O CMMI possui duas representações: "contínua" ou "por estágios". Estas representações
permitem à organização utilizar diferentes caminhos para a melhoria de acordo com seu
interesse.
 Possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de
negócio da empresa. É caracterizado por: Níveis de Capacidade (Capability Levels):

 Representação Contínua
 Nível 0: Incompleto (Ad-hoc)
 Nível 1: Executado
 Nível 2: Gerenciado / Gerido
 Nível 3: Definido
 Nível 4: Gerenciado quantitativamente --- REMOVIDO DA v.1.3
 Nível 5: Em otimização --- REMOVIDO DA v.1.3

Representação Contínua
Esta representação a capacidade é medida por processos separadamente.
 No nível 1: o processo é executado de modo a completar o trabalho necessário para a
execução de um processo.
 No nível 2: é sobre planejar a execução e confrontar o executado contra o que foi
planejado.
 No nível 3: o processo é construído sobre as diretrizes do processo existente, e é
mantido uma descrição do processo.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 07

REPRESENTAÇÃO POR ESTÁGIOS
Disponibiliza uma sequencia pré-determinada para melhoria baseada em estágios que não
deve ser desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por
Níveis de Maturidade (Maturity Levels):
 Nível 1: Inicial (Ad-hoc)
 Nível 2: Gerenciado / Gerido
 Nível 3: Definido
 Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
 Nível 5: Em otimização

Nesta representação a maturidade é medida por um conjunto de processos

 O CMMI fornece às organizações um conjunto de melhores práticas em
desenvolvimento e manutenção de produtos e serviços tecnológicos
 Quando uma organização atinge um nível de maturidade, considera-se que tem
mecanismos que garantem a repetição sucessiva de bons resultados futuros
relacionados principalmente à qualidade, custos e prazos.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 07

Objetivo:
Além da integração dos modelos e redução dos custos com melhorias de processo, os
seguintes objetivos também fazem parte do projeto CMMI:
• Aumento do foco das atividades
• Integração dos processos existentes
• Eliminar inconsistências
• Reduzir duplicações
• Fornecer terminologia comum
• Assegurar consistência com a norma ISO 15504
• Flexibilidade e extensão para outras disciplinas

Conceito básicos
 Área de Processo (Process Area – PA): práticas relacionadas em uma área que,
quando executadas de forma coletiva, satisfazem um conjunto de metas consideradas
importantes para trazer uma melhoria nessa área.
 Metas Específicas: se aplicam a uma PA e tratam de características que descrevem o
que deve ser implementado para satisfazer essa PA. São utilizadas nas avaliações para
auxiliar a determinar se a PA está sendo satisfeita.
 Práticas Específicas: atividades que são consideradas importantes na satisfação de
uma meta específica associada.
 Metas Genéricas: aparecem em diversas PAs.
 Práticas genéricas: oferecem uma institucionalização que assegura que os processos
associados com a PA serão eficientes, repetíveis e duráveis.
 Produtos de trabalho típicos: exemplos de saídas de uma prática específica ou
genérica.
 Sub-práticas: descrições detalhadas que fornecem um direcionamento para a
interpretação de práticas específicas ou genéricas.

PAs são organizadas em quatro categorias de processo: Gerenciamento de Processos,
Gerenciamento de Projetos, Engenharia e Suporte

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 07

1- Gerenciamento de Processos
Atividades relativas à definição, planejamento, distribuição de recursos, aplicação,
implementação, monitoramento, controle, avaliação, medição e melhoria de processos.
Envolve as seguintes PAs:
• Foco no Processo Organizacional (básica)
• Definição do Processo Organizacional (básica)
• Treinamento Organizacional (básica)
• Desempenho do Processo Organizacional (avançada)
• Inovação e Desenvolvimento Organizacional (avançada)

2- Gerenciamento de Projetos
Atividades de gerência de projetos relacionadas ao planejamento, monitoramento e controle
do projeto.
• Planejamento de Projetos (básica)
• Monitoramento e Controle de Projetos (básica)
• Gerência de Acordos com Fornecedores (básica)
• Gerência Integrada de Projetos (avançada)
• Gerência de Riscos (avançada)
• Integração de Equipes (avançada)
• Gerência Quantitativa de Projetos (avançada)

3- Engenharia:
Atividades de desenvolvimento e manutenção que são compartilhadas entre as disciplinas de
engenharia (por exemplo, engenharia de sistemas e engenharia de software).
• Gerência de Requisitos
• Desenvolvimento de Requisitos
• Solução Técnica
• Integração de Produtos
• Verificação
• Validação

4- Suporte
Atividades que apóiam o desenvolvimento e a manutenção de produtos.
As PAs de Suporte tratam os processos que são utilizados no contexto da execução de outros
processos, a saber:
• Gerência de Configuração (básica)
• Garantia da Qualidade do Processo e do Produto (básica)
• Medição e Análise (básica)
• Ambiente Organizacional para Integração (avançada)
• Análise de Decisões e Resoluções (avançada)
• Análise de Causas e Resoluções (avançada)

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 07

Representações Por Estágios: Vantagens

• Fornece uma rota de implementação por meio de:
– grupos de área de processo
– implementação em seqüência
– cada nível funciona como a fundação para o próximo
• Estrutura familiar para aqueles que estão migrando do SW-CMM.
• Habilidade de gerenciar processos ao longo da organização.
• Em uma avaliação, atribui um nível de maturidade em que a organização se encontra,
permitindo, assim, comparar organizações de forma direta.

Representação por Estágio: PAs do Nível 2
• Gerência de Requisitos
• Planejamento de Projeto
• Monitoração e Controle de Projeto
• Garantia da Qualidade do Processo e do Produto
• Gerência de Acordo com Fornecedores
• Gerência de Configuração
• Medição e Análise

Gerência de Requisitos: gerenciar os requisitos dos produtos e componentes de produtos do
projeto e identificar as inconsistências entre estes requisitos e os planos e os produtos de
trabalho do projeto. Envolve:
– Assegurar que o conjunto de requisitos acordados é gerenciado para apoiar as
necessidades de planejamento e execução do projeto.
– Documentar as mudanças nos requisitos e suas justificativas, e manter a
rastreabilidade bidirecional entre os requisitos fonte e todos os requisitos de
produtos e componentes de produtos.

Planejamento de Projetos: estabelecer e manter planos que definem as atividades do projeto.
Envolve:
– Desenvolver o plano do projeto
– Interagir com os stakeholders de forma apropriada
– Obter compromissos com o plano
– Manter o plano
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 07

Monitoramento e Controle do Projeto: oferecer um entendimento do progresso do projeto,
de maneira que as ações corretivas apropriadas possam ser tomadas quando o desempenho
do projeto se desviar significativamente do plano. Envolve:
– Monitorar atividades, comunicar status e tomar as ações corretivas.
– O progresso é basicamente determinado pela comparação dos atributos reais
de produtos de trabalho e tarefas, esforço, custo e cronograma com o que foi
planejado.

Garantia da Qualidade do Processo e do Produto: fornecer à equipe e à gerência um
entendimento objetivo dos processos e seus produtos de trabalho associados. Envolve:
– Avaliar objetivamente os processos, produtos de trabalho e serviços
executados contra as descrições de processo, padrões e procedimentos
aplicáveis
– Identificar e documentar questões de não conformidades
– Fornecer feedback para a equipe do projeto e gerentes sobre os resultados
das atividades de garantia da qualidade
– Assegurar que as questões de não conformidades sejam tratadas

Gerência de Configuração: estabelecer e manter a integridade dos produtos de trabalho,
utilizando a identificação da configuração, controle da configuração, comunicação do status da
configuração e auditorias de configurações. Envolve:
– Identificar a configuração de produtos de trabalho selecionados que compõem
as baselines em determinados momentos no tempo
– Controlar as mudanças nos itens de configuração
– Construir ou fornecer especificações para construir produtos de trabalho a
partir do sistema de gerenciamento de configurações
– Manter a integridade das baselines
– Fornecer um status preciso e os dados atuais de configurações para
desenvolvedores, usuários finais e clientes

Gerenciamento de Acordos com Fornecedores: gerenciar a aquisição de produtos de
fornecedores para os quais existe um acordo formal. Envolve:
– Determinar o tipo de aquisição que será utilizada para os produtos a serem
adquiridos
– Selecionar os fornecedores
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 07

– Estabelecer e manter acordos com fornecedores
– Executar o acordo com o fornecedor
– Aceitar a entrega dos produtos adquiridos
– Fazer a transição dos produtos adquiridos para o projeto

Medição e Análise: desenvolver e sustentar a capacidade de medições que é utilizada para
apoiar as necessidades de gerenciamento de informações. Envolve:
– Especificar os objetivos de medições e análises, de forma que estes estejam
alinhados com as necessidades e objetivos de informações identificados
– Especificar as medidas, mecanismos de coleta de dados e armazenamento,
técnicas de análises e mecanismos de comunicação e de feedback
– Implementar a coleta, armazenagem, análise e relatórios sobre os dados
– Fornecer resultados objetivos que possam ser utilizados na tomada de
decisões bem informadas e na tomada das ações corretivas apropriadas

Representação por Estágio: PAs do Nível 3

• Gerência de Projeto Integrada
• Definição do Processo Organizacional
• Foco no Processo Organizacional
• Treinamento Organizacional
• Desenvolvimento de Requisitos
• Solução Técnica
• Integração do Produto
• Verificação
• Validação
• Gerência de Riscos
• Análise de Decisão e Resolução

Representação por Estágio: PAs do Níveis 4 e 5

• Nível 4:
– Gerência Quantitativa do Projeto
– Desempenho do Processo Organizacional
• Nível 5:
– Análise de Causas e Resolução
– Inovação e Implantação na Organização / Gestão de Processo Organizacional
Aula 06 - ES2.pdf
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 06

MPS.BR - Melhoria de Processo do Software Brasileiro

• Mantido pela SOFTEX – Associação para Promoção da Excelência do Software
Brasileiro (www.softex.br)
• Ajuda as organizações a compreenderem todos os componentes presentes na
aquisição e fornecimento de software,
• Facilitar a contratação de produtos e serviços de software
• Permitir às organizações executarem projetos de forma mais eficaz.

Motivações
– No topo da pirâmide estão as empresas exportadoras de software e outras
grandes empresas que desejam atingir níveis mais altos de maturidade (CMMI
níveis 4 e 5) e serem formalmente certificadas pelo SEI - Software Engineering
Institute, em um processo de longo prazo.
– Para as empresas, isto pode levar de 4 a 10 anos e custar muito dinheiro.

– Na base encontra-se a grande massa de micro, pequenas e médias empresas
(PMEs) que desenvolvem software e que necessitam melhorar radicalmente os
seus processos, para atender normas internacionais e outros modelos (como
CMMI nível 2 e aqui, o fator custo é crítico)
– Isto pode levar de 2 a 4 anos e custar dezenas de milhares de dólares. Aqui, a
melhoria de processo está baseada na oferta de pacotes de serviços para
grupos de empresas (MNC - Modelo de Negócio Cooperado)
Objetivo
 Visa a Melhoria de Processo do Software Brasileiro em todo o país, com foco nas
Pequenas e Médias Empresas, a um custo acessível
 Modelo de qualidade de processos voltado para a realidade brasileira

Vantagens:
 Melhoria de processos mais gradual – Sete níveis mais ‘suaves’ de se alcançar
 Compatibilidade total com CMMI (DEV e SVC) e normas internacionais ISO (12207;
15504 e 20000,25000)
Desvantagem:
 A certificação MPS.BR tem foco para o mercado Brasileiro
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 06

Estrutura: 4 Componentes
 Modelo de Referência MPS para Software (MR-MPS-SW)
o Contém os requisitos que os processos das unidades organizacionais devem
atender para estar em conformidade;
o O Guia de Aquisição é um documento complementar destinado a organizações
que pretendam adquirir software e serviços
 Modelo de Referência MPS para Serviços (MR-MPS-SV)
o Contém as definições dos níveis de maturidade, processos e atributos do
processo.
o Baseado no CMMI-SVC
 Método de Avaliação (MA-MPS)
o O Guia de Avaliação contém o processo e o método de avaliação
o Os requisitos para os avaliadores líderes,
avaliadores adjuntos e Instituições
Avaliadoras (IA).
 Modelo de Negócio para Melhoria de Processo de Software e Serviços.
o Descreve regras de negócio para implementação do MRMPS-SW e MR-MPS-SV
pelas Instituições Implementadoras
o Avaliação seguindo o MA-MPS pelas Instituições Avaliadoras (IA)

Estrutura: 5 Guias
• Guia Geral de Software
• Guia Geral de Serviços
• Guia de Aquisição
• Guia de Avaliação
• Guia de Implementação

Estrutura: 7: Níveis de Maturidade
• Sete níveis de maturidade acumulativos:
• A (Em Otimização)
• B (Gerenciado Quantitativamente)
• C (Definido)
• D (Largamente Definido)
• E (Parcialmente Definido)
• F (Gerenciado)
• G (Parcialmente Gerenciado).
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 06

O atendimento aos atributos do processo (AP), pelo atendimento aos resultados esperados
dos atributos do processo (RAP), é requerido para todos os processos no nível correspondente
ao nível de maturidade.

CAPACIDADE X ATRIBUTOS DE PROCESSO

• AP 1.1 O processo é executado
– propósito descreve o objetivo geral a ser atingido durante a execução do processo.

• AP 2.1 O processo é gerenciado
– Este atributo evidencia o quanto a execução do processo é gerenciada.

• AP 2.2 Os produtos de trabalho do processo são gerenciados
– Este atributo evidencia o quanto os produtos de trabalho produzidos pelo processo são
gerenciados apropriadamente

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 06

• AP 3.1. O processo é definido
– Este atributo evidencia o quanto um processo padrão é mantido para apoiar a
implementação do processo definido.
AP 3.2 O processo está implementado
– o quanto o processo padrão é efetivamente implementado como um processo definido
para atingir seus resultados.

• AP 4.1 O processo é medido
– o quanto os resultados de medição são usados para assegurar que a execução do
processo atinge os seus objetivos.

• AP 4.2 O processo é controlado
– o quanto o processo é controlado estatisticamente para produzir um processo estável,
capaz e previsível dentro de limites estabelecidos.

AP 5.1 O processo é objeto de melhorias incrementais e inovações
– Este atributo evidencia o quanto as mudanças no processo são identificadas a partir da
análise de defeitos, problemas, causas comuns de variação do desempenho e da
investigação de enfoques inovadores para a definição e implementação do processo.

• AP 5.2 O processo é otimizado continuamente
– Este atributo evidencia o quanto as mudanças na definição, gerência e desempenho do
processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do
processo.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 06

NORMA ISO IEC 15504 – SPICE

É uma “evolução” da ISO/IEC 12207, mas possui níveis de capacidade para cada processo assim
como o CMMI.
• O modelo tem dois objetivos:
– Melhoria dos processos;
– Determinação da capacidade de processos de uma organização.

Níveis de Maturidade do SPICE
– 0 (Não executado): não possui nenhum tipo de processo, caótico;
– 1 (Informalmente executado): algumas práticas básicas, porém não
documentadas, depende de esforços individuais de seus colaboradores;
– 2 (Planejado e rastreado): apresentam uma especificação padrão e requisitos
bem delineados;
– 3 (Definido): planejamento e organização usando processos padronizados;
– 4 (Controlado): utiliza ferramentas de medição da melhoria dos seus processos
tendo o desempenho gerenciado;
– 5 (Melhoria contínua): possui uma resposta de seu desempenho. Controle e
gerenciamento, visando detecção de falhas e correções.
PROCESSO
AVALIAÇÃO
DO PROCESSO
MELHORIA DO
PROCESSO
DETERMINAÇÃO DA
CAPACIDADE
Identifica
mudanças
Identificação da
Capacidade e
riscos
O que
Leva a
O que
Leva a
É examinado
Motiva a
PROCESSO
AVALIAÇÃO
DO PROCESSO
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 06

• O SPICE possui mecanismos de pontuação em escala:
– 0% a 15% não atendido;
– 16% a 50% parcialmente atendido;
– 51% a 85% largamente atendido;
– 86% a 100% totalmente atendido.

 Focada exclusivamente em software.
 É um modelo para avaliação de processos de software.
 Possui um modelo de referência que é a base da Avaliação dos Processos.
 Dá suporte a todo o ciclo de vida do software.
 Dividida em 9 partes.
 Apenas um Relatório Técnico e não uma norma internacional.

 O modelo de referência parte 2 documenta um conjunto universal de processos da
engenharia de software que são fundamentais para uma boa engenharia de software,
cobrindo as atividades de melhores práticas.
 Ele descreve processos que uma organização pode realizar para adquirir, fornecer,
desenvolver e operar software e os atributos de processos que caracterizam a
capacidade desses processos.
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 06

 O propósito do modelo de referência é fornecer uma base comum para modelos e
métodos diferentes para avaliação de processos de software, garantindo que os
resultados de avaliação possam ser relatados num contexto comum.

1- As dimensões do modelo de referência:
É caracterizada pela declaração dos propósitos do processo, que são os objetivos essenciais e
quantificáveis de um processo.
1. 1- CUS (customer-supplier) – cliente-fornecedor: estão nessa categoria os processos
que afetam diretamente o cliente, desde a aquisição, fornecimento, instalação e assistência
técnica.
1.2 - ENG (engineering) – engenharia de software: esse grupo de processo tem o
objetivo de transformar requisitos em um produto de software e foi subdividido em sete
subprocessos ou componentes
1.3- SUP (support) – apoio: os processos de apoio ou suporte, em número de oito,
podem ser usados por quaisquer dos demais processos em qualquer ponto do ciclo de vida do
software.
1.4- MAN (management) – gestão: essa categoria consiste de quatro processos que
contêm práticas de natureza geral, afetando qualquer pessoa que execute tarefas gerenciais,
em qualquer ponto do ciclo de vida.
1.5- ORG (organization) – organização: essa categoria de processos consiste de seis
processos associados às atividades gerais da organização, desde os objetivos do negócio até a
gestão de recursos humanos.

2- A dimensão de capacidade de processo
 Estabelece uma escala de capacidade de processo em geral. A capacidade é definida
em uma escala de seis níveis crescentes, desde o nível inferior, o nível 0, até o nível
superior, o nível 5.
 Esses níveis são caracterizados por uma série de atributos de processo aplicáveis para
qualquer processo, que representam características quantificáveis necessárias para
gerenciar um processo e melhorar sua capacidade de realização.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 06

HÁ 9 ATRIBUTOS DE PROCESSO (PA) QUE SÃO AGRUPADOS NOS NÍVEIS DE CAPACIDADE:

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 06

DIFERENÇA ENTRE AS ISO

Aula 05 - ES2.pdf
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 05

SISTEMAS DE QUALIDADE - GARANTIA DA QUALIDADE

Conjunto de atividades executadas com o propósito de gerar confiança para o cliente e para a
administração da organização de que os requisitos da qualidade especificados serão atingidos.
Normas para Garantia da Qualidade: ISO 9001, ISO 9002 e ISO 9003

SISTEMAS DE QUALIDADE - DOCUMENTAÇÃO
• A documentação de um sistema de qualidade pode dividida em dois tipos:
1. Documentos da qualidade : que descrevem o processo, ou seja, como os
procedimentos devem ser executados.
2. Registros da qualidade: que registram os resultados do processo, evidenciando que a
organização seguiu as ações descritas nos documentos da qualidade.

A ISO 9000-3 possui diretrizes para aplicação da ISO 9001 no que diz respeito a:
1. Desenvolvimento;
2. Fornecimento;
3. Manutenção de software.

Para cada item da ISO 9001 existe um correspondente na ISO 9000-3 que detalha e adequa ao
software.

SISTEMAS DE QUALIDADE – ISO-9001
• Modelo para Garantia da Qualidade em Projeto, Desenvolvimento, Produção,
Instalação e Assistência Técnica.
• Indicada quando a conformidade com os requisitos especificados tiver que ser
garantida pelo fornecedor desde o projeto até a manutenção.
• ISO 9001 utiliza a metodologia conhecida por melhoria contínua conhecida como PDCA
(Planejar – Fazer- Verificar – Agir)
• A ISO 9001 baseia-se em 20 diretrizes que englobam vários aspectos da garantia da
qualidade.
• Apenas a ISO 9001 exige que todos os 20 elementos estejam presentes no sistema da
qualidade.
• A ISO 9001 é constituída por 8 seções sendo as 3 primeiras seções informações sobre a
própria norma e as 5 ultimas seções focam na implementação da Norma

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 05

SISTEMAS DE QUALIDADE – ISO-9001 – SEÇÕES - INFORMAÇÕES SOBRE A NORMA
• Âmbito: Define que a organização precisa corresponder as exigências dos clientes e
garantem que seus funcionários seguem as suas políticas e procedimentos enquanto
implementam a melhoria contínua.
• Referências Normativas: Fornece referência normativas que estão em conformidade
com a ISO 9000 – para constituir os termos da 9001.
• Termos e Definições: Define os termos utilizados na norma e indica as diferenças
existentes entre as informações.

SISTEMAS DE QUALIDADE – ISO-9001 – SEÇÕES: IMPLEMENTAÇÃO
• Sistema de Gestão de Qualidade: Descreve os requisitos gerais que englobam todas as
atividades da documentação do manual e controle de documentos, além de
determinar a sequência de iteração dos processos.
• Responsabilidade de Gestão: Exige o compromisso da gestão e explica que a
administração deve estar orientada e dedicada aos produtos da organização, clientes
e processos.
• Gestão de Recursos: Fornece critérios para desempenhar uma determinada tarefa.
Nessa seção discutem-se os recursos humanos, o planejamento de infra e ambiente de
trabalho.
• Realização do Produto: Define os passos ao desenvolvimento do produto envolvendo
desde o momento da concepção até a entrega final.
• Medição, Análise e Melhoria: Centra-se na medição, analise e melhoria, fazendo com
que a empresa faça auditorias internas, monitorando o grau de satisfação do cliente.

SISTEMAS DE QUALIDADE – ISO-90003
• Organizava e dava nomes às diretrizes diferentes dos utilizados na ISO 9001 sendo
necessário uma tabela de mapeamento entre as diretrizes da ISO 9000-3 e da ISO
9001.
• Agrupava as diretrizes em três partes principais:
• Estrutura: Descreve aspectos organizacionais, relacionados ao sistema de
qualidade.
• Atividades do ciclo de vida: Descreve as atividades de desenvolvimento de
software.
• Atividades de suporte: Descreve as atividades que apoiam as atividades do
ciclo de vida.
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 05

• Nas edições mais recentes segue exatamente a estrutura da ISO 9001 e suas diretrizes
têm o mesmo nome.
SISTEMAS DE QUALIDADE – ISO-90003 – DIRETRIZES
1. Responsabilidade da Gerência
2. Requisitos do sistema de qualidade
3. Revisão dos requisitos de contrato
4. Requisitos de projeto do produto
5. Controle de documentos e dados
6. Requisitos de aquisição (compra)
7. Produtos de clientes ou fornecedores
8. Identificação e controle de produtos
9. Processo de controle de requisites
10. Testes e inspeções dos produtos
11. Controle dos equipamentos de inspeção
12. Inspeção e teste dos produtos
13. Controle de não conformidade
14. Ações corretivas e preventivas
15. Manuseio, Armazenamento e Expedição
16. Controle dos registros da qualidade
17. Requisitos de auditoria interna da qualidade
18. Requisitos de Treinamento
19. Requisitos de Manutenção
20. Técnicas estatísticas.

SISTEMAS DE QUALIDADE – ISO-90003 – DIRETRIZES

Exemplo diretriz: CONTROLE DOS EQUIPAMENTOS DE INSPEÇÃO
Requer procedimentos para a calibração/aferição, o controle e a manutenção destes
equipamentos.
• Desenvolva procedimentos para controlar, calibrar e manter equipamentos (hardware
e software) de inspeção, medida e teste usados para demonstrar que seu produto
cumpre os requisitos especificados.
• Use ferramentas, técnicas e equipamentos para testar se seu produto de software se
adequa aos requerimentos especificados.
• Desenvolva procedimentos para assegurar que seus equipamentos de medida são
apropriados, efetivos e seguros.
• Desenvolva procedimentos para calibrar todos os seus equipamentos de inspeção,
medida e testes.
• Desenvolva procedimentos para calibrar hardware e ferramentas usadas para testar e
validade seus produtos de software.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 05

PROCESSO DE CICLO DE VIDA DO SOFTWARE – ISO-12207
• A ISO/IEC 12207 define processo de desenvolvimento de software
• Estabelece uma estrutura comum para os processos de ciclo de vida de software
visando ajudar as organizações a compreenderem todos os componentes presentes na
aquisição e fornecimento de software;
• Possibilita as organizações firmarem contratos e executarem projetos de forma mais
eficaz
• Ela pode ser utilizada com qualquer modelo de ciclo de vida, método ou técnica de
engenharia de software e linguagem de programação.
• Contém um conjunto de processos, atividades e tarefas projetado para ser adaptado
de acordo com cada projeto de software.
• A
estrutura cobre o ciclo de vida do software desde a concepção de ideias até a
descontinuação do software.
• O processo de adaptação consiste na supressão de processos, atividades e tarefas não
aplicáveis.
• Descreve a arquitetura dos processos de ciclo de vida de software, mas não especifica
os detalhes de como implementar ou executar as atividades e tarefas incluídas nos
processos.
• Não pretende prescrever o nome, formato ou conteúdo explícito da documentação a
ser produzida.
• Não prescreve um modelo específico de ciclo de vida ou métodos de desenvolvimento
de software.
• Essa flexibilidade é uma característica importante;
• As atividades e tarefas do processo de ciclo de vida do software especificam "o que
fazer" e não "como fazer“;

Propósito do Processo: O principal objetivo da execução do processo. Convém que a
implementação do processo forneça benefícios tangíveis aos envolvidos.

Resultado do Processo: Um resultado observável da realização com sucesso do propósito do
processo.
Um resultado pode ser:
• um artefato produzido;
• uma mudança significativa de estado; e
• o atendimento das especificações, como requisitos
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 05

FORMALIZA PROCESSOS, ATIVIDADES E TAREFAS QUE DEVEM SER APLICADAS:

 PF - Aquisição: obter um produto e/ou serviço que satisfaça a necessidade expressa
pelo cliente.
 PF - Fornecimento: fornecer um produto ou serviço ao cliente que atenda aos
requisitos acordados.
 PF - Desenvolvimento: transformar um conjunto de requisitos em um produto de
software ou um sistema baseado em software que atenda às necessidades explicitadas
pelo cliente.
 PF - Operação: operar o produto de software no seu ambiente e fornecer suporte aos
clientes desse produto.
 PF - Manutenção: modificar um produto de software/sistema após sua entrega para
corrigir falhas, melhorar o desempenho ou outros atributos, ou adaptá-lo a mudanças
no ambiente.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 05

 PA - Documentação: desenvolver e manter registradas as informações do software
produzidas por um processo.
 PA - Gerência de Configuração: estabelecer e manter a integridade de todos os
produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os
envolvidos.
 PA - Garantia da Qualidade: fornecer garantia de que os produtos de trabalho e
processos estão em conformidade com os planos e condições pré definidos.
 PA - Verificação: confirmar que cada produto de trabalho de software e/ou serviço de
um processo ou projeto reflete apropriadamente os requisitos especificados.
 PA - Validação: confirmar que são atendidos os requisitos de um uso específico
pretendido para o produto de trabalho de software.
 PA - Revisão Conjunta: manter um entendimento comum com os envolvidos
(stakeholders) a respeito do progresso obtido em relação aos objetivos acordados e ao
que deveria ser feito.
 PA - Auditoria: determinar, de forma independente, a conformidade dos produtos e
processos selecionados com os requisitos, planos e contratos, quando apropriado.
 PA - Resolução de Problema: assegurar que todos os problemas identificados são
analisados e resolvidos e que as tendências são identificadas.
 PA - Usabilidade: garantir que sejam considerados os interesses e necessidades dos
envolvidos de forma a proporcionar otimização do suporte e do treinamento, aumento
da produtividade e da qualidade do trabalho, melhoria das condições para o trabalho
humano e redução das chances de rejeição do sistema por parte do usuário.
 PA - Avaliação de Produto: garantir, através de exame e medição sistemáticos, que o
produto atende às necessidades especificadas e implícitas dos seus usuários.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 05

 PO - Gerência: organizar, monitorar e controlar a iniciação e a execução de qualquer
processo de forma a atingir as suas metas de acordo com as metas de negócio da
organização.
 PO - Infra estrutura: manter uma infra estrutura estável e confiável, necessária para
apoiar a execução de qualquer outro processo. A infra estrutura pode incluir
hardware, software, métodos, ferramentas, técnicas, padrões e instalações para o
desenvolvimento, a operação ou a manutenção.
 PO - Melhoria: estabelecer, avaliar, medir, controlar e melhorar um processo de ciclo
de vida de software.
 PO - Recursos Humanos: fornecer à organização os recursos humanos adequados e
manter as suas competências consistentes com as necessidades do negócio.
 PO - Gestão de Ativos: gerenciar a vida dos ativos reutilizáveis desde a sua concepção
até a sua descontinuação.
 PO - Gestão do Programa de Reuso: planejar, estabelecer, gerenciar, controlar e
monitorar esse programa em uma organização e sistematicamente explorar as
oportunidades de reuso.
 PO - Engenharia de Domínio: desenvolver e manter modelos, arquiteturas e ativos de
domínio.

PROCESSO DE DESENVOLVIMENTO
 Implementação do processo;
 Análise dos requisitos do sistema;
 Projeto da arquitetura do sistema;
 Análise dos requisitos do software;
 Projeto de arquitetura do software;
 Projeto detalhado do software;
 Codificação e testes do software;
 Integração do software;
 Testes de qualificação do software;
 Integração do sistema;
 Teste de qualificação do sistema;
 Instalação do software;
 Apoio à aceitação do software

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 05

O desenvolvedor deve estabelecer e documentar os requisitos do software, incluindo as
especificações das seguintes características de qualidade:
(i) especificações funcionais e de capacidade,
(ii) interfaces externas ao item de software,
(iii) requisitos de qualificação,
(iv) especificações de proteção, segurança e de engenharia de fatores humanos
(ergonomia),
(v) definição de dados e requisitos de bases de dados,
(vi) requisitos de instalação e aceitação do produto,
(vii) documentação do usuário,
(viii) requisitos do usuário para execução, operação e manutenção.

O desenvolvedor deve avaliar os requisitos do software considerando os seguintes critérios:
(i) Rastreabilidade para os requisitos do sistema e projeto do sistema,
(ii) consistência externa com os requisitos do sistema,
(iii) consistência interna,
(iv) testabilidade,
(v) Viabilidade do projeto do software,
(vi) viabilidade da operação e manutenção.
Os resultados das avaliações devem ser documentados.

Resultados:
 Os requisitos para o desenvolvimento do software são obtidos e acordados;
 um produto de software ou um sistema baseado em software é desenvolvido;
 produtos de trabalho intermediários são desenvolvidos e demonstram que o produto
final é baseado nos requisitos;
 há consistência entre os produtos do processo de desenvolvimento;
 os fatores de qualidade de sistema são otimizados
em relação aos requisitos do
sistema, por exemplo, desempenho, custo de desenvolvimento, usabilidade etc.;
existem evidências que demonstram que o produto final atende aos requisitos (por exemplo,
evidências de teste); e
 o produto é instalado de acordo com os requisitos cordados.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 05

Resultado
 Os requisitos alocados aos elementos de soft do sistema e suas interfaces são
definidos;
 Os requisitos de soft são analisados em relação à testabilidade e correção;
 A consistência e a rastreabilidade entre os requisitos de software e os requisitos de
sistema são estabelecidas;
 A priorização para implementação dos requisitos de soft é definida;
 Os requisitos de software são aprovados e atualizados, sempre que necessário;
 As mudanças nos requisitos de software são avaliadas quanto aos impactos nos
aspectos técnicos, de custo e de cronograma; e
 Os requisitos de software são colocados sob uma linha básica (baseline) e
comunicados a todas as partes envolvidas.

Aula 04 - ES2.pdf
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 04

QUALIDADE DO PRODUTO DE SOFTWARE
ISO-9126 - ISSO-25000
São normas que tem o foco na medição da qualidade do produto de software
A ISO 9126 É UMA NORMA DA FAMÍLIA ISO-9000
 A família de normas ISO 9000 designam um grupo de normas técnicas que
estabelecem um modelo (padrão) de gestão da qualidade para organizações em geral,
qualquer que seja o seu tipo ou dimensão;
 A adoção das normas ISO é vantajosa para as organizações uma vez que lhes confere:
o Maior organização;
o Maior Produtividade e credibilidade;
o Aumento de competitividade nos mercados nacional e internacional.
 A norma ISO/IEC 9126 é um conjunto de normas que tratam qualidade de software e
estabelecem um modelo de qualidade com os seguintes componentes:
o Processo
o Produto
o Qualidade em Uso

Processo de desenvolvimento, cuja qualidade afeta a qualidade do produto de software
gerado e é influenciado pela natureza do produto desenvolvido;
Produto, compreendendo os atributos de qualidade do produto (sistema) de software.
Os atributos de qualidade podem ser divididos entre atributos:
1. Internos:
Fatores perceptíveis pela equipe de desenvolvimento (desenvolvedores, mantenedores,
ou seja, profissionais que tem acesso ao código fonte).
1. Externos:
Fatores perceptíveis pelos usuários (usuários finais e clientes).
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 04

 Também identificada como NBR 13596
 Fornece um modelo de propósito geral o qual define 6 categorias de características de
qualidade de software que são, por sua vez, divididas em sub características.
 Que podem ser avaliadas por um conjunto de métricas.
Categoria Característica
Funcionalidade
satisfaz às necessidades explícitas
e implícitas do usuário?
Confiabilidade
durante um período de tempo,
funciona de acordo com as condições
pré-estabelecidas?
Usabilidade é fácil de usar?
Eficiência não desperdiça recursos?
Manutenibilidade é fácil de alterar?
Portabilidade
é facilmente adaptável a
diferentes plataformas?

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 04

FUNCIONALIDADE: A capacidade de um software prover funcionalidades que satisfaçam o
usuário em suas necessidades declaradas e implícitas, dentro de um determinado contexto de
uso.
• Adequação: mede o quanto o conjunto de funcionalidades é adequado às
necessidades do usuário;
• Acurácia (ou precisão): representa a capacidade do software de fornecer
resultados precisos ou com a precisão dentro do que foi acordado/solicitado;
• Interoperabilidade: trata da maneira como o software interage com outro(s)
sistema(s) especificados;
• Segurança: mede a capacidade do sistema de proteger as informações do
usuário e fornecê-las apenas (e sempre) às pessoas autorizadas;

CONFIABILIDADE: O produto se mantém no nível de desempenho nas condições
estabelecidas.

• Maturidade: a capacidade do software em evitar falhas decorrentes de
defeitos no software;
• Tolerância a Falhas: a capacidade do software em manter o funcionamento
adequado mesmo quando ocorrem defeitos nele ou nas suas interfaces
externas;
• Recuperabilidade: a capacidade de um software se recuperar após uma falha,
restabelecendo seus níveis de desempenho e recuperando os seus dados;

USABILIDADE: capacidade do produto de software ser compreendido, seu funcionamento
aprendido, ser operado e ser atraente ao usuário.
O conceito é abrangente e se aplica mesmo a programas que não possuem uma interface para
o usuário final.

• Inteligibilidade: representa a facilidade com que o usuário pode compreender
as suas funcionalidades e avaliar se o mesmo pode ser usado para satisfazer as
suas necessidades específicas;
• Apreensibilidade: identifica a facilidade de aprendizado do sistema para os
seus potenciais usuários;
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 04

• Operacionalidade: como o produto facilita a sua operação por parte do
usuário, incluindo a maneira como ele tolera erros de operação;
• Atratividade: envolve características que possam atrair um potencial usuário
para o sistema, o que pode incluir desde a adequação das informações
prestadas para o usuário até os requintes visuais utilizados na sua interface
gráfica;

EFICIÊNCIA: tempo de execução e os recursos envolvidos são compatíveis com o nível de
desempenho do software.

• Comportamento em Relação ao Tempo: avalia se os tempos de resposta (ou
de processamento) estão dentro das especificações. qual é o tempo de
resposta e de processamento?
• Utilização de Recursos: mede tanto os recursos consumidos quanto a
capacidade do sistema em utilizar os recursos disponíveis. quanto recurso usa?
Durante quanto tempo

MANUTENIBILIDADE: Capacidade (ou facilidade) do produto de software ser modificado,
incluindo tanto as melhorias ou extensões de funcionalidade quanto as correções de defeitos,
falhas ou erros.

• Analisabilidade: identifica a facilidade em se diagnosticar eventuais problemas
e identificar as causas das deficiências ou falhas;
• Modificabilidade: caracteriza a facilidade com que o comportamento do
software pode ser modificado;
• Estabilidade: avalia a capacidade do software de evitar efeitos colaterais
decorrentes de modificações introduzidas;
• Testabilidade: representa a capacidade de se testar o sistema modificado,
tanto quanto as novas funcionalidades quanto as não afetadas diretamente
pela modificação;

PORTABILIDADE: A capacidade do sistema ser transferido de um ambiente para outro.
Ambiente é todo fator de adaptação, tal como:
• Diferentes condições de infraestrutura (sistemas operacionais, versões de bancos de
dados, etc.),
Disciplina Engenharia
de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 04

• Diferentes tipos e recursos de hardware (tal como aproveitar um número maior de
processadores ou memória).
• Fatores como idioma ou a facilidade para se criar ambientes de testes devem ser
considerados como características de portabilidade.

• Adaptabilidade: capacidade do software se a adaptar a diferentes ambientes
sem a necessidade de ações adicionais (configurações);
• Capacidade para ser Instalado: identifica a facilidade com que pode se instalar
o sistema em um novo ambiente;
• Coexistência: mede o quão facilmente um software convive com outros
instalados no mesmo ambiente;
• Capacidade para Substituir: capacidade que o sistema tem de substituir outro
sistema especificado, em um contexto de uso e ambiente específicos. Este
atributo interage tanto com adaptabilidade quanto com a capacidade para ser
instalado.

QUALIDADE DO PRODUTO DE SOFTWARE – ISO-9126

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 04

Definição dos níveis de pontuação
• Os resultados quantificados são mapeados em uma escala com regiões sugeridas pela
norma:
– Três para a pontuação Satisfatória:
Excelente
Bom
Razoável
– Uma para a pontuação Insatisfatória

QUALIDADE DO PRODUTO DE SOFTWARE – ISO-25000 - ISO/IEC 25000 (SQUARE)
Software product QUAlity - Requirements and Evaluation
E uma evolução das séries de Norma

OBJETIVO:
• Organizar;
• Enriquece;
• Unir as séries que cobrem dois processos principais:

1. Especificação de requisitos de qualidade do software e
2. Avaliação da qualidade do software, suportada pelo processo de medição da qualidade
do software.

ESTABELECE CRITÉRIOS PARA:

• especificação de requisitos de qualidade de produtos de software,
• indicadores e respetiva avaliação

• Inclui um modelo de qualidade para unir as definições de qualidade dos clientes com
os atributos no processo de desenvolvimento.
• Tendo a ISO-9126 como base principal, a ISO-25000 pode ser entendida como a norma
que estabelece o “como fazer” e acrescenta algumas características.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 04

MÓDULOS PRINCIPAIS
• Gerenciamento
• Introdução geral sobre 25000
• Definição de termos
• Modelo de qualidade
• Corresponde a 9126 – conceitos qualidade externa/interna – modelo de
características/atores
• Medição
• Definir medição / Processo de medição / Proposta de métricas
• Requisitos de qualidade
• Herda da 9126 – conceito do objetivo de qualidade para um produto – relação
com os requisitos do software
• Avaliação

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 04

Aula 03 - ES2.pdf
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 03

Somente há poucas décadas o conceito de qualidade passou formalmente para a função de
gerenciamento.
• Era somente relacionada às funções de inspeção
• Hoje é vista como essencial para o sucesso de um produto

ERA DA INSPEÇÃO
 No final do século XVIII e início do século XIX a Qualidade era obtida de uma forma
bem diferente da obtida hoje em dia.
 Com a Revolução Industrial começou a aumentar o distanciamento entre o produtor e
o consumidor, o que originou os primeiros problemas sérios com a qualidade do
produto.
 Henry Ford descobriu que se dividissem as tarefas de em pequenas operações, poderia
recrutar mão-de-obra não qualificada, treinar e, assim, conduzir de maneira eficaz
todas as tarefas de fabricação e montagem de um automóvel.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 03

ERA DO CONTROLE
 Com a ascensão da empresa industrial e da produção massificada, tornou-se
impraticável inspecionar a totalidade de produtos que saíam aos milhares das linhas
de montagem;
 Surgimento do controle estatístico da qualidade (CEQ), baseado em técnicas de
amostragem;
 Apesar do envolvimento dos diversos setores das empresas na busca de qualidade em
seus produtos, faltava uma coordenação central.
ERA DA GARANTIA
 A Guerra Fria fez com que a questão "qualidade" ganhasse nova dimensão. Estudos
mostravam que os problemas da falta de qualidade eram causados em 80% dos casos
por falhas gerenciais e não por falhas técnicas;
 As empresas sempre se preocuparam com a qualidade no "chão de fábrica",
esquecendo-se que os grandes problemas surgiam das falhas de comunicação entre os
diversos órgãos da empresa e entre diversos níveis hierárquicos.
ERA DA QUALIDADE
 O livro Total Quality Control Engineering and Management (Feigenbaum, 1961, que
envolve de maneira sistêmica todos os órgãos da empresa, passando pelo marketing,
projeto, desenvolvimento, aquisição, fabricação, inspeção e testes, expedição,
instalação e assistência técnica;
 A ênfase passa a ser o cliente, tornando-se o centro das atenções das organizações
que dirigem seus esforços para satisfazer às suas necessidades e expectativas;
 A gestão da qualidade total pode ser definida como um conjunto integrado e
sistêmico de procedimentos que visam coordenar as ações das pessoas de uma
organização.
ERA DA GESTÃO
 A qualidade deixa de ser atributo do produto ou serviço, deixa de ser também
responsabilidade exclusiva do departamento da qualidade. A qualidade passa a ser
problema de todos e envolve todos os aspectos da operação da empresa;
 O desenvolvimento de padrões continua a ser feito com bastante afinco, sobretudo
em busca de normalizações internacionais, a exemplo da ISO 9000;
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 03

Aqui aparece Joseph Moses Juran com sua famosa definição de qualidade como adequação ao
uso. Fica assim expressa a existência de um sujeito, que vai receber o bem ou serviço, cujas
necessidades de uso precisam ser satisfeitas.
Com o conceito de adequação ao uso, Juran explicita que o produto deve cumprir as funções
básicas que resolvem os problemas do cliente e, ao mesmo tempo, atender às características
conexas como nível de desempenho, durabilidade, pouca manutenção e facilidade de uso,
entre outras.
QUALIDADE DE SOFTWARE
 “É um processo sistemático que focaliza todas as etapas e artefatos produzidos com o
objetivo de garantir a conformidade de processos e produtos, prevenindo e
eliminando defeitos”.
 Conjunto de características que devem ser alcançadas em um determinado grau para
que o produto atenda às necessidades de seus usuários. [Ana R. C. Rocha, 2001]
 Alguns modelos de qualidade de software também são citados por Pressman (2005).
Há o que McCall e Cavano (1978) sugerem como métricas para qualidade de software.
Conhecido como Fatores
da Qualidade
 Portanto, é necessário um planejamento adequado para que a qualidade de software
seja atingida, conforme a definição de qualidade que deverá ser alcançada.
 Para isso são necessários modelos, padrões, procedimentos e técnicas para atingir
essas metas de qualidade propostas.
 Para tanto, todas as etapas do ciclo de vida de engenharia de software devem ser
contempladas com atividades que visam garantir a qualidade tanto do processo
quanto do produto.
• Pelos fundamentos da Engenharia de Software, um processo bem definido e aferido
tende a produzir, no final, um produto com qualidade.
• Mas como medir se o produto, resultante do processo, tem a qualidade esperada?
• Algumas normas focam medir a qualidade do processo. Outras normas enfatizam
medir a qualidade do produto.
• Para que se possa medir a qualidade é necessário estabelecer critérios;
• Os critérios visam minimizar a subjetividade da avaliação;

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 03

MODELO DE QUALIDADE DE MCCALL

OPERAÇÃO
 Correção: o quanto um programa satisfaz a sua especificação e cumpre os
objetivos visados pelo cliente
 Confiabilidade: o quanto um programa executa a função pretendida com a
precisão exigida
 Eficiência: a quantidade de recursos computacionais e de código exigida para que
um programa execute sua função
 Integridade: o quanto o acesso ao software ou aos dados por pessoas não
autorizadas pode ser controlado
 Usabilidade: o quanto de esforço é necessário para aprender, preparar a entrada e
interpretar a saída de um programa.

TRANSIÇÃO
 Portabilidade: o quanto de esforço é necessário para transferir um programa de
uma plataforma de hw e/ou software para outra
 Reusabilidade: o quanto um programa (ou partes dele) pode ser reutilizado em
outros programas
 Interoperabilidade: o quanto de esforço é necessário para se acoplar um
programa a um outro

REVISÃO
 Manutenção: o quanto de esforço é necessário para localizar e eliminar erros em um
programa
 Flexibilidade: o quanto de esforço é necessário para modificar um programa
 Testabilidade: o quanto de esforço é necessário para testar um programa a fim de
garantir que ele execute a função pretendida
TRANSIÇÃO
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 03

A VISÃO DO USUÁRIO:
 O usuário interessado na utilização e no desempenho Há interesse nas medidas
externas de qualidade:
• as funções especificadas estão disponíveis?
• qual é a confiabilidade do software e sua eficiência?
• é fácil de usar?
 é fácil para transferir para outro ambiente operacional Características construtivas não
interessam

A VISÃO DO DESENVOLVEDOR:
 Deve ser coerente com as expectativas do usuário (requisitos + aceitação)
 Medidas internas – ex: controle de caminhos + tempo de espera ⇒ tempo de resposta
 Qualidade de produtos intermediários Expectativas de outros atores; ex: manutenção
 Produtos de prateleira: requisitos implícitos

CRISE DO SOFTWARE:
 Abordagem tradicional com teste final
• grande percentual de sistemas encomendados e não usados; desperdício
• motivos: ou com problemas de confiabilidade ou não atendiam mais às
necessidades do cliente
 Falta de foco no cliente:
• distância do especificado
 Foco no processo
• não basta esperar o produto final
bons processos -> bons produtos

Aula 02 - ES2.pdf
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 02

QUETIONÁRIO:
1. O que você entende de Qualidade?
2. Qual o seu nível de qualidade ao desempenhar uma atividade ou função?
3. Qual o nível de qualidade que você espera de um “terceiro”?
4. Quem “desenvolveu” o critério de qualidade no mundo? Por quê? Desde quando?
5. Cite 3 ferramentas de qualidade? Explique?
6. Vocês conhece o programa de qualidade 5S? Quem já executou?
QUALIDADE
• Para que se possa identificar a qualidade de algo é necessário que o que se está
alisando possa ser medido segundo algum critério;
• A qualidade de algo deve atender aos requisitos implícitos e explícitos esperados para
o produto;
• Em um produto que possui uma forma física torna-se mais fácil de identificar os itens
de qualidade do que um produto de software.
• As métricas de qualidade se tornaram cada vez mais necessárias à medida que a
indústria tendeu a produção em larga escala;
• As métricas avaliam tanto o produto final como o(s) processo(s) utilizado para produzir
o produto.
CONCEITO DE QUALIDADE DE SOFTWARE
• “A qualidade de software é definida como a conformidade a requisitos funcionais e de
desempenho explicitamente declarados, a padrões de desenvolvimento claramente
documentados e a características implícitas que são esperadas de todo software
profissionalmente desenvolvido” (PRESSMAN, 1995)
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 02

OS FATORES QUE AFETAM A QUALIDADE DE SOFTWARE PODEM SER CATEGORIZADOS EM 02
(DOIS) GRUPOS:
• Podem ser medidos diretamente. Exemplo: erros, unidade de tempo.
• Medidos indiretamente. Exemplo: usabilidade, manutenibilidade.
• A qualidade de um software depende de se decidir o que significa qualidade;
• Não se pode ser dogmático: “Não cometerás erros de programação”
• É preciso adotar uma perspectiva técnica e considerar diversos fatores que afetam a
construção do produto e que influenciem no julgamento dos usuários...
FATORES QUE INFLUENCIAM
• Tamanho e complexidade do software sendo construído;
• Número de pessoas envolvidas no projeto;
• Ferramentas utilizadas;
• Custos associados à existência de erros;
• Custos associados à detecção e à remoção de erros.

SQA - SOFTWARE QUALITY ASSURANCE - GARANTIA DE QUALIDADE DO SOFTWARE
É uma atividade que é aplicada ao longo de todo processo de engenharia de software

SQA ABRANGE
1. Métodos e ferramentas de análise, projeto, codificação e teste;
2. Revisões técnicas formais que são aplicadas durante cada fase de engenharia de
software;
3. Uma estratégia de teste de múltiplas fases;
4. Controle da documentação de software e das mudanças feitas nela;
5. Um procedimento para garantir a adequação aos padrões de desenvolvimento de
software (quando aplicáveis)
6. Mecanismos de medição e divulgação.

QUALIDADE É UM DOS PRINCIPAIS OBJETIVOS DA ENGENHARIA DE SOFTWARE.
• Muitos métodos, técnicas e ferramentas são desenvolvidas para apoiar a produção
com qualidade.
• “Tem-se dado grande importância ao processo como forma de se garantir um software
de melhor qualidade.”

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 02

O termo QUALIDADE pode ser definido de várias formas, causando mal-entendidos:
• Qualidade não tem um único sentido;
• Para cada conceito existem vários níveis
de abstração;
• Visão popular pode ser diferente do seu uso profissional.
• Qualidade é estar em conformidade com os requisitos do cliente.
• Qualidade é antecipar e satisfazer os requisitos dos clientes.
• Qualidade é escrever tudo o que se deve fazer e fazer tudo o que foi escrito.
• SIGNIFICADO: “Propriedade, atributo ou condição das coisas ou das pessoas capaz de
distingui-las das outras e de lhes determinar a natureza” (Aurélio)

EVOLUÇÃO DA QUALIDADE

A maioria dos autores que hoje são chamados de "gurus da qualidade" (Juran, Deming,
Feigenbaum e Ishikawa).
EDWARDS DEMING:
 Norte-americano
 Várias conferências no Japão na década de 1950
 Gestão da qualidade
 “A participação do trabalhador no processo decisório é fundamental”
 “A simples inspeção de entrada e de saída não é eficaz”
 “Sistema” dos 14 princípios
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 02

OS 14 PRINCÍPIOS:

1º princípio: Estabeleça constância de propósitos para a melhoria do produto e do serviço,
objetivando tornar-se competitivo e manter-se em atividade, bem como criar emprego;

2º princípio: Adote a nova filosofia. Estamos numa nova era econômica. A administração
ocidental deve acordar para o desafio, conscientizar-se de suas responsabilidades e
assumir a liderança no processo de transformação;

3º princípio: Deixe de depender da inspeção para atingir a qualidade. Elimine a
necessidade de inspeção em massa, introduzindo a qualidade no produto desde seu
primeiro estágio;

4º princípio: Cesse a prática de aprovar orçamentos com base no preço. Ao invés disto,
minimize o custo total. Desenvolva um único fornecedor para cada item, num
relacionamento de longo prazo fundamentado na lealdade e na confiança;

5º princípio: Melhore constantemente o sistema de produção e de prestação de serviços,
de modo a melhorar a qualidade e a produtividade e, consequentemente, reduzir de
forma sistemática os custos;

6º princípio: Institua treinamento no local de trabalho;

7º princípio: Institua liderança. O objetivo da chefia deve ser o de ajudar as pessoas e as
máquinas e dispositivos a executarem um trabalho melhor. A chefia administrativa está
necessitando de uma revisão geral, tanto quanto a chefia dos trabalhadores de produção;

8º princípio: Elimine o medo, de tal forma que todos trabalhem de modo eficaz para a
empresa;

9º princípio: Elimine as barreiras entre os departamentos. As pessoas engajadas em
pesquisas, projetos, vendas e produção devem trabalhar em equipe, de modo a preverem
problemas de produção e de utilização do produto ou serviço;

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 02

10º princípio: Elimine lemas, exortações e metas para a mão-de-obra que exijam nível zero
de falhas e estabeleçam novos níveis produtividade. Tais exortações apenas geram
inimizades, visto que o grosso das causas da baixa qualidade e da baixa produtividade
encontram-se no sistema, estando, portanto, fora do alcance dos trabalhadores;

11º princípio: Elimine padrões de trabalho (quotas) na linha de produção. Substitua-os
pela liderança; elimine o processo de administração por objetivos. Elimine o processo de
administração por cifras, por objetivos numéricos. Substitua-os pela administração por
processos através do exemplo de líderes;

12º princípio: Remova as barreiras que privam o operário horista de seu direito de
orgulhar-se de seu desempenho. A responsabilidade dos chefes deve ser mudada de
números absolutos para a qualidade; remova as barreiras que privam as pessoas da
administração e da engenharia de seu direito de orgulharem-se de seu desempenho. Isto
significa a abolição da avaliação anual de desempenho ou de mérito, bem como da
administração por objetivos;

13º princípio: Institua um forte programa de educação e auto-aprimoramento;

14º princípio: Engaje todos da empresa no processo de realizar a transformação. A
transformação é da competência de todo mundo.

Aula 01 - ES2.pdf
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 01

I - EMENTA
Qualidade de Software. Modelos de qualidade de software. Verificação e Validação. Testes.
Plano e casos de teste. Técnicas e tipos de teste. Revisões técnicas formais. Manutenção de
Software. Tipos de manutenção. Gerência de configuração.

II – OBJETIVOS GERAIS
Apresentar ao aluno os aspectos mais importantes para a qualidade de um produto de
software, bem como a importância das atividades de testes e da manutenção de software.

III – OBJETIVOS ESPECÍFICOS
Apresentar ao aluno conceitos de qualidade de produto e de processo, bem como os modelos
de qualidade de software. Conscientizar os alunos sobre a importância da Verificação e
Validação para a qualidade do software que é produzido, bem como a importância dos testes e
seu impacto nos custos de desenvolvimento do software. Apresentar as atividades de teste e
as principais técnicas empregadas. Apresentar ao aluno a importância da manutenção no ciclo
de vida de um software. Mostrar que esta atividade envolve não somente o código, mas
também todos os documentos do projeto.

IV - CONTEÚDO PROGRAMÁTICO
1. Qualidade de software
 Conceitos de qualidade de produto e de processo
 Qualidade do produto de software: ISO/IEC 9126 e ISO 25000
 Sistemas da Qualidade: ISO 90003 e ISO 9001
 Processos do Ciclo de Vida do Software: ISO 12207
 Modelos de qualidade de software
CMMI (Capability Maturity Model Integration)
MPS.Br (Melhoria de Processos de software Brasileiro)
SPICE - ISO 15504

2. Verificação e Validação de software
 Definição e importância da Verificação e Validação ao longo do ciclo de vida
 Classificação das técnicas
 Revisões técnicas: Passeio (walkthrough); Inspeção do produto
 Abordagens formais: Prova de correção; O processo sala limpa (clean room)
Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 01

 Testes: Fundamentos; Os testes e o ciclo de vida
 Testes unitários: Testes Estruturais; Testes Funcionais
 Outras estratégias de teste

3. Manutenção de software
 Manutenção: definição e características
 Manutenabilidade
 Processos de Manutenção
 Técnicas de Desenvolvimento para a Manutenabilidade
 Padrões de Desenvolvimento
 Padrões de Manutenção
 Desenvolvimento Baseado em Componentes e Impactos na Manutenção
 Desenvolvimento Orientado a Aspectos e Impactos na Manutenção
 Atividades de Apoio a Manutenção

4. Gerência de Configuração

V - BIBLIOGRAFIA BÁSICA
PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e padrões. 3. ed. Rio de
Janeiro: LTC, 2012.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. ed. AMGH, 2011.
COSTA, I.; MOLLO NETO, P. L. O.; CARDOSO JÚNIOR, J. L.. Qualidade em tecnologia da
informação: conceitos de qualidade nos processos, produtos, normas, modelos e testes de
software no apoio às estratégias empresariais. São Paulo: Atlas, 2013.
VI - BIBLIOGRAFIA COMPLEMENTAR
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
COHN, M. Desenvolvimento de Software com Scrum. Bookman, 2011.
SCHACH, S. R. Engenharia de software: os paradigmas clássico orientado a objetos. 7. ed. Porto
Alegre : AMGH, 2010.
BECK., and Kent. TDD Desenvolvimento Guiado por Testes. Bookman, 2010. PEZZÉ, M.; YOUNG,
M. Teste e Análise de Software: processo, princípios e técnicas. Porto Alegre: Bookman, 2008.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 01

Lembrar: O que é software?
Muitas pessoas atualmente ainda possuem um conceito errado a respeito de software,
o que é então para vocês software????
Segundo o Autor Roger Pressman, software de computador é o produto que os
profissionais de software (quais são os profissionais), constroem e mantêm ao longo do
tempo. Esse software abrange programas que executam em computadores de qualquer
tamanho e arquitetura, conteúdo que é apresentado ao programa a ser executado e
documentos tanto de forma impressa quanto virtual que combinam todas as formas de mídias
eletrônicas.

O que é Engenharia de Software?
Segundo Sommerville, Engenharia de software é uma disciplina de engenharia
relacionada com todos os aspectos da produção de software, desde os estágios iniciais de
especificação do sistema até sua manutenção, depois que este entrar em operação.
Nessa definição dada por Sommerville temos duas frases importantes que vamos
discutir a seguir:

 Disciplina de Engenharia – É dito uma disciplina, porque os engenheiros estão sempre
aplicando teorias, métodos e ferramentas sempre aonde as mesmas forem mais
apropriadas e usando-as de modo seletivo, além disso, os engenheiros estão sempre
estudando novas maneiras e métodos de solucionar os problemas.

 Todos os aspectos da produção de software – Isso significa dizer que a Engenharia não
esta relacionada apenas com os processos técnicos de desenvolvimento de software,
mas também com atividades como o gerenciamento e desenvolvimento de
ferramentas, métodos e teorias que apoiem a produção de software.

Disciplina Engenharia de Software II Período 2018/1 Turma: ADS
Prof. Rika Luz richardson.luz@docente.unip.br Aula 01

Questões:

Assinale a alternativa que melhor explica a frase “O software não se desgasta, ele se
deteriora".

a) Significa que o software não tem falhas
b) Significa que o software não sofre falhas, mas problemas relacionados ao tempo e
ambiente
c) Significa que o software não sofre desgastes de manutenções ao longo da sua vida
entretanto sofre problemas ambientais e temporais tornando-se obsoletos ou
deteriorados
d) Significa que o software não sofre desgastes ambientais (tempo, poeira), mas ao longo
da sua vida sofre diversas alterações por causa das falhas e manutenções ficando
obsoletos ou deteriorados

Em 1968 aconteceu a NATO Software Engineering Conference, um evento criado com o
objetivo de discutir alternativas para contornar a Crise do Software. Podemos resumir à crise
no desenvolvimento de software causada por alguns problemas com exceção de:

a) Projetos estourando o prazo
b) Software de baixa qualidade
c) Projetos atendendo o orçamento
d) Software muitas vezes não atendendo os requisitos

Podemos afirmar que a construção de um carro e a construção de um software são projetos
similares?

a) Não, pois os produtos são diferentes
b) Sim, mesmo exigindo diferentes formas de condução e execução do projeto
c) Sim, porque qualquer pessoa pode utilizar
d) Não, pois o levantamento de requisitos é totalmente diferente