14/2/2005 1

Cleanroom Software Engineering

Engenharia de Software II, DSC/UFCG, 2004.2Patrícia D. L. Machado

14/2/2005 2

Produção de Software de Alta Qualidade

Aplicação prática de matemática e estatística para 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

14/2/2005 3

Desenvolvimento Gerenciável

Controle sobre o processo – progresso evidente + garantia de integridade dos artefatosTrabalho em equipe + processos de engenharia bem definidosGerenciamento 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 4

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

14/2/2005 5

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 produtividadeOs custos tangíveis são maiores do que se consegue calcularOs 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 6

Prevenção de Falhas

Grande parte das falhas são evitáveisSã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 falhasCom isso: melhor gerenciamento e redução de custos para correção de defeitos

14/2/2005 7

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 8

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

14/2/2005 9

Fundamentos (Trabalho em Equipe)

Especificação, Desenvolvimento e Certificação

3 a 8 pessoas

Quantidade de equipes varia com o tamanho de projetos

Revisões são cruciais:Revisões de desenvolvimento (idéias, estratégias, etc)

Revisões de verificação (correção, completude, etc)

14/2/2005 10

Tecnologias

Desenvolvimento incremental sob controle estatístico de processos

Especificações, Projeto e Verificação baseados em métodos precisos

Teste Estatístico e Certificação de Software

14/2/2005 11

Desenvolvimento Incremental

Iteração controladaPequenos passos de desenvolvimento acumulativosO produto sendo desenvolvido pode ser mostrado ao cliente em passos sucessivos

14/2/2005 12

Gerenciamento

O principal enfoque do gerenciamento de 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 13

Gerenciamento

Fatores que podem ser usados na seleção de pessoal incluem experiência no domínio de aplicação, adaptabilidade e capacidade de

trabalhar em equipe.

14/2/2005 14

Gerenciamento

Equipes de desenvolvimento de software devem ser pequenas e coesas.

Devem ser coordenadas de forma efetiva.

14/2/2005 15

Gerenciamento

Comunicações dentro de uma equipe são influenciadas por fatores como status dos

membros, tamanho da equipe, composição sexual, personalidades e canais de

comunicação.

14/2/2005 16

Regras para Trabalho em Equipe

Assumir a personalidade do grupoRespeite os membros:

Escute seus pontos de vista e tente entendê-los;Seja construtivo em seus comentários;Mantenha confidencialidade em nome do grupo.

14/2/2005 17

Técnicas para Trabalho em Equipe

BrainstormingFeedback

Dar: Construtivo, objetivo, balanceado, no tempo certoReceber: Escute, não se defenda, não acuse, não ataque, esclareça, aceite o presente, reflita

14/2/2005 18

Definição de Processo

A falta de planejamento contribui significativamente para o fracasso de projetos.É necessário ter conhecimento prévio do escopo das atividades a serem executadas:

Quais os métodos/técnicas/processos a serem seguidos? Qual o esforço estimado para cada um? E o esforço total?Quais os ganhos a serem obtidos com cada um? Este ganho é realmente significativo para o projeto em questão?Quais os recursos disponíveis (tempo?, recursos humanos e tecnológicos?) 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 19

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.

14/2/2005 20

Definição de Processo: Formato de 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 sobreos produtos.

14/2/2005 21

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 22

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 23

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 24

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 25

Definição da Arquitetura do Sistema

Tarefas –Elaboração de um modelo preliminar da estrutura do sistemaIdentificação de fronteiras e comunicação com sistemas externosEnumeraçã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.

14/2/2005 26

Definição da Arquitetura do Sistema

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õesSaída –

Modelo gráfico validado com o cliente. Relação de estímulos de entrada e principais saídas produzidasDependências, principais características e restrições na comunicação com sistemas externos

14/2/2005 27

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