Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Princípios, Padrões e Práticas para um Design Ágil – Parte 2 - Java Magazine 81
A segunda parte deste artigo apresenta alguns indícios de como identificar a qualidade do software e boas práticas relacionadas ao desenvolvimento, onde são abordados diversos princípios de Design OO, que quando aplicados corretamente aumentam a qualidade do código e do Design da aplicação.
Java Magazine 81
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 81
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 81
Princípios, Padrões e Práticas para um Design Ágil – Parte 2
Criando um Design Ágil aplicando boas práticas de desenvolvimento
Na primeira parte deste artigo, analisamos conceitos importantes relacionados à arquitetura de software e seus tipos existentes, onde demos ênfase para a arquitetura distribuída, conceituando separação de responsabilidades, camadas físicas e lógicas, e a aplicação de alguns padrões de projeto para cada uma destas camadas.
Para esta segunda parte, vamos abordar as diferenças entre a criação de uma arquitetura seguindo métodos tradicionais, como o Waterfall, e a criação de um Design Ágil a partir de ciclos iterativos de duas a três semanas. Além disso, veremos meios de identificar um software mal planejado através de alguns sintomas conhecidos como Design Smells.
Para tratar estes sintomas, apresentaremos alguns princípios de Design OO (base de muitos padrões de projeto) que são o produto de décadas de experiência com a Engenharia de Software de não apenas um, mas de vários profissionais consagrados na área.
Design Ágil
Todos os anos o Standish Group – consultoria especializada em pesquisas na área de TI – prepara um relatório chamado Relatório do Caos (Chaos Report), que tem como objetivo apresentar o índice de sucesso nos projetos de software. No último estudo realizado, referente ao ano de 2009, o resultado foi alarmante.
O estudo apontou que apenas 32% dos projetos de software tiveram sucesso em sua implementação, enquanto 24% dos projetos falharam e nos 44% restantes houve algum tipo de desperdício, como atraso no projeto ou estouro no orçamento.
Entre os grandes vilões responsáveis pelas falhas nos projetos está a falta de definição clara dos requisitos e estimativas inapropriadas por parte dos analistas e arquitetos de software, que estimulados por metodologias de desenvolvimento de software como Waterfall, insistem em definir toda a arquitetura do sistema nas fases preliminares do projeto, resultando no chamado Big Design Upfront.
Waterfall: O modelo Waterfall, ou modelo cascata, é um modelo de desenvolvimento de software sequencial, no qual uma fase somente inicia quando a anterior termina, passando pelas fases de Análise de Requisitos, Projeto, Implementação, Verificação e Manutenção.
Big Design Upfront: É um termo utilizado para qualquer metodologia de desenvolvimento de software que define que o design da aplicação deve estar completo e perfeito antes do início do desenvolvimento da aplicação. Ele é geralmente associado ao método de desenvolvimento Waterfall.
Com a crescente popularidade das metodologias ágeis e a adoção de métodos como Scrum e XP, esta abordagem começou a cair em desuso, pois a construção do software passou a ser feita em pequenos incrementos, com ciclos iterativos de duas a três semanas, o que acabou levando a outra questão importante: como podemos assegurar que o software tenha uma estrutura que seja flexível, reutilizável, de fácil manutenção e que não fuja do escopo?
Talvez esta seja uma pergunta que não tenha resposta. O que sabemos é que os requisitos mudam, as regras de negócio mudam, o cliente muda, as pessoas mudam e, por fim, o sistema muda. Para evitarmos que estas constantes mudanças afetem nossa aplicação, ao iniciarmos o desenvolvimento de um sistema, se levarmos em consideração boas práticas de desenvolvimento, podemos chegar próximo ao software ideal, que atenda às necessidades do cliente com qualidade.
Para identificar se nosso sistema está com um bom design, Robert C. Martin, popularmente conhecido como Uncle Bob, apresentou alguns sintomas de design ruim, chamado de Design Smells (algo como Odores do Design). Estes sintomas permeiam a estrutura geral do software, e em seu livro Agile Software Development, Uncle Bob chegou a seguinte classificação:
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Criando um Design Ágil aplicando boas práticas de desenvolvimento
Na primeira parte deste artigo, analisamos conceitos importantes relacionados à arquitetura de software e seus tipos existentes, onde demos ênfase para a arquitetura distribuída, conceituando separação de responsabilidades, camadas físicas e lógicas, e a aplicação de alguns padrões de projeto para cada uma destas camadas.
Para esta segunda parte, vamos abordar as diferenças entre a criação de uma arquitetura seguindo métodos tradicionais, como o Waterfall, e a criação de um Design Ágil a partir de ciclos iterativos de duas a três semanas. Além disso, veremos meios de identificar um software mal planejado através de alguns sintomas conhecidos como Design Smells.
Para tratar estes sintomas, apresentaremos alguns princípios de Design OO (base de muitos padrões de projeto) que são o produto de décadas de experiência com a Engenharia de Software de não apenas um, mas de vários profissionais consagrados na área.
Design Ágil
Todos os anos o Standish Group – consultoria especializada em pesquisas na área de TI – prepara um relatório chamado Relatório do Caos (Chaos Report), que tem como objetivo apresentar o índice de sucesso nos projetos de software. No último estudo realizado, referente ao ano de 2009, o resultado foi alarmante.
O estudo apontou que apenas 32% dos projetos de software tiveram sucesso em sua implementação, enquanto 24% dos projetos falharam e nos 44% restantes houve algum tipo de desperdício, como atraso no projeto ou estouro no orçamento.
Entre os grandes vilões responsáveis pelas falhas nos projetos está a falta de definição clara dos requisitos e estimativas inapropriadas por parte dos analistas e arquitetos de software, que estimulados por metodologias de desenvolvimento de software como Waterfall, insistem em definir toda a arquitetura do sistema nas fases preliminares do projeto, resultando no chamado Big Design Upfront.
Waterfall: O modelo Waterfall, ou modelo cascata, é um modelo de desenvolvimento de software sequencial, no qual uma fase somente inicia quando a anterior termina, passando pelas fases de Análise de Requisitos, Projeto, Implementação, Verificação e Manutenção.
Big Design Upfront: É um termo utilizado para qualquer metodologia de desenvolvimento de software que define que o design da aplicação deve estar completo e perfeito antes do início do desenvolvimento da aplicação. Ele é geralmente associado ao método de desenvolvimento Waterfall.
Com a crescente popularidade das metodologias ágeis e a adoção de métodos como Scrum e XP, esta abordagem começou a cair em desuso, pois a construção do software passou a ser feita em pequenos incrementos, com ciclos iterativos de duas a três semanas, o que acabou levando a outra questão importante: como podemos assegurar que o software tenha uma estrutura que seja flexível, reutilizável, de fácil manutenção e que não fuja do escopo?
Talvez esta seja uma pergunta que não tenha resposta. O que sabemos é que os requisitos mudam, as regras de negócio mudam, o cliente muda, as pessoas mudam e, por fim, o sistema muda. Para evitarmos que estas constantes mudanças afetem nossa aplicação, ao iniciarmos o desenvolvimento de um sistema, se levarmos em consideração boas práticas de desenvolvimento, podemos chegar próximo ao software ideal, que atenda às necessidades do cliente com qualidade.
Para identificar se nosso sistema está com um bom design, Robert C. Martin, popularmente conhecido como Uncle Bob, apresentou alguns sintomas de design ruim, chamado de Design Smells (algo como Odores do Design). Estes sintomas permeiam a estrutura geral do software, e em seu livro Agile Software Development, Uncle Bob chegou a seguinte classificação:
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Você está em:
canal Java
Publicidade
Wagner Roberto Dos Santos
Space do autor
é Lead Editor da queue Arquitetura do portal Infoq Brasil (www.infoq.com/br), entusiasta do NetBeans IDE, tendo diversas participações na criação de plugins, traduções e testes do IDE. Palestrante em diversos eventos nacionais e vencedor de diversos prêmios de desenvolvimento, possui as certificaçõe...
Space do autor
0
0
