Princípios da Engenharia de Software
Introdução
Desde a sua concepção até a sua entrega para o cliente, um software passa por diversas etapas. A engenharia de software, entre outras coisas, garante a consistência da execução desses passos, aplicando técnicas comprovadamente eficientes em cada uma delas.
De acordo com Fritz Bauer, a engenharia de software é o estabelecimento e a utilização de princípios de engenharia livres de falha com o objetivo de obter softwares que sejam economicamente viáveis e que possam ser executados de forma consistente. O IEEE, Institute of Electrical and Electronics Engineers, resume a aplicação da engenharia ao software como sendo uma abordagem sistemática, disciplinada e quantificada ao seu desenvolvimento, operação e manutenção.
Embora ambas as definições sejam igualmente aceitas como válidas, elas possuem limitações de acordo com Pressman. Bauer, embora tenha sido responsável por nortear quais são os desafios envolvidos na construção de um software, levanta algumas discussões, tais como o que seria um software consistente. Em contrapartida, a segunda definição, dada pelo IEEE, evidencia que as características que fazem do desenvolvimento de software uma engenharia não devem ser abandonadas, mas devem ser adaptáveis e ágeis ao passo que possam ser justificáveis economicamente e facilmente utilizadas por diferentes equipes de desenvolvimento.
Uma vez que sabemos qual é o objetivo da engenharia de software, vamos discutir ao longo desse artigo como atingir esse objetivo, sem deixar de atender as expectativas do cliente. Faremos isso expondo os sete princípios da engenharia de software de David Hooker e discutindo diferentes opiniões sobre cada um deles.
Princípios da engenharia de software
Os princípios da engenharia de software são sete de acordo com o cientista David Hooker. Eles são chamados gerais porque podem ser aplicados a uma única camada da engenharia de software, sua qualidade, processos, métodos ou ferramentas, bem como a ela como um todo.
The reason it all exists
A razão de existir.
Um sistema de software existe por um motivo: agregar valor para seus usuários. Todas as decisões devem ser tomadas com esse princípio em mente. Antes de especificar um requisito de um sistema, antes de indicar alguma parte da funcionalidade de um sistema, antes de determinar as plataformas de hardware ou os processos de desenvolvimento, pergunte a si mesmo: “Isso realmente agrega valor real ao sistema?”. Se a resposta for “não”, não o faça. Todos os demais princípios se apoiam nesse primeiro.
Um software que não oferece valor para o usuário falhou fundamentalmente. De acordo com Hooker, cada decisão durante a construção de um software, que vai desde o primeiro requisito levantado até os processos que levarão ao seu desenvolvimento, deve ser tomada para que a sua existência se justifique no valor que ele representa para quem vai utilizá-lo.
KISS (Keep It Simple, Stupid!)
Não complique!
O projeto de software não é um processo casual. Existem muitos fatores a considerar em qualquer trabalho de projeto. Todo projeto deve ser o mais simples possível, mas não simplista. Esse princípio contribui para um sistema mais fácil de compreender e manter. Isso não significa que características, até mesmo as internas, devem ser descartadas em nome da simplicidade. De fato, os projetos mais elegantes normalmente são os mais simples. Simples também não significa “gambiarra”. Na verdade, muitas vezes são necessárias muitas reflexões e trabalho em várias interações para simplificar. A contrapartida é um software mais fácil de manter e menos propenso a erros.
De acordo com Pressman, o projeto é onde o engenheiro combina os propósitos das pessoas quem deseja o software com a tecnologia necessária para a sua construção, unindo assim dois mundos diferentes. Com isso podemos criar uma representação detalhada da sua arquitetura, estruturas de dados, interfaces, bem como dos demais componentes dos quais depende a sua implementação. Hooker pontua nesse princípio que esse não deve ser um processo guiado pelo acaso.
Nem sempre um projeto de software é sustentado por uma boa relação entre prazo e entrega. Contudo, a qualidade do software não deve ser comprometida pela velocidade de entrega do projeto. É preferível, nesse primeiro momento, aperfeiçoar as ideias em busca de uma solução elegante para o problema a acatar a primeira solução por questões de prazo.
Maintain the Vision
Mantenha a visão.
Uma visão clara é essencial para o sucesso. Sem ela, um projeto se torna ambíguo. Sem uma integridade conceitual, corre-se o risco de transformar o projeto em uma colcha de retalhos de projetos incompatíveis, unidos por parafusos inadequados… Comprometer a visão arquitetural de um sistema de software debilita e até poderá destruir sistemas bem projetados. Ter um arquiteto responsável e capaz de manter a visão clara e de reforçar a adequação ajuda a assegurar o êxito de um projeto
Um software deve manter a sua integridade conceitual, o que exige uma visão clara a seu respeito. Embora esse princípio possa ser compreendido no âmbito do propósito e da funcionalidade de um software, Hooker utiliza um trecho do livro Object-Oriented Analysis and Design with Applications, escrito por Grady Booch, para se referir a sua arquitetura. Nas palavras de Booch, a arquitetura está preocupada não apenas com o comportamento, mas igualmente com a estrutura de um sistema.
De acordo com o IEEE 1471, arquitetura se refere a organização fundamental de um sistema incorporada nos componentes, a forma como eles se relacionam uns com os outros, seu ambiente e aos princípios que guiam sua evolução e modelagem. Um software não pode ser bem sucedido sem possuir uma arquitetura interna bem resolvida. A arquitetura de um sistema não é fundamental para quem vai aprová-lo ou utilizá-lo, mas quando bem definida leva a construção de softwares menores e mais facilmente compreendidos por quem será responsável pela sua codificação, manutenção e expansão.
What You Produce, Others Will Consume
O que um produz outros consomem.
Raramente um sistema de software de qualidade industrial é construído e utilizado de forma isolada. De uma maneira ou de outra, alguém mais vai usar, manter documentar ou, de alguma forma, depender da capacidade de entender seu sistema. Portanto, sempre especifique, projete e implemente ciente de que mais alguém terá de entender o que você está fazendo. O público para qualquer produto de desenvolvimento de software é potencialmente grande. Especifique tendo como objeto os usuários. Projete tendo em mente os implementadores. Codifique se preocupando com aqueles que deverão manter e ampliar o sistema. Alguém terá de depurar o código que você escreveu, e isso o torna um usuário de seu código. Facilitando o trabalho de todas essas pessoas, você agrega mais valor ao sistema.
No processo de construção de um software estão envolvidos diferentes tipos de profissionais. Desde a análise de requisitos até que o software seja implantado no cliente, costumamos passar o bastão diversas vezes. Por exemplo, a documentação gerada pelo programador certamente será utilizada durante a correção de um problema inesperado. Considerando esse cenário, um débito técnico pode adiar a correção de uma falha, o que certamente implicará na baixa percepção de qualidade do sistema por parte do usuário. Manter uma boa relação de trabalho se esmerando em gerar valor para o sistema deve ser uma cultura promovida pelo engenheiro de software, a fim de tornar o trabalho de todos mais fácil, os processos mais estáveis e o cliente sempre satisfeito.
Be Open to the Future
Esteja aberto para o futuro.
Um sistema com tempo de vida mais longo tem mais valor. Nos ambientes computacionais de hoje, em que as especificações mudam de um instante para outro, e as plataformas de hardware se tornam rapidamente obsoletas, a vida de um software, em geral, é medida em meses. Contudo, os verdadeiros sistemas de software com qualidade industrial devem durar muito mais. Para serem bem-sucedidos nisso, esses sistemas precisam estar prontos para se adaptar a essas e outras mudanças. Sistemas que obtêm sucesso são aqueles que foram projetados dessa forma desde seu princípio. Jamais fala projetos limitados. Sempre pergunte “e se” e prepare-se para todas as respostas possíveis, criando sistemas que resolvam o problema geral, não apenas o específico. Isso muito provavelmente consuzira à reutilização de um sistema inteitro.
Investir em software é uma necessidade e um custo a ser evitado pelo cliente sempre que possível. Tecnologia custa caro e uma vez que o cliente decida pela sua aquisição, ela deve se manter sendo utilizada pelo maior tempo possível, a fim de justificar o investimento. Por essa razão, a arquitetura do software deve ser bem pensada com vistas às diversas mudanças que podem ocorrer no contexto no qual ele será utilizado e que podem levar a sua obsolescência. Embora a arquitetura deva ser simples e inteligível, ela também precisa ser flexível a ponto de permitir para o programador escrever todo o código necessário para uma implementação.
Deixar de se perguntar “e se” pode significar se colocar em uma situação contra a parede. Imagine que o cliente está descrevendo como um produto será categorizado, será utilizada mais de uma categoria por produto? A resposta pode ser não no momento, mas e no futuro? Uma determinada rotina de liberação de acesso será sempre dependente de um único formato de arquivo de pagamento, ou o modelo poderá mudar se a empresa decidir trabalhar com uma outra instituição financeira? Às vezes é melhor estar preparado para mudanças e projetar o sistema para lidar com certas problemas de forma menos específica, a fim de facilitar que novas funcionalidades sejam incorporadas pela aplicação.
Para entender melhor o que Hooker quis dizer com esse princípio, ele mesmo sugere conhecer uma prática da eXtreme Programming chamada YAGNI, You aren’t gonna need it, que diz que você deve implementar as coisas que precisa, não as que acredita que um dia vai precisar. Hooker chama a atenção para o fato de que se preparar para o futuro é construir a aplicação para que ela seja facilmente expandida, sem antecipar essa expansão.
Software muda porque mais cedo ou mais tarde uma funcionalidade será adicionada, reescrita ou removida. Por conta disso, muitas soluções surgiram e foram discutidas ao longo dos anos para que esse processo de transformação tenha baixo custo operacional e um menor impacto no sistema como um todo. Na programação orientada a objetos, apenas para citar algum fundamento nesse contexto, temos o SOLID. Dentre os princípios nesse acrônimo está o da responsabilidade única, que nos orienta que uma classe deve ter apenas uma razão para mudar. Com isso, são reduzidas as chances da modificação de uma funcionalidade ter impacto em uma outra. Para uma introdução mais profunda nesse assunto deixo como sugestão o vídeo Os pilares da Programação Orientada a Objetos, no qual discutimos conceitos anteriores ao SOLID, sobre os quais se fundamentam a orientação a objetos.
Plan Ahead for Reuse
Planeje com antecedência, visando a reutilização.
A reutilização economiza tempo e esforço. Alcançar um alto grau de reutilização é indiscutivelmente a meta mais difícil de ser atingida ao se desenvolver um sistema de software. A reutilização de código e projetos tem sido proclamada como uma grande vantagem do uso de tecnologias orientadas a objetos. Contudo, o retorno desse investimento não é automático. Aproveitar as possibilidades de reutilização - oferecidas pela programação orientada a objetos (ou convencional) - exige planejamento e capacidade de fazer previsões. Existem várias técnicas para levar a cabo a realização em cada um dos níveis do processo de desenvolvimento do sistema… Planejar com antecedência para a reutilização reduz o custo e aumento o valor tanto dos componentes reutilizáveis quanto dos sistemas aos quais eles serão incorporados.
Esse pode ser um dos princípios mais controversos de Hooker. Kent Beck citou que grande parte do seu esforço como consultor se concentrava em remover camadas de abstração de projetos a fim de conseguir corrigi-lo. Dave Smith pontua que a reutilização deve vir posterior a utilização e que somente assim o crescimento será orgânico. Contudo, mesmo que seja uma tentação planejar a reutilização antes da utilização, considerando os benefícios dessa decisão, o esforço adicional para isso deve ser ponderado.
Considerando um sistema de pagamento por cartão de crédito, me parece adequado projetá-lo para funcionar com diferentes bandeiras, mesmo que isso signifique criar algumas interfaces e classes adicionais. Contudo, considerando a política de pagamento atualmente utilizada pelo cliente, seria mais adequado discutir o custo de se preparar o sistema para considerar cupons de desconto desde a sua idealização, se isso não é uma necessidade no momento.
Think!
Pense!
Este último princípio é, provavelmente, o mais menosprezado. Pensar bem e de forma clara antes de agir quase sempre produz melhores resultados. Quando se analisa alguma coisa, provavelmente ela sairá correta. Ganha-se também conhecimento de como fazer correto novamente. Se você realmente analisar algo e mesmo assim o fizer da forma errada, isso se tornará uma valiosa experiência. Um efeito colateral da análise é aprender a reconhecer quando não se sabe algo, e até que ponto poderá buscar o conhecimento. Quando a análise clara faz parte de um sistema, seu valor aflora. Aplicar os seis primeiros princípios exige intensa reflexão, para a qual as recompensas em potencial são enormes.
Novamente Hooker se refere a arquitetura para justificar seus pensamentos, enquanto registrava suas discussões sobre o sétimo princípio da engenharia de software em sua wiki. Kent Beck e Brian Schuth, concordam que não vale a pena refletir em um cenário de incerteza e que, nesse caso, o melhor a se fazer é iniciar um ciclo experimentação que favoreça um melhor entendimento do problema. Hooker enxerga um equilíbrio natural entre fazer e pensar e defende que pensar demais não é a solução, mas que simplesmente fazer as coisas por fazer pode levar a uma violação da arquitetura do sistema e condená-lo a deterioração.
Aqui a discussão entra em um novo âmbito que coloca a experimentação como ferramenta para a exploração de novos domínios e tecnologias, não uma regra a ser seguida. Uma vez que se tenha experiência em um dado contexto, a reflexão pode vir antes da experimentação e quando as coisas parecerem obscuras, experimentar pode trazer iluminação.
Conclusão
Os princípios do desenvolvimento de software de Hooker se aplicam às atividades da engenharia de software, assim como proposto por Pressman. A respeito deles, como vimos ao longo do texto, surgiram diversas discussões, sob diferentes pontos de vista. É certo que utilizar esses princípios de forma isolada ou levá-los ao pé da letra não é suficiente para uma perfeita aplicação da engenharia de software. Porém, quando estudados em conjunto com metodologias de desenvolvimento de software, como a eXtreme Programming, ou da análise e desenvolvimento de sistemas orientados a objetos, os princípios de Hooker oferecem um claro panorama de algumas dentre as muitas dificuldades encontradas por engenheiros de software e como resolvê-las sem sacrificar a qualidade do sistema.
