プログラムを作成し、クラスインタラクションの新しいアルゴリズムまたはシステムにパズルをかけ、テクノロジー、言語の新しい機能を使用し、正しいスペルに時間と労力を費やします。 そして最終的には、ユーザーがそこに座って、クライアントまたはクライアントのクライアントが製品を使用します。 そして、彼は一般的にプログラミングを知らないかもしれません。 ボタン、画面、アプリケーションまたはウェブサイトがあります-それだけです。 内部にあるものは彼を全く気にしません。 確かに、ユーザーはプログラムで使用したもの（forまたはforeach）にまったく無関心です。 最も厄介なのは、Delphi、VB、またはC＃であっても、記載されている内容に対してまったく無関心であることです。 そして、彼らはバージョン管理システム、フレームワーク、テストによる開発、および設計パターンについて何も知りません。
しかし、ユーザーなしでは存在しません。 これらの技術はすべてエンドユーザーの消費に基づいているという事実を理解し、受け入れなければなりません。 つまり 彼らには理由がありました。 私たちがすること、学ぶこと-これらはすべてユーザーのためのものです。 私たちは彼らの生活を楽にし、彼らは私たちにお金を支払い、私たちは利益を得て、それに生きます。 電子メール、検索エンジン、ソーシャルネットワーク、インターネット、CRMシステム、会計プログラム、プロジェクト管理システム-すべてユーザーが使用できます。
ここに、ユーザーを満足させるためにどこまで行けるかを示す良い例があります： http : //lenta.ru/news/2007/04/09/butty/
ソフトウェア開発技術。
2つのテクノロジーは、ソフトウェア開発テクノロジーとは区別されます。
- カスケード（または滝）モデル
- 反復開発モデル
カスケードモデル
これらは実際には類似しており、カスケードモデルは、たとえば、柔軟な開発モデルのドラフトバージョンです。 カスケードモデルのフェーズは次のとおりです。
- 要件の定義
- 設計
- 建設業
- 統合
- テスト中
- 設置
- サポート
すべてのフェーズは、厳密に連続して次々に実行されます。 「要件定義」段階では、ソフトウェア要件（機能仕様）のリストを取得し、「設計」段階では、要件リストに基づいて、プログラマー向けにこれらの要件を実装する方法と計画を説明するドキュメントを作成します。 次に、プログラムコードが作成され、テストされるプログラムのすべての部分が統合されます。テストが成功すると、お客様のシステムでインストールが実行されます。次に、ユーザートレーニング、ドキュメント、カスタマーサポート付きの気難しい電話を含む「サポート」フェーズに入ります。
矛盾に気づきましたか？ 私は。 もう一度簡単に説明しますが、「ユーザーにとってすべて」という原則にまだ導かれているという事実を考えてみましょう。 状況を想像してください。2009年1月にユーザーAはプログラムが必要であることに気付き、当局の要件を正当化し、当局は要件の合理性を受け入れ、予算の一部を新しいプログラムを注文するために割り当て、それを注文しました。 まあ、あなたは上司の観点からの要件の合理性が余分なお金であることを理解しています。 まあつまり プログラム全体（+法的文書、ユーザートレーニングとユーザーマニュアル、および13％のVAT）を注文すると、プログラムを使用して得られる利益よりも安くなります。
ユーザーA.が来て、何を、どれだけ、そして何を望んでいるかを説明します。 彼は製品マネージャーの要件を策定します。 彼らが理解する言語で、プロダクトマネージャーは聞き取り、書き留めます;これが「要件定義」フェーズです。 そしてもちろん、これに基づいて、プログラムを書くための予算と締め切りはすでに設定されています。 どれだけの情報が失われ、元の目標が失われるかを理解することが重要です-プログラムの開発にかかるよりもしばらくの間、プログラムを使用してお金を稼ぐこと。 第二に、プロダクトマネージャーはタイミングとコストについて話す資格がありますか？ もちろん、特定のシニアプログラマーまたはチームリーダーが関与しており、どれだけの時間とどれだけの時間を見積もって教えてくれるのでしょうか？ 上級プログラマーは、数日で数を発表します。 400人日（MD）または20人月（すべて読んだ？）としましょう。 通常、機能要件を作成し、契約書に署名し、ユーザーAを手放します。彼はオフィスに戻り、製品のインストール準備ができてから5〜6か月後に戻ってくるようお願いします。
私たちは仕様を取り、アーキテクトに行き、アーキテクトはシステムを想起させ、上級プログラマーと一緒に技術的要件を思い浮かべます。 上級プログラマーがそれらを受け取り、MS Projectで開発計画を作成します。 プログラム自体の作成を開始したときに各プログラマにタスクを分散し、時間ごとにそれらを収集し、すべてが計画どおりに動いているかどうかを確認します。
すべてをまとめて「統合」フェーズにし、アーキテクトの作業を確認します。 建築家は開発の重要人物の1人であり、ミスを犯すと、検証の後の段階でそれが検出されます。各ミスのコストは非常に高く、時間とコストの両方の増加につながり、チームの全体的な気分にも影響します。 このフェーズが失敗すると、設計フェーズに戻り、予算に影響します。
すべてがうまくいけば（決して起こらない）、「テスト」フェーズに進み、別のモジュールで小さなエラーを特定すると、このモジュール内でのみ修正が行われますが、システム全体でエラーを検出すると、「設計」フェーズに戻ります。高価な喜び。
「インストール」フェーズと「サポート」フェーズは同じ統合であり、エンドユーザーのみが対象です。 ここで最も難しい問題が待っています。 ユーザーAと再び会います。2009年11月に10か月が経過しました。 この期間中に多くのことが変更される可能性があり、この期間中の当社製品は請求されなくなる可能性があります。
技術的には、すべての署名された要件が満たされた場合、エラーのすべての費用を差し引いた後、利益を上げます。 しかし、私たちは究極の目標に到達しましたか？ 最終的な目標は、プログラムを使用することで会社の効率を高め、その結果、顧客から追加の利益を得ることでした。 もしそうなら、それは私たちが望んでいるほど大きくはなく、あまりにも多くのリスクが最もカスケード型の開発技術に内在しています。
次は、これらのリスクに対処する必要がある反復開発モデルです。
反復開発モデル
開発の各段階でこのアプローチを使用するプロジェクトは、繰り返しのサイクルを経ます。
- 計画中
- 実装
- 確認する
- 格付け
実際、反復アプローチ自体がそれを物語っています。 開発を開始し、プログラムの主な機能に焦点を当て、タスクを分析します。 製品マネージャーを使用するユーザーAは再び要件のリストをコンパイルしますが、この段階で要件のサブセットが強調表示され、それに基づいて今後のすべてのバージョンが構築されます。 上級プログラマーおよびアーキテクトは、この反復のみを実装する計画を立てます。 開発チーム（または最初は1つ）がプログラムに要件を実装し、テストと再分析のためにそれを渡します。 これらの2つのフェーズは同時に実行できます。 プログラムでエラーが検出された場合、パッチがリリースされます（このバージョンの修正）。 また、プログラムアーキテクチャでエラーが検出されると、再分析を考慮して、システムの再設計が次の反復に追加されます。
反復自体は短いプロセスですが、非常に最初から、最も高価なエラー（アーキテクチャのエラー）を特定して解決できます。 さらに、ユーザーAについては、最初の反復の後、プログラムのプロトタイプを既に表示し、フィードバックを取得し、要件を調整し、将来の実装に備えます。
したがって、ステップごと、反復ごとに、必要なすべての機能を徐々に実装します。 ソフトウェア製品を作成するこの方法を使用して、私たちはしばしばエンドユーザーと対話し、それにより、より満足する製品を作成します。 製品の配送は10か月後ではなく、1〜2か月ごとに行われます。 この期間中、顧客のスタッフは新しいシステムを研究して慣れ、アイデアや追加を提案および作成できるため、より効果的なソリューションを作成できます。
しかし、ここには多くの落とし穴があります。エンドユーザーとの関係が前面に出てくるため、ユーザーはプログラムとサポートサービスによって作業の質を判断するため、開発プロセスでは製品のテストとインストールに特別な注意を払う必要があります。 次の記事でそれについて。