コール フローを記述し、描画し、音声 XML 開発でモデル化するために、どのツールを使用しますか? このようなダイアグラムやモデルを描くのに最も便利なエディタは何ですか? [音声アプリケーションの設計のための特定のツールはないように思います] ? プロの音声アプリ開発では、どのブロックを使用してプロンプトや文法を描画しますか?
質問する
290 次
1 に答える
1
資料の対象者が誰であるかについて言及していないことに注意してください。そのため、あなたは会社の開発側にいて、ビジネス/顧客のために文書化していると想定しています。
コール フロー ダイアグラムを描画するために、Visio は企業スペースで使用される最も一般的なツールです。小規模なアプリケーションでは、実際にはブロック単位でプロンプトが表示される場合がありますが、通常、ダイアグラムはアプリケーションの概要を示すためにのみ使用されます。たとえば、メイン メニュー プロンプトには選択肢がリストされますが、すべてのバリエーションや再試行がリストされるわけではありません。ブロック間の接続は通常、すべてのエラー パスやすべてのグローバル出口ではなく、主要なパスに限定されます。また、決定は通常、顧客タイプの識別などの主要なビジネス ロジックの決定のみを反映します。
プロンプトと詳細なコール フローは通常、Word で行われます。Word ドキュメントは、仕様の中核を形成します。一部のグループは、ホスト/データ関連のアクティビティからコール フローの用語とインターフェイス ドキュメントを分離していますが、分離していないグループもあります。
文法に関しては、少なくとも自然言語 (NL) 文法については、通常、伝統的な意味で文書化されていません。簡単な DTMF 文法は、上記のドキュメントのメニュー選択から推測できます。通常、自然言語文法は、大量の標準的なフィラー (「I want」、「Please」、「May I」など) を含むプロンプトによって暗示される単語/句の一般的なセットから始まります。NL アプリケーションでは、通常、最初のパスは、録音された発話を大量に収集することであり、その後、文字起こしされます。録音と書き起こしは、チューニング プロセスで使用され、発呼者の発言に一致するように文法の選択肢を強化し、未使用のパスを排除して精度を高めます。チューニング プロセスには他にも多くの手順があります。
ドキュメントをコードにリンクするさまざまな試みを見てきました。それほど成功しているようには見えません。自動的に生成された文書化された、またはソース文書は、通常、ビジネス ユーザーにとって混乱を招くものです。たとえば、ある状態からの 50 の出口点を見たくありません。彼らは、顧客に伝えられた 5 つのことを確認したいと考えています。その後、どこか別の場所で、グローバルな選択肢または州固有のエスケープ フレーズとその宛先 (キャンセル、戻る、再起動) を参照します。
于 2009-12-26T14:48:20.557 に答える