Engenharia de Software I Processo Sala Limpa Mirian Ellen de Freitas Sandro Danilo Gatti Set/2004

Roteiro Introdução Diferenças entre métodos convencionais Por não ganhou ampla utilização Fases do processo Gerenciamento do projeto Controle de qualidade Manutenção Conclusões

Introdução Proposto nos anos 1980 por Mill, Dyer e Linger Baseado em matemática Orientado a equipes Voltado ao desenvolvimento e certificação de software de alta confiabilidade O nome Sala Limpa deriva das Cleanroom do desenvolvimento de hardware, onde se enfatiza a disciplina rigorosa em engenharia e foco na prevenção de defeitos, ao invés da remoção de defeitos [SEI,PRE]. Este processo pode ser empregado em sistemas novos ou legados, embarcados ou sistemas grandes e complexos, uma vez que é independente de linguagem, de ambiente, suporta prototipação, orientação a objetos e permite reuso através da definição de serviços e semântica funcional de componentes comuns, além da certificação da confiabilidade do componente [SEI]. Aliás, a orientação objeto é citada explicitamente como uma tecnologia complementar [SEI2].

Introdução (cont.) Especificação Formal. Ciclo de vida incremental de desenvolvimento. Programação estruturada. Verificação de qualidade de produto através de testes estatísticos independentes. Construção de um sistema de software que exiba zero falhas durante seu uso. Especificação Formal: O software a ser desenvolvido é formalmente especificado. Um modelo de transição de estado, que mostra as respostas do sistemas a estímulos, é utilizado para expressar a especificação. Desenvolvimento incremental: O software é decomposto em incrementos, que são desenvolvidos e validados separadamente utilizando-se o processo Cleanroom.Esse incrementos são especificados como entrada do cliente, em um estágio inicial do processo. Programação estruturada: è utilizado um número limitado de construções abstratas de controle e de dados. O processo de desenvolvimento do programa é um processo de refinamento da especificação, feito passo a passo. Um número limitado de construções é utilizado e a meta é aplicar as transformações com preservação de correção à especificação, a fim de criar o código do programa. Verificação estática: O software desenvolvido é verificado estaticamente utilizando-se rigorosas inspeções de software. Não existe nenhum processo de teste de unidade ou de módulo para os componentes do código. Teste estatístico do sistema: O incremento de software integrado é testado estaticamente para determinar sua confiabilidade. Esses testes estáticos baseiam-se em um perfil operacional que é desenvolvido em paralelo com a especificação do sistema.

Introdução (cont.) Usado em desenvolvimento de software na indústria e em organizações como NASA e DoD, com os seguintes resultados [SEI]: Aumento da qualidade Aumento de produtividade de desenvolvimento Alto ROI (return-on-investment) Aumento da qualidade, com a construção de softwares com muitos poucos erros, sem o aumento do custo de desenvolvimento [PRE,SOM], pois há menos correções de erros, menos testes e menos manutenção; Aumento de produtividade de desenvolvimento (mais linhas de código em menos tempo), com software mais simples e melhor comentado [PRE,SOM]; Alto ROI (return-on-investment), pois os investimentos feitos na implantação do Sala Limpa retornam já nos primeiros projetos, através da redução dos custos de desenvolvimento.

Principais diferenças em relação a outros métodos Segundo Pressman [PRE], o que torna o Sala Limpa diferente de outros métodos é: Uso explícito de controle estatístico de qualidade; Verificação de especificação de projeto usando provas baseadas em matemática; Uso enfático de testes estatísticos para descobrir erros de alto impacto. O desenvolvimento convencional toma os erros como inevitáveis, causando re-trabalho dispendioso e demorado. O Sala Limpa procura eliminar os erros ainda durante o projeto, evitando que eles ocorram. O processo cleanroom é projetado para aceitar uma rigorosa inspeção do programa. Um modelo de sistema baseado em estados é produzido para servir como uma especificação de sistema, e esse modelo é refinado por meio de uma série de diferentes modelos de sistema para um programa executável. A abordagem utilizada para o desenvolvimento tem como base transformações bem definidas, que tentam preservar a exatidão em cada transformação, para uma representação mais detalhada. As inspeções de programa são suplementadas por argumentos matemáticos rigorosos, que demonstram que a saída da transformação é consistente com sua entrada. Os argumentos matemáticos utilizados no processo Cleanroom são mais INEFICIENTES do que provas matemáticas formais!!! As provas formais de que um programa está correto com respeito à sua especificação são bastante dispendiosas de se desenvolver. Elas dependem do uso da semântica formal da linguagem de programação para construir teorias que relacionem o programa com sua especificação formal. As provas matemáticas formais são realizadas através de programas grandes e complexos para provar teoremas. Em razão do alto custo e das habilidades específicas necessárias, as provas formais só são realizadas para aplicações especiais com segurança e proteção fundamentais.

Porque ainda não ganhou ampla utilização Crença de que é uma metodologia muito teórica, matemática e radical para o desenvolvimento de software; A substituição de testes unitários por verificação de correção e controle estatístico de qualidade é muito diferente do método costumeiramente empregado pelos desenvolvedores de software; A indústria de software ainda não possui um nível de maturidade ideal para aplicar o processo Sala Limpa. Estas opiniões estão expostas em Pressman [PRE], citando Henderson. Segundo exposto em [SEI2], CMM e Sala Limpa são tecnologias complementares.

Fases do Processo O processo Sala Limpa é composto por 4 grandes processos (funções), cada qual com suas fases: Cleanroom Management Processes Cleanroom Specification Processes Cleanroom Development Processes Cleanroom Certification Processes Cada fase gera um ou mais produtos, em geral documentos e especificações.

Cleanroom Management Processes Processo Produtos Project Planning Process Cleanroom Engineering Guide Software Development Plan Project Management Process Project Record Performance Improvement Process Performance Improvement Plan Engineering Change Process Engineering Change Log Estes quatro processos afetam todo o ciclo de desenvolvimento. No Project Planning Process, que pode ser repetidamente invocado durante o projeto, a equipe ajusta os processos Sala Limpar ao ambiente do projeto e cria e mantém os planos de desenvolvimento. Este planos são usados no Project Management Process para o gerenciamento e controle do desenvolvimento e certificação incrementais. O Performance Improvement Process é usado para avaliar continuamente o desempenho do projeto ao aplicar os processos Sala Limpa, além de identificar e implementar melhorias. O Engineering Change Process fornece a disciplina de gerenciamento e configuração necessáriaa para todas as atividades.

Cleanroom Specification Processes Processo Produtos Requirements Analysis Process Software Requirements Function Specification Process Function Specification Usage Specification Process Usage Specification Architecture Specification Process Software Architecture Increment Planning Process Increment Construction Plan O Architecture Specification Process abrange o ciclo de vida inteiro, analisando e definindo estruturas arquiteturais e estratégias de desenvolvimento de software em múltiplos níveis de abstração. O Requirements Analysis Process é empregado na criação de uma definição inicial das necessidades dos clientes. Esta definição é expressa em termos precisos durante o Function Specification Process, quando se produz uma especificação do comportamento externos, e o Usage Specification Process produz uma especificação dos usuários, ambientes de uso e modelos de uso do software. O Increment Planning Process aloca as funções especificadas do software em um conjunto de incrementos e gera seu cronograma de desenvolvimento e certificação dentro da estrutura do projeto como um todo. Antes do desenvolvimento e certificação de cada incremento, a análise e especificação devem ser revisadas para validar os requisitos e incorporar feedback das avaliações dos clientes.

Cleanroom Development Processes Processo Produtos Software Reengineering Process Reengineering Plan Reengineered Software Increment Design Process Increment Design Correctness Verification Process Increment Verification Report Estes 3 processos são repetidos no desenvolvimento de cada incremento. O Software Reengineering Process prepara o software existente para uso em um incremento enquanto o Increment Design e Correctness Verification Processes são empregados no desenvolvimento detalhado do projeto e código de um incremento e para verificar sua correção.

Cleanroom Certification Processes Processo Produtos Usage Modeling and Test Planning Process Usage Models Increment Test Plan Statistical Test Cases Statistical Testing and Certification Process Executable System Statistical Testing Report Increment Certification Report Estes processos também são repetidos a cada incremento. O Usage Modeling and Test Planning Process é empregado na criação dos modelos de uso necessários e nos planos de teste. O Statistical Testing and Certification Process é empregado para testar um incremento usando os casos de teste gerados a partir dos modelos de uso e para avaliar a adequação de um incremento para uso, nos termos de medidas estatísticas. Os incrementos certificados são entregues aos clientes para avaliação e validação de requisitos.

Fluxo entre os processos [SEI]

Modelo de Processo Sala Limpa SE RG Incremento 1 Incremento 2 Incremento 3 BSS FD CV CG CI TP SUT C Esta nova forma de visualizar o processo é descrita em [PRE]. É desenvolvido um plano de projeto que adota a estratégia incremental. A funcionalidade de cada incremento, seu tamanho projetado e um cronograma de desenvolvimento sala limpa são criados. Cuidado especial precisa ser tomado para garantir que incrementos certificados sejam integrados em momento oportuno. -         Coleta de requisitos  RG -         Especificação da estrutura de blocos  BSS : esta fase emprega um método de especificação que faz uso de uma estrutura de blocos na especificação funcional (Function Specification Process), visando “isolar e separa a definição criativa do comportamento, dados e procedimentos, em cada nível”. -         Projeto formal  FD : se usar a abordagem de blocos, é uma extensão natural da especificação. Usa-se o conceito de caixas-pretas, caixas de estados e caixas-brancas. -         Verificação de correção CV : atividades de verificação de correções rigorosas sobre o projeto e subseqüentemente sobre o código. -         Geração de Código, inspeção e verificação CG , CI -         Teste estatístico de uso  SUT : usa-se uma amostra estatística de todas as execuções do programa com base no padrão de uso do software (o que é mais usado é mais testado) -         Certificação  C : depois de completadas as verificações, inspeções e testes de uso, e corrigidos os erros, o incremento é certificado para ser incorporado no software. CG (geração de código) CI (inspeção de código) SUT (teste estatístico de uso) C(certificação) TP (planejamento de Teste) SE (engenharia de sistemas) RG (coleta de requisitos) BSS (especificação de estrutura de blocos) FD (projeto formal) CV (verificação de correção)

Diretrizes para o gerenciamento do projeto Baseado em equipes (de especificação, de desenvolvimento e de certificação), compostas de seis a oito pessoas, trabalhando e forma disciplinada. Em projetos pequenos, os indivíduos podem trabalhar em várias equipes. Em projetos grandes, pode-se obter equipes de equipes. Embora exija muita disciplina, a criatividade não é tolhida e sim incentivada [SEI]. As equipes de equipes podem envolver centenas de pessoas. Neste caso, a estruturas das equipes é constituída de acordo com a evolução e estrutura do software em desenvolvimento. Porém, é necessário treinar as equipe na tecnologia Sala Limpa para poder obter o máximo de produtividade. Equipe de especificação: responsável pelo desenvolvimento e pela manutenção da especificação do sistema. A especificações orientadas ao cliente (definição de requisitos) e as especificações matemáticas para verificação são produzidas por esta equipe. Em alguns casos, quando a especificação está completa, a equipe de especificação assumirá também a responsabilidade pelo desenvolvimento. Equipe de desenvolvimento: Essa equipe tem a responsabilidade de desenvolver e verificar o software. O software não é executado durante o processo de desenvolvimento. É utilizada uma abordagem estruturada e formal para a verificação, baseada na inspeção do código, suplementada com argumentos relativos à precisão. Equipe de certificação: Essa equipe é responsável pelo desenvolvimento de um conjunto de testes estatísticos para testar o software, depois que ele foi desenvolvido. Esses testes são baseados em especificação formal. O desenvolvimento de casos de teste é realizado em paralelo com o desenvolvimento de software. Os casos de teste são utilizados para certificar a confiabilidade do software. Os modelos de aumento de confiabilidade [SOM] - cap 21 podem ser utilizados para decidir quando interromper os testes.

Diretrizes para o gerenciamento do projeto (cont) Cada equipe é composta elementos com papéis de especificação, desenvolvimento, gerenciamento e certificação. O gerente de projeto de software é o responsável pelo processo em geral. Há ainda os papéis engenheiro chefe de especificação (Specification Process) engenheiro chefe de projeto/desenvolvimento Development Process (design) engenheiro chefe de certificação (Certification Process). Há ainda os papeis de engenheiro chefe de especificação (Specification Process), engenheiro chefe de projeto/desenvolvimento Development Process (design) e engenheiro chefe de certificação (Certification Process).

Atividades de controle de qualidade do Processo - CMM Segundo exposto em [SEI2], CMM e Sala Limpa são tecnologias complementares. Podem ser utilizados outros modelos de qualidade, porém não se consegue aplicar o processo com processo de desenvolvimento empírico.

Atividades de controle de configuração A configuração segue os preceitos do cliclo de desenvolvimento incremental. Estabelecer requisitos Formalizar a especificação Desenvolver incremento Entregar o software Especificação Congelada Pedido de mudança de requisitos

Atividades de controle de qualidade do Produto - Certificação Envolve 5 passos: Cenários de uso devem ser criados; Um perfil de uso é especificado; Casos de teste são gerados a partir do perfil; Testes são executados e dados de falhas são registrados e analisados; A confiabilidade é calculada e certificada. Testes A certificação para a engenharia de software sala limpa (quinto passo) exige a criação de três modelos: Modelo de amostragem – O teste de software executa m casos de teste aleatórios e é certificado se nenhuma falha ou número de falhas especificado ocorre.O valor de m é derivado matematicamente para garantir que a confiabilidade desejada é atingida.   Modelo de componentes – Um sistema composto de n componentes deve ser certificado. O modelo de componentes permite o analista determinar a probabilidade de o componente i falhar antes de ser completado. Modelo de certificação – A confiabilidade total do sistema é projetada e certificada. certificação

Atividades de controle de qualidade do Produto - Testes Modelos de uso + probabilidades de ocorrência Casos de teste são gerados aleatoriamente a partir dos modelos de uso. Medidas estatísticas da confiabilidade /fidedignidade (reliability) são computadas baseadas no resultados dos testes. Se uma longa seqüência de testes é conduzida sem falha, o tempo médio de falhas (MTTF) é baixo e a confiabilidade do software pode ser considerada alta. As equipes de certificação criam modelos de uso que definem os cenários de utilização do software, com suas correspondentes probabilidades de ocorrência. Um “customer” (que pode ser um patrocinador interno/externo, um provável usuário ou alguém que esteja apto a definir requisitos e avaliar o sistema) sempre deve fazer parte da equipe testes de da de certificação. Na engenharia de software sala limpa teste de unidade e depuração são substituídos por verificação de correção e teste de baseado em estatística. Essas atividades acopladas com a manutenção de registros necessários para o aperfeiçoamento contínuo tornam a abordagem sala limpa singular

Atividades de controle de qualidade do Produto - Testes Estímulo do Programa Probabilidade Intervalo Armar/Desarmar (AD) 50% 1-49 Ativar zona (ZS) 15% 50-63 Consulta (Q) 15% 64-78 Teste (T) 15% 79-94 Alarme de pânico 5% 95-99 13-94-22-24-45-56  AD-T-AD-AD-AD-ZS 81-19-31-69-45-9  T-AD-AD-Q-AD-AD 38-21-52-84-86-4  AD-AD-ZS-T-T-AD [PRE] Para gerar a seqüência de teste que segue a destituição de probabilidades de uso, uma série de números aleatórios entre 1 e 99 é gerada. A seqüência de teste é gerada aleatoriamente, mas corresponderá à probabilidade adequada à ocorrência do estímulo.

Atividades de controle de qualidade - Certificação Ao final do teste estatístico de uso os registros produzidos são combinados com esses modelos de amostragem, de componentes e de certificação para permitir o cálculo matemático da confiabilidade projetada para o componente de software.

Atividade de manutenção Manutenção da especificação do sistema; Correções realizadas a partir de feeedbak do cliente para equipe de desenvolvimento que solicita nova versão do incremento. Combinação de novos incrementos com os já existentes. Teste de todos os incremento integrado  Teste de regressão do incrementos anteriores. A medida que novos incrementos são desenvolvidos, estes são combinados com os incrementos já existentes e o sistema integrado é novamente testado. Portanto os incrementos existentes são novamente testados sempre que novos incrementos do sistema são adicionados.

Conclusões Abordagem diferentes das convencionais Software com baixo índice de erros Testes estatísticos Diferentes domínios de aplicação Orientado a equipes Metodologia complementar a CMM Pontos vulneráveis da abordagem: Casos de sucesso relatados somente pelos próprios proponentes conforme [PRE] e [SOM]. Necessidade de equipes especializadas e bem treinadas para sua execução.

Referências [PRE] R.S.Pressman. “Software Engineering. A Practitiner’s Approach”. 5ª edição, 2002, cap. 26. [SOM] I. Sommerville. “Software Engineering”. 6ª ed, 2003, cap 19.4 [SEI] Relatório de Referência. http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr022.96.pdf. Acessado em 10/09/2004 [SEI2] http://www.sei.cmu.edu/str/descriptions/cleanroom_body.html. Acessado em 10/09/2004.

Sítios visitados http://www.cleansoft.com. Sítio com vários artigos interessantes . Acessado em 10/09/2004 http://www.rspa.com/spi/-- SITE COM REFERÊNCIAS - Acessado em 12/09/2004. http://www.rspa.com/spi/cleanroom.html -- SITE COM TUTORIAIS http://www.cc.gatech.edu/classes/cs3302_99_summer/slides/cleanroom/ - tutoriais - Acessado em 12/09/2004. http://www.uta.edu/cse/levine/fall99/cse5324/cr/clean/page.html - tutoriais - Acessado em 12/09/2004.