160 likes | 327 Views
Cleanroom Trabalho realizado por: Daniel Franco n.º 3391 Vitor Guilherme Vicente n.º 3997 Beja, Instituto Superior de Tecnologia e Gestão 28-11-2005. Tópicos. O que é o Cleanroom? Método de Cleanroom Cleanroom e o CMM ( Capability Maturity Model ) Case Studies
E N D
Cleanroom Trabalho realizado por: Daniel Franco n.º 3391 Vitor Guilherme Vicente n.º 3997 Beja, Instituto Superior de Tecnologia e Gestão 28-11-2005
Tópicos • O que é o Cleanroom? • Método de Cleanroom • Cleanroom e o CMM ( Capability Maturity Model ) • Case Studies • Object Oriented Software Enginnering and Cleanroom • Mudar a organização • Mitos e realidades em volta do Cleanroom • Críticas • Sumário e revisão do Cleanroom SE
O que é o Cleanroom? • O Cleanroom combina métodos formais de requisitos e desenho com uso no teste estatístico para produzir software com quase ou nenhum defeito. • O desenvolvimento de software segue alguns modelos: • Um modelo muito mau mas muito comum é o “code fix” ou o “Design at the Keyboard”. • Isto faz com que o programador descubra o que um programa tem de fazer, tem de algoritmos, tem de criar dados e tem de escrever o código, tudo ao mesmo tempo. Uma série de trabalhos, tudo a ser desenvolvido ao mesmo tempo. É muito complicado.
Passos para o Método Cleanroom • Alguns dos processos que constituiem o Cleanroom são: • Análise de Requisitos: Produzindo e revendo especificações informais. • Desenho de alto nível: Convertendo o requisito em máquinas de estado e funções • Desenho detalhado: Refinamento das funções • Codificação por incremento: Desenvolver código e verificar o mesmo usando métodos informais. Compilar código ou efectuar teste às unidades é proibido. • Pré-teste: por incremento: Geração de casos de teste. • Teste estatístico por incremento: O código é compilado, linkado e testado. Os resultados são validados.
Cleanroom e o CMM (Capability Maturity Model ) • O modelo CMM descreve a organização dos processos de software desde caótico, ad hoc ao disciplinado. Acontece também para processos já em elevada fase de desenvolvimento. • Existem 5 níveis no CMM. • Os níveis de maturidade são definidos no KPA ( Key Process Area). • O cleanroom tem como intuito a aplicação de disciplina ao software desenvolvido e é complementar ao CMM. • Para cada nível CMM, as KPA’s são revistas para o processo Cleanroom correspondente.
Cleanroom e o CMM (Capability Maturity Model ) Nível 1: Nenhum! (Não existem processos para o Cleanroom e Ad hoc) Nível 2: Todas as KPA’s. Tem alta correspondência mas é assegurada a qualidade do software. Nível 3: Todas as KPA’s. Alta correspondência Nível 4: Todas as KPA’s. Alta correspondência Nível 5: Todas as KPA’s. Alta correspondência; Mas KPA de “Mudança de Tecnologia”.
Case Studies • O Cleanroom SE(Software Engeneering) não tem uma longa história de uso como outros modelos têm. No entanto existem vários projectos que reportaram a sua experiência com o CSE. • Um exemplo é o STARS que é um programa usado pelo Departamento da Defesa dos Estados Unidos de pesquisa e desenvolvimento fundado pela ARPA ( Advanced Research Projects Agency ) • Determinaram que a filosofia de gestão de qualidade ( pôr decisões nas mãos dos trabalhadores, focando assim os processos, medidas quantitativas ) são criticas e que o Cleanroom SE segue essa filosofia.
Object Oriented Software Enginnering and Cleanroom • No Cleanroom, o uso de objectos é o principal objectivo. • Todos os Objectos têm uma especificação que começa com a “black-box view” ( abstracção de comportamentos) • A Black-box contém: • Abstracção de processos ( abstracção de procedimentos). • Abstracção de dados. • Um objecto encapsulado não é como um processo. Contém dados ou estados históricos do objecto. Isto faz com que a função de especificação se torne mais difícil, mas pode ser tratada como uma “história estimulante” ( tal como adicionar itens a uma base de dados).
Mudar a Organização • Por que razão haveria a organização de adoptar a abordagem do Cleanroom quando com o mesmo trabalho poderiam usar a sua estratégia de SE? • Os métodos tradicionais de desenvolvimento de software são já tão usuais em tanto software desenvolvido nas organizações – que o processo de descobrir bug’s nas aplicações já é visto como normal • A organização que pretende adoptar o Cleanroom tem de estar preparado para uma mudança radical ou como diria o Dr Harlan Mill’s adoptar uma filosofia “sem erros na cultura da empresa”. • Uma vez que o principal objectivo do Cleanroom é prevenir erros, o produto final é um produto praticamente sem erros com um certificado de fiabilidade cientifica. • Isto faz com que baixe o preço de produção e manutenção de um produto produzido em grande escala.
Mitos e Realidades em volta do Cleanroom • Mito: O Cleanroom irá substituir as técnicas SE existentes. • O Cleanroom utiliza muitas das práticas existentes e, ao contrário do que dizem as críticas, não é suposto substituir todas as técnicas existentes do SE. • Mito: O Cleanroom é um conjunto de práticas e princípios ortodoxos. • Não existem princípios e práticas ortodoxas no Cleanroom – Os programadores ajustam o Cleanroom de modo a que sirva para o projecto específico no qual estão a trabalhar no entanto, os princípios fundamentais do Cleanroom mantêm-se iguais seja qual for o projecto.
Mitos e Realidades em volta do Cleanroom • Estes princípios apontam para um número de praticas específicas em que a única regra é que estas praticas fiquem nos limites dos princípios fundamentais. • Adequando o Cleanroom de acordo com a necessidade é vital para o sucesso do projecto.
Criticas • Em 1997, Beizer desafiou algumas das queixas feitas pelos apoiantes do Cleanroom, particularmente com a eliminação da unidade de testes. • Ele chegou à conclusão que era claramente uma contradição “teoria de testes conhecida e o senso comum” e que era impossível encontrar um bug sem compilar código. • Ele indica também que o Cleanroom nunca é medido contra: • Testes feitos por cumprir os objectivos • Testes feitos por engenheiros de software treinados nas técnicas de testes. • Testes realizados por organizações que usam testes de desenho e técnicas de testes automáticas. • Testes de integração.
Criticas • Ele põe algumas dúvidas na veracidade de alguns estudos que avaliaram o Cleanroom, incluindo o Basili e o Green ( 1994), apontando algumas lacunas nesses testes. • Baizer levantou alguns aspectos importantes que não podem ser ignorados e ensina-nos a ter cuidado em adoptar técnicas de engenharia de software que supostamente resolvem problemas maiores.
Sumário de Revisão do Cleanroom • O principal objectivo é a alta qualidade do software através da prevenção de erros. • Os Case Studies mostram que se produz software com um número muito reduzido de erros. Os Case Studies também mostram uma grande produtividade e moral do grupo. • É necessário grandes mudanças na forma de aproximar o software: • Provas de exactidão formal e contagem de erros de compilação como erros são duas formas. • Pode ser adaptado para trabalhar com abordagens de estruturas ou métodos OO, com algumas alterações.
Sumário de Revisão do Cleanroom • Os testes dependem de testes de uso estatístico – Um modelo probabilístico de como é utilizado; – Que produz a certificação de componentes. • É necessário treino e pessoal experiente on-site para ser eficiente ( pelo menos ao inicio). • É uma aproximação rigorosa e formal para a engenharia de software que produz software muito fiável que outros métodos de engenharia de software não conseguem produzir.
Bibliografia • http://www.sei.cmu.edu/str/descriptions/cleanroom.html • http://www.cleansoft.com/ • http://www.uta.edu/cse/levine/fall99/cse5324/cr/clean/page.html