Dovrei usare metodi formali sul mio progetto di software?

Question

Il nostro cliente ci vuole costruire un web-based, Rich Internet Application per i requisiti software di raccolta. Fondamentalmente si tratta di un caso di strumento web-based che segue un processo specifico per ottenere i requisiti delle parti interessate. Sono il responsabile del progetto e siamo ancora nelle prime fasi del progetto.

Ho pensato di usare metodi formali per contribuire a chiarire i requisiti per lo strumento sia per il mio cliente e gli sviluppatori. Con metodi formali intendo una qualche forma di modellazione, forse qualcosa matematicamente-based. Alcune delle cose che ho letto su e stanno prendendo in considerazione comprendono Z ( http://en.wikipedia.org / wiki / Z_notation ), macchine a stati, UML 2.0 (eventualmente con estensioni quali OCL ), reti di Petri , e alcune cose a livello di codifica, come contratti e pre e condizioni postali. C'è qualcos'altro che devo considerare?

Gli sviluppatori sono esperti ma a seconda del formalismo utilizzato potrebbero dover imparare un po 'di matematica.

Sto cercando di determinare se vale la pena, mentre per me di utilizzare metodi formali su questo progetto e, se sì, in quale misura. So che "dipende" in modo che le risposte più utili per me è un sì / no e sostenere argomenti.

useresti metodi formali se si fosse su questo progetto?

Answer 1

  

Ho pensato di usare metodi formali per contribuire a chiarire i requisiti per lo strumento sia per il mio cliente e gli sviluppatori.

Molto pochi sviluppatori hanno formale esperienza metodi. L'unica volta che ho visto i clienti con la formazione metodi formali erano membri del ZUG quando siamo stati porting di Cádiz a Windows.

  

Con metodi formali intendo una qualche forma di modellazione, forse qualcosa matematicamente-based. Alcune delle cose che ho letto su e stanno prendendo in considerazione comprendono Z ( http://en.wikipedia.org/ wiki / Z_notation ), macchine a stati, UML 2.0 (possibilmente con estensioni come OCL), reti di Petri, e alcune cose a livello di codifica, come contratti e le condizioni pre e post. C'è qualcos'altro che devo considerare?

C'è un grande divario tra Z, che è un metodo convenzionale, prendendo la sua base nella teoria degli insiemi, e UML, che è una notazione informale con alcune notazioni semiformali (macchine a stati) codificati sulla.

Alcuni clienti tecniche, come ad esempio ci si aspetterebbe di trovare utilizzando uno strumento di requisiti software, sono a proprio agio con UML.

Ci può essere il valore creando un modello Z del dominio, e ci può essere valore nella creazione di un modello di pi-calcolo della messaggistica tra client e server (o Petri-net, ma trovo pi è più semplice e più potente ).

Quello che un modello Z del proprio dominio darebbe è un'implementazione insieme indipendente di vincoli di tipo, espresso in modo più forte di quanto il sistema di tipi di qualsiasi linguaggio di implementazione comune.

Quello che un modello formale di messaggistica darebbe è la possibilità di eseguire le analisi per essere sicuri di non perdere gli aggiornamenti o ottenere conflitti o deadlock.

Che modello UML ti dà è una notazione per la rottura di un sistema di grandi dimensioni fino in aree funzionali (diagrammi dei package), di mostrare come le classi in quelle aree in relazione tra loro (diagrammi di classe) staticamente, di mostrare come le istanze di quelle classi riguardare dinamicamente (sequenza, attività e diagrammi di interazione), e mostra come i pacchetti vengono distribuiti (componente e diagrammi di distribuzione). Questi sono utili per la comunicazione nella squadra, e per avere idee concretizzati un po ', ma non hanno la semantica formalmente definiti, che permette l'analisi molto sofisticata.

Gli specialisti Z con cui ho lavorato negli anni '90 prese in considerazione l'idea di specificare una GUI CASE in Z ridicolo. La creazione di un modello UML per un tale GUI è all'ordine del giorno.

Non ho usato le condizioni formali di progettazione per contratto pre e post, anche se a volte li aggiungo nei commenti, e spesso in asserzioni e condizioni di prova unità I che potrebbero violarli.

Answer 2

La vera domanda da qui non è se usarli o no, ma ciò che si guadagna e perso.

Sarà la produttività e l'esito superare la complessità e l'apprendimento necessaria?

Answer 3

In generale è necessario utilizzare quello che la squadra sta bene con. Con i nuovi elementi ci sta per essere una curva di apprendimento, che significa che ci stanno per essere domande sul processo e gli errori commessi. Parte della vostra timeline di sviluppo sarà utilizzato per correggere questi problemi, e se non ha intenzione di essere utilizzate con questa squadra, in futuro, in realtà non si sta andando ad avere un guadagno a lungo termine con l'introduzione di qualcosa di nuovo. Modifica processo richiede molto tempo e un sacco di lavoro.

Se si è stimato il tempo sufficiente per gestire questi problemi si potrebbe essere ok ..... se la stima è corretta. Considerando che non avete lavorato con queste persone (almeno questo è ciò che il tuo post suona come), è probabile che la vostra timeline non sta per essere più precisi come dovrebbe significare che non si poteva avere assegnato abbastanza tempo per completare il progetto per non parlare di introduzione di un nuovo processo.

L'altra questione si deve chiedere la vostra auto è "come comodo sono con il processo che si desidera implementare?" Non cerco mai e di introdurre un nuovo processo su un progetto se non so che posso tirare la squadra attraverso di essa se devo. Provare cose nuove di tanto in tanto è buona, ma è necessario avere una squadra che hai dimestichezza con sapere come navigare fuori da una situazione tesa.

Answer 4

Ho cercato in diversi approcci ai metodi formali 'leggeri', per le applicazioni che possono essere mission-critical, ma non la vita / sicurezza critici. Alcune idee:

• Lega
• SysML
• SPIN
• Altri ???

Answer 5

Ci sono alcuni esempi di successo di utilizzo ACSL (ANSI C Specification Language), che ha insieme maturo di strumenti maggior parte dei quali sono Open Source come ad esempio perché la piattaforma, Frama-C. Per una tecnologia simile Java chiamata JML (Java Modeling Language). Credo che entrambi sono usati per le piccole e medie dimensioni progetti per applicazioni embedded e aiutano aggiungere alcune garanzie nel codice, ma non sono finalizzate alla validazione specifiche. Z non è assolutamente facile da usare e manca un adeguato strumento di supporto IMHO.

Tra gli strumenti commerciali che possono essere utilizzati su fasi specifiche Vorrei guardare in piattaforma di Rodin che si basa su B-metodo.

Answer 6

alla fine del gioco qui, ma si potrebbe prendere in considerazione qualcosa di simile a architettura verificabili attraverso Savara che usiamo per molti progetti in cui v'è una predominanza di comunicazione o interazione tra i componenti. Questo è più spesso visto in qualsiasi backend SOA ad un'interfaccia web.

E 'formalmente messo a terra in pi-calcolo e non c'è bisogno di capire pi-calcolo per usarlo.

Answer 7

Sono d'accordo totalmente con Tom e la stessa domanda,

Sarà la produttività e l'esito superare la complessità e l'apprendimento necessaria?

A mio parere meno che il sistema / software può essere identificato come “safety-critical” metodi formali non sono necessarie.

Quali media safety-critical:

Quando il fallimento di un sistema informatico può portare a conseguenze catastrofiche, come la perdita di vite umane, danni all'ambiente o danni al sistema stesso, tale sistema è noto come “safety-critical”.

Answer 8

Sono d'accordo sia con Tom e Abufardeh - Will la produttività e l'esito superare la complessità e l'apprendimento necessario

?

Inoltre, è presente methd meglio per ottenere tutti i requisiti prima di sviluppo (AMD garantire questi requisiti sono entrambe ben definiti e verificabili)? Ottenere tutti i requirments primo sembra il senso comune, ma una grande percentuale di programmi di fare le cose nel modo di pensare in parallelo non è un problema per ottenere alcuni requisiti più tardi. Requisiti scorrimento è un incubo! Il film "Il Pentagono guerre" è un aprire gli occhi a chi non è d'accordo.