双子座山羊座SDM

Cap Gemini SDM、またはSDM2 (System Development Methodology) は、1970 年にオランダのソフトウェア会社 Pandata によって開発されたソフトウェア開発手法です。この手法はウォーターフォール モデルであり、開始と終了が^明確な 7 つのフェーズに分かれています。各フェーズでは、マイルストーンと呼ばれるサブ成果物が作成されます。この手法は、1980 年代から 1990 年代にかけてオランダの ICT プロジェクトで広く使用されました^{。Pandataは1980 年代に}Capgeminiグループに買収され、英語で出版された SDM の最終バージョンは、1991 年に Cap Gemini Publishing BV によって出版された SDM2 (第 6 版) でした。この手法は定期的に Capgemini のコンサルタントや顧客に指導され、配布されていましたが、Rapid application development、Rational Unified Process、Agile software developmentなどのより反復的なエクストリーム プログラミング手法の台頭により、ウォーターフォール手法は徐々に廃れていきました。

1970 年代前半から中頃にかけて、システム開発方法論のさまざまな一般的な作業ステップは、さまざまな構造化分析または構造化設計技法に基づく作業ステップに置き換えられました。SDM、SDM2、SDM/70、Spectrum は、Steven Ward、Tom Demarco、Larry Constantine、Ken Orr、Ed Yourdon、Michael A. Jacksonなどの研究、および Thomas Bachmann とPeter Chenが開発したデータ モデリング技法に基づくシステム開発方法論へと進化しました。SDM はトップダウン モデルです。システム全体から始まり、設計が進むにつれてその記述はより詳細になります。この方法は、顧客プロジェクトの品質を確保するためにすべての会社の開発者が使用する必要がある独自の方法として販売されました。この方法は、1990 年に CAP Gemini の最も重要な競合他社の独自の方法といくつかの類似点を示しています。後に 2002 年に法廷で同社自身に対して使用された同様のウォーターフォール方式は、CMG:Commander でした。^[1]

SDM は 1970 年に PANDATA という会社によって開発されました。この会社はCap Geminiの一部であり、Cap Gemini 自体はAKZO、Nationale Nederlanden、Posterijen, Telegrafie en Telefonie (Nederland)の 3 つのオランダ企業の合弁会社として設立されました。この会社は、この方法を開発し、この方法を普及させるためのトレーニング マテリアルを作成するために設立されました。この会社は成功を収めましたが、1987 年に改訂され、方法の理論が標準化され、方法の実装に使用されるより技術的な側面から分離されました。これらの側面は、"Software Development Workbench" と呼ばれるプロセス モデリング ツールにまとめられ、後に 2000 年に別のオランダ企業である BWise に売却されました。このツールなしの改訂版は、一般にSDM2として知られています。^[2]

SDM2 は SDM の改訂版で、SDM プロジェクトで頻繁に発生する基本的な問題、つまり納品されたシステムが顧客の要件を満たさないという問題を解決しようとしたものです。この問題にはさまざまな理由が考えられますが、SDM で使用される基本的なウォーターフォール方式では、定義調査フェーズと実装フェーズの間に開発チームが費やす時間が比較的長いため、この問題が生じやすくなりました。プロジェクトが顧客の要件と同期しなくなることがよくあったのは、設計フェーズのときでした。

SDM の機能設計フェーズである BD (基本設計) では、後の技術設計である DD (詳細設計) のために、設計面が詳細に文書化されていました (フェーズがずれていました)。このため、2 つのフェーズの間に責任のグレーゾーンが発生しました。BD のデータ フローとプロセス フローを担当する機能チームは、技術チームが後でコーディングする必要のある決定を下していましたが、その決定を下すのに十分な技術的知識がありませんでした。これは明らかに、BD フェーズと DD フェーズの両方でプロジェクト チーム間のコラボレーションに問題を引き起こしました。各フェーズの最後に Go/No Go を決定するウォーターフォール方式のため、技術チームは、基本設計の詳細セクションを修正するために正式な変更要求を行う必要がありました。このような変更は、変更凍結が実施された後でも、顧客要件から直接ではなくプロジェクト チームから発生したため、顧客を混乱させることがよくありました。通常、顧客は BD フェーズで機能設計までの要件のみを作成することが許可されていました。その後、顧客は実装フェーズの受け入れテストまで辛抱強く待たなければなりませんでした。

SDM2 では、「基本設計」という用語が「グローバル設計」という用語に置き換えられ、このドキュメントが継続的に更新され、BD フェーズと DD フェーズの両方で変更される可能性があることが示されました。したがって、「基本設計」は、プロジェクトの最後にはグローバルでありながら詳細になります。グローバル設計では、機能と構成の原則、およびそれらの関係が文書化されます。これが反復開発のアイデアの始まりです。機能設計は、実装用に選択されたテクノロジ プラットフォームによって本質的に影響を受け、初期の仮定が後で間違っていたり実装にコストがかかったりすることが判明した場合は、いくつかの基本設計の決定を再検討する必要があります。これが、ラピッド アプリケーション開発方法の先駆けとなり、この 2 つのフェーズが循環的になり、連携して機能するようになりました。

SDM2 は、顧客の要件を満たすという問題を部分的にしか解決していません。現代のソフトウェア開発手法では、たとえば増分配信を要求したり、顧客が配信されたシステムの主要ユーザーを任命してプロジェクトの最初から最後まで役割を果たすようにしたりすることで、さらに数歩進んでいます。

SDM はフェーズに基づいた方法です。各フェーズの前に、そのフェーズのアクティビティの詳細について合意する必要があります。これらのドキュメントは、マイルストーン ドキュメントと呼ばれます。これらのドキュメントには、いくつかの用途があります。

• 追跡可能性 - マイルストーン文書に期限を適用することで、クライアントはプロジェクトが予定どおりに進んでいるかどうかを追跡できます。
• 統合 — マイルストーン ドキュメントを承認すると、特定のステータスが付与されます。クライアントは、開発中に仕様を変更することはできません。
• 必要に応じて、プロジェクトを中止することができます。これは主に開発の開始時に発生します。

この方法では、ウォーターフォール モデルのように、連続して実行される 7 つのフェーズを使用します。フェーズは次のとおりです。

1. 情報計画：問題の定義と初期計画
2. 定義調査: 要件分析と修正計画
3. 基本設計: 高レベルの技術設計と修正計画
4. 詳細設計: システムの構築 (および修正計画)
5. 実現: テストと承認 (および修正された計画)
6. 実装: インストール、データ変換、本番環境への切り替え
7. 運用・サポート：ICTサポート部門への納品

フェーズが完了すると、次のフェーズに進むかどうかが決定されます。これには「Go」と「No-Go」という用語が使用されます。次のフェーズは「Go」が与えられるまで開始されませんが、「No-Go」が与えられた場合、プロジェクトは現在のフェーズに留まり改善されるか、完全にキャンセルされます。

このフェーズでは、プロジェクトで解決しなければならない問題が定義されます。現在の状況と望ましい状況が分析され、プロジェクトの目標が決定されます。このフェーズでは、将来のユーザーとその管理者など、すべての関係者のニーズを考慮することが重要です。多くの場合、彼らの期待は衝突し、後で開発中またはシステムの使用中に問題が発生します。

このフェーズでは、プロジェクトのより詳細な調査が行われます。組織を分析してニーズを特定し、システムが組織に与える影響を判断します。システムの要件について議論し、決定します。プロジェクトの実現可能性を判断します。実現可能性を判断するために考慮できる側面は次のとおりです。

• 推奨 — プロジェクトを完了するためのリソース (時間と知識の両方) が利用可能かどうか。
• 重要性 - 現在のシステムを置き換える必要があるか?
• 技術 — 利用可能な機器は、システムが要求する要件に対応できますか?
• 経済性 — システムの開発コストは、システムの使用から得られる利益よりも低いですか?
• 組織 — 組織は新しいシステムを使用できますか?
• 法律 — 新しいシステムは既存の法律に抵触しますか?

このフェーズでは、製品の設計が行われます。定義調査でシステムの要件が決定された後、設計でその実行方法を決定します。多くの場合、この結果、システムの各部分の動作を説明する機能設計またはユーザー インターフェイス設計と、システムの各部分の動作を説明する高レベルの技術設計の 2 つのドキュメントが作成されます。このフェーズでは、機能設計と技術設計を組み合わせ、システム全体の大まかな設計のみを示します。多くの場合、システムのアーキテクチャはここで説明されます。

SDM2 では、グローバル設計ドキュメントを作成するために、このステップを BD フェーズ用と DD フェーズ用の 2 つの部分に分割しました。

このフェーズでは、製品の設計が、ソフトウェア開発者 (および後の O&S フェーズでシステムのサポートを担当するチーム) に必要な専門用語で技術的に説明されます。基本設計が承認された後、技術的な詳細設計によって、ソフトウェアでの開発方法が決まります。これにより、多くの場合、機能ごとの機能設計と機能ごとの技術設計というソース ドキュメントのライブラリが作成され、システムの各部分がどのように機能し、それらが互いにどのように関連しているかが説明されます。

SDM2 では、このフェーズでは、より詳細な設計を作成したり、既存の詳細設計をさらに改良したりして、システム自体の構築に使用できるレベルまでグローバル設計を詳細化します。

このフェーズでは、設計が機能するシステムに変換されます。実際の方法は、使用するシステムによって異なります。古いシステムでは、プログラマーがすべてのコードを記述する必要がありましたが、新しいシステムでは、プログラマーが設計を直接コードに変換できるため、作業が少なくなり、エラーが発生する可能性が低くなります。同じタイプでは、システムは設計にさらに依存するようになります。設計が適切にテストされていれば、適切なコードが生成されますが、設計が完全に正しくなければ、プログラマーが問題を見つけなければ、コードは不正確になります。

実装、つまりテストのフェーズは、システム テストと受け入れテストの 2 つのステップで構成されます。

システム テストでは、開発チームまたは別のテスト チームがシステムをテストします。そのほとんどは技術的な側面に重点が置かれます。システムは期待どおりに動作するか、それともバグが残っているかなどです。このフェーズで見つかったバグは修正されます。このフェーズの終了時には、プログラムは正常に動作するはずです。

受け入れテストでは、エンド ユーザーがシステムをテストします。プログラムが期待どおりに動作するかどうかをテストします。考えられるすべてのシナリオをテストするわけではありませんが、プログラムが期待どおりに動作し、簡単に動作するかどうかをテストします。このフェーズで見つかったバグは開発チームに報告され、修正されます。

このフェーズでは、システムの最終バージョンが組織によって実装されます。ハードウェアがセットアップされ、ソフトウェアがインストールされ、エンド ユーザー ドキュメントが作成され、エンド ユーザーがプログラムの使用方法をトレーニングされ、既存のデータがシステムに入力されます。

システムが実装されると、組織内で使用されます。システムの存続期間中は、システムを継続的に実行し、必要に応じて拡張する必要があります。

• ソフトウェア開発方法論
• チェックリスト SDM アクティビティ (オランダ語)
• Association for Computing Machineryの SDM ブックの記録