Metodologia ideal

Assuntos Gerais Agile
#1

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

#2

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).

#3

[quote=oyama]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). [/quote]

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”.

#4

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.

#5

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?

#6

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).

#7

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?[/quote]

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.

#8

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.

#9

[quote=leandronsp][quote=oyama]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). [/quote]

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.
…
[/quote]

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

#10

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:

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

Sucesso no seu projeto!

#11

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

#12

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.

#13

:shock:

flws

#14

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…

#15

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…

#16

Bem Rodrigo, primeiro gostaria que você desse uma relida nos termos do fórum, pois segundo ele você concordou em: "não postar qualquer mensagem abusiva, obscena, invulgar, insultuosa, de ódio, ameaçadora, sexualmente tendenciosa ou qualquer outro material que possa violar qualquer lei em vigor. Isto conduz à sua expulsão imediata e permanente. "

E ao meu entender você infringiu tal regra.

Você tem total liberdade de discordar do meu post. Mas falar que é piada é ser radical e desrespeitoso, se bem que pelo visto, você é uma pessoa radical, já que acredita que “SÓ AGILIDADE FUNCIONA”. E o radicalismo não funciona no mundo atual, principalmente no mundo de TI.

E você como um blogueiro deveria ter mais respeito com os demais.

Sobre os seus comentários:

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

Essa é sua opinião, respeito ela. Mas a busca por definições no dicionário é um bom começo, e melhor do que buscar definições no achômetro.

“Depois disso, separar em cascata, iterativo e ágil também não é conceitualmente correto, já que métodos ágeis são iterativos.”

Não disse que métodos ágeis não são iterativos, só separei métodos ágeis em outra categoria, assim como está na fonte do post.

"Além disso dizer que RUP não é ágil é falta de conhecimento. RUP poder ser tão ágil quanto qualquer outra coisa. "

Não disse que RUP não é ágil, e sei muito bem que RUP pode ser tão ágil quanto qualquer outra metodologia ágil, dependendo da maneira que ele é implementado, já que o RUP é um framework de processo.

"Quero ver bibliografias que suportem tais afirmações… "

Se você fosse tivesse lido o post com mais atenção verificaria que o post é baseado em uma fonte bem confiável e de boa qualidade, que aliás, é o material para a certificação IBM Certified Specialist - Software Quality (http://www-03.ibm.com/certify/certs/46000101.shtml): Engineering Quality in Software Development, Module 1: Overview of Software Development Practices (http://www.arizonaworkforceconnection.com/AZIT/)

Abraços!

Fabrício Ferrari de Campos

#17

Fabricio, desculpe… já editei o post. Não estou mais chamando seu artigo “daquilo”. OK?

Se você acha que outras coisas além de Agilidade funcionam, cite-as aqui… Lancei esse post no meu blog para levar à reflexão: Agile não compete com outras coisas que funcionam. Sobre radicalismo e TI, isso depende de qual mundo de TI você vive e o que você chama de radicalismo. Quando a 37Signals lançou o livro “Getting Real” você achou radicalismo?

A questão é que essa fonte é muito estranha, pois não vejo nenhum outro autor defender essa visão (alias não achei esse desenho seu nos links que vc enviou). Tomar essa literatura para falar sobre Metodologias é bem pouco proveitoso. Não tem o mínimo sentido, em qualquer circunstância, classificar métodos como cascata, iterativo e ágil da maneira que você colocou no blog.

Eu posso customizar o RUP para instanciá-lo como Cascata?

#18

Para o autor do post, amigo, acredito que realemnte vc esta misturando um pouquinho a parte de engenharia com gerência, SCRUM vai gerênciar seu projeto, TDD, BDD vai ser utilizado na parte de engenharia, mão na massa do projeto.

Aconselho não pensar em ficar modelando nada até que precise ser feito, leia algo sobre modelagem ágil, UML em cores, pode lher dar novas visões sobre essa necessidade.

Não vou querer entrar no diálogo do Yoshima com o Fabrício, mas faço dele as minhas palavras, SÓ AGILIDADE FUNCIONA, e o resto é culpado até que se prove o contrário. rs

#19

Tudo bem Rodrigo.

Primeiramente, vou deixar claro que não sou contra metologias ágeis, pelo contrário elas ajudam muito para o sucesso do projeto. Só acredito que metologia ágil por si só, não é a salvação da lavoura. Afinal, todos os projetos que foram desenvolvidos antes do surgimento do manifesto ágil, falharam?

E o ponto fundamental de qualquer projeto, seja de TI ou não. São as pessoas. Então, antes de buscar a metodologia ideal você deve buscar a equipe ideal.

E como eu coloquei no meu post, acredito que por justamente termos mundos de TI variados, o que é algo muito natural, pois nenhuma empresa é igual a outra, precisamos encontrar a melhor metodologia para a nossa realidade. Não adianta colocar a força cascata, RUP, XP ou qualquer outra.

Sobre o livro “Getting Real”, o desconhecia até o momento, até irei buscar informações sobre ele. E para mim radicalismo é você falar que só agilidade funciona. Pode até ser real na sua realidade, mas na realidade de outras pessoas pode não ser.

A fonte é um material da IBM para uma certificação, portanto, é bastante influenciado pela visão da IBM, até comento isso no post. Quanto aos desenhos, você primeiramente deve ser cadastrar no site para ter acesso ao material.

Agora sobre a sua pergunta: “Eu posso customizar o RUP para instanciá-lo como Cascata?”

Até pode. Porém você estará transformando algo feito para ser iterativo em cascata. E você não irá fazer isso com certeza, já que acredita que só o que é ágil funciona.

Para terminar. Respeito a maneira como você encara Metodologias de Desenvolvimento e Testes de Software, aliás, esse é justamente o assunto do tópico. E não se o meu post ou o seu está “conceitualmente incorreto”.

Abraços!

Fabrício Ferrari de Campos

#20

[quote=Luiz Aguiar]Para o autor do post, amigo, acredito que realemnte vc esta misturando um pouquinho a parte de engenharia com gerência, SCRUM vai gerênciar seu projeto, TDD, BDD vai ser utilizado na parte de engenharia, mão na massa do projeto.

Aconselho não pensar em ficar modelando nada até que precise ser feito, leia algo sobre modelagem ágil, UML em cores, pode lher dar novas visões sobre essa necessidade.

Não vou querer entrar no diálogo do Yoshima com o Fabrício, mas faço dele as minhas palavras, SÓ AGILIDADE FUNCIONA, e o resto é culpado até que se prove o contrário. rs
[/quote]

Olá Luiz! O meu post é a minha visão sobre a metodologia ideal, portanto, com certeza é digna de concordâncias e discordâncias. E nela eu não defendo nem X nem Y. E ele é sobre metodologia em geral, não apenas de desenvolvimento de software, por isso o Scrum está citado como iterativa. Por ser uma metodologia ágil para gestão e planejamento de projetos de software.

Abraços!

Fabrício Ferrari de Campos