Devo usar métodos formais sobre meu projeto de software?

Question

O nosso cliente quer-nos a construir, uma aplicação de internet rica baseada em web para a coleta de requisitos de software. Basicamente, é uma ferramenta de caso baseado na web que segue um processo específico para obter os requisitos das partes interessadas. Eu sou o gerente de projeto e ainda estamos nas fases iniciais do projeto.

Eu estive pensando sobre o uso de métodos formais para ajudar a esclarecer os requisitos para a ferramenta tanto para o meu cliente e os desenvolvedores. Por métodos formais quero dizer alguma forma de modelagem, possivelmente algo baseado em matematicamente. Algumas das coisas que eu li sobre e está considerando incluir Z ( http://en.wikipedia.org / wiki / Z_notation ), máquinas de estados, UML 2.0 (possivelmente com extensões como OCL ), Petri redes , e algumas coisas de nível de codificação como contratos e pré e pós-condições. É outra coisa lá qualquer coisa que eu deva considerar?

Os desenvolvedores são experientes, mas dependendo do formalismo usado eles podem ter de aprender um pouco de matemática.

Eu estou tentando determinar se vale a pena enquanto para mim usar métodos formais neste projeto e em caso afirmativo, em que medida. Eu sei que "depende" de modo a maioria das respostas úteis para mim é um sim / não e apoiar argumentos.

Você usaria métodos formais se você estivesse nesse projeto?

Answer 1

Eu estive pensando sobre o uso de métodos formais para ajudar a esclarecer os requisitos para a ferramenta tanto para o meu cliente e os desenvolvedores.

Muito poucos desenvolvedores têm experiência formal de métodos. A única vez que eu vi os clientes com formação métodos formais eram membros da ZUG quando estávamos portando Cádiz para o Windows.

Por métodos formais quero dizer alguma forma de modelagem, possivelmente algo baseado em matematicamente. Algumas das coisas que eu li sobre e está considerando incluir Z ( http://en.wikipedia.org/ wiki / Z_notation ), máquinas de estados, UML 2.0 (possivelmente com extensões como OCL), redes de Petri, e algum material de nível de codificação como contratos e pré e pós-condições. É outra coisa lá qualquer coisa que eu deva considerar?

Há uma lacuna muito grande entre Z, que é um método formal, tendo sua base na teoria dos conjuntos, e UML, que é uma notação informal com algumas anotações semi-formais (máquinas de estado) marcadas por diante.

Alguns clientes técnicos, tais como você esperaria encontrar usando uma ferramenta de requisitos de software, são muito confortáveis ??com UML.

Pode haver valor criando um modelo Z do seu domínio, e pode haver valor na criação de um modelo pi-cálculo de suas mensagens entre cliente e servidor (ou petri-net, mas acho que pi é mais simples e mais poderoso ).

O que um modelo Z do seu domínio daria é uma implementação de conjunto independente de restrições de tipo, expressa com mais força do que o sistema de tipos de qualquer linguagem de implementação comum.

O que um modelo formal de suas mensagens lhe daria é a facilidade para executar análises para garantir que você faça atualizações não perder ou ficar conflitos ou bloqueios.

O que um modelo UML lhe dá é uma notação para quebrar um sistema grande para cima em áreas de função (diagramas do pacote), de mostrar como aulas nessas áreas se relacionam entre si estaticamente (diagramas de classe), de mostrar como instâncias dessas classes referem dinamicamente (sequência, actividade e diagramas de interação), e mostrando como os pacotes são implantados (componente e diagramas de implantação). Estes são úteis para a comunicação na equipe, e para obter ideias clarificado, um pouco, mas não tem semântica formalmente definidas que permite a análise muito sofisticado.

Os especialistas Z com quem trabalhei nos anos 90 consideraram a ideia de especificar um caso GUI em Z ridículo. Criando um modelo UML para tal GUI é comum.

Eu não usei pré formal de projeto-a-contrato e pós-condições, embora eu às vezes adicioná-los nos comentários, e freqüentemente em afirmações, e as condições de teste de unidade I, que pode violá-los.

Answer 2

A verdadeira pergunta a fazer aqui não é se a usá-los ou não, mas o que se ganha e perdeu.

Será que a produtividade e os resultados compensam a complexidade e aprendizagem necessárias?

Answer 3

Em geral, você deve usar o que a equipe está confortável com. Com novos itens lá vai ser uma curva de aprendizado, o que significa que vão ser perguntas sobre o processo e os erros cometidos. Parte do seu cronograma de desenvolvimento será usado para corrigir esses problemas, e se você não está pensando em usá-los com esta equipe no futuro, realmente você não vai ter um ganho a longo prazo através da introdução de algo novo. Mudança processo leva um longo tempo e muito trabalho.

Se você tiver tempo estimado suficiente para lidar com esses problemas que você pode estar ok ..... se sua estimativa está correta. Considerando-se que você não tenha trabalhado com essas pessoas (pelo menos é o que seus sons post como), as chances são de sua linha do tempo não vai ser tão preciso como deveria, que significa que você não poderia ter alocado tempo suficiente para terminar o projeto quanto mais a introdução de um novo processo.

A outra pergunta você tem que perguntar a si próprio é "o quão confortável você está com o processo que você deseja implementar?" Eu nunca tentar introduzir um novo processo em um projeto a menos que eu sei que posso puxar a equipa através dele se eu tiver que. Tentar coisas novas de vez em quando é bom, mas você precisa ter uma equipe que você está confortável com saber como navegar fora de uma situação apertada.

Answer 4

Eu estive olhando várias abordagens para métodos formais 'leves', para aplicações que podem ser de missão crítica, mas não a vida / segurança crítica. Algumas idéias:

• Alloy
• SysML
• SPIN
• Outros ???

Answer 5

Existem alguns exemplos de sucesso do uso ACSL (ANSI C Specification Language) que tem maduro conjunto de ferramentas a maioria dos quais são de código aberto como plataforma Porque, Frama-C. Para Java tecnologia similar chamada JML (Java Modeling Language). Eu acho que ambos são usados ??para pequenas e projetos de tamanho médio para aplicações embarcadas e ajudam a adicionar algumas garantias em seu código, mas não são destinadas a validar especificações. Z não é absolutamente fácil de usar e falta adequada IMHO suporte da ferramenta.

Entre as ferramentas comerciais que podem ser usadas em palcos de especificação Gostaria de olhar para plataforma de Rodin que é baseado em B-método.

Answer 6

No final do jogo aqui, mas você pode considerar algo como testável arquitetura através Savara que usamos para muitos projectos onde existe uma predominância de comunicação ou interacção entre os componentes. Isso geralmente é visto em qualquer backend SOA para uma interface web.

É formalmente baseada em pi-cálculo e você não precisa entender pi-cálculo para usá-lo.

Answer 7

Eu concordo totalmente com Tom e fazer a mesma pergunta,

Será que a produtividade e os resultados compensam a complexidade e aprendizagem necessárias?

Na minha opinião a menos que o sistema / software pode ser identificado como “críticos para a segurança” métodos formais são desnecessárias.

O médio de segurança crítica:

Quando a falha de um sistema de computador pode levar a conseqüências catastróficas, como a perda de vidas humanas, danos ao meio ambiente, ou danos no próprio, tal sistema é conhecido como “segurança-crítico” do sistema.

Answer 8

Concordo com Tom e Abufardeh -? Será que a produtividade e os resultados compensam a complexidade e aprendizagem necessária

Além disso, é este methd melhor para obter todos os requisitos antes de desenvolvimento (amd assegurar estes requisitos são bem definidas e testáveis)? Obtendo todas as exigências primeiro parece ser o senso comum, mas uma grande porcentagem de programas fazem coisas no pensamento paralelo não é nenhum problema para obter alguns requisitos mais tarde. Requisitos de fluência é um pesadelo! O filme "O Pentágono Wars" é um abrir de olhos para quem discorda.