ソフトウェア書籍一覧12

|   一覧11へ   |   書籍一覧目次へ    |   トップページへ   |   一覧13へ   |

BD10219_.GIF (978 バイト)

 

cbook24.comで購入する

ソフトウエア書籍一覧 目次



プログラミングの心理学

または,ハイテクノロジーの人間学

ISBN4-7741-0077-3  技術評論社

原書:Dorset House「The Psychology of Computer Programming」Gerald M. Weinberg(’98発売)

ワインバーグ,G.M. 著 

木村 泉 ・ 角田 博保 ・ 久野 靖 ・ 白浜 律雄 訳

A5  368ページ  本体価格(税別):\2,233  1994年11月発売 1994年発売

[内容]

ソフトウェア開発における人間側の問題に史上はじめて真正面から取り組み、その基本的問題点をずばりずばりと数え上げ、当時はびこっていた、そしていまなお一部ではびこり続けている迷信に痛棒を加えた本。 

[目次]

第1部 人の活動としてのプログラミング
第2部 社会活動としてのプログラミング
第3部 個人の活動としてのプログラミング
第4部 プログラミングの道具
第5部 エピローグ

 

 

 

 

Amazon.co.jpで購入する

cbook24.comで購入する

ソフトウエア書籍一覧 目次

 

[実践的]ソフトウェア開発工程管理

ISBN4-7741-1075-2  技術評論社

竹山 寛 著

A5 判   232 ページ  本体価格 2280 円+税  初版 2000年10月発行

[内容]

商品としてのソフトウェアの開発は、一人が黙々と作るというのではなく、組織的に行われるものです。少人数のプロジェクトから大規模な開発まで、人が集まって実施するという点で、問題の発生する局面は多々存在します。どうすれば問題を回避できるか、問題が発生したとしてそれをどう乗り切るかが、開発においては鍵になります。しかし、そういったノウハウは口伝えや見よう見真似で受け継がれているというのが実状で、これまで、現場レベルでの知識がまとめられたことはありませんでした。本書は、豊富な実践経験を持つ著者が、永年にわたって蓄積してきた知識を一挙に公開するものです。いま管理をする立場にある方にも、これから管理をする立場に立つ方にも、必ず得るところがあるものと思います。

[目次]

第1章 ソフトウェアの開発

1・1 ソフトウェア開発の手順
1・2 ソフトウェアの設計

1・2・1 基本設計
1・2・2 機能設計
1・2・3 詳細設計

1・3 ソフトウェアの開発と製造

1・3・1 プログラミング
1・3・2 テスト仕様書
1・3・3 プログラム変更管理
1・3・4 テスト進捗管理

第2章 管理とは何か

2・1 管理に対する考え方
2・2 開発工程と管理

第3章 開発と管理

3・1 開発管理で用いるドキュメント

3・1・1 アローダイアグラム(作戦遂行戦略図)
3・1・2 工程管理表
3・1・3 テスト進捗管理(バグ発生/テスト消化曲線)
3・1・4 目標設定

3・2 アローダイアグラム

3・2・1 アローダイアグラムの利用
3・2・2 アローダイアグラムを利用する上でのポイント

3・3 目標の設定

3・3・1 プログラミング
3・3・2 テスト項目
3・3・3 摘出不良件数

3・4 開発管理マスタードキュメント

3・4・1 工程管理表
3・4・2 ILUO(モジュール関連図)管理

3・5 テスト進捗管理

3・5・1 テスト進捗管理の事例
3・5・2 発生/テスト消化曲線でのテスト進捗管理のポイント

第4章 品質と管理

4・1 品質の管理
4・2 品質とコスト
4・3 不良の分析

4・3・1 プログラム変更管理表
4・3・2 不良摘出状況分析/予測

第5章 開発における実践アドバイス

5・1 設計段階

5・1・1 アローダイアグラムの日程は逆から立てる
5・1・2 アローダイアグラムの項目ははっきりと記載する
5・1・3 作業ステップ数はプログラム開発の基準値である

5・2 プログラミング段階

5・2・1 きれいなプログラムには不良が少ない
5・2・2 プログラムの先頭にはヘッダコメントをつける
5・2・3 コメントは重要な仕様書である
5・2・4 プログラムの入口/出口は1カ所にまとめる
5・2・5 プログラムのステップ数は、50ステップを目安にする
5・2・6 インデンティングはあまり深くしない
5・2・7 例外処理、異常処理はメイン処理の外に置く

5・2・8 アセンブラ言語で記述することをおそれてはいけない
5・2・9 罠を張るプログラムを仕込んでおく
5・2・10 重要な処理についてはシミュレーションを行う
5・2・11 チューニングは諸条件を考慮して注意深く行う
5・2・12 作業エリアの定義は正確に行う
5・2・13 ソースの管理は体系的に行う

5・3 テスト段階

5・3・1 テストの目的を認識しておく
5・3・2 テスト項目作成の際は、不良があることを前提にする
5・3・3 マトリックスチェックリストは、机上、単体テストに利用する
5・3・4 プログラムテスト仕様書は、結合テスト、システムテストに利用する
5・3・5 机上デバッグをおろそかにしない
5・3・6 机上、単体テスト完了までは、結合テストに移行しない
5・3・7 単体デバッグ以降は、メインパスを最優先に完了させる
5・3・8 テスト項目件数は、その最適値を求める
5・3・9 目標テスト項目件数の配分は、よく考えて行う
5・3・10 摘出不良目標件数は、使用に従った開発の証明となる
5・3・11 テストプログラムの作成は計画をもって行う
5・3・12 負荷テストを前提にテストを実行する
5・3・13 入力データは、許されない物もテストしておく
5・3・14 モンキーオペレーションも重要なテスト方法である
5・3・15 テスト結果の判定は正確に行う
5・3・16 不良が発生したら分析を行う
5・3・17 類似の不良はステップ数と同じだけあると考える
5・3・18 「1と3の法則」に注意する
5・3・19 不良の修正では、現象対策ではなく根本原因対策を行う
5・3・20 プログラムの修正は完全を期して行う
5・3・21 プログラムの変更管理は省かない
5・3・22 自前ツールの開発は怠りなく行っておく

5・4 管理者としての心構え

5・4・1 プロジェクト管理者は、そのあり方を自ら問うべし
5・4・2 プロジェクトの開発能力を把握するように努める
5・4・3 開発者の技術能力の差を平準化するように努める
5・4・4 開発者が達成可能な目標値を定め、「挑戦」する
5・4・5 技術能力は個人個人で違い、1人=1人とはいえない
5・4・6 つねに新しい試みを行うようにする
5・4・7 管理者は、いつも攻撃的であれ
5・4・8 油断はプロジェクトを混乱させる
5・4・9 数字がすべてを物語るとは限らない
5・4・10 管理はビジュアルに行う
5・4・11 プロジェクト推進には3つの「山」がある
5・4・12 突き当たった「壁」を知るには、ボールを投げてみる
5・4・13 決断にはリスクがあることを認識しておく
5・4・14 プログラムを切り捨てることも管理者の仕事である
5・4・15 遅延を取り戻す特効薬はない
5・4・16 分析ができない管理者は去れ
5・4・17 過去の失敗は成功への扉の鍵として活かす
5・4・18 ソフトウェアは、システムの総仕上げをするものである
5・4・19 プログラムの最終評価は、使用する顧客が下す
5・4・20 プログラムの品質という物を考え直してみる


Amazon.co.jpで購入する

ソフトウエア書籍一覧 目次

一般システム思考入門 

ISBN4-314-00254-9  紀伊国屋書店出版部

原書:「An Introduction to General Systems Thinking」Dorset House

G.M.ワインバーグ 著

松田武彦 監訳

増田伸爾 訳

A5判  352頁  本体価格¥3,592  1979年6月発売

[内容]
   
「一般システム思考」は,今までの専門的な固有学問の領域に属さない様々な問題を考える場合にきわめて有効な思考法である。すなわち,ものごとを有機的に関連したものとして,そして何よりも全体的に把握することをめざしている。誰にもわかるように平易に書かれた本書は,学生,教師,研究者,ビジネスマンなどあらゆる人々の思考方法に一大変革をもたらすだろう。

 

 

ソフトウェア書籍次のページ          ソフトウェア書籍目次            トップページ