Para quem não conhece o diagrama do V, explico neste capítulo do que se trata. O modelo apresenta o fluxo de atividades de desenvolvimento e verificação. Não considera atividades complementares como CM e auditorias. A parte de cima do modelo apresenta um nível de abstração maior, ou seja, mais conceitos e menos detalhes de implementação, enquanto a parte debaixo mostra detalhes dos componentes de software. A parte de esquerda do diagrama mostra as atividades de desenvolvimento, que começam com a especificação de requisitos e terminam com a implementação do código em um executável. A parte da direita apresenta as atividades de verificação associadas ao seu par do lado esquerdo.
O primeiro nível que aparece normalmente no diagrama na parte superior é o nível do sistema. Ele define como que o sistema onde o software está inserido deve funcionar, considerando inclusive o comportamento de sensores e atuadores no escopo da especificação. Mas como dito anteriormente, este nível não detalha características específicas do software, do hardware ou dos componentes mecânicos, eletro-opticos, etc. Ele apenas descreve requisitos de como o sistema deve se comportar. Este nível ainda não é um nível de software, portanto a sua definição e a sua validação (do lado direito do diagrama do V) são feitas por profissional com a competência no sistema específico.
O nível logo abaixo é dos requisitos de alto nível de software (ou HLR) e sua respectiva verificação. Neste nível o software é tratado separado do sistema onde está inserido, mas ele é descrito como uma caixa-preta, sem detalhes internos. É habitual que os requisitos de alto nível de software especifiquem como os sinais de saída do software se comportam em relação aos sinais de entrada e ao estado interno do software. A verificação de alto nível é feita por testes de integração que avaliam este comportamento e por análises que avaliam a performance (tempo e memória) do software integrado. Estas atividades serão vistas em capítulos apropriados.
Depois de estabelecido este nível, é feito o design do software, com o projeto da arquitetura do software que detalha componentes e suas conexões. Cada um destes componentes são especificados em requisitos de baixo nível (LLR), que definem comportamento das saídas de cada componente com relação às suas entradas, igual o que era feito no HLR, mas agora tendo o componente de software como escopo. Estes componentes serão implementados como funções de código, ou às vezes funções que chamam outras funções em cadeia. A verificação deste nível é feita por testes unitários, que testam cada uma das funções.
A parte de baixo do diagrama, que constitui o vértice do V, é a implementação do código fonte, sua compilação e integração no hardware, feita através do carregamento do software. É feita uma revisão deste código e arquivos gerados durante a compilação usando-se como base os requisitos e a arquitetura.
Em empresas onde o desenvolvimento de software é o foco, costuma haver um processo corporativo que define um padrão de ciclo de vida de software a ser seguido por todos os projetos daquela empresa. O modelo em V serve como base para a definição destes processos, mas pode haver adaptações para o contexto necessário.
Como já foi comentado, é difícil em um projeto real se seguir a sequência estabelecida neste modelo de desenvolvimento, pois atividades costumam se sobrepor de maneira a que resultados de fases posteriores realimentem fases anteriores. Não vale a pena, portanto, estabelecer critérios muito rígidos para a transição de uma fase a outra, o que algumas vezes é imposto por processos de software tradicionais. Na filosofia de métodos ágeis, a prototipação adianta a implementação do código para que com isto se validem conceitos e requisitos. De qualquer forma, mesmo que não se siga linearmente, os conceitos do modelo em V são amplamente usados, sobretudo a sua definição dos níveis de software.
Comentários
Postar um comentário