情報システムの開発における事前設計調査

事前審査なしで何が起こりますか?



かつて、輸送ルートを作成するためのシステムを開発して販売する必要がありました。注文のあるポイントが地図に表示され、マウスでそれらを丸で囲んで車に乗せます。 ある会社が、アプリケーションの販売リクエストを連絡しています。 数ヶ月間、私たちはなぜ彼らがそのようなシステムを必要としているかを見つけようとしました。 それからこの会社は私達を実施のために引き付けることにした。 そして、そもそも燃料の会計処理のための機能が必要であることが判明しましたが、これは私たちのシステムの言葉にはまったく含まれていませんでした。



そして、システムの開発中にプロジェクトに参加し、プロジェクトのドキュメントと既に開発された機能を調べます。 そしてある時点で、意識が生まれます:インターフェイスがあり、プログラムは何かをしますが、それが開発されている理由、それが解決するビジネスタスク、達成されるべき指標を答えるために、プロジェクトチームは誰もできません。 このようにして、顧客の要件を満たすシステムを作成することは可能ですか?

言い換えれば、 参照規約を作成する前であっても、通常は小規模な(いつのように)調査を実施し、いくつかの質問に回答する必要があります。



調査が回答する主な質問



sayingにもあるように、何を、どこで、いつ理解する必要があります。 すなわち:



  1. 開発が行われている目的は何ですか、顧客にとってどのようなメリットがありますか?
  2. 提案されたビジネススキームとは、作成されたシステムの助けを借りて自動化されるプロセスです。
  3. システムの主なユーザー機能は何ですか。


なぜ書くのか、なぜ議論して話すのに十分ではないのですか?



文書を起草すると、口頭での議論とはまったく異なる質的なレベルで思考を定式化できます。 会話では、多くの詳細が届かず、情報の一部が忘れられ、後で見落とされます。 そして、紙はすべての考えを保存します。



はい、ドキュメントの作成は骨の折れる作業であり、時には不快なビジネスでもありますが、それだけの価値はあります。 思考は、それが形成されたときにのみ価値があり、紙の上に定式化されたときに形成されます。



プロジェクト前試験には何を含めるべきですか?



通常、設計前調査は、企業のビジネスプロセスの調査を指します。 これについて多くの記事や本が書かれています。 しかし、残念ながら、プロセスの簡単なプレゼンテーションでは十分ではありません。



調査の結果は、ドキュメントのパッケージ全体になる場合があります( それらの一部は記事の最後に記載されています )。 私が通常持っている中心的な(そして、残念なことに、しばしば唯一の)ドキュメントは、「システムコンセプト」ドキュメントです。 この記事では、このドキュメントについて説明します。



コンセプトの独自の構造を開発し、「原子力発電所の要件の形成」の段階でGOST 34に従って作成されたレポートを基礎としました(標準RD 50-34.698-90「方法論的指示。情報技術。自動システムの標準およびガイダンス文書のセット。システム。ドキュメントのコンテンツの要件」)。 しかし、彼は彼の追加を行いました。



「システムコンセプト」には、2ページ、場合によっては30ページを含めることができます。 それはすべて問題文に依存します。 「コンセプト」は、原則として、顧客のトップマネジメントと合意されており、これに基づいてのみ参照規約を作成できます。



システムの作成(近代化)の目的



創造という目標の下で、私はそれがビジネス上の目標であることを理解しています。 自動化は目標ではありません。 関数を追加することも目標ではありません。 そして、「最適化」は目標ではありません。 たとえば、従業員が座って、1日数時間、職場ですぐに眠ることができます(ところで、実際の場合)。 そして、誰かが彼の活動を自動化するように頼みます。 なんで? それで彼は4時間寝ますか?



数十のプロジェクトを数年間分析した結果、システムを作成(近代化)するために考えられる5つの目標のみが特定されました。



  1. 新しいビジネスが編成されています(たとえば、オンライン注文システム)。 事業がインターネット経由で行われることを計画している場合、開発が不可欠であることは明らかです。
  2. 運用コストの削減。 古典的なケースは、自動化の結果として、スタッフが削減されるか、より良い計画の助けを借りて、より少ない労力でより多くのことを行うことができるということです。
  3. 内部プロセスの品質を改善する。 また、古典的なケース。 たとえば、新しい顧客を検索するときに、マネージャーが電話をかけることを常に忘れ、リードに関する情報を失った場合、CRMを実装するのが理にかなっています。
  4. 主要従業員に応じたリスク削減(「金色の爪」など)。 低レベルの自動化とプロセスの複雑さにより、解雇(または病気)がビジネス全体を終わらせる1〜2人の従業員によって多くの操作が実行されることがあります。 そして、新しいものを見つけて教えるには1ヶ月以上かかります。
  5. 外部要件の履行。 たとえば、新しい法律が登場したり、電子文書の管理またはモバイル従業員の仕事の管理が必要であるというカウンターパーティの要件があります。


目標を具体化することが望ましいことは明らかです。 コストを削減したい場合、いくらで何を犠牲にします。 新しいビジネスを組織する場合は、少なくともおおよその操作量とオペレーターの数を理解する必要があります。 プロセスの品質を改善する場合、問題の範囲を概説し、解決策を提案する必要があります。



システムのアイデア



ドキュメント「Concept」が非常に膨大であることが判明した場合、最初にシステムの本質、そのアイデアを簡単に概説することは理にかなっています。 たとえば、ある種の特殊なソーシャルネットワークを作成したい場合(博物館に行って印象を共有します)。 最初に訪問者間のコミュニケーションの必要性を説明し、次に簡単に要約します。ユーザーが1つまたは別の展示物の印象を書くことができるモバイルアプリケーションが開発されています。



新旧の比較



作成されたシステムの本質を理解する最も効果的な方法は、まるで反対側からのように行くことです。



これを行うには、以下を行う必要があります。





このセクションの目的は、新しいスキームを導入する必要性を正当化することです。 ビジネスプロセスの詳細な説明は、別のドキュメントに配置するのが最適です。 ここでは、欠点と提案に焦点を当てます。



何を稼ぎますか



あなたがお金を稼ぐことを計画しているアプリケーションを開発している場合、あなたは間違いなく収入の方法を決定する必要があります:広告、有料購読、有料サービス、請求された利子など。 選択したメソッドは、開発中の機能に大きな影響を与える可能性があります。



締約国の関心



作成されたシステムを機能させるために他の組織の参加が必要な場合は、組織を仕事に興味を持って引き付ける方法を決定する必要があります。 つまり、最初にビジネスチェーン全体を構築し、次に他のすべてを構築します。



自動化プロセスの説明



このセクションの目的は、プロセスの一般的だが完全な図を提供することです。 たとえば、オンラインストアを開発しています。 明らかに、カタログ、バスケット、買収銀行との統合、配達が必要です。 しかし、ここでは、返品、配達の拒否、サプライヤの拒否、在庫品の予期せぬ不足の問題があなたの注意をそらすかもしれません。 可能なすべてのオプションを事前に検討し、自動化するオプションと、手動モードでそれらを「レーキ」するのが非常にまれなケースを決定することをお勧めします。



説明のために図を提供する必要はありません。 一般的な場合、通常のテキストスクリプトは、アクションの本質をより完全に明らかにします。



法的サポート



多くの場合、システムの作成後、アプリケーションまたは組織を使用している人々が法律に違反していることがわかります。 したがって、まず法的にクリーンなスキームを見つけてから、技術的なソリューションを開発する必要があります。



機能リスト



ドキュメント「コンセプト」は技術的なタスクではないため、ビジネス機能、上位レベルについて説明します。 この段階では、承認について話したり、ユーザープロファイルを操作したりする必要はありません。 ただし、機能の一般的な考え方を示す必要があります。



セキュリティ要件



金融システムまたは極秘データを含むシステムを開発している場合、セキュリティ標準のリストを提供する必要があります。 たとえば、保存または送信されるデータの暗号化要件。 個人データの処理と保存に関するより厳しい要件をすべて忘れないでください。



システム実装オプションの選択



場合によっては、ニーズに応じて、アプリケーションのタイプ(Webアプリケーション、ネイティブ)、プラットフォーム(Windows、Linux)、一般的なアーキテクチャ(1つのサーバーまたは複数のクラスター)、典型的なシステムを採用するか、ゼロから開発を改良または実施するかを決定する必要があります。 これを行うには、提案されたオプションを比較し、最適なオプションを選択する必要があります。





その他の設計前の研究文書



上記で述べたように、チーム全体が1週間以上にわたって実施したプロジェクト前の優れた真剣な研究の結果は、文書全体のパッケージです。 それらのいくつかを次に示します。







おわりに



この記事では、プロジェクト前調査の主要なセクションを非常に迅速に実行しました。 なぜ流に? そのような試験は非常に創造的な活動だからです。 主なことは、概念を読むとき、これがどのように機能するかについての完全な理解があるということです。 そして、残り、研究の結果を含む2つの文書はまったく似ていないかもしれません。 したがって、ドキュメント内のセクションのリストは上記のものとは大きく異なる場合があります。



著者による他の記事を読む:






All Articles