Pergunta

Então ...

Eu ensinar métodos formais em engenharia de software. Eu também ensino "metodologias ágeis". A maioria das pessoas parecem pensar que esta é contraditória. Acho que faz muito sentido ... Eu também trabalho para uma empresa, onde precisamos realmente fazer as coisas :) Enquanto eu possa aplicar meus pontos de habilidade ganhos em "especificação" em uma base dia-a-dia, o meu colegas normalmente fogem da palavra "formal".

Eu costumava pensar que isso era devido à maneira intrínseca aprendemos como programa: nós são geralmente conduzidos para encontrar uma solução de trabalho, não para entender o problema. Então eu pensei que isso era devido ao fato de que a maioria das pessoas da comunidade formal não são engenheiros, mas os matemáticos ou cientistas da computação. Hoje em dia, eu me pergunto se apenas porque o-métodos formais hide comunidade por trás algum tipo de lei "ofuscação", para usar todos os símbolos Unicode disponíveis, desenvolver activamente, ferramentas unesthetic rudes, e rir na cara de normas.

Sim, eu tenho movido a partir de uma "culpá-los" para um "responsabilizar-nos" perspectiva; -)

Então, minha pergunta é: Você usar qualquer tipo de métodos formais na sua empresa? você introduziu-los, ou eles eram pré-requisitos? Que técnicas você usa para limpar a névoa da matemática de medos das pessoas e incitá-los a usar métodos formais? O que você acha ferramentas atuais estão faltando para um uso mais geral?

Foi útil?

Solução

A chave para levar as pessoas a comprar em qualquer métodos ou metodologias é mostrar-lhes como ele resolve problemas que estão tendo. Se eles podem vê-lo vai tornar sua vida melhor que você tem uma chance muito melhorada de levá-los a adotar as técnicas.

E se você não pode mostrar-lhes que, talvez você queria adotar os métodos baseados na filosofia ao invés de praticidade. A menos que os outros compartilham sua filosofia, em seguida, você não vai chegar a lugar nenhum. E talvez você não deve.

Ao longo das décadas tem havido um grande número de metodologias. os mais novos sempre resolver as deficiências dos antigos, ainda projetos ainda ficar em apuros e falhar. Por quê? Porque as estrelas de rock que surgem com novas metodologias são estrelas do rock, e fizeram uma nova metodologia precisamente porque eles entendem as questões subjacentes e como aplicá-los. Aqueles que vierem depois tendem a seguir cegamente a receita, e ele não funciona tão bem.

Então eu acho que a melhor coisa é ensinar sobre os problemas subjacentes e, em seguida, mostrar como métodos vários tentar lidar com esses problemas. As diferenças de empresas, projetos e equipes é tão grande que ninguém metodologia pode ser aplicada com sucesso em todas as combinações. Aprender a escolher uma ferramenta apropriada e aplicá-lo bem é crucial.

Outras dicas

Obrigado por todas as contribuições. Eles são muito perspicaz. Permita-me chama um pouco (não levá-la pessoal, embora: -)

A maioria das pessoas parecem pensar que os métodos formais são apenas sobre a verificação do programa. Ou sistemas críticos. Isso pode ser verdade se seguirmos o clichê final:. Para provar que estamos fazendo o programa certo (validação V.S., que pede, como um contribuinte disse, se estamos fazendo o programa certo)

Mas considere modelo encontrar / ferramentas de verificação, como a Liga. Aprender a usar uma ferramenta como esta leva um ammount insignificante de tempo para qualquer um usado para UML e OO. Ainda assim, ele pode lhe dar uma visão imediata sobre o seu modelo. Ele geralmente não mais de 10 minutos leva para encontrar um contra-exemplo sobre um subconjunto pequeno o suficiente do modelo one tentando usar (e isso inclui descrevendo o modelo na Liga em primeiro lugar).

Tome Engenharia de Requisitos como um exemplo. Um normalmente desenhar um monte de UML. Poucas pessoas usam OCL, porém, e muitas regras de negócio são informalmente annoted em linguagem natural. Por quê? limitações de tempo?

Agora, considere o fato de que a maioria só usa seu / sua gut-sensação para provar que um modelo pode ser satisfeita. Mais uma vez, por quê? Eu posso tomar a mesma quantidade de tempo (provavelmente ainda menos, desde que eu não precisa se preocupar com a estética de desenho) para escrever esse modelo na Liga, e apenas verificar se há satisfiability? E que tipo de matemática que eu preciso agora? "Predicados"? nome fantasia para FI e booleans ;-) Quantifiers? nomes de fantasia para ForEachs () ...

E sobre grandes sistemas de informação? Eles não precisam de ser crítico ... Basta tentar analisar em sua cabeça um conceitual (não implementação!) Diagrama com mais de 600 classes. Vejo muita gente batendo a cabeça na parede com erros modelo fácil de fazer, porque eles perderam alguma restrição, ou o modelo permite que coisas estúpidas para acontecer.

O fato é que não é preciso usar abordagens formais da cabeça à cauda. Concedido, eu poderia ser um aplicativo inteiro em Coq, e certificar que ele é 100% compatível com alguma especificação. Esta pode ser a abordagem Scientist Computer / matemático.

Ainda assim, com um philisophy GTD, por que não posso delegar algumas tarefas para o computador e permitir que ele ajuda a melhorar o meu desenvolvimento? É realmente uma questão de "tempo", ou simples, simples falta de capacidade técnica e vontade de aprender / inovar?

Trabalho com a linha de desenvolvimento de negócios de TI em um meio de empresas que têm que transferir conhecimento sobre o negócio de pessoas de negócios reais na cabeça dos desenvolvedores. Enquanto eu me encontro matemática abstratas para ser um dos maiores passatempos existe, é uma ferramenta de comunicação terrível. E comunicação é o que é tudo sobre. Enquanto eu poderia concebivelmente ter algum sucesso convencer o pessoal de TI para abraçar notações mais abstratas, eu basicamente não tem chance com as pessoas de negócios.

Enquanto existem algumas áreas onde eu possa vê um papel para métodos formais em uma empresa (matemática e aos lógica-pesado software especialista, necessidade significativa de propriedades demonstráveis ??como em software de segurança crítica) eles fornecem pouca ajuda com a obtenção de requisitos corretos sobre por exemplo como cumprir uma ordem do cliente através da emissão de um ou mais pedidos de fornecimento de um conjunto de possíveis fornecedores externos ou internos.

Eu acho que o júri é ainda para fora em abordagens baseadas em modelo e linguagens específicas de domínio. Eu acho que eles vão ter sucesso ou falhar dependendo se eles fornecer feedback rápido de TI com os desejos e necessidades do lado do negócio, e se eles presumem empresários vai ter que fazer qualquer significativa estudando.

A tecnologia é fácil. A comunicação é difícil. métodos formais podem nos ajudar a fazer as coisas direito, mas aquelas que eu vi fazer nada para nos ajudar a fazer as coisas certas. (Sim, estes são clichês, mas isso é porque eles são inevitavelmente e dolorosamente verdadeiro.)

Eu estou tomando um curso sobre 'Especificação e Verificação'. Como parte da estrutura do curso que estão fazendo o seguinte- 1. ferramentas de aprendizagem como PVS (Sistema de Verificação Prototype) http://pvs.csl.sri.com/ e SMV (Software Modelagem e Verificação) http: //www.cs.cmu edu / ~ ModelCHECK / smv.html 2. Para além de que fazemos acidentes dissect que ocorreram devido a falhas de software. Por exemplo - Falta de Ariane V

Eu me sinto métodos formais são mais aplicáveis ??a situações em que o custo de falha não é mais do que o custo do projeto. E parece apto a usá-los para softwares sendo usados ??em sistemas críticos. Eu acho que ele é usado em aviônicos, design de chips etc e da indústria automobilística atual também está a elaborar-la em prática.

Eu tentei levar as pessoas a abraçar métodos de especificação formal algumas vezes (Z e liga) e fizeram a mesma experiencia que você tem: A maioria das pessoas, ao mesmo tempo sensação de que eles servem a um propósito útil, são muito desconfortável usá-los para trabalho real.

Engraçado o suficiente, as mesmas pessoas são mais do que feliz para produzir diagramas UML totalmente inútil em quantidades ginormous.

Eu acho que há duas razões principais para isso:

a.) Muitos desenvolvedores estão desconfortáveis ??com o nível de abstração exigido por uma abordagem formal. O fato de que a matemática mais entrada de nível de educação é tudo cálculo e não discretos-matemática pode ter que fazer alguma coisa com isso.

b.) Os métodos formais exigem um aproach projeto-se muito fundo onde você projetar seu modelo de núcleo a partir do solo e torná-lo hermético e, em seguida, conecte-se com as exigências reais do usuário, fornecendo uma interface em cima dela. Desde que tendem a ter exigências conduzir os esforços de desenvolvimento, uma abordagem top-down sente mais natural, embora muitas vezes leva a modelos inconsistentes. É como reequipamento um porão debaixo de sua casa depois que ele já foi construído.

Os métodos formais não fazem sentido em sistemas onde o custo do fracasso é baixo.

Em um aplicativo de produção web, você tem várias caixas de front-end, várias caixas de back-end, várias caixas de banco de dados - se um programa em qualquer um deles falhar, é um não-evento. Hardware é tão barato que você pode construir esses sistemas por muito menos do que o custo de especificar formalmente todos os seus softwares.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top