Produção de Software de Alta Qualidade
Aplicação prática de matemática e estatística para
Cleanroom Software Engineering
Engenharia de Software II,
DSC/UFCG, 2004.2
Patrícia D. L. Machado
14/2/2005
Desenvolvimento Gerenciável
„ Controle sobre o processo – progresso evidente +
garantia de integridade dos artefatos
„ Trabalho em equipe + processos de engenharia
bem definidos
„ Gerenciamento de complexidade, redução de
riscos, eliminação do refazer e satisfação dos
requisitos do negócio dentro de prazos e
orçamentos estabelecidos.
14/2/2005
„
produzir software de alta qualidade
„ Hardware cleanrooms
„ Prevenção de erros x Remoção de erros
„ Design correto + certificação por teste
„ Metas: processo de desenvolvimento gerenciável +
prevenção de erros
1 14/2/2005 2
Desenvolvimento Gerenciável
„ Controle depende da tecnologia empregada pelos
times (Tecnologia e processos adequados)
„ Métodos para especificação e projeto precisos,
verificação de correção, teste e medidas de
qualidade e confiabilidade.
„ Completude e consistência matemática =>
verificação de correção
3 14/2/2005 4
Prevenção de Falhas
„ Falhas têm sido consideradas como inevitáveis !
„ Correção de falhas após o desenvolvimento é uma
atividade institucionalizada e aceita em organizações
=> altos custos de produtividade
„ Os custos tangíveis são maiores do que se consegue
calcular
„ Os custos intangíveis como diminuição da confiança e
lealdade de consumidores são também altíssimos e
difíceis de quantificar.
14/2/2005
Fundamentos (Funções)
„ Matemática (especificação) e Estatística (teste)
„ Software Ù Funções de domínios de entrada a
domínios de saída
„ Completude – funções são definidas para cada
elemento do domínio
„ Consistência – Cada elemento do domínio deve ser
mapeado a no máximo um elemento na imagem
„ Correção – dada uma especificação correta, a
correção de um projeto pode ser verificada.
14/2/2005
Prevenção de Falhas
„ Grande parte das falhas são evitáveis
„ São conseqüência de práticas de especificação e
projetos não efetivas que permitem a introdução e
disseminação de falhas, bem como práticas de teste
ineficientes.
„ Práticas rigorosas de especificação, projeto e
verificação + práticas de teste => ausência de falhas
„ Com isso: melhor gerenciamento e redução de custos
para correção de defeitos
5 14/2/2005 6
Fundamentos (Estatística)
„ Métodos de teste são baseados em estatística já
extensivamente aplicados com sucesso.
„ Em software, estatística é usada a partir da seleção
de conjuntos finitos de cenários de uso.
„ Obter inferências válidas para o conjunto completo de
cenários.
„ Cleanroom é baseado em um método interativo e
incremental que permite melhorias em medidas e
seleção de conjuntos de teste
7 14/2/2005 8
Fundamentos (Trabalho em Equipe) Tecnologias

„ Especificação, Desenvolvimento e Certificação „ Desenvolvimento incremental sob controle

„ 3 a 8 pessoas estatístico de processos
„ Quantidade de equipes varia com o tamanho de „ Especificações, Projeto e Verificação
projetos
baseados em métodos precisos
„ Revisões são cruciais:
„ Teste Estatístico e Certificação de Software
‰ Revisões de desenvolvimento (idéias, estratégias, etc)
‰ Revisões de verificação (correção, completude, etc)

14/2/2005 9 14/2/2005 10

Desenvolvimento Incremental Gerenciamento

„ Iteração controlada O principal enfoque do gerenciamento de

„ Pequenos passos de desenvolvimento
acumulativos
„ O produto sendo desenvolvido pode ser
mostrado ao cliente em passos sucessivos
projetos de software são as pessoas
envolvidas.
Gerentes devem portanto compreender melhor
fatores do comportamento humano a fim de
não requisitar tarefas impossíveis ou
inviáveis.

14/2/2005 11 14/2/2005 12
Gerenciamento Gerenciamento

Fatores que podem ser usados na seleção de Equipes de desenvolvimento de software

pessoal incluem experiência no domínio de devem ser pequenas e coesas.
aplicação, adaptabilidade e capacidade de Devem ser coordenadas de forma efetiva.
trabalhar em equipe.

14/2/2005 13 14/2/2005 14

Gerenciamento Regras para Trabalho em Equipe

Comunicações dentro de uma equipe são „ Assumir a personalidade do grupo

influenciadas por fatores como status dos „ Respeite os membros:
membros, tamanho da equipe, composição ‰ Escute seus pontos de vista e tente entendê-los;
sexual, personalidades e canais de ‰ Seja construtivo em seus comentários;
comunicação. ‰ Mantenha confidencialidade em nome do grupo.

14/2/2005 15 14/2/2005 16
Técnicas para Trabalho em Equipe Definição de Processo
„ A falta de planejamento contribui significativamente para o fracasso de
„ Brainstorming projetos.
É necessário ter conhecimento prévio do escopo das atividades a
„ Feedback „
serem executadas:
‰ Dar: Construtivo, objetivo, balanceado, no tempo ‰ Quais os métodos/técnicas/processos a serem seguidos? Qual o esforço
estimado para cada um? E o esforço total?
certo ‰ Quais os ganhos a serem obtidos com cada um? Este ganho é realmente
significativo para o projeto em questão?
‰ Receber: Escute, não se defenda, não acuse, não ‰ Quais os recursos disponíveis (tempo?, recursos humanos e tecnológicos?)
ataque, esclareça, aceite o presente, reflita O esforço necessário poderá ser cumprido?
‰ Como concluir que uma atividade foi satisfatoriamente desenvolvida? Quais
as métricas e padrão de qualidade a ser adotado?
‰ Como avaliar a qualidade dos produtos finais?
‰ Como avaliar a performance do processo com vistas a implantação de
melhorias? Que métricas aplicar, dentro do escopo objetivos de qualidade X
recursos disponíveis?

14/2/2005 17 14/2/2005 18

Definição de Processo: Formato de Definição de Processo: Formato de

Definição de Cada Fase
„ Objetivos – Resultados obtidos quando a performance for
efetiva
„ Entrada – Critérios de entrada que devem ser satisfeitos para
que a fase seja iniciada
„ Tarefas – Atividades a serem executadas na fase, sua ordem e
papéis.
„ Verificação – Passos para verificar se a atividade está sendo
bem desempenhada e se os produtos desenvolvidos estão
obtendo a qualidade desejada.
Definição de Cada Fase
„ Métricas – Para avaliar a performance do processo e
características dos produtos sendo gerados nesta fase.
„ Saída – Critério de saída que deve ser estabelecido para definir
quando a atividade deve acabar. Normalmente envolve
completude e verificação de produtos, mas também pode ser
expressa por meio de valores quantitativos ou qualitativos sobre
os produtos.

14/2/2005 19 14/2/2005 20
Análise de Requisitos
„ Objetivos – Descobrir e documentar as
características do sistema a ser desenvolvido em
consulta e em acordo com clientes e potenciais
usuários.
„ Critérios de Entrada – Definição preliminar do
sistema e documentos que apresentem a descrição
de processos manuais ou sistemas equivalentes.
14/2/2005 21
Análise de Requisitos
„ Verificação – Revisões em equipe após a realização de cada
tarefa.
„ Métricas – Tempo gasto por papel e taxa de defeitos detectados
nas revisões
„ Saída – Uma enumeração das principais características do
sistema deverá ser produzida e validada junto ao cliente.
14/2/2005 23
Análise de Requisitos
„ Tarefas – As principais tarefas desta fase são:
‰ Identificação dos Requisitos – Entrevistas, Investigação de
Recursos etc.
‰ Documentação dos Requisitos – Enumeração das características
do sistema.
‰ Validação dos Requisitos – Revisões com cliente.
As atividades devem ser realizadas nesta seqüência, sendo
previstos retornos eventuais.
Os principais papéis são: identificador de recursos, entrevistador,
especificador, solucionador de conflitos ou elucitador.
14/2/2005 22
Definição da Arquitetura do Sistema
„ Objetivos – Esboço preliminar da estrutura do
sistema em termos de hardware e software que
permita identificar suas fronteiras, estímulos de
entrada e saída.
„ Entrada – Documento de Requisitos do Sistema
14/2/2005 24
Definição da Arquitetura do Sistema Definição da Arquitetura do Sistema

„ Tarefas – „ Verificação – Revisões em equipe após a

‰ Elaboração de um modelo preliminar da estrutura do
sistema
‰ Identificação de fronteiras e comunicação com sistemas
externos
‰ Enumeração de estímulos de entrada e respostas geradas
pelo sistema.
As tarefas podem ser executadas em paralelo.
Principais papéis: projetista de arquitetura, analista e
especificador.
realização de cada tarefa.
„ Métricas – Tempo gasto por papel e taxa de
defeitos detectados nas revisões
„ Saída –
‰ Modelo gráfico validado com o cliente.
‰ Relação de estímulos de entrada e principais saídas
produzidas
‰ Dependências, principais características e restrições na
comunicação com sistemas externos

14/2/2005 25 14/2/2005 26

Referências

„ Stacy J. Prowell, Carmen J. Trammell, Richard C.

Linger and Jesse H. Poore. Cleanroom Software
Engineering - Technology and Process. The SEI
Series in Software Engineering. Addison-Wesley,
1999. (Cap 1)
„ http://www.embedded.com/97/feat9609.htm (Introdução)
„ http://www.rspa.com/spi/cleanroom.html
„ http://www.dacs.dtic.mil/databases/url/key.hts?keycode=64

14/2/2005 27