1995年の小型計算機上での開発プロセスの改善法 199年のレガシーな組込みソフトウェアの改良法 を2000年にまとめたものです。

1. 博士論文公聴会
導入/運用工数の制約を考慮した
ソフトウェア開発支援
ソフトウェア計画構成学講座
阪井 誠
NAIST-IS-DT9861008
1

2. 従来のソフトウェア開発支援
• ソフトウェアを効率よく開発する目的で開
発支援は行われてきた．
– 品質や開発プロセスの管理をする．
• 専任の部門や担当者を置く．
– 保守性の悪くなったソフトウェアを改良する．
• ナレッジベースなどを用いた大規模なリエンジニア
リングが行われる．
⇒多くの導入/運用工数が必要である．
2

3. 導入/運用工数の制約
• 導入/運用工数の制約が大きい場合，従来の開発
支援法は適用が困難である．
– 組織や開発の規模が比較的小さい小型計算機上での
開発プロセスの改善．
– 競争が厳しいので再利用が繰り返された，組込みソフ
トウェアの改良．
目的：導入/運用工数の制約を考慮した2つの
ソフトウェア開発支援法を提案する．
3

4. 発表のあらまし
– 背景(論文1章および2章)
– 小型計算機上での開発プロセスの改善法
(論文第3章)
– レガシーな組込みソフトウェアの改良法
(論文第4章)
– まとめと今後の課題(論文第5章)
4

5. 小型計算機上での開発プロセスの
改善法(論文第3章)
•背景と目的
•小型計算機上でのソフトウェア開発
•基本的なアイデア
•提案するプロセス改善法
•適用実験
•まとめ
5

6. 背景 -小型計算機上でのソフトウェア開発-
– 処理速度や使いやすさの向上により，パーソ
ナルコンピュータをはじめとする小型計算機
上でのソフトウェア開発が増加している．
– 標準規格に準拠した安価で豊富な製品を組み
合わせて構成されている．
– 開発環境が整備されているので,システムの規
模は比較的小さく，開発支援への導入/運用工
数の制約は大きい．
6

7. 背景-小型計算機上でのソフトウェア開発の問題-
• 小型計算機上でのソフトウェア開発では，開発・実行環境，
要求の実現方法，開発の対象となるドメインの選択肢が増
えた．
環境 実現方法 ドメイン
Hardware SUN GUI クリッカブルマップ 業種 電力
HP メニュー 建設
PC互換機 ラジオボタン 鉄鋼
Macintosh スクロール 機械
OS Solaris 分散処理 2階層 電機
Linux 3階層 販売
Windows 機能分散 業務 受付
Mac-OS 不可分散 経理
Middleware Oracle ファイル共有 総務
HORB 開発
• 増加した全ての選択肢を予め熟知することは困難であり，
開発中に問題の生じる危険性(リスク)が高くなった．
7

8. 背景 -開発中に生じる問題の例-
• OS-A 上の表計算ツール-X用のデータベースアクセスツール-Yから，
OS-B上のDBMS-Zにあるコマンドを送った時のみ処理速度が低下する．
OS-A OS-B
処理速度
表計算ツール-X 低下
DBMS-Z
ツール－Y
• このような特定の組合せのみで生じる問題は，開発前の調査ではわ
からないので，開発中に明らかになることが多い．
8

9. 背景 -ソフトウェアプロセスモデル-
• ソフトウェア開発は作業の複雑な集合であり，秩序だった開発のためには，
必要な作業とその順序を“ソフトウェアプロセスモデル”として予め定義する
必要がある*．
計画 実行
ソフトウェア
開発計画
プロセスモデル
プロジェクトチーム
管理者
ソフトウェア規模，開発期限，
開発者の配員が考慮される
• ソフトウェアプロセスモデルを基にソフトウェアの規模，開発期限，開発者の
配員が考慮され開発計画が立てられ，開発される．
*Watts S. Humphrey:”Managing the Software Process, ”Addison-Wesley Publishing (1989).
9

10. 背景 -従来のプロセスの改善法-
• プロセスの管理に必要な，主に品質に関する定量的なソフトウェ
アデータがプロセスグループにより収集され，実績に基づきソフ
トウェプロセスモデルは変更される．
新しい計画になれること
で生産性を向上させる
計画 実行
ソフトウェア
開発計画
プロセスモデル
プロジェクトチーム
管理者
コードレビュー比率 収集
変更
を20%に増やす
プロセスグループ ソフトウェア
データ
コードレビュー比率20%
の生産性が高い
10

11. 背景 -従来のプロセスの改善法の問題点-
計画的な活動を支援する
計画 実行
ソフトウェア
開発計画
プロセスモデル
プロジェクトチーム
管理者
導入/運用工数 収集
変更
が多い
プロセスグループ ソフトウェア
データ
具体的な解決法ではない
– 秩序正しい計画的な活動を支援するので，小型計算機上のソフ
トウェア開発で生じる，予想外の問題の解決を支援していない．
– 具体的な解決法などの定量的でないソフトウェアデータに基づい
たプロセス改善を考慮していない．
– プロセス改善にはプロセスグループが必要なので，多くの導入/
運用工数が必要である．
11

12. 本研究の目的
小型計算機上でのソフトウェア開発中に生じた問題の経
験を組織内で共有し，問題の解決を容易にする．
– 小型計算機上のソフトウェア開発で生じる，予想外の
問題の解決を支援する．
– 具体的な解決法に基づいたプロセス改善を考慮する．
– 多くの導入/運用工数を必要としない．
小型計算機上でのソフトウェア開発におけるプロセス
改善法を提案する
12

13. 基本的なアイデア
(2)問題の解決法が創 (1)ソフトウェア開発中に経
造され，再計画される． 験のない問題が発生する．
計画 実行
ソフトウェア
開発計画
プロセスモデル 再計画
プロジェクトチーム
管理者
報告
(通常業務)
(3)問題の対処
作業報告書
が報告される．
通常の週次の業務として作業報告書が作成されるので，作業
報告書から具体的な問題の解決法が抽出し，プロセス改善に
用いることができれば，導入/運用工数を少なくできる．
13

14. 作業報告書
プロジェクト管理者により
毎週作成される．
– 週間予定/実績
– 問題
– 対処
– スケジュール表
– その他
14

15. 提案するプロセス改善法-手順-
作業報告書に記述された問題の解決法に基づき
プロセスを改善する．
計画 実行
ソフトウェア
開発計画
プロセスモデル 再計画
プロジェクトチーム
報告 管理者
問題の解決法が (通常業務)
抽出され，蓄積 作業報告書
される．
抽出/蓄積
提示
変更
解決法データベース
頻繁に発生し，発生時期が特定可能
な問題に対しては，解決法を用いてプ 類似した問題の解決法が提示され，
ロセスモデルを変更する． 経験のない問題の解決が支援される．
15

16. ソフトウェアプロセスモデル
作業とその順序を示すUPM*(Unconstrained Process Model)にアクションダイ
アグラム+の表記法と作業の定義が拡張され用いられる．
*Watts S. Humphrey and Marc Kellner: “Software process modeling: Principles of entity process models,” Proc. of the
11th ICSE, pp. 331-342 (1989).
+James Martin:“Recommended Diagramming Standards for Analysts and Programmers,”Prentice-Hall (1987).
16

17. 解決法の形式
• 解決法は以下の属性に形式化されて蓄積される．
属性 内容
問題 再計画の原因となった問題
キーワード 問題のキーワード
作業 問題の生じた作業
リスクタイプ 問題の要因(環境/実現方法/ドメイン/その他)
方法 問題の解決法
プロセス 拡張されたUPMで記述されている解決法の作業
タイプ 解決法のタイプ(追加/置き換え/モニター)
17

18. 適用実験1 －目的－
目的： 作業報告書に解決法が記述されているか，ソフトウェア
プロセスモデルを変更し，解決法を組込み可能かを確認する．
計画 実行
ソフトウェア
開発計画
プロセスモデル 再計画
プロジェクトチーム
報告 管理者
(通常業務) 解決法が記述
作業報告書 されるか？
抽出
提示
変更
解決法データベース
頻繁に発生し，発生時期が特定可能な問題に対
して，解決法をプロセスモデルに組み込めるか？ 18

19. 適用実験1 －対象と方法－
対象：（開発者１名＋管理者１名）×６ヶ月の
アプリケーション開発のプロジェクト
方法：
1. プロジェクト管理者に開発中に生じた問
題と解決法をインタビューする.
2. 問題と解決法が作業報告書に書かれてい
るかをチェックする.
3. ソフトウェアプロセスモデルを変更する.
19

20. 適用実験1 －収集された解決法－
No. 問 題 作 業 リスクタイプ 解決の方法 タイプ 報告
画面イメージによるプロトタイ
1 仕様書の理解が困難である 要求定義 実現方法 追加 ×
ピングを行う
2ページディスプレイが不足して 仮想画面ツールをインストール
2 要求定義 環境 追加 ○
いる する
ユーザーズマニュアルが使いに
3 要求定義 ドメイン 動画説明書を作成する 追加 ○
くい
部分レビューで問題の多い部分
4 仕様書の品質が予測できない レビュー ドメイン 置き換え ○
に時間を加重配分する
設計/コーディ
5 デモバージョンが必要である ング/テスト 実現方法 工程を２分割する モニター ○
データチェックツールを作成す
6 ユーザのデータ入力誤りがある 検収テスト ドメイン 追加 ○
る
• 収集された６つの解決法のうち，５つが作業報告書に記述されていた．
• No.1の解決法は，工数や進捗に影響がなかったこと，比較的一般的な
解決方法であるため記述されなかった．
• No.4とNo.6の解決法が，ソフトウェアプロセスモデルに組み込まれた．
20

21. 変更されたソフトウェアプロセスモデル
21

22. 適用実験2
目的：解決法データベースの開発/導入
工数と，解決法の抽出に必要な運
用工数を評価する．
対象：抽出対象は約3年間の小型計算機
を用いたプロジェクトである．
方法：右図の解決法データベースを
Lotus APPROACHを用いて開発し,
実際のプロジェクトで作成された
作業報告書の記述から,解決法を抽
出/蓄積する.
22

23. 適用実験2 －結果－
計画 実行
ソフトウェア
開発計画
プロセスモデル 再計画
プロジェクトチーム
報告 管理者 3年間の作業報告書か
(通常業務) ら39件の解決法を抽出
作業報告書 /蓄積した．
3人日で開発した．(DBMSの (抽出55分/登録1時間)
インストールは約1時間)
抽出/蓄積
提示
変更
解決法データベース
解決法データベースのコピーは数秒であり，データ
ベースのインストールと合わせて導入工数は約0.13
人日，運用工数は約0.1人日/年である．
23

24. 小型計算機上での開発プロセスの改善法まとめ
• 小型計算機上でのソフトウェア開発におけるプロセス改
善法を提案した．
項目 従来法 提案法
ソフトウェアプロセスモデル 厳守する 参考にする
開発中の再計画の支援 考慮されていない 支援する
解決法の蓄積 定められていない 蓄積する
収集する対象 主に品質データ 作業報告書上の解決法
管理者を中心とする
プロセスの改善担当 プロセスグループ
開発者
導入/運用工数 大きい 小さい
24

25. 小型計算機上での開発プロセスの改善法まとめ
• 適用実験の結果，経験した問題の解決が容易と考えられる新しいソ
フトウェアプロセスモデルが得られた．
• 作業報告書に記述されなかった解決法は，Humphrey が述べている
ように，データがどのように役立つかをプロジェクト管理者に教えるこ
とで，更に注意深く記述されると考えられる*．
• 解決法データベースはデータ構造が単純なので開発と導入の工数
が少なく，作業報告書を用いるので運用工数も少なかった.
• 今後は実プロジェクトでの解決法を集め，実際のプロジェクトで運用
する予定である．
*Watts S. Humphrey: “Managing the Software Process,”Addison-Wesley Publishing (1989).
25

26. レガシーな組込みソフトウェア
の改良法(論文第4章)
•背景
•提案する評価法
•改良支援ツール
•試行と導入の結果
•考察とまとめ
26

27. 遺産的(legacy)な組込みソフトウェア
再利用が繰り返された組込みソフトウェアは，多くの
仕様を満たしており，遺産のように価値は高いが，
保守が困難である．
– 機器(商品)に組み込まれているので高い信頼性が求められ
る．
– マーケティングの観点(ｼｽﾃﾑ移行時期，競合他社)から，開発
期間短縮の圧力や予算の制約が厳しい．
– 再利用が繰り返される間に保守性が徐々に悪くなっている．
→ 改良により，保守性を改善する必要があるが，導入/運用工
数の制約は大きい．
27

28. 組込みソフトウェアと外部変数
– 組込みソフトウェアでは以下の内容を不揮発メモリー
に保存する必要がある．
• 機能ごとの動作モードの設定内容
• 障害発生時の復旧情報になる処理内容
– 実装の容易さや処理速度の観点から，外部変数とし
て実現されている．
⇒ このような外部変数が，従来の保守性の評価法を
用いた改良を困難にしている．
28

29. 従来の評価法（構造化設計）
最上位の関数でないなら
M1で操作しないなら構造
やや複雑なインタフェース
体として統合すべき？
M1
A
D
B
C
M2 M6
A M3がM4/M5の前処理として独
C
R
B 立していなければM4/M5のイ
ンタフェースはやや複雑になる
M3 M4 M5
– 各モジュールのインタフェースに基づき,モジュール構
造を評価する.
– 外部変数の参照を含めたモジュール構造の評価がで
きない. 29

30. 構造化設計における
モジュール間結合度の評価(抜粋)
正常な結合
データ結合 単純なデータをパラメータとする
同一データ結合 複合データを渡す
制御結合 他のモジュールの内部ロジックを制御する
良くない結合
共通結合 外部変数によるデータの受け渡しを行う
内容結合 他のモジュールの内部を参照する
従来の方法論では，外部変数によるデータの受け渡しは良く
ないとされており，外部変数を用いざるを得ないプログラムを
改良する方法は示されていなかった． 30

31. 目的
導入/運用工数の制約を考慮したレガシーな組込
みソフトウェアの改良を可能にする．
– 外部変数の参照を含めた評価法がない．
– 従来の改良法(リエンジニアリング)はプログラム全体
の大規模な改良を行うので，多くの導入/運用工数が
必要である．
→そこで，改良のための評価法を提案すると共に，
提案する評価法に基づく支援ツールを開発した．
31

32. 提案する評価法 -調査-
– Ｃ言語，6,748ファイルを調査した．
– 保守性の悪いモジュールは以下特徴があった．
• 多くの外部変数を参照する．
– 同一分類の外部変数による複雑なインタフェースを持つ．
– 異なる分類の外部変数による判定処理が分散している．
• モジュール構造が複雑である．
– 上位関数を共通処理として用いており，複数の関数によ
る再帰処理になっている．
⇒上記の調査に基づき，評価法を提案する．
32

33. 提案する評価法 -基本的なアイデア-
下位モジュールでの
M1
M1 み用いる外部変数
A は＋で区別する
B
C
M2 M2(A, +B, +C)
M2 M3(B)
A
M4(C)
B C
M3 M4 M3 M4
B C
• 外部変数によるデータの受け渡しを上位モジュールから
の引数として扱い，関数の引数として表示する．
• 広く普及している構造化設計の評価法を用いて評価する．
33

34. 提案する評価法 -評価と改良-
a)外部変数が多い b)モジュール構造が複雑
再帰処理
保守性の悪
い状態
ABCDE ABCDE ACDE
評価 複雑なインタフェース 手順的 機能の重複
改良後
SB SB S CDE AB AB A
a-1)外部変数の統合 a-2)共通処理の抽出 b)共通処理の抽出
34

35. 支援ツール
オープンソースのツールであるRubyおよびECTAGSを
利用して支援ツールを約1人月で開発した．
– 外部変数によるデータの受け渡しを，上位関数との
評 インタフェースとして可視化できる．
価 – 外部変数を構造体として統合した場合のシミュレー
ションができる．
– 全体を鳥瞰しやすいように，プログラム構造をシンプ
改 ルに表示できる．
良
– 導入のために設計ガイドを作成した．
維
持 – 保守性を維持するためにチェックリストを作成した．
35

36. ツールの構造
関数および
ソースファイル 外部変数参照情報 ツール
Ruby
関数定義情報
ECTAGS 出力
test_1st(+DXpass, +TLsrams, TLzensrams)
test_2nd(+DXpass, TLsrams, +TLzensrams)
test_3rd(DXpass, +TLzensrams)
[再]test_1st(DXpass, TLsrams, TLzensrams)
外部変数分類定義 test_B(+DXpass, +TLsrams, TLzensrams)
[既]test_2nd(+DXpass, TLsrams, +TLzensrams)
外部変数をどのように構造 再帰処理には[再]，既に展開され
図 1 ツールの構造
体として統合するかを示す たツリーには[既]が表示される
36

37. 評価法の試行
対象：エキスパートが８時間レビューした約5,500ステッ
プのソースプログラム．
方法:プログラム構造の知識がないエンジニアが，支援
ツールを用いて30分調査した．
既に指摘されていた保守性の悪い状態を発見したほか，
レビューで発見できなかった問題点(複数の関数による
再帰処理)を発見することができた．
レビューでの指摘漏れを防止する効果は高い．
37

38. 評価法の導入
• レガシーソフトウェアを改造して，新しいシ
ステムを作るプロジェクトに導入した．
• 開発の中心メンバー３～４人で2時間ずつ，
５回の勉強会を実施した．
• 最終テスト段階でアンケートを実施した．
38

39. アンケート結果
– リーダーの評価は高く，支援ツール導入の効果はあった．
• 改良方法が分かる．
• 改良後の構造を確認できる．
– メンバーの評価は低かった．
• 複雑なオプションの指定など，キャラクタインタフェースが使いに
くい．
• 悪いところを見つける手助けはするが,修正作業そのものを支
援しない．
ユーザインターフェースの改良が必要である．
改良作業の支援の検討が必要である．
39

40. レガシーな組込みソフトウェアの改良法のまとめ
• レガシーな組込みソフトウェアの特徴を調査し，改良法
を提案すると共に支援ツールを作製した．
– 提案した改良法は，組み込みソフトウェアの導入/運用工数
の制約を考慮し，部分的な改良を支援する．
– 改良すべき点の検討や改良後のソフトウェアの保守性の確
認に有効であった．
– 導入(教育)に10時間/人を必要としたが，広く普及している方
法論であり，本来は研修として行われるべき工数である．
– 運用工数は30分を要したが，以降の工程での生産性の向上
を考慮すると十分な利益があったと考えられる．
40

41. レガシーな組込みソフトウェアの改良法の課題
• 改造作業の支援など，より使い易くす
ることが今後の課題であリ，GUIを開
発するなど，改良を進めている．
• アプリケーション終了時の状態保存用
のレジストリの操作にも，提案する改
良法を適用できる可能性がある．
Tcl/Tkを用いて開発したGUI
41

42. おわりに (論文第5章) -まとめ-
– 導入/運用工数の制約を考慮した2つの開発
支援法を提案した．
– 評価の結果，各支援法の導入/運用工数は少
なくてすむことがわかった．
導入工数 運用工数
小型計算機上での 0.13人日 0.1人日/年
開発プロセス改善法
レガシーな組込み (1.3日/人) 0.06人日
ソフトウェアの改良法
42

43. おわりに (論文第5章) -今後の課題-
• 本研究では実証的ソフトウェア工学の考え方に
基づき，ツールの設計や実装を行い，具体的な
議論を行った．
• 今後は，提案した支援法の現場での利用と改良
を，さらに進めていく予定である．
• また，今後もソフトウェア開発に関する提案だけ
ではなく，具体的なツールの開発を行い，研究を
進めていく予定である．
43