none
Documentação de projeto que relaciona processos

    Question

  • Pessoal

    Eu não sei onde postar isso, pois não sei que sub-área da tecnologia pode me ajudar
    talvez seria interessante estar em mais de um forum, pois o publico alvo é diferente...


    Aqui vai:

    estou procurando alguma forma de fazer uma documentação "interdependente"

    não sei como chamar isso, mas vou tentar explicar o que eu preciso, e no que estou pensando:
    (acho que todo mundo que desenvolve deve se preocupar com isso):

    documentar os modelos, fluxogramas, e processos, de maneira dinamica, que se consiga ligar uma coisa com outras.

    por exemplo: algum calculo ou formula que muda, passa a ter outro campo que interfere no calculo...
    ---> no momento em que se modificasse uma regra neste calculo, teria que dar erros em todos os lugares onde é feito esse calculo...
    eu precisaria saber todos os lugares do projeto onde tenho que alterar.

    Outro exemplo: modifica uma chave de uma tabela (passa de chave composta um campo ID passa a ser uma chave composta
    ---> Neste caso em especifico (que é bem simples, diga-se de passagem) é necessario alterar em todos os lugares do sistema que tratam a chave da tabela, seja para insert, delete, update, relacionamentos entre tabelas...
    (se o sistema é bem desenvolvido, usado uma ferramenta tipo EF ou NHibernate, q faciliataria o processo, daí já é outro assunto, gostaria de me ater a questão da documentação)

    Um exemplo o qual estou passando no momento:
    ---> Tenho uma rotina para carregar uma lista de bancos cadastrados no sistema. Agora surgiu a necessidade de, em determinados processos, carregar
    - Criei um novo campo "Inativo" no cadastro de bancos e fiz a manutenção nele para adicionar este campo.
    - Na rotina, criei um parametro (opcional) boleano para passar True quando quero que só carregue os bancos ativos, e adicionei este filtro, caso o parametro seja True.

    O que eu gostaria que acontecesse é, em todos os processos que esta alteração interfere (isso é, todos os lugares que é carregada a lista de bancos) emitissem um aviso.
    Isso tudo para garantir que eu verifiquei o processo, e que 'não passou em branco' sem eu avaliar se nestes processos seria necessario ou não passar o parametro True.
    Claro que neste caso é simples, é só eu verificar todos os lugares que chamo esta rotina de carregar a lista. Mas tem casos bem mais complicados de identificar tudo no sistema que sofre interferencia com uma alteração.

    ---

    Para elucidar melhor, seria algo parecido com os relacionamentos de um banco de dados, a integridade... o BD não vai deixar informar campos sem valor onde é 'not null', não deixa duplicar chave, etc etc, MAS, com a lógica do sistema em geral (processos, regras de negocio, estrutura de tabelas...)

    Isso seria muito interessante, uma forma "automatica", seria o ideal. No caso, teria que usar alguma ferramenta...

    Mas uma documentação, mesmo que manual se for o caso, que sempre seja atualizada conforme mudam as regras do negocio , a lógica do sistema, e a modelagem de dados, já seria suficiente.

    ---

    Resumindo, seria uma maneira de documentar todos os processos, com nivel de detalhe bem alto (até que dados do sistema precisam ser informados etc etc), e que me gerasse ERRO nos processos que sofrem interferencia de alguma modificação que seja feita.

    - Não conheço muito de UML, mas imagino que não chega a este nivel...
    - Não sei muito bem tambem como funciona os projetos com o Workflow Foundation.

    Isso que gostaria de discutir.
    • Moved by AndreAlvesLimaMVP Thursday, July 14, 2011 1:02 PM (De:Onde devo postar minha dúvida?)
    Wednesday, July 13, 2011 8:48 PM

Answers

  • Julio,

     

        Sugiro que estude UP (ou processo unificado) além de UML (se já não conhece).

        Depois disso, sugiro a ferramenta Enterprise Architect. (http://www.sparxsystems.com/)

        Vou resumir o processo para que veja como pode (questão de opinião, ok?) trabalhar. O UP (ou RUP) sugere que você tenha uma lista de requisitos inicial (não é só isso, mas só para dar uma idéia). Estes requisitos serão divididos em funcionais (cor, formato de tela, quais dados e regras) ou não funcionais (segurança, performance, qual o banco de dados, etc).

        Com esta lista e muitas reuniões você cria um protótipo (FUNCIONAL ou NÂO). Para o seu caso, sugiro o não funcional (CASOS DE USO e a Especificação de Casos de Uso). Este documento quando bem escrito e com imagens de telas em rascunho permite que você converse tanto com os desenvolvedores quanto com os usuários.

        Ok, e onde entra o EA? O software permite que você crie um diagrama de Interface com o usuário (para prototipar as telas e dizer a navegação delas). Depois você pode criar o diagrama de casos de uso, informar regras de negócio, e criar o modelo de dados.

        Com isso, você consegue criar dependências com a propria ferramenta. Por exemplo dizendo que o requisito de "Permitir ao cliente dizer o nome" foi atendido pelo caso de uso "Manter Cliente" e depende da tabela "Cliente".

        Veja que para isso TUDO deve estar no EA (inclusive perfiro o Erwin para modelo de dados, mas acabei acostumando com o EA por "imposição" da ferramenta).

        O processo é manual, mas você consegue relacionar os diferentes modelos (Classes, Casos de Uso, MER, etc). E caso tenha uma alteção, sugiro que aprove a alteração na especificação de casos de uso (protótipo) com o usuário e depois altere os diferentes objetos e modelos no EA. Assim você consegue "mensurar" os impactos "manualmente".

       Dá bastante trabalho, mas dependendo do tamanho/prazo de seu projeto, é possível.

     

    Att,

    Ricardo

     

     

    Thursday, July 14, 2011 9:46 PM

All replies

  • então, talvez o pessoal do sql server possa dar alguma ideia,

    o pessoal q desenvolve em .net outras,

     

    acho até que o mais adequado seria no "Arquitetura de soluções", mas fico preocupado em pouca gente ver o problema... de repente a forma de solucionar seja com uma tecnologia de especialidade de outro fórum...

     

    alias, essa duvida para mim é bem recorrente, visto que é usual eu postar problemas meio "genéricos" que não sei qual tecnologia pode ajudar.

     

     

    Enfim, se alguem puder ajuda...

    Obrigado


    Wednesday, July 13, 2011 8:51 PM
  • Julio,

    Acredito que realmente a categoria mais adequada ao seu problema seria o de Arquitetura de Soluções... Vou migrar sua thread para lá...


    André Alves de Lima
    Microsoft MVP - Client App Dev
    Visite o meu site: http://www.andrealveslima.com.br
    Me siga no Twitter: @andrealveslima
    Thursday, July 14, 2011 1:01 PM
  • Obrigado, Andre!
    Thursday, July 14, 2011 8:31 PM
  • Julio,

     

        Sugiro que estude UP (ou processo unificado) além de UML (se já não conhece).

        Depois disso, sugiro a ferramenta Enterprise Architect. (http://www.sparxsystems.com/)

        Vou resumir o processo para que veja como pode (questão de opinião, ok?) trabalhar. O UP (ou RUP) sugere que você tenha uma lista de requisitos inicial (não é só isso, mas só para dar uma idéia). Estes requisitos serão divididos em funcionais (cor, formato de tela, quais dados e regras) ou não funcionais (segurança, performance, qual o banco de dados, etc).

        Com esta lista e muitas reuniões você cria um protótipo (FUNCIONAL ou NÂO). Para o seu caso, sugiro o não funcional (CASOS DE USO e a Especificação de Casos de Uso). Este documento quando bem escrito e com imagens de telas em rascunho permite que você converse tanto com os desenvolvedores quanto com os usuários.

        Ok, e onde entra o EA? O software permite que você crie um diagrama de Interface com o usuário (para prototipar as telas e dizer a navegação delas). Depois você pode criar o diagrama de casos de uso, informar regras de negócio, e criar o modelo de dados.

        Com isso, você consegue criar dependências com a propria ferramenta. Por exemplo dizendo que o requisito de "Permitir ao cliente dizer o nome" foi atendido pelo caso de uso "Manter Cliente" e depende da tabela "Cliente".

        Veja que para isso TUDO deve estar no EA (inclusive perfiro o Erwin para modelo de dados, mas acabei acostumando com o EA por "imposição" da ferramenta).

        O processo é manual, mas você consegue relacionar os diferentes modelos (Classes, Casos de Uso, MER, etc). E caso tenha uma alteção, sugiro que aprove a alteração na especificação de casos de uso (protótipo) com o usuário e depois altere os diferentes objetos e modelos no EA. Assim você consegue "mensurar" os impactos "manualmente".

       Dá bastante trabalho, mas dependendo do tamanho/prazo de seu projeto, é possível.

     

    Att,

    Ricardo

     

     

    Thursday, July 14, 2011 9:46 PM
  • Ricardo

     

    desde já agradeço a sua atenção,

    vc entendeu o que preciso, o meu problema, e como eu já pensava, não há uma solução "magica", e a resolução é algo complexo e trabalhoso..

    "O processo é manual, mas você consegue relacionar os diferentes modelos (Classes, Casos de Uso, MER, etc). E caso tenha uma alteção, sugiro que aprove a alteração na especificação de casos de uso (protótipo) com o usuário e depois altere os diferentes objetos e modelos no EA. Assim você consegue "mensurar" os impactos "manualmente"."

    é bem isso mesmo que é a minha idéia...

     

    prazo, como sempre é apertado, mas estou definindo tudo como vai ser, antes de começar

    Vou dar uma boa estudada nesses itens :)

     

     

    Se alguem tiver mais sugestões..

     

    Obriagdo!

    Monday, July 18, 2011 1:53 PM
  • "Com isso, você consegue criar dependências com a propria ferramenta. Por exemplo dizendo que o requisito de "Permitir ao cliente dizer o nome" foi atendido pelo caso de uso "Manter Cliente" e depende da tabela "Cliente"."

     

    é bem por aí, mesmo...

     

    o RUP e essa ferramenta tem algo a ver com as metodologias ágeis, ou isso é outra coisa?

    Monday, July 18, 2011 2:00 PM
  • Julio,

        Um pouco de história... rss...

        Era uma vez 3 caras.... um "inventou" um diagrama para ajudar no desenvolvimento, outro outros diagramas e o último uma maneira de "conversar" com os usuários através de algo que pudessem entender (casos de uso e diagramas). Chamaram UML. Posteriormente receberam ajuda e criaram um processo chamado UP (Processo Unificado).

        O processo "pegou" e uma empresa chamada Rational "contratou" os caras, modificou/aperfeiçoou o processo e chamou RUP (Rational Unified Process / Processo Unificado Rational). Depois disso, foram só "ajustes" (isso é opinião pura, ok?). Veja:

        RUP - Mal compreendido (em minha opinião), pois a UML 2.0 tem 13 diagramas e o processo mais alguns. Muito pensam que é necessário criar TUDO para cada TELINHA do programa. O entendimento está errado, o RUP diz claramente: Aconselhamos criar os diagramas de apoio para itens com COMPLEXIDADE ALTA. Ou seja, tudo o que é mais complexo deve ser melhor detalhado. Não tem sentido criar 13 diagramas para 20 telas de cadastro IGUAIS em funcionamento e sabendo que TODAS manipulam apenas 1 tabela no banco de dados. O "defeito" do RUP são as interações, se não houver não funciona.

        XP ou Extreme Programming - 2 Desenvolvedores em uma máquina. Um programa e o outro aponta erros. Sem documentação alguma. PORÉM, se for algo complexo: Cria-se diagramas, casos de uso, etc para diminuir a complexidade e visualizar o problema.

        SCRUM, Ágile e outras do momento - Dividiram o RUP em subprojetos. Ou seja, o RUP sugeria "interações" com o usuário (para que ele acompanhe o desenvolvimento e para diminuir a chance de ter um monte de coisas para alterar no final) num desenvolvimento em cascata. O ágile sugere que você inicie o projeto dividindo em partes de 1, 2, 3 ou 4 semanas. E acompanhe estas partes como se fossem pequenos projetos (com documentação (planejamento), levantamento de requisitos, projeto, codificação, teste e documentação).

        TODOS estes utilizam a UML como base. Todos se baseiam na conversa com os usuários (as chamadas interações). O objetivo principal é saber que: VAI MUDAR. Um projeto sempre VAI mudar e deve ser feito para isso. Design Patterns, modelos de desenvolvimento e processos visam ajudar nessas mudanças ENQUANTO o projeto está sendo desenvolvido.

     

    Falei d+, rss.

    Ricardo

     

     

     

    Tuesday, July 19, 2011 11:58 AM