開発プロセス

当事務所における標準的なソフトウェア開発プロセスをご説明します。

企画 ヒアリング まずはお問い合わせをいただいた時点で、案件の概要や規模、納入時期などを伺います。電子メールや電話では十分に内容を把握できないと判断した場合は、直接お客様のところに訪問させていただきます。
要求定義 ヒアリングの結果を元に、開発対象システムの目的と範囲、必要とされる基本的な機能、品質レベルなど、案件の要求を定義します。要求定義は、開発対象システムのイメージを共有するための重要な作業ですので、お客様のご協力が不可欠です。
スケジューリング 案件の概略に基づいて大まかな開発計画を立てます。
見積もり 要求定義と開発計画を元に開発料をお見積もりします。ただし、案件によっては分析工程を経ないと正確な見積もりを用意できないことがあります。この場合は、分析工程のみの契約を結び、その結果に基づいて企画を練り直すことになります。
契約 これまでの作業の結果が妥当で、当事務所に発注する意思をお持ちになれば、ここで正式に契約を結び、開発プロジェクトを発足させることになります。
分析 要求分析 要求分析の目的は、要求を吟味し、開発対象システムの概念モデルを確立することです。開発対象システムをブラックボックスとして捉え、要求の本質をユーザーの視点で掘り下げます。
プロトタイピング ソフトウェア開発では、実際に動くものを見るまで、はっきりした要求を提示できないことが少なくありません。特にユーザーインターフェイスに関する要求はこの傾向が顕著です。そのような場合は、簡単なプロトタイプを作成し、完成時のイメージを明らかにしていきます。ある特定の技術に依存する案件では、その実現可能性を評価するために、詳細まで作り込んだプロトタイプを用意することもあります。
設計 基本設計 開発対象システムの論理モデルを確立し、全体像を把握することが基本設計の目的です。要求分析が開発対象システムの外側に注目しているのに対し、基本設計ではその内側に注目します。要求を実現するのに最適なアーキテクチャを選択し、個々の機能をオブジェクト同士の相互作用へと展開します。
詳細設計 基本設計だけでは不十分な場合、必要に応じて詳細設計を実施します。オブジェクトの状態遷移やスレッドの同期など、慎重な設計が求められる部分を重点的に掘り下げます。
実装 プログラミング 基本設計および詳細設計をプログラミング言語で書かれたソースコードへと展開します。プログラミング言語によっては、最終的に実行可能ファイルをビルドします。必要に応じてインストーラも作成します。
オーサリング ヘルプファイルやマニュアルを制作します。ただし、マニュアルについては版下作りを支援するくらいしかできませんので、本格的なマニュアルを制作する場合は専門業者に委託することをお勧めします。
検査 単体テスト 基本設計および詳細設計の内容がソースコードに正しく反映されているかどうかを検査し、発見された不具合を修正します。また、新しい機能を追加するごとに回帰テストを行い、ソースコードの品質レベルを一定の水準に維持します。
総合テスト インストールから実際の運用、アンインストールまで、要求定義および要求分析の内容が満たされているかどうかを総合的に検査し、発見された不具合を修正します。できるだけ多様な環境でテストするために、当事務所では Virtual PCVMware などの仮想マシンを積極的に利用しています。
βテスト 開発したソフトウェアが実用レベルに達した時点で、お客様に出来具合を確認していただくことがあります。
納入 検収 所定の納入物一式を光ディスクまたは他の電子的な手段でお渡ししますので、受け入れ条件を満たしているかどうかを確認してください。検収に合格した時点で正式に納入完了となります。
請求 検収が済み次第、請求書をお送りします。契約に従って開発料をお支払いください。
保守 瑕疵修補 一般的な案件であれば検収から1年間は、開発したソフトウェアの瑕疵(要求仕様との不一致、不具合)を無償で修補します。ただし、瑕疵が当事務所の責めに帰すものでない場合は、別途ご相談させていただきます。
運用支援 納入したソフトウェアを継続的にメンテナンスする必要がある場合は、別途保守契約を結びます。
アップグレード 納入したソフトウェアの機能追加や性能向上など、アップグレードの計画はお気軽にご相談ください。

ここでご説明した開発プロセスは典型的なウォーターフォール型プロセスの例であり、実際の開発では案件の内容に応じて適切なプロセスを採用します。たとえば近年では、スパイラル型プロセス、インクリメンタル型プロセスなど、要求仕様の変化に対応しやすいアジャイル(agile)な開発プロセスが注目されています。要求仕様が流動的な場合は、ウォーターフォール型プロセスよりも、ソフトウェアを徐々に成長させていく手法が適しています。