Aula 7_Qualidade_Software

The main ideas from this information are: - The lecture is about software quality, including topics such as contextualization, motivation, objectives, and quality models like CMMI and MPSBR. - The cost of fixing errors increases exponentially as they progress through different phases of development. - The use of a formal technical review (RTF) is more effective in reducing defects compared to testing. - The main objective of RTF is to find errors before they become defects. - The main quality models discussed are CMMI, MPS-BR, and ISO 9126. - The cost of certification for CMMI is high, so there is a Brazilian version called MPS-BR with reduced certification costs. - The RTF can be applied in different phases of the software development lifecycle to detect errors. - The application of RTF significantly reduces the number of errors in each phase. - The chapter 7 of the book "Processando a Informação" discusses the importance of RTF and is recommended Aula 7, qualidade de software. O roteiro desta aula, vamos falar de contextualização, motivação, objetivos, modelos de qualidade que é o CMMI ou C M M I e a versão brasileira que é o MPSBR. Depois vamos falar de custo exponencial para corrigir erros, modelo de aplicação de defeitos, sem o RTF que é a revisão técnica formal e com o RTF que é a revisão técnica formal, referências e atividades em grupo. Então vamos iniciar então esta aula aqui. Contextualização na linha do Rapito. Nós estamos na fase de teste, praticamente final do processo. Aliás o final do processo, a gente falou então de processo, cascata ou RUP, a gerência, cronograma ou entramos no Rapito propriamente dito, que é um requisito, que a gente utilizou o diagrama de fluxo, de fluxo, o diagrama de entidade relacionamento, o IDF0, análise, classes e sequência, o projeto em si que é o mapa de componentes e ERS, implementação que é o I do Rapito, o teste, estratégias de teste, tecnologias técnicas de teste, caixa branca e caixa preta e a operação. Motivação, garantia de qualidade de software, é o Software Quality Assurance, SQA. Uma revisão técnica formal, que é o RTF, é uma atividade do SQA, Software Quality Assurance, garantia de qualidade de software. RTF é um filtro mais efetivo do ponto de vista de garantia de qualidade comparado aos testes. Em média, usar um RTF reduz 75% dos defeitos e cada teste reduz 50% dos erros. Só para contextualizar, algo que deu errado, erro é algo que deu errado durante o ciclo de vida de desenvolvimento e esse erro ele passou para a implantação, então dessa forma ele se tornou um defeito. Continuando, 50 a 65% dos erros encontram-se na fase de projeto e você pode fazer direito ou fazer novamente, que é um jargão. Objetivos, o objetivo principal da RTF é encontrar erros antes que eles sejam passados para outra atividade da engenharia de software. O RTF é uma atividade da garantia de qualidade do software. O objetivo da RTF é achar erros durante o processo de desenvolvimento de modo que eles não se transformem em defeitos depois da entrega do software. Definir um conjunto de atividades como checklists para o sistema de gestão da qualidade em todos os níveis de abstração. Objetivos, garantir a qualidade do software através da definição e normatização de processos de desenvolvimento. Garantir um produto final que satisfaça as expectativas do cliente dentro daquilo que foi acordado inicialmente. A qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento. Principais modelos de qualidade, que é o CMMI e o MPS-BR, que é a versão brasileira, e a ISO 9126. CMMI ou C M M I, maturidade de processo, gerenciado pelo CENEC, que é o Software Engineering Institute, que definiu um metamodelo de processo baseado em um conjunto de capacidades que devem estar presentes na medida que as empresas alcançam diferentes níveis de capacidade e maturidade. O site deles é o www.ce.cmu.edu Os níveis do CMMI, o primeiro é o inicial, que é o ad-hoc, o segundo é o gerenciado, gerido, terceiro definido, quarto quantitativamente gerenciado, gerido quantitativamente e o quinto em otimização. É uma certificação muito cara, por isso existe uma versão brasileira de certificação. A versão brasileira é o MPS-BR. O MPS-BR, ou Melhoria de Processos do Software Brasileiro, é simultaneamente um movimento para a melhoria e um modelo de qualidade de processo, voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil. No Brasil, uma das principais vantagens do modelo é seu custo reduzido de certificação em relação às normas estrangeiras. Os níveis de maturidade do MPS.BR apresenta sete níveis de maturidade, o que é um diferencial em relação aos outros padrões de processo, sendo A, em otimização, B, gerenciado quantitativamente, C, definido, D, largamente definido, E, parcialmente definido, F, gerenciado e G, parcialmente gerenciado. Custo relativo para corrigir um erro. Nós temos aqui uma tabela, que ela começa com um requisito, que é uma vez o custo, em torno de 150 dólares, e você vai para a fase de projeto, se você tiver um erro lá, ele é de três a seis vezes os 150 dólares. Na fase de código, ele é dez vezes o valor dos 150 dólares. O teste da unidade, que é de 15 a 40 vezes os 150 dólares. O teste de sistema, que é de 30 a 70 vezes o valor do custo inicial, e na fase de operação, que é de 40 mil vezes o custo inicial de 150 dólares. Isso aqui pode quebrar uma empresa, conforme explicado pelo professor. Agora, a gente tem um gráfico adaptado, do uso de RTF nos modelos V, adaptado. Então, na fase de teste da unidade, você tem o RTF aplicado ao código. Na fase do projeto, você tem os testes de integração, e ali você tem também o apoio do RTF no projeto. Na fase de análise, o teste de validação, você também tem o RTF atuando, e na última etapa, o requisito, o teste de sistema, você tem o RTF. Então, é isso. Você tem as fases, a esquerda, que é a especificação e o RTF, e a direita é a execução ou validação, que são todos os testes realizados. Na revisão técnica formal, se trata de fazer um checklist para checar todo o artefato produzido, todo o documento gerado para especificar o que será desenvolvido, precisa ser verificado pelo RTF. Modelo de aplicação de defeitos. Isso aqui é a motivação que o livro do Pressman apresenta para utilizar o RTF em todas as fases do ciclo de vida. Então, a gente tem um fluxo, vamos dizer assim, que você tem os erros advindos da fase anterior. Então, ele se classifica em três erros, erros que atravessam, erros que são multiplicados por X, e erros essengerados. Então, você tem depois uma mensuração percentual de eficiência na detecção de erros. Se você não usa o RTF, a porcentagem é zero. Agora, se você usar, você terá 75% de eficiência de eliminar os erros nessa fase. E, por fim, são os erros passados para a próxima fase, que acontecem sempre. Bom, aplicação de defeitos sem o RTF. Então, você tem na fase preliminar do projeto, 0%. Aí, depois, ele passa, de 10, passa a 6, por projeto detalhado. E, você tem quatro erros, dos 10, que são multiplicados por 1,5, que encarece mais, se tornando 25 erros depois. Ou seja, que você, então, junta 37 erros, 10 passa para o código, teste de unidade, 10. E, depois, para a fase de integração, 94 erros são levados. Isso aqui é um exemplo de como funciona esse processo. E, dos 94, 50% fica lá no teste de integração e 50% vai para o teste de validação. Depois, 24 vai para o teste de sistema e, por fim, apenas 12 são erros latentes mesmo. Isso sem o RTF. Agora, com o RTF, diminui muito essa quantidade. Na fase preliminar, você tem apenas lá 10 erros, que dos 10, só 3. De 3, 2 vai para o projeto detalhado. E, que depois, nesse projeto detalhado, se tornam 15 erros. De 15, 5 vai para o código. E, depois que você gera 25 erros no próprio código, 60%, que é 24 erros, vão para a fase de teste de integração. Apenas 12 vai para o teste de validação e 6 vai para o teste de sistema, que se tornam 3 erros latentes no final. Bom, exercício aqui, né? Considere hipoteticamente que, nas mudanças de fase, 50% dos erros atravessam e 50% são multiplicados, onde os fatores de multiplicação são 2, 3 e 4 para análise, projeto e codificação, respectivamente. Considere também que 10 erros novos aparecem em cada fase e os testes detectam, em média, 50% dos erros. Aplica o modelo anterior na figura, né? A seguir, sem e depois com a aplicação do RTF e em cada mudança de fase, para facilitar trabalhar com aproximações, para não manipular decimais, né? Então, a gente tem um fluxograma aqui, em que estão todas as fases, né? Requisito, análise, projeto, código, teste de unidade, teste de integração, teste de validação e teste de sistema. Isso daqui é feito sem o RTF e depois você tem com aplicação com o RTF e a ideia aqui é que você saiba que, com a aplicação do RTF, os erros serão muito, né? diminuídos, na casa de 75%. E, por fim, a revisão do capítulo 7 do livro Processando a Informação, um livro de prático, né? De programação independente de linguagem, que é vendido pela UFABC, né? UFABC, por R$ 40,00. É isso. O professor sugeriu que a gente lesse, então, esse livro aí, mas não vamos pagar. Por fim, a gente finaliza, então, a atividade 7, aliás, a aula 7. Boa sorte na prova, Marcelo.