トライアルトピックは、最初の章の本の主要な段落のセクションです。 ボリュームは4倍に縮小され、可能であればプレゼンテーションの順序と意味が保持されます。 フィードバックをお待ちしています。

なぜ自分の言葉ではなく、本の段落を正確に書いたのですか？ 多くの場合、より良いと言うのは非常に難しいからです。 そして、退屈な要約は読むのが退屈です-2ページ目は退屈です。
トピックが気に入ったら、ボリュームを減らして情報の密度を上げるたびに、本全体を記事で説明する準備ができています。

ソフトウェア工学

ソフトウェア設計とは何ですか？

ソフトウェア開発は簡単なプロセスではなく、多くのコンポーネントを含めることができます。 科学者が過去25年間に特定したソフトウェア開発のコンポーネントは次のとおりです。
-問題の定義;
-要件の開発;
-設計計画の作成。
-ソフトウェアアーキテクチャ開発、または高レベル設計。
-詳細設計;
-コーディングとデバッグ。
-ブロックテスト。
-統合テスト;
-統合;
-システムのテスト。
-修正メンテナンス。

構築は「コーディング」または「プログラミング」と呼ばれることもあります。
この場合、「コーディング」は最良の用語ではないようです。
は、開発された計画をプログラミング言語のチームに機械的に翻訳することを意味しますが、構築はまったく機械的なプロセスではなく、創造性と分析に関連付けられることがよくあります。 「プログラミング」と「デザイン」という言葉の意味は似ているように思われますが、それらを平等に使用します。

特定の設計タスクを次に示します。
-設計を成功させるために必要な条件の検証。
-後続のコードテストのメソッドの決定。
-クラスとメソッドの設計と作成。
-変数および名前付き定数の作成と命名。
-制御構造の選択とチームブロックの編成。
-ブロックテスト、統合テスト、独自のコードのデバッグ。
-グループのメンバーによるコードと低レベルのプログラム構造の相互レビュー。
-コードを慎重にフォーマットおよびコメントすることによりコードを「研磨」します。
-個別に作成されたソフトウェアコンポーネントの統合。
-パフォーマンスの改善と削減を目的としたコードの最適化
リソースの使用度。

ソフトウェア設計がなぜそれほど重要なのですか？

- デザインはソフトウェア開発プロセスの大部分です。 プロジェクトの規模にもよりますが、通常、設計には合計時間の30〜80％がかかります。

- デザインはソフトウェア開発プロセスの中心です。 アプリケーションとそのアーキテクチャの要件は、その有効性を確保するために設計段階の前に開発されます。 システムテスト（厳密には）は、構築後に実行され、その正確性を検証するのに役立ちます。

-設計への関心が高まると、個々のプログラマの生産性が大幅に向上します。

-構成の結果-ソースコード-は、多くの場合、プログラムの唯一の真実で関連性のある説明です。

- 実行する唯一のプロセスはデザインです
すべての場合。

最終的に、ソフトウェア設計の能力が決定します
あなたがプログラマーであることがどれほど良いか。

メタファーの理解を深める

コンピュータサイエンスの用語は、最もカラフルなものの1つです。 確かに
ウイルス、トロイの木馬、ワーム、バグ、その他の生き物や悪霊で満たされた、温度が慎重に制御された無菌室は、他のどの地域にありますか？

比phorの重要性

アナロジーを描くことは、しばしば重要な発見につながります。 まったく比較していない
似たような、しかしより理解しやすい、理解可能な現象
問題への対処方法。 この比phorの使用はモデリングと呼ばれます。
科学の歴史には、隠phorのおかげで発見がたくさんあります。 それで、夢の中で化学者ケクルは、ヘビが尾をつかんでいるのを見ました。 目を覚ますと、彼はベンゼンの性質が類似の環形状を有する分子構造によって説明されることに気づいた。 さらなる実験により、彼の仮説が確認されました（Barbour、1966）。

一般に、モデルの有効性は、その明るさと概念によって説明されます
整合性。 モデルは科学者の特性、関係、有望なことを示唆している
研究分野。 モデルが誤解を招く場合があります。 原則として、メタファーの過度の一般化はこれにつながります。 エーテルの検索は、モデルの過度の一般化の良い例です。

時には人々は比metaの本質を単純化します。 説明されている各例について
「もちろん、正しいメタファーの方が便利です。 別の比phor
間違っていました！」それはそうですが、あまりにも単純な見方です。 科学の歴史は、「間違った」メタファーから「真の」メタファーへの一連の移行ではありません。 これはシリーズです
「あまり良くない」メタファーから「最高の」メタファーへの移行。

ソフトウェア開発は、比較的若い科学分野です。 彼女は十分ではありません
標準的な比のセットを持つように成熟しました。 したがって、質量が含まれます
二次的で対立する比phor。 それらのいくつかは他のものよりも優れています-悪い。
メタファーをどれだけ理解するかによって、理解度も決まります。
ソフトウェア開発。

比phorの使用方法

ソフトウェア開発を特徴付ける比phorは、ロードマップというよりもスポットライトのようなものです。 彼女は答えを見つける場所を言っていない-彼女はそれを検索する方法を言います。 メタファーは、アルゴリズムというよりもヒューリスティックなアプローチです。

アルゴリズムとヒューリスティックの違いは微妙であり、いくつかの点でこれら2つの概念は重複しています。 それらの主な違いは、決定の間接性の程度を考慮します。 アルゴリズムは、コマンド自体を提供します。 ヒューリスティックは、コマンドを自分で発見する方法、または少なくともコマンドを探す場所を示します。

次に、ソフトウェア開発を特徴付ける一般的なメタファーを検討します。

文学の隠phor：コードの記述

ソフトウェア開発を記述する最も原始的なメタファーは、「コードを書く」という表現に由来します。 文学のメタファーによれば、プログラム開発は手紙を書くことに似ています。テーブルに座って、紙、ペンを取り、最初から最後まで手紙を書きます。 これは正式な計画を必要とせず、書簡で表現された考えは著者によって途中で定式化されます。

叔母に平凡な手紙を書く場合、同様のアプローチが実用的です。 ただし、「ライティング」ソフトウェアのメタファーの最初の拡張
プログラムのコピーは、大規模システムが10階建てのオフィスビルやオーシャンライナーのコストにすでに達しているソフトウェア開発の世界では、最良のアドバイスではありません。

農業のメタファー：成長システム

一部の開発者は、ソフトウェア開発は
作物の成長との類似。 別のブロックを設計し、エンコードし、テストしてシステムに追加します。
そのたびにその機能。 このようにタスクを多数の小さなアクションに分割すると、各段階で発生する可能性のある問題が最小限に抑えられます。

この比phorの弱点は、直接的なものがないという仮定です
ソフトウェア開発の制御。 春にコードの種をまくだけで、もしあれば
偉大なカボチャの意志があり、秋には前例のないコードの収穫を受け取るでしょう。

真珠のメタファー：システムの増分が遅い

ソフトウェアの成長について話すとき、実際には増分を意味する場合があります。
降着 これら2つの比phorは密接に関連していますが、2番目はより説得力があります。 増分は、少量の炭酸カルシウムの堆積による真珠形成のプロセスを特徴づけます。 地質学および法学では、降着は、水に含まれる岩の堆積による陸地面積の増加を意味すると理解されています。

これは、堆積岩からコードの作成を習得しなければならないという意味ではありません。 つまり、ソフトウェアシステムに一度に小さな断片を追加することを学ぶ必要があります。 言い換えれば、したがって
心、「増分」、「反復」、「適応」、「進化」という用語です。 インクリメンタルな設計、構築、およびテストは、最も効果的なソフトウェア開発の概念の一部です。

漸進的な比phorの長所は、過度の約束をしないことです。 さらに、農業のメタファーほど簡単には拡張できません。 真珠を形成する巻き貝は、漸進的な開発または付加のための優れた視覚化です。

比metaの構築：ソフトウェアの構築

「構築」ソフトウェアの比phorは、「作成」または「成長」ソフトウェアの比phorよりも有用です。これは、ソフトウェアの付加の考え方と一致しており、より詳細なガイダンスを提供するためです。 ソフトウェアの構築とは、計画、準備、実装の段階が存在することを意味し、その種類と重大度は特定のプロジェクトに依存します。 この比phorを探索すると、他の類似点が見つかります。

メータータワー、しっかりした手、平らな表面、
ビール缶10個、100倍高いタワーには十分ではありません
ビール缶の100倍。 このようなプロジェクトには、まったく異なる計画と設計が必要です。

比phorの組み合わせ

メタファーは本質的にアルゴリズムではなくヒューリスティックであるため、
お互いを除外しません。 降着比metaと構築比phorの両方を使用できます。 必要に応じて、ソフトウェア開発は手紙を書いて、この比phorを車の運転、狼男の狩り、またはタールの水たまりに詰まった恐竜のイメージと組み合わせることと考えることができます。 あなたの思考を刺激したり、グループの他のメンバーとコミュニケーションをとるのに役立つメタファーまたはそれらの組み合わせを使用します。

比phorの使用は微妙な問題です。 比phorがあなたを価値あるものに導くために
ヒューリスティックな推測、それを展開する必要があります。 ただし、拡張しすぎたり、間違った方向に拡張したりすると、誤解を招く可能性があります。 いずれかのように
強力なツール、メタファーは間違った方法で使用できますが、
彼らの力により、彼らはあなたの知的ツールの貴重なコンポーネントになることができます。

重要なポイント：
-ソフトウェア設計と建物の建設の比較は、プロジェクトの注意深い準備の必要性を示し、大規模プロジェクトと小規模プロジェクトの違いを明確にします。
-プログラマーの知的ツールキットのソフトウェア開発方法とツールの類似性は、
プログラマーにはさまざまなツールがあり、普遍的なツールはありません。 適切なツールを選択することは、効果的なプログラミングの条件の1つです。
-比phorはお互いを排除しません。 比phorの組み合わせを使用します。
あなたの場合に最も効果的です。

7回測定、1回カット：前提条件

家の建設を開始する前に、建築業者は図面を見て、すべての許可が取得されているかどうかを確認し、基礎を調べます。 建設業者は、超高層ビル、住宅、犬小屋の建設に別の準備をしていましたが、プロジェクトが何であれ、プロジェクトのすべての機能を考慮して誠意を持って準備していました。

この章では、ソフトウェア設計の準備のためのコンポーネントについて説明します。 どうやって
建設では、ソフトウェアプロジェクトの最終的な成功は、建設が始まる前に大部分が決定されます。 基盤が信頼できない場合、または計画が不注意に行われた場合、設計段階でせいぜいできる
害を最小限に抑える

前提条件の重要性

高品質のソフトウェアを作成するすべてのプログラマに共通する機能は、ソフトウェアの品質を重視する高品質の方法を使用することです。
プロジェクトの開始、中間、終了。

設計は作業の中間段階であるため、建設が始まる頃には、プロジェクトの成功はすでに部分的に事前に決定されています。 それでも、設計プロセス中に、少なくとも状況がどれほど安全であるかを判断し、障害の黒い雲が地平線に現れた場合に戻ることができるはずです。

建設を始める前に前提条件を満たすための最も説得力のある議論

すでに問題定義の山に登り、道を1マイル歩いたとします
要求をし、建築の噴水に汚れた服を捨て、
準備の透明な水に浸した。 したがって、あなたは前にそれを知っています
システムの実装では、システムの機能と方法を理解する必要があります。

ソフトウェアシステムの作成は、他のプロジェクトに必要なものと同様です。
人的および財政的資源。 家の建設は目詰まりから始まりません
ネイル、および図面の作成、分析、承認。 ソフトウェアを開発するとき、技術的な計画を立てることはそれ以下を意味します。

プロジェクトの準備は、効果的なプログラミングの主な条件の1つであり、これは論理的です。 計画の量は、プロジェクトのサイズによって異なります。 管理の観点から、計画には、作業を完了するために必要なタイミング、人数、およびコンピューターの数が含まれます。 技術的な面では、計画には作成中のシステムのアイデアが含まれます。これにより、間違ったシステムの作成にお金を費やすことができなくなります。 ユーザーは、何を受け取りたいかが明確にわからない場合があり、要件を判断するよりも手間がかかる場合があります。 必要なものを作成せずに結果を盗み、最初からやり直すよりも安いかもしれません。 システムの作成を開始する前に、それをどのように作成するかを考えることも同様に重要です。 迷路で実りのない放浪に時間とお金を費やしたい人はいません。

Hewlett-Packard、IBM、Hughes Aircraft、TRWなどの科学者
組織は、設計の開始時にバグを修正すると、プロジェクトの終了時、アプリケーションテスト中、またはリリース後に修正するよりも10〜100倍少ないコストであることがわかりました（Fagan、1976; Humphrey、Snyder、and Willis、1991; Leffingwell 1997 ; Willis et al。、1998; Grady、1999; Shull et al。、2002; Boehm and Turner、2004）。

作業しているソフトウェアの種類を特定する

何を開発していますか？
-人々の生活が依存する組み込みシステム
-ビジネスシステム
-対象システム

ビジネスシステムを開発するときは、計画、要件の開発、およびアーキテクチャ設計が、設計、システムのテスト、および品質保証に点在する高度に反復的なアプローチを使用することをお勧めします。 要件の安定性はシステムの最高の信頼性の条件の1つであるため、人々の生活が依存するシステムには、より一貫したアプローチが必要です。

前提条件に対する反復アプローチの影響

反復法を使用する場合、特に前提条件をいじる必要はないと主張する人もいますが、この観点は間違っています。 反復的アプローチは不十分な準備の結果を弱めるが、そうではない
それらを排除します。

前提条件を減らした反復プロジェクト
条件またはそれなしで、2つの同様の順次プロジェクトとは異なります
側面。 まず、反復的なアプローチでは、欠陥を早期に検出するため、欠陥を修正するコストは通常​​低くなります。

第二に、反復的なアプローチにより、プロジェクト全体にコストが分散され、
最後にグループ化するのではなく。 最終的に、反復的アプローチと順次的アプローチの両方で、総コストは同様になりますが、最初のケースでは
それは分割払いで支払われるため、それほど大きくは見えません。

一般的な経験則の1つは、要件の約80％を事前に定義し、後で追加の要件を定義する時間を確保し、作業中に体系的な変更管理を実行して、最も重要な要件のみを受け入れることです。 別のオプションも可能です。最も重要な要件のみの20％を事前に決定し、残りのソフトウェアを小さな断片で開発し、追加の要件と改良を定義して、進行に応じてアプリケーションプロジェクトを完成させることができます。

次の場合は、より一貫性のあるアプローチ（問題が事前に解決される）を選択できます。
-要件はかなり安定しています。
-ドラフトアプリケーションはシンプルで比較的明確です。
-開発チームはアプリケーション領域に精通しています。
-プロジェクトが特定のリスクに関連付けられていない。
-プロジェクトの長期的な予測可能性が重要です。
-要件、アプリケーション設計、およびコードを変更するコストがかかる可能性が高い
高いことが判明しました。

次の場合は、より反復的なアプローチ（作業中に問題が解決される）が推奨されます。
-要件が比較的わかりにくい、または他の理由で不安定になる可能性があるように思えます。
-ドラフトアプリケーションが複雑である、完全に明確ではない、またはその両方。
-開発チームはアプリケーション領域に不慣れです。
-プロジェクトには高いリスクが伴います。
-プロジェクトの長期予測可能性は特別な役割を果たしません。
-要件、アプリケーション設計、およびコードを変更するコストがかかる可能性が高い
低くなります。

繰り返しになりますが、逐次アプローチよりも効果的です。 必要に応じて、前提条件を特定のプロジェクトに適合させ、多かれ少なかれ形式的または完全にすることができます。

問題定義の前提条件

構築する前に満たす必要がある最初の前提条件は、システムが解決しなければならない問題の明確な声明です。

問題の定義は、単に問題の本質を表明するものではなく、
または彼女の可能な解決策のヒント。 数ページかかる場合がありますが、
問題のように聞こえるはずです。 「当社のGigatronシステムは注文処理を処理できません」というフレーズは問題​​のように聞こえ、適切な定義です。 ただし、「Gigatronシステムが注文の処理を処理できるように、自動データ入力モジュールを最適化する必要があります」というフレーズ-
問題の不十分な定義。 問題ではないようですが、解決策です。
問題の定義は、詳細な要件の開発に先行します。
問題のより深い研究です。

問題は、ユーザーが理解できる言語で定式化し、ユーザーの観点から問題を説明する必要があります。 通常は問題
コンピューター用語で定式化すべきではない
その解決策はコンピュータープログラムではないかもしれません。 年間利益を計算する必要があるとします。 四半期ごとの利益の計算
コンピューター化。 プログラミングで行き詰まったら、それを決めなさい
既存のアプリケーションでは、年次計算機能を追加するだけです
すべての結果をもたらした：人件費
開発者など。少し考えてみたら、少しだけ取り上げてください。
年に一度、次の4つの数字を要約する秘書の給与
電卓。

問題がコンピューターに関するものである場合、この規則の例外は受け入れられます。プログラムのコンパイルが遅すぎるか、プログラミングツールがエラーでいっぱいです。 このような場合、問題はプログラマーに馴染みのあるコンピューター用語で定式化できます。

問題の適切な定義がなければ、間違った問題の解決に努力することができます。

要件を作成するための前提条件

要件の明示的なセットの重要性は、いくつかの理由によるものです。
「 明示的な要件は、システム機能がプログラマ固有ではなくユーザー定義であることを保証するのに役立ちます。」 要件が策定されている場合
明示的に、ユーザーはそれらを分析して承認できます。

「明示的な要件があることで、紛争を回避できます。」

- 要件への注意は、開発開始後のシステム変更を最小限に抑えるのに役立ちます。 コーディング中にコードにエラーが見つかった場合、数行を変更して作業を続行します。 コーディング中に要件にエラーが見つかった場合、変更された要件に合わせてドラフトプログラムを変更する必要があります。

ソフトウェア安定性の神話

おそらく、ポンティアックアステカは最も壮大な車だと思います
これまでに作成された、フラット地球の信者の社会のメンバーです
そして4年ごとにニューメキシコ州ロズウェルへの巡礼をします
エイリアンの着陸場所。 もしそうなら、あなたはそれを信じ続けることができます
プロジェクトの要件は変更されません。 すでに信じていない場合
サンタクロースで、または少なくともそれを認めることをやめた、あなたは何かすることができます
要件の変更への依存を最小限に抑える手順を実行します。

プログラムの設計中に要件を変更する場合はどうすればよいですか？

チェックリストを使用して要件の品質を評価します。
セクションの最後にあります。 要件が十分でない場合は、作業を中止し、戻って修正します。

- 誰もが要件の変更の価格を知っていることを確認してください 。 新しいことを考える
機能、顧客は興奮しています。 彼らの血は液化し、延髄に溢れ、幸福感に陥り、要件、署名式、およびすべての文書の議論に捧げられたすべての会議を忘れます。 新しい機能に困惑しているこのような人々を落ち着かせることは最も簡単です。「うわー、これは本当に素晴らしいアイデアです！ しかし、それは要件ドキュメントに含まれていないため、作業スケジュールと見積もりを修正して、今すぐ実装するか後で実装するかを決定できるようにする必要があります。 「スケジュール」と「推定」という言葉は、コーヒーや冷たいシャワーよりも落ち着いていて、多くの要件がすぐに願いに変わります。

-変更管理手順の定義

-変更に適応する開発アプローチを使用する

-要件が特に失敗した場合は、プロジェクトを終了します。

- プロジェクトのビジネスモデルを記憶する

チェックリスト：要件

次のチェックリストには、要件の品質を判断するための質問が含まれています。 本もこのリストも、要件を適切に開発することを教えてくれません。 建設中に使用して、立っている地面の固さを判断します。

すべての質問がプロジェクトに関連するわけではありません。 取り組んでいる場合
非公式のプロジェクトなので、いくつかの問題について考える必要さえありません。 他の質問も重要ですが、正式な回答は必要ありません。 ただし、大規模で正式なプロジェクトに取り組んでいる場合は、おそらくすべての質問に答える必要があります。

特定の機能要件

-システムへのデータ入力のすべての方法は、ソース、精度、値の範囲、および入力頻度の指示で定義されていますか？
-データの出力方法はすべて、システムによって定義されており、目的、精度、値の範囲、頻度、形式を示していますか？
-Webページ、レポートなどにすべての出力形式が定義されていますか？
-すべての外部ハードウェアおよびソフトウェアインターフェイスが定義されていますか？
-すべての外部通信インターフェースは、接続の確立、エラーチェック、および通信のためのプロトコルで定義されていますか？
-ユーザーが完了する必要があるすべてのタスクが特定されましたか？
-各タスクで使用されるデータと、各タスクのパフォーマンスから生じるデータは定義されていますか？

特定の非機能要件（品質要件）

-必要なすべての操作について、ユーザーの予想応答時間が決定されていますか？
-データ処理時間、伝送速度、システム帯域幅など、他の時間パラメーターは定義されていますか？
-システムのセキュリティレベルは決定されていますか？
-システムの信頼性は、その動作の障害の結果、障害から保護されるべき情報、エラーを検出および修正するための戦略などの側面を含めて決定されていますか？
-メモリ容量の最小プログラム要件が定義されており、
空きディスク容量？
-特定の機能、OS、および他のアプリケーションとのインターフェースの変更に適応するシステムの能力など、システムを維持する利便性の側面はありますか？
-成功の定義は要件に含まれていますか？ それとも失敗？

品質要件

-要件はユーザーが理解できる言語で書かれていますか？ ユーザーはこれに同意しますか？
-要件間に矛盾はありますか？
-最初の仮定の違反に対する抵抗性や正確性など、拮抗薬パラメーター間の許容可能なバランスが定義されていますか？
-要件に設計要素はありますか？
-要件の詳細レベルは合意されていますか？ 要件をさらに詳細に定義する必要がありますか？ 詳細が少ない？
-要件は、独立した設計チームに伝えられるほど明確ですか？ 開発者はこれに同意しますか？
-各要件は問題とその解決策に関連していますか？ 問題のある環境で、すべての要件をそのソースにトレースすることは可能ですか？
-すべての要件をテストすることは可能ですか？ すべての要件が満たされているかどうかを判断できる独立したテストを実施することは可能ですか？
-要件のすべての可能な変更と各変更の可能性が特定されていますか？

要件の完全性

-開発の開始前に決定できない、不足している要件はありますか？
-アプリケーションがすべての要件を満たせば許容できるという意味で、要件は完全ですか？
-不快感を感じますか？ 実装に適さず、クライアントまたはボスを安心させるためだけに含まれていた要件を除外しましたか？

スティーブマッコネル