清水吉男のレビュー一覧
-
-
Posted by ブクログ
「入門+実践」要求を仕様化する技術・表現する技術
改訂第2版
仕様が書けていますか？
著：清水 吉男
出版社：技術評論社
良書、どろくさいシステム開発のなぜを考える書です。難易度が高いです。
本書の目的は、コンピュータシステムの構築の要求を適切に表現することで仕様を引き出す方法を語ってくれています。
本書を読めば、仕様変更率を５％以下に抑えることができ、仕様関係のバグも激減し、当初の納期通りにシステムができあがる、という、なんというありがたい書なのである。
要求の仕様化技術は、ソフトウエアエンジニアリングの技術の中の一部にすぎない
仕様化技術を生かすために、設計技術、見積技術、スケジ -
-
-
-
-
Posted by ブクログ
改善や改修に特化した開発プロセス方法が記載されている。ソフトウェアの話として書かれているが、機械や電気系の人にも役立つと思う。特に、組み込み系をやられている方は、殆どの場合、既存製品のモディファイが開発となると思われるので、参考として手にとってはいかがだろうか？
XDDPと呼ばれる筆者が考えた方法論が書かれている。背景まで丁寧に書かれているので、手っ取り早くノウハウを得たい人にはやや冗長に映るだろう。基本的に本手法の肝は、要求からの漏れチェックのための視覚化と要求からの変更内容を導く思考過程の可視化だと思った。よって、その場限りのコード改修と異なり、レビューがしやすくなる上、設計者の従来機種 -
-
Posted by ブクログ
清水さんの本を読んだのは、これで3冊目です。
冗長とか読みにくいとかいう感想は一緒です。でも、まずは、それを書いておかないとね。
そのように、本としては、いまいちな本書がこんなに読まれているのは、そこに卓越したオリジナリティと実用性があるからだと思います。
★★★
本書では、清水さんのUSDM（Universal Specification Describing Manner）について書かれています。
改訂版なので16ページ増えています。
USDMは、要求仕様書の書き方です。仕様書というからには、
「仕様書」は「Specification」の日本語ですが、どのような状態か -
Posted by ブクログ
ソフトウェアエンジニアリングの教科書には「新規開発をどう上手くやるか」について書いてありますが、私たちが日々格闘している「派生開発」については「保守」としてひとくくりにされ、十分な記述がありません。
もちろん、新規開発のノウハウが役立つ部分もあるのですが、筆者の清水吉男は「派生開発の現場では、時間に追われバグを見つけ次第直すという間違ったプロセス」にメスを入れています。
つまり、派生開発においては、
o 変更要求仕様書
o トレーサビリティ・マップ
o 変更設計書
を作るプロセスを提案しています。これらは、実践的で非常に役立つノウハウと思います。口語調で話が整理されていないためちょっと -
Posted by ブクログ
ネタバレ世界中で，システム設計の現場では、「新規開発」より、「派生開発」としての動いているシステムの変更や機能追加が多い。
その点に着目した著者の経験が凝縮されている。
派生開発の場合に何が課題になるかの仕立てをうまくしている。
仕様をどうやって明確にしていくかについての知見が豊富にある。
仕立て(tailoring)をしているだけでなく，清水吉男さんのよいところは，現場にあわせた着付け(fitting)もできることだ。
決めたことを，決めた通りにやるだけなら，能力のある技術者はいらないかもしれない。
どういう制約条件のもとで決めたことか，条件が変わったらどうするかを考える能力があるかどうかが課 -
Posted by ブクログ
ネタバレ何を作るとよいかということをここでは「要求」という漢字2文字で表現しています。仕事によっては「制約」という場合もあります。
これらの制約を仕様として記述するのが不十分だと，
何を，どういう条件で試験すればいいかが分からないため，
結果として，何度も作り直しをしないといけないこともあります。
システム設計の基本的なところを，清水吉男さんの経験に基づいて、うまく整理しているところがよいでしょう。
参考文献も，海外でも流通している基本文献をあげているので，
国際的な展開に役立てることもできるでしょう。
2011年の11月には，上海で開催された世界ソフトウェア品質会議でも関連発表があったので， -
Posted by ブクログ
・良書。久しぶりに自分でも試してみようと思ったソフトウェア開発プロセスの本。
・個人の思い込みや勘違いを防止する為に、レビュー（他者の視点＝組織力）を重視する所は、ワインバーグのエゴレス方式に近い。 ≪参考≫ジェラルド・M.ワインバーグ(著)「プログラミングの心理学―または、ハイテクノロジーの人間学」
・設計に時間を掛ける事で、事前にバグを防ぎ、その結果、プログラム修正の時間は減らせるという考えは、デマルコの思想に近い。 ≪参考≫トム・デマルコ (著)「デッドライン―ソフト開発を成功に導く101の法則 」
・XDDPの成果物は下記の通り。レビュー時に他者の気付きがされ易いように工夫されている -
-
-
Posted by ブクログ
ネタバレ最近、新規プロジェクトが少なくなってきたと聞く。
そうであれば、今後は、既存システムの改修案件が増えてくるであろうということで、読んでみた本。
よくあることだが、ソースを書いた人と保守する人は別の人。
だから保守する人はどこを直せばよいのか、わからないことがある。
そんな時、「部分理解」な人でも、できる限り手戻りなく修正するプロセスを確立しておけよってことがこの本の趣旨。
ごもっともです。
主軸は、レビューの大切さ。そしてレビュアーに気づいてもらうように（アンカー効果が働かないように）、変更内容の事前準備をすること。
その方法として、手順は５つ。
・変更内容とその理由を記載した、変更要 -
-
-
-