数年前、私はアルゴリズムと複雑さを研究しました。 各コンセプトが明確に定義された、きれいな領域であり、各結果は以前の証拠に基づいています。 この分野で事実を見つけたとき、数学自体がそれを引き出したので、あなたはそれに頼ることができます。 近似や確率的アルゴリズムのような不完全な結果でさえ、その不完全性の厳密な分析を行います。 ネットワークトポロジや暗号化など、他のコンピューターサイエンスの分野も同様に満足のいく状態にあります。
そして今、私はソフトウェア開発に取り組んでおり、これは耐え難いほど滑りやすいトピックです。 正確に定義された概念はありません。 結果は、「通常」または「全般」の特性で評価されます。 今日の研究は、明日の仕事に役立つかもしれないし、そうでないかもしれない。 多くの場合、新しいアプローチは以前の方法に反論し、短時間で明るく燃え上がり、限界が表面化すると流行遅れになります。 構造プログラミングを信じていました。 それから、彼らは第4世代言語を信じ始め、次にオブジェクト指向のメソッドを、次に極端なプログラミングを、そして今はオープンソースを信じるようになりました。
しかし、プログラミングはまさにタイヤがアスファルトに接触する場所です。 気にする人は少ない P 等しい NP 、純粋に問題の美しさのために。 コンピューター領域はコンピューターを扱います。 これは、実際の人間の問題と実際のマシンでのこれらのプログラムの作業を解決するプログラムを書いています。 Church-Thuringの論文によれば、すべてのコンピューター機器は本質的に同等です。 そのため、コンピューターアーキテクチャは優れていますが、ソフトウェアを作成するという問題は、コンピューターサイエンスの真の限界です。 合理的な時間とコストで組み立てることができ、おおむね設計者が計画した方法で機能し、エラーなく機能するプログラムが必要です。
このような目標を持って、私は常に1つの質問（他の多くの研究者のように）に夢中になりました：コンピューターサイエンスの他の分野のように、なぜプログラマーはより厳しい結果を得られないのですか？ 「プログラムのアーキテクチャと設計のどの部分を正式かつ証明可能にすることができますか？」と異なる質問をした場合、この質問に対する答えは図1にあります。
図1：コンピューターサイエンスの輝線
この行の上のトピックは、ソフトウェア開発に関するものです。 この線より下の研究分野は、基本的なコンピューターサイエンスの科目です。 後者には明確で正式な結果があります。 この分野の未解決の問題については、新しい結果が正式に定式化されることを期待しています。 これらのトピックは相互に基づいています。たとえば、複雑さに関する暗号、アルゴリズムに関するコンパイラなどです。 さらに、これらの分野で実証された結果は100年後も変わらないと信じています。
それでは、この明るい線とは何ですか、そしてなぜその下に単一のプログラミングトピックがないのですか？ ラインは、「人間の直接参加」と呼ばれる品質です。 ソフトウェア開発にはこのような品質がありますが、従来のコンピューターサイエンスにはありません。 線の下の分野の結果は人々が使用できますが、これらの結果は人々の直接の影響を受けません。
ソフトウェア開発には人間の不可欠な要素があります。 たとえば、ソフトウェアの運用上の信頼性は、ソフトウェアシステム内の人の欠陥を理解、特定、修正する能力です。 運用上の信頼性は、いくつかの正式なコンピューターサイエンスの概念（ソフトウェア制御グラフの循環的な複雑さなど）の影響を受ける場合があります。 しかし、運用上の信頼性は、ソースコードの意味と目的を理解する人々とその能力に大きく依存しています。 特定のソフトウェアシステムの動作の信頼性が高いかどうかという質問に対して、単にソフトウェアを機械的に調べるだけでは答えることはできません。
セキュリティについても同じことが言えます。 研究者は、いくつかの正式な方法を使用して、人々の健康と財産に対するソフトウェアシステムの影響を見つけました。 しかし、プログラムのセキュリティについての議論は、調査中のシステムの人間のコンポーネントを参照せずに完全とみなすことはできません。 要件の開発についても同様です。 関係者から正確な要件を取得するために調査技術を開発し、それらを記録するためのさまざまなシステムを作成できます。 しかし、この分野での研究は、要件の収集にしばしば人々の会話や観察を伴うという事実を変えることはありません。 これらの人々は正しい情報を教えてくれることもあれば、そうでないこともあります。 おそらく人々は、おそらく正当な理由で嘘をつくことがあります。 時には人々は正直に正しい情報を伝えようとしますが、それはできません。
この観察は、コネルの論文につながります。
ソフトウェア開発は、人間の活動を伴うため、実績のある厳格な規律になることはありません。
これは、正式なシステムの境界に関する数学的な記述ではありません。 賛成または反対の証拠はありません。 しかし、実際のところ、人間の問題はソフトウェア開発の中心的な問題のままです。
- このプログラムは何をすべきですか？ （要件、使いやすさ、セキュリティ）
- プログラムを簡単に修復および変更できるようにするには、プログラムをどのように表示する必要がありますか？ （アーキテクチャ、設計、スケーラビリティ、移植性、拡張性）
- 書くのにどれくらい時間がかかりますか？ （評価）
- どのように開発する必要がありますか？ （コーディング、テスト、測定、構成）
- チームはどのように効果的に作業する必要がありますか？ （管理、プロセス、ドキュメント）
これらの問題はすべて、人を中心に展開しています。
私の論文では、ソフトウェア開発が非常に困難で滑りやすい理由を説明しています。 プログラマーの1つのチームの実証済みの方法は、他のチームでは機能しません。 過去のプロジェクトの包括的な分析は、以下の適切な評価には役立たない場合があります。 革新的な各開発ツールは少し役立ちますが、その大きな期待に応えることはできません。 その理由は、人々があまりにも柔らかく、失望し、予測できないからです。
私の主張の意味に移る前に、考えられる3つの異議を検討します。
論文はそれを実現します。 ソフトウェア開発のいずれかの領域が突然厳密に解決された場合、ソフトウェア開発の定義を変更するだけで、この問題を排除できます。
ある意味では、この異論は真実ですが、すべてではありません。 私は、一般にソフトウェア開発と呼ばれる一連の分野が、厳密なソリューションに本質的に挑戦し続けると主張します。 一部の問題の狭い側面は、正式なアプローチに役立つ可能性がありますが、それらの成功は主要な開発問題の周辺でのみ発生します。
プログラミングの統計結果はすでにこの論文に反論しています。
これらの方法は一般に評価の問題を解決し、ファンクションポイントカウント、 COCOMO II 、プローブなどを含みます。 数学的な外観にもかかわらず、これらの方法は証拠でも正式な結果でもありません。 このような統計は、単に過去のソフトウェアプロジェクトの主観的な人間の経験を定量化し、将来のプロジェクトに外挿する試みです。 時にはそれが動作します。 しかし、現代の表現を使用する場合、これらのスキームで外向きに厳密な式は口紅のついた豚です。 たとえば、COCOMO IIの式の1つは次のようになります。 PersonMonths=2.94×サイズB どこで B=0.91+0.01×ΣSFi 、そして Sf -これは、「開発の柔軟性」や「チームの結束性」など、5つのスケーリング係数のセットです。 数式自体は厳密に見えますが、ヒューマンファクターで構成されるインジケーターが支配的です。
クリーンルーム方式などの正式な開発プロセスでは、厳格で実証可能な方式が徐々に見つかっています。 以前はぼやけたテーマをその下にもたらすために、明るい線を上げます。
実際、正式なプロセス研究者は、さまざまな問題の解決に進歩を示しています。 しかし、彼らはこのリストの最初の異議に違反していることがわかります。厳密な決定に屈するにはソフトウェア開発をあまりにも狭く定義します。 正式な方法は、人間の参加と解釈に基づいた問題を単に自分自身で簡単に解釈します。 たとえば、正式な開発方法の重要な要素は、厳密で明確な仕様の作成です。 これらの仕様は、その後の開発ステップを実行（および証明）するために使用されます。 もちろん、正式なメソッドには、セマンティック表記法の明確なスキームが含まれている場合があります。 しかし、プログラムが何をすべきかについての人々の漠然とした考えを曖昧な状態に変換する方法に関する正確なレシピを含む正式な方法はありません。
これらの反対に反して、ソフトウェア開発は従来の正式な情報学とは本質的に異なると述べています。 前者は人に依存し、後者はそうではありません。 これにより、コネルの結論に至ります。
ソフトウェア開発の基本的な結果を証明する試みは停止されるべきであり、この分野での重要な成果は一般的な推奨事項に過ぎません。
たとえば、1972年のDavid Parnassusは、「 システムをモジュールに分解するための基準について」というすばらしい科学記事を書きました。 彼女は、Parnassusが別のソフトウェア設計戦略を使用して行った簡単な実験について説明します。1つは情報の隠蔽、もう1つはグローバルデータの可視化です。 次に、この小さな実験に基づいて、彼はいくつかの結論を導き出し、勧告を行いました。 この記事には何も立証されておらず、Parnassusは、推奨事項に従うことで誰もが同様の結果が得られることを保証しません。 しかし、この記事には賢明なアドバイスが含まれており、オブジェクト指向プログラミング言語の人気に大きな影響を与えています。
別の例は、 CMMIとして知られるカーネギー大学メロン大学ソフトウェア工学研究所の大規模な研究です。 CMMIはソフトウェア開発プロセスのモデルとして始まり、現在では成長しており、他のタイプのプロジェクトも含まれています。 CMMIの長さは約1,000ページで、例、解釈、およびトレーニング資料は含まれていませんが、1,000人年以上の作業を表しています。 多くの大規模な組織がこれを使用し、ソフトウェア開発プロセスと製品を大幅に進歩させました。 しかし、CMMIには確証された単一の結果はありません。 これは、過去に他の組織にとって効果的だった方法に基づいてソフトウェアプロジェクトを編成する方法に関する（適切に設計された）提案のセットです。 実際、ソフトウェア工学研究所は、CMMIはプロセスではなく、むしろメタプロセスであり、その詳細は各組織によって記入されると述べています。
同じ流れの他の研究分野は、設計パターン、建築スタイル、疑わしい方法に基づくリファクタリング、柔軟な開発方法論、データの視覚化です。 これらの分野には、実証済みの結果が部分的に含まれている場合がありますが、一般的に、最初は人間の参加が含まれるシステムを対象としています。 明確にするために、重要な情報学のトピック（明るい線の下）は、開発者にとって重要なツールです。 高性能アプリケーションを設計する際には、アルゴリズムの知識が重要です。 キューイング理論は、オペレーティングシステムの中核を設計するのに役立ちます。 クリーンルームの方法論は、状況によっても役立ちます。 統計の分析は、同様のグループの参加者と同様のプロジェクトを計画するときに役立ちます。 しかし、形式主義は単に必要であり、良い発展のための十分な条件ではありません。 例として建設と建築（つまり、家と建物）を見てみましょう。
素晴らしい土木技師、建築材料、応力-ひずみ依存性、荷重分布、ウインドシアー、震え保護などの世界最高の専門家を想像してください。この男は彼を呼ぶためにすべての国の建築家のノートにリストされています各建設プロジェクトに関する協議。 この神話的な土木技師は、彼が分析する建物の設計も上手くいくのでしょうか？ まったくありません。 彼は、クライアントとの会話で失われ、生活に快適な場所を設計することができず、彼の想像力は新しい問題の解決策を考え出すのに十分ではなく、地獄に退屈しています。 建設技術は実際の建築家には便利ですが、良いプロジェクトには十分ではありません。 成功するアーキテクチャには、創造性、構想、学際的な思考、ヒューマニズムが必要です。
同様に、古典的なコンピューターサイエンスはソフトウェア開発に役立ちますが、決して十分ではありません。 優れたソフトウェアを設計するには、創造性、概念、学際的思考、ヒューマニズムも必要です。 この観察は、ソフトウェア開発プロセスの研究者を解放します。 彼らは成功する方法の学習に時間を費やすことができます。将来の実践者のために集合的な知識を蓄積します。 ソフトウェア開発を数学的ベースでコンピューターサイエンスの拡大に絞るべきではありません。 これは機能せず、まだ彼らの時間を待っている有用な発見から私たちをそらすかもしれません。
謝辞
このテーマに興味を持った議論をしてくれたSteve Homerに感謝します。