Bom dia,
Me deparei com essa pergunta, já que estou começando a desenhar um, mas não consigo enxergar direito os relacionamentos, o jeito certo de fazer, já tentei entrevistar os funcionarios para ver se facilitava, digamos que ajudou, mas ainda assim é complicado…
Quando eu disse “correta”, quis dizer mais usual pois devem existir N maneiras…
Pelo que li eu deveria começar pelo diagrama de classes, é isso mesmo?
eu gosto de seguir a seguinte sequencia, Modelar Banco de Dados, Camada de Persistencia, Camada de Negocio e Camada de Visão.
t+
Eu acho que o ideal é começar pelos processos, um bom trabalho de BPM com Aris mapeando processos em EPC ou BPMN faz muita diferença. Se a empresa já possui um AS-IS de todos os processos, vc poderia gastar mais tempo do projeto planejando o TO-BE de todos os processos, nessa modelagem vc identifica quais são oportunidades de reusabilidade e se uma atividade é melhor aproveitada sendo completamente humana ou suportada por algum sistema ou funcionalidade.
Após esse trabalho com o TO-BE vc já tem um norte, fica mais fácil elaborar uma arquitetura de referência vc saberá com quais sistemas irá interagir e se os componentes que vc irá adicionar irão atender os processos.
Em paralelo ao trabalho de arquitetura pode ser tocado um mapeamento de requisitos funcionais a partir dos requerimentos gerados nos processos, os requisitos são o insumo para produção dos casos de uso e prototipação.
Após a definição dos Casos de Uso e com os processos a mão fica mais fácil produzir artefatos para desenho técnico, em paralelo a essa etapa acho que é possivel produzir o documentação para testes.
Obrigado pelas rápidas respostas Alisson e Davi!
E se no caso a empresa ainda não possui um bom AS-IS, por assim dizer? Vou pesquisar sobre como obter isso, mas gostaria da opinião de vocês.
Vou estudar o TO-BE para já começar alguma coisa quando o AS-IS tiver pronto.
muita coisa depende de escopo, imagino que seu projeto seja simples.
Entao vc pode ter uma abordagem prática, começou bem, entrevistou os usuários, se já descobriu oque eles querem, vc pode usar as user stories ou casos de uso mesmo para documentar, documente somente o necessario para comunicaçao, nao se apegue a documentacao inutil que vai ser um monte de papel esquecido e desatualizado. Entenda o negocio do seu cliente.
pesquise que tecnologia se enquadra melhor. Feito isso comece a desenvolver. FAÇA TESTES. E foque na comunicação
abrasss
Eu imagino que tenha várias maneiras de começar…
O que eu aprendi é começando pelos requisitos, anotar tudo… fazer várias reuniões - brainstorm (tempestade de idéias).
A partir dai, você filtra o que é útil…
As vezes, montar um exemplo de tela, pode ajudar a montar um banco de dados!!
não precisa ser a tela mesmo, em swing ou html/css ou sei lá oq… pode ser um desenho no papel mesmo ou no photoshop/corel draw.
Eu faço muito isso, desenhar telas no papel, e realmente ajuda na formação do banco de dados.
Mais uma vez, obrigado pela resposta Renan.
Se é simples não sei, o que sei é que sou meu próprio cliente e entrevistei para enxergar melhor os processos, mas o que aconteceu é que cada um enxergava o processo de uma forma, fazia de um jeito. Talvez caiba ao meu sistema disciplinar os processos.
O que eu quero que o sistema faça e bem é gerar bons relatórios, isso é primordial.
To aqui lendo sobre EPC e BPMN, pelo que entendi, EPC é bom para linkar varias dimensões, BPMN é melhor no controle de fluxo, vou analisar meu caso e começar a desenvolver esse BPM para depois partir para arquitetura de referência e assim por diante.
Pelo menos esse é meu plano hehehe
Respondendo ao Alan, eu também achava que fazendo telas facilitava para enxergar, mas eu me perco na hora de organizar. Na realidade fico naquela… como criar essa tela? Assim ou assado?
Poxa, muito obrigado pela ajuda de todos, eu estava mesmo precisando de uma base teórica. De um jeito ou de outro não da para fugir de conhecer as necessidades, acho que vou começar por ai
Começar pelo diagrama de classes?
De onde essas classes virão?
Mapeando processos?
Depende do escopo?
Existem N maneiras?
Sim, existe a maneira certa e as erradas. Se você quer a maneira correta, precisa conhecer o negócio, o objetivo do sistema, quais são os pontos em que ele irá ser aplicado, quem irá utilizar e como essa interação vai ocorrer. Isso lembra alguma coisa? Se você disse “requisitos” a resposta está correta.
Levantar requisitos vai além de entrevistar usuários, é fazer parte do cotidiano deles, ver como as operações são feitas atualmente, que entradas, onde o processamento ocorre e de que forma e quais são as saídas.
Não é possível criar um sistema para padaria, pensando que vender pães é a mesma coisa que vender roupas.
É por isso que se chama análise de sistemas, você precisa estudar, analisar a coerência do que existe e, então, mapear os processos, criar os use-cases, diagramas de classes e sequências, modelar e desenvolver em uma das N maneiras existentes.
Quando você programa um HelloWorld, aí sim, não precisa de nada disso, só criar a classe ou arquivo, compilar e rodar.
Exatamente drsmachado!
Na verdade são muitos termos para eu assimilar então posso ter escolhido o errado, mas é realmente isso, análise de requisitos.
Estou fazendo o possível para conhecer o negócio, nessa parte as entrevistas ajudaram pois entrevistei todos que cuidavam de ENTRADAS, minha idéia inicial era mapear as entradas, mapear os cenários dessas entradas e por último mapear as saídas. Pelo que você me falou eu não estava totalmente errado, mas acho que com o BPM isso vai ser mais completo.
Como eu disse, nas entrevistas cada um tinha uma visão de como fazer uma coisa, até implementamos uma certa padronização, mas acredito que isso só vai se consolidar com um sistema rodando.
Achei umas apresentações muito interessantes sobre Mapeamento de Processos no Slideshare, acham que é uma boa eu postar os links? Talvez possa ser útil para outros novatos como eu…
[quote=fggs]Exatamente drsmachado!
Na verdade são muitos termos para eu assimilar então posso ter escolhido o errado, mas é realmente isso, análise de requisitos.
Estou fazendo o possível para conhecer o negócio, nessa parte as entrevistas ajudaram pois entrevistei todos que cuidavam de ENTRADAS, minha idéia inicial era mapear as entradas, mapear os cenários dessas entradas e por último mapear as saídas. Pelo que você me falou eu não estava totalmente errado, mas acho que com o BPM isso vai ser mais completo.
Como eu disse, nas entrevistas cada um tinha uma visão de como fazer uma coisa, até implementamos uma certa padronização, mas acredito que isso só vai se consolidar com um sistema rodando.
Achei umas apresentações muito interessantes sobre Mapeamento de Processos no Slideshare, acham que é uma boa eu postar os links? Talvez possa ser útil para outros novatos como eu…
[/quote]
Para o BPM ter resultado, é preciso saber o mínimo sobre como o processo funciona.
Cada usuário irá falar do próprio conhecimento e isso acaba gerando ruído e poluição para a análise.
É fato que um sistema, quando implementado, irá atender a determinadas necessidades e acabar por suprimir outras.
De qualquer forma, você está no caminho certo.
Qualquer metodologia de desenvolvimento prega que você precisa levantar requisitos para começar, seja ela para desenvolvimento ágil ou “normal”.
O que eu tenho em mente hoje é me basear nas entrevistas para determinar como vai ser. Eu poderia simplesmente determinar como quero e pronto, mas acho que isso dificulta na hora do usuário interagir com o sistema, se ele está acostumado a efetuar uma tarefa de um jeito e ficar muito diferente no sistema, ele vai levar mais tempo para se familiarizar.
Talvez um meio termo ajude, porque realmente gera ruído e me deixa confuso.
Falou mais que a verdade, o pessoal prega que para vc valide os processos vc use como base uma reunião baseada em JAD, onde vc desenha o processo com os usuários chave de um processo presentes, assim vc evita que cada usuário desenho o processo do jeito que mais lhe interessa.
Vocês não tem idéia de como estou aprendendo com este tópico, não só para o meu projeto, como para toda minha empresa, assim como a vida. Li quase 200 páginas sobre o Aris e ele ajuda bastante a desenhar os cenários, não o conhecia, obrigado pela dica.
Se vocês não se importarem, vou formular um passo-a-passo para eu seguir, dai vocês comentam se estou entendendo corretamente os conceitos e se essa é a forma de obter o que eu preciso.
Trabalho melhor quando tenho um guia.
Obrigado mais uma vez pela participação de todos!
O Aris é uma plataforma que era da IDS scheer, a IDS foi adquirida pela Software AG que também é dona de uma plataforma muito bem conceituada a Webmethods. Além do Aris existem outras ferramentas para essa funcionalidade como o BPA da Oracle que é praticamente igual ao Aris foi desenvolvido na Argentina com ajuda de alguns consultores IDS Scheer aqui do Brasil, a Oracle fez uma parceria a nivel Global com IDS Scheer na epóca e o intuito era desenhar processos em EPC e migrar nativamente para BPEL ou XPDL.
No começo a migração era uma bosta e só se fazia via plugins, hj já melhorou bastante.
Os processos que vc desenhar no Aris assim como no BPA podem ser migrados para XPDL ou para BPEL através de um plugin que vc instala no Aris Business Architect .
[quote=DaviPiala]Eu acho que o ideal é começar pelos processos, um bom trabalho de BPM com Aris mapeando processos em EPC ou BPMN faz muita diferença. Se a empresa já possui um AS-IS de todos os processos, vc poderia gastar mais tempo do projeto planejando o TO-BE de todos os processos, nessa modelagem vc identifica quais são oportunidades de reusabilidade e se uma atividade é melhor aproveitada sendo completamente humana ou suportada por algum sistema ou funcionalidade.
Após esse trabalho com o TO-BE vc já tem um norte, fica mais fácil elaborar uma arquitetura de referência vc saberá com quais sistemas irá interagir e se os componentes que vc irá adicionar irão atender os processos.
Em paralelo ao trabalho de arquitetura pode ser tocado um mapeamento de requisitos funcionais a partir dos requerimentos gerados nos processos, os requisitos são o insumo para produção dos casos de uso e prototipação.
Após a definição dos Casos de Uso e com os processos a mão fica mais fácil produzir artefatos para desenho técnico, em paralelo a essa etapa acho que é possivel produzir o documentação para testes.
[/quote]
Qualquer semelhança…
http://www.marcoscintra.org/fabula_porcos.asp
Yvga oq vc quis dizer??
Eu quis dizer que tem muito processo, muita teoria, muita nomenclatura em algo que pode ser simples.
Emprestem do Lean o conceito de Menor Produto Avaliavel e ponham a mao na massa.
Levante alguns requisitos com o usuario, crie um prototipo ou uma implementacao simples do fluxo principal e leve para ele avaliar, corrija o que ele pedir e repita esse processo ate ter o produto pronto.
Só enfatizei que seria interessante gastar mais tempo em processo para não ter surpresas.
Modelar processo -> Requisitos -> Casos de Uso -> Desenvolvimento
Um monte de sigla quais? TO-BE e AS-IS?
Yvga, quase não há diferença da sua sugestão pra minha, a diferença está em se trabalhar por dominios e com small releases.