目次
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 ソフトウェアリスクマネージメントプロセス