ソフトウェア開発で見積もりのための定量化はできないんじゃない？ - うさぎ組
素人がそう思ったよ。間違っていると思うよ？入門しようと片足つっこんでいるときの独り言だよ？的な。でも、こう思っているよ？的な。 メトリクスとかをふくむ定量的なデータは傾向を測るものであって、特定チームの特定期間にしか使えないというもとに活用出来ると思った。 根底にあるのは「僕は1年前と同じようなコードは今では書かない。」のような「以前よりもっと綺麗な設計/実装ができる」というのがあります。 だから、例えば行数でも相対値でも違うものになる。 行数：コードの行数。コピペがないコードだとしても設計方針でまるで違ってくる。 ストーリーポイント：実現するための相対的なコスト見積もり。 他にもいろいろあると思うんですけど、きっとどれもが他人(成長する前の自分含む)と比較しにくいものだと思うのです。常に変化していく。 例としては(経験による感覚)、5,6人以下固定チームで2ヶ月目から9ヶ月以内くらいのチ
バグ修正のための変更の40%が新たなバグを混入するという研究結果 - Googleのバグ予測方法との共通点：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
Googleで実施されているというバグ予測の方法がブログで公開され（こちら）、ツールも利用できるようです（こちら）。Publickeyの記事での紹介で端的に紹介されていますので、時間がない方にお勧めします。ソースコードの変更（コミット）履歴から高い頻度でバグ修正されているコードは今後もバグが出る可能性が高いというものです。 類似の研究結果がたくさん報告されているので、この分野の研究者の1人として紹介したいと思いエントリを書きました。興味のある方には本エントリ末尾に示すこの分野の論文も読んでいただきたいです。 一例として2000年にICSMで発表された以下の論文を紹介します。 Mockus A, Votta LG. Identifying reasons for software changes using historic databases. International Conferen
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
