各種の開発資料は「見たいときに、見たいところを、いつでも見る」ことができなければ、意味がないですね。第3回の実習で作った、対になったデータを材料に、データを検索できる仕組みを整えます。要件変更に強い仕組みを作り、可視化を実現します。

情シス部門のためにトレーサビリティを解説する連載の第3回。前回まではトレーサビリティの意味や、その重要性などについて説明をしてきました。今回は演習編ということで、実際に問題を出題し、解説しながら、トレーサビリティの方法論をお伝えしていきたいと思います。

今回は、もしユーザ主導のトレーサビリティを行わなかった場合、どんな不都合が起こるのか？ その重要性についてお話していきます。トレーサビリティは投資や工数見積もりの交渉道具ではありません。ユーザの道具として、正しく使いましょう。

皆さんのプロジェクトでは、トレーサビリティ（追跡可能性）活動を行っていますか？ 案外、耳にしたことくらいで具体的にはよく分かっていないという方も結構多いのではないでしょうか。この連載では、情シス部門が絶対に身に着けておくべきトレーサビリティ活動の進め方について解説します。

ソフトウェア構成管理を実施する目的は、構成を再現することです。そのためには再現するための目印が必要になります。今回は、「ベースライン」の考え方と「ビルド管理」についてお話します。

ソフトウェア開発の基本となる「テストのマインド」を紹介する連載の第2回。今回は、テストレベルの意義や、それに基づいた効果的なテスト設計を勉強していきます。もちろん今回も、成夫君と伝子ちゃんが一緒です。

バージョン管理を行っていないプロジェクトは少ないと思いますが、その考え方について「実は、イマイチ理解できていないんだよね」という人は意外に多いのではないでしょうか。この連載では、バージョン管理も含めた構成管理の考え方を解説します。

　システム開発は物つくりです。できた製品でシステムの成否が決まります。一方、システムを作る目的は、システム装置を飾るために欲しいわけではなく、それを使って新しいビジネスや商品を実現したいのですから、正しく動いて、期待通りのビジネスや商品が実現する。これが大切です。予算どおり、期限どおりに出来上がっても、不完全なシステムだったら困ります。バグがないことはもちろんのこと、非機能要求などもきちんと分析定義して、使ってみて満足のいくシステムとしなければなりません。直接、要件定義書やプログラムなどを見るレビューに加えて、プロジェクトレビューをうまく使い品質向上を実現しましょう。