あのトヨタのレクサスの事故

故あってアメリカで起こったトヨタの事故リポートを見ている(http://www.nhtsa.gov/UA)。NASAが作っただが、おもしろい（もちろん学術的に）。正月暇があればずっと読んでいたい（まあ暇じゃないから読めないと思うけど）。

CodeSonarとCoverityの解析結果とかすごーい私には役にたつ。


CodeSonarでは2272個のGlobal variable declared with different typesがあるらしい。でもCodeSonarはヘッダーにあると、それをincludeしているＣファイルで全部警告でちゃうから、この2272はまったく信用できないということは、当然リポートには書いていない。

Coverityが出す警告数は信頼できる。そしてその警告はすごく少ない。芸術レベルである。さすがトヨタさん！

でもMisraもチェックされているのだけど、まあまあ守ってるね。アメリカンなPower of 10もチェックされている（なんかこれはアウエーな規格なので、トヨタにとってはかわいそう）。

グローバル変数については
The Camry05 software code structure relies on the use of a single large memory space that is shared among all tasks, with unrestricted access.
なんていわれているぜ！

非機能要求: Architecture Quality Revisited

2012年6月号　IEEE Software

Architecture Quality Revisited, by Frank Buschmann

13人のスペインのアーキテクトのインタビューの結果（すくねー、そしてスペインかよー！という話はおいておいて）。

アーキテクトが非機能要求で気にするトップは

1. ライセンス問題（きっとGPLとか。。。）
2. パフォーマンス
3. ユーザビリティ
4. セキュリティ
5. 技術的ポリシー
6. Availability


まあまあ、そういう結果かー。ちなみに彼は非機能要求はconstraintsとquality attributesと２つに分かれていると考えている。ライセンス問題はconstraints, パフォーマンスはquality attributes。

テスト: How Google Tests Software

必要が生じてHow Google Tests Softwareを読んだ。まああまり構成がされておらずいい本ではない。Googleがどのようにcloudアプリやシステムを作って、テストして短いライフサイクルで出しているかを知りたかったのだが、まあけっこういいかげんにやっているのがわかった。

抜群に頭のいい人しか雇わない組織だとそういうふうにできるのかなと思ってします。

James君が書いているのだが、やつの文章はIEEE Softwareとかに書くときは抜群なのだが、長い文章は構成が変なんだよねー。きっと頭が良すぎるから、下々の人の理解力をわからないんだろうなー

ただちなみに奴の英語は天才的であるので、英文を勉強する人は参考にするといい。外人だからといって全員がうまい英語を書くわけではない。そりゃ日本人だってかなりほとんどの人がいいかげんな日本語を書くと同様に、アメリカ人のかなりの人の英語はいいかげんだ。でも彼の書く文章はほんと、すごいんだ。

Government Guidelines for Agile Adoption

時間があれば、ちょっと紹介しましょう。悪い取り組みではない。

http://www.infoq.com/news/2012/07/agile-in-government;jsessionid=F4F5BC1AB38C39DFA759ECA46B8A200B

書評

■http://booklog.jp/item/1/4798125407
おおむね好評！

■　http://book.akahoshitakuya.com/b/4798125407


■　http://itengineersbook.seesaa.net/article/277108550.html
「誤字や濁点の位置がおかしいな。。」あれ？結構推敲したんだけどなー

本にかけなかったこと１

塩梅。
塩梅は非常に日本語的である。英語でどういうのか想像できない。まあ日本人だから日本語でわかればいい。

塩梅というのはプロジェクトを進める上でとても大事だ。でもそんな抽象的なことを本に書くと怒られるのでやめた。うまくいかないプロジェクトはこの塩梅ができない。

たとえばCMM/CMMiのlevel 5なんていうのはやりすぎで、塩梅としては極端である。理解できないぐらいのたくさんのドキュメントと理解できないぐらいのたくさんのお約束事と、作業時間がとれないほどのたくさんの会議と、どうでもいいたくさんのステークホルダー。

逆に極端なぐらいな放任主義もまた塩梅てきにはよくない。

もしろんこの塩梅について学者がとりくむことはない。なぜなら論文にならないからだ。

正誤表

言い訳

私の本は常に参考文献が多い。そして、説明が少なくそして解説を参考文献丸投げといわれ方をするケースが多い。
個人的にはちゃんとどの本も参考文献の本質を書きたい気持ちはある。しかし、それを書きはじめると、２００ページという書籍の標準サイズを大きく超えてしまう。たとえばこの本でも１０００ページは優に超えてしまう。１０００ページの定価一万円本を皆さん買ってくれるでしょうか？そして読んでくれるでしょうか？（重すぎる）。なので泣く泣くこういった簡易的な説明になってしまいます。

最近はネットが進んでいるので、参考文献を手に入れやすいようになっています、なのでホント皆さん参考文献を紐解いて欲しいです。そのためにもIEEE softwareを中心にした参考文献構成にしました。IEEE softwareはどこでも手に入る質の高い文献です！

ペンネームについて

まずペンネームについて。
私のペンネームをを不思議がってなぜ勝呂暖生になったの？と聞かれるようになった、勝呂は母方の性でからとった。暖生は子供の名前が「暖」なので、一緒にすると後々子供に怒られると思い暖生としたのだ。たいした理由ではない。


ちなみに野球好きの人は知ってると思うが巨人のコーチの勝呂 壽統はいとこである。私と同様なかなか嫌なやつである。

スタート

知識ゼロから学ぶソフトウェアプロジェクト管理 

のブログです！