はじめに
少し前に、ソフトウェア開発方法論のRational Unified Process（製品ビジョン）方法論に注意を向け、ソフトウェア製品を開発するための出発点は、製品が解決しようとしている問題を特定することであることがわかりました。
同様のアプローチが国内の慣行にも存在するため、GOST 34.601-90は、原子力発電所（自動化システム） の要件の形成段階で、「自動化によって解決できる問題が特定される 」と述べています。
この記事では、問題の性質、ソフトウェア製品開発に対する問題の重要性および態度に関する私の調査結果を読者と共有したいと思います。
意思決定プロセスの一般的な特徴
人間の活動の結果として作成される他の製品と同様に、ソフトウェアは特定のタスクセットを解決するために設計されたツール（ツール）です。 どこで決める必要がありますか？ 理論を見てみましょう...
さまざまな種類のタスクに対する最適なソリューションの人々の選択の法則の研究は、 決定理論などの科学によって実行されます。
祖国の決定はどこから始まりますか？
意思決定の理論は、あらゆる活動の根本的な原因を問題と呼びます-現時点で持っているもの（ 実際の状態 ）と、将来持ったり達成したいこと （ 望ましい状態 ）の間の人の考えの不一致です。
意思決定理論は組織内の管理活動に重点を置いているため、このパラダイムから逸脱することはありませんが、このアプローチは他の活動にも適用できることに留意してください。
問題を認識している、または何かを変更したいだけでなく、それを解決する方法を決定し、実際の状態を目的の状態に変更することを目的とした特定のアクションを実行する準備ができている人は、 利害関係者または意思決定者（DM）と呼ばれます。
目的
問題を実現した後、 目標の理解が生まれます-意思決定者によると、その成果は、問題の前提の解決につながる、望ましい結果の具体化、すなわち 望ましい状態と実際の状態を対応させます。
挑戦する
より詳細な分析を経て、ターゲットはサブゴールに分割されます。 サブゴールは、主な目標を達成するプロセスの段階と一致します-それらは時間、場所、演技者、努力の適用の目的と相関します。 したがって、目標は一連のタスクに変換されます。 設定された目標が達成される度合い、したがって元の問題全体が解決される度合いは、タスクのセット全体が解決されるかどうか、および解決されたすべてのタスクで必要な結果が達成されるかどうかによって異なります。
運用とソリューション
タスクのリストが決定されると、意思決定者は目標を達成するために組織の焦点を絞った活動の形成に進みます。 意図された目標を達成するために意思決定者によって実行される対策の複合体の意図的な活動は、 操作と呼ばれます 。
運用のアイデアは、意思決定者によってその実装に関する決定に向けて徐々に最終化され、その公式化の間に、部門の長、開発プログラム、計画、タスク、および実装の基準の個人的な目標と目的のシステムに変換されます。 この後、決定の実際的な実装プロセスが実行され、エグゼキュータに通知されます。
図1.典型的な組織管理プロセス
管理決定の有効性の評価
操作の最後まで、意思決定者と問題の解決に関与するすべての人は、操作の成功または失敗について無知のままです。 参加者の活動が完了したときにのみ、問題の前提条件（根本原因）を解決するために選択されたかどうか、操作の目的が正しく定式化されたかどうか、この目標がタスクに正しく分割されたかどうか、実行者にこれらのタスクが割り当てられたかどうかが、意思決定者に明確になります解決するなど
決定が実行され、問題を修正する操作が完了すると、意思決定者は達成された結果を評価します。 得られたソリューションの有用性と有効性を評価するとき、操作の終了の事実だけでなく、元の問題の除去の程度も考慮されます。
評価の結果、次の結論に達することができます。
- この問題は完全に解消されており、その解決により目に見えるマイナスの影響はありませんでした。
- 問題は部分的に解決されていますが、マイナスの結果もありません。
- 問題は部分的に解決されており、それを解決する際にいくつかの新しい困難が生じました。
- 問題は解決されず、その解決策の実装により、新しい重大な問題が発生しました。
ソフトウェア要件の性質
どのような問題-そのような解決策
問題に対しては、解決策に代わる多くの選択肢があることが知られています。 たとえば、生産を最適化する最も簡単な方法は、組織内のビジネスプロセスを変更することです。 ただし、これだけでは不十分な場合があり、新しい問題を可能な限り効率的に解決できるツールが必要です。
問題を解決する方法を考える過程で、DMが組織の自動化によって目標の達成が促進されるという結論に達する場合、開発する操作の1つは適切な情報（自動化）システムの導入です。
会社の長がドキュメントの処理を最適化することに決めたと想像してください。 文書の調整の条件を減らすことだけが目的である場合、このためには、電子形式の文書の使用に切り替えるだけで十分です-すべての人に言葉を確立し、電子メールの使用を教えます。 ヘッドがドキュメントの調整と実行のプロセスを合理化および制御するという目標を設定する場合、このようなアクティビティをサポートするツール、つまり情報システムが必要になります。
この平凡な例は、さまざまな問題を解決するには、さまざまな種類のソリューションを使用する必要があることを示しています。 それは明らかだろう！ 結論に急がないでください...
要件は何ですか？
定義によれば、 自動システムという用語は、組織の人員と、特定の目標の達成を目的としたアクションの実装のための情報技術を実装する自動化ツールのセットの全体を意味します（GOST 34.003-90を参照）。 つまり、使用するソフトウェアには、目標を達成するためのアクションを実行したりタスクを解決したりするための一連のプロパティが必要です。 ソフトウェア製品の指定されたプロパティは、 要件と呼ばれます 。
要件-目標を達成するときにユーザーが問題を解決するために必要なソフトウェア機能。
要件レベル
経営理論の観点から自動化された情報システムを作成するプロセスを考慮すると、経営上の意思決定を行うための上記の手順との類似性をたどることができます。
図2.自動化システムを作成するプロセス
必要
経営上の意思決定を開発するプロセスと同様に、意思決定者の問題を分析することは、組織の自動化の目標を策定します。 目標を達成するには、開発されたシステムが特定の一連の技術的またはビジネス上の問題を解決する必要があります。 ソフトウェア開発のコンテキストでは、これらのタスクはneedsと呼ばれます 。
機能
指定された目標を達成することを目的とした問題を解決するためのアクションの実装の一環として、組織の人員（ユーザーおよびその他の関係者）は、使用するソフトウェアに特定の動作を期待する権利があります。 ユーザーの言語で定式化され、1つ以上のニーズを満たすフレームワークでソフトウェア製品の動作を記述する動作は、システムの機能 （機能）と呼ばれます。
ソフトウェア要件
一連の関数を定義した後、開発したいプログラムの動作の具体的かつ完全な説明でそれらを詳しく説明します。 このような説明は、 ソフトウェア要件またはソフトウェア要件を構成します。
ソフトウェアソリューションの評価
特定されたソフトウェア要件を満たすシステムを構築すると、システムが必要な機能セットを提供するということができます。 同様に、機能は要員の1つまたは複数のニーズを満たすように設計されているため、これらのニーズは結果として得られるソリューション全体で直接満たされ、ソリューションを使用することで目標を達成できます。 そして、目標が正しく選択されていれば、その達成により既存の問題を解決できると想定できます。
自動化システムの開発と実装の結果を分析するとき、顧客は多くの場合、ソリューションが無効であるか、新しい問題を作成し、時には既存の状況を悪化させるという結論に達します。
悲しい話
少し前まで、郡の町Nの病院で、私は1つの医療システムを導入しました。 しかし、試運転中、それを完全に使用することは不可能であることが判明しました-それは根本的に医師の仕事の通常の論理を壊しました。 彼女は手助けする代わりに、干渉しました。 最初は、活動家だけがシステムを使用していましたが、後にシステムの使用は無意味になりました。
これはなぜですか？
誰が責任を負い、何をすべきか？
収集と分析のプロセスで、要件が歪められたり、これらの要件の原因（利害関係者の問題）がまったく検出されないことが非常に多くあります。
図3.要件のゆがみ
図3は、歪みが発生するプロセスの例を示しています。 意思決定者が問題を認識し、それを排除するための活動の目標を策定したとき、彼はタスクのリスト（T 0 ）を実行者（組織の担当者）にもたらします。 後で開発されたソフトウェア製品を使用するのは、これらのアーティストであると仮定します。 ユーザーになります。 それらのそれぞれは、彼に割り当てられたタスクを独自の方法で理解し、ソフトウェア製品の要件を策定するとき、彼の仮定（T 1 ）から進みます。
潜在的なユーザーのインタビューデータに基づいて、アナリストは解決すべきタスクに関する独自のアイデアを策定し（T 2 ）、プロジェクトマネージャーに伝え、開発者向けのタスクに組み込まれたソリューションを開発しました（T 3 ）。
最良の場合、記載されたプロセスの結果として、スタッフの要件、最悪の場合はアナリストまたはプロジェクトマネージャーの要件を満たす製品が取得されます。 この結果は、プロジェクトチームが将来のユーザーと利害関係者の真のニーズを理解していないために生じたものであり、その作業は開発されたソフトウェアソリューションの影響を受けます。
特に深刻な場合、結果として生じる製品は顧客の期待とは関係なく、ユーザーがどのように作業すべきかについての開発者自身のアイデアを反映しています。
プロジェクトの初期段階で問題を特定し、ユーザーの特定されたすべての要件、および提案された解決策がそれと相関する場合（図4を参照）、結果の製品がユーザーのニーズと関係者の期待の両方を最大限に満たすことが期待できます。
図4.要件と問題の相関
さらに、解決する問題を理解することで、プロジェクトの規模を定性的に制御できます。たとえば、まず、問題の80％を解決する機能を実装します。
これを達成する方法は？
問題定義
前のプレゼンテーションの過程で、ソフトウェア製品を開発する前に、解決する必要のある問題を特定する必要があるという結論に達したため、この問題を修正する方法を理解する時が来ました。
多くの情報源は、以下のフォームを使用して、解決する必要のある問題ステートメントを作成することを提案しています。 指定されたフォームは、将来の決定によって達成されると予想される目標も考慮に入れます。
| アイテム | 説明 |
|---|---|
| 問題 | [問題の説明] |
| 影響する | [この問題の影響を受ける関係者のリスト] |
| 結果は | [この問題が利害関係者および/または事業活動に与える影響の説明] |
| から勝つ | [提案されたソリューションの説明] |
| 次のもので構成されます。 | [ソリューションによって提供される主な利点のリスト] |
例
| アイテム | 説明 |
|---|---|
| 問題 | 統合された健康データへのアクセスの欠如 |
| 影響する |
|
| 結果は |
|
| から勝つ | 公衆衛生の状態とそのインターフェースに関する医療データの統合リポジトリの作成 |
| 次のもので構成されます。 |
|
解決されている問題のすべてのプロジェクト参加者による共通の理解に関する定式化および合意に達することは、ソフトウェアプロジェクトの最初の重要なステップの1つです。 解決すべき問題の定義は、プロジェクト全体としても、既存のソフトウェア製品に新しい機能を追加するときにも作成できることに注意してください。
おわりに
この記事に記載されている条項が誰かに明白な（または平凡な）ように思える場合は、失敗したソフトウェアプロジェクトの問題が依然として関連しており、要件が主な理由であることを示す統計を引用します。
現在、すべてのソフトウェアプロジェクトの39％だけが、言葉の意味で成功していると見なすことができます。 プロジェクトの18％は完全に失敗し、残りの43％の実装中に、予算を超過したり、誤った機能を実装したりすることに関連する問題が発生します。
その結果がCHAOS Chronicles 2013に反映されているStandish Group Internationalの研究では、ソフトウェアプロジェクトの成功の重要な要因は次のとおりです。
- プロジェクトへの利害関係者の関与（経営管理サポート）-20％;
- エンドユーザーの魅力（ユーザーの関与）-15％;
- プロジェクトスケール管理（最適化）-15％。
開発者の資格、プロジェクト管理の経験、柔軟な方法論の適用などの要素が後に続きます。
***
上記のすべては、ソフトウェア製品がユーザーのために作成されるという公理を確認します。 利害関係者の問題と実際の（エンド）ユーザーのニーズに対するオリエンテーションは、ソフトウェア開発プロジェクトの成功の鍵です。 既にプロジェクトの初期段階で、ユーザーは作業に関与している必要があります。その結果、問題の定義 （問題の説明）と製品コンセプト （製品ビジョン）は、プロジェクトチームが解決される問題を明確に認識し、ユーザーのニーズを理解し、それらを満足させる準備ができていることを示す必要があります。