ソフトウェアエンジニアリングを今一度考える · •...

All rights reserved, Copyright © IPA 2015

ソフトウェアエンジニアリングを今一度考える

1

ソフトウェアグループ・研究員鈴木基史

独立行政法人情報処理推進機構連携委員新谷勝利、新谷ITコンサルティング

2015年11月19日


１９６８年NATO会議−１/3

• 1967年秋：

NATO科学委員会はコンピューター科学

に関する作業部会を発足。

→ソフトウェアの設計、生産及びサービス

の観点を議論。

• 造語：「ソフトウェアエンジニアリング」

ソフトウェア開発にあたり、他のエンジニア

リング分野と同様学問的基礎に立脚する

と共に実践的な規律に基づくことが必要。2


１９６８年NATO会議−2/3

• 危機と言えない分野があるかもしれないが、特に大規模システムにおいては、危惧がある。

• 大規模システムにおいては、ソフトウェアの不具合の発生をなくすことはできない。

• 他のエンジニアリング分野と比べ、ソフトウェアエンジニアリングはまだその初期段階。

• プログラミングのコスト、スケジュール管理は、依然として低い評判のままである。

3


１９６８年NATO会議−3/3

• ソフトウェア開発の工程管理の難しさは、進捗をどう測定するのがよいのかわかっていないことにある。

• ソフトウェア不具合は指数関数的に増加している。

• ソフトウェア開発への要望は現場の能力を超えてなされている。

=>これらは未だに未解決では？4


SWEBOK V.3

• 第１章ソフトウェア要求

• 第２章ソフトウェア設計

• 第３章ソフトウェア構築

• 第４章ソフトウェアテスティング

• 第５章ソフトウェア保守

• 第６章ソフトウェア構成管理

• 第７章ソフトウェアエンジニアリング・マネージメント

• 第８章ソフトウェアエンジニアリングプロセス

• 第９章ソフトウェアエンジニアリングモデルおよび方法

• 第１０章ソフトウェア品質

• 第１１章ソフトウェアエンジニアリング専門技術者実践規律

• 第１２章ソフトウェアエンジニアリング経済学

• 第１３章計算基礎

• 第１４章数学基礎

• 第１５章エンジニアリング基礎

5


信州大学情報工学科ソフトウェア工学

【授業のねらい】

・ソフトウェアの快活に関わる要素技術を習得することにより、工学的にソフトウェアを開発できるようになること

・ソフトウェア開発で使われる各種ツールを理解し、使えるようになること

・ソフトウェア開発の各工程を、演習を通じて理解する。１１回の課題提出と、３回の小テストを行う。

6


信州大学情報工学科ソフトウェア工学

授業は、１コマ2時間×１週2コマを15回、合計60時間

• 大規模ソフトウェア開発の課題

• ソフトウェアの開発工程

• プロジェクト管理

• 要求分析

• 構造化分析

• オブジェクト指向分析

• アーキテクチュア設計

• ユーザインターフェイス設計

• モジュール設計

• プログラミング1(記述方法)

• プログラミング2(プロダクト管理)

• テストと検証

• 形式手法1(基本概念)

• 形式手法2(ツール)

• 保守と再利用 7


京都大学工学部ソフトウェア工学

ソフトウェア工学とは、高品質な情報システムを開発するための理論・技術・手法・規律など様々な学問分野の総称である。ソフトウェア工学が対象とする情報システムとは、組織、社会、あるいは個人における様々な活動に関連する情報を取り扱うシステムでありこれを正しく低コストで迅速に開発することは社会要請となっている。本講義では、情報システム開発に関わる様々な側面について解説する。

8


京都大学工学部ソフトウェア工学

• ソフトウェア工学概説

• ソフトウェアのディペンダビリティ

• ソフトウェアプロセス

• ソフトウェア要求工学（２回）

• ソフトウェア設計技術（２回）


• 確認と検証１ー形式手法（２回）

• 確認と検証２ーテスト

• 分散システムとクラウド

• ソフトウェアの再利用と品質管理（２回）

• 学習到達度の確認

9


九州大学工学部ソフトウェア工学特論

ソフトウェア工学の分野において、ソフトウェアの開発プロセス、ソフトウェアの品質特性、フォーマルメソッドに基づくソフトウェア開発、ソフトウェアのテストなどの主要な話題について講義する。

10


九州大学工学部ソフトウェア工学特論

授業は次の項目で構成する．コマ数は目安であり，授業の進み具合によって適宜調整．

1 ソフトウェア工学とは（1コマ）

ソフトウェア工学という分野が発生した背景を説明し、ソフトウェアおよびソフトウェア

開発の特質について論じる。

2 ソフトウェア開発プロセス（２コマ）

ソフトウェア開発の代表的なプロセスモデルを紹介し、それぞれの特徴を述べる。

3 ソフトウェア品質特性（１コマ）

ソフトウェアの品質特性について概説する。

4 フォーマルメッソッド概説（3コマ）

フォーマルメソッドの概要を述べて、形式仕様記述の具体例を示す。

5 フォーマルメッソッドに基づくソフトウェア開発（2コマ）

フォーマルメソッドに基づくソフトウェア開発法について説明し、実際の開発事例の紹介

を行う。

6 ソフトウェアのテスト（5コマ）

ソフトウェアの信頼性を保証する方法の一つとしてのテスト技法を紹介する。 11


放送大学大学院ソフトウェア工学

今や情報システムは、電気・ガス・水道から交通システム、通信システム、あるいは経済関係の活動まで、ありとあらゆるものを支えるものとなっているが、その本質は、情報処理機械、すなわちコンピュータの中で稼動しているソフトウェアが担っている。ここでソフトウェアは一種の抽象概念であり、目に見えるものではないために、その存在は、その作成や運用に携わっている人々以外にはほとんど意識されることがない。ましてやその複雑さや構築の困難さに思いが及ぶこともないのが実情である。本科目では、このように特殊な存在であるソフトウェアをどのように作ればよいかという問題と対峙している「ソフトウェア工学」について学ぶ。

まず最初にソフトウェアの作成が「工学」を必要とする程に難しいタスクであることを学んだ後、ソフトウェア工学の概要をその発展の様子を含めて理解する。

情報学プログラムの学生を主なターゲットとするが、ソフトウェアやソフトウェア工学に関心を寄せる他コース・プログラムの学生も興味をもって理解できるように、先端的な内容も含めて平易に解説する。

12


放送大学大学院ソフトウェア工学項目

• ソフトウェアとは

• ソフトウェアの不具合がもたらす社会的影響

• ソフトウェア工学の意義と方法

• ソフトウェアプロセス

• 要求分析

• モデル化技法とUML

• 制御とデータのモデル

• 動的振る舞いのモデル

• オブジェクト指向開発

• 形式手法

• 設計技法

• 検証技術

• 開発環境とツール

• 保守と発展


13


ソフトウェア工学の企業内研修

仮に、大学あるいは大学院でソフトウェア工学を勉強していない人が、企業において集中学習をして、60時間は、6時間/日X5日/週X2週

就業時間内あるいは残業時間で毎日2時間勉強するとして、6週間

SWEBOKからピックアップしたとして、どの程度実施が可能？あるいは実施しているか？

14


ソフトウェア工学の企業内研修

• ソフトウェア工学の全分野を学習することはできず、実践的に効果のある部分を学ぶことになる。

→何か？

→開発ライフサイクルでの問題点への着目

→開発ライフサイクルを通したデータは案外

取られていない。

15


NISTモデルによるソフトウェア開発ライフサイクルコストの段階別推計

16


NISTモデルによるソフトウェア開発ライフサイクルコストの段階別推計

• Vカーブの左側で20%しかディフェクトを除去出来ていないというのは妥当？(2000年初め）

→そもそもどのタイミングでデフェクトと認識？

→Verificationとvalidation

Verification: 仕様と設計、設計とコード

Validation: 実行して仕様と妥当性を見る

→左側：UT以外ではレビューは行われる

が、実行されない

→右側：結合テストで実行に入り気づく？17


SEC「ソフトウェア産業の実態把握に関する調査」-QCD未達成の原因（左：ベンダー、右：ユーザ）

18

0% 10% 20% 30% 40% 50% 60% 70%

要求定義工程以前における問題

システム/ソフトウェア設計工程における問題

プロジェクト計画を遂行中のプロジェクト管理の失敗

元々のプロジェクト計画（見積り、目標QCD設定等）に無理

があった

ソフトウェア実装・デバッグ工程における問題

ソフトウェアテスト/システムテスト工程における問題

ハードウェア・他システムなど外部接続システム・装置の遅

れ等の問題

その他

1番目 2番目 3番目

0% 10% 20% 30% 40% 50% 60% 70% 80%

業務・システム要求定義工程における問題

システム化計画工程における問題

ソフトウェア設計～テスト工程における開発委託先の問題

システム設計工程における問題

運用テスト工程における問題

その他

1番目 2番目 3番目


ソフトウェア工学の出番

• Vモデル左側で検証できる仕組み

→形式手法による仕様の実行

→変化する要求に対応出来る仕様記述

• Vモデル右側を効率化する仕組み

→仕様からテストケースを早期に作成し、W

モデルを志向

• 等々、ソフトウェア工学が提唱している方法論を導入

19


ご清聴ありがとうございます。

ご質問があれば、以下にどうぞ。

新谷勝利、IPA/SEC連携委員

[email protected]

2015/11/18 20


「ｉパス」は、ITを利活用するすべての社会人・学生が備えておくべきITに関する基礎的な知識が証明できる国家試験です。

ITパスポート公式キャラクター上峰亜衣（うえみねあい）

【プロフィール：マンガ】 https://www3.jitec.ipa.go.jp/JitesCbt/html/uemine/profile.html


Windows Server 2003のサポートが2015年7月15日に終了しました。

サポート終了後は修正プログラムが提供されなくなり、脆弱性を悪用した攻撃が成功する可能性が高まります。

周辺ソフトウェアもサポートが順次終了していくため、あわせて対策が必要です。

サポートが継続しているOSへの移行検討とOS移行に伴う周辺ソフトウェアの影響調査や改修等について迅速な対応をお願いします。

会社の事業に悪影響を及ぼす被害を受ける可能性があります

IPA win2003 検索詳しくは

なおWindowsXPを利用されている方はサポートが継続しているOSへの移行検討をお願いします

脆弱性が未解決なサーバ

脆弱性を悪用した攻撃

ホームページの改ざん

重要な情報の漏えい

他のシステムへの攻撃に悪用

業務システム・サービスの停止・破壊

データ消去

Windows Server 2003のサポート終了に伴う注意喚起


Check！Catch！

Search！

Click！

ソフトウェアエンジニアリング を今一度考える · •...

Documents

ソフトウェアエンジニアリングを今一度考える · •...