No capítulo anterior vimos que Firesmith comenta que as atividades de V&V são tipicamente executadas usando técnicas de análise, demonstração, insp...

No capítulo anterior vimos que Firesmith comenta que as atividades de V&V são tipicamente executadas usando técnicas de análise, demonstração, inspeção e teste. Podemos dizer que a análise e inspeção são técnicas essencialmente estáticas e que demonstração e teste são técnicas dinâmicas. Recapitulando o que vimos no capítulo anterior, a análise no contexto de V&V aplica técnicas ou modelos matemáticos, algoritmos de simulações ou procedimentos científicos para determinar se algum produto ou artefato está em conformidade com seus requisitos. Sendo assim, pode-se abstrair que esse tipo de atividade é aplicado em sistemas críticos, nos quais há um alto risco em testar o que foi desenvolvido, por exemplo, sistemas no ramo espacial, aéreo, químico etc. As demonstrações (comumente chamadas de demos) são execuções do produto para que o cliente, ou alguém nesse papel faça a aprovação e dê um feedback sobre o que foi construído. Nesse ponto, para otimizar recursos, o ideal é que o produto desenvolvido esteja o mais próximo possível dos requisitos. Com base nisso, podemos constatar que para que o produto em desenvolvimento esteja em conformidade com os requisitos, é importante que esses requisitos estejam adequados. Mesmo porquê, se pensarmos na atividade de teste, vimos no capítulo anterior que essa atividade também depende dos requisitos. Por requisitos de software, no nosso contexto, podemos entender que é qualquer documento que especifica as funcionalidades do software – pode ser o documento textual, pode ser um diagrama de caso de uso, diagrama de atividades, fluxogramas... enfim, qualquer artefato que registre e especifique com qualidade o que deve ser desenvolvido. Tendo isso em mente, você pode se perguntar: “Professor, se vimos que o teste é uma forma de encontrar defeitos... e se pensarmos que algum problema nos requisitos vai impactar nos testes que serão criados desde o começo, mas executados apenas no final de um ciclo, o ideal seria testar os requisitos para que possamos identificar os problemas existentes. Tem como fazer isso, mesmo sabendo que os requisitos não são executáveis?” Primeiro, é bom lembrarmos que alguns requisitos são executáveis, como por exemplo, aqueles especificados por meio de máquina de estado. No entanto, isso se aplica a sistemas muito específicos. Na grande maioria dos sistemas os requisitos não são executáveis e uma forma de garantir a qualidade deles é por meio de atividades V&V de inspeção, como revisões técnicas formais. Desde já é importante destacar que revisões técnicas não são exclusividade de requisitos – essas atividades podem ser aplicadas em todos os artefatos produzidos durante o ciclo de vida de um sistema, incluindo código-fonte. As revisões técnicas formais, de acordo com Pressman, podem ser vistas como um filtro para o processo de engenharia de software, afinal, ao revisar um artefato, ou seja, uma representação do software, seja ela visual ou textual, e corrigir possíveis defeitos, o próximo artefato e ser construído tendo o artefato revisado como base não irá propagar esse defeito. Os objetivos de uma revisão técnica formal, conhecida pelo acrônimo RTF, são: identificar defeitos na implementação, na lógica ou em qualquer outra forma de representação do sistema; verificar se o software satisfaz seus requisitos; garantir se padrões definidos para o time ou convenções da comunidade estão sendo seguidos nas diversas formas de representação do software; permitir que o software seja desenvolvido de forma uniforme, sem mudanças drásticas no meio do caminho; facilitar a administração/gerenciamento dos projetos; disseminar conhecimento para novos engenheiros de software. Uma RTF pode ser considerada com uma classe (um conjunto) de diferentes formas de revisão, como por exemplo, walkthroughs, inspeções, inspeções circulares entre outras. Uma das atividades mais genéricas e que pode ser adaptada em vários contextos por meio de checklists e técnicas de leitura é a inspeção de software.
Quais são as técnicas de V&V tipicamente executadas?
O que é análise no contexto de V&V?
O que são demonstrações?
Por que é importante que os requisitos estejam adequados?
O que são requisitos de software?
O que são revisões técnicas formais?
Quais são os objetivos de uma revisão técnica formal?
O que é uma RTF?
O que é inspeção de software?