PD思考法の基礎と情報収集（その1）
PDとは PDとはProblem Determinationの略である。直訳すれば、「問題を確定する」などになるだろう。われわれは問題の切り分けをし、問題部分を特定する、つまり問題判別することをPDと呼んでおり、「PDをする」「PDはどこまで進んでいる」といった使い方をする。 PDを行う目的は、問題要素を特定することにある。それに対し、要素内のプログラムの問題個所を特定しステップ修正するという作業、debug＆fixは開発の役割であり、PDではない。場合によってはPDでデバッグまで踏み込む必要性も生じるが、それは基本的にはPDの役割ではない。コードのバグを発見し修正するには、バグを持つコードを含む要素を特定する必要がある。その要素に到達するまでの道のりを明確にし、問題の発生源を特定するのがPDである。 PDの例 それでは、ある問題を例に、PDの流れを説明してみよう。 さて、このような連絡が
ユーザ受入れテスト（ＵＡＴ） - ユーザ受入れテスト（ＵＡＴ）のテストケースを書くことになりました。書いたことがないのですがどのレベ... - Yahoo!知恵袋
ユーザ受入れテストとは、ユーザ側が納品された製品を受け入れる(＝対価を払う)かどうか を判定する為の重要なフェーズです。 開発側からすれば、受入れ検収なしでメクラ判をついてもらったほうがありがたいのですが、 それでは本番稼動してから不具合が起こった時に困るのはユーザです。 主目的は「要求仕様」を満たしているかのチェックです。 「要求仕様書」「要件定義書」などと照らし合わせ、チェックすることになります。 なので、システムテストとは異なり、システムの中身をチェックするのではなく、 システムをブラックボックスとして、業務が想定通りに行えるかという観点でテスト を実施します。 定型業務、非定型業務、日次業務、月次業務、決算業務などの 各業務単位で、業務フローに基づいた手順でシステムのI/Oを検証することになります。 また、運用テストとしては、高負荷テスト(想定最大データ量での処理能力テスト)や、
急がば回れ──質の良い仕様書の作り方
前回は、自社の業務に必要なシステムの要件の定め方について触れた。今回はその次のフェイズ──仕様決定について考えていこう システムの要件が決まったら、これを具体的なシステム仕様書に落とし込んでいく必要がある。システム仕様書とは、要件を満たすための具体的なシステムの機能・性能に対する要求事項を文書化したものだ。 ソフトウェアの場合、要件定義や仕様書の段階で発見された不備を是正するコストと、運用段階に入ってからのそれとでは、実に200倍の差があるという説がある。また、NASAの記録では、最初の20％の工程に、全体の作業時間の15％を投入することで、プロジェクトの成功確率が80％にまで高まるという。 「早く、安く、最小の投資で最大の効果を生むシステム構築をする」には、システム仕様書の作成に手を抜いたり、他人任せにすべきでない。「急がば、回れ！」である。 質の高い仕様書とは 要件を満足するための、必
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
