Metodologia ideal

Olá pessoal
quero desenvolver um sistema web de cotações, que relaciona o comprador X fornecedor. Resumidamente, a idéia inicial é o comprador cadastrar uma cotação (um pedido) no site, e os fornecedores visualizam as cotações em aberto e enviam os orçamentos vinculados com a cotação.

Isso irá facilitar o tempo de cotação aqui no orgão público, que necessita de 3 orçamentos para uma determinada compra. Só que atualmente temos que ligar para as empresas, pedir orçamento por fax, por email, e esperar a disponibilidade dos fornecedores.

Com um sistema web, os fornecedores podem entrar diariamente no site e verificar as cotações pertinentes às suas respectivas áreas de atuação, e enviar os orçamentos pelo site mesmo. Pensou que legal, o comprador cadastra uma cotação no site pedindo alguns materiais de escritorio, e no outro dia ele acessa novamente e vê que tem uns 5 orçamentos, aí ele imprime e fecha com o mais barato (mas com qualidade).

Não sei se fui claro, mas antes de sair "javando", quero tentar modelar corretamente os requisitos, modelar as classes, identificar os dados, coisas asism. Usar uma metodologia para o desenvolvimento.

O ideal seria UML? Ouvi dizer de uma modelagem ágil. Ela aborda UML ou é totalmente diferente?
Alguém poderia me dar uma idéia de como começar?

Grato

This message was edited 1 time. Last update was at 18/03/2009 16:53:11

Somente para sua informação (não é resposta para sua pergunta): o governo do estado de SP já tem um sistema mais ou menos que faz isto http://www.bec.sp.gov.br/publico/aspx/Home.aspx.

Não é um sistema de "cotações", mas atende mais ou menos o que você quer (ele cobre a parte de pregão, dispensa e convite).

oyama wrote:Somente para sua informação (não é resposta para sua pergunta): o governo do estado de SP já tem um sistema mais ou menos que faz isto http://www.bec.sp.gov.br/publico/aspx/Home.aspx.

Não é um sistema de "cotações", mas atende mais ou menos o que você quer (ele cobre a parte de pregão e convite).

Obrigado amigo. Nós já utilizamos (alias, temos por Lei que utiiza-lo..rs) BEC para Pregões, Convites e compras sem licitações de até 8.000,00 reais. E podemos comprar na BEc só com valores acima de 600 reais.

Acontece que a BEC exige que tenhamos um valor X reservado para cadastrar a cotação (que chamamos de oferta de compra). Mas para chegarmos a esse valor X, temos que fazer uma pesquisa (orçamentos) no mercado e levantar uma "média" de preços.
É aí nessa fase de "orçamentos" que ligamos para as empresas, mandamos email, e esperamos juntar 3 orçamentos ao processo, para poder dar continuidade e fazer a compra pela BEC.

E oq acontece com as compras de valores menores de 600? Não podemos usar a BEC. Temos que comprar direto com o fornecedor. Mas tem que existir no processo 3 orçamentos. Não podemos fugir desses monstruosos "três orçamentos". E essa fase de levantamento de orçamentos á a mais árdua.

Acreditamos que com um sistema web, onde os fornecedores fazem o cadastro, e acessam para verificar as cotações do dia em aberto, facilita o relacionamento e diminui o tempo de cotação. Temos sempre aqueles "mesmos" fornecedores que vendem pra gente. E conversando com alguns deles, acharam a idéia ótima. O cara pode estar num laptop na casa dele e verificar as cotçaões que pode passar. Fora que também posso divulgar o site para outros fornecedores, expandindo nosso nicho de contratação, e isso será econômico ao erário público. Bom, Direito Administrativo à parte, esse sistema irá auxiliar apenas na fase de orçamento. Nada mais. O resto é pedido de compra ou até mesmo BEC.

Mas qual metodologia devo utilizar para desenvolver esse sistema sem me enrolar? Cheguei a esboçar uma UML,mas ainda não tenho mta prática com UML e acabo "travando".

GUJ Master Membro desde: 29/05/2008 14:09:28 Mensagens: 1615 Offline

Basicamente, UML não é uma metodologia, é uma linguagem visual para descrever conceitos do paradigma orientado a objetos em diversas etapas de desenvolvimento. Basicamente, eu aconselharia a você a não se prender muito em seguir uma determinada metodologia, sob o risco de perder o foco do seu projeto. Concentre-se na definição clara dos requisitos, casos de teste e validação. Ficar desenhando diagramas pode ser uma perda de tempo.

rmendes08 wrote:Basicamente, UML não é uma metodologia, é uma linguagem visual para descrever conceitos do paradigma orientado a objetos em diversas etapas de desenvolvimento. Basicamente, eu aconselharia a você a não se prender muito em seguir uma determinada metodologia, sob o risco de perder o foco do seu projeto. Concentre-se na definição clara dos requisitos, casos de teste e validação. Ficar desenhando diagramas pode ser uma perda de tempo.

hmmm...esses casos de teste e validação que vc disse, de que forma posso implementá-los? Da forma normal com JUnit mesmo?
ou vc quer dizer um mega rascunho numa folha de papel?

Eu pensei em algo assim tb: modelar minha classes, começar a fazer possiveis testes, e com base nos testes ir montando a minha logica de negocios.
Isso é uma boa prática de desenvolvimento?

Virtual Machine Man Membro desde: 19/04/2005 10:11:09 Mensagens: 572 Offline

Desculpe, mas eu não estava te enrolando. Como coloquei explicitamente, foi com o intuito de informar que enviei o post anterior.

Entendi também que o que voce quer atender com este sistema é a modalidade de "tomada de preço".

Com relação a sua dúvida: não existe uma metodologia ideal neste seu contexto. Vai depender do conhecimento da equipe e de outros fatores externos (tempo, budget, requisitos, etc). O que voce descreveu é mais ou menos o que se tem de mais prático: testes automatizáveis e desenvolvimento incremental. Não se preocupe em "usar UML" neste contexto. O importante é a equipe saber claramente o que deve ser feito (isto inclui as regras de negócio).

leandronsp wrote:

rmendes08 wrote:Basicamente, UML não é uma metodologia, é uma linguagem visual para descrever conceitos do paradigma orientado a objetos em diversas etapas de desenvolvimento. Basicamente, eu aconselharia a você a não se prender muito em seguir uma determinada metodologia, sob o risco de perder o foco do seu projeto. Concentre-se na definição clara dos requisitos, casos de teste e validação. Ficar desenhando diagramas pode ser uma perda de tempo.

hmmm...esses casos de teste e validação que vc disse, de que forma posso implementá-los? Da forma normal com JUnit mesmo?
ou vc quer dizer um mega rascunho numa folha de papel?

Eu pensei em algo assim tb: modelar minha classes, começar a fazer possiveis testes, e com base nos testes ir montando a minha logica de negocios.
Isso é uma boa prática de desenvolvimento?

Vc descreveu TDD no fim das contas: vc tem experiência nisso? Eu começaria pensando nos testes do CORE do sistema, nas classes de domínio, e estenderia os testes ao ponto que eu achasse mais relevante.

Agora, não confunda a forma como vc vai gerenciar o projeto com a forma de desenvolvimento: escolher os artefatos que estejam ligado a definição de "pronto" (rascunho de papel, email com foto do que foi acordado, junit pro cliente) são coisas que vc deve pensar muito bem e acatar o que é melhor para vc. De uma lida sobre Scrum para gerenciamento e XP para desenvolvimento e pense que vc pode usar o melhor dos dois.

peczenyj wrote:

Vc descreveu TDD no fim das contas: vc tem experiência nisso? Eu começaria pensando nos testes do CORE do sistema, nas classes de domínio, e estenderia os testes ao ponto que eu achasse mais relevante.

Agora, não confunda a forma como vc vai gerenciar o projeto com a forma de desenvolvimento: escolher os artefatos que estejam ligado a definição de "pronto" (rascunho de papel, email com foto do que foi acordado, junit pro cliente) são coisas que vc deve pensar muito bem e acatar o que é melhor para vc. De uma lida sobre Scrum para gerenciamento e XP para desenvolvimento e pense que vc pode usar o melhor dos dois.

Ahhh, então pensar no negócio do sistema antes de sair programando, está ligado a XP?
E para gerenciar o projeto como um todo envolve Scrum?

To quase que assimilando oq vc quer dizer.

JavaChild Membro desde: 13/03/2008 09:39:28 Mensagens: 104 Offline

leandronsp wrote:

oyama wrote:Somente para sua informação (não é resposta para sua pergunta): o governo do estado de SP já tem um sistema mais ou menos que faz isto http://www.bec.sp.gov.br/publico/aspx/Home.aspx.

Não é um sistema de "cotações", mas atende mais ou menos o que você quer (ele cobre a parte de pregão e convite).

Obrigado amigo. Nós já utilizamos (alias, temos por Lei que utiiza-lo..rs) BEC para Pregões, Convites e compras sem licitações de até 8.000,00 reais. E podemos comprar na BEc só com valores acima de 600 reais.

Acontece que a BEC exige que tenhamos um valor X reservado para cadastrar a cotação (que chamamos de oferta de compra). Mas para chegarmos a esse valor X, temos que fazer uma pesquisa (orçamentos) no mercado e levantar uma "média" de preços.
É aí nessa fase de "orçamentos" que ligamos para as empresas, mandamos email, e esperamos juntar 3 orçamentos ao processo, para poder dar continuidade e fazer a compra pela BEC.

E oq acontece com as compras de valores menores de 600? Não podemos usar a BEC. Temos que comprar direto com o fornecedor. Mas tem que existir no processo 3 orçamentos. Não podemos fugir desses monstruosos "três orçamentos". E essa fase de levantamento de orçamentos á a mais árdua.
...

Leandro:

Já leu Kafka ? Me parece que temos ai um problema de irracionalidade administrativa.
Aparentemente, já existe um sistema que faz isso, dentro da mesma esfera da administração pública,
para promover agilidade e transparência nas compras, mas a política de uso não permite que isto seja
aproveitado plenamente.

Esse novo sistema, quase duplicado do anterior, seria desenvolvido e mantido com o dinheiro
de nossos impostos. Não seria o caso de sensibilizar os gestores para obter os benefícios que a
ferramenta que já existe pode dar ?

Jorge

Como já foi dito, UML será uma representação gráfica para os requisitos e atuantes no sistema.
Este artigo é muito bom para você que quer escolher uma metodologia:
http://qualidadebr.wordpress.com/2009/02/10/qual-a-melhor-metodologia

Para que você tenha sucesso nos prazos do seu sistema é importante sim modelar corretamente, documentar e testar.

Sucesso no seu projeto!

This message was edited 1 time. Last update was at 27/03/2009 12:32:20

Esse artigo acima está conceitualmente incorreto. Meu ponto de vista está listado abaixo:

http://blog.aspercom.com.br/2008/04/23/so-agilidade-funciona/

Rodrigo, entendo a sua "preocupação" em ajudar o colega e ao mesmo tempo indicar o seu trabalho.

Porém acho que o autor do artigo que indiquei merece respeito, e não ter seu artigo chamado de piada. Afinal podemos considerar que ele teve a mesma preocupação que você em divulgar o conhecimento.

rodrigoy wrote:Esse artigo acima é uma piada...

flws

Obrigado pelas dicas pessoal....

Com relação aos testes, concordo que eles podem em suma ser uma parte da "documentação" dos requisitos.
O código fica bem maior na parte de testes, mas no final vale a pena. A chance de ter que arrumar é menor.

É muito bom poder codificar o sistema, ao final aquela bateria enorme de teste e ver que está tudo "verdinho"...rs...

apgomes88 wrote:
Porém acho que o autor do artigo que indiquei merece respeito, e não ter seu artigo chamado de piada. Afinal podemos considerar que ele teve a mesma preocupação que você em divulgar o conhecimento.

Bom, começar o artigo buscando definição de dicionário para Metodologia e depois apresentar o desenho abaixo é meio dose!!!

Depois disso, separar em cascata, iterativo e ágil também não é conceitualmente correto, já que métodos ágeis são iterativos. Além disso dizer que RUP não é ágil é falta de conhecimento. RUP poder ser tão ágil quanto qualquer outra coisa.

Quero ver bibliografias que suportem tais afirmações...

Notícias, artigos e o maior fórum brasileiro sobre Java