[quote=fggs]@rmendes08:
Desculpe pela demora em responder, não sei porque a notificação deste tópico caiu no Spam.
Então, eu avaliei tudo isso, um sistema pronto tem funções que eu nunca vou usar e não tem funções que eu gostaria de ter.
Tempo eu tenho, pois não cuido sozinho da empresa e a ideia é fazer as coisas aos poucos e com módulos, assim posso ajustar o custo com a produtividade que isso me dará.
Tenho um amigo que é muito bom mesmo, ele tem uma fábrica de software, para ajudá-lo e para também “acelerar” o processo de análise, pensei em tentar chegar pelo menos num documento UML ou então diagrama de classes, só não estou sendo muito feliz na hora de modelar e é por isso que fui atrás no outro tópico em “Arquitetura de Sistemas”.
Se a empresa fosse nova seria mais fácil, agora fica mais difícil enxergar os padrões, pelo menos na minha visão.
Talvez tenha um pouco de orgulho nisso também, de conseguir implementar uma coisa que eu idealizei do zero.
Como eu disse várias vezes, qualquer sugestão, até mesmo critica, são bem-vindas. Semana passada passei perto de me matricular no curso de formação Java da Caelum, mas sinceramente, acho que não iria me ajudar muito no momento, somente em muitas etapas seguintes, enquanto isso vou buscando o caminho de tornar realidade.[/quote]
Veja bem rggs, acho que como investidor a sua preocupação é garantir o retorno do investimento, e não se o framework do projeto deve ser JSF ou GWT (a não ser que isso tenha impacto no ROI).
Como você mesmo disse, se você como dono da empresa está tendo dificuldades em enxergar padrões nos seus processos, imagina os programadores, que provavelmente nem conhecem o seu negócio! Durante um tempo, foi defendido que uma maneira de resolver esse problema seria documentar os requisitos em termos de diagramas e documentos, mas essa não é a solução. Casos de uso, diagramas de UML, diagramas de ER são ferramentas de desenvolvimento, tanto quanto uma linguagem de programação. Ou seja, técnicas de modelagem ou documentação são internas à equipe de desenvolvimento, e impor uma ferramenta (como um diagrama de classes) pode ser extremamente prejudicial ao processo. O resultado desse pensamento, durante um tempo foi um foco exagerado em documentação e modelagem e o esquecimento das disciplinas mais importantes no desenvolvimento: a implementação e a análise de negócios.
A análise de negócios, ao contrário do que muitos pensam, não é análise de requisitos. Fazer uma entrevista e desenhar um UML qualquer bacharel mediano faz. O problema da análise de negócios é resolver o problema do ponto de vista do cliente, do investidor. Hoje, já se sabe que tentar levantar todos os requisitos e implementar tudo de uma vez é problemático, pois o risco é muito grande. Uma das maneiras de mitigar esse risco é dividir o sistema em lotes menores e entregar aos poucos. Mas isso por si não resolve o problema do ROI, pois é preciso saber o que tem que ser feito antes. É nesse ponto que entra a análise de negócios: priorizar as entregas, identificar os processos mais importantes, propor melhorias aos processos, e comunicar isso à equipe de desenvolvimento.
Enfim, espero não estar ensinando o Pai-Nosso ao vigário. Alguns links que eu acho interessante sobre o assunto:
http://blog.fragmental.com.br/2008/01/15/quando-eu-crescer-quero-ser-analista-de-sistemas/
http://blog.claudiobr.com/tag/análisedenegócios
http://www.iiba.org.br/index.php?option=com_content&view=article&id=43:babok