ソフトウェアエンジニアリング論文集80'sデマルコ・セレクション の商品レビュー

トムデマルコ,ティモシーリスター【編著】,児玉公信【監訳】,日本技術士会プロジェクトチーム「IT21の会」【訳】

2018/10/23

デマルコ、レスター両巨匠選出のソフトウエア論文集。ワインバーグや、ナッシュ、リッチーなどのソフトウエアの巨人たちの論文が掲載されており、読み応えあり。ただし、私の見地からは、何の役にも立たない論文も多々あり。だめな物は読み飛ばしましょう。

2015/05/12

今から30年以上前の論文を集めたものですが、いずれの論文の最後に記してある「論文の今日的意義」のとおり、今でも読むに値する論文だと思います。

印象に残ったものとしては「合理的な設計プロセス：それを真似る方法と理由」で成果物とそれを生み出すプロセスを合理的に設計することが大事だということは同感しました。

また、Boelm博士の生産性改善の取り組みや、Knuth 氏の TeX への取り組みに見せる個人的なエネルギーには驚嘆しました。

それから、これが一番得たものかもしれませんが、書籍ばかりではなく論文を読みたいという気になりました。情報処理学会で公開されているものから、時間を作って読み、いずれは書く側に回れればと思います。

2014/09/28

結構読みごたえがある．
古典的（と言っても10～20年前だが）なよく引用されるものがまとめられている．
他にも是非選定して欲しいと思うものもあるが，数が限定されているので仕方がないのかも．
ちょっと和訳が微妙で気になるところが無いではないが・・・

2013/01/19

経営.
ソフトウェア工学の超構造化管理　, Gerald M.Weinberg
銀の弾丸はない , Frederick P.Brooks, Jr
ソフトウェアコストの理解および制御 , Barry W.Boehm, Phillip N.Papaccio
ソフトウェア研究についての私見, Dennis M.Ritchie
測定.
ソフトウェア開発見積りのメタモデル , John W.Bailey, Victor R.Basili
方法.
生産性改善のためのソフトウェア開発環境 , Barry W.Boehm
ボックス構造化情報システム ,H.D.Mills, R.C.Linger, A.R.Hevner
STATEMATE:複雑なリアクティブシステムの開発作業環境 ,D.Harel
Pascalの問題に対する一解決=Modula-2 , Roger T.Sumner, R. E. Gleaves
合理的な設計プロセス,David L.Parnas, Paul C.Clements
他の「新しい」分野.
セルフアセスメント手順. 9 , Donn B.Parker ; Eric A.Weiss
TEXのエラー ,Donald E.Knuth

「経産省はITSSなるものを打ち上げたのですが、浸透は十分とは言えません。それは表面的な知識を要求しているからです。」
「Hoareの仕事であるCSP(communicating Sequential processes)やHansenの並列パスカルと比べてどこを改良したのかと聞いたところ、そんなものは知らないというのです。私は驚きました。」
「論文の構成」「参考文献の読み方」「重要語にこだわる」

ソフトウェア費用の理解および制御
論文の後に「本論文の今日的意義」「解説」「コンピュータ倫理と職業倫理」
翻訳者は、
児玉公信
鈴木康介
荒勝俊
石井一夫
宇田川剛
大久保孝殻
尾形芳邦
小山田応一
川手隆義
田吹く隆明
林滋
本田和幸
山野浩
吉川博晴

ご質問される前に
www.senshop.com/book/errata/
book/qa/

2012/05/01

Tom Demarco (Author), Timothy Lister (Editor)が選別した論文集"Software State of the Art: Selected Papers"に採択された31編の論文から、12編がさらにセレクトされた論文集です。

特に、Weingerg, Boehm, Millsがおもしろかったです（すばらしいという意味では12編全てすばらしいものでした）。

ソフトウェアエンジニアリングの歴史は短いもののやはり先人の積み重ねがあって、現在があるわけなので、どんなことが研究済みで結果はどうだったのかについて知ることが重要だとよく分かりました（アジャイルがどんなところから生まれてきたのかといったことが分かります）。

残りの19編の中には、田島・松原による「日本のソフトウェア産業」、「日本のソフトウェア産業の内幕」や、板倉・高柳の「プログラム規模見積もりのモデルとその評価」という当時の日本人の論文が採択されているようです。

2009/10/04

論文だけあって表現が難しい。理解できない箇所多い。

複雑性
規模拡大に伴って複雑性が非線形的に増加する。その複雑性のため、チームメンバー間の意思疎通が困難になり、その結果、製品欠陥やコスト超過、スケジュール遅延がもたらされる。
複雑性のためプログラムの状態を理解することはもちろんその状態を記述することも困難。
構造の複雑性
→副作用なしに拡張できない。可視化されない。セキュリティ上の弱点の温床となる。
全体理解を難しくし、概念の統一性を妨げ、未処理事項の検出や管理を難しくしている。
引継ぎや理解には多大な労力が必要。