Quais são os principais desafios no desenvolvimento de software e como a engenharia de software busca resolver estes desafios?

Por que eu devo ler este artigo:Os sete princ�pios de David Hooker, que s�o apresentados neste artigo, nos ensinam a tomar decis�es durante a elabora��o do projeto de software que aumentem a percep��o de valor por parte do cliente, mantendo a arquitetura do sistema consistente e livre de imperfei��es.

Princ�pios da Engenharia de Software

• Introdu��o
• Princ�pios da engenharia de software
• Conclus�o

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.

Confira outros conte�dos: