ソースコード変更波及解析の8カテゴリ - どのくらいご存知ですか？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
変更波及解析は既存のソフトウェアに変更を加えたら、どの場所に影響を与えるかを調べる方法です。影響は本来の意図であるものや本来意図していない副作用も含みます。変更波及解析が不十分だとデグレードする場合があります。 Steffen Lehnert氏のA Review of Software Change Impact Analysisという文献調査をしたテクニカルレポートがここで公開されています。調査対象の文献が182件ある大きめの調査です。網羅性や調査方法に関しても客観的な基準を与え、洗練した上で論文として公開されるのかもしれません。 このテクニカルレポートで紹介されている影響波及解析のカテゴリの一覧は以下のとおりです。10カテゴリのうち9番目は組合せ、10番目は「その他」なので、実質的には8カテゴリあります。どのくらいのカテゴリをご存知ですか？ いずれも完璧とはいかないまでも、変更波及解析
コードレビューやテストの優先順位付けに統計モデルが役立つか実際に試してみた論文：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
プログラムの規模が大きくなるとソースコードレビューやシステムテストをどこからはじめてよいか優先順位が付けにくくなります。優先順位は様々です。たとえば、欠陥を見逃した場合にリスクが大きくなるところからはじめる、多くのユーザが使う基本機能の正常動作からはじめる、依存関係が多く様々な部分から参照される共通モジュールからはじめる、今後も長期にわたって保守、拡張する部分からはじめるといった方針が考えられます。もちろん、できた部分から順番にという順位付けもあるでしょう。 優先順位のつけ方の一つとして、ソースコードの特徴から不具合がありそうなクラス、モジュール、メソッド、関数を予測する技法としてFault-proneモジュール予測という技法があります。過去の不具合のデータとソースコードの特徴を表わす数値をモデルに与え、不具合が起こりやすいソースコードの特徴を学習させます。数値は関数、メソッド、クラスとい
本質的でないレビュー指摘を減らすための試行を紹介した日経ITproの記事：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
要求ドキュメントや設計ドキュメントをレビューにおいて、誤字脱字の指摘の割合が高く本質的な欠陥の指摘が少ないというのは、どのような組織、プロジェクト、チームにおいても共通の悩みでしょう。 そのようなレビューを改善することを目的として、レビューで検出すべき欠陥の条件を変えて実務者の方にご協力いただいて検出結果を比較する試行をしました。 結果は論文で報告しています（S. Morisaki Y. Kamei K. Matsumoto: Experimental Evaluation of Effect of Specifying a Focused Defect Type in Software Inspection: PDFはこちらから）。ほぼ同じ内容の記事を以前に日経SYSTEMS（雑誌）に寄稿していました。昨日Web記事として日経ITproのサイトにも掲載いただきました。こちらから読めます。
Fault-proneモジュール予測：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
バグが含まれていそうなソースコードモジュールを予測することをfault-proneモジュール予測と呼びます。予測の単位であるモジュールはソースコードファイルであったり、メソッド、クラスであったりします。過去の傾向に照らし合わせて、予測する方法が一般的です。 たとえば、規模が大きいファイル、メソッド、クラスにバグが含まれているという傾向から予測したり、特定の（一般には複雑なロジックを持つために実現が難しい）機能を実現するソースコードという傾向から予測したりします。ここ（本ブログの過去エントリ）でも紹介しましたが、過去に何度も改変されているとバグを含む可能性が高いという経験則を使っているものもあります。改変担当者による予測もあります。 過去にバグが含まれていたモジュールとソースコードメトリクス等の特徴を統計モデル等を使って学習させ、それ以外のソースコードにバグが含まれているかどうかを学習したモ
だんだん開発作業が重くなっている？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
ここ最近、細かいエビデンス、コンプライアンスを取っ払ったほうがいいという話やエビデンス、コンプライアンスのために負荷が高まって開発効率に影響を与えているという話を見聞きしたのでエントリにしています。私の主観によるもので全体傾向と言えるほどではないかもしれません。ガバナンス不況という指摘もかなり前からあるように思います。しかし、最近見聞きしたものは私の感触と一致する表現が多いように思いました。これが今回のエントリを書いたきっかけです。 まず見聞きした内容を私が見聞きした順番で紹介します。 1. 講演 （スクウェアエニックス社長 和田氏が中央大学で「ゲーム産業の業態変化」というタイトルで講演された内容） http://www.square-enix.com/jpn/news/speeches/20111125/page18.html 「ヴィジョンがないままに部分部分に中途半端にチャチャをいれた
「山浦恒央の“くみこみ”な話」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
山浦恒央の“くみこみ”な話（181）： イチから全部作ってみよう（12）要求仕様書の異常系を階層構造を使って洗い出す ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第12回は、これまでに作成したたこ焼き屋模擬店の要求仕様書における異常系の洗い出しを行う。（2024/9/18） 山浦恒央の“くみこみ”な話（180）： イチから全部作ってみよう（11）たこ焼き屋模擬店の要求仕様書を抜け漏れなく作る ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第11回は、前回「機能分割」を用いて作成したたこ焼き屋の模擬店をの要求仕様書を抜け漏れのないようにブラッシュアップする。（2024/8/22） 山浦恒央の“くみこみ”な話（179）： イチから全部作ってみよう（10）トヨタとたこ焼き屋模
ITmedia Biz.ID：失敗しないプロジェクトマネジメント――Appleやはてな、Googleに学ぶ3つのヒント
失敗しないプロジェクトマネジメント――Appleやはてな、Googleに学ぶ3つのヒント：デジタルワークスタイルの視点 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。これらを管理しようとすればするほど悪いスパイラルに落ち込みます。Appleやはてな、Googleなど、注目企業ではどのようなマネジメントを行っているのでしょうか。 「完璧に管理しようとすればするほど、プロジェクトは失敗する」という悪いスパイラルが存在します（2月21日の記事参照）。そこで今回は、どのようなプロジェクトマネジメントをすれば、プロジェクトを失敗させないようにできるのか考えてみたいと思います。 プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。前回はそれぞれを完璧に管理しようとしていましたが、今回は考え方を180度変えてみましょう。それぞれの要因を最初からなくしてしまうのです。 失敗しない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
