開発プロセス

吉田誠一のホームページ   >   ソフトウェア工学   >   技術コラム

要件定義から設計、実装、テストに至るまでの、ソフトウェア開発プロセス全般について、技術情報やガイドラインを紹介します。

良いユースケースを書くための発想法

作成:2007年6月14日

ユースケースは上手く書けない、何を書けば良いのか分からない、という人も、少なくありません。

たいていのユースケースは、アクターが1人2人いて、アクターが行える操作がいくつか丸で描かれて、それらが線で結ばれているだけの、とてもシンプルなものです。しかし、シンプルすぎて、何の役に立つのか分からない、という人もいます。

役に立つユースケースを書こうとして、細かいことまで書き込みすぎてしまう人も良く見かけます。しかし、それは誤りです。

ここでは、良いユースケースを書くための考え方を紹介します。 ................

数値に基づく効果的なプロジェクトレビュー

作成:2005年11月7日

ソフトウェア開発のプロジェクトは、なかなか一筋縄ではいかない。予定通りに進まなかった原因、作業の遅れをもたらした問題点など、実際のプロジェクトから得られる教訓は大きい。

得られた教訓を活かし、次のソフトウェア開発をより良く進めるためには、プロジェクトを総括・反省する、プロジェクトレビューが重要となる。効果的なレビューを実践するには、プロジェクトを客観的に解析できるような具体的な資料を用意して臨む必要がある。そのためには、プロジェクトの実績を数値として算出することが大切だ。 ................

「やることリスト」に基づく見積もり手法

作成:2005年11月7日

業務としてソフトウェアを開発するならば、工数の見積もりは避けては通れない。見積もりは、ソフトウェア開発プロセスのはじめの一歩に過ぎないが、その成否はプロジェクト全体の命運を握ることになる。

小規模なソフトウェア開発では、見積もりのしやすさも重要になってくる。ここでは、ファンクションポイント法より簡潔で、直観的で、実利的な見積もり手法として、「やることリスト」に基づく手法を提案する。 ................

WBS(Work Breakdown Structure)によるプロジェクト管理

作成:2007年12月17日

筆者の開発プロジェクトでは、WBS (Work Breakdown Structure) を使ったプロジェクト管理を導入した。WBSは見積もりのための強力な道具として広く使われている。筆者はさらに、実績も管理できるようにWBSを拡張し、見積もりから進捗管理まで一貫して管理できる手法を確立した。

ここでは、筆者が拡張したWBSの書き方と、それを使ったプロジェクト管理の手法を提案し、実際の開発業務に適用した経験から得られたWBSの運用ノウハウを紹介する。 ................

WBS(Work Breakdown Structure)によるプロジェクト管理(旧稿)

改訂:2006年6月1日

WBSには、プロジェクトに関するすべての項目が、重複も漏れも無く書かれているので、プロジェクトを管理する上で、とても役に立つツールとなる。見積もりや作業の分担、進捗管理、工数管理などに、WBSを利用することができる。

ここでは、ソフトウェア開発プロジェクトの見積もりや工数管理を行うのに適した、WBSの作り方を紹介する。また、WBSを使ってプロジェクトを管理する上での、コツや注意点も紹介する。 ................

テスト項目のレビューは、項目を挙げる前に行おう

作成:2005年12月1日

テストは、ソフトウェアの品質を高めるために欠かせない、重要なプロセスだ。規模の小さいソフトウェア開発でも、テスト項目の数は数百、数千にもなることも珍しくない。

ふつうはテストを実施する前に、まず、テスト項目のレビューを行っているだろう。だが、どんなに時間や人を費してテスト項目のレビューをしても、どうしても項目の抜けや誤りを見落としてしまう、という人も少なくないだろう。 ................

バグを見つけるためのテストをしよう

作成:2005年12月16日

バグのあるソフトウェアでも、リリース前には、膨大なテスト項目をクリアしてきたはずだ。だが、そのほとんどは、仕様書や設計書から書き写しただけの、機能が正しく動くことを確認するものばかりになってはいないか。

テストしても見逃されるバグは、ソフトウェアを使い込んだり、ちょっと変わった操作をしたり、ある特殊な状況でのみ発生するものが多い。このようなバグは、意図的にバグを見つけようとしない限り、見つからないものである。 ................

リスク・ベース・テストの効果と限界

作成:2005年12月20日

ソフトウェアの開発サイクルが短くなっている現在では、短時間にいかに効率良くテストを行い、ソフトウェアの品質を高められるかが焦点になっている。テスト不足による品質低下に悩む人にとって、リスク・ベース・テストは効果的かつ魅力的な解決策である。

だが、リスク・ベース・テストが改善するのは、テスト・プロセスである。品質低下の原因がテスト・プロセスではなく、テスト項目そのものにある場合は、リスク・ベース・テストを導入しても、品質を高めることはできないだろう。 ................

テストファーストの弊害

作成:2006年1月13日

テストファーストは、短期開発におけるXPの有効性が認められ、JUnitなどのテストツールが普及した今では、広く受け入れられるようになった。だが、最近では「JUnitでテストコードを書いていれば、ソフトウェアの品質は問題ない」という風潮が広まりつつあるような危惧も感じる。

テストファーストの効果は、多くの人が認めるところだ。だが、ここでは敢えて、テストファーストがもたらす弊害について考えてみる。 ................

実践!電卓で学ぶソフトウェアテストのコツ

作成:2005年11月18日

品質の良いソフトウェアを作るためには、ソフトウェアテストの技術が不可欠です。

ソフトウェアテストの真髄は、奥深くに隠れているバグをいかに見つけ出すか、です。ソフトウェアをありとあらゆる方向から使いまくり、いじり倒して、バグを絶滅させなければなりません。

ここでは、Windowsに付いてくる「電卓」から、バグが見つけられるかどうか、試してみたいと思います。 ................

ソフトウェアテストにおけるリスクの捉え方 〜アメリカと日本の違い〜

作成:2006年2月7日

2006年1月に開催されたソフトウェアテストシンポジウム in 東京では、アメリカからリック・クレイグ氏が招待され、基調講演が行われた。クレイグ氏は、リスク分析を行い、リスクに基づいてテストの優先度を決める、という考え方を提唱した人である。

このリスクという指標は、テストケースやバグの重要性を評価する上で、たいへん分かりやすく、かつ有効である。だが、日本国内で使われているリスク分析と、クレイグ氏が提唱した本来のリスク分析には、大きな違いがあるように感じられる。 ................

実装が終わってからプログラム説明書を書こう

作成:2005年2月12日

ソフトウェアの開発では、ソースコードだけでなく、ドキュメントも残しておくことが重要である。ソースコードしかなければ、後になって機能追加を行うのも極めて難しくなってしまう。ドキュメントがあれば、新しい担当者はソフトウェアの作りをすぐに理解して、新たな改造に取り組むことができる。 ................

複雑なアプリケーションの機能仕様は、概念モデルで整理しよう

作成:2005年2月14日

機能豊富なアプリケーションの開発では、機能仕様の策定にもかなりの時間がかかる。特に、画面にたくさんのボタンが置かれていたり、いくつもの画面を並行して操作できるような、操作性の複雑なアプリケーションになると、ユーザインターフェースの機能仕様をまとめるだけでも、極めて大変な作業となる。 ................

技術者の評価を下げる「悪い」コメントに注意しよう

作成:2005年2月12日

ソフトウェアの受託開発や、オープンソースのプロジェクトでは、ソースコードが他の技術者の目に触れる。そのため、ソースコードから開発者の技術力が評価されやすい。 ................

Copyright(C) Seiichi Yoshida ( comet@aerith.net ). All rights reserved.