投稿者: webmaster

CMMIの成熟度レベル

レベル1 初期

成熟度レベル1では多くの場合、プロセスは場当たり的であり、組織は安定した環境を提供しない。 こうした組織では、プロジェクトの成功は、組織に属する個々人の能力と英雄的行動に依存しており、有用性が証明されたプロセスを採用していない。 場当たり的で混沌とした環境であるにもかかわらず、成熟度レベル1の組織は実際に動く成果物とサービスを提供することが少なくない。 しかしそれらは多くの場合プロジェクトの予算および予定期限を超過する。

成熟度レベル1の組織は、超過労働、危機に対処するプロセスの欠如、過去の成功を繰り返す能力の欠如、によって特徴づけられる。

レベル1の組織が遂行するプロジェクトの成功は、高い能力をもつ個人に依存している。
レベル2 管理された

成熟度レベル2の組織はソフトウェア開発などの成功を反復して実行することができる。 このレベルの組織では、組織の全てのプロジェクトにおいて反復が実現できているとは限らない。 このレベルの組織では、何らかの基本的なプロジェクト管理を行い、費用と予定 (スケジュール) を管理している。

レベル2のプロセスの規律を実行することにより、これまで行ってきた実践は今後も意識して行われ続けられる。 これまで行ってきた実践は今後も首尾良く行われる場合、プロジェクトは文書化された計画に従って実行され管理される。

プロジェクトの情況や納品物の引渡しなどは、事前に定めておいた時点 (メジャーマイルストーンやメジャータスクの完了など) での管理を通して明確になる。

基本的なプロジェクト管理プロセスが確立し、費用、予定、開発対象の機能を管理する。 レベル2のプロセスの最低限の規律は、過去の類似した分野と範囲をもつプロジェクトの成功を、反復することである。 このレベルでは、費用もしくは納品予定日を超過するという大きなリスクは依然として存在する。
レベル3 定義された

成熟度レベル3の組織では、組織の標準プロセスが確立しており、時が経つにつれ標準プロセスは改善される。 こうした標準プロセスは、組織全体に浸透させ組織における一貫性を確立すべく使用される。 組織のプロジェクトは、組織の標準プロセスによりテーラリング指針に沿って、定義されたプロセスを確立する。

組織の管理部門は、組織の標準プロセスに基づいてプロセスの目的を確立し、こうした目的が確実に適切に取り組まれるようにする。

成熟度レベル2とレベル3の重要な違いは、標準群とプロセス記述と手続きである。 成熟度レベル2の組織では、標準群とプロセス記述と手続きは、プロセスのおのおのの具体的な内容において組織内でかなり異なっているかもしれない。 成熟度レベル3の組織では、あるプロジェクトや部門の標準群とプロセス記述と手続きは、組織の標準プロセスに適合している。
レベル4 定量的に管理された

成熟度レベル4の組織では、実施プロセスを安定化し、さらに実績を予測するモデルを持つことで、ソフトウェア開発などの有効性を効果的に制御することができる。 特に、個別のプロジェクトに対してプロセスを調整し適合する道筋を同定することができる。 このとき測定可能な品質の低減や仕様からの逸脱が無いようにプロセスが制御され、安定化される。 成熟度レベル4の組織は、ソフトウェア開発プロセスやソフトウェア保守などのための定量的な品質の目標を設定する。注意すべきことは、この目標がプロセスの実績データを基にした実現可能なものであり、(低いレベルの組織でありがちな)管理層からの一方的押しつけや実現不可能な努力目標ではないということである。

プロセス全体の遂行に非常に大きく貢献するサブプロセスが選択される。 この選択されたサブプロセスは、統計的な技法と他の定量的な技法により制御される。

成熟度レベル3とレベル4の重要な違いはプロセス遂行の予測可能性である。 成熟度レベル4では、プロセスの遂行は統計的な技法と他の定量的な技法により制御され、定量的に予測可能である。 成熟度レベル3では、プロセスは単に定性的に予測可能なだけである。
レベル5 最適化している

成熟度レベル5は、段階的および革新的な技術的進歩を通じた継続的なプロセスの有効性の改善を重視する。 組織にとっての定量的なプロセス改善の複数の目標が定められる。 これらの目標は、ビジネス上の目標の変更を反映して継続的に改訂される。 またこれらの目標は、プロセス改善の管理における基準として使われる。 適用されたプロセス改善の有効性は計測され、定量的なプロセス改善目標に照らして評価される。 定義されたプロセスと組織の標準プロセスのセットの双方が、改善活動の計測の対象となる。

プロセス改善は、プロセスにおける変動の共通の原因に取り組み組織のプロセスを計測可能な形で改善するために、同定され評価され適用される。

敏捷で適応力のある進取的なプロセスの最適化は、能力の高い労働者がビジネス価値と組織の目標に同調して参加するかどうかにかかっている。 組織における変化と機会にすばやく対応する能力は、学習を加速し共有する道筋をみつけることで高まる。

成熟度レベル4とレベル5の重要な違いは、取り組む対象である、プロセスにおける変動の種類である。 成熟度レベル4では、プロセスはプロセスにおける変動の特定の原因に取り組むことと結果の統計的予測と関連している。 プロセスは予測可能な結果を出すかもしれないが、その結果はあらかじめ定めた目標の達成には不十分であるかもしれない。 成熟度レベル5では、プロセスはプロセスにおける変動に共通する原因に取り組むこととプロセスを変更し (すなわちプロセスの遂行能力の平均値を変更する) その遂行能力を向上させ (統計的確率を修整しつつ) あらかじめ定めた定量的なプロセス改善目標を達成できるようにすることと関連している。

[参考:Wikipedia]

もも

CMMI

CMMIは、プロセスの評価や改善をすすめるための枠組みであり、段階表現と連続表現の2つの表現方法がある。段階表現では、組織の実施プロセスを評価し、レベル1からレベル5までの5段階の成熟度レベルを(組織に対して)出すことができる。連続表現では、各プロセスを評価し、レベル0からレベル3までの4段階の能力度レベルを(プロセスごとに)出すことができる。(以前はレベル0から5までの6段階であったが、v1.3から4段階に改訂された。)これらのレベルは、評価の対象となるプロセスの制度化の程度に応じて、等級づけられている。

評価の対象となる領域はさまざまであり次のようなものがある。

ソフトウェア開発
システム開発
プロジェクト管理
リスク管理
システム調達、情報技術 (IT) サービス
パーソナルマネジメント

CMMIでは5つの成熟度レベルを厳密に定義している。

レベル1は、非常に未熟で混沌とした開発プロセスである。
レベル5は、非常に成熟した高品質を実現する開発プロセスである。

1998年の時点では、ソフトウェア開発を行う組織の75%がレベル1であると推定されている (参考)。

CMMIの前身にあたるCMMは、1980年代半ばにアメリカ合衆国のピッツバーグにあるカーネギーメロン大学 (CMU) のソフトウェア工学研究所 (SEI; Software Engineering Institute) で開発された。 CMMIは、航空電子工学ソフトウェアの開発や北アメリカ、欧州、アジア、オーストラリア、南アメリカ、アフリカなどの国々の政府主体で行うプロジェクトなどで、広く採用されてきており、こうした国々でCMMIに対する官民の関心は高い[2] 。 現在、いくつかの国々の省庁は、ソフトウェア開発契約に際して業者にレベル3の基準を達成しかつ運用できていることを必須としている。 また日本においても、ソフトウェアを発注する官公庁や民間組織がCMMIを採用し、一方でソフトウェア開発を担う組織がCMMIの指針に即して自らのソフトウェア開発プロセスを改善する動きが、徐々に広がりつつある。

[参考:Wikipedia]

キーワード関連:CMMIの成熟度レベル

もも

開発工程モデル

ここ数十年のソフトウェア工学の目標のひとつとして、反復可能かつ予測可能な開発工程の方法論を見出し、生産性と品質を向上させるということが挙げられる。一部の人々はソフトウェア開発の一見して手に負えないタスクを体系化し、形式化しようとしてきた。他の人々はソフトウェア開発にプロジェクトマネジメント手法を適用した。プロジェクトマネジメントを適用しなければ、ソフトウェアプロジェクトは簡単に納期に遅れたり、予算を超過したりする。多くのソフトウェアプロジェクトは実際に機能/コスト/納期に問題を抱えており、プロジェクトマネジメントの困難さを証明している。
①ウォーターフォール型

最もよく知られた従来型の開発工程モデルはウォーターフォール・モデルである。このモデルでは、開発者は上述の工程(局面、フェーズ)を順番に行う。要求仕様を作成し、それを分析し、解決法を設計し、そのためのソフトウェアフレームワークのアーキテクチャを作り、コードを書き、評価し(単体テスト→システムテストの順)、配備し、保守する。各工程が完了すると、次の工程に進むことができる。ちょうど、家の骨組みを組み上げてから土台を変更できないというのと同じ考え方である。

ウォーターフォール・モデルでは上流工程での間違いや仕様変更を後から訂正・反映することを考慮していないと考えられがちだが、これは誤解である。これは要求管理に変更制御を含めるかどうかという問題である。

この手法は特に大規模なシステム開発や危険の大きいプロジェクト(軍需関係の契約など)で使われている。各工程ごとに契約・入札が行われる場合もある。

大規模なシステム開発ではサブシステム化も併用し、各サブシステムで時期をずらしてウォーターフォール・モデルを採用する事で、先行するサブシステムで発見した問題を後続のサブシステムでは早い段階の工程で取り入れたり、各工程の要員(設計者、プログラマ、テスターなど)や主要イベント(プロジェクト立ち上げ、レビュー、検収、研修、本番稼動など)の平準化を図る場合も多い。また各工程の内部では後述のスパイラルモデルや反復型開発を組み合わせる場合もある。

ウォーターフォールの問題は、要求分析と要求管理についての技術的未熟さから生じることが多い。さらに言えば、開発工程の弱点の把握不足と開発者が問題を理解せずにコーディングを開始してしまうことからも問題が生じる。また、しばしば省略されがちな工程として顧客と開発者の間での共同レビューがある。開発者は危険を承知で設計を進めて開発するが、その設計は最終的には Critical Design Review(最終設計審査)というマイルストーンでチェックを受けることになる。この手法への批判はソフトウェア工学者よりも実際の技術者から出てくることが多い。批判者は WISCY(Why Isn’t Someone coding yet ?)アプローチなどを信奉している。
②反復型

反復型開発は、ソフトウェアを徐々に開発していく手法であり、問題点や前提の間違いを早期に検出して大きな問題となるのを防ぐ。反復型開発はパッケージでない商用ソフトウェア開発で好まれる。というのも、自分がソフトウェアに何を求めているかをうまく定義できない顧客の要求にも応えて開発していくことが可能だからである。

アジャイルソフトウェア開発は反復型開発からの派生手法である。アジャイルでは、従来よりも軽量で人間中心の視点を導入した。アジャイルでは計画よりもフィードバックを重視する。フィードバックは主にテスト(評価)と開発途中のソフトウェアを外部にリリースすることで得られる。

アジャイルソフトウェア開発は従来の方法論よりも効率的と思われる。少ない工数でより多くの機能を開発でき、品質の高いソフトウェアを開発できる。しかし、ビジネス的観点から見ると、長期的計画を立てるのが困難であるという問題がある。基本的に、必要な機能は開発されるが、それが何時になるのかは不明である。

エクストリーム・プログラミング(XP)は最も有名なアジャイル的手法である。XPでは工程が非常に短いステップに分割される。ウォーターフォール・モデルでは数ヶ月から数年かかる工程を1日から1週間の工程に分割するのである。まず、自動化されたテストを書き、その工程でのゴールを定める。次に(2人のプログラマにより)コーディングを行い、全部のテストをパスした段階でその工程が完了する。設計とアーキテクチャはリファクタリングによって生み出され、コーディングの後に完成する。設計はコーディング担当者が行う。設計とコードの統合を行う段階は他のアジャイルソフトウェア開発と同様である。不完全だが機能するシステムがユーザー(あるいはその一部、開発チームもユーザーの一部である)に配布され、評価される。その後、次に重要と思われる部分に関するテストが書かれ、次のサイクルが開始される。

反復型開発には独自の利点があるが、ソフトウェアアーキテクトはさらに信頼できるソフトウェア開発基盤を生み出そうとしている。そのような開発モデルの基盤には最前線の現場の分析とプロトタイピングが必要である。開発モデルは特定の設計パターンや実体関連図(ERD)に依存していることが多い。反復型開発はコストおよび品質で有利な長期的戦略を採用することにより、事前の基盤を必要としない。

反復型開発への批判は、これらの手法が顧客に対してソフトウェア開発に深く関わること、すなわち開発者的スキルと経験を要求することを問題にする。また、そうでなければこの手法のコストは増大する。それは「どういう家が欲しいか決めかねているなら、試しに私どもに建てさせて気に入るかどうか見てみてください。もし気に入らなかったら、取り壊して立て直します」と言っているようなものである。この批評は、反復型開発の要点を取り違えている。反復型開発では顧客からフィードバックを得るのに家全体を建てる必要はない。従来型の開発手法で実際の開発が始まる前に行っている要求分析と開発完了後に行っている評価を、反復型開発では全工程に分散させていると見ることができる。

実際、アジャイルのコミュニティでは要求仕様を固定せずにソフトウェアを改良していくという点で曲折があった。従来の手法ではこれは許されず、商業的にもナンセンスである。アジャイル的手法ではアーキテクチャの変更を迫るような新たな要求について、顧客が対価を支払わない場合、アジャイル的にプロジェクトは終了させられる。

これらの手法はウェブベースの技術の発展と共に開発されてきた。したがって、アーキテクチャとソリューションの機能のほとんどがアプリケーションのバックボーンに選ばれた技術で実現されていると仮定すると(つまり、ミドルウェアで実現されている)、これらの手法は実際には保守ライフサイクルと同義である。

リファクタリングは、設計を慎重に行って文書化することの代替案としてアジャイル・コミュニティが提案したものである。アーキテクチャ上の問題に対するリエンジニアリングへの代替案は提案されていない。どちらも比較するとコストがかかる。既存のコードへのリファクタリングを1回通して行うと 10% から 15% のコスト増となると言われている。しかし、この値に再評価やリグレッションテストも含んでいるかどうかは不明である。もちろん、既存のアーキテクチャを捨ててしまう方がさらにコストがかかる。実際、アジャイル的手法を利用した開発ではコスト問題に悩んでいるという調査結果がある(Software Development at Microsoft Observed)。ここでは、基本設計の管理よりもプログラミング担当者らによる定常的なリバースエンジニアリングが強調されている点に注意されたい。

テスト駆動開発(TDD)はアジャイル的手法から生まれた便利な手法だが、同時に問題もはらんでいる。TDD ではコードを書く前にそのコードに関する単体テストを書く必要がある。したがって、まずどういうコードを書くかを考え、それを書く前にその単体テストを書けるほど十分に詳細を決定しなければならない。アジャイルソフトウェア開発では簡単な設計からコードを書くのであるから、TDD をアジャイル的でない開発工程モデルに取り入れることはアジャイル的なものとは正反対となる。
3.形式手法

形式手法は要求/仕様記述/設計段階でのソフトウェア(およびハードウェア)問題への数学的対処法である。形式手法の例として、B-Method、ペトリネット、RAISE、VDM などがある。形式仕様記述もZ記法など様々な手法がある。より一般化すれば、有限状態機械のシステムを設計することでオートマトン理論を応用してアプリケーションの動作を解明する。

有限状態機械(FSM) に基づいた方法論で実行可能ソフトウェアの仕様記述ができ、従来的なコーディング工程を省くことができる(仮想有限状態機械およびイベント駆動有限状態機械)。

形式手法はアビオニクスソフトウェアなどの安全性が重要とされるソフトウェアでよく採用されている。DO178Bなどのソフトウェアの安全性保証標準規格では、形式手法の採用が義務付けられている(レベルAの場合)。

形式手法は開発工程に様々な形で入り込んできつつある(例えば、OCL、JML、モデル駆動型アーキテクチャなど)。

[参考:Wikipedia]

キーワード関連:テスト駆動開発B-MethodペトリネットVDM

もも

開発工程

1ソフトウェア要求分析
ソフトウェア製品を作るにあたっての最初のタスクは要求を引き出す・集めることである。顧客はソフトウェアに何をさせたいのかを知っているものである。しかし、その要求は不完全だったり、曖昧だったり、互いに矛盾していたりする。経験をつんだソフトウェア技術者はそれを聞き出して一貫性のある要求仕様に纏め上げる。
2.仕様記述
仕様記述は可能な限り厳密な方法で開発すべきソフトウェアを正確に記述するタスクである。安全性が重要なソフトウェアシステムでは、開発に先駆けて仕様記述を注意深く行うが、実際に最も成功している仕様記述とは、既存のアプリケーションを理解して改善するために書かれるものであろう。安定していなければならない外部インターフェイスにとって仕様記述は最も重要である。
3.ソフトウェアアーキテクチャ
ソフトウェアシステムのアーキテクチャとは、システムを抽象的に表現したものである。アーキテクチャはソフトウェアシステムが製品として要求に適合しているかを検証するのに使用される他、将来の追加要求に応えるためにも使用される。アーキテクチャ作成段階ではソフトウェアシステム間や他のソフトウェア製品間のインターフェイスも規定し、ハードウェアやオペレーティングシステムも規定する。
4.実装
設計からコードを作成する段階はソフトウェア開発において最も明白な工程であるが、必ずしも最大の工程とは限らない。
5.評価
特に複数の技術者が開発したコードを結合して行う評価はソフトウェア技術者が行う。
6.文書化
ソフトウェアの内部設計を文書化するタスクは重要だが、しばしば見過ごされている。これは将来の保守と改良に使用される。文書化は外部インターフェイスにとっては最も重要である。

[参考:Wikipedia]

もも

プロセスとメタプロセス

プロセスとメタプロセスとは、
ソフトウェア開発組織の巨大化とともに開発工程に関する方法論が提案されるようになってきた。アメリカでは軍需での契約を獲得する条件としてプロセスモデルに基づいた評価が行われるため、それが方法論の発達を促したとも言える。ISO 12207 はプロジェクトのライフサイクルを選択・実装・監視する手法に関する標準規格である。

能力成熟度モデル(CMM) は主要なモデルの1つである。独自のアセスメントにより組織が自身で定義したプロセスにどれだけ忠実に従っているかを測る。このとき、そのプロセスの品質そのものやソフトウェア製品の品質は関与しない。CMM は徐々に拡張され能力成熟度モデル統合(CMMI) となった。ISO 9000 は形式的に構成されたプロセスとその文書に関する標準規格である。

ISO 15504 は、ソフトウェアプロセスのアセスメントのためのフレームワークであり、Software Process Improvement Capability Determination (SPICE) とも呼ばれる。この標準規格はプロセスを比較するための明確なモデルとなっている。SPICE も CMM や CMMI と同様に使われている。それは、ソフトウェア開発を管理/制御/誘導/監視するためのプロセスのモデルである。このモデルを使って、ソフトウェア開発において組織やプロジェクトチームが実際何をしているのかを測る。その情報を元に弱点を検出し、それを克服するよう改善する。同時に長所も探し出して、それを組織やチーム全体の共通の慣習にして継続させるようにしていく。

シックス・シグマはプロセス管理の方法論の一種であり、統計分析により企業の経営品質を測定し、それを向上させる。製造やサービスのプロセスでの問題点を検出して排除するのに使われる。最大許容欠陥発生率は百万回につき 3.4回である。しかし、シックス・シグマは製造業を対象としているため、ソフトウェア開発に適用するにはさらに研究が必要である。

[参考:Wikipedia]

キーワード関連:プロセスモデルISO 12207ISO 9000ISO 15504シックス・シグマ

もも

ソフトウェア開発工程

ソフトウェア開発工程(ソフトウェアかいはつこうてい、Software Development Process)とは、ソフトウェア製品の開発の構造を意味する。ソフトウェアライフサイクル、ソフトウェア開発プロセス、ソフトウェアプロセスもほぼ同義語である。開発工程にはいくつかのモデルがあり、開発工程内の各種タスク・活動のための手法を提案している。

1 プロセスとメタプロセス
2 開発工程
3 開発工程モデル

[参考:Wikipedia]

もも

PRINCE2

PRINCE2とは、イギリス商務局 (OGC) が開発したロプジェクトマネジメントの方法論の1つ。プロジェクトの管理面、組織面、制御面をカバーする。
1989年、イギリス政府の情報システムのプロジェクトマネジメントの標準として中央電子計算機局 (CCTA) が PRINCE を開発した。これは、すぐにIT向けにイギリス政府機関以外でも使われるようになった。1996年、より汎用的なプロジェクトマネジメント手法として PRINCE2 が発表された。PRINCE2 は徐々に知名度が上がり、イギリスでのプロジェクトマネジメントのデファクトスタンダードとなっている。また、イギリス以外の国々にもその利用が広がりつつある。

最新版は商務局が2005年にリリースしたもので、2008年9月を目指して改版作業中である。

「PRINCE2」という名称は OGC の商標であり、英語の「projects in controlled environments, 2nd version」に由来する。

[参考:Wikipedia]

もも

Vモデル

Vモデル(V-Model)とは、IT製品開発の手法の一種。ドイツ政府と軍関係のプロジェクトで標準として採用されている。また、一般に利用可能であるため、様々な企業でも使われている。プロジェクトマネジメント手法としては、PRINCE2に匹敵する。また、システム開発やソフトウェア開発の手法としても使われている。
現在のバージョンは V-Model XT と呼ばれ、2005年2月に完成した(http://www.v-modell-xt.de)。能力成熟度モデル統合(CMMI)とは直接競合しない。CMMIは「何を」すべきかを示すものだが、Vモデルはそれに加えて「如何にして」「何時」「誰が」責任を持って行うかも示す。
Vモデルはドイツ政府関連のソフトウェア開発工程を規定するために開発された。ソフトウェア開発の中で行うべき活動とその成果物を規定している。Vモデルはソフトウェア開発のライフサイクルをグラフィカルに表現したものでもある。自動化されたシステム検証フレームワークとの関連でなされるステップを要約している。

仕様策定部分は主に次のような作業からなる:
1.ユーザー要求仕様
2.機能仕様
3.設計仕様(詳細仕様)

テスト実行部分は主に次のような作業からなる:
1.受け入れテスト
2.操作テスト
3.性能テスト

[参考:Wikipedia]

キーワード関連:PRINCE2CMMIソフトウェア開発工程

もも

ウォーターフォール

ウォーターフォール、ウォーターフォールモデル、ウォーターフォール開発手法は、前もって決められた作業工程に従って進められる開発手法のこと。
開発プロジェクトを時系列に、「要求定義」「外部設計(概要設計)」「内部設計(詳細設計)」「開発(プログラミング)」「テスト」「運用」などの作業工程(局面、フェーズ)に分割し、線表(ガントチャート)を使用してこれらの工程を順次進める計画を立て進捗管理をする。
原則として前工程が完了しないと次工程に進まない(設計中にプログラミングを開始するなどの並行作業は行わない)事で、前工程の成果物の品質を確保し、前工程への後戻り(手戻り)を最小限にする。
ウォーターフォール・モデルの利点は、工程の進捗管理がしやすいことである。
対義語は「アジャイル」。
[参考:Wikipedia]

もも

アジャイル

アジャイル、アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 近年、アジャイルソフトウェア開発手法が数多く考案されている。
対義語は「ウォーターフォール」

[出典:Wikipedia]

もも

VNC

Virtual Network Computing(ヴァーチャル・ネットワーク・コンピューティング、略称VNC)は、ネットワーク上の離れたコンピュータを遠隔操作するためのRFBプロトコルを利用する、リモートデスクトップソフトである。VNCはクロスプラットフォームなソフトウェアとして開発されているため、インストールされているマシン同士はOSなどのプラットフォームの種類に依存することなく通信できる。

[出典:wikipedia

もも
もも
もも
もも
もも
もも
もも
もも
もも
もも
もも

基本から学ぶソフトウェアテスト

 高品質なソフトウェア開発のために、さまざまな開発プロセスや管理手法が提唱されているが、その最後の砦(とりで)ともいえるのがソフトウェアテストである。本書は、テスト技法のみにとどまらず、計画、管理に至るまで、あくまで現場主義、実用主義に基づいて解説を行っており、ソフトウェアテスト解説の集大成といえる。今日のPCソフトウェア開発現場で長く望まれていたものだ。  ソフトウェアテストに関しては、いくつかの古典的な名著があるが、技法を重視したものや学術的なものが多かった。本書は、厳しいスケジュールとより少ない予算、人員で開発を行わなければならず、かつ十分な品質が要求される今日のソフトウェア業界にとってよりふさわしい内容となっている。 「基本から学ぶ」という本書のタイトル通り、内容は具体的でわかりやすい。テスト対象となるプログラムの分析方法や効果的なテストケースの作成方法、障害レポートの記述方法や障害の再現方法などを解説している。経験の浅いテストエンジニアにとっては、短期間で十分な知識を身に付けられる、ありがたい書である。さらに、プロジェクト管理者やテストチームリーダーレベルの読者を対象として、障害管理データベースの構築、テスト自動化、テスト計画、テストチームの管理など、テスト技法から一歩踏み込んだ内容も取り上げられている。  また、本書で取りあげられているトピックをいくつか挙げてみると、ソフトウェアのローカライゼーション、構成テスト、ユーザマニュアルやオンラインヘルプなどのドキュメントテスト、さらにはソフトウェアの不具合に対する法的責任などがあり、ソフトウェアテストの範ちゅうとして考えられるあらゆるものが、具体的に解説されている点も特筆したい。  テストエンジニアにとっては必携の1冊。また、プログラマーにとっても、高品質ソフトウェア開発のためのヒントがちりばめられている。(福島紀行)

著者Cem Kaner、Hung Quoc Nguyen 、Jack Falk
翻訳テスト技術者交流会
出版社日経BP社
発売日2001/11/25
形式単行本
ページ数471ページ
購入アマゾンへ行く
もも