いつテストを終わらせるか？ - プログラマの思索
信頼度成長曲線の使い方について、フジハラさんのBlogによいリンクがあったのでメモ。 【元ネタ】 Redmine プラグイン開発 - テストレポートプラグイン開発中 - フジハラボ -- 目指せ！スーパーエンジニア どこでテストをやめるのか？ 日本電気株式会社 川村真弥さん オープンソースソフトウェアにおけるコードの 安定性予測に向けたゴンペルツ曲線の適用 成長曲線（ゴンペルツ曲線とロジスティック曲線） つれづれなる技術屋日記: バグカーブ 対数曲線や二次曲線での近似のお勧め テスト消化曲線とバグ発生曲線の7パターン診断 － ＠IT MONOist プログラムバグの成長曲線とプログラム品質の判定 テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索 信頼度成長曲線の使い道は、テストでソフトウェアの品質が歩溜りに達したかどうかを判定するのに使う。 つまり、テストの止め時は、信頼度成
リスバーガー - Natural Software
CSM研修中に紹介されたリスバーガー、これはみんなに知ってもらいたいなー、と思い探していたら@kanu_さんが教えてくれました。 http://flux88.com/blog/don-t-make-squirrel-burgers/ これを会社の人に訳してもらって、公開の了承ももらったので載せておきますね。 ＃より良い訳があったら教えてください Don't Make Squirrel Burgers あなたのマネージャが席まで来て、話しかけてきます。 「なぁ、ジョー、ちょっといいかい。ヘルプデスクコールの動向をおさえるために新しいシステムを開発したいんだ。ナビゲートしやすいなめらかなユーザーインタフェースで、速くて、SAPの統合も必要だね。」 あなたは、似たシステムがないか熟考します。 「どれくらいかかるかな？」彼が続けます。 もちろん、あなたの本能は、概算して彼に折り返し連絡するよう囁き
ソフトウェア品質の12の属性
システム開発において「品質の向上」という標語がしばしば掲げられますが、 「品質の属性」については無頓着なケースが多いのではないでしょうか。 ひとくちに品質といっても多様な属性があります。 顧客と品質の話で揉めたことはありませんか？ 品質には多様な属性があり、単一の軸で良しあしを決められないという側面があります。 そのため、単に「品質」と言ってしまうと認識に齟齬が生じるのです。 Karl E. Wiegers氏が著書 「ソフトウェア要求」 で挙げた、すべてのプロジェクトが検討すべき12の属性は以下のとおりです。 可用性availability 動作可能時間の指標。システム故障までの平均時間MTTF(Mean Time To Failure)を 平均修復時間MTTR(Mean Time To Repair)とMTTFの合計で割った値。稼働率とも呼ばれる。 効率性efficiency 同じ処理性
コードのクリーンアップ: アジャイルな手法を使用して技術的負債を返済する
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 アジャイルな手法を使用して技術的負債を返済する David Laribee すべてのコードベースには、暗くて恐ろしい隠れた場所や小道があります。非常に脆弱なコード、回帰バグが発生するコード、および処理をたどろうとするとイライラしてしまうようなコードのことです。 Ward Cunningham は、コードの、変更が困難でエラーが発生しやすい部分を金銭的負債ににたとえて、みごとな隠喩を作りました。技術的負債があると、前に進んだり、利益を得たり、"黒字" の状態を維持したりすることができなくなります。現実世界と同様に、安い負債もあります。低リスクの金融商品よりも利率の低い負債です。また、負債をさらに増やしていく高利
品質は作り込むもの - rabbit2goのブログ
ソフトウェア開発において、ありがちな品質対策の例。 テスト作業への人員追加 テスト期間の延長 テスト体制の見直し 経験的に言って、こんな素性の悪いソフトウェアに関わるとロクな事が無い。根本的な作りが悪いソフトウェアを、いくらテストでフォローしようとしてもそれは無理というものだ。出血が続いているからと言って、傷口に絆創膏を貼り続けても何も解決しない。対処療法が効くのはほんのつかの間に過ぎないし、それでカバーできる範囲は極めて限られている。やるべきなのは出血が続いている根本原因を突き止め、その出血を抑えるための施策を取ることだろう。テストによってマイナス10点がマイナス5点に上がったことを指して「品質が改善した」と主張するのは大きな誤解だし、そもそもいくらテストを続けても決してプラスの点にはなり得ない。スティーブ・マコネル氏がCode Completeの中で言っているように、テストは品質を改善
求ム、障害分析アナリスト - rabbit2goのブログ
終了した開発プロジェクトの問題分析を行っている。「バグの源流をたどれ」の如く、なぜなぜ分析で問題の根本原因を探り、抜本対策案をまとめるのが目的だ。さすがに限られた時間内で全障害を検証するのは不可能なので、優先度の高い問題のみをピックアップしてから分析を行う。Tracのチケットに記載された情報を元に、仕様書の記載ミスなら変更前後の仕様書を見比べ、コーディングミスなら該当するコミット状況を確認し、テスト漏れならテスト手順書の記載を検証するといった感じだ。 開発対象も開発者も異なるプロジェクトを見ているけれど、いずれの開発でも共通の傾向があるので面白い。 障害は偏在する 全ての障害が一様に分布するのではなく、特定の機能、開発者、モジュール等に著しく偏って発生することが多い。パレートの法則ほどではないけれど、その偏り方は目に見えてはっきりと分かる程だ。 類似の障害は繰り返し発生する 一つのプロジェ
欠陥を作らないための読書「ソフトウェアの欠陥予防」 - rabbit2goのブログ
「バグの無いソフトを作るためには、そもそもバグを発生させなければ良い」というのはid:rabbit2goの名言だけど、モグラ叩きの如くバグを潰していくだけの開発では、一向に品質は向上しない。そもそも、障害が発生するのは開発プロセスやエンジニアリングに何らかの問題を抱えているからであり、その根本原因を突き止めて直す必要がある。 「ソフトウェアの欠陥予防」はそんな欠陥予防にフォーカスした書籍だ。著者は、ソフトウェア品質に対する取り組みとして「検出、分析、予防」の3つがあるものの、この中では検出に重点が置かれすぎている現状を指摘している。 多くの開発チームは、結果を防ぐことの必要性を認識し、欠陥を防ぐためのさまざまなテクニックを試みています。しかしこのようなテクニックのほとんどは、欠陥検出（テスト）の改善に焦点を合わせたもので、欠陥の予測や予防に焦点を合わせてものではありません。 既存の様々な方
品質を考える読書〜「技術にも品質がある」 - rabbit2goのブログ
モノ作りの品質というと、どうしても製造現場にフォーカスしたもの（品質管理）が多いけど、この本は開発現場での品質（品質工学）を取り上げている。品質工学を毛嫌いする人は少なくなく、知名度や普及度は今ひとつのような感じがする。でも、この本に難しい理屈は無く、品質工学の基本的な考え方やその必要性が平易な言葉で説明されており、初心者でも容易に読み進められるはずだ。 TQM活動は、生産分野から始まり経営分野へと広がりを見せているが、技術開発分野への展開はまだ不十分である。それは、技術そのものに対する理解がボトルネックになっているからである。品質工学は、そのボトルネックを克服し、品質を根本から改善するためのツールの一つである。どのような視点から技術を理解すべきか、製品をどう設計すべきかを追求する方法である。 実績データを活用して信頼性を予測する信頼性工学とは異なり、品質工学は、実績データが存在しない場合
富士通、「新要件定義手法」を確立－要件定義の合意への手引き
富士通株式会社は10月7日、システム開発で重要となる要件定義の課題を解決する「新要件定義手法」を確立したと発表した。同日より富士通が手がけるシステム開発に適用していく。 新要件定義手法は、要件定義における1）要件の品質、2）合意形成の品質、3）マネジメントの品質にまつわる問題を根本的に解決するための3つの方法論を体系化したもの。 要件定義には「誰が要件に責任を持つのか」「経営層－業務部門－情報システム部門の3方向でいかに合意形成するか」「要件の成熟度（内容がどこまでできているか）をいかに把握するか」といった課題が存在する。「ところが実際は、責任所在がはっきりしないまま、合意形成がされないままプロジェクトが進んでいくことがあり、要件定義までに時間がかかったり、下流工程で手戻りが多発したりするケースが多い」（テクノロジーサポートグループ システム生産技術本部 SI生産革新統括部長代理の若杉賢治
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
