ペガのメリット
ソフトウェアにソフトウェアを作成
させるビジネスロジックを強化
する組織にとって意味のある場所でアプリケーションを実行
するPegaのアプリケーション製品を使用して変換を開始する
チームメンバー：
1ケースデザイナー（ビジネスアーキテクトおよびシステムアーキテクト）：対象の専門家および利害関係者とシステムを開発します。
ビジネスアーキテクト：ビジネスルール、サービスレベルの合意およびプロセスを定義します。ユーザーのニーズを理解し、ユーザーのケースと特性を定義することが重要です。
システムアーキテクト：アプリケーション開発者はオブジェクト指向の設計とアプリケーションの実装を実行します
。2。対象の専門家はビジネスロジックを設計し
ます。3。利害関係者はソリューションのレビュー、再定義、提供を支援します。。
アプリで直接オブジェクトをキャプチャする
客観的（DCO）ビジネスの直接キャプチャとその利害関係者は、共有仮想モデルを使用してアプリケーションのビジネスニーズを直接キャプチャし、ビジネス目的で両者が相互に通信して需要を完全に理解できるようにします。
ペガプラットフォームアプリケーションをインストールする
ベストプラクティスとガードレール
ベストプラクティスの目標：常に少なくとも1つの目標があります。組織がベストプラクティスに従っている場合、問題や同時実行性の問題を最小限に抑えることで、期待される結果を予測できます。
ベストプラクティスを確立する方法：
さまざまな基準を使用してベストプラクティスを選択できます。これにより、アプリケーション開発に測定可能で予測可能な配信が提供されます。
ベストプラクティスが組織の目標を満たしている
かどうか。ベストプラクティスが組織構造と一致して
いるかどうか。使用時に必要なリソースが追加されているかどうか。ベストプラクティス
の費用対効果。
pegaは、ベストプラクティスをpegaプロジェクトを提供するための鍵として定義しています。
ldcoを使用して製品の品質を向上させます。
DCOを使用すると、プロジェクトチームはビジネス要件をペガに直接入力できます。DCOは、変換エラーの排除、チーム時間の節約、効率の向上、目に見える作業モデルに関するビジネスおよびITリソースの直接参加の促進、およびプロジェクト参加者が作業の進捗状況を最もよく確認できるようにするのに役立ちます。
Pegaは、すべてのプロジェクトで配信プロセスの中核としてdcoを使用することをお勧めします。
標準のペガパフォーマンスを使用する
Pega7には、信頼性がテストおよび証明されているpegaパフォーマンスを使用して、多くの機能とパフォーマンスが製品に組み込まれています。たとえば、ケースのライフサイクルの一部でレビューレベルを上げる必要があるとします。カスタムレビュープロセスを構築する代わりに、Pega7で提供される承認プロセスを使用します。カスタムプロセスの構築に必要な時間の何分の1かでニーズをサポートするように、ケースのライフサイクルを設計できます。
構築中に繰り返してテストする
アジャイルで反復的な配信モデルは、組織で最もよく使用されます。まず、大きなアプリケーションを分離して、より小さくし、統合をより適切に管理できるようにします。たとえば、完全なアプリケーションをビルドしてから、完成したアプリケーションを一度にテストする代わりに、各プロセスを段階的にビルドしてテストします。次に、フィードバックを提供する関係者にこれらの機能の関連するデモンストレーションを提供できます。プロジェクトの早い段階でテストすることで、より高いレベルの製品品質を実現できます。
プロジェクトの進捗状況をすべてのレベルで伝達する
定期的なコミュニケーションは、チームが時間通りに適切な問題に注意を払うのに役立ちます
ペガガードレールに従ってください
pegaガードレールは、ベストプラクティスを使用してpegaアプリケーションをインストールおよび構成するのに役立ちます。ペガガードレールを使用すると、開発チームはペガを構成するためのベストプラクティスを追跡できるため、保守とアップグレードが容易になります。
ガードレールは、危険な状態を含む、または望ましくない結果につながる可能性のある状況に関するベストプラクティスおよびガイダンスです。ガードレールは、あなたとあなたのチームがPegaプラットフォームを正しく使用することを保証し、厄介な状況を回避するのに役立ちます。
ライフサイクルループを設定する
技術モデルは、ライフサイクル設計中にビジネスアプリケーションがどのように機能するかを説明するためによく使用されます。それはすべてのプロジェクトの基盤です。ビジネスアプリケーションは、特定のビジネス結果を達成できるように作業を自動化します。たとえば、口座の開設、事故の申し立て、オンラインでの商品の注文などです。
目に見える仕事のビジネス
ビジネスユーザーが効果的に業績を達成できるようにするには、ビジネスユーザーが協力する方法が必要です。ビジネスアプリケーションは、ビジネスユーザーが自分の仕事を自然に考えて説明するのと同じ方法で実行する必要があります。Pegaアプリケーションでは、ケースタイプを使用して、繰り返し可能なビジネストランザクションをモデル化します。ケースタイプはビジネストランザクションの抽象的なモデルであり、ケースはトランザクションの特定のインスタンスです。ケースタイプは、ケースを作成および処理するためのテンプレートと考えることができます。新しいトランザクションが開始されると、ケースタイプの定義に従って新しいケースが作成されます。
ビジネスアプリケーションをビジネス用語で説明するために使用されるモデリング手法は、ライフサイクルループ設計と呼ばれます。
ステージ
ステージは、組織の作業の最初のレベルです。ワークフロー、プロセスが含まれています。ユーザーは、ケースをケースライフサイクルの次のフェーズに移動する前に、次の手順に従います。
ケースのライフサイクルでは、期待される結果につながる段階はプライマリ段階と呼ばれます。初期段階のシーケンスは、しばしばハッピーパスと呼ばれます。例として新しい家を取り上げます。家を建てるタスクを建設の主要な段階に整理するように求められた場合は、タスクを3つの段階に整理することができます。どんな建物の基礎も最初の段階です。次に、家自体、つまりフレームが作成されます。最後に、屋根が追加されました。各段階は、住宅建設ケースのライフサイクルのさまざまな段階を表しています。住宅建設の場合、基礎、フレーム、屋根が家の完成につながる主要な段階であり、これも商業的な成果です。
代替フェーズ
ケースは通常、ある主要な段階から次の段階へと順番に進行します。場合によっては、作業が必ずしも計画どおりに進まないことがあります。これが発生した場合は、別のステージを使用して、問題を解決するために必要なアクションを説明してください。代替ステージは、「通常のイベントプロセス」の一部ではないが、特定の状況下で使用可能でなければならないプロセスステップを編成するために使用されます。たとえば、オンライン注文アプリケーションのライフサイクルをモデル化する場合、注文は出荷前にキャンセルできることを考慮する必要があります。注文がキャンセルされた場合、注文がキャンセルされたと見なされる前に、多くのタスクを完了する必要があります。最初のタスクはキャンセルされた注文を処理することです。次に払い戻しを行う必要があり、最後に注文がキャンセルされたことを顧客に通知する必要があります。代替ステージを使用して、メインパスからの例外を管理するためのプロセスステップを整理します。
定義フェーズのガイドライン
フェーズを定義するには、次のガイドラインを考慮してください。
**組織フェーズ：**フェーズは通常、ある機関から別の機関へ、または組織のある部分から別の部分へのケースの転送を表します。ステージは、ケースのステータスの大きな変化を表す場合もあります。
命名フェーズ：ビジネスユーザーにとって最も意味があり、関連性のある名前を使用します。名詞または名詞句を使用して、ステージの背景を説明します。名前を2文字に制限してみてください。
ステージ数：特定の状況では、プライマリステージの数を7に制限し、代替ステージの数を5に制限することを検討してください。10を超えるプライマリステージまたは5を超える代替ステージが必要な場合は、2つ以上のステージを組み合わせるか、別のケースタイプを使用することを検討できます。
この場合、ステージはしばしば組織作業の最初のレベルと見なされます
相転移
フェーズ変換を使用すると、フェーズの実行時シーケンスをさらに絞り込むことができます。
予備段階では、段階内のすべてのステップが完了すると、デフォルトのオプションは自動的に次の予備段階に切り替わります。現在のフェーズを完了する前に別のフェーズへの移行を許可する場合は、制御された移行をフェーズに追加できます。制御された遷移は、任意のプライマリステージまたはバックアップステージとして構成でき、ステップ内の操作またはプロセス内の特定のステップとして発生する可能性があります。
ケースが移行する段階をユーザーが選択できるようにステップを構成できます。このタイプの構成は、はい/いいえの決定が必要なステップで最も役立ちます。たとえば、ケースワーカーはリクエストを確認する必要があり、リクエストを承認または拒否できます。リクエストが承認されると、通常の処理が続行され、ケースはメインパスの次のステップまたはステージに進みます。リクエストが拒否された場合、ケースは事前定義されたステージに進みます。このステージは、メインパスにある場合とない場合があります。
ステージ変更プロセスステップを使用して、ケースフローを指定されたステージに自動的に移行できます。
このタイプの構成は、代替フェーズへの自動移行および代替フェーズからの自動移行に非常に役立ちます。たとえば、拒否されたリクエストは、更新のために発信者に返送されます。更新要求のプロセスステップは、別のフェーズで編成されています。ステージの変更ステップが発生すると、ケースフローはステージの変更ステップで定義されたステージに自動的に移行します。
制御相転移
代替フェーズへの移行を許可するため、または特定のフェーズが完了する前に、特定のフェーズに制御された移行を追加できます。制御された変換は、Change Stageスマートシェイプを使用したプロセスステップとして、またはプロセスステップのオプションのユーザー操作として追加できます。
承認/却下の手順を使用して、ケースが移行する段階を制御します。