close
1.

図書

東工大
目次DB

図書
東工大
目次DB
Capers Jones著
出版情報: 東京 : 構造計画研究所 , 東京 : 共立出版 (発売), 1999.4  xvi, 388p ; 21cm
所蔵情報: loading…
目次情報: 続きを見る
はじめに 1
ソフトウェアの品質に影響を与える36の要因 5
   1. 高いソフトウェア品質レベルの達成 15
   2. 能動的,受動的,名目的ソフトウェア品質組織 34
   3. 報告された欠陥のエージング 39
   4. 誤修正 42
   5. 誤ったテストケース 44
   6. Baldrige賞 48
   7. ソフトウェア品質計測の障壁 50
   8. ベストインクラスの品質結果 53
   9. ソフトウェア品質改善のケーススタディ 55
   10. ソフトウェア欠陥の種類 69
   11. ソフトウェア品質要員の認証 84
   12. クリーンルーム開発 85
   13. クライアント/サーバの品質 91
   14. ソフトウェア品質要員の報酬レベル 95
   15. 複雑度分析および測定 97
   16. 構成管理 105
   17. コスト見積とソフトウェア品質 108
   18. 品質コスト 116
   19. 欠陥あたりのコスト 119
   20. 徐々に増大するユーザ要求とソフトウェア品質 124
   21. ソフトウェア品質の米国平均の現状 127
   22. データ品質とデータ尺度 131
   23. 顧客およびユーザによる欠陥発見率 133
   24. 欠陥予防手法 134
   25. 欠陥予防および欠陥除去における産業間差異 137
   26. 欠陥除去率 140
   27. 欠陥修復率 147
   28. 欠陥の埋込み 150
   29. 欠陥重度レベル 152
   30. 欠陥追跡 153
   31. デミング賞 156
   32. ソフトウェア品質要員の人口調査 157
   33. DoD品質標準 159
   34. ダウンサイジングとソフトウェア品質 159
   35. ソフトウェア品質の経済的および競合的価値 159
   36. 欠陥多発モジュール 162
   37. ヨーロッパのソフトウェア品質イニシアティブ 164
   38. 正規の設計およびコードインスペクション 175
   39. ファンクションポイント尺度とソフトウェア品質 180
   40. ファンクションポイントによるソフトウェア品質見積の概算 194
   41. ソフトウェア品質データの欠落 197
   42. 世界的な品質レベル 198
   43. 「十分に良い」品質の誤謬 201
   44. 大規模なベータテスト 206
   45. IEEE品質標準 207
   46. ISO9001-9004の認証 209
   47. 日本のソフトウェア品質アプローチ 214
   48. ジョイントアプリケーション設計(JAD) 222
   49. キビアートグラフ 225
   50. Microsoftの品質手法 226
   51. 複数リリースの品質測定 232
   52. オブジェクト指向の品質レベル 235
   53. 直交欠陥報告(ODR) 245
   54. アウトソーシングと受託ソフトウェアの品質レベル 246
   55. プロジェクト管理とソフトウェア品質 255
   56. プロトタイピングとソフトウェア品質 260
   57. 品質保証部門 267
   58. 品質保証ツール量 271
   59. 品質定義 278
   60. 品質見積ツール 283
   61. 訴訟および保証にかかわる品質要因 285
   62. 品質機能展開(QFD) 287
   63. 品質後進企業 289
   64. 品質計測 291
   65. ラピッドアプリケーション開発(RAD)とソフトウェア品質 296
   66. 信頼性とソフトウェア品質 300
   67. 再利用性とソフトウェア品質 302
   68. リスク分析計画とソフトウェア品質 320
   69. スケジュールプレッシャとソフトウェア品質 322
   70. SEIの成熟度モデルとソフトウェア品質 326
   71. 6シグマ品質レベル 341
   72. テスト 342
   73. 総合的品質管理(TQM) 367
   74. 利用性研究室 368
   75. 顧客満足度 369
   76. 2000年問題 372
   要約および結論 373
文献 375
索引 381
訳者紹介 387
はじめに 1
ソフトウェアの品質に影響を与える36の要因 5
   1. 高いソフトウェア品質レベルの達成 15
2.

図書

東工大
目次DB

図書
東工大
目次DB
Robert B.Grady著 ; 古山恒夫,富野壽監訳
出版情報: 東京 : 構造計画研究所 , 東京 : 共立出版(発売), 1998.11  xix, 344p ; 21cm
所蔵情報: loading…
目次情報: 続きを見る
第1章 ソフトウェアプロセス改善-ランドラッシュ- 1
   プロセス改善のイメージ 3
   本書の構成 6
   PLAN:リスクを識別し、何をすべきか決定する 6
   プロセス改善のビジネス上の緊急性 8
   プロセス改善に対する投資の価値 9
   組織のプロセス改善に対する対応性 11
   DO:成功への構造化 13
   鍵を握る人々の支援を得る 14
   アプローチおよびプロジェクト計画の文書化 14
   CHECK:成功を測る 16
   基本的なソフトウェア尺度 16
   期待の枠組み作り 17
   中間結果 19
   ACTION:成功をてこにする 20
   改善領域を特定する強力な方法 21
   成功したベストプラクティスを広げる 21
   結論 23
第1部 PLAN リスクの特定と解決 26
第2章 ソフトウェアプロセスアセスメント:大地に杭を打つ 28
   アセスメントの範囲 29
   ISO9001,ISO9000-3 29
   プロセス成熟度モデル(CMM) 31
   ソフトウェア品質と生産性のアセスメント(SQPA) 31
   品質成熟度システム(QMS) 34
   Malcolm Baldrige賞 35
   アセスメントの選択 36
   何がアセスメントを成功させるか 40
   結論 41
第3章 ソフトウェアのコアコンピテンスのための計画作成 44
   ソフトウェアのコアコンピテンス計画の作成 46
   管理者のリーダシップ:事前計画作成 47
   コアコンピテンス計画の9つのステップ 49
   コアコンピテンス計画の遂行 58
   コアコンピテンスに向けた進捗の計測 59
   コアコンピテンスへの道を閉ざす障害の除去 63
   結論 64
第4章 ソフトウェアプロセス改善の投資モデル 66
   ソフトウェアマネジメントコストモデル 67
   モデルの新規開発コンポーネント 67
   モデルの保守コンポーネント 68
   モデルの手戻り作業コンポーネント 69
   ソフトウェアマネジメントの完全なコストモデル 71
   モデルの応用 72
   改善への期待を設定する-インスペクションの場合 73
   より積極的な期待-再利用の場合 74
   投資選択のポートフォリオ 76
   いくら投資すべきか? 78
   結論 79
第5章 ソフトウェアプロセス改善に対するマネジメントコミットメントの獲得 81
   マネジメントコミットメントに影響を与えるビジネス視点 83
   戦略的コンポーネント-「全体像」はあるか? 83
   戦略的コンポーネント雨漏れはないか? 86
   要約 90
   マネジメントコミットメントに影響を与える組織的視点 91
   戦略的コンポーネント-我々はどのリーグにいるのか? 91
   戦略的コンポーネント-今こそ・・・何をなすべきか? 94
   要約 96
   マネジメントコミットメントの力の場の利用 96
   力の場分析の準備 97
   力の場分析に基づいたアクション 98
   補遺:ソフトウェア依存ビジネスのマネジメントへの提言 100
   リーダシップ 100
   計画 101
   組織 101
   管理 101
第2部 DO 訓練,適用,支援,障害除去 104
第6章 成功できないことの古くからの言い訳から抜け出す 106
   理由その1:「マネジメントは決してそれに賛成しない」 107
   他の例 109
   理由その2:「前に試してみたがうまくいかなかった」 110
   経験マップ 112
   理由その3:「その方法でうまくっているグループと我々とは異なる」 114
   理由その4:「これらのすべての事柄をまず最初に行わなければならない」 117
   将来のあるべき姿に対するビジョン 119
   理由その5:「我々には時間がない」(我々はスケジュールに遅れてしまう) 121
   理由その6:「我々はもっとリソースを必要としている」 123
   推論のはしご 125
   結論 128
第7章 成功のための環境を作る 131
   動機づけ 132
   意欲を起こさせるビジョンを作り出し,それを分かち合う 132
   鍵を握る人々を特定し,励まし,支援する 135
   顧客のニーズに対して改善を柔軟にマッチさせる 138
   プロジェクトの作業環境を最適化する 141
   支援的かつ熱意に満ちた風土を作る 141
   プロセス改善の導入を加速させるためのインフラストラクチャ 143
   改善を計画しプロジェクトとして効果的にそれを実行する 146
   プロセス改善のスパイラルモデルを計画プロセスの強化に用いる 148
   プロジェクト管理の枠組みを変える 150
   結論 151
第8章 ソフトウェアプロセス改善を語る 153
   PLAN 155
   DO 164
   CHECK 165
   測定および確認 167
   ACTION 172
   PLAN 173
   ストーリーボードの準備 174
   結論 176
第3部 CHECK 結果の評価,成功の確保,顕彰 178
第9章 プロセス改善の確認 180
   ソフトウェアプロセス変革の目標 181
   ソフトウェアプロセス改善プログラムのためのベースライン測定 183
   提案:プロセスと製品を記述する 183
   例:プロセスと製品の記述 184
   提案:上位レベルプロセスの測定値を収集し要約する 184
   例:上位レベルプロセスの測定値 185
   提案:欠陥分析ベースラインの決定 185
   例:プロセス変革の前後における欠陥分析 186
   結果を確認するための当該変革に固有な測定 186
   結果を用いて次のステップを計画する 188
   プロセスは改善したか?それはどのくらいか? 189
   予期せぬ副次的効果があったか?複合要因はどうか? 189
   提案を明言する 190
   結論 194
第10章 プロセス改善結果の追跡と報告-ミションポッシブル 196
   ケース1:周辺機器用リアルタイムファームウェアのための構造化手法 197
   ケース2:初期のライフサイクルの改善 199
   ケース3:発展的目視レビュープロセス 201
   ケース4:3年間のインスペクションデータからの教訓 203
   幕間 205
   ケース5:オブジェクト指向技術の影響 206
   ケース6:ファームウェア再利用計画の成功例 207
   ケース7:品質,生産性,経済性に関する再利用効果 210
   幕間 212
   ケース8:結果の金銭的考察 212
   ケース9:結果の品質的な考察 214
   ケース10:HPの10X改善プログラム 215
   ケース11:最良の例 217
   結論 218
第4部 ACTION 更新,次レベルプロセスの展開,他の納得を得る 224
第11章 見返りの多いプロセス改善決定のためのソフトウェア欠陥分析 226
   欠陥データの対症的利用(一般的な出発点) 227
   欠陥分析(考え方の枠組みを変える) 230
   原因に対する行動 232
   根本原因分析のプロセス 232
   単発的根本原因分析 233
   プロジェクト終了後の根本原因分析 234
   主要な欠陥根本原因を除去することから得られる結果 241
   継続的プロセス改善サイクル 243
   結論 245
第12章 ソフトウェアプロセス改善の価値づけ 248
   価値の定義 249
   価値の違い 250
   コストの節減:開発組織内のコミュニケーション 251
   製品価値の増大:ビジネスチームとのコミュニケーションの拡大 254
   ビジネスの将来に対する価値議論の拡大 258
   結論 261
第13章 ソフトウェア工学のベストプラクティスの導入 264
   背景:インスペクションとは何か? 265
   HPの現在のインスペクションプロセスの要約 266
   HPの実験的段階(1976~1982)-スパイラルリングの1および2 269
   得られた教訓 269
   初期のHPガイドラインの確立(1983~1988)-スパイラルリング3 270
   得られた教訓 272
   ある部門における回想 273
   信念および導入の拡大(1989~1994)-スパイラルリング4 274
   得られた教訓 280
   もう1つの回想 281
   慣行の標準化-スパイラルリング5 282
   結論 285
第14章 運転次第で「マイレージ」は変わる 289
   将来のありたい姿をもって,プロセス改善を定義する 290
   「マイレージ」の改善その1:ビジネスニーズをよく理解する 291
   現状に対する明確な図式を描く 292
   「マイレージ」の改善その2:ソフトウェア開発コストとそれに影響を与える因子を理解する 292
   「マイレージ」の改善その3:変革に対する組織の対応性を理解する 293
   潜在的な障害を回避し最小化する 293
   「マイレージ」の改善その4:ビジネスおよび組織力を理解する 294
   「マイレージ」の改善その5:変革に対する抵抗の源を理解する 295
   「マイレージ」の改善その6:計画を強化する 295
   成功を最大化するために,問題解決について話す 296
   「マイレージ」の改善その7:改善プロジェクトを早期にストーリボード化する 296
   「マイレージ」の改善その8:成果について理にかなった期待を設定する 296
   「マイレージ」の改善その9:さまざまな聞き手に対して期待の枠組みを作る 297
   「マイレージ」の改善その10:計測結果をもって成功を一層強固なものにする 297
   改善の将来 298
付録 301
   付録A ソフトウェアの主要な開発/保守コストモデル 301
   基本モデルの仮定値 304
   開発と保守の詳細 305
   HPの7部門における失敗分析データと欠陥データの正規化 309
   HPの2部門が集めた開発全段階のデータの欠陥分析 311
   HPの7部門における欠陥分析データ 312
   棒グラフ:主要な開発/保守コストの主要要素のマネジメントモデル 313
   付録B コアコンピテンス計画ノート 315
   第1日目のスケジュール例 316
   第2日目のスケジュール例 317
   付録C ソフトウェアプロダクト/プロセスマトリックス 318
   付録D 導入度尺度 321
   導入度を求める数式の定義 321
   インスペクションアセスメント成熟度モデル 322
   HPインスペクションの節減額の推定 324
   付録E ソフトウェアプロセス改善参考文献 326
   PLAN 326
   DO 327
   CHECK 328
   ACTION 329
   アルファベット順の全文献リスト 330
索引 341
第1章 ソフトウェアプロセス改善-ランドラッシュ- 1
   プロセス改善のイメージ 3
   本書の構成 6
3.

図書

東工大
目次DB

図書
東工大
目次DB
イレイン・ワイス著 ; 関友作訳
出版情報: 東京 : 海文堂出版, 2000.11  166p ; 21cm
所蔵情報: loading…
目次情報: 続きを見る
訳者まえがき 7
はじめに 11
第1部 人とコンピュータを結ぶ
   [1] 本書の目的 19
   ・能力のパラドックス 20
   ・本書のねらい 23
   ・つぎの章では 24
   [2] コンピュータ・トレーニングの全体図 27
   ・現場からの報告 : 営業員を武装する 27
   ・内容 : 何を教えるか 28
   ・過程 : どのように教えるか 31
   ・結果 : どのように評価するか 34
   ・つぎの章では 37
第2部 何を教えるか
   [3] 学習者を知る 41
   ・現場からの報告 : 授業のどこがまずいのか? 41
   ・なぜ学習者を調べるのか 42
   ・能力には差がある 42
   ・態度には差がある 47
   ・学習者の能力と態度を知る 49
   ・つぎの章では 53
   [4] システムの使いやすさを知る 55
   ・現場からの報告 : すぐに使えるシステム? 55
   ・なぜ使いやすさは重要なのか 56
   ・なぜ使いやすさを調べるのか 57
   ・ユーザ・インタフェースの4側面 58
   ・現場にもどって 68
   ・つぎの章では 70
   [5] 業務環境を知る 73
   ・現場からの報告 : 1日で教えるには? 73
   ・なぜ業務環境を調べるのか 74
   ・業務環境の3ポイント 75
   ・現場にもどって 83
   ・つぎの章では 84
第3部 どのように考えるか
   [6] 教育方法を教える 87
   ・現場からの報告 : 教えてはみたけれど 87
   ・人はコンピュータをどのように学ぶのか 88
   ・成人学習者の3ポイント 92
   ・理論はわかった-では、どのように教えるのか 94
   ・つぎの章では 105
   [7] 教材を考える 107
   ・現場からの報告 : 学校の教員に教える 107
   ・3種類の教材 109
   ・効果的な教材のポイント : 内容とデザイン 113
   ・クイック・リファレンスを自作すべき場合 117
   ・現場にもどって 119
   ・つぎの章では 122
第4部 どのように評価するか
   [8] 教育を評価する 125
   ・現場からの報告 : トレーニングの評価方法 125
   ・複数の観点から評価する 126
   ・自己評価する 127
   ・同僚に評価してもらう 128
   ・受講者に評価してもらう 130
   ・つぎの章では 140
   [9] 学習を評価する 143
   ・現場からの報告 : システムを導入するまえに 143
   ・なぜ評価するのか 144
   ・何を評価するか 146
   ・どのように評価するか 150
   ・つぎは 157
参考文献 159
索引 163
訳者まえがき 7
はじめに 11
第1部 人とコンピュータを結ぶ
4.

図書

東工大
目次DB

図書
東工大
目次DB
Tom Gilb, Dorothy Graham著
出版情報: 東京 : 構造計画研究所 , 東京 : 共立出版 (発売), 1999.8  xxvi, 450p ; 21cm
所蔵情報: loading…
目次情報: 続きを見る
第1章 インスペクションの歴史的背景および他の手法との比較 1
   1.1 歴史的ルーツ 1
   1.2 インスペクションと他のレビュー技術との比較 4
   1.3 テストとインスペクションの比較 8
第2章 インスペクションの便益とコスト 13
   2.1 現在、欠陥によってどの程度のコストがかかっているか? 14
   2.2 直接的節約 17
   2.3 間接的便益 24
   2.4 インスペクションのコスト 27
   2.5 インスペクションプロセス内の作業の割合 29
   2.6 副次効果コスト 29
第3章 ソフトウェアインスペクションの概観 31
   3.1 成果物インスペクション 31
   3.2 プロセス改善 37
   3.3 要約 39
第4章 インスペクションプロセス(パート1)-始動と文書 40
   4.1 インスペクションの要請 41
   4.2 プロセス計画の策定 43
   4.3 成果物のインスペクションに必要な文書 44
   4.4 開始プロセス 64
   4.5 キックオフミーティング 67
   4.6 まとめ 69
第5章 インスペクションプロセス(パート2)-チェック 71
   5.1 個人チェック 71
   5.2 ロギングミーティング 83
第6章 インスペクションプロセス(パート3)-完了 97
   6.1 編集 98
   6.2 フォローアップ 103
   6.3 終了 105
   6.4 要約 114
第7章 インスペクションプロセス(パート4)-プロセス改善 115
   7.1 問題予防と対比した問題除去 115
   7.2 プロセス管理の概念 116
   7.3 プロセスブレーンストーミング(根本原因の分析) 117
   7.4 IBMの方法との対比 125
   7.5 プロセス変革管理チームの組織 130
第8章 インスペクションリーダ 136
   8.1 リーダは誰か? 136
   8.2 マスタープラン 138
   8.3 開始基準 143
   8.4 対象文書の選択 145
   8.5 チェックおよびロギング速度 153
   8.6 インスペクタの選択 157
   8.7 会議室の予約 166
   8.8 インスペクタにスペシャリストの役割を割り当てる 167
   8.9 キックオフミーティング 171
   8.10 ロギングミーティングの準備 176
   8.11 ロギングミーティングの指揮をとる 179
   8.12 プロセスブレーンストーミングを指揮する 194
   8.13 尺度の収集、公開および利用 197
   8.14 編集作業 202
   8.15 作業終了の検証:インスペクションリーダによるフォローアップ 203
   8.16 終了 205
   8.17 変革管理 207
   8.18 リーダの管理 208
   8.19 進歩的なリーダの指針 211
第9章 スペシャリストの視点からのインスペクション 221
   9.1 チェッカの視点からのインスペクション 221
   9.2 オーサ/編集者の視点から見たインスペクション 226
第10章 導入とトレーニング 232
   10.1 導入 233
   10.2 インスペクション導入のチェックリスト 247
   10.3 正規のトレーニング 258
   10.4 要約と結論 263
第11章 困難に打ち勝つ 265
   11.1 インスペクションの失敗を把握する 265
   11.2 なぜインスペクションプロセスが失敗するか 267
   11.3 失敗したプロセス改善の初期の試み 268
   11.4 典型的な導入時の問題と解決法 271
第12章 Appliconにおけるインスペクション 277
   実施 277
   1年目の実施状況 278
   2年目の実施状況 281
   定着に向けての多様な取組み 282
   長期戦略 283
   コスト 284
   便益 284
   問題とその解決策 285
   成功の鍵 288
   実施の秘訣 291
第13章 1人からの出発 294
   パート1:プロジェクト 295
   1. 概況 295
   2. 上流インスペクション 298
   3. 顧客訪問 305
   4. プロジェクトの成功 310
   パート2:インスペクションの進め方 311
   1. 自分で作る尺度 311
   2. インスペクションを阻むもの 319
   3. 結論 321
第14章 Thorn EMIの文書インスペクション 322
   はじめに 322
   社内でのインスペクションの確立 326
   インスペクション実施までの経緯 328
   便益 329
   コスト 330
   Thorn EMIで学んだ教訓 331
   結論 332
第15章 Racal Redacにおけるインスペクション 334
   会社紹介 334
   開発アプリケーション 334
   導入経過 334
   インスペクション対象文書 339
   運営方針 340
   コストと便益 341
第16章 Sema Group(英国)におけるインスペクション 343
   準備 343
   最初のプロジェクト 344
   最初のプロジェクトの教訓 346
   インスペクションの普及 347
   Semaの現状 348
   事例 350
   グラフと残存欠陥数 351
   結論 353
   推奨事項 354
第17章 欠陥予防プロセスの実践 355
   はじめに 355
   欠陥予防プロセス概観 355
   インスペクションプロセスとの関係 358
   欠陥予防の実践面 360
   欠陥とは何か? 360
   欠陥の選択 361
   原因分析ミーティングの運営 362
   リポジトリ 377
   工程キックオフ(プロセスレビュー)ミーティング 377
   工程キックオフミーティングのコストとその効果 378
   結論 379
   参考文献 379
付録A:1ページインスペクションハンドブック 381
付録B:手順-スペシャリストおよびサブプロセスが何をすべきか 382
付録C:インスペクションの尺度と書式 395
付録D:ルールセット 411
付録E:インスペクションの活動に関わる基本方針の例 419
用語集 421
参考文献 439
索引 444
第1章 インスペクションの歴史的背景および他の手法との比較 1
   1.1 歴史的ルーツ 1
   1.2 インスペクションと他のレビュー技術との比較 4
5.

図書

東工大
目次DB

図書
東工大
目次DB
Capers Jones著 ; 島崎恭一, 富野壽監訳
出版情報: 東京 : 構造計画研究所 , 東京 : 共立出版 (発売), 1995.8  xxiii, 627p ; 27cm
所蔵情報: loading…
目次情報: 続きを見る
1 序論 1
2 よくあるソフトウェア開発上のリスク 27
3 深刻なソフトウェア開発上のリスク 45
4 あいまいな改善目標 62
5 不自然な成熟度レベル 70
6 プロジェクトの中止 77
7 企業内の政治抗争 83
8 コストの超過 88
9 徐々に増大するユーザ要求 94
10 狭いオフィス環境 101
11 欠陥多発モジュール 106
12 過大な文書化作業 112
13 過酷なスケジュール 120
14 出荷時期の遅れ 126
15 生産性の誇大宣伝 133
16 顧客と受託開発企業の軋轢 139
17 ソフトウェア管理者と経営者の軋轢 146
18 高い保守コスト 150
19 不正確なコスト見積 160
20 不正確な尺度 172
21 不正確な品質見積 181
22 不正確な規模見積 187
23 不適切なアセスメント 193
24 不適切な報酬制度 203
25 不適切な構成管理 209
26 不適切な技術教育者 218
27 不適切な管理者教育 225
28 不適切な計測 234
29 不適切なパッケージ入手法 242
30 不適切な資料調査環境 250
31 不適切な規格 255
32 不適切なプロジェクトリスク分析 262
33 不適切な価値分析 268
34 不適切な管理ツールと手法 277
35 不適切な品質保証ツールと手法 292
36 不適切なソフトウェア工学ツールと手法 306
37 不適切な技術文書作成ツールと手法 320
38 再利用性の低いシステム構成 330
39 再利用性の低いプログラム 339
40 再利用性の低いデータ 347
41 再利用性の低い設計 358
42 再利用性の低い文書 366
43 再利用性の低い見積 376
44 再利用性の低いヒューマンインターフェース 389
45 再利用性の低いプロジェクト計画 397
46 再利用性の低い要求仕様 404
46 再利用性の低いテスト 412
48 専門分化の不足 420
49 老朽化システムの保守 430
50 低生産性 437
51 低品質 444
52 ソフトウェア従事者の低いステータス 454
53 低い顧客満足度 460
54 管理者の不当行為 466
55 技術者の不当行為 473
56 スケジュールの遅れ 479
57 不完全なソフトウェアライフサイクルの使用 485
58 弱体な組織 499
59 拙劣な技術投資 507
60 過酷なレイオフや解雇 516
61 性急な改善計画 525
62 銀の弾丸(特効薬)症候群 536
63 進まない技術転移 544
ソフトウェア開発のアセスメントと管理の用語集 552
1 序論 1
2 よくあるソフトウェア開発上のリスク 27
3 深刻なソフトウェア開発上のリスク 45
6.

図書

東工大
目次DB

図書
東工大
目次DB
Ian Sommerville, Pete Sawyer著 ; 富野壽監訳
出版情報: 東京 : 構造計画研究所 , 東京 : 共立出版 (発売), 2000.2  ix, 333p ; 21cm
所蔵情報: loading…
目次情報: 続きを見る
第1章 はじめに 1
第2章 実践的プロセス改善 14
第3章 要求定義文書 33
第4章 要求の導出 57
第5章 要求の分析および折衝 98
第6章 要求の記述 123
第7章 システムモデリング 140
第8章 要求の確認 163
第9章 要求の管理 187
第10章 クリティカルシステムについての要求定義工学 217
第11章 構造化手法によるシステムモデリング 255
第12章 形式的仕様記述 281
第13章 視点(ビューポイント) 305
索引 331
第1章 はじめに 1
第2章 実践的プロセス改善 14
第3章 要求定義文書 33
文献の複写および貸借の依頼を行う
 文献複写・貸借依頼