5

私たちのクライアントは、ソフトウェア要件を収集するための Web ベースのリッチ インターネット アプリケーションを構築することを望んでいます。基本的には、利害関係者から要件を取得するための特定のプロセスに従う Web ベースのケース ツールです。私はプロジェクト マネージャーで、まだプロジェクトの初期段階にあります。

クライアントと開発者の両方にとってツールの要件を明確にするために、形式的な方法を使用することを考えていました。正式な方法とは、何らかの形のモデリング、おそらく数学に基づくものを意味します。Z ( http://en.wikipedia.org/wiki/Z_notation )、ステート マシン、UML 2.0 (おそらくOCLなどの拡張機能を使用)、ペトリ ネット、およびいくつかのコーディングについて読んだことがあり、検討していることもあります。契約や前後の条件などのレベルのもの。他に考慮すべきことはありますか？

開発者は経験豊富ですが、使用する形式によっては、数学を学ぶ必要がある場合があります。

このプロジェクトで形式的な方法を使用する価値があるかどうか、もしそうならどの程度の価値があるかを判断しようとしています。私は「場合による」ことを知っているので、私にとって最も役立つ答えは、はい/いいえとそれを裏付ける議論です。

あなたがこのプロジェクトに参加した場合、正式な方法を使用しますか?

4

8 に答える 8

10

クライアントと開発者の両方にとってツールの要件を明確にするために、形式的な方法を使用することを考えていました。

フォーマルメソッドの経験を持つ開発者はほとんどいません。CADiZを Windows に移植していたときの ZUG のメンバーだけが、フォーマル メソッドのトレーニングを受けているクライアントを見たことがあります。

正式な方法とは、何らかの形のモデリング、おそらく数学に基づくものを意味します。Z ( http://en.wikipedia.org/wiki/Z_notation )、ステート マシン、UML 2.0 (おそらく OCL などの拡張機能を使用)、ペトリ ネット、およびいくつかのコーディングについて読んだことがあり、検討していることもあります。契約や前後の条件などのレベルのもの。他に考慮すべきことはありますか？

集合論に基づいた正式な方法である Z と、いくつかの準正式な表記法 (ステート マシン) がタグ付けされた非公式な表記法である UML の間には、非常に大きなギャップがあります。

ソフトウェア要件ツールを使用して見つけることが期待されるような一部のテクニカル クライアントは、UML に非常に慣れています。

ドメインの Z モデルを作成することには価値があるかもしれませんし、クライアントとサーバー (またはペトリネット、しかし私は pi の方が単純で強力だと思います) 間のメッセージングの pi 計算モデルを作成することにも価値があるかもしれません。

ドメインの Z モデルが提供するのは、一般的な実装言語の型システムよりも強力に表現された、実装に依存しない型制約のセットです。

メッセージングの正式なモデルが提供するものは、分析を実行して、更新が失われたり、競合やデッドロックが発生したりしないようにするための機能です。

UML モデルが提供するのは、大規模なシステムを機能領域に分割するための表記法 (パッケージ図)、それらの領域内のクラスが互いに静的に関連する方法を示すための表記法 (クラス図)、それらのクラスのインスタンスが動的に関連する方法を示すための表記法です (シーケンス図、アクティビティ図、相互作用図)、およびパッケージの展開方法の表示 (コンポーネント図と展開図)。これらは、チーム内のコミュニケーションやアイデアを少し具体化するのに役立ちますが、非常に洗練された分析を可能にする正式に定義されたセマンティクスはありません。

私が 90 年代に一緒に働いていた Z スペシャリストは、Z で CASE GUI を指定するという考えはばかげていると考えていました。このような GUI の UML モデルを作成することは一般的です。

正式な契約前および事後条件の設計は使用していませんが、コメントに追加することもあれば、アサーションに頻繁に追加することもあり、それらに違反する可能性のある条件を単体テストします。

于 2009-04-09T20:00:59.690 に答える
1

成熟したツールセットを備えたACSL（ANSI C仕様言語）を使用した成功例がいくつかあります。そのほとんどは、Whyプラットフォーム、Frama-Cなどのオープンソースです。JML（Java Modeling Language）と呼ばれるJava同様のテクノロジーの場合。どちらも組み込みアプリケーションの小規模から中規模のプロジェクトに使用されており、コードにいくつかの保証を追加するのに役立ちますが、仕様の検証を目的としたものではないと思います。Zは絶対にユーザーフレンドリーではなく、適切なツールサポートIMHOが不足しています。

仕様段階で使用できる商用ツールの中で、B-methodに基づくRodinプラットフォームを調べます。

于 2010-12-17T07:15:11.530 に答える
1

ここで真の問題は、それらを使用するかどうかではなく、何を得て何を失うかです。

生産性と結果は、必要な複雑さと学習を上回りますか?

于 2009-04-09T19:34:19.227 に答える
1

一般に、チームが使い慣れているものを使用する必要があります。新しいアイテムを使用すると、学習曲線が発生します。つまり、プロセスに関する質問や間違いが発生します。開発タイムラインの一部は、これらの問題を修正するために使用されます。将来、このチームでそれらを使用する予定がない場合は、新しいものを導入しても長期的な利益は得られません。変更プロセスには長い時間と多くの作業が必要です。

これらの問題を処理するのに十分な時間を見積もっている場合は、大丈夫かもしれません....あなたの見積もりが正しければ. あなたがこれらの人々と仕事をしたことがないことを考えると (少なくともあなたの投稿はそのように聞こえます)、タイムラインが本来あるべきほど正確ではない可能性があります。つまり、プロジェクトを完了するのに十分な時間を割り当てられなかった可能性があります。新しいプロセスの導入は言うまでもありません。

自分自身に尋ねなければならないもう 1 つの質問は、「実装したいプロセスにどの程度満足していますか?」ということです。必要に応じてチームを引っ張ることができることがわかっていない限り、プロジェクトに新しいプロセスを導入しようとはしません。時々新しいことを試すのは良いことですが、窮屈な状況から抜け出す方法を知るためには、慣れ親しんだチームが必要です。

于 2009-04-09T19:36:24.773 に答える
1

ここではゲームの後半ですが、コンポーネント間の通信や相互作用が優勢な多くのプロジェクトで使用する、Savara を介したテスト可能なアーキテクチャのようなものを検討するかもしれません。これは、Web フロントエンドへの SOA バックエンドで最もよく見られます。

公式には円周率計算に基づいており、使用するために円周率計算を理解する必要はありません。

于 2010-04-06T17:51:55.300 に答える
0

私はトムに完全に同意し、同じ質問をします。

生産性と結果は、必要な複雑さと学習を上回りますか?

私の意見では、システム/ソフトウェアが「安全上重要」であると識別できない限り、正式な方法は不要です。

安全上重要な意味:

コンピュータシステムの障害が、人命の損失、環境への損害、またはシステム自体への損害などの壊滅的な結果につながる可能性がある場合、そのようなシステムは「セーフティクリティカル」として知られています。

于 2009-04-09T20:40:43.153 に答える
0

私は Tom と Abufardeh の両方に同意します - 生産性と結果は複雑さと必要な学習を上回るでしょうか?

また、この方法は、開発前にすべての要件を取得するのに適していますか(これらの要件が明確に定義され、テスト可能であることを確認します)? 最初にすべての要件を取得することは常識のように思えますが、大部分のプログラムは、いくつかの要件を後で取得しても問題ないと考えて、並行して処理を実行します。要件クリープは悪夢です! 映画「ペンタゴン・ウォーズ」は、同意しない人にとっては目を見張るものです。

于 2009-04-20T13:13:20.933 に答える