概念:
|
概念 |
ユーザビリティ エンジニアリング (または、ユーザー指向の設計) は、エンドユーザーの理解を深め、要求、ユーザー インターフェイス設計、テスト作業にユーザーを参加させることで、よりよいシステムを構築する技術です。基本概念は、「概念: ユーザー指向の設計」で説明しています。先に進む前に読んでおいてください。ここでは、RUP (Rational Unified Process) が現在ユーザービリティ エンジニアリングをどのように扱っているかを説明します。
RUP には、使いやすさに関しての多くの役割があります。システム分析者、ユース ケース定義者には、ユーザー、ユーザーのタスク、ユーザーの環境に関する情報を収集して分析する技術、これらを要求やの成果物から取得する技術が必要です。この資料は、要求レビュー担当者.テスト担当者と
テスト分析者の役割は、使いやすさのテストに責任を持ちます。ユーザー インターフェイス設計者は、ユーザー インターフェイスの設計と「外見」に責任を持ちます。実装担当者は、ユーザー インターフェイスを選択または開発して、機能的なユーザー インターフェイスを構築します。
プロジェクト 管理者にも重要な役割があります。プロジェクト管理者は、ユーザーが開発環境を利用できるようにし、使いやすいシステムを構築するために必要なスキルを持つ要員で開発組織を組織します。導入管理者、
コース開発者、、
テクニカル ライターなどにも、導入システムを使いやすくするための責務があります。
次に、RUP の基本プロセス ワークフローを、使いやすさで最も重要な作業と成果物の面から説明します。
使いやすさの面から、要求の基本プロセス ワークフローでは次の点に注目します。
具体的な作業と成果物は次のとおりです。
作業
|
成果物 |
使いやすさに関する内容 |
利害関係者の要望の顕在化 | 利害関係者の要望 |
この作業には、ユーザーへのインタビュー、アンケート、検討会議の開催が含まれます。ユーザーとユーザー環境への理解を深めます。次の作業が含まれます。
|
開発構想書の作成 | 開発構想書 |
開発構想書テンプレートの「ユーザー環境」では、エンドユーザーの作業環境や、ISO の環境コンテキストを説明します [ISO 13407]。 開発構想書テンプレートの「ユーザー プロファイル」では、ユーザーの専門領域、技術的な背景、責任、成功の条件、納品可能物などを説明します。これは、ISO でユーザー コンテキストと呼ばれます [ISO 13407]。 |
アクターとユース ケースの獲得、ユース ケース モデルの構成、ユース ケースの詳細の作成 | ユース ケース モデル |
ユース ケース モデルは、ユーザー (人間のアクター) が実行するタスク (ユース ケース) を表します。汎化関係を使用して、アクター間の類似性や関係を把握します。アクターはユース ケースに関連付けられます。Constantine の 「役割モデル」と同様です [CON99]。ユース ケースは、コミュニケーション関連、包含、汎化、拡張の関係を通して構成され、相互に、またはアクターに関係付けられます。 検討会議は、ユーザーを参加させるための適切な方法です。「 |
人間のアクターの特性は、アクターの属性として把握されます。これには、次のものがあります。
|
||
Constantine の参考資料 [CON99] で説明されている、基底ユース ケースが含まれます (基底ユース ケースについて詳しくは、「概念: ユーザー指向の設計」を参照してください)。特定のユース ケースの具体的な使いやすさに関する要求は、![]() |
||
ソフトウェア要求の詳細の作成 | 補足仕様書では、ユース ケースで指定されていない要求を把握します。これには、使いやすさに密接に関連する、利用可能性や性能に関する要求が含まれます。複数のユース ケースに適用される一般的な使いやすさに関する要求は、適用される法規や使いやすさの標準と共に、ここで把握されます (使いやすさに関する法規と標準について詳しくは、「概念: ユーザー指向の設計」を参照してください)。 | |
要求のレビュー | 変更依頼 | ユーザー指向の開発作業では、すべての要求レビューに可能な限りユーザーを参加させます。 |
共通語彙の把握 | 用語集 | ユーザーの問題領域に固有な共通語彙を把握し、ユーザーとその他の開発チーム間のコミュニケーションと理解を促進します。 |
この基本ワークフローの多くの作業では、ユーザー インターフェイスの具体化や設計に集中します。これらを次に示します。
作業
|
成果物 |
使いやすさに関する内容 |
ユーザー インターフェイスの設計 |
この作業では、一般的に概念的な設計と呼ばれるものを作成します [FER01]。これは、ユーザー インターフェイスの初期の抽象化であり、ユーザーに対して表示されるメイン ウィンドウやナビゲーション経路が作成されます。この作業では、ユーザー インターフェイスの設計を駆動するユース ケースに注目します。 ナビゲーション マップは、やり取りを行う場所 (画面、ウィンドウ、ダイアログ ボックス) のナビゲーション経路の概要を示します。参考資料 [CON99] を参照してください。 |
|
ユーザー インターフェイスのプロトタイプの作成 | ユーザー インターフェイスのプロトタイプ |
3 種類の基本的なプロトタイプの作成が可能です。 図 (紙) ユーザー インターフェイスのプロトタイプを作成する主な目的は、実際に設計と開発が開始される前に、システムの機能と使いやすさを明らかにしテストすることです。これにより、開発に多くの時間とリソースを費やす前に、適切なシステムを作成しているかどうかを確認できます。 |
次の方法も、ユーザー インターフェイスの設計の一部として有効です。
ここで説明した作業に加えて、次のような分析と設計作業でユーザー インターフェイスの設計を補足します。
作業
|
成果物 |
使いやすさに関する内容 |
ユース ケース分析 | 分析クラス、 ユース ケースの実現 |
以下も参照してください。 |
クラス設計 |
この作業では、ユーザー インターフェイスの設計とプロトタイプの結果を使用して、クラスを設計します。プロトタイプと異なり、簡単に作成する概念的なユーザー インターフェイス作業ではなく、納品されるシステムの設計を表すことを意図しています。 以下のガイドラインも参照してください。 |
ユーザー インターフェイスの実装は、一般的な実装ワークフローに従います。多くの場合、ユーザー インターフェイスの実装は、設計作業の一部として行われることに注意してください。
使いやすさのテストは、ユーザー インターフェイスの試作や実行可能形式のプロトタイプが完成すると同時に開始します。テストには、使いやすさに関連する性能テストも含まれます。テストでは、補足仕様書で記述された、または
ユース ケース仕様書で特殊な要求として記述された、使いやすさや性能の要求が検証されます。
ユーザーは、ワークフローの詳細: ベータ テスト リリースや、
ワークフローの詳細: 受け入れテストの管理における最終の使いやすさのテストに大きく関与します。
ワークフローの詳細: サポート資料の作成には、トレーニング教材やシステムのサポート資料の作成が含まれ、納品されたソフトウェア製品をエンドユーザーが正しく使用できるようにします。
プロジェクト管理では、目標の達成、リスク管理、制約の克服などの間でバランスを取りながら、顧客 (ソフトウェアの開発費用を払う当事者) やユーザーのニーズを満たす製品を納品することが必要になります。ユーザビリティ エンジニアリングの観点から、最も重要な作業は作業: プロジェクト組織と要員配置の決定です。この作業では、組織構造、外部インターフェイス、役割と責務を定義します。ここでは、ユーザーを開発プロセスに参加させる範囲も定義します。また、開発者にユーザビリティ エンジニアリングの経験が必要かどうかも決定します。
環境の基本ワークフローには、プロジェクトや組織が従う開発プロセスの定義が含まれます。
作業: 開発個別定義書の作成 (
成果物: 開発個別定義書) では、適用するユーザビリティ エンジニアリング技術を定義し、これらの手法を組み込むために RUP のさまざまな成果物や作業をカスタマイズする方法を定義します。
その他の重要な作業として、作業: プロジェクトのガイドラインの準備があります。この作業では、ユーザー インターフェイスのガイドラインを含む
成果物: プロジェクト固有のガイドラインを作成します。これらのガイドラインは、ユーザー インターフェイスの一貫性を維持するのに役立ちます。これにより、使いやすさが大きく向上します。ショートカットのガイドライン、「取り消し」機能、わかりやすい終了、モードのないやり取りなど、使いやすさに関する原則もここで把握します。
RUP のソフトウェア ライフサイクルは、時間に沿って 4 つの連続したフェーズに分解できます。各フェーズは基本的に 2 つの主要なマイルストーンに挟まれた期間で、主要なマイルストーンが達成された時点で終了します。各フェーズの終わりには、評価 を実施し、フェーズの目標が達成されたことを確認します。満足のいく評価が得られたら、プロジェクトを次のフェーズに進めます。
各フェーズには、複数の反復があります。各反復は、実行可能な製品のリリース (内部リリースまたは外部リリース) を成果物とする完全な開発ループです。これらのリリースは開発中の最終製品のサブセットであり、ひとつの反復を経るごとに徐々に成長して、最終的なシステムへと展開していきます。この反復的な手法は、使いやすさに対して有効です。早期の段階でユーザーが使いやすさについてのフィードバックを返すことができ、ユーザーのニーズに一致しない状況にまで作業を進めることを避けられます。
ユーザーは各反復に参加し、要求の洗練、設計概念の評価、概念検証プロトタイプとシステムの進展の両方に関する使いやすさのテストおよび評価を行いますます。
次に、使いやすさに関連する各フェーズの完了条件と、各フェーズの主な作業について説明します。
方向づけフェーズの主な目標は、次の 2 つです。
ユーザビリティ エンジニアリングの観点からは、次の点に関する要求とビジネス モデリング作業を重視することを意味します。
また、方向づけフェーズは、概念的な設計や概念検証プロトタイプを調査する機会でもあります。特に、プロジェクトの主なリスクがユーザー インターフェイスや使いやすさに関連する場合は、よい機会になります。使いやすさのテストは、ユーザー インターフェイスの試作や実行可能形式のプロトタイプが完成すると同時に開始します。テストには、使いやすさに関連する性能テストも含まれます。
RUP は反復的なプロセスであり、方向づけで作成された成果物はユーザーによる再考とレビューを受けます。これにより、開発範囲が管理され、開発中のシステムがユーザーのニーズを満たすことが保証されます。
推敲フェーズでは、ソフトウェア アーキテクチャに重点を置きます。これには、ユーザー インターフェイスのアーキテクチャも含まれます。概念的なユーザー インターフェイスが定義され、ユーザー インターフェイス設計の重要でリスク性の高い要素が実装されます。ソフトウェア アーキテクチャに関連する作業は、一般的にユーザー インターフェイスに適用されます。評価が必要な既存の製品、再利用の考慮、メカニズムとパターンの選択などがあります。
このフェーズでは、分析と設計の基本ワークフロー作業のサポートと共に、ユーザー インターフェイス設計作業を重視します。推敲の完了には評価可能なシステムを構築することが必要であるため、実装とテストにも関係があります。
使いやすさのテストと使いやすさに関連する性能テストでは、補足仕様書で把握されたリスク性の高い要求や、
ユース ケース仕様書の「特殊な要求」として表された要求に注目します。
作成フェーズでは、より多くのユース ケースを実装することに重点が置かれます。これには、ユーザー インターフェイスの概念モデルやプロジェクト固有のガイドラインで把握されたユーザー インターフェイス ガイドラインに沿った、ユーザー インターフェイスへの追加が含まれます。新しい機能が追加された場合は、使いやすさのテストが重要です。
各反復でどの機能を実装するかは、ユーザーの価値観に基づきます。
移行フェーズの焦点は、導入の基本ワークフローに移っていきます。ユーザー指向の開発作業では、移行フェーズまでにユーザーを参加させます。ただし、ユーザーの関与は、これまでどおり主にフィードバックを返すことです。ユーザーが開発を通じて参加している場合、正式なベータ テストや受け入れテストは小規模なものになるか、実行されないことがほとんどです。開発作業の全体を通じて、詳細なユーザーのフィードバックや承認が行われます。
トレーニング教材やシステムのサポート資料の作成は移行フェーズで完成させますが、可能な場合は、ユーザーのフィードバックを得るために、より早いフェーズで開始しておきます。
移行では、エンドユーザーが使用可能な稼働システムが存在します。移行では、少なくとも 2 ~ 3 回の反復を計画して、初期リリースで発生した問題を修正し、主要なユーザー フィードバックを組み込むことができるようにします。
Rational Unified Process
|