Produção de Software de Alta Qualidade

Aplicação prática de matemática e estatística para

Cleanroom Software Engineering
„
produzir software de alta qualidade
„ Hardware cleanrooms
„ Prevenção de erros x Remoção de erros
„ Design correto + certificação por teste
Engenharia de Software II,
„ Metas: processo de desenvolvimento gerenciável +
DSC/UFCG, 2004.2 prevenção de erros
Patrícia D. L. Machado

14/2/2005 1 14/2/2005 2

Desenvolvimento Gerenciável Desenvolvimento Gerenciável

„ Controle sobre o processo – progresso evidente + „ Controle depende da tecnologia empregada pelos
garantia de integridade dos artefatos times (Tecnologia e processos adequados)
„ Trabalho em equipe + processos de engenharia „ Métodos para especificação e projeto precisos,
bem definidos verificação de correção, teste e medidas de
„ Gerenciamento de complexidade, redução de qualidade e confiabilidade.
riscos, eliminação do refazer e satisfação dos
requisitos do negócio dentro de prazos e „ Completude e consistência matemática =>
orçamentos estabelecidos. verificação de correção

14/2/2005 3 14/2/2005 4
Prevenção de Falhas Prevenção de Falhas
„ Falhas têm sido consideradas como inevitáveis ! „ Grande parte das falhas são evitáveis
„ Correção de falhas após o desenvolvimento é uma „ São conseqüência de práticas de especificação e
atividade institucionalizada e aceita em organizações projetos não efetivas que permitem a introdução e
=> altos custos de produtividade disseminação de falhas, bem como práticas de teste
ineficientes.
„ Os custos tangíveis são maiores do que se consegue
calcular „ Práticas rigorosas de especificação, projeto e
verificação + práticas de teste => ausência de falhas
„ Os custos intangíveis como diminuição da confiança e
lealdade de consumidores são também altíssimos e „ Com isso: melhor gerenciamento e redução de custos
difíceis de quantificar. para correção de defeitos

14/2/2005 5 14/2/2005 6

Fundamentos (Funções) Fundamentos (Estatística)

„ Matemática (especificação) e Estatística (teste) „ Métodos de teste são baseados em estatística já

„ Software Ù Funções de domínios de entrada a extensivamente aplicados com sucesso.
domínios de saída „ Em software, estatística é usada a partir da seleção
„ Completude – funções são definidas para cada de conjuntos finitos de cenários de uso.
elemento do domínio „ Obter inferências válidas para o conjunto completo de
„ Consistência – Cada elemento do domínio deve ser cenários.
mapeado a no máximo um elemento na imagem „ Cleanroom é baseado em um método interativo e
„ Correção – dada uma especificação correta, a incremental que permite melhorias em medidas e
correção de um projeto pode ser verificada. seleção de conjuntos de teste

14/2/2005 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 projetos de software são as pessoas
acumulativos envolvidas.
„ O produto sendo desenvolvido pode ser Gerentes devem portanto compreender melhor
mostrado ao cliente em passos sucessivos 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 Definição de Cada Fase
„ Objetivos – Resultados obtidos quando a performance for „ Métricas – Para avaliar a performance do processo e
efetiva características dos produtos sendo gerados nesta fase.
„ Entrada – Critérios de entrada que devem ser satisfeitos para „ Saída – Critério de saída que deve ser estabelecido para definir
que a fase seja iniciada quando a atividade deve acabar. Normalmente envolve
„ Tarefas – Atividades a serem executadas na fase, sua ordem e completude e verificação de produtos, mas também pode ser
papéis. expressa por meio de valores quantitativos ou qualitativos sobre
os produtos.
„ Verificação – Passos para verificar se a atividade está sendo
bem desempenhada e se os produtos desenvolvidos estão
obtendo a qualidade desejada.

14/2/2005 19 14/2/2005 20
Análise de Requisitos Análise de Requisitos

„ Objetivos – Descobrir e documentar as „ Tarefas – As principais tarefas desta fase são:

características do sistema a ser desenvolvido em ‰ Identificação dos Requisitos – Entrevistas, Investigação de

Recursos etc.
consulta e em acordo com clientes e potenciais
‰ Documentação dos Requisitos – Enumeração das características
usuários.
do sistema.
„ Critérios de Entrada – Definição preliminar do ‰ Validação dos Requisitos – Revisões com cliente.
sistema e documentos que apresentem a descrição As atividades devem ser realizadas nesta seqüência, sendo
de processos manuais ou sistemas equivalentes. previstos retornos eventuais.
Os principais papéis são: identificador de recursos, entrevistador,
especificador, solucionador de conflitos ou elucitador.

14/2/2005 21 14/2/2005 22

Análise de Requisitos Definição da Arquitetura do Sistema

„ Verificação – Revisões em equipe após a realização de cada „ Objetivos – Esboço preliminar da estrutura do
tarefa.
sistema em termos de hardware e software que
„ Métricas – Tempo gasto por papel e taxa de defeitos detectados permita identificar suas fronteiras, estímulos de
nas revisões
entrada e saída.
„ Saída – Uma enumeração das principais características do
sistema deverá ser produzida e validada junto ao cliente. „ Entrada – Documento de Requisitos do Sistema

14/2/2005 23 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 realização de cada tarefa.
sistema „ Métricas – Tempo gasto por papel e taxa de
‰ Identificação de fronteiras e comunicação com sistemas
defeitos detectados nas revisões
externos
‰ Enumeração de estímulos de entrada e respostas geradas
„ Saída –
pelo sistema. ‰ Modelo gráfico validado com o cliente.
As tarefas podem ser executadas em paralelo. ‰ Relação de estímulos de entrada e principais saídas
Principais papéis: projetista de arquitetura, analista e produzidas
especificador. ‰ 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