So-net無料ブログ作成
検索選択
プロジェクト・品質 ブログトップ

テストの終結判定 [プロジェクト・品質]

テストの終結判定

テストではバグがあることを証明できるがバグがないことを証明できない。
それでは、テストを行った場合に、どの時点で終結と判断するか。
なかなかスッキリとしたものがないような気がします。

1.カバレッジによる判定
各工程に対する網羅率を、データとして持つことで指針にする。

*カバレッジテスト
 ・命令(C0)網羅
  すべての命令が最低1回、正常に実行されるかをテストします。
 ・分岐(C1)網羅
  すべての条件及び判定分岐が最低1回、正常に実行されるか否かをテストします。

2.信頼度成長曲線による判定
過去データから収束を判断することが出来る。

  ・信頼度成長曲線の注意事項
  ・縦軸は、十分に幅を持ったスケールで表現する。
  ・横軸を日付ではなくテスト項目数にする。

 * 信頼度成長曲線の派生
  ・重要度別信頼度成長曲線を作成
  ・機能別の信頼度成長曲線を作成
  ・会社(個人)別の信頼度成長曲線を作成


コーディング基準 [プロジェクト・品質]

コーディング基準

2004年版の"組み込みソフトウェア産業実態調査報告書"によれば
日本は、欧米に比べ各工程の規程(開発標準)が疎かのようです。
特に、製造工程でのコーディング規約を整備が欧州の90%、米国の60数%
に比べ日本は50%程度のようです。
これは、作成されたソースコードはプログラマの癖により様々な様式の
物が出来上がることになり、保守及び評価の際の大きな妨げとなります。
また、コーディング基準がないとコードインスペクションの効率も
悪くなりスケジュールにも影響が出てしまいます。

このことから、プロジェクトの開発に入る前にコーディング基準を作成してプログラマ
に周知徹底する必要があると思います。また、コーディング基準は標準を作成しておいて
プロジェクトの開始前にプロジェクト用のコーディング基準に書き換えるのが一般的な
手順です。

決めるべき基準
ネーミングルール
ファイルの命名規則
モジュールの命名規則
・関数の命名規則
・変数の命名規則
データベーステーブル、カラムの命名規則

コメントルール
・ファイルヘッダー
・関数ヘッダー
・関数中のコメント
文法の作法
・インデントのカラム数の統一
・空白の扱い
・最大カラムの設定
・"("、"{"のつけ方の統一
・判定式の書き方(自然な書き方をする:(!(xxx < yyy)は(xxx >= yyy))
マジックナンバーを使わない
・自動変数は宣言時に初期化する
・環境に依存したコーディングを行わない。


McCabeの複雑度 [プロジェクト・品質]

McCabeの複雑度

デバック、テスト及び保守のし易さを考えると関数の簡素化に注意してロジックを考える必要があります。関数が複雑化していくと単体評価などが複雑になるばかりか、保守の際のプログラム改修に障害を作りこみやすくなります。こうのようなプログラムは、属人的となり開発者しか保守を行うことが出来ません。

プログラムの良し悪しを機械的に判断する方法として、McCabeがあります。McCabeは、プログラムの複雑さをグラフ理論を利用し基本パスの数によりあらわします。

McCabeの指数



この式をプログラムに当てはめると


であらわせます。

要するに、ifの数足す1がMcCabe指数となります。

一般的なMcCabe指数の判断

判断値 指数
10以下 良い
11~20 場合によりロジック再検討
21~40 理解に時間がかかる
41~50 開発者のみ改修可能
51以上 理解不可能

プログラムの複雑度は、このほかにステップ数の多さや変数の種類の数に影響されるので他の要因も考慮して判定するのが良いかと思います。


プロジェクト評価 [プロジェクト・品質]


ソフトウェア開発では、納品が完了したことで打ち上げを行うことが多いと思います。
しかし、プロジェクト管理者はプロジェクトの評価を終えるまで仕事は終了しません。

プロジェクト評価をどのように実施するかで、今後の組織としてのプロジェクト運営を左右します。
プロジェクトリーダは発生した問題点の原因を分析し、同じことを繰り返さない為の策を講じて基準書、手順書の改善に取り組まなければなりません。

評価内容:
・プロジェクト総評
 プロジェクト全体の成功、失敗の評価を行う。(品質、工数、収支など)
・計画工数と実績工数の比率
 このデータを採取することで、実行中のプロジェクトが成功するかの指標とすることが出来ます。 工数は、要求分析、設計、製造、評価に分けそれぞれに成功、失敗のマトリックスを作成します。そのマトリックスから、開発中のプロジェクトが過去のプロジェクトと比較してどのような位置にいるか目安とします。
・予定外の事象発生と対応
 開発時のスケジュールでは、予定していない事柄が発生したときに対応した内容を整理し、開発後にその対応が正しかったのか評価をし、別の方法があった場合は、その案も記述します。
レビュー指摘件数
 レビューでの指摘を項目分けし件数を収集することで、各工程のでの陥りやすいミスや欠落の情報を次の開発のチェックポイントに生かします。
・障害発生件数
 発生した障害を種類、工程などで分類し障害を作りこんだ要因を分析します。また、開発からの障害件数だけではなく保守で収集するリリース後の障害件数と開発ステップ数で割った件数を次の障害検出のノルマとするために収集することも有ります。この場合は、全てのプロジェクトに適用するのは無理が有りますが、同じチーム(個人?)が開発する場合は、わりと同じような数値になりがちなので、ノルマを適用するのも品質を作る一つの手段と思います。
その他にも、開発メンバーの感想も収集しメーンバーがどのように考えてプロジェクトを行っていたかなども収集し、次の開発で"気概"、"集中"や"達成感"をもてる環境作りに生かします。

採取データ

工程 分類 概要
プロジェクト分析 予実費用 予定・実績の費用
運用経費
外部人件費
教育費費
要求分析 予実工数 予定・実績の工数差や変更したスケジュール、要員毎の実績など
レビュー指摘件数、項目 レビュー指摘件数及び指摘内容
要求変更件数 ユーザからの仕様変更要求
障害発生件数 システム評価での障害件数
ドキュメントの種類と枚数
設計 予実工数 予定・実績の工数差や変更したスケジュール、要員毎の実績など
予実モジュール数 予定・実績のモジュールの数
レビュー指摘件数
仕様変更件数
障害発生件数
ドキュメントの種類と枚数
開発 予実工数 予定・実績の工数差や変更したスケジュール、要員毎の実績など
レビュー指摘件数
新規開発ステップ数
変更開発ステップ数 (仕様変更、障害対応)
ドキュメント枚数
評価 予実工数 予定・実績の工数差や変更したスケジュールなど
レビュー指摘件数
予・実定評価項目数
障害検出件数 評価時の障害件数
未解決障害件数 評価時の未解決障害件数
要員別障害件数
原因別障害件数


エラー処理設計 [プロジェクト・品質]


ユーザにとってエラーの対応はプログラムの品質(完成度)を印象付ける大事な要素になります。
エラー処理が無いプログラムは無いと思いますが、大きなプロジェクト以外では暗黙の対応が多いように思います。暗黙の対応とは、製造時にプログラマーがエラー処理を追加していくことです。
この場合は、システムによりエラーの対処方がまちまちで処理の抜けや製造後に追加した為にソースコードの可読性が落ち保守性が悪くなります。保守工数を減らす為にもエラー処理を設計する必要があります。

エラー処理は、システム上のエラーのほかに、業務上の問題やユーザの操作ミスなどを抑制するように処理を設計します。このため、基本設計段階で大局的な観点からエラー処理を設計します。

エラー設計項目

項目 概要
エラーの分類 エラーの洗い出しのために分類する
・業務上の境界値・例外エラー(論理エラー)
・プログラムエラー(論理エラー)
・操作ミスエラー(実行時エラー)
・外部システム起因によるエラー(実行時エラー)
・システム(OS、DBMSなど)エラー(実行時エラー)
・ハードエラー(実行時エラー)
など
エラーレベル エラーの大きさ(復旧時間、費用など)を整理
・注意
・警告
・障害
・致命的
など
回復の分類 エラーの大きさを整理(保守計画)
・自動回復可能
・ユーザ対応可能
・保守員対応
・対応不可能
など
エラー通知 エラーの種類、重要度ごとに分類
・ダイアログ表示
・システムログを使用
・メールまたはメッセンジャーによる通知
など
エラーログ エラーのログ保管方法
・システムログを使用
データベース等に保管
など
エラーコード 種類、発生源が分かるようなコード体系
エラーメッセージ ユーザに種類・重要度が理解できるような簡単な説明
付加メッセージ
・ユーザ対処方法
・保守員コール
など

* エラー処理設計はエラーを整理することで、エラーが致命的になる前に障害を抑制するように基本設計を変更することがあります。このようにエラー処理設計のフィードバックを基本設計に織り込むことでより品質、保守性の高いシステムの設計が可能になります。また、時にはエラー処理が機能設計より大きく膨らむ場合があるため見積もりの際は慎重に考慮する必要があります。

レビューの覚書 [プロジェクト・品質]


レビューは開発工程の品質を保障する上で重要な意味を持っていてます。また、設計・製造・評価の質を高めるだけではなく、担当者の能力も高めるので積極的に行うべきです。レビューを行わないのは、社員教育を放棄していることにもなります。

レビューは基本構造など品質に関わることを重点的にチェックし重箱の隅をつまよう枝で突っつくのは辞めましょう。また、レビューで承認したものは、レビューに参加した全員が責任を持つようにすべきです。

レビューは、必ず第三者が客観的に行う必要があります。レビュー会議では、指摘事項表(詳細と指摘レベルを記述)と指摘事項管理表(一覧表示で対応者、対応日時を記述したもの)を用意しなければならない。
また、レビュー対象物は、予め関係者に配布し内容を確認してもらう。

順次指摘項目の精査を行う。現時点はこんなもの?

要求分析のレビュー
・実現性の判断
・機能の過不足は無いか
・採用する技術は適切か
システムブラックボックスとして書かれているか
・ユーザが理解しやすい構成になっているか(専門用語、略語の説明など)
・業務フローは、他の業務との連携に矛盾が無いか
・入出力が明確化されているか
・リスク管理表があるか(機能、工数、リスクの一覧)
・保守・運用が明確になっているか
・制約・制限事項が明確になっているか

設計書のレビュー
・要求定義書との追跡
・設計ルールに則っているか
・採用する技術は適切か
・機能の過不足
モジュール構成
・データ構造の矛盾
・制約事項の確認
・品質が保たれる内容になっているか
・製造工程を行える品質であるか

評価仕様書のレビュー
・設計書との追跡
・環境、条件及び予測結果が明記されているか(再試験で同一結果が出せる)
・評価項目は、デシジョンテーブルなどを使用して網羅されている
・制約、制限による評価項目がある
・エラーケースの評価項目がある
・評価工程を行える品質であるか

製造のレビュー
・設計書との追跡
・プログラム規約に沿ったコーディングがされている
・ロジックの確認
・変数の扱いが正しいか
・エラー時の対応は正しいか
・評価工程を行える品質であるか

評価結果のレビュー
・評価実施ルールに準拠しているか
・設計書との追跡
・問題管理はされているか
・積み残されている問題が有るか


開発と品質 [プロジェクト・品質]


CMMやISOなどソフトウェアの品質管理に注目が集まっています。
本質は、私が20数年前に大学で教わった”ソフトウェア工学”(当時としては珍しい講座でした)
から大きく変わっていないような気がします。
もちろん、品質を高めようと色々な手法が提唱さて言いますが、その手法を1から10まで
実行することは無理があるのでプロジェクト毎の対応が必要になります。

品質の大前提として、「契約の内容を保証する」を念頭に何を明確にどのようなISOの定義では下記の様になります。
ISO/IEC9126の品質特性

特性 概要
機能性 要求達成度:正しい結果が得られるか、目的にあった機能があるか
使用性 ヘルプやUIが考慮され運用が取得しやすい。
効率性 資源・処理能力の効率
信頼性 性能維持能力(定義した期間と条件内での)
移植性 別環境への移行のしやすさ
保守性 変更、拡張のしやすさや障害時対応の容易性

各プロジェクトに沿ったソフトウェアライフサイクルと品質管理を考慮したプロジェクト管理が重要 なのですが、その前にソフトウェアライフサイクルを定義します。

ソフトウェアのライフサイクル
ソフトウェアのライフサイクルは、大きく下記の工程に分かれると思います。
ウォーターフォール

工程 説明 成果物 品質
要求仕様 大きく3形態の作成方法があります
・システムの要求をユーザが作成
・ユーザと開発者が共同で作成
・開発者が企画立案し作成(プロダクト製品)
要求仕様書 実際の業務に則した内容になっている
要求分析 ユーザからの要求を明確化します。
・目的・目標・機能・性能・制限条件を明確化する
要求定義書 要求分析を行ったデータが妥当である
プロジェクトの基準書、手順書及びリソース計画をこの段階で用意する
システム設計 基本設計、ソフトウェア設計、ハードウェア設計、インターフェース設計を含みます。
このほかに、この工程で評価仕様と運用保守系のSOPを定義する必要があります。
・基本設計書
・ソフトウェア設計書
・ハードウェア設計書
・インターフェース設計書
・評価仕様
・運用保守
エラー処理及び想定外処理が考慮されている
製造 ソフトウェアの製造のほかに評価工程までに付随する成果物を作成 実行モジュール
・詳細設計書
・ソース
・インストール媒体
・評価仕様書
・運用保守仕様書
システム設計に合致した詳細設計書、ソースコードである
評価 システム評価、総合評価を行います。 評価結果報告書
・障害表
・障害管理台帳
システム設計書に則した評価内容で、エラー及び想定外の評価を行っている。
全評価が再現可能である

*各工程で作成された成果物は、トレーサビリティマトリックスを作成しユーザ要件と相違なく 作成されていることを確認する必要があります。

プロトタイプ
ウォータフォールの設計の前にプロトタイプ設計、プロトタイプ検証を繰返し作成する方法です。
ユーザの意見を聞きながら試作品を作成していくので最終的にはユーザの意向に合ったものが 作れますが、大規模開発には向きません。

スパイラル
機能を分解してウォータフォール工程を短い時間で開発し次々と機能を追加して最終的に目的の 機能を全て乗せる方法です。開発工程が渦巻きのように表現されるのでき中心から離れるほど機能 が追加されていきます。一つ一つの開発期間が短いので後戻り工数を少なくすることが出来ます。 オブジェクト指向の開発で使われます。

反復型開発方
反復型は開発とテストを繰返し行うため、初期段階で要件を全てそろえる必要が無く要件変更や新技術に対応しやすい開発手法です。
反復型には、次の二つの方法が有ります。
 インクリメント型
システム全体を複数のサブシステムに分割し,最初にシステムの基盤部分と共通機能を開発します。その後は優先順位に従い機能を追加(製造・テスト)を繰り返していくため機能単位で常に動作可能なシステムとなってます。このため、リスクの検証とユーザの要求検証が早期に可能になります。
 インタラクティブ型
分割した部分ごとに開発・テストを繰り返してシステムを構築する方法で、修正と改修を繰り返しながら製造していきます。

アジャイル型
アジャイル型とは、XP(eXtreme Programming)、FDD(Feature Driven Development)、スクラム(SCRUM)などの開発方法の総称で、反復型と同様な工程を取りますが、設計方法やユーザとの関係及び開発者同士の関係までを視野に入れた開発方法です。特に、ユーザとの関係と開発者が如何に気持ちよく開発に取り組めるかと言うところを重視しているので、昔よく言われていた”ピープルウェア”をちょっと思い出しました。

ソフトウェアの品質が改善されない要因はいろいろ有ると思いますが、内的要因として設製造者 のスキルが均一でなく(均一のわけが有りません)同じ設計で作成しても違うコードを作成するこ とが多く有ります。(外的要因は、営業に関わるので除外しておきますが、要求分析の後に発生しうる追加用件についてどのような取り扱いにするのかユーザと相談のしておくとべきです。) この違いを吸収する為にSOP(基準書、手順書など)を作成する必要があります。これが有ると、 もしもの時(火を噴いた場合など)に開発の増員や外部へのモジュールの切り出しをすることが有 ると思いますが、この場合にもスムーズに作業を開始することができます。評価工程のみでなく 全工程で品質を作りこむ(プロセスの保証)という考え方が高品質のソフトウェア開発うえで必要 なことと思います。
しかし、全てのプロジェクトに一つの基準や手順を適用するのでは無く、プロジェクトに合った 基準書、手順書を作成しなければ過去と同じ道を進むことになりますのでプロジェクト毎に見直 すようにすべきです。

運用中に障害が発生すると”評価不足”という言葉をよく聴きますが品質を決定するのは評価と 評価に重点を置きすぎのような気がします。全ての障害は、要求分析、設計、製造と各工程のレ ビュー不足により発生すると考え障害の分析を行い次のプロジェクトに反映する必要があります。

品質とは、「契約の内容を保証する」が前提となることを、ユーザにも理解してもらわなければなら ないので、開発者は、ベースとなるSOPを基に契約ごとのSOPを作成・提出し説明をする必要があり ます。

要求分析
ユーザからの要求仕様書はあいまいなことが多いため、目的、目標、機能、性能、制限条件を明確に した要求定義書を作成する。読み手は、ユーザ、営業、開発者、評価者及び保守員と開発から運用まで の広い範囲の人が読みます。そのため、理解しやすく書くことを心がけなければなりません。この段階 で誤解を受けると後々大変なことが起きます。
イベント、ユーザインターフェース、作業及びデータの流れを図式化(モデル化)することで、要求分析 の妥当生が理解しやすくなります。
要求定義書は、設計書ではないので具体的な実現方法は記述しないように心がけます。具体的な実現方法は、 次の工程のシステム設計に任せます。
また、条件による動作を明確にするためにデシジョンテーブルで表現します。
開発する立場としては、プロジェクトに適合した基準書、手順書及びリソース計画をこの段階で用意した いものです。
関連知識として調査したい項目:
・要求工学
・構造化分析設計法:SADT
・ワークデザイン手法
・E-Rモデル
・KJ法
・デルファイ法
・UML
基準書:
・要求分析基準(分析方法の指定など)
・進捗率算出基準(全員が同じ基準で算出)

手順書:
・ドキュメント管理手順
・スケジュール管理手順

システム設計
基本設計、ソフトウェア設計、ハードウェア設計、インターフェース設計を含みます。
このほかに、この工程で評価仕様と運用保守系のSOPを定義する必要があります。
システム設計では、要求定義書に従い具体的な実現方法を記述します。 ・基本設計書
基本設計書には、開発目的、設計の基本方針、製造の基本方針、性能、機器構成、機能一覧、システム構成、開発体制、開発スケジュール が必要になります。
・ソフトウェア設計書
プログラム構造設計、モジュール設計によりデータ構造と制御構造を具体的にしていきます。
設計方法は、UMLなど色々有りますのでプロジェクトの方針に従って記述します。
・ハードウェア設計書
ハードウェアそのものを作る為の設計ではなく、システムのハードウェア構成を設計します。
ハードウェアの設置・接続方法及び環境設定方法などを記述します。
・インターフェース設計書
ユーザインターフェース、外部インターフェースについて記述します。入力、出力(画面、帳票など)及び外部機器との接続方法などを記述します。
・評価仕様書
単体・結合・システムの評価仕様書を作ります。
評価仕様は、何時でも評価を再現できる様に評価手順の細かな記述及びデータを揃えます。
この段階で評価仕様書を作成すると製造の前に設計の不備を検出することが出来るので早い段階で評価仕様書 を作成するのがよいと思います。順番としては、要求分析の後にシステム評価仕様書、基本設計の後に結合仕様書、ソフトウェア設計の後に単体評価仕様書になります。 ・運用保守書
設計時に運用仕様を固めることで、ソフトウェア仕様、ハードウェア仕様に運用保守の機能を載せて 考えることができます。また、評価仕様書と同様に設計の不備の早期発見のためにもなるべく早く作成する必要があります。
基準書:
・設計基準(設計方法の指定など)
・進捗率算出基準(全員が同じ基準で算出)

手順書:
・ドキュメント管理手順
・スケジュール管理手順

製造
基準書、手順書及びソフトウェア設計書にしたがってコーディングをします。ここでの品質をどのように考えるか が一つの命題になりますが、基本的には、プロジェクト毎の基準書、手順書に従ってコーディングすることで一定 の品質が確保されると思います。このときにモジュール単位の評価モジュールを作りこんでおくと、結合評価の際の 障害の絞込み及び仕様変更による再評価の時間を短縮してくれます。

開発は、多くの場合複数の人間が開発に携わるので、それぞれの環境に差異が無いようにVMWareなどを使用して同じ 環境で開発することが非常に重要になります。これは、開発環境をそれぞれが構築しなくとも、一つ環境を作成すれ ば、環境を簡単に複製することが出来、全員が完全に同一の環境でプログラムを作成することが出来ます。 また、ソース管理をSubversionのようなソース管理ツールを使用することでデグレートなどを抑制します。 このように出来るだけ使えるツールは積極的に使用して管理に頭を悩ませる時間をコーディングに使うようにします。
単体評価(ホワイトボックステスト)は、この段階で行います。
個人的には、機能単位で短いゴールを設定することで遥か彼方にゴールがある場合よりもメリハリがあり気分的にも 楽になるのでコーディング、単体評価の繰返しで開発を行うようにしています。
基準書:
・コーディング規約(コメントのルール、変数、関数の命名則など)
・進捗率算出基準(全員が同じ基準で算出)

手順書:
・開発環境設定手順
・ソースコード管理手順
・スケジュール管理手順

評価(結合・システム)
評価は、ユーザの要求を満たしていることを確認する為に行います。一般的には設計者および製造者とは別の要員により 作業を行います。
評価仕様書には、ユーザが同じ評価で同じ結果が得られるように環境、手順、予測値の記入が必要です。

・結合評価(グレーボックステスト)
結合評価はモジュール間のインターフェース確認と実装された機能が仕様書と合っているかどうかを確認します。

・システム評価(ブラックボックステスト)
ユーザの実行環境と同様な環境により評価を行います。作業の流れのシナリオを作成しそれに沿った評価を行います。 同時接続数、データ量なども本番に近い環境にします。

評価方法は色々な手法が有りますが、漏れが無いように評価を行うのが大事です。しかし、全てのケースを評価していた のではいつ出荷できるか分かりません。そこで、入力に範囲のある場合は、境界値、同値を分析し少ない評価で 最大限の効果が得られる様にします。また、障害が発生した場合のリスクの大きさを整理し優先度を付け評価をする 方法も有ります。
障害が発生した場合は、障害票に障害内容を記入します。障害内容、評価番号、発生日時、発見者、対応者及び対応期限 は必ず記入してください。管理者は、障害台帳を作成し対応の進捗及び対応漏れが無いようにします。
評価環境を仮想(VMWare、Virtual Server、GENなど)で作成しておくと、環境(データやサーバ環境など)を変えたマシンの 評価が平行でできるので期間の短縮になります。
基準書:
・評価方法
・進捗率算出基準(全員が同じ基準で算出)

手順書:
・障害管理手順
・スケジュール管理手順

*プロジェクトとしてはプロジェクトの最後に必ずプロジェクト評価をおこないます。


プロジェクト・品質 ブログトップ
メッセージを送る

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。

×

この広告は1年以上新しい記事の更新がないブログに表示されております。