>
Os engenheiros de sistemas há muito que vêem o V como uma parte fundamental da boa engenharia. Ultimamente, porém, a engenharia de sistemas V tem recebido um mau rap. A nova geração de engenheiros vêem-no como um símbolo de práticas lentas de engenharia em cascata. Eles consideram estas práticas irrelevantes para a velocidade necessária para o desenvolvimento de software.
Os proponentes da engenharia tradicional preferem os métodos V a “ágeis”. Isto é especialmente verdade quando se trata de sistemas críticos.
Quem devemos acreditar?
Bem, se formos honestos, quando o V existe como um passe glorioso para todo um sistema, a nova geração faz um grande ponto. O V pode realmente retardar o bom desenvolvimento de software.
No seu núcleo, o V de Engenharia de Sistemas é uma construção lógica. Ele descreve a descoberta dos requisitos do sistema, dividindo um sistema em partes menores e depois montando e validando essas partes.
Os engenheiros de sistemas aplicam o V em vários contextos. Na maioria das vezes, o V aparece em grandes organizações, tais como o Departamento de Defesa dos EUA. É também proeminente em instituições acadêmicas.
Estes grandes programas ou organizações usam o V como parte do seu processo de execução de alto nível. O fluxo de trabalho geral tem sete fases:
O processo começa no lado esquerdo do V onde (1) os conceitos são gerados. Em seguida, (2) os requisitos para todo o sistema são definidos, decompostos e alocados. Em seguida, (3) os componentes do sistema são projetados em detalhes.
A implementação ocorre na parte inferior do V (4). É aqui que os componentes projetados são criados de acordo com os requisitos anteriores no processo.
Movendo-se para o lado direito do V, esses componentes são (5) integrados juntos no sistema final. O sistema integrado é então verificado para garantir que ele atenda aos requisitos originais e validado para garantir que ele atenda às necessidades do usuário (6). Finalmente, (7) o sistema é entregue e mantido.
Desafios do V
Executar o processo do V revela-se problemático para muitos projetos grandes – especialmente aqueles que incluem software.
Integração
Um grande problema é que a integração ocorre muito tarde no processo de desenvolvimento. Programas que dependem do V esperam até que os componentes de software estejam completos para reduzir o dispendioso retrabalho de integração.
Integração manual de componentes de software leva uma tremenda quantidade de tempo. A realidade que todos nós sabemos que é verdade é que o software nunca é feito. As atividades de integração deixadas até o fim são apressadas para cumprir o cronograma do programa.
No V, os componentes integrados geralmente atendem aos requisitos funcionais, mas muitas vezes não são seguros, seguros ou corretos.
Verificação &Validação
Esperar até que o sistema tenha sido completamente integrado para realizar verificação e validação (V&V) compõe este problema. A implementação de correções causa ondulações em todo o sistema, tornando desafiador e dispendioso abordar problemas que surgem durante V&V.
Programas frequentemente colocam correções ‘a nível de sistema’ em vez de resolver a raiz do problema – uma abordagem band-aid. O risco do software é frequentemente mitigado por práticas como firewalls de nível de sistema e software anti-vírus em vez de abordá-lo em código.
Band-aids diminuem a chance dos usuários encontrarem a falha, mas a falha em si não é corrigida e continua a espreitar no sistema.
Conhecendo o desafio
Os conceitos na Engenharia de Sistemas V não são o problema – é a estrutura do V que não se aplica ao software
Técnicas modernas podem permitir a integração contínua do software, mesmo em grandes programas. O uso de ferramentas e processos que abraçam a integração e verificação precoce não negam os conceitos centrais do V – eles melhoram o V para que ele funcione para o desenvolvimento de software.
O resultado final é um software que é correto na criação, e um sistema que é mais barato, seguro e rápido de entregar.