ES+-+2019-01+-+parte+05

Prévia do material em texto

Engenharia de Software
5ª parte
Prof. Jobson Massollar
jobson.silva@uva.br
Engenharia de Software2
Qualidade de Software
➢ O que é qualidade de software?
"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]
"Totalidade de características de uma entidade que lhe confere a
capacidade de satisfazer necessidades explícitas e implícitas"
[ISO 1994]
Engenharia de Software3
Qualidade de Software
➢ Afinal, como obter um software de qualidade?
✓ Através de mecanismos de avaliação: 
▪ Garantia da qualidade (Quality Assurance)
▪ Controle da qualidade (Quality Control)
Engenharia de Software4
Garantia e Controle da Qualidade
➢ Garantia da qualidade: está relacionado ao processo usado para
criação dos produtos.
✓ Nesse caso, estamos interessados em avaliar se o processo para
produzir os diversos artefatos foi seguido.
➢ Controle da qualidade: está relacionado às técnicas empregadas para
avaliar se os produtos possuem a qualidade planejada.
✓ Nesse caso, estamos interessados em avaliar se os artefatos
produzidos possuem defeitos.
✓ Também está relacionado ao entendimento das causas dos
defeitos e definição de ações para eliminá-las.
Engenharia de Software5
Garantia e Controle da Qualidade
Garantia da Qualidade Controle da Qualidade
Foco na adequação dos processos Foco na descoberta de defeitos
Voltada para a prevenção Voltado para a detecção
Orientada a processos Orientada a produtos
Utiliza monitoramento e auditorias 
de processos para melhorá-los
Utiliza revisões e testes para avaliar os 
produtos
Procura garantir que a equipe está 
trabalhando da forma correta
Procura avaliar se o produto está em 
conformidade com o que foi definido
Engenharia de Software6
Garantia e Controle da Qualidade
Garantia da Qualidade Controle da Qualidade
Foco na adequação dos processos Foco na descoberta de defeitos
Voltada para a prevenção Voltado para a detecção
Orientada a processos Orientada a produtos
Utiliza monitoramento e auditorias 
de processos para melhorá-los
Utiliza revisões e testes para avaliar o 
produto
Procura garantir que a equipe está 
trabalhando da forma correta
Procura avaliar se o produto está em 
conformidade com o que foi definido
Modelos de maturidade 
(CMMI, MPS-BR)
Engenharia de Software7
Garantia e Controle da Qualidade
Garantia da Qualidade Controle da Qualidade
Foco na adequação dos processos Foco na descoberta de defeitos
Voltada para a prevenção Voltado para a detecção
Orientada a processos Orientada a produtos
Utiliza monitoramento de processos 
para melhorá-los
Utiliza revisões e testes para avaliar o 
produto
Procura garantir que a equipe está 
trabalhando da forma correta
Procura avaliar se o produto está em 
conformidade com o que foi definido
Verificação e Validação 
de sistemas
Engenharia de Software8
"A qualidade de um sistema ou produto é altamente 
influenciada pela qualidade do processo utilizado para 
desenvolvê-lo e mantê-lo"
Modelos de Maturidade de Processos
Engenharia de Software9
Modelos de Maturidade de Processos
➢ Em 1984, o Departamento da Defesa norte-americano (DoD)
patrocinou a criação do SEI (Software Engineering Institute) ao
observar a situação crítica dos seus contratos de desenvolvimento de
software.
➢ O DoD tinha como objetivo alcançar, em seus projetos de software, o
mesmo nível de maturidade e controle dos setores industriais, tais
como a manufatura e a construção civil.
➢ O SEI tinha como desafio criar condições para a evolução da boas
práticas da Engenharia de Software.
Engenharia de Software10
Modelos de Maturidade de Processos
➢ O modelo proposto pelo SEI está baseado nos princípios propostos
por três pesquisadores na área de qualidade (Crosby, Juran e
Deming).
➢ Esses princípios foram organizados em uma estrutura chamada de
modelo de maturidade.
➢ Um modelo de maturidade indica o quanto uma empresa está madura
com base nas práticas que ela adotada.
➢ Exemplos:
✓ Se uma empresa adota atividades da Engenharia de Requisitos,
então ela é mais madura do que uma empresa que não adota.
✓ Se uma empresa adota atividades de Teste de Software, então ela
é mais madura do que uma empresa que não adota.
Engenharia de Software11
Modelos de Maturidade de Processos
➢ Assim, um Modelo de Maturidade funciona como um guia para as
empresas de tal forma que elas possam:
✓ Avaliar o seu estágio de maturidade no que diz respeito ao
desenvolvimento de sistemas, e;
✓ Planejar melhorias no seu processo de desenvolvimento de
software (aumentar sua maturidade).
Engenharia de Software12
Modelos de Maturidade de Processos
➢ Por que as empresas buscam maturidade no desenvolvimento?
✓ Porque em empresas imaturas os processos de desenvolvimento
são improvisados ou não são seguidos:
▪ O trabalho é feito em regime de emergência (apagar incêndios);
▪ Compromissos de prazo e custo não são cumpridos;
▪ O planejamento não é feito com base em estimativas realistas;
▪ Como os processos não são bem definidos todas as iniciativas de
melhoria não se sustentam ou não se perpetuam;
▪ Quando o projeto é pressionado por prazo, a qualidade e o escopo
são sacrificados;
▪ O sucesso de um projeto depende de especialistas ("gurus") para
resolver grandes problemas;
▪ Frequentemente novas tecnologias são adotadas como soluções
milagrosas.
Engenharia de Software13
Modelos de Maturidade de Processos
➢ Em 1991, o SEI publicou a versão 1.0 do SW-CMM (Capability Maturity
Model for Software).
➢ Com o sucesso do SW-CMM, outros modelos semelhantes foram
criados para outras áreas. Exemplos:
✓ Gestão de Recursos Humanos (People-CMM)
✓ Aquisição de Software (SA-CMM)
✓ Engenharia de Sistemas (SE-CMM)
➢ Entretanto, os diversos modelos apresentavam estruturas, formatos e
termos diferentes, dificultando sua aplicação conjunta.
➢ Em 2000, o SEI lançou o CMMI (Capability Maturity Model
Integration), com a finalidade de integrar os diversos modelos CMM.
Engenharia de Software14
CMMI
➢ Objetivo principal: guiar organizações a conhecerem e melhorarem
seus processos de software.
✓ Identifica as práticas de Engenharia de Software que um processo
de software maduro deve ter.
✓ Descreve como as práticas de Engenharia de Software evoluem
sob certas condições.
✓ Organiza os estágios de evolução da melhoria dos processos em
níveis de maturidade.
✓ É formado por 3 grandes modelos:
▪ CMMI-DEV: modelo de maturidade para desenvolvimento de software.
▪ CMMI-SVC: modelo de maturidade para serviços contínuos de
software.
▪ CMMI-ACQ: modelo de maturidade para contratação de serviços de
software.
Engenharia de Software15
CMMI-DEV
➢ O CMMI-DEV está organizado em 5 níveis de maturidade:
✓ Um nível de maturidade é um patamar evolutivo bem definido, que
mostra o quanto o processo de desenvolvimento de software de
uma organização está maduro.
✓ Os níveis de maturidade são uma forma de priorizar as ações de
melhoria, de tal forma que a empresa consiga aumentar a
maturidade do processo de desenvolvimento de software de forma
gradativa.
Engenharia de Software16
CMMI-DEV
Engenharia de Software17
CMMI-DEV
➢ Distribuídos nesses 5 níveis estão:
✓ 22 áreas de processos (PA - Processes Areas) agrupadas em 4
categorias:
▪ Uma área de processo é o agrupamento de práticas comuns de
uma determinada disciplina.
▪ Define o "o que fazer" do CMMI.
Engenharia de Software18
➢ Níveis de maturidade x Áreas de Processo
CMMI-DEV
2 3
4 5
Engenharia de Software19
CMMI-DEV
➢ Cada Área de Processo possui métodos e práticas específicas (MEs e
PEs):
➢ Exemplo: Planejamentodo Projeto possui 3 MEs.
✓ ME 1 – Estabelecer estimativas:
▪ PE 1.1-1 – Estime o escopo do projeto.
▪ PE 1.2-1 – Estabeleça estimativas de produto do trabalho.
▪ PE 1.3-1 – Defina o ciclo de vida do projeto.
▪ PE 1.4-1 – Determine estimativas de esforço e custo.
Engenharia de Software20
CMMI-DEV
➢ Exemplo: Planejamento do Projeto possui 3 MEs
✓ ME 2 – Desenvolver um plano de projeto:
▪ PE 2.1-1 – Estabeleça o orçamento e o cronograma.
▪ PE 2.2-1 – Identifique os riscos do projeto.
▪ PE 2.3-1 – Planeje a gestão de dados.
▪ PE 2.4-1 – Planeje os recursos de projeto.
▪ PE 2.5-1 – Planeje as habilidades e conhecimentos necessários.
▪ PE 2.6-1 – Planeje o envolvimento dos interessados.
▪ PE 2.7-1 – Estabeleça o plano de projeto.
✓ ME 3 – Obter comprometimento com o plano
▪ PE 3.1-1 – Revise planos que afetam o projeto.
▪ PE 3.2-1 – Reconcilie os níveis de trabalho e os recursos.
▪ PE 3.3-1 – Obtenha o comprometimento com o plano.
Engenharia de Software21
CMMI-DEV
➢ Nível 1: Inicial
✓ O processo de software é caracterizado como sendo imprevisível e,
ocasionalmente, caótico.
✓ Poucos processos são definidos e o sucesso depende de esforços
individuais.
✓ O processo de software é uma caixa preta, de forma que somente
as entradas e os produtos finais podem ser vistos com clareza.
entrada saída
Engenharia de Software22
CMMI-DEV
➢ Nível 1: Inicial
✓ Organizações no nível 1 apresentam deficiências de planejamento
e enfrentam dificuldades ao realizarem previsões.
✓ Cronogramas e planos são irrealistas.
✓ Como não há credibilidade no planejamento, mesmo aquilo que foi
planejado não é seguido.
✓ Não há controle de requisitos e o cliente só os avalia na entrega
do produto.
✓ É comum passar diretamente dos requisitos à codificação.
✓ A documentação é encarada como algo inútil.
✓ São comuns reações intransigentes ao uso de padrões,
documentação e ferramentas.
✓ As chances de sucesso: habilidades pessoais do corpo gerencial e
dos desenvolvedores, da sua dedicação e "heroísmo".
Engenharia de Software23
CMMI-DEV
➢ Nível 2: Gerenciado/Repetível
✓ Processos básicos de gerência de projetos são estabelecidos para
controle de custos, prazos e escopo.
✓ É possível repetir sucessos de projetos anteriores em aplicações
similares.
✓ Ao invés do processo ser uma única caixa preta, ele passa a ser
uma sequência de caixas pretas que asseguram a visibilidade em
determinados pontos, que são os marcos do projeto.
entrada saída
Engenharia de Software24
CMMI-DEV
➢ Nível 2: Repetível
✓ Neste nível as organizações têm maior probabilidade de cumprir
compromissos de requisitos, prazos e custos, desde que os
projetos sejam semelhantes a outros realizados anteriormente.
✓ A organização é disciplinada, mas não está bem preparada para
mudanças.
✓ Há preocupação com a gerência do projeto. Os gerentes
acompanham custos, cronogramas e o escopo de cada um dos
projetos.
✓ A gerência ainda não é pró-ativa, tomando ações normalmente
quando está diante de um problema.
✓ Os projetos podem ter processos diferentes.
✓ Controla-se a evolução dos requisitos, permitindo avaliações ao
final de cada marco do projeto.
✓ O relacionamento com subcontratados é controlado e gerenciado.
Engenharia de Software25
CMMI-DEV
➢ Nível 3: Definido
✓ Um processo de software, composto por atividades de gerência e
engenharia, é documentado, padronizado e integrado em um
processo de software padrão de toda a organização.
✓ Todos os projetos utilizam uma versão aprovada e adaptada do
processo organizacional para desenvolvimento e manutenção de
software.
✓ A organização interna das tarefas está definida e visível.
entrada saída
Engenharia de Software26
CMMI-DEV
➢ Nível 3: Definido
✓ Processos utilizados são estabelecidos e padronizados em toda a
organização.
✓ Os processos pertencem à organização e não aos projetos.
✓ O Grupo de Processos (Software Engineering Process Group -
SEPG) é responsável pelos processos da organização.
✓ Apesar da padronização, é possível adaptar os processos para as
necessidades particulares de um projeto.
✓ Processos de engenharia de software são considerados juntamente
com os processos gerenciais.
✓ Há treinamento técnico e gerencial.
✓ Como o processo é bem definido, caso um desenvolvedor
abandone o projeto antes de seu término, o impacto é
relativamente menor que nos níveis anteriores.
Engenharia de Software27
CMMI-DEV
➢ Nível 4: Gerenciado Quantitativamente
✓ Métricas detalhadas do processo de software e da qualidade do
produto são coletadas.
✓ Tanto o processo como o produto de software são
quantitativamente analisados e controlados.
entrada saída
Engenharia de Software28
CMMI-DEV
➢ Nível 4: Gerenciado Quantitativamente
✓ A organização estabelece metas quantitativas de qualidade e
produtividade para as atividades do processo e para os produtos
produzidos.
✓ Medidas de qualidade e produtividade são coletadas em todos os
projetos como parte de um processo organizacional de medição e
estabelecem uma base quantitativa para que os gerentes possam
avaliar o progresso do desenvolvimento e a ocorrência de
problemas.
✓ Os projetos melhoram o seu controle sobre os produtos e
processos e a variância das medidas é diminuída.
✓ É estabelecido o controle estatístico de processos.
✓ Uma organização no nível 4 passa a ter uma gestão feita com
bases quantitativas.
Engenharia de Software29
CMMI-DEV
➢ Nível 5: Otimizado
✓ A melhoria contínua do processo é estabelecida por meio de sua
avaliação quantitativa e da implantação planejada e controlada de
novas tecnologias e inovações.
entrada saída
Engenharia de Software30
CMMI-DEV
➢ Nível 5: Otimizado
✓ A organização está engajada na melhoria contínua de seus
processos, possuindo meios para identificar fraquezas e fortalecer
o processo de forma pró-ativa, prevenindo defeitos.
✓ O entendimento do processo ultrapassa os processos praticados,
possibilitando compreender os efeitos de alterações potenciais no
processo.
✓ Melhorias em processos e tecnologias são planejadas e executadas
como parte das atividades de rotina.
✓ Mudanças mais significativas de processos ou de tecnologias são
feitas a partir de análises de custo/benefício com base em dados
quantitativos cuja coleta iniciou-se no nível 4.
Engenharia de Software31
MPS.BR
➢ A implantação dos níveis do CMMI e a avaliação das empresas nesse
modelo tem um alto custo (consultoria, treinamento, avaliação, etc.)
➢ Para empresas de pequeno e médio esse custo é proibitivo.
➢ Pensando nisso, foi definido um modelo de Melhoria de Processo de
Software Brasileiro (MPS.BR), lançado em 2003.
➢ Esse modelo é atualmente desenvolvido pela Softex, interagindo com
universidades e com o Governo Federal.
➢ Uma das principais vantagens do modelo é seu custo reduzido de
certificação em relação às normas estrangeiras, sendo ideal para
micro, pequenas e médias empresas de TI que são a grande maioria
no Brasil.
Engenharia de Software32
➢ Desenvolvimento do MPS.BR:
MPS.BR
Engenharia de Software33
➢ O MPS.BR é compatível com o CMMI, mas utiliza 7 níveis de
maturidade:
MPS.BR
Engenharia de Software34
➢ Níveis de maturidade:
MPS.BR