2013年1月1日火曜日

初めて学ぶソフトウェアメトリクス

正月も原稿モードで「初めて学ぶソフトウェアメトリクス」をふと読み返している。下記転載

そこである会社の見積りとは
■プロジェクトチームの規模が決まっている
■会社の上層部から押し付けられた日程がある。この開発日程は神の声と同じで、無条件に飲まねばならない。
■この2つの値の積を工数として。

「自分で自分のプロジェクトの日程をきめるなんて贅沢なことはできません勝手にふってくるんですから」

ってなふうな記述がある、なんかどっかの国のほぼほとんどの会社のことのような気が。。。

そしてその次の章のタイトルが「頭を使えば道は開ける」です。


まあいかに世界中のソフトウェア開発のほとんどが知的労働ではなく労働集約型産業なのですね。


2012年12月23日日曜日

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

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

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


CodeSonarでは2272個のGlobal variable declared with different typesがあるらしい。でもCodeSonarはヘッダーにあると、それをincludeしているCファイルで全部警告でちゃうから、この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.
なんていわれているぜ!


2012年9月23日日曜日

非機能要求: 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と2つに分かれていると考えている。ライセンス問題はconstraints, パフォーマンスはquality attributes。

2012年8月12日日曜日

テスト: How Google Tests Software

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

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

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

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

2012年7月7日土曜日

書評

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

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


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

本にかけなかったこと1

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

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

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

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

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