“確実な記録”こそが、品質・コストに貢献する
“形だけ”になりがちなソフトウェアレビュー 近年、ソフトウェアレビューに対する認知はますます向上しつつあります。例えば商用開発なら、「要件定義」「設計書」「ソースコード」「テスト計画」「運用手順書」などを対象としたレビューが実施されていますし、オープンソースソフトウェアのプロジェクトなら、ソースコードリポジトリへのチェックインの前にソースコードレビューを推奨したり、義務付けたりしています。 その背景として挙げられるのは、ビジネスや社会におけるITの重要性が高まっていることでしょう。われわれの日常にこれだけITが浸透しているいま、ソフトウェアの品質は、システムの運用に大きな影響を及ぼします。その品質が低下すれば、ビジネスなら機会損失や収益悪化、社会的信用の失墜につながりますし、社会インフラなら公共交通機関などのサービスがストップすることも起こり得ます。ソフトウェアレビューの認知度が向上してい
レビューで失敗しない8つのポイント
ソフトウェア開発の品質・効率向上に欠かせないレビュー。しかし、やり方を間違えているために、かえって逆効果になっているケースが多い。本連載ではソフトウェアレビュー研究の第一人者、森崎修司氏が豊富な現場経験と研究成果を基にレビュー成功のポイントを分かりやすくリアルに解き明かす。 なぜレビューがうまくいかないのか？ ソフトウェア開発の品質・効率向上が求められている今、ソフトウェアレビュー（以下、レビュー）の重要性はますます高まっています。商用開発では「要件定義」「設計書」「ソースコード」「テスト計画」「運用手順書」などを対象としたレビューが行われていますし、オープンソースソフトウェアのプロジェクトでも、ソースコードリポジトリへのチェックインの前にソースコードレビューを推奨したり、義務付けたりしています。 しかし、レビューは自由度の高い活動です。レビュー会議では本質的な欠陥や問題を指摘しても、欠陥
開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経
時々組織の内外で盛り上がるネタの一つに「設計書は必要なのか」談義がある。今回も後輩の一人から設計書不要論がぶつけられてきたので、現時点での個人的見解をまとめておくもの。個人的には、ソフトウェアの設計書は必須でもないし、開発戦略を練る段階で作成するかどうかを決めればいいと思っている。 議論の前提：仕様書と設計書 議論を簡単にするために、まず「仕様書」と「設計書」という言葉を再定義しておきたい。今回の整理は以下としている。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 要は今回議論しようとしている「設計書」は、ユーザー(仕様決定者)とは無関係なものであるという前提である。また、ここ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
