＠IT：不具合追跡でよくある間違い
第8回「ソフトウェアの不具合を追跡するには」では、不具合報告書のライフサイクルと状態、処理方法について説明しました。今回は、不具合報告書に記述すべき項目を紹介します。また、トリアージという考え方についても紹介します。 不具合報告書に記載すべき項目 不具合報告書の書式に用意すべき項目には、次のようなものがあります。 不具合報告書のID番号 件名 製品名 状態と処理方法 サブシステム名 各担当者名 不具合が再現したバージョン／ビルド番号 不具合を解決｛する|した｝バージョン／ビルド番号 環境 深刻度と優先度 再現性 再現手順 添付資料 回避方法 履歴／コメント これらの項目について、詳細に見ていきましょう。 不具合報告書のID番号（ID） ユニークなIDを記入する項目です。不具合（報告書）を一意に特定できるように、不具合報告書には通しの番号を付けます。同じ書式でたくさん書かれる文書には、どんな
＠IT：開発プロセス再入門（1）
下流工程における開発プロセスの復習 昨今、開発プロセスについての関心が大変に高まっています。しかし、開発プロセスに関する文章をいくつか読んでみると、抽象的で分かりにくいものが多く、具体的にどうしたらいいんだろうとお考えの読者もおられるのではないでしょうか。開発プロセスとは、もっとずっと具体的かつ実践的なものであるはずです。 本連載では、ソフトウェアの開発プロセスを具体的に、特に下流工程に主眼を置いて説明していきます。あえて上流工程に着目しない理由は、これが非常に難しい仕事だからです。要求仕様の獲得と分析はドメインによっても難易度が異なりますし、ソフトウェアの設計は属人的なスキルや経験、計算機に関する技術的な知識などに頼らなければならないことも多いものです。 ですから、このあたりの作業を単純にプロセス化することは困難で、どんなドメインにも適用できる上流工程の開発プロセスの案出というのは非常に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
