ソフトウェア開発201の鉄則 の商品レビュー
(2002.08.27読了)(2002.06.30購入) (「BOOK」データベースより)amazon 本書は、ソフトウェア工学の原理を1冊にまとめた本である。原理とは、選択した技法、ツール、言語がどんなものであるかに関係なく、ソフトウェア工学に関して言える基本的な真理、原則、ま...
(2002.08.27読了)(2002.06.30購入) (「BOOK」データベースより)amazon 本書は、ソフトウェア工学の原理を1冊にまとめた本である。原理とは、選択した技法、ツール、言語がどんなものであるかに関係なく、ソフトウェア工学に関して言える基本的な真理、原則、または仮説を指す。わずかな例外を除いて、本書に掲載した原理は私自身のものではなく、多くのソフトウェア工学の実践者や研究者の論文から抜粋したものである。失敗を未然に防ぐノウハウ。
Posted by
技術本の善し悪し、あるいは有用性を自分で判断するのは難しいものです。 ここに書かれている「原理」は、まえがきにあるように「原理とは、選択した技法、ツール、言語がどんなものであるかに関係なく、ソフトウェア工学に関して言える基本的な心理、原則、または仮説を指」します。 数学の定理の...
技術本の善し悪し、あるいは有用性を自分で判断するのは難しいものです。 ここに書かれている「原理」は、まえがきにあるように「原理とは、選択した技法、ツール、言語がどんなものであるかに関係なく、ソフトウェア工学に関して言える基本的な心理、原則、または仮説を指」します。 数学の定理のようなものとも言えますが、序章に書かれているとおり、「原理は、学問分野の成長につれて進化するもの」です。この201の原理は「こんにち(日本版の初版は1996年)」のものです。それにしては、ここに書かれている原理は色あせていません。ソフトウェア開発やテストがさほど進化していないとも言えますし、だからこそこれらが「原理」としての価値を失っていないとも言えます。 以前の私には、この本の価値は理解できなかったと思います。数くの本を読み、セミナーやシンポジウムに参加するなどして、ようやく本書が非常に優れた辞書的な価値を持っていることを実感しました。 よほどの自信がない限り、まずはここに書かれていることは正しいと信じて、いかにそれを実践するかを考えるべきだと思います。難しいですが、難しいからこそ本書のような羅針盤が必要です。 手元に置いて、折に触れ参照したくなる珠玉の一冊です。 XDDPで有名な清水吉男氏も推薦されていますね。
Posted by
ソフトウェア工学の多数の論文のなかから、principleと呼べるものをDavisが厳選し、実務者にも読みやすく(Davisはもともとは実務者でした)エッセイ風にまとめたものです。 この本には「当たり前」と思うことばかり書いてあります。 けれど、実践できていないことも多いは...
ソフトウェア工学の多数の論文のなかから、principleと呼べるものをDavisが厳選し、実務者にも読みやすく(Davisはもともとは実務者でした)エッセイ風にまとめたものです。 この本には「当たり前」と思うことばかり書いてあります。 けれど、実践できていないことも多いはず。 何故、実践できていないか? どうしたらよいか? を考えるきっかけになる良書です。 テスティングの原理も載っています。 107 テスト項目と要求項目と関係づけよ 108 テストを行う時期よりずっと前にテストを計画せよ 109 自分のソフトウェアを自分でテストするな 110 自分のソフトウェアのテスト計画を自分で作成するな 111 テスティングは欠陥の存在をあらわにするだけだ 112 エラーだらけのソフトウェアは価値がないことを保証するが、エラーがないこととそのソフトウェアの価値は無関係である 113 エラーを見つけてこそテストがうまくいったといえる 114 半分のエラーは15%のモジュールで発見される 115 ブラックボックス及びホワイトボックス両方のテスティングを用いよ 116 テストケースには期待される結果を含めよ 117 無効な入力をテストせよ 118 常にカフカ状態のテストをせよ 119 ビッグバン説は当てはまらない 120 MCabeの複雑性尺度を使え 121 効果的な完了尺度を使え 122 テスト・カバレッジを効果的に達成せよ 123 単体テスティングが済む前に統合するな 124 ソフトウェアに仕掛けを組み込め 125 エラーの原因を分析せよ 126 エラーを個人のものにするな それから、「“硬派”のホームページ」に清水吉男さんによる解説がまとめられていますので合わせて読むと面白いと思います。
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
多くの経験を読んで、自分はなぜそうしないか、なぜそうできていないかの理由を考えるとよいかもしれない。 その仕事固有の制約条件があったり、その分野固有の制約条件があってできないことがあるかもしれない。 それを洗い出すきっかけとしても、いいかもしれない。
Posted by
様々なソフトウェア工学の原理を一冊にまとめた書籍で、 一般、要求分析、設計、コーディング、テスティング、 管理、製品保証、進化の各分野から選りすぐりの原理を紹介していく。 とりわけ以下のような原理が私的には頷けました。 ・文書のない設計は設計とは言わない ・特殊なケースをあまり...
様々なソフトウェア工学の原理を一冊にまとめた書籍で、 一般、要求分析、設計、コーディング、テスティング、 管理、製品保証、進化の各分野から選りすぐりの原理を紹介していく。 とりわけ以下のような原理が私的には頷けました。 ・文書のない設計は設計とは言わない ・特殊なケースをあまりたくさん作るな ・人のことを第一に考えてプログラムを書け ・すぐコーディングを始めるな ・壊れていないのはら直すな ・保守は開発よりも多くのエラーを作り込む ・この変更は簡単だという信念が正しくない変更をもたらすことが多い 会社の机に置いておきたい一冊です。
Posted by
現場の人間としては201の鉄則として網羅された各解説はある意味、身の回りに起きているだけに面白くも身につまされながら読める
Posted by
これを買ったのは、多分7から8年前。まわりに(当時も今もソフトウェア開発の現場にいますが)すごく薦められて買いました。内容が、端的であるうえにかなり確信をついている内容が多く今でもこの本を読むとうなることがあります。
Posted by
- 1
