その存在の約70年で発明されたソフトウェア構築の方法を見てみましょう。見た目ほど多くはありません。しかし、困惑するのに十分です。
格言
人は本質的に適応力があります。たとえば、鶏肉がグリルで回転しているキッチンに行きます。香りが鼻に当たり、お腹が空いたら唾を吐きます。約5分後、臭いが止まります。食べ物を思い出させるのは、翼を広げたオーブンのガラスの後ろで回転する肉片だけです。匂いはまだ残っています、あなたはそれを測定することができます、しかし受容体からの情報は脳によってブロックされます。
これは至る所で起こっており、ソフトウェアエンジニアリングも例外ではありません。私たちは「悟りの精神が私たちのために準備する」という「素晴らしい発見」から始め、日常の恥とスクラム、スプリント-シュミント、カプセル化-ポリモーフィズム-国籍にスムーズに移ります。病院の平均を超える定期的な物質刺激にもかかわらず、オーブンで回転し、満期まで燃えると脅迫している。
1960年代に、リチャードB.ドスという好奇心旺盛な男性が 、プロテスタントの仕事中毒で飽和状態にあるアメリカでは、70〜80％の人が仕事の能力をはるかに下回っていることを発見しました。さらに、ロボットマニピュレーターとは異なり、タンパク質労働者はそれをすばやく切り抜けることができます。研究は「ゼロ」と「10分の1」で繰り返され、同じ結果が得られました。そのような状況は健康に影響を及ぼします、穏やかに言えば、それは問題ではありません。
このテキストの目的は、生産性が不十分であることを思いとどまらせたり、アドバイスを提供したりすることではありません。約70年の歴史の中で発明されたソフトウェア構築の方法について簡単に説明します。
3つの方法
ゴムを引っ張らないで、本物から始めます。ソフトウェアを開発する方法は3つしかありません。はい、3つは良い数です、美しいです。だから：
トップダウン方式。これは、彼らが最初に「何をすべきか」、次に「それをどのように行うか」を世界的に考え、そして時間が残っている場合はそれを行うときです。
昇順。これは、彼らが最初に少しずつ、小さな部分でそれを行うときです。彼らは、この部分についてのみ「何を、どのように」と考え、グローバルに煩わされることなく、永続することはありません。
スパイラルウェイ。私たちはグローバルに考え始めますが、アラームが鳴ると、目を覚ましてプロトタイプを展開します。そして、要件に応じて解決策が現れるまで、何度か経験を積み重ねていきます。
トップダウン開発
一般的な用語では、すべてのトップダウン方式は「ウォーターフォール」と呼ばれます。すでにいくつかのアジレスの存在について知らされているなら、そのような「単純さは盗難よりも悪い」というのは疑惑を呼び起こすはずです。
大衆への方法の降下は1960年代に起こり、食べる前に手を洗い、カトラリーとナプキンを使用する構造化プログラミングの要件を有機的に補完します。グローバルタスクは、プログラミング言語で直接実装できる構造ブロックのレベルまで、より小さなサブタスクに分割され、さらに詳細なサブタスクに分割されました。ちなみに、これらのブロックのテストは並行して書かれています。1960年代のTDDにこんにちは。
ロシアのことわざ「7回測定-1回カット」はトップダウン方式です。
「滝」のオーソドックスなバージョンでは、顧客からのフィードバックは配達が完了した後にのみ届きます。私たちは1年間働き、ピアノを茂みから転がしましたが、「正しくない」ことが判明しました。いくつかの仕上げが必要です。その間、顧客は新機能の長いリストを生み出しました。そのような計画で働くことに慣れていないのは少しばかげています。したがって、人道的なバージョンでは、どこからでも明確にするために前の段階に戻ることが可能であり、「リターンのあるカスケード」になります。
この方法の利点は明らかです。最初に考えれば考えるほど、途中と最後に行う必要のある不要な作業が少なくなります。自転車の複数の再発明、機能の重複、間違いは除外されます。
しかし、最初は機能が多いと、正しい内訳を生むのは簡単ではありません。これらの分野で経験を積んだ優れたアナリスト、デザイナーが必要です。そして、この場合でも、実施計画を下品な期間遅らせるリスクがあります。
将来的には、この方法を繰り返し、例えば、改善された V-方法、テスト、右側の上昇の受け入れの段階に文字「V」対応の左斜面に沿って発達段階を。水平レベルは、請負業者のどのプロジェクト文書が顧客の受け入れ文書の基礎として機能するかを即座に示します。
改善が方法の基本的な制限を克服できないことは明らかです。それが彼らが原則である理由です。これは、方法が悪いという意味ではありません。彼にはこの種のリスクがあります。リスクをかわすことができれば、すべてが順調です。私たちは考え始め、その過程でメリットを享受します。
アップストリーム開発
実際、昇順の方法は降順の方法よりもさらに古いものです。 1950年代には、FortranとCobolの両方がすでに存在していましたが、ソフトウェアを構築する方法について明確なアイデアはありませんでした。したがって、私たちは最も自然な方法で行動しました。今日は1つのことを行い、明日は別のことを行い、いつかそれを3分の1に接着します。複数のタスクを実装する必要がある場合は、最も重要なタスクを選択します。
この方法は、明らかに
i++
。との類推により、インクリメンタルとも呼ばれます 。関数を追加しました-インクリメント。地球儀をメルカトル図法に引き伸ばしたい場合は、スパイラルメソッドをインクリメンタルと呼ぶこともできますが、それについては後で詳しく説明します。彼らはまた、サイクルの形でメソッドを描くのが好きですが、
i++
最終的な値は定義されていないため、ここからランチタイムまで「掘る」必要があります。ロシアのことわざのテーマを続けると、「輪の中のリスのように曲がる」ということわざがあります。これはまさに昇順の方法です。
この手法は、社内開発で最も一般的であり、現在も続いています。彼らのプログラマーは昨日ビジネスが必要とすることをしなければなりません。よりグローバルに考えると、1960年代には、 IBMなどのモンスターを含むカスタムシステムを開発するための大規模な設計オフィス である「ソフトウェアハウス」が登場しました。
この上向きのソフトウェア構築はすべて、1990年代まで大きな変更なしに続けられました。学術理論を工学の実践に一致させるための主な戦いは、トップダウンとスパイラルの方法のジャングルで戦われたため、安全な避難所を迂回しました。
1990年代には、「ホーム」プログラマーを外部コンサルタントに置き換えるという強力な傾向がありました。その理由の1つは、ソフトウェアエンジニアリングが非中核的な活動である企業内で達成するのが難しい、テクノロジーと専門化の複雑さです。ホームソフトウェアは現在、一時的なチームによって開発されています
このような状況では、単純な関数ごとの方法が再び適切であるように思われます。しかし、日給の請負業者と協力するには、サラリーマンのフルタイム労働者よりも多くの監督が必要です。官僚的な手続きを避けて、アプローチを適応させる必要があります。実際、「委託条件を発行する」には、一般的な計画と関連文書、つまりvollensnolensが必要であり、正式なトップダウンまたはスパイラル方式に切り替える必要があります。たとえば、運送会社や自動車メーカーがなぜそれを必要とするのでしょうか。人々は、小さな内部の問題を解決したり、そこで給与を計算したり、休暇のスケジュールを減らしたりしたいだけです。
需要が供給を生み出し、1990年代の終わりまでに、いわゆるアジャイル手法が登場し、少なくとも顧客は常に最新情報を把握できるようになり、請負業者は実際に何を実装しているかを徐々に理解しました。
改善点：
- 計画はまだ短いですが、ステージの期間が厳密に制限されている間、それは複数の機能とそれらのグループをカバーしています。
- 行われたことの記録が保持されます。
- 理論的には、コードを単純化してクリーンアップする（リファクタリング）ために時間を割り当てる必要があります。
- 理論的には、回帰のリスクは包括的なテストで対処する必要があります。
なぜ私は「理論的に」書いているのですか？実際には、予算が限られている場合や時間の問題がある場合、そもそもこれら2つのポイントが犠牲になります。 ajilesの「聖なる牛」は、著者が意図したようにコードの品質ではなく、次の機能の期限です。
コードの重複、不必要な複雑化、「後で」効果のない実装の延期-以前に行われたことをクリーンアップしないと、技術的負債が増大します。債務の返済が遅れるほど、最終的にはより多くの支払いが必要になります。時間、工数、間違い、失敗、遅い仕事などです。
約10〜15年後、「アジャイラマニフェスト」の作者は 警鐘を鳴らし始めました：「みんな、あなたは何をしているのか、私たちは何か他のものを意味した。」それらはいくぶん正しいです、ボトムアップ開発はとても単純でとても説得力があるので、これらの追加の手順はすべて不必要に思えます。
ボトムアップ開発の良いところをまとめましょう。まず、エントリのしきい値が大幅に削減されます。ゼロから始めるには、経験のある分析と設計の高価な専門家は必要ありません。建設全体は無期限に続く可能性がありますが、最初の兵舎が間もなく建設され、そこに落ち着くことができます。プロセスの管理が容易であり、コントロールポイントとローカル目標は透過的です。
「滝」の場合のように、問題は根本的なものです。プロセスの管理は簡単ですが、ほとんど不可能です。どこにも明確に記録されていないため、最終結果です。リスクは顧客に転嫁されます。製品の所有者に自分の頭が大きいと思わせます。チームが経験、テスト、およびリファクタリング（複雑さの特定のしきい値まで）を使用して技術アーキテクチャに対処する場合、機能アーキテクチャは不良です。問題ステートメントの単純化、つまり現在ドメインモデルである非常に「リファクタリング」は、維持するための凝った高価なコードを取り除くのに役立ちますが、それを行う人は誰もいません。そして、モデルはありません。正直なところ、すべてのセマンティクスはヘッドとコードにあります。
しかし、動揺する理由はありません。世界史上最も悲惨なスプリントについて覚えておいてください。5日間の作成と15億年の継続的なリファクタリングです。
スパイラルエンジニアリング
前述の「ウォーターフォール」の制限は、SADT / IDEFのような対応する方法論の大規模な実装の後、1970年代に明らかになりました 。同時に、他の問題を抱えた「ホーム」プロジェクトのボトムアップ手法にも取り組み、行き詰まりを感じました。したがって、研究者たちは、1980年代半ばに発行された、スパイラルの形でソフトウェア構築プロセスの最新のビジョンを発表した問題（主にバリーベーム）に戸惑い 、カブを引っ掻きました 。
「スパイラル」推論の論理はおおよそ次のとおりです。はい、タスクの複雑さが増すにつれて、分析と設計にますます多くの時間を費やし、この段階でのエラーのリスクが高まっています。しかし、一般的な計画なしに個々の機能を実装すると、間違いを犯すリスクが少なくなり、効果のない、または単に互換性のない部品になってしまいます。したがって、「聖なる牛」のデザインはそのままにしておきますが、a）その時間枠を制限し、b）決定を厳密にチェックして、完全なプロトタイプを展開します。
ポイント「b」は非常に重要です。ボトムアップ開発では、常に何か、そこでのバグ修正、新機能も作成します。ただし、システムがすでに稼働中であり、メンテナンス中の場合は機能します。そうでなければ？顧客が列車の交通管制システムを望んでいると想像してください。数週間以内に、車両とスケジュールシミュレータに関する情報を入力するための画面を顧客に表示します。真剣ではありません。
プロトタイプには、完全に実装されていない場合や「スタブ」がある場合でも、ほとんどの機能が含まれている必要があります。完全なプロトタイプから、それぞれ完全なフィードバックが得られます。ここでは、失敗したり、要件の本質を理解していなかったり、動作環境を考慮していなかったり、出力形式が入力形式と一致しなかったりします。この貴重なフィードバックをもとに、次のプロトタイプを完成品のレベルに引き上げる可能性が高いと合理的に信じて、スパイラルの第2ラウンドを開始します。中規模のシステム（約100万行のコード）の場合、2〜3回の反復で十分です。
言われていることから、スパイラルをインクリメンタルな方法に帰することは、クジラが釣りをするのと同じくらいばかげていることは明らかですが、両方とも尾を持っています。
スパイラルの何が良いのですか？製品ではなくお客様に展開するリスクを大幅に減らし、率直に言って乗りますが、同時にデザインを犠牲にすることはありません。つまり、状況のグローバルなビジョンは残っており、最終結果は予算と利益を計算することによって管理できます。クライアントと請負業者の誰もが、トンネルの終わりに光を見ることができます。顧客は、彼が彼の意図に真剣であるならば、「なぜあなたは私のしっぽをつけて、それから私のトランクを滑らせて、私に象全体を見せてください！」と吠えません。各ターンで、象全体が表示されます。
ただし、ソフトウェアエンジニアリングの台頭と比較すると、プログラマー、つまりアナリストやデザイナーのいない技術者の小隊を管理することは不可能であり、このデリケートな瞬間を顧客に説明して、価格を高くする必要があります。最初のラウンドの設計段階の後、スペシャリストはアイドル状態ではなく、フィードバックを待ってタスクに食い込み続けますが、最終ラウンドでは、スペシャリストはほとんど必要ありません。コイルの長さは最大で数ヶ月ですが、通常は2〜3か月かかります。毎週のスプリントの極端なようには見えませんが、製品の年間の期待のようにも見えません。また、この段階で「設計するだけで十分」で、レンガの敷設を開始する時期を選択するのも簡単ではありません。
スパイラル手法の最も有名で成功した実装 -MSF（Microsoft Solution Framework）。マイクロソフトは後にトリミングされたバージョンを持ち、ボトムアップ方式のために研ぎ澄まされ、比較的小さなプロジェクトやチームのためにアジャイルのMSFとして販売されました。
エピローグの代わりに
おじいちゃん ブルックスは、人々が彼のベストセラーの本で構築する4つのタイプのソフトウェアを概説しました。
写真は、ある時点で「プログラムを書くだけ」をやめ、「法外な価格で」それを製品（多くの異なるクライアントに提供されるもの）または複雑なもの（多くの異なるクライアントで構成されるもの）にしたいことを示しています。プログラムし、機器を含む顧客の環境にシームレスに統合します）。そして、概して「プログラムの作成」がソフト構築方法のいずれかである可能性がある場合、トップダウンおよびボトムアップ方法の欠点によって、さらなる開発のための優れた計画が混乱する可能性があります。
プログラマー・テクニシャンの人材が不足し、デザイナーやアナリストの採用が困難な状況では、水平組織（「システムエンジニア」が「応募者」のプラットフォームを作る）ではなく、垂直組織を使い始める。 、各チームが独自の自転車に基づいて機能を実装します。管理の観点からは、2番目の方法は単純に見えますが、水平方向の「アーキテクチャ」コマンドが導入される瞬間までです。これは、長い説得と調整を通じて、同じ繰り返しの間違いのリスクを軽減します。
これについては、おそらく、情報の空間での最初の方向付けで十分であるため、停止することができます。テキストにはキーワードといくつかのリンクがあるので、好奇心旺盛な人はトピックをさらに掘り下げることができます。
原文 サイト「ソフトウェア工学の力学」