1
Download 第1回：ソフトウェア工学とは？ ソフトウェア工学の起源 ソフトウェア工学と
Transcript
コンピュータ・ネットワーク工学科 ３年次必修科目 ソフトウェア工学 第１回：ソフトウェア工学とは？ 本位田 真一 深澤良彰 鷲崎 弘宜 失敗したプロジェクトの共通的な特徴 • • • • • • • エンドユーザのニーズを正確に理解していない ソフトウェアへの変更要求に対応できない モジュール間の整合性がない ソフトウェアの保守や拡張が困難 プロジェクトの重大な欠陥を発見するのが遅れた ソフトウェアの品質が悪い 誰が、何を、いつ、どこで、どのように変更したの かがわからない… ソフトウェア工学の起源 1968年 NATO Science Committee の国際会議 「ソフトウェア工学」という用語が始めて使用 ソフトウェアの危機 （１９６０年代末～） ソフトウェア需要の増大 ↓ ソフトウェア技術者の不足 ↓ プログラムの質の低下、ソフトウェア技術者の高賃金化 ソフトウェア開発の問題の 根本原因 • 要求管理が場当たり的 • コミュニケーションが曖 昧で不正確 • アーキテクチャが脆弱 • 著しく複雑 • 要求／設計／実装間の 矛盾を発見できない • テストが不十分 • プロジェクトの評価が 主観的 • リスクの処理に失敗 • 変更の伝播を制御で きない • 自動化が不十分 Caper Jones “Patterns of software systems failure and success”, Int. Thompson Computer Press (1996) ソフトウェア工学とは？ • The systematic approach to the development, operation, maintenance, retirement of software. ( IEEE Standard Glossary ) • The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works effectively on real machine. ( F.Bauer 1969 ) ソフトウェア工学とは？（続き） • Software engineering involves the practical application of scientific knowledge to the design and construction of computer programs and the associated documentation required to develop, operate, and maintain them. ( B.W. Boehm 1976 ) • Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed end modified on time and within cost estimates . ( R.E. Fairley 1985 ) . . . 1 ソフトウェア≠プログラム ソフトウェア工学とは？（ここでの定義） • 良い ソフトウェアを、 簡単に作成するための ソフトウェア工学の対象 • • • • 大規模なソフトウェア 多人数で開発するソフトウェア 開発者と利用者が異なるソフトウェア 使い捨てでないソフトウェア 方法論、ツールを開発する 学問（工学） ソフトウェア工学の特質 • 個人で解決できないような大規模ソフト ウェアの構築に工学的な方針を採用 • 技術的な側面と非技術的な側面 • 会話や記述による情報交換 – 理解していない分野のソフトウェアをも作成 • プロジェクト管理の問題も扱う • 単にプログラムの作成だけを意味するの ではなく、すべての文書の作成を意味する ｢良い」ソフトウェアの考え方 • ｢良い」ソフトウェアが満たすべき性質は何か？ ⇒ 品質特性 • 特定のソフトウェアでどのような特性を重視する か？ ⇒ （品質モデル） • 何により品質特性を計測するか？ ⇒ メトリクス • どのようにして品質要求を作り込むか？ ⇒ 品質保証 ⇒ 品質管理 ソフトウェア品質特性 （ISO／IEC 9126） 1. 機能性 ¾ 機能の集合の存在及びそれらの明示された性質の存在 をもたらす属性の集合。機能は、明示的又は暗示的な 必要性を満たすものとする。 2. 信頼性 ¾ 明示された条件の下で、明示された期間、ソフトウェア の達成のレベルを維持するソフトウェアの能力をもたら す属性の集合 4. 効率性 ¾ 明示的な条件の下で、ソフトウェアの達成レベルと使用 する資源の量との間の関係に影響する属性の集合。 5. 保守性 ¾ 仕様化された改訂を行うために必要な労力に影響する 属性の集合。 6. 移植性 ¾ ソフトウェアをある環境から他の環境へ移す際のそのソ フトウェアの能力をもたらす属性の集合。 3. 使用性 ¾ 明示的又は暗示的な利用者の集合が、使用するために 必要とする労力及び個々の使用結果による評価に影響 する属性の集合。 2 機能性（Functionality） 信頼性（Reliability） 1. 合目的性（Suitability） ¾ 明示された仕事に対する機能の集合が存在し、適切であることをも たらすソフトウェアの属性 2. 正確性（Accuracy） ¾ 正しい結果若しくは正しい効果、又は同意できる結果若しくは同意 できる効果をもたらすソフトウェアの属性 3. 相互運用性（Interoperability） ¾ 明示されたシステムと相互作用できる能力をもたらすソフトウェアの 属性 4. 標準適合性（Compliance） ¾ 5. 1. 成熟性（Maturity） ¾ ソフトウェアに潜在する障害による故障の頻度に影響するソフト ウェアの属性 2. 障害許容性（Fault tolerance） ¾ ソフトウェアの障害部分を実行した場合、又は仕様化されたイン タフェース条件に違反が発生した場合に、仕様化された達成の レベルを維持する能力をもたらすソフトウェアの属性 3. 回復性（Recoverability） ¾ ソフトウェアを応用分野に関係する規格若しくは用法、又は応用分 野に関する法律及び類似の法規における規則を遵守したものとす るソフトウェアの属性 障害時に、ソフトウェアの達成レベルを再確立したり、直接に影 響を受けたデータを回復したりする能力をもたらすソフトウェアの 属性、並びにそれらに必要な時間及び労力に影響するソフトウェ アの属性 セキュリティ（Security） ¾ プログラム及びデータに対し、偶発的か又は故意にかかわらず、不 当なアクセスを排除する能力をもたらすソフトウェアの属性 使用性（Usability） 効率性（Efficiency） 1. 理解性（Understandability） ¾ ソフトウェアの論理的な概念及びそれがどう適用できるかを理解 するための利用者の労力に影響するソフトウェア属性 1. 時間効率性（Time behavior） ¾ 2. 習得性（Learnability） ¾ ソフトウェアの適用（例えば、運用管理、入力、出力）を習得する ための利用者の労力に影響するソフトウェアの属性 2. 資源効率性（Resource behavior） ¾ 3. 運用性（Operability） ¾ 1. 解析性（Analysability） 欠陥若しくは故障の原因の診断又は改訂すべき部分の識別に 必要な労力に影響するソフトウェアの属性 2. 変更性（Changeability） ¾ 改訂、障害の除去又は環境の変化への対応に必要な労力に影 響するソフトウェアの属性 3. 安定性（Stability） ¾ ソフトウェアの機能を実行する際の、使用した資源の量及びその使 用時間をもたらすソフトウェアの属性 ソフトウェアの運用と運用管理を行うための利用者の労力に影 響するソフトウェアの属性 保守性（Maintainability） ¾ ソフトウェアの機能を実行する際の、応答時間、処理時間及び処理 能力をもたらすソフトウェアの属性 改訂によって予期せぬ影響を与える危険性をもたらすソフトウェ アの属性 4. 試験性（Testability） ¾ 改訂したソフトウェアの妥当性の確認に必要な労力に影響する ソフトウェアの属性 移植性（Portability） 1. 環境適応性（Adaptability） ¾ 対象ソフトウェアにあらかじめ用意された以外の付加的な作業 又は手段なしに、特定の異なる環境にソフトウェアを適用する可 能性をもたらすソフトウェアの属性 2. 設置性（Installability） ¾ 特定の環境に設置するために必要な労力に影響するソフトウェ アの属性 3. 規格適合性（Conformance） ¾ ソフトウェアを移植性に関係する規格又は規約を遵守したものと するソフトウェアの属性 4. 置換性（Replaceability） ¾ 特定の環境で動作する他のソフトウェアの代わりに、対象ソフト ウェアで置き換えて使用する可能性及びそのための労力に影響 するソフトウェアの属性 3 メトリクスの例 • 機能性 相互運用性 標準適合性 • 使用性 理解性 • 使用性 習得性 • 効率性 資源効率性 内部変数の数／使用変数の数 引数の数／ELOC コーディング規則有無 取扱説明書記述規則有無 内部仕様書記述規則有無 内部仕様書ページ数／ELOC ELOC／SLOC コメント数／ELOC ELOC／モジュール数 最大ネスト数 サイクロマティック数／ELOC 取扱説明書のページ数／ELOC 使用例題出題数／ELOC 使用変数の数／ELOC 見積りの背景 •他分野の見積りモデル –履歴が沢山ある –広範囲に利用 –詳細な計画立案データを生成する –入力として規模見積り値を要求する なぜ規模を見積もるのか? •より優れた計画を作成するために –ジョブの規模をより良く測る –そのためにジョブを分離可能な要素に分ける •進捗の追跡を助けるため –開発中も適宜見積もることでジョブ範囲の変 化を判断できる –これにより作業をより良く測定できる Ｍｙｓｔｉｃａｌ Ｍａｎ－Ｍｏｎｔｈ 規模見積りの原理 •見積りとは不確実なプロセスである •製品規模がどの位になるか誰も分からない •見積り時期が早ければ早いほど、知りうる情報はより少ない •ビジネスや他の圧力によって偏ることがある •見積りとは直感的な学習プロセスである •経験を積むにつれて能力が改善する •定義された見積り方法を使うことの主な長所 •ソフトウェア規模見積りの経験 –100%以上の誤差は普通 –見積りをする開発者はほとんどいない –秩序正しい方法を使う開発者はなおさら少ない 見積りの方法の例 •ファジー論理法 •ファンクションポイント法 •デルファイ法 •勝手を知ったプラクティスをもつことで改善が可能に •データ収集のための枠組みを提供 •一貫した方法と履歴データを使うことによって、見積りはより 首尾一貫したものに ファジー論理法 1. 製品規模の履歴データを規模の範囲に分 割 z 範囲は，非常に大きい、大きい、中くらい、小さい、 非常に小さいの５つ z 各範囲に規模範囲を設定する z 範囲は，既存および期待される製品の全てを含むよう に 2. 開発予定の製品を以前の製品と比較 3. この比較に基づいて、「新規製品に最も適 切である」と思われる規模を選択 4 ファジー論理法の長所と短所 ファンクションポイント法（1） •長所 •関連する履歴データに基づいている •ファンクションポイントとは恣意的な単位 •使いやすい –アプリケーションの機能に基づく •特別なツールや訓練を必要としない •入力、出力、ファイル、照会 •新規作業が以前経験したことに似ているところではかなり良 い見積り値が得られる –単純、平均、複雑という複雑さで調整する •ジョブの複雑さに対して: •短所 –さらに +/- 35% 調整する •数多くのデータを必要とする •大ざっぱな規模の値を提供するにすぎない •プログラムが新しいタイプの場合には役に立たない •履歴データよりもはるかに規模が大きかったり、小さかったり するプログラムには役に立たない ファンクションポイント法（２） IFPUG (International Function Point Users Group) URL http://www.ifpug.org ファンクションポイント法の長所と短所 •長所 –最も初期の要求フェーズで使える •手順 –アプリケーション中の機能のタイプ毎に数を決定す る –各機能の規模と複雑さを判断する –ファンクションポイントの合計を計算する –プログラミング言語、製品設計、開発形態によらない –数多くの履歴データがある –文書がよく整備されている •短所 –ファンクションポイント当たりの開発コストについて の履歴データを見積りに使う –既存製品に対してファンクションポイントの各項目を直 接カウントできない –ファンクションポイントに比率を掛けて見積り値を出 す –履歴データがないと、見積りのスキルを改善する の が難しい –プログラミング言語、製品 設計、開発形態の違いを 反映しない デルファイ法の例 - 1 デルファイ法 •数人の見積り者を使う –各人は独自に見積りを行う –各人は調整者に見積り結果を提出する •調整者 •3 人の見積り者が製品の見積りを依頼されて いる •最初の見積り値は次の通りである – A - 13,800 LOC – B - 15,700 LOC – C - 21,000 LOC –見積り値の平均を計算 –次の項目を帳票に記入 •平均値、他の人の見積り値（匿名）、以前の見積り値 •再見積り値が安定したとき –平均値が見積り値である –範囲は最初の見積り値の範囲である • •調整者は以下を行う –見積り値の平均を計算し、16,833 LOCとなる –この結果を最初の見積り値とともに、見積り者へ返 す 5 デルファイ法の例 - 2 デルファイ法の長所と短所 •次に見積り者は集まって、見積り値について 議論 •長所 –非常に正確な結果が得られる –組織のスキルを利用する –どんな規模の製品にも適用できる •2 回目の見積り値は次の通りである – A - 18,500 LOC – B - 19,500 LOC – C - 20,000 LOC •短所 • •調整者は以下を行う –見積り値の平均を計算し、 19,333 LOCとなる –この見積り値に同意するか、見積り者に尋ねる 情報システム開発のモデルの例 • ウォータフォールモデル（Waterfall Model） • プロトタイプモデル（Prototype Ｍｏｄｅｌ） • スパイラルモデル（Spiral Model） ウォータフォールモデル 要求仕様書 要求分析・定義 設計書 設計 実現 プログラム テスト –少数のエキスパートに依存している –多くの時間を必要とする –共通の偏りが入りやすい ウォータフォールモデル • 分析（基本計画）、設計（内部・外部）、実装 （プログラミング）、テスト、運用・保守の順 番でシステム（ソフトウェア）を開発 • 水の流れ落ちるような形で、システム（ソフ トウェア）が開発 • 順番を守らなければいけない制限がある • トップダウン開発方式、段階的詳細化技法 ウォータフォールモデルの利点 • すべての工程が順次に進められる • 全体の見通しがつきやすい • スケジュールの決定や資源配分が計画と おり行われる • 工程が理解しやすい • 大規模のシステム開発に向いている 運用・保守 6 ウォータフォールモデルの欠点 • 開発工程の初期の段階で要求仕様を確定 することは現実的に難しい – 開発の初期段階では、開発要求仕様書の不 明確な部分の定義が難しい • ユーザインタフェースの要求は、システム が完成した時点でなければ確立できない – 問題があったときには前に戻らなければいけ ないのだが、それを許さない プロトタイプモデルの手順 • • • • • • • 要求分析 プロトタイプ作成 プロトタイプの評価 設計 プログラミング テスト 運用・保守 プロトタイプモデル • 開発の速い段階で、システムの試作品（プロトタ イプ）を作成し、ユーザに使ってもらうことにより、 ユーザの要求を明確にするモデル • 開発はフィードバックを根底に置くモデル • プロトタイプモデルに基づいた開発技法を、「プロ トタイピング｣と呼ぶ • 比較的小規模のシステム開発に向く プロトタイプモデルの利点と欠点 • 利点 プロトタイピング 要求の追加・修正 – 開発工程の早い段階で、ユーザの要求を把 握することが可能 – 開発期間の短縮や、開発コストを低減するこ とが可能 – ユーザが開発に参加でき、積極的な協力を得 ることが可能 • 欠点 – 開発スケジュールの調整が困難。 スパイラルモデル プロセスとは? • ウォータフォールモデルとプロトタイピングの 利点を抽出したモデル • • • • • 要求定義 要求分析 設計 評価・計画 実装・テスト 保守 誰によって(who)(workers) 何が (what)(artifact) どのように (how)(activity) いつ (when)(workflow) なぜ (why) なされるのか 活動の集まり B.W. Boehm: A Spiral Model of Software Development and Enhancement. IEEE Computer, May 1988 7 プロセスの定義 • 作業や思考は常に構造的な方法を必要 – プロセスのような明示的なガイド – 考え方のような暗黙的なガイド • プロセスの視点 – プロセスの適用問題領域 – プロセスの使用者の理解：ツール≠プロセス – プロセスのステップ – プロセスの評価 8
