DEVO USAR UML? VB6 OU VB.NET
Srs. boa tarde.
Já faz algum tempo que sinto necessidade de um nivelamento mais aprofundado nos meus conhecimentos.
Acabei de entregar um sistema no qual o desenvolvimento foi bastante complicado. Não pela complexidade do sistema nem no negócio do cliente, mas faltou visualização do cenário todo.
O sistema que desenvolvi, basicamente realiza pedidos de compra e venda. Logo vem a nossa mente cadastro de clientes e fornecedores, produtos, quantidades, valore unitários, etc. A visão global é bastante simples. O [Ô]problema[Ô] começa quando vamos nos aprofundando.
Um exemplo rápido: No meio do desenvolvimento, o cliente gostaria que fosse mostrado no relatório de pedidos do fornecedor, a qual cliente pertencia cada produto. Isso é fácil de se fazer. Mas não programei desta forma porque na nossa [Ô]conversa técnica[Ô], isso não foi requerido. Dias depois de entregar a versão de testes, o cliente pediu essa função.
Embora logo pensamos que isso deveria ser pedido antes, eu acho que é um pouco complicado o cliente conseguir visualizar estes detalhes. Penso eu que nós, os desenvolvedores, que devemos avisar o cliente que isso seria uma função quase que consequente.
é extremamente trabalhoso detectar isso em uma reuninão para saber o cliente deseja, e mais trabalhoso ainda ter que desmanchar o sistema para adaptar funcionalidades [Ô]esquecidas[Ô] ou não visualizadas.
Este é apenas um exemplo de um cenário muito mais complexo. O que eu quero dizer é que antes de digitar qualquer linha de código, montar qualquer tela de formulário ou criar qualquer tabela do banco, antes eu gostaria de modelar o sistema (que seria o mais correto).
Já estudei UML na faculdade, mas não cosigo visualizar o que é realmente importante ou efetivo me ajudar em meus projetos (sabe como é... lá na faculdade não é a vida real. Era para tirar nota.
).
Eu sempre desenvolvi programas sozinho. Nunca fiz parte de nenhuma equipe e nunca trabalhei em empresas de desenvolvimento. No entanto, sempre escrevi programas para as empresas que trabalhei. Alguns até foram bem grandes e até hoje mantenho e atualizo.
Mas na maioria dos meus desenvolvimentos, eu já sabia como funcionava o trabalho dos usuários ou precisei de pouca explicação. Só foi necessário trasnformar em software.
Hoje em dia desenvolvo para áreas e necessidades que eu não fazia idéia que existiam. Por isso fica extramamente difÃcil eu tomar decisões durante o desenvolvimento e não consigo visualizar o resultados sem antes pelo menos construir o banco de dados. Aà acontece o que mencionei no inÃcio do tópico...
Fico me perguntando como transformar a UML em algo prático.
A UML é uma boa alternativa, ou então alguma outra metodologia para modelar os meus sistemas?
[ ]'s
Já faz algum tempo que sinto necessidade de um nivelamento mais aprofundado nos meus conhecimentos.
Acabei de entregar um sistema no qual o desenvolvimento foi bastante complicado. Não pela complexidade do sistema nem no negócio do cliente, mas faltou visualização do cenário todo.
O sistema que desenvolvi, basicamente realiza pedidos de compra e venda. Logo vem a nossa mente cadastro de clientes e fornecedores, produtos, quantidades, valore unitários, etc. A visão global é bastante simples. O [Ô]problema[Ô] começa quando vamos nos aprofundando.
Um exemplo rápido: No meio do desenvolvimento, o cliente gostaria que fosse mostrado no relatório de pedidos do fornecedor, a qual cliente pertencia cada produto. Isso é fácil de se fazer. Mas não programei desta forma porque na nossa [Ô]conversa técnica[Ô], isso não foi requerido. Dias depois de entregar a versão de testes, o cliente pediu essa função.
Embora logo pensamos que isso deveria ser pedido antes, eu acho que é um pouco complicado o cliente conseguir visualizar estes detalhes. Penso eu que nós, os desenvolvedores, que devemos avisar o cliente que isso seria uma função quase que consequente.
é extremamente trabalhoso detectar isso em uma reuninão para saber o cliente deseja, e mais trabalhoso ainda ter que desmanchar o sistema para adaptar funcionalidades [Ô]esquecidas[Ô] ou não visualizadas.
Este é apenas um exemplo de um cenário muito mais complexo. O que eu quero dizer é que antes de digitar qualquer linha de código, montar qualquer tela de formulário ou criar qualquer tabela do banco, antes eu gostaria de modelar o sistema (que seria o mais correto).
Já estudei UML na faculdade, mas não cosigo visualizar o que é realmente importante ou efetivo me ajudar em meus projetos (sabe como é... lá na faculdade não é a vida real. Era para tirar nota.
).Eu sempre desenvolvi programas sozinho. Nunca fiz parte de nenhuma equipe e nunca trabalhei em empresas de desenvolvimento. No entanto, sempre escrevi programas para as empresas que trabalhei. Alguns até foram bem grandes e até hoje mantenho e atualizo.
Mas na maioria dos meus desenvolvimentos, eu já sabia como funcionava o trabalho dos usuários ou precisei de pouca explicação. Só foi necessário trasnformar em software.
Hoje em dia desenvolvo para áreas e necessidades que eu não fazia idéia que existiam.
Por isso fica extramamente difÃcil eu tomar decisões durante o desenvolvimento e não consigo visualizar o resultados sem antes pelo menos construir o banco de dados. AÃ acontece o que mencionei no inÃcio do tópico...Fico me perguntando como transformar a UML em algo prático.
A UML é uma boa alternativa, ou então alguma outra metodologia para modelar os meus sistemas?
[ ]'s
UML é muito bom mas pode tornar o desenvolvimento bem burocrático. Ela é excelente para servir como parte documentação do sistema. Não sou expert em UML, mas dos artefatos que eu mais gosto de usar são os diagramas de classe, casos de uso bem como seus diagramas. Acredito que diagrama de atividades ou de sequência devam ser utilizados em processos mais complexos do sistema.
Como é quase impossÃvel haver projeto de software estático, mudanças sempre existirão, então muda software e muda os artefatos. é bem trabalhoso, acho muito complicado uma pessoa tomar conta tanto das alterações do software quanto dos artefatos.
Hoje temos propostas ágeis como Scrum e outros. E tem algumas pessoas que mesclam com UML.
Acho o Scrum legal, pois vc define o que vai ser feito, define prazo, entrega e espera o conscientemente o feedback do [Ô]cliente[Ô] solicitando alterações ou aprovando o que foi feito, passando para outra etapa o desenvolvimento. O lance é: quanto mais rápido o feedback, mas fácil de resolver as solicitações e efeitos colaterais menores.
Como é quase impossÃvel haver projeto de software estático, mudanças sempre existirão, então muda software e muda os artefatos. é bem trabalhoso, acho muito complicado uma pessoa tomar conta tanto das alterações do software quanto dos artefatos.
Hoje temos propostas ágeis como Scrum e outros. E tem algumas pessoas que mesclam com UML.
Acho o Scrum legal, pois vc define o que vai ser feito, define prazo, entrega e espera o conscientemente o feedback do [Ô]cliente[Ô] solicitando alterações ou aprovando o que foi feito, passando para outra etapa o desenvolvimento. O lance é: quanto mais rápido o feedback, mas fácil de resolver as solicitações e efeitos colaterais menores.
Vai parecer mentira, mas publiquei um artigo, mais ou menos meia hora atrás exatamente sobre isso!
LLAIA, Vou ver sobre o Scrum. Obrigado!
KERPLUNK, posta o link do artigo.
[]'s
KERPLUNK, posta o link do artigo.
[]'s
Ainda está em aprovação... assim que sair eu posto...
FBUR, seu problema pode não ser a necessidade de utilizar UML e sim de criar um sistema utilizando Best Practice que lhe permitam realizar alterações com menor numero de danos possÃvel.
Eu lhe indicaria leitura de livros (já que é difÃcil encontrar tutoriais ou video aulas que cubram o assunto com autoridade) sobre Analise e Projeto Orientado a Objetos e Refatoração.
Projetos em VB6 tendem a ser estruturados e com muito código duplicado, e nesse caso, qq mudança no sistema se torna dramática.
Eu lhe indicaria leitura de livros (já que é difÃcil encontrar tutoriais ou video aulas que cubram o assunto com autoridade) sobre Analise e Projeto Orientado a Objetos e Refatoração.
Projetos em VB6 tendem a ser estruturados e com muito código duplicado, e nesse caso, qq mudança no sistema se torna dramática.
Caro SAMUKA, creio que você chegou onde eu queria.
O objetivo é construir um projeto primeiro [Ô]no papel[Ô]. Aà ficaria mais fácil (e correto) identificar se o que SERà desenvolvido é o que realmente o cliente quer. E se não for, identificar o que pode ser alterado, acrescentado, etc. é poder visualizar o projeto pronto e funcionando, só que no papel, na teoria. Mostrar todos os caminhos que a informação irá percorrer e como será recuperada.
Duvido muito que projetos que sigam metodologias começem um projeto criando formulários ou tabelas do bancos.
Comprei um livro sobre Análise e Projeto Orientado a Objeto (que usa um pouco de UML). Acho que é um bom complemento para um desenvolvimento mais profissional e com o mÃnimo de tempo desperdiçado.
O objetivo é construir um projeto primeiro [Ô]no papel[Ô]. Aà ficaria mais fácil (e correto) identificar se o que SERà desenvolvido é o que realmente o cliente quer. E se não for, identificar o que pode ser alterado, acrescentado, etc. é poder visualizar o projeto pronto e funcionando, só que no papel, na teoria. Mostrar todos os caminhos que a informação irá percorrer e como será recuperada.
Duvido muito que projetos que sigam metodologias começem um projeto criando formulários ou tabelas do bancos.
Comprei um livro sobre Análise e Projeto Orientado a Objeto (que usa um pouco de UML). Acho que é um bom complemento para um desenvolvimento mais profissional e com o mÃnimo de tempo desperdiçado.
Legal cara, mas cuidado pra não afundar em diagramas e na complexidade de mante-los atualizados pois, requisitos sempre mudam.
Tópico encerrado , respostas não são mais permitidas