本エントリは、「要求のブレを経験した人は78%、特定の技法がブレを小さくするという研究結果」で公開したものを一部改変している。Journal of Software Maintenance and Evolutionに掲載のReducing the risk of requirements volatility: findings from an …
"Prioritizing Unit Test Creation for Test-Driven Maintenance of Legacy Systems"というタイトルの論文が10th International Conference on Quality SoftwareでEmad Shihab, Zhen Ming Jiang, Bram Adams, Ahmed E. Hassan , Robert Bowermanにより発表さ…
先週、Twitterの被リスト数やリスト表示が一時的に表示されなくなった。Twitterには、ある機能を一時的に無効にする機能があるそうだ。本エントリは、「Twitterの「ダークモード」はリリースと開発の分離の幕開けになるか？」で公開したものを一部改変してい…
本エントリは、オルタナティブブログのこのエントリを少し改変、再掲したものです。N. Nagappan, M. E. Maximilien, T. Bhat and L. Williams: Realizing quality improvement through test driven development: results and experiences of four industrial…
ディベロッパーサミット2010の1セッションとして、ソースコードリーディングワークショップ in デブサミ2010の進行を奈良先端大 保田と私で担当する。1/30に実施したソースコードリーディングワークショップ2010と類似するが、読解時間の「見積り」という点…
Javaで書かれた1500行程度のGUIアプリケーションのバージョンのnを理解し、バージョンn+1との差分19種類を適用してよいかどうかを答えていただく。バージョンnを理解するための所要時間、読み方の戦略、差分を理解するための所要時間、判断の戦略を答えてい…
ソースコードの読解力を自分で試しつつ、その結果を我々の研究にも役立てようとするWebページを用意した。オンラインでコードを読んでいただき、結果をメールで送信いただく。メールアドレスはフリーのものを使っていただくことができ、匿名のまま実施できる…
レビュー／インスペクションの時間を短縮したいという方向け。7月にソニーの永田氏が実施されています。今回は、普段ソフトウェア設計、プログラミング、プロジェクトリーダ・マネージャをされている方向けに以下の要領で実施します。お気軽にご参加ください…
ここで紹介していたソフトウェアインスペクションワークショップ2009を7/2に開催した。その内容は、atmarkitのニュース記事("レビュー"とは、責め合うものではなく、品質を高め合うもの)になった。定員60名を大幅に上回る申込みをいただき、開催10日前にして…
レビューがうまくいかない理由の1つに、参加者(レビューア)の同意がないということが挙げられる。 たとえば、以下のような感じ。これを解決するための方法として、計画と納得してもらう方法を紹介した。詳細はこちら。中堅くらいの方であれば目にしたことが…
IBMの方に声をかけていただき執筆する機会をいただいた。記事はこちら。atmarkitの連載記事（現在、1回目のみ公開中、近々2回目も公開予定）のほうはここ数回は入門的なものになっているが(これからこちらもマニアックになる予定)、developerWorksのほうは、…
実際に手を動かしながらソフトウェアレビューをし、実感して得られたことを会社の垣根を越えてグループでディスカッションする。グループ毎のディスカッションの内容を受けて、参加者全員でパネルディスカッションを通じて明日に活かせる内容を考える。その…
ソフトウェアレビューの記事がatmarkitに掲載された。記事は連載の予定で、初歩的なところからだんだんと高度になっていく予定だ。タイトルは「“確実な記録”こそが、品質・コストに貢献する」。連載の1回目になる。記事はここに掲載されていく。1回目は初歩…
あまりお目にかかれない、ソフトウェアレビュー、インスペクションの特集がThinkITで3月いっぱい続く。 第5週目をまとめてみた。 インスペクションを自在にカスタマイズ（Frank Elberzhager Institute for Experimental Software Engineering: 訳: 森崎 奈良…
あまりお目にかかれない、ソフトウェアレビュー、インスペクションの特集がThinkITで3月いっぱい続く。 第4週目をまとめてみた。 インスペクションで何を指摘するべきか（森崎 奈良先端科学技術大学院大学） すぐに使える！レビュー効果向上の秘訣（安達氏 H…
あまりお目にかかれない、ソフトウェアレビュー、インスペクションの特集がThinkITで3月いっぱい続く。 第3週目をまとめてみた。 技法の分類とテンプレート（応用編） （森崎 奈良先端科学技術大学院大学） パスアラウンドレビューの適用事例（平野氏 オムロ…
あまりお目にかかれない、ソフトウェアレビュー、インスペクションの特集がThinkITで3月いっぱい続く。 第2週目をまとめてみた。 技法の分類とテンプレート（基本編） （森崎 奈良先端科学技術大学院大学） レビューの質をモデル化する！（デンソークリエイ…
あまりお目にかかれない、ソフトウェアレビュー、インスペクションの特集がThinkITで3月いっぱい続く。レビュー、インスペクション好きにはたまらない企画だろう。私は月曜日を担当している。かなり基礎的なことから最後は海外事例を紹介するまで、一気に駆…
本エントリはオルタナティブブログの2008/9/8で公開したものを一部改変したものである。 - インスペクション、レビューの大家Tom Gilb氏による基調講演"Agile Inspections: reviews by sampling and measuring defects"を、9/4, 5に東洋大で開催されたソフト…
本エントリはオルタナティブブログの2008/9/4で公開したものを改変したものである。 - ソフトウェア開発に携わり、周りから職人と称される複数のエンジニア、自身の技術をとても大切にしている複数のエンジニアから聞いた話。それなりにニーズがあるのではな…
本エントリはオルタナティブブログの2007/6/13, 2008/3/13で公開したものである。 - □ ICSE2007での講演 by Mary PoppendieckICSE2007のセッションの1つで、agile contractsの例としてトヨタとサプライヤの良好な関係について語られていた。トヨタがbest con…
本エントリの元ネタは2007/8/23にここで公開したものである。 - ここ半年くらいいろんなところで話題になっていて気になっていることがある。決め事、プロセス、プロジェクトルールでどこまで一定の品質、コスト、開発期間を守れるかということである。たと…
本エントリは2008/10/27の元ネタはここで公開済みのものである。 - Protocol Buffersという通信用フレームワーク、ミドルウェアをご存じだろうか。Javaや他のオブジェクト指向プログラミング言語のライブラリに出てくるストリームの概念を実装したフレームワ…
本エントリは2007/7/3にここ、2008/10/13にここで公開済みのものを加筆・修正したものである。 - コーディング、テストにおいて、バグを見つけたら修正して修正箇所の確認と想定できる範囲内の回帰テストを実施するのが普通だろう。修正箇所が1箇所だと言い…
本エントリは2008/8/11にここ（オルタナティブブログの私のエントリ）で公開済みのものを加筆・修正したものである2008年3月くらいに、businessweekのアップルの設計プロセスの記事を読んだ。記事にある「Paired Design Meetings」というのを読んでビビっと…
本エントリは2008/3/31にここ（オルタナティブブログの私のエントリ）で公開済みのものを加筆・修正したものである - テストの一部を委託し委託先から1週間単位でレポートを提出してもらっていたものを、バグを見つけ次第委託元のバグ管理システムに直接入力…
本エントリは2007/6/8にここ（オルタナティブブログの私のエントリ）で公開済みのものを加筆・修正したものである - salesforceはもう説明の必要もなくなってきているのではないかと思うが、クラウドコンピューティングのリーディングカンパニーの１つだ。ソ…
本エントリは2008/7/31にここ（オルタナティブブログの私のエントリ）で公開済みのものを加筆・修正したものである。 - オープンな（守秘義務のない）レビュー技術の適用評価実験をしていて感じたこと。このエントリとも関連する話だ。レビュー指摘で「その…
本エントリは2008/6/23にここ（オルタナティブブログの私のエントリ）で公開済みのものである。 - 詳細がわかっていない大量のドキュメントやコードの潜在的欠陥を短時間で指摘する方がいる。私はそのような方を「大食いレビューア/インスペクタ」と呼んでい…
本エントリは2007/11/19にここ（オルタナティブブログの私のエントリ）で公開済みのものである。 - 長期にわたる保守を前提としたソフトウェアを開発していく場合、保守性(拡張性)、信頼性のトレードオフが問題となる。保守性は長期的、信頼性は短期的な観点…
