Especificação Funcional

[Daniel_MV]

Pessoal uma das documentações mais utilizadas em projetos de software é a especificação funcional, contendo requisitos funcionais, não funcionais, casos de uso, etc…

Tirando os diagramas usuais desse tipo de documento, por exemplo, diagrama de caso de uso, aqui na minha empresa o pessoal tem mania de colocar diagrama de classes e diagrama de sequência na porra da funcional. Eu sempre fui veementemente contra a utilização desses diagramas (os últimos 2 citados) na espec. funcional, na minha opinião esses diagramas devem aparecer na especificação técnica.

A especificação funcional, deve servir para mostrar o que o software tem que fazer, e não como.

Ou seja, a funcional deveria ser, na minha opinião, um documento simples e de fácil entendimento e aprovação do usuário/cliente. E não um frankstein de 80 páginas.

Depois de muito brigar, convenci o pessoal a retirar outros diagramas que não servem para nada em funcional (Jacobson por exemplo, nem é uml compliance) , mas a porra dos diagramas de classe e de sequência eles querem que faça uma versão simplificada, ou seja, um modelo macro de como é a comunicação nas camadas. Porra, ai eu pergunto, para que fazer isso? Se não vai representar a sequência verdadeira dos passos? Só para encher linguiça?

Como é a funcional na empresa que vocês trabalham, quais documentações vocês utilizam?

Grato

[surfzera]

Cara concordo com tudo que você falo… aqui na empresa os procedimentos ainda são piores a documentação funcional até vem com os diagramas de classes etc… e quando vem sempre vem com problemas.

[FrancoC]

Realmente não é função de um Analista de Negócio modelar Classes de Análise, até porque geralmente são profissinais que não tem muita intimidade com o paradigma da Orientação a Objetos. Na verdade, até conhecem um pouco da coisa através de apostilas e curtas introduções do assunto em livros de programação e UML. Ou seja, conhecem mesmo somente aquele decoreba básico. Há um grande salto entre o conceito e a prática que somente uma experiencia rica e exaustiva é capaz consolidar esse conhecimento.

O A. N. poderia até esboçar ai um snapshot das principais entidades de negocio a serem abstraidas, mas de forma alguma esse rascunho deverá ir para um documento formal com o cliente.

Diagramas de Interação nessa fase do projeto chega a ser ridículo. Qualquer autor sério recomenda que sejam apenas iniciados após voce ter um modelo de classes maduro, com uma arquitetura do sistema já definida.

Se eles querem diagramas porque acreditam que com eles atingirão uma documentação robusta e completa para a fase seguinte do processo, eles devem se limitar aos Diagramas Comportamentais da UML. Assim um Diagrama de Atividades seria muito mais sensato. Contudo, deve-se alertar que diagramas de atividades estão se tornando obsoletos frente a semântica e notações da Modelagem de Processos de Negócio como BPMN, XPDL, BPEL, e outros. Os famosos Workflows permitem a integração entre o Modelo e o Sistema através de engines de gerenciamento, em curtas palavras: um canal de comunicação full-duplex entre o mundo do negócio e a aplicação.

Sem dúvida a fase de Analise de voces esta descabando para o amadorismo com trabalho impreciso, incorreto, excedente, desnecessario e inutil ao processo. O fato é que essa é a realidade de boa parte das pequenas e medias empresas do nosso setor. Depois quando falo em um Conselho Nacional regulamentando a produção se software no Brasil, entre outras atividades da TIC, os ingenuos e leigos da Eng. de SW se armam com suas falacias.

[Daniel_MV]

[quote=FrancoC]Realmente não é função de um Analista de Negócio modelar Classes de Análise, até porque geralmente são profissinais que não tem muita intimidade com o paradigma da Orientação a Objetos. Na verdade, até conhecem um pouco da coisa através de apostilas e curtas introduções do assunto em livros de programação e UML. Ou seja, conhecem mesmo somente aquele decoreba básico. Há um grande salto entre o conceito e a prática que somente uma experiencia rica e exaustiva é capaz consolidar esse conhecimento.

O A. N. poderia até esboçar ai um snapshot das principais entidades de negocio a serem abstraidas, mas de forma alguma esse rascunho deverá ir para um documento formal com o cliente.

Diagramas de Interação nessa fase do projeto chega a ser ridículo. Qualquer autor sério recomenda que sejam apenas iniciados após voce ter um modelo de classes maduro, com uma arquitetura do sistema já definida.

Se eles querem diagramas porque acreditam que com eles atingirão uma documentação robusta e completa para a fase seguinte do processo, eles devem se limitar aos Diagramas Comportamentais da UML. Assim um Diagrama de Atividades seria muito mais sensato. Contudo, deve-se alertar que diagramas de atividades estão se tornando obsoletos frente a semântica e notações da Modelagem de Processos de Negócio como BPMN, XPDL, BPEL, e outros. Os famosos Workflows permitem a integração entre o Modelo e o Sistema através de engines de gerenciamento, em curtas palavras: um canal de comunicação full-duplex entre o mundo do negócio e a aplicação.

Sem dúvida a fase de Analise de voces esta descabando para o amadorismo com trabalho excedente, desnecessario e inutil ao processo. O fato é que essa é a realidade de boa parte das pequenas e medias empresas do nosso setor. Depois quando falo em um Conselho Nacional regulamentando a produção se software no Brasil, entre outras atividades da TIC os ingenuos se armam com suas falacias.
[/quote]

Não poderia concordar mais.

O que observo como motivo chave para essa situação pelo menos no meu caso, é a falta de atualização do profissional. Os caras que hoje gerenciam minha área, são uns caras das antigas, programaram muito tempo em C++, antes do Java, naquela época que nem se tinha tanto conhecimento da OO. Programavam de maneira procedural em uma linguagem OO. Até hoje pensam que OO é herança, interface e classes, sendo que OO é uma filosofia que vai além de usar apenas os recursos de uma linguagem OO.

Acredito que hoje em projetos de software, tão importante quanto o conhecimento técnico é o conhecimento do negócio, tenho olhado com atenção para a técnica DDD , esses caras que falei nunca nem ouviram falar.