Part1　ソフトウェアの危うさの本質を体感してみよう

Chapter 1　ソフトウェアの危うさを知ろう

• 1-1　設計の規範教育演習から見えるソフトウェアの危うさ
• 1-2　SESSAMEの「Cプログラミングによる設計の規範演習」
• 1-3　演習広義のスケジュールの例
• 1-4　演習問題の仕様
• 1-5　演習問題の解き方
• 1-6　演習問題の解答例
• 1-7　ユニットテスト環境とテストケースの準備
• 1-8　設計規範の適合性の判定方法とチェック手法
• 1-9　演習結果の評価について

Chapter 2　危ないソフトウェアのプログラム例とケーススタディ

• 2-1　プログラム例－20個のケースの特徴
• 2-2　ケーススタディ
• 2-3　［ケース1］iとjの未初期化でプログラムが飛んだ
• 2-4　［ケース2］アイデアはわかるけど，効率は？
• 2-5　［ケース3］どうしてここマクロを使うの？
• 2-6　［ケース4］returnを通らず抜ける危険があるぞ！
• 2-7　［ケース5］字下げがめちゃくちゃ
• 2-8　［ケース6］試行錯誤のなれの果て
• 2-9　［ケース7］それじゃ境界がわからないでしょう
• 2-10　［ケース8］変数は初期化して使いましょう
• 2-11　［ケース9］使っていない変数は何のため？
• 2-12　［ケース10］出口4つはわかりにくくない？
• 2-13　［ケース11］無意味なコメントアウトは残すな
• 2-14　［ケース12］細かすぎませんか？
• 2-15　［ケース13］意味のある変数なら1文字変数はやめよう
• 2-16　［ケース14］カウンタは2つもいらないんじゃない？
• 2-17　［ケース15］デバッグ用のprintfが残っているよ
• 2-18　［ケース16］解答例とは違うけど，これもいいかも
• 2-19　［ケース17］if文をもう少しすっきりさせたいなぁ
• 2-20　［ケース18］かなりいい感じ
• 2-21　［ケース19］ビフォーアフター：Beforeがこれ
• 2-22　［ケース20］ビフォーアフター：Afterで改善！

Chapter 3　ソフトウェアはなぜ危ないのか

• 3-1　単体テストをパスしているコードでも…
• 3-2　テストで完全なソフトウェアを作れると考えてはいけない

Chapter 4　ソフトウェアの品質を高く保持するために

• 4-1　ソフトウェアには見える化が必要
• 4-2　品質を保持するために必要なこと
• 4-3　「ソフトウェアを作るのは生身の人間である」ことを理解しよう

Part2　日本的ソフトウェアプロジェクトの管理はここから

Chapter 5　ソフトウェア開発の理想と現実

• 5-1　ソフトウェアの開発プロセス
• 5-2　組込みソフトウェアの開発プロセス
• 5-3　小規模ソフトウェアの開発プロセス
• 5-4　ソフトウェア開発プロセスのモデル

Chapter 6　日本のソフトウェアプロジェクトに求められる取り組み

• 6-1　プロジェクトに根付いている目に見えない規範
• 6-2　継続的な取り組みの必要性
• 6-3　テストでは「リコールを起こさないソフトウェア」は作れない
• 6-4　ソフトウェア品質向上の取り組み－構成管理と変更管理

Chapter 7　ソフトウェア構成管理

• 7-1　なぜ，ソフトウェア構成管理が必要か？
• 7-2　ソフトウェア構成管理をシミュレーションしてみよう
• 7-3　ソフトウェア構成管理のベースライン設定
• 7-4　ソフトウェアの変更容易性
• 7-5　ソフトウェアの要求仕様の管理
• 7-6　ソフトウェア構成管理と変更管理
• 7-7　ソフトウェアリリース時の管理
• 7-8　トレーサビリティの向上
• 7-9　派生開発とソフトウェア構成管理
• 7-10　再利用資産とソフトウェア構成管理
• 7-11　ソフトウェア構成管理とアクセス権の設定

Chapter 8　ソフトウェア変更管理

• 8-1　なぜ，ソフトウェア変更管理が必要か？
• 8-2　ソフトウェア変更管理の段階的な適用
• 8-3　変更要求と入力データ
• 8-4　ソフトウェア変更管理と構成管理のリンク
• 8-5　ソフトウェア変更管理と品質管理
• 8-6　ソフトウェア変更管理における注意点

Chapter 9　レビュー

• 9-1　なぜ，CMMIのアプローチをそのまま取り入れないのか？
• 9-2　さまざまなレビュー
• 9-3　レビューの実施
• 9-4　今後の取り組み

Part3　ソフトウェア資産化の技術がリコール防止につながる

Chapter 10　ソフトウェア開発のプラットフォーム

• 10-1　プラットフォームが共通のソフトウェア開発とそうでないソフトウェア開発
• 10-2　ソフトウェア開発のアーキテクチャ

Chapter 11　ソフトウェアシステムとソフトウェア搭載機器の価値

• 11-1　ソフトウェア品質とは？
• 11-2　ソフトウェア資産の価値

Chapter 12　再利用資産を抽出するためのアプローチ

• 12-1　ソフトエンジニアはソフトウェア資産を再利用できているか？
• 12-2　再利用戦略のこれまでとこれから

Chapter 13　再利用資産を抽出する手順

• 13-1　現状のソフトウェアシステムの分析とドメイン構造の可視化
• 13-2　ドメイン構造図の作成
• 13-3　市場要求・ソフトウェア実装対応表の作成

Chapter 14　再利用資産の抽出のケーススタディ

• 14-1　［ケーススタディ1］再利用すべき機能モジュールが固定要素，かつ市場要求の重要度が高い
• 14-2　［ケーススタディ2］再利用すべき機能モジュールが変動要素，かつ市場要求の重要度が高い
• 14-3　［ケーススタディ3］機能モジュールを用いない，かつ市場要求の重要度が高い
• 14-4　3つのケーススタディからわかること

Chapter 15　再利用資産の抽出後のアプローチ

• 15-1　組込みシステムの信頼性を効果的に向上させるために
• 15-2　再利用すべきソフトウェア資産の抽出の重要性

Chapter 16　安全性が求められるシステムに対するアプローチ

• 16-1　安全という価値
• 16-2　史上最悪のソフトウェアバグの考察

Chapter 17　安全アーキテクチャの検討

• 17-1　エレベータの安全アーキテクチャ
• 17-2　安全設計
• 17-3　安全アーキテクチャモデル

Chapter 18　ソフトウェアの資産化して品質と開発効率を高める

• 18-1　顧客満足度を高める価値の可視化とソフトウェアの資産化
• 18-2　ソフトウェア資産を抽出するスキルを修得するには

Appendix　ソフトウェアを含むシステムの安全標準と安全規格の紹介

Appendix A　ソフトウェアに関する国際標準や国際規格の読み方

• A-1　「MISRA SA」と「IEC 62304」
• A-2　国際標準や国際規格との向き合い方
• A-3　「ISO（国際標準化機構）」と「IEC（国際電気標準会議）」
• A-4　ソフトウェアに関する国際標準や国際規格への対応
• A-5　安全性や信頼性を説明する責任
• A-6　説明責任が果たせない製品は世界に受け入れられないし，実際に危ない
• A-7　国際標準や国際規格をポジティブにとらえる
• A-8　国際標準や国際規格の読み方

Appendix B　MISRA SA（MISRAソフトウェア安全性解析ガイドライン）

• B-1　略語と用語の解説（抜粋）
• B-2　概論
• B-3　安全マネージメント
• B-4　MISRA安全プロセス
• B-5　MISRAシステム安全分析プロセス
• B-6　PSA（予備安全分析）
• B-7　ハザードの等級化
• B-8　DSA（詳細安全分析）

Appendix C　IEC 62304（医療機器ソフトウェア－ソフトウェアライフサイクルプロセス）

• C-1　リスクを軽減するために
• C-2　概要
• C-3　用語および定義（抜粋）
• C-4　ソフトウェア開発計画
• C-5　ソフトウェア要求分析
• C-6　ソフトウェアアーキテクチャ設計
• C-7　ソフトウェア詳細設計
• C-8　ソフトウェアユニットの実装および検証
• C-9　ソフトウェア結合および結合テスト
• C-10　ソフトウェアシステムテスト
• C-11　ソフトウェアリリース
• C-12　ソフトウェア保守プロセス
• C-13　ソフトウェアリスクマネージメントプロセス