Como fazer um bom projeto de software

Programação Arquitetura
#1

Boa tarde pessoal, este é parte do material de uma lista de discussão que gostaria de expor aqui no forum para obter outras possíveis soluções de como fazer um bom projeto de software, o software a ser construído é um ERP e esta sendo refatorado pois alguns conceitos mudaram durante o desenvolvimento do software.

Caso vc note algo de errado vc pode postar aqui mesmo como poderiamos melhorar o desenvolvimento, porem se vc quiser participar da lista de discussão peço que acesse o seguinte endereço http://groups.google.com/group/itrust-erp

Muito Obrigado :wink:

 Eu estou definindo o modulo de login e segurança do sistema, como este é nosso primeiro domínio existe muita coisa a ser discutida entre os especialistas de software, talvez os peritos do domínio fiquem ausente nessas primeiras discussões pois precisamos definir quais tecnologias serão usadas e como resolver de forma pratica os problemas do mundo real sem prender o design do código a uma determinada solução.

 1)Com relação a persistência dos dados eu proponho usar Hibernate com JPA.
 2)Controle de transações através de um container de inversão de controle para abstrair a forma como este controle é realizado.
 3)Disponibilizar dados na camada de apresentação web usando um webframework JavaServer Faces.
 4)Implementar interatividade com o cliente usando o framework AJAX4JSF
 5)Para acrescentar uma boa aparência na interface web podemos usar alguns componentes do RichFaces.
 6)Para adicionar interatividade com outros sistemas sugiro criar alguns webservices.
 7)Para implementar uma boa integração entre os especialistas de software e metodologia de software sugiro implementar os conceitos de Domain Driven Design, Extreme Programing e Scrum.

Observações:
Particularmente não pretendo implementar qualquer outro framework, acredito que os frameworks acima devem suprir a maior parte das nossas necessidades, porem eu não sou dono da razão e outras frameworks podem ser apresentadas como possíveis soluções e as apresentadas acima podem até mesmo serem substituídas por outras mais eficientes, desde que seja comprovada a sua eficiência.
As frameworks apresentadas acima já estão implementadas e testadas dentro do sistema, mas se existe outras melhores essa é melhor hora para mudar e questionar as frameworks usadas e ate mesmo a metodologia usada.

Caso alguém tenha duvidas sobre o que é Domain Driven Design, Extreme Programing e Scrum, peço que aguarde a confecção dos próximos artigos em http://www.iprogramming.blogspot.com
Eu adicionei o ultimo artigo fazendo referência ao controle de transações com springframework o qual é usado hoje no ITrust, porem como o projeto esta sendo refatorado nos próximos artigos eu vou descrever o que é o Domain Driven Design, como esta metodologia esta sendo aplicado ao ITrust, como o código foi refatorado e etc.

Outros pontos precisam ser ajustados pois mesmo refatorando o código eu ainda estou quebrando algumas regras, mas dessa vez propositalmente, um exemplo claro é o uso do Active Record.

#2

1 - OK
2 - Explicou mais tarde que se trata do Spring, mas IoC não tem haver diretamente com controle de transações, só pra deixar claro.

3- Ok ( Pode usar o MyFaces Orchestra, para utilizar o conjunto todo da obra - JSF + Spring + JPA.

4 -Ok

5 - Ok

6 - Muito cuidado com a exposição dos serviços, mais com o que vai ser exposto e como , existem muitas questões como segurança, cardinalidade e por aí vai … Pode simplificar a vida também avaliando a exposição através de REST.

7 - Aqui amigo, confusão total DDD, XP e Scrum na mesma salada ?

Scrum está em nível de gestão do projeto e XP de engenharia. Cabe as respectivas áreas adotarem seu framework para trabalho.

#3

Pode ser que eu tenha feito confusão :? pois nao conheco muito extreme programming e scruum, segue abaixo os motivos.

Eu imagino que o DDD nao prega o uso de waterfall como metodologia de desenvolvimento, pois é complicado prever todas as situações e desenvolver uma especificação que detalhe todas as necessidades do software no inicio do projeto, portanto creio que uma abordagem com extreme programing seja uma opção melhor para se trabalhar.

Com relação ao Scrum eu estou pesquisando, tenho pouco conhecimento e não saberia dizer se realmente é necessário, mas a Caelum fez um breve esclarecimento sobre a metodologia e acredito que esta pode ser aplicado no desenvolvimento do projeto.

#4

Nossa, muita coisa.

1, com base na minha experiência te adianto que ANTEs de decidir por um framework de persistência você deveria avaliar as seguintes questões:

a) sua aplicação é “orientada à banco” ou é uma aplicação 100% OO ? (numa aplicação orientada à banco normalmente os analistas começam desenhando o “MER” e, só depois disso, passam para o projeto da aplicação em si);

b) Você tem total controle do banco?

c) Vai ter necessidade de alta performance?

IMO, hibernate apenas para a,b = sim e c = não. Se você não tem controle do banco (segue as regras do cliente, não pode fazer truncate, tem que saber exatamente o quê vai submeter ao banco ou qualquer outra política de segurança do cliente) o hibernate pode te afundar. O hibernate é aconselhado para bancos que o tenham levado em consideração na modelagem. O analista se preocupou em desenhar um modelo à prova de hibernate. Se você precisar de alta performance não haverá chance de fazer tunning nas querys.

Para os casos nos quais não dá pra usar hibernate (muita empresa restringe por seguranca, tenho um case real disso) aconselho o iBatis.

  1. ERP certo? de prateleira? Você pode conseguir isso com session beans bem desenhados (4 camadas). Não conheço IoC à fundo mas te adianto que isso pode dificultar na hora de montar um bom time pro desenvolvimento - visto que ERPs não costumam ser aplicações pequenas. Você vai precisar de gente que conheça muito bem do assunto e já está difícil encontrar bons profissionais em java …

  2. me abstenho, não sei nada de JSF (de novo, por alto, isso tb pode complicar);

4 e 5) não conheço AJAX4JSF nem RichFaces mas se você tiver que escrever jabascript (ECMA) e o ambiente do seu cliente não for bem controlado (cada usuário com um navegador diferente) isso pode se tornar uma baita dor de cabeça. Assumindo que não é bem controlado: se ouver algum módulo a ser liberado na web esse deve ser incluído na sua gerência de risco;

  1. 10, sem problemas.

  2. não sei. nunca usei essas “metodologias”.

Cara, com exceção do ítem 7 (que não tenho como dar opinião) acho que pela quantidade de tecnologia extra (JSF, AJAX4JSF , RichFaces), para um ERP, você está carrendo bastante no risco. Não creio que seu cronograma (se já foi desenhado) tenha menos de 12 meses, certo?

Acho que vale lembrar que um bom projeto de software é aquele que atende seu cliente, pelo custo que ele pode pagar. Esse “quanto o cliente pode pagar”, conseqüentemente, afeta quem você pode contratar …

#5

[quote=agodinhost]Nossa, muita coisa…
[/quote]
a)o MER faz parte da abstração do dominio, portanto estamos formulando como os dados devem ser armazenados

b)Sim, temos controle total do banco, pois somos os próprios gerenciadores do banco

c)Nao, porem a performance do sistema hoje é satisfatória

2)Nao entendi o que vc queria dizer com esse item

3)Tudo bem, entao permanecemos com o JSF, creio que seja uma boa webframework

4,5)Nao é necessario escrever qualquer codigo javascript

7)Nao sou especialista nessas metodologias, mas acredito que seja a melhor opção

Com relação as tecnologias usadas, na verdade estas são só as basicas, creio que outras vao ser adicionadas como o jfreechart

De inicio nao temos uma preocupação direta com dinheiro, mesmo porque nao temos um cliente, esse é um projeto opensource e os links para acessar o projeto estao na minha assinatura.

Obrigado.

#6

Perdão, não havia visto que essa proposta era pra um projeto open source - só entrei no site depois de postar a mensagem.

Cara, não esquentei com as bibliotecas - isso normalmente não é problema para os desenvolvedores (desde que vc se atenha as comuns de mercado). A preocupação deve ser dada é com os frameworks que introduzam paradigmas diferentes, novos ou ainda não muito bem disseminados. Biblioteca se aprende com javadoc, já paradigmas novos é outra história …

  1. legal.

  2. Resumidamente o quê estou dizendo é que você pode conseguir “quase” o mesmo resultado utilizando ferramentas mais simples. Você não tem risco financeiro num projeto open source, apesar de tempo ser traduzido em dinheiro, o risco é de que você aumente muito a complexidade do seu projeto e isso acabe dificultando na hora de encontrar gente pra desenvolver. Acaba que seu projeto vira um grande laboratório de tecnologia (e não de negócios). Se você optar por essas tecnologias mesmo tenha certeza de ter alguém pra centralizar e revisar o código de tempos em tempos. No mundo ideial seria interessante que você, antes de iniciar o projeto, desenvolvesse o maior número de templates possíveis em “laboratório” pra poder difundir melhores práticas pros seus developers.

3,4 e 5) veja 2.

#7