リスク・ベース・テストの効果と限界
ソフトウェアテストを改善する手法として、リスク・ベース・テストが注目されている。 ソフトウェアの開発サイクルが短くなっている現在では、短時間にいかに効率良くテストを行い、ソフトウェアの品質を高められるかが焦点になっている。テスト不足による品質低下に悩む人にとって、リスク・ベース・テストは効果的かつ魅力的な解決策である。 だが、リスク・ベース・テストが改善するのは、テスト・プロセスである。品質低下の原因がテスト・プロセスではなく、テスト項目そのものにある場合は、リスク・ベース・テストを導入しても、品質を高めることはできないだろう。
テストファーストの弊害
テストファーストは、XP（エクストリームプログラミング）の中でも特に広く浸透したプラクティスの１つである。 テストファーストは、モノを作るよりも前に、まずテストから着手する、という手法だ。モノが無ければテストできないという常識を、根本からひっくり返す斬新なアイディアは、多くのソフトウェア開発者に衝撃を与えた。 テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。 だが、このようなまったく新しい手法は、初めはなかなか受け入れられ難いが、いったん受け入れられると、今度は逆に、魔法の技術であるかのように盲信されやすい。テストファーストについても、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。 テストファーストの効果は、多くの人が認め
WBS（Work Breakdown Structure）によるプロジェクト管理
ソフトウェア開発プロジェクトでは、短期開発の要求が高まっている。受託開発も例外ではない。特定の顧客から長期に渡って大型案件を請け負っている場合でも、開発期間はますます短縮される傾向にある。 納期に対する高い要求を満たすには、プロジェクト管理が重要である。正確な見積もりと、的確な進捗管理ができなければ、短期開発では容易にデスマーチに陥ってしまう。 筆者の開発プロジェクトでは、WBS (Work Breakdown Structure) を使ったプロジェクト管理を導入した。WBSは見積もりのための強力な道具として広く使われている。筆者はさらに、実績も管理できるようにWBSを拡張し、見積もりから進捗管理まで一貫して管理できる手法を確立した。 ここでは、筆者が拡張したWBSの書き方と、それを使ったプロジェクト管理の手法を提案し、実際の開発業務に適用した経験から得られたWBSの運用ノウハウを紹介する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
