インスペクタビリティ - 検証容易性：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソースコードや設計書等、レビュー（インスペクション）対象の読みやすさを向上する試みがある。On Inspection and Verification of Software with Timing Requirements（IEEE Digital library）という論文では、並列プログラミングのタイミング等、実行タイミングが問題になりやすいソースコードをレビュー（インスペクション）しやすく方法を提案している。 並列して実行されるプロセスのソースコードを実行する時間軸（タイミング）に沿って可視化し、ソースコードを横方向に眺めると、同時に実行されるソースコードをわかりやすくする。たとえば、あるプロセスAでステートメントA1, A2, A3, A4、プロセスBでB1, B2が実行され、A1とB1、A3とB2が同じタイミングで実行される場合、以下のようにソースコードを可視化する。 プロセス
コードレビューでの指摘分類FunctionalityとEvolvability、その比率の調査結果：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
"What Type of Defects are Really Discovered in Code Reviews?"というタイトルの論文がIEEE Transaction on Software Engineeringに掲載されている。分量の多い論文（2段組で20ページ弱、参考文献が70件以上）だが、示唆も多い。視点は実務に近いように思う。 論文は、ここ（IEEE digital library）から購入できる。また、ここ（Helsinki University of Technology）からダウンロードできる。詳細は原典を参照いただければと思う。 functionalityとevolvabilityは論文で提案されている欠陥分類。700件超のコードレビュー指摘結果と過去の研究結果とを踏まえて、大まかに2種類に分類していて、次のとおり。 functionality欠陥 機能欠陥の指
ソフトウェアレビューでは問題点の指摘だけでなくよい点も指摘したい（コストの範囲内で）：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
国際会議、国内会議にかかわらず研究論文のレビュー（査読）書式があり、多くの書式に「積極的に評価できる点」という項目がある。査読者はここにレビュー対象の論文の評価できる点を記入する。 査読の主目的は、その論文を採録とするかどうかを決めることにあるが、そうすると問題点の指摘に目が行きがちになってしまう。「積極的に評価できる点」の項目には、これを抑止する機能がある。よいものが公開されなければ、その分野全体が沈んでいってしまうからだ。 通常、著者がいない場で実施される論文の査読であっても「積極的に評価できる点」が存在する。ソフトウェアレビューは、問題点の指摘と修正が主目的の場合が多いが、レビュー対象の作成者がいる場では、できるだけ「積極的に評価できる点」も指摘すべきだと思う。 私の新人時代もレビューとなると気が重かったのだが、その理由は「これはダメ」がリスト化されるからだったように思う。「ここは伸
ワークフローがない状態でツール利用を強制されるとつらい：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ソフトウェア開発に限らずだが、定着しているワークフローや洗練されているプロセスの実行を支援するツールは非常に便利で、利用しているとスカッとする。ワークフロー支援が無駄なくビシッと決まっている支援ツールを利用したことがあれば、感じたことがあるだろう。 逆にワークフロー、プロセスが存在しない、あるいは今一歩という状態で支援ツールが介在すると当事者はかなり面倒に感じてしまう。結果として支援ツールがいまいちという結論になってしまうことが多いが、現実には、支援ツール自体のまずさの前に支援ツールと既存のワークフロー、プロセスの不整合が原因となっている場合がある。 あるソフトウェア開発プロジェクトでの開発支援ツール導入の際に痛感したのがきっかけだが、共同研究でパイロットプロジェクト導入済の状態からより多くの関係者やプロジェクトに展開していく場合に、注意している。 とにかくツール導入だけを目的にしてしまう
SQLのテストファースト：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
どのようなものを想像されるだろうか？（主に）単体テストを自動化するためのフレームワークxUnit（xにはプログラミング言語の名前に関連した文字が入る）がある。データベース用にDBUnitというフレームワークがある。テストプログラムとそれによってテストされるプログラムのプログラミング言語は同一のものが使われることがほとんどのため、「SQLのためのテスト自動化フレームワーク」と聞くと、テストプログラムまでSQLで書かれているのではないかと勘違いしてしまいそうだ。 SQLのテスト自動化用のフレームワークにDBUnitというものがある。JUnitをベースにしてあり、テストコードはJavaで書く。データベースを事前に定義した初期状態にする → テストを実行する → 実行結果を期待する結果と比較 → DBの状態を元に戻す、というのが大まかな流れだ。エクセルファイルを使ってテスト用のテーブルの内容を定義
グローバルスタンダードに振りまわされた20年となぜかうまくいくモチベーション向上：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
「夏のソフトウェアプロセス改善セミナー in 大阪」に参加した。午前中は2つの講演、午後はチュートリアルという構成だった。ここでは午前中2つの講演（ご講演順）を紹介する。 森田祥男氏（ソニーグローバルソリューションズ）「プロセス改善の真髄 ～ 日本のソフトウェア産業の発展にむけて ～」（SPI Japan 2003最優秀発表賞受賞） 阪本太志氏（東芝デジタルメディアエンジニアリング）「8年目のSPI ～ 継続的に改善するための秘訣 ～」（SPI Japan 2006プログラム委員長賞受賞） 私が印象に残った点は以下のとおり。 無用なルールの押し付けはダメ。 パートナ（派遣）さんによる人材確保の割合が高くなっている、後輩や部下が少ない年代の存在など、品質に関する知識の伝承を阻害される原因が増えている。 阿吽の呼吸で成り立っている日本企業にISOベースのドキュメンテーションの文化、責任と権限を
大食いレビューア - 食べ物ではなくソフトウェアレビューで -：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
詳細がわかっていない大量のドキュメントやコードの潜在的欠陥を短時間で指摘する方がいる。私はそのような方を「大食いレビューア/インスペクタ」と呼んでいる。ご本人の前で「大食い」は失礼なので、呼んでいるのは私の心の中のつぶやき程度であるが。読者の身の回りにもいるのではないだろうか。 けれども、私はまだ大食いレビューアに関する報告や文献をみつけられていない。多くの文献では、レビュー対象をきっちり理解するフェーズ、それに基づいて指摘をするフェーズを前提として書かれている。理解するスピードや指摘する時間の長さを具体的に示している文献もあるが、私のイメージする「大食い」とはかけ離れている。詳細がわかっていない状態での大食いレビューアについて公開されている報告や文献があれば紹介していただければと思う。 大食いレビューアの観察がしたくて、被験者になっていただきたいとお願いをしたことがあるが、コンサルタント
影響力のあるアルゴリズム：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
5/20のgoogle blogの最後あたりにGoogleの検索アルゴリズムがここ数ヶ月で変更されることを示唆するような記述がある。もしそうだとすると、ものの売れ行きや知名度などに影響が出るものもあるかもしれない。 アルゴリズムといえばリストをアルファベット順や数値順に効率的に並び替えるものだったり、大規模な科学技術計算をするためだったり、将棋やチェスといったゲームのためのものであったりした。不可能を可能にしたものも多く、その影響力は非常に大きいといえるだろう。 しかしながら、別の種類の影響力をもつ（ビジネスを動かすような）アルゴリズムというのができつつあると言えるように思う。冒頭のGoogleや証券におけるアルゴリズム取引（事前に条件を設定しておき、条件に応じて株式を売買する）もこれと同じカテゴリに入るのではないだろうか。Amazonの推薦アルゴリズムもそのようなものの1つといえるのかも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
