quarta-feira, 2 de julho de 2008

O projeto de software está morto?

O artigo de Martin Fowler, “Is design dead?” [1], ele faz uma comparação com relação às vantagens do processo evolutivo, como é o caso de XP (eXtreme Process), e do processo planejado.

As diferenças entre o processo planejado e o processo evolutivo é que no processo evolutivo o design cresce à medida que se codifica, conseqüentemente o design sofre diversas mudanças durante o ciclo do processo de desenvolvimento. O risco deste tipo de design é que se for tomada uma decisão errada no momento de modificar o sistema pode-se gerar bugs e tornar o código mais difícil de ser modificado. Para que este design funcione é necessário que alguém garanta a qualidade do processo, que vigie o código sempre que possível e que os erros sejam corrigidos de imediato.

O processo planejado é diferente, pois tem como base outras engenharias, utiliza a linguagem UML para descrever o design num nível mais abstrato. Um problema deste design é porque não há como prever tudo o que irá acontecer no momento da programação e o custo para modificar um modelo é muito alto e as mudanças são imprescindíveis, já que sempre há mudanças nos requisitos. Um balanço entre os dois processos é necessário, com isso XP possui uma etapa de construção de design mínima antes da primeira construção do código. No processo XP são necessárias práticas de Teste, Integração contínua e Refatoração do código.

A simplicidade é um ponto chave em XP, com isso ele utiliza a técnica YAGNI, que diz que não se deve criar nenhuma funcionalidade hoje que só será necessária amanhã, pois o custo para corrigi-la ou modifica-la depois será altíssimo, principalmente quando não for bem feito. Um design simples é muito mais fácil de entender do que um design complexo, logo fica mais fácil de realizar mudanças.

A curva de mudança do software diz que quanto mais se avança no projeto mais caro será fazer mudanças, no caso do design simples, como fica mais fácil de realizar mudanças a curva de mudanças fica mais plana. Um ponto importante a se preocupar é com a reversibilidade do código, principalmente quando é necessário modificar o código várias vezes.

Em XP o uso de padrões é uma prática comum, pois eles são utilizados no momento de realizar refatoração no código e assim torna-lo mais simples. No entanto, o mau uso dos padrões, podem trazer grandes prejuízos para o projeto. Com relação ao uso de diagramas UML, em XP isso não é normal, mas pode acontecer de se usar diagramas desde que ele seja útil. Uma maneira de usar UML é não detalhar muito os modelos.

No design evolutivo só tem uma forma de saber se o design está acontecendo, que é analisando a qualidade do código. Uma forma de detectar se a qualidade está boa é verificando se a equipe se queixa do código ao tentar modifica-lo.

Fowler não afirma que o design planejado seja pior que evolutivo, mas concorda que ambos possuem seus problemas e ele está buscando um design ideal. Além disso, segundo o autor, XP nos dá uma nova forma de pensar sobre o design planejado, pois tem feito do design evolutivo uma estratégia plausível.

Opinião:

Eu acho que o design não está morto, pois se levarmos em consideração que nem sempre é possível utilizar processos ágeis, como XP, em projetos grandes, onde os programadores não têm contato direto com o cliente e a equipe de análise está distante da equipe de programação, então o design é necessário, pois será possível definir em um nível mais alto as especificações do sistema.

Acho que XP é um tipo de processo muito interessante e que quando é possível aplica-lo em um projeto deve ser aplicado, pois deixa o processo bem mais simples e viável. Com ele a qualidade do código fica melhor e quando ele é feito baseado em testes automático, facilita a refatoraração. O processo evolutivo deve ser utilizado em projetos que precisam ser atualizados constantemente, pois o custo da mudança não é tão alto quanto em processos planejados.

No entanto, existem problemas tanto com o processo planejado quanto no processo evolutivo. Pois, para o processo planejado ser bem sucedido seria necessário que fosse produzido um design muito bem elaborado, mas nem sempre isso é possível.

Referências:

  1. Fowler, Martin. Is design dead? (2000) http://martinfowler.com/articles/designDead.html, Acesso: Mar/2008.
  2. FOWLER, Martin. Evolutionary Design (2002) http://www.artima.com/intv/evolution.html, Acesso: Mar/2008.
  3. MANCHESTER, Phil. XP daddy: Go incremental on design (2008) http://www.regdeveloper.co.uk/2008/03/14/beck_safety_steps_development/ Acesso: Mar/2008

sexta-feira, 27 de junho de 2008

O que é Projeto de Software?

De acordo com Pressman, Projeto é a representação significativa de alguma coisa que será construída. Em engenharia de software, o Projeto de Software é a fase de desenvolvimento, na qual são feitos modelos com todas as entidades que serão construídas posteriormente a partir dos requisitos do sistema. O projeto de software foca em 4 áreas, como: dados, arquitetura, interface e componentes. Para garantir que um projeto está sendo feito com qualidade é necessário avaliar continuamente pontos referentes a corretude, completude, clareza e consistência com os requisitos do sistema.

O projeto de software não deve reinventar a roda, para isso é necessário construir sistemas usando padrões de projeto. O projeto é importante para minimizar a distância entre o sistema e o mundo real.

Segundo Sommerville, projeto de software é a descrição da estrutura do software que será implementado, onde contém os dados que fazem parte do sistema, a interface entre os componentes do sistema, e algumas vezes, o algoritmo utilizado. O projeto não detalha completamente o sistema na sua primeira versão, pois são feitos vários modelos com diferentes níveis de abstração e a cada nível criado, geralmente, detecta-se problemas nos níveis anteriores. A cada nível seguinte são criados modelos mais detalhados, diminuindo cada vez mais a abstração.

A engenharia de software é diferente das outras engenharias, pois o produto (o software) manipulado pelo projeto, não é tangível. Além disso, não há um processo de software padrão, pois há uma dificuldade de relacionar os processos com os tipos de desenvolvimento, já que cada software produzido é único, pois as tecnologias mudam constantemente em um curto espaço de tempo.

No caso de Jack Reeves, no artigo “What is Software Design?”, ele aborda este tema de uma forma diferente dos conceitos dados por outros autores, pois ele levanta a hipótese de que o “Projeto de Software é o próprio código e que os modelos são apenas uma parte do projeto de software”. Pois, segundo Reeves, programar não consiste em construir software e sim em projetar software, já que a única documentação de software que na verdade parece satisfazer o critério de projeto de software é o código fonte. Outro ponto que o autor aborda é que é muito barato fazer software, se levarmos em consideração que o software, em sua fase final, é feito pelo compilador.

Em comparação com as outras engenharias, a engenharia de software ainda tem sido considerada como uma arte indisciplinada. Pois, nem sempre o que é projetado em modelos é o que realmente é construído no produto final. Há um problema nos artefatos gerados pela engenharia de software, pois há muito mais coisas no código fonte do que o que foi realmente projetado. Com isso, para Reeves o projeto de software mais correto seria o que fosse extraído a partir do código fonte, pois este pode ser facilmente testado e validado.


Opinião:

Na minha opinião, projeto de software é a arte de representar os requisitos de um sistema em diferentes níveis de abstração. Com isso, os requisitos são representados em modelos, com um alto nível de abstração, os quais são refinados para níveis inferiores até chegar ao código fonte, estando este no mais baixo nível de abstração.

O projeto de software é importante para formalizar as regras de negócio do sistema, melhorando a comunicação entre o cliente e o programador.

Não concordo com Reeves, quando ele diz que o projeto de software é o código fonte, pois sem as etapas de modelagem, que também fazem parte do projeto de software, seria bem mais difícil construir um software, principalmente com relação à formalização dos requisitos do sistema. Mas, concordo que falta na engenharia de software testar e validar os modelos de mais alto nível, talvez se houvesse esta validação, então o código gerado poderia ser exatamente o que foi projetado.

O artigo de Reeves foi muito importante para mostrar que existem muitas falhas na engenharia de software. Acho que para minimizar este problema, deveria haver um nível de abstração anterior ao nível do código fonte, que contivesse informações suficientes para gerar o código fonte exatamente como foi proposto no nível anterior. Além disso, seria necessário existir uma maneira de testar e validar este modelo antes de passar para o mais baixo nível.

Referências:
  • PRESSMAN, Roger S. Software engineering: A practitioner's approach - 5. ed. - New York: McGraw-Hill, p. 335-341, 2001.
  • SOMMERVILLE, Ian. Software Engineering - 7.ed. New York: Addison-Wesley, p. 71-73, 2005.
  • REEVES, J. W. Code as Design: Three Essays http://www.developerdotstar.com/mag/articles/reeves_design.html Acesso: Mar/2008.