私のキャリアの中で、物理理論と教育/管理理論という 2 つの広いタイプの理論に出くわしました。
物理的な理論は、物理的な世界によって判断されるように、(適切な条件下で) 正しいか正しくないかのいずれかです。
教育/経営理論は物理理論のように見えますが、厳格なテストが欠けています。せいぜい、問題についての新しい考え方を提供するだけです。複数の理論が役に立ちます。
ソフトウェア エンジニアリングの愛好家の学生として、ソフトウェア エンジニアリングには多くの理論があるようです (アジャイル プログラミング、テスト駆動設計、パターン、エクストリーム プログラミングなど)。これらの理論は物理的なものと考えるべきですか、それとも教育的/管理的なものと考えるべきですか?
それとも、ソフトウェア エンジニアリングを誤解していて、自分が「間違っていない」立場にいることに気付いたのでしょうか。
ソフトウェア エンジニアリングは、究極的には心理学、つまり人間がどのように複雑さを管理するかに関するものです。したがって、ソフトウェア エンジニアリングの原則は、物理的な原則というよりも、教育や経営の理論にはるかに似ています。
O(n log n) の並べ替えは O(n^2) の並べ替えよりも高速であるなど、一部のソフトウェア エンジニアリングにはしっかりした数学があります。メンテナーが狂わないように物事を整理する方法、変更される可能性があるものと変更されないものを予測する方法、ヒューマンエラーを防止および検出する方法など。心理学または社会学の一分野です。
適切な理論的分割は、「よりハードな」科学 (証明がある場合) と、質的な答えと証明があったとしてもほとんどないソフトなトピックだと思います。
私にとってソフトウェアとは、主に言語とコミュニケーションに関するものであり、主に質的で主観的なトピックです。ときどき、証明と厳密な形式が存在するアルゴリズムやその他の「難しい」領域に触れます。はい、両方お願いします。
間違っていません。
すべてのソフトウェア工学の「理論」は、あなたとあなたのチームの生産性を向上させるかどうかを確認するための特定の事柄に関するアドバイスにすぎないようです。科学理論のように反証可能に設定できたとしても、ほとんど意味がありません。それは、それらについて学ぶ価値がないと言っているのではなく、逆に、できるだけ多くのそれらに精通し、どのような種類のチームや環境でよりうまく機能するかを理解しようとする必要があります. ただし注意してください。ドグマや特効薬があると考えるのは避けてください。
アジャイル プログラミング、テスト駆動設計、パターン、エクストリーム プログラミングなどを「理論」とは呼びません。それらは方法論、または作業スタイルです。彼らは何の主張もしません。
一般に、情報学の分野は 4 つの分野に分けられます (ソースへのリンク、SWEBOK を見つける必要がありますか?)。
Steve McConnel の「Professional Software Development」には、工学と科学の優れた分析があります。彼のSoftware Engineering, Not Computer Science をチェックしてください。
ソフトウェア開発は、何よりもエンジニアリング、つまり実際の問題に対する実際的な解決策を見つけることです。ソフトウェア エンジニアリングがコンピューター サイエンス、数学、複雑性理論、系統学、心理学、およびその他の分野に依存していることは間違いありませんが、それらのいずれとも同一視することはできません。
私にとって、それは私自身の理論であり、他の多くの理論がベースとして使用されています。単一の特定の理論を使用している人は誰も知りません。そして、それは警官の答えではありません。
異なる言語があるように、理論/実践/方法論は異なる状況で使用されます。構造、規則、および定義は、人々が物事がどのように達成されるべきかを理解するすべての方法ですが、達成されるべきことは主観的です。
クライアント、プロジェクト、プログラマー、時間、そして特にあなたを成功/幸せにするものの裁量で、アジャイル、極端、または他の方法を知って適応します。チームになり、チームがより大きな利益のために行っていることに適応/適応します。あなたが自分の心の中で定義した何かを持っていることを覚えておいてください、さもなければそれは単なる混乱ではありません。
[SOAPBOX]変換されたフラットキーボードと64Kアップグレードを使用してAtari400でプログラミングを開始しました。私が大学を始めたとき、経済学の教師がグラフや視覚的な入力を使用して経済学についてもっと学ぶのに役立つ教育ツールを構築するために使用したのはVB1.0でした。かっこよかった！そして、私はそれができることを知っていました。
後にIT教師にもなる（彼は良かった）この同じ経済学の教師は、私がデバッグのクラスを教えるかどうか尋ねました。彼は、「概念を理解し、あなたと同じくらい速くデバッグする自然な能力を持っている人に会ったことがありません。あなたが知っていることとそれをどのように行うかを教えてくれませんか」と語った。もちろん、これは私のエゴを後押ししましたが、他の人を教え、指導し、助けるためでした。
それらのインスタンスのすべてが、他の人々を助けたいという私の願望を実現しました。私にとって、私はコンピューターが自分のやりたいことを正確に実行し、ビジネスや家庭生活の他の人々が生活の質を高め、より多くを学び、より多くのことを成し遂げるのを助けることを望んでいます。
ある時、誰かが私に「あなたはあなたの道具と同じくらい良いだけだ」と言いました。学び、実践し、成長します。
あなたが何かを定義し、それが機能し、秩序があり、そしてそれがあなたと境界を伸ばすなら、あなたは間違っていません。
「ソフトウェア工学」のような考え方はありますか？
それともソフトウェア開発は「エンジニアリング」ですか？
事実:
現実か幻想か？一つを選ぶ ：-）
一部の人は、私たちは若い「エンジニアリング」ブランチであるため、「確固たる」実践と「理論」を持っていないと言いますが、やがてはそうなるでしょう。彼らは、もっと「理論」や基礎を働かせる必要があると言っています。
問題領域の性質上、ソフトウェア開発は「実験的な社会活動」であると言う人もいます。私たちは理論と方法論のプロセスを実践しますが、それらは常に二次的な効果をもたらします。ユニークな人々、彼らの感情の質、および他の人々との相互作用は、より影響力があります. 彼らはソフトウェア開発を複雑な適応システムと見なしています
そしてもうひとつの現実があります
ソフトウェア開発活動の 80% は、非常に頭脳明晰である必要はありません。「平均的な」人なら誰でもできます。
しかし、残りの 20% の部分は非常に難しく、学際的なタスクです。
別の新しい視点がありますMy One :-)
この見解は、ソフトウェア開発は「エンジニアリング」の一分野ではないということです。「自然科学・社会科学」の分科です。したがって、ソフトウェア人類学と人類学者が必要です。
理論の他に、フレームワーク、モデル、および経験則もあります。アイデアは確かに、しかし厳密ではない基礎に基づいており、大まかにあなたの教育/管理カテゴリに属しています.
コンピューター サイエンスにはいくつかの強力な基礎理論 (あなたの定義では物理的な理論) がありますが、これらのほとんどは、より小さな要素を結び付けることで構成されています。
一方、ソフトウェア エンジニアリングは比較的新しい分野であり、コンピュータを利用し、場合によってはコンピュータ サイエンスを利用してソフトウェア システムを構築します。そのアリーナでの実践のほとんどは、厳密ではない実験的および逸話的な証拠に完全に基づいています。最も単純な問題でさえ陪審はまだ出ていないので、実践に合格するもののほとんどは、純粋な当て推量と不合理な好みとして最もよく説明できます. これは、非常に不安定なカードの家にどれだけのものが構築されているかを理解するために、本当に多くのことを知らなければならない分野の 1 つです。
ポール。
プログラミングは無形であるため、他の人間、他のプログラマーと関連付けるのが非常に難しい作業です。ソフトウェアエンジニアリングは、構造がないところに構造を追加しようとしますが、そのような構造は現実の必然性に根ざしたものではありません。したがって、これらのアプローチはすべて、技術的な神 (または悪魔) をなだめようとするときに人々のグループがどのように振る舞うかという点で、宗教のようになります。
これらすべての理論とベスト プラクティスは、ソフトウェア システムを確実かつ予測どおりに作成できるようになるまでには至っていません。これらの調査の最新のものは 2001 年のものです。Jeff の 2006 年のコラムでは、依然として失敗率が高いことを嘆いています。
誰かが最新の調査に取り組んでいるかどうかを確認するのは興味深いでしょう.
アビオニクスと私の車を動かしているソフトウェアは、エンタープライズ ソフトウェアで引用されている速度に近いものでは失敗していないようです。企業の開発者が自分たちの慣行にもっと厳密に従わないのはなぜですか? たぶん、私たちは皆、Ada を書いているはずです....[冗談です]
それらはレシピのようなものです: それらはガイドラインであり、その成功は以下に依存します: