Arquivo Discussoes de Programacao e Tecnologia Pessoal tenho interesse de fazer um software, mas queria que ele fosse bem “desenhado”… ou seja queria fazer antes de tudo queria planeja-lo… ai so depois de tudo ir pra parte gostosa que sao os codigos.
Ai que mora o problema… como fazer isso? Existe algum metodo que facilite essa “abstracao”?
Primeiro, “tenho interesse de fazer um software” de que?
Para quê ele servirá? Quem utilizar? Conhece bem o negócio em que ele estará inserido? Quais são os pontos que o software melhorará? Quais ele garantirá melhor desempenho? Quais ele irá engessar?
Comece levantando os requisitos.
Depois, fica mais fácil.
Pessoal tenho interesse de fazer um software, mas queria que ele fosse bem “desenhado”… ou seja queria fazer antes de tudo queria planeja-lo… ai so depois de tudo ir pra parte gostosa que sao os codigos.Ai que mora o problema… como fazer isso? Existe algum metodo que facilite essa “abstracao”?
Começou pensando bem. Os fatores questionados pelo drsmachado te levam ao levantando de requisitos, após isto pesquise sobre UML (o próprio levantando de requisitos, casos de uso, diagramas sequencia, diagramas de estado, IHM dentre outros…)
:thumbup:
Pessoal tenho interesse de fazer um software, mas queria que ele fosse bem “desenhado”… ou seja queria fazer antes de tudo queria planeja-lo… ai so depois de tudo ir pra parte gostosa que sao os codigos.Ai que mora o problema… como fazer isso? Existe algum metodo que facilite essa “abstracao”?
Começou pensando bem. Os fatores questionados pelo drsmachado te levam ao levantando de requisitos, após isto pesquise sobre UML (o próprio levantando de requisitos, casos de uso, diagramas sequencia, diagramas de estado, IHM dentre outros…)
:thumbup:
Então como nunca trabalhei como programador estava pensando em criar alguns sistemas pra ter um pequeno “case”, pra servir como experiencia.
Mas queria fazer a coisa do jeito certo, criando a documentação e fazendo um sistema bom.
A minha primeira ideia era criar um sistema de boletim escolar online.
(deve ter varios por ai, mas queria fazer o meu apenas para o proposito que eu coloquei acima.)
(tbm estou estudando pra certificacao)
faeldix, é por aí que você deve seguir.
Encontre os requisitos funcionais, identificando quais ‘entidades’ fazem parte da sua aplicação, qual o relacionamento entre elas, quais as validações de consistências necessárias, o que deve ser exibido em tela, etc.
Depois requisitos não-funcionais, definindo se o software será uma aplicação disponível na web (ou numa intranet via navegador web) ou se vai ser desktop.
Para fins de aprendizado, vale mais a pena ir direto para o web.
E recomendaria que, paralelamente a isso, você pesquise bastante sobre desenvolvimento web (se for o caso), modelagem de banco de dados, etc., de forma que, após definir os requisitos, você já terá um norte para pelo menos iniciar o desenvolvimento. Dica: Procure por “CRUD básico”.
Depois de iniciar, surgirão muuuitas outras dúvidas (as melhores), aí você vem pra internet captar a experiência alheia.
Em resumo, neste primeiro momento, juntar um bom conhecimento do todo vai te ajudar bastante, senão tu pode entrar por um caminho e perder muito tempo fazendo algo que virá a desfazer e refazer depois.
Forte abraço!
Já ouviu falar em processo unificado ? Entenda um pouco sobre o OpenUp, pode se ter uma ideia interessante de que norte seguir.
Ah, vc mencionou certificação tb…
Conhecimento (certificado ou não, mas especialmente certificado) deve SEMPRE ser acompanhado de experiência, senão você vira uma “aberração” no mercado. 
No sentido de que seu currículo fica “pesado”, você fica com uma munição muito impressionante, mas no meio do fogo cruzado não vai saber como usar e aí… :shock:
Então, minha dica, faça muitas experiências com tudo o que você estudar, faça funcionar, faça quebrar, faça funcionar de outra forma, domine de verdade. Aí a prova de certificação fica bem mais fácil e a entrevista de emprego tb. 
Forte abraço!
O que todo mundo falou é de muita utilidade. Eu só teria cuidado em procurar informações mais embasadas.
O que você quer é entender como funciona um processo de desenvolvimento de software. Existem diversos processos padrões no mercado, desde os mais tradicionais como o RUP, e suas derivações, até as ditas metodologias ágeis como o SCRUM e XP, por exemplo.
Processo de desenvolvimento de software não é algo “Aprenda em 24h” se você quer ter um real entendimento do assunto.
Não existe processo “bala de prata”, você precisa entendê-los para definir qual é o melhor para o escopo do seu projeto.
Outro erro comum que as pessoas costumam cometer é confundir UML com processo. UML é uma boa forma de facilitar a rastreabilidade e comunicação dentro de um processo. Ou seja, UML é uma forma de facilitar abstrações dentro de determinados processos.
Que é isso gente … RUP ? OpenUP ? Scrum, XP ? para um projeto de uma pessoa só ?
Na boa, não há sentido em adotar metodologias de gerenciamento para um projeto que o cara vai fazer sozinho. As metodologias, qualquer uma delas definem papéis e processos para equipes de desenvolvimento. Para projetos pessoais eu acho completamente desnecessário. Claro que sair fazendo o que der na telha também não dá certo, pois você fica sem um norte e pode acabar se perdendo no meio do código. Nesse caso, o que você precisa fazer na prática é:
:arrow: manter uma organização pessoal razoável. Sério mesmo, uma checklist com as funcionalidades do seu projeto será mais do que suficiente. Esqueça qualquer template de documento de requisitos ou coisas do tipo
:arrow: técnicas de modelagem de software. Estas sim podem te ajudar muito! Existem diversos aspectos do software que você pode modelar antes de por a mão na massa: estados de objetos, interações entre usuário e sistema, entidades, etc. Porém, tentar modelar tudo é um erro, pois a partir de certo ponto você quer modelar detalhes sobre os quais você ainda não tem conhecimento.
:arrow: Princípios de projeto OO. Estes são os mais importantes. Conceitos como coesão, acoplamento, separação de responsabilidades são fundamentais na hora de escrever o seu software.
Enfim, o planejamento do seu trabalho não pode ser mais complicado do que o trabalho em si. Procure algumas técnicas formais mas não se apegue demais a elas. Você vai ver que na maioria dos casos, o que funciona melhor são justamente as técnicas mais simples: uma checklist, alguns protótipos e diagramas rascunhados vão dar o norte que você precisa. Quanto mais cedo você conseguir alguma coisa funcionando mais cedo você vai poder aprender.
Que é isso gente … RUP ? OpenUP ? Scrum, XP ? para um projeto de uma pessoa só ?Na boa, não há sentido em adotar metodologias de gerenciamento para um projeto que o cara vai fazer sozinho. As metodologias, qualquer uma delas definem papéis e processos para equipes de desenvolvimento. Para projetos pessoais eu acho completamente desnecessário. Claro que sair fazendo o que der na telha também não dá certo, pois você fica sem um norte e pode acabar se perdendo no meio do código. Nesse caso, o que você precisa fazer na prática é:
:arrow: manter uma organização pessoal razoável. Sério mesmo, uma checklist com as funcionalidades do seu projeto será mais do que suficiente. Esqueça qualquer template de documento de requisitos ou coisas do tipo
:arrow: técnicas de modelagem de software. Estas sim podem te ajudar muito! Existem diversos aspectos do software que você pode modelar antes de por a mão na massa: estados de objetos, interações entre usuário e sistema, entidades, etc. Porém, tentar modelar tudo é um erro, pois a partir de certo ponto você quer modelar detalhes sobre os quais você ainda não tem conhecimento.
:arrow: Princípios de projeto OO. Estes são os mais importantes. Conceitos como coesão, acoplamento, separação de responsabilidades são fundamentais na hora de escrever o seu software.
Enfim, o planejamento do seu trabalho não pode ser mais complicado do que o trabalho em si. Procure algumas técnicas formais mas não se apegue demais a elas. Você vai ver que na maioria dos casos, o que funciona melhor são justamente as técnicas mais simples: uma checklist, alguns protótipos e diagramas rascunhados vão dar o norte que você precisa. Quanto mais cedo você conseguir alguma coisa funcionando mais cedo você vai poder aprender.
Concordo plenamente sou iniciante tambem e começar a estudar várias coisas ao mesmo tempo acaba atrapalhando e tomando mais de 60% do seu tempo tentei todo tipo de planejamento e parava antes de concluir o que realmente deu certo foi criar um checklist de requisitos um diagrama de caso de uso e um de classe o programa saiu rapidinho em cerca de 60 dias, planejamento pesado mesmo é para equipe com mais de 3 pessoas fora isso só atrapalha você não consegue utilizar essas técnicas “ageis” se realmente não conhece-las e acabará atrapalhando em vez de ajudar…
Exato, eu fui lendo o tópico e dizendo: WTF?!
Caiam na real, literalmente: http://gettingreal.37signals.com/GR_por.php.
Exato, eu fui lendo o tópico e dizendo: WTF?!
+1.
A melhor forma seria você utilizar técnicas da
Engenharia de Software.
Utilizar Modelos de processo de desenvolvimento.
Exato, eu fui lendo o tópico e dizendo: WTF?!
+1.
Não entendi muito bem o espanto. O cara não falou o escopo ou o “tamanho” do software. Pode ser um sistema de agenda ou pode ser um ERP.
Se o cara quer fazer um produto manutenível que tenha qualquer tipo de documentação, seja ela técnica, funcional ou de usuário, ele precisa de ALGUM processo, qualquer que seja. Pra isso ele precisa de embasamento teórico em qualquer processo que seja.
Acredito que o que os colegas quiseram dizer é que, se ele vai desenvolver sozinho, não precisa estudar sobre pair-programming (XP) ou stand up meeting (Scrum). Claro que talvez um kanban seja útil para se auto-organizar, ou entender os conceitos de on-site client para tocar melhor curtas entregas, ou TDD, etc.
Enfim, dependendo do tamanho do software (que pode sim ser um ERP que o cara vai desenvolver sozinho… :shock: ), vale a pena conhecer estes conceitos de Agile e/ou outras metodologias mais tradicionais (RUP, etc.) que não estão diretamente relacionados ao trabalho em equipe.
Se você for desenvolver um mega sistema sozinho que talvez no futuro precise ser mantido por uma equipe, vale a pena desde o início já seguir bons padrões especialmente de implementação (testes, patterns, etc.) e talvez alguma documentação também explicando os fluxos das coisas. Aí colocar mais 10 pessoas para trabalhar vai ser barbada com uma curva de aprendizado bem reduzida e ninguém vai ter o primeiro contato com o código e dizer “Que droga é essa???”.
Exato, eu fui lendo o tópico e dizendo: WTF?!
+1.
Não entendi muito bem o espanto. O cara não falou o escopo ou o “tamanho” do software. Pode ser um sistema de agenda ou pode ser um ERP.
Se o cara quer fazer um produto manutenível que tenha qualquer tipo de documentação, seja ela técnica, funcional ou de usuário, ele precisa de ALGUM processo, qualquer que seja. Pra isso ele precisa de embasamento teórico em qualquer processo que seja.
Penso o mesmo e concordo em absoluto. Também não entendi o espanto.
Acredito que o que os colegas quiseram dizer é que, se ele vai desenvolver sozinho, não precisa estudar sobre pair-programming (XP) ou stand up meeting (Scrum). Claro que talvez um kanban seja útil para se auto-organizar, ou entender os conceitos de on-site client para tocar melhor curtas entregas, ou TDD, etc.Enfim, dependendo do tamanho do software (que pode sim ser um ERP que o cara vai desenvolver sozinho… :shock: ), vale a pena conhecer estes conceitos de Agile e/ou outras metodologias mais tradicionais (RUP, etc.) que não estão diretamente relacionados ao trabalho em equipe.
Se você for desenvolver um mega sistema sozinho que talvez no futuro precise ser mantido por uma equipe, vale a pena desde o início já seguir bons padrões especialmente de implementação (testes, patterns, etc.) e talvez alguma documentação também explicando os fluxos das coisas. Aí colocar mais 10 pessoas para trabalhar vai ser barbada com uma curva de aprendizado bem reduzida e ninguém vai ter o primeiro contato com o código e dizer “Que droga é essa???”.
O papel de um processo formal é organizar as atividades entre os diferentes membros da equipe.
Se a pessoa vai fazer sozinho não precisa de um processo formal. Ponto.
Sobre o projeto ser manutenível, documentação e outras boas práticas, nada que 10000 horas de experiência não resolva.