[#s88cb27a]-ソフトウェアはデータからなるのではなく、ロジック(論理)の塊から構成されている。--ロジックとは入力の組み合わせによる特別な動作のことである。--そのため、ソフトウェアのテストを考える場合は、ソフトウェアの入力が系統的にロジックを網羅し、正しく動作することを確認しなければならない。-ソフトウェアは非常に複雑な構造を持っている。--そのため、[[ソフトウェアテスト]]も複雑になることがある。-ソフトウェアとは、実世界にある問題を、その要求を満たすように設計され、プログラムコードとして実現されるものである。-ソフトウェアには概念構造体に関わる本質的性質と、周辺的なツールやオペレーションなどに関わる偶有的性質とがある。--「本質」(essential)と「偶有」(accidental)という用語は、ブルックスが『人月の神話』の中で使用している。元々は[[アリストテレス]]の哲学が基になっている概念である。--ソフトウェアの本質的なもの:プログラミング言語、ライブラリ、フレームワーク、使用記述言語など---時代の流れと共に、新しいものが出現しては消えていく運命にあるため。--ソフトウェアの偶有的なもの:データセットやデータ項目間の関係、アルゴリズム、モジュール化された機能の呼び出しなど-ソフトウェアの代表的な領域が言語処理系である。--自由に言語設計をしても、それを解析し実行できる処理系を構築できるとは限らない。-ソフトウェア開発にとって最も重要なことは、「ソフトウェアがどのような人に、どう使われるか」ということである。--構造化やオブジェクトテクニックが目的であっては何も作れなくなる。[補講]書籍の場合の本質的なものと偶有的なものを次に示す。-本質的なもの--書籍の内容、構造、物語など-偶有的なもの--紙の質、文書殺性ツールなど◇-ソフトウェアとは実世界の問題を解くためにある。-ソフトウェアは周辺のハードウェアや外部の装置、システムに受動的に同調させなくてはならない。-ソフトウェアは複雑な概念構造体であるために不可視である。-ソフトウェアの世界では、開発プロセスを標準化し、作業の種類を類型化して、それらの間の依存関係を決める方法が採られることがよくある。これはソフトウェアの可視化という観点からはほとんど意味がない。--多人数のプロジェクトで、マネジメント上の必要性から役割分担を行い、それぞれの人やチームの段取りを決めておくことは必要なことである。無駄を省き、生産性を向上させるために計画を立てなくてはならない。いった活動によって可視化される事柄は、あくまでも段取りの可視化であってソフトウェアの可視化ではない。-ソフトウェアとは最初の段階で不明確で曖昧なものである。--不確定で曖昧なものをブナ帰することはできない。これがトップダウン型のアプローチが破綻した理由である。--また、プロジェクトの[[WBS]]を決定していく方法も現状ではトップダウン型にならざるを得ない。---よくわかっていない不明瞭なプロセスを分解することはできないから、WBS主体の[[プロジェクトマネジメント]]手法はそれだけではうまくいかない。-ソフトウェアが保守・拡張・改変を繰繰り返していくと、同じような機能拡張でも時を経ると段々と工数が膨らむ。--これは一般的に構造劣化によるものである。---ソフトウェアを構成しているコンポーネントが複雑になり、これらの間の依存関係も増えてくると、一部を拡張したときの変更波及範囲が広がり、それに対応して考慮すべき事項も増え、全体のテスト工数も膨らむ。ある臨界点を超えるとシステム全体の品質も維持できなくなり、全体を作り替えた方が近道となってしまう。いった状況ではシステムの寿命が尽きているといえる。ソフトウェアは[[著作権]]と[[特許権]]で保護され得る。プログラムの表現は著作権で保護され、[[アルゴリズム]]は特許権で保護されている。著作権の保護はプログラムそのものである。特許権の保護はプログラムの背後にある技術的アイデアである。-複雑性(complexity)--ソフトウェアは大きくて複雑なことそれ自身が問題である。--ソフトウェアの構成要素間の依存関係も規模が大きくなるほど非線形に増大する。-同調性(conformity)--ソフトウェアはソフトウェア単独で存在しているわけではなく、ハードウェアやネットワーク、他のシステム、人間の行動や習慣に至る様々なものと関係を持ち続けるものである。--ソフトウェアの宿命はこういった外部につねに同調(順応)し続けなければならないところにある。-可変性(changeability)--ソフトウェアは常に変化し続けなければならないということである。---例え、当初の計画通りシステムができあがったとしても、それを使っているユーザーはさらなる要求を思いつくだろうし、そもそもできあがったシステムが世界を変えてしまうため、人間の認識に影響を及ぼし、新たな要求が出てくる。--最近のビジネス環境の変化は激しく、技術進歩も速いため、ソフトウェアもこれにつねに対応していくことが要求されている。-不可視性(invisiblity)--ソフトウェアが複雑な概念の集積であることに起因して、それが目に見えないというkとである。---開発プロセスや意思決定の経緯も見ることができず、単純な図面で全体が理解できることもない。[#vb249152]-ソフトウェアが概念構造体であるということは、数学の世界にも似ている。--数学者が新しい空間を頭の中で描くのと同じような自由度がある。[#d896ce86]|ソフトウェアの世界|数学の世界||h|計算機|数学機械|計算機の動作のあらゆる局面は、数学的な厳密さで定義することができる。その詳細は純粋な論理法則と数学的な確実さで、定義から演繹することができる。||プログラム|数学的表現|プログラムは厳密かつすべての細部にわたる詳細さで計算機の動作を記述する。||プログラミング|数学的活動|プログラミングを行うためには、数学的な理解・計算・証明などの方法を適用することが要求される。[#u974ebfe]-影響範囲の調査を効率よく行うためには、[[リポジトリ]]などのツールを使用する。0161)の「ソフトウェア保守」に次の4つのタイプが規定されている。-訂正--是正保守---ソフトウェア製品の引渡し後に発見された問題を訂正するために行う受身の修正。--予防保守---引渡し後のソフトウェア製品の潜在的な障害が顕在化する前に発見し、是正を行うための修正。-改良--適応保守---引渡し後、変化したまたは変化している環境において、ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の修正。--安全化保守---引渡し後のソフトウェア製品の性能または保守性を改善するための修正。例:OSのバージョンアップに伴い、アプリケーションソフトウェアの修正が必要になった。[#e67bd89d]-SLCPでは、システムおよびソフトウェア製品の移行および廃棄も含まれるとしている。--つまり、情報システムを使い続けることそのものが保守プロセスとされている。-保守レビューの目的として、保守者は修正を承認する権限を持つ組織と共同でレビューを行い、修正されたシステムの完全性を確認する。-そのため、同じ手間(生産性)なら障害件数順の[[パレート図]]などを用いて作業優先度を把握するのが得策といえる。「人月の神話」を超えて』-『これだけでわかる!初歩のUMLモデリング。