ポイント: ソフトウェア開発ライフサイクル (SDLC) は、要件分析、実現可能性調査、デプロイメントなどのフェーズを含む構造化されたソフトウェア開発プロセスを概説します。それは、アジャイルやウォーターフォールのような手法を通じて、ソフトウェアの品質とユーザー満足を向上させます。
- SDLCはクロスファンクショナルチーム間のコラボレーションを促進します。
- 現代のフレームワークは反復的で段階的な開発を可能にします。
ソフトウェア開発ライフサイクル (SDLC) は、ソフトウェア開発に対する体系的アプローチを説明します。本記事では、以下を見ていきます:
ソフトウェア開発ライフサイクルとは？
SDLCは、高品質なソフトウェアが迅速かつ最適なコストで構築され、エンドユーザーにリリースされることを保証するのに役立ちます。ソフトウェアの品質をどのように判断するかは異なるかもしれませんが、一般的な測定基準には以下が含まれます:
- ソフトウェア機能の堅牢性
- 全体的なパフォーマンス
- セキュリティ
- 最終的にはユーザーエクスペリエンス
あなたがどのソフトウェア開発手法を支持するにせよ—アジャイル、ウォーターフォール、または他のバリエーション—このライフサイクルは適用されます。
誰がSDLCを使用するのか？
それほど前ではありませんが、ソフトウェアの品質の父として知られるWatt S. Humphreyは次のように述べました:
“すべてのビジネスはソフトウェアビジネスである。
最近では、MicrosoftのCEO Satya Nadellaがこの言葉を繰り返しました: “すべての会社はソフトウェア会社である”。
もちろん、ソフトウェアを開発する特定のテクノロジー企業を挙げることはできます。アプリがあれば、誰かがそれを開発しました。
しかし、「ソフトウェアの中にいない」ビジネス組織は、ビジネスを行うためにソフトウェアとテクノロジーに依存しています（つまり、すべての組織がそうです）。これらの組織は、少なくとも一部の市販ソリューションを適応させる必要があり、独自のビジネスオペレーションに合わせてソフトウェアを調整することが多いです。
だからこそ、開発者やエンジニアだけでなく、人々はSDLCアプローチを理解する必要があります: 多くの利害関係者がさまざまなステージに関与する可能性があります。さらに、クロスファンクショナルチームは、アジャイルおよびDevOpsベースのプロジェクトにおいてSDLCを採用することがあります。最新のSDLCプラクティスとフレームワークに従うことで、ソフトウェア開発プロセスを大幅に改善できます。
では、誰がSDLCを使用するのか？短く言えば、全員です。
SDLCは、ソフトウェア開発に関与する一連のフェーズに従います。SDLCフレームワークによっては、これらのフェーズは順次または並行して採用されることがあります。(以下で詳しく説明します。)
SDLCワークフローは、最終フェーズに到達する前に、フェーズ間で繰り返しの移行や反復を含むことがあります。
SDLCのステージ
フェーズ1: 要件分析
SDLCの最初の段階では、組織の技術、ビジネス、およびリーダーシップセグメントの利害関係者が関与します。この初期段階では、次のことを行います:
- コスト、パフォーマンス、機能性、リスクなどのさまざまな要因を考慮して、ビジネスの質問をエンジニアリングの問題に分析し、翻訳します。
- プロジェクトの広範な範囲を評価し、利用可能なリソースを特定します。
- 各SDLCフェーズの意思決定選択において、技術的およびビジネス的な観点からプロジェクトの機会とリスクを考慮します。
この段階は長期間続く可能性があり、SDLCが進化するにつれて戦略的な変更を行うための準備が含まれます。
(ソフトウェア要件仕様を書く方法を学ぶ。SRSとも呼ばれます。)
フェーズ2: 実現可能性調査
この段階では、要件の実現可能性を評価します。すべての要件が現在の範囲で実現可能であるわけではありません。この段階の目標は、合意された要件に対処するための機会とリスクを、利用可能なさまざまなリソースと戦略で定量化することです。
実現可能性調査は、以下の主要な側面を評価します:
- 経済的: 利用可能なリソースに基づいて、プロジェクトに投資することは財政的に実行可能ですか？
- 法的: 規制の範囲と、組織が遵守を保証する能力はどのようになりますか？
- 運用的: 提案された運用フレームワークおよびワークフローに従って、範囲定義内で要件を満たすことは可能ですか？
- 技術的: SLDCプロセスをサポートするための技術と人材リソースの可用性はどうですか？
- スケジュール: プロジェクトを時間内に完了できますか？
経営者は、これらの質問に答え、文書化し、注意深く検討する必要があります—ソフトウェア設計および実装プロセスに進む前に。
フェーズ3: アーキテクチャ設計
次に、適切な技術的およびビジネスの利害関係者が、リスク、機会、実用的な手段、および制約に対して設計仕様と選択を文書化、レビュー、および評価します。
このフェーズでは、次のような技術文書が必要です:
- システムアーキテクチャ
- 構成
- データ構造
- リソース調達モデル
期待される成果物には、プロトタイプ、擬似コード、最小実行可能製品 (MVP)、および必要な技術詳細を含むアーキテクチャレポートや図が含まれます:
- 高水準の設計詳細には、ソフトウェアとシステムモジュールの望ましい機能が含まれます。
- 低水準の設計詳細には、機能ロジック、インターフェース詳細、依存関係の問題、およびエラーが含まれる場合があります。
フェーズ4: ソフトウェア開発
実装は設計フェーズに続きます。複数の独立したチームと個人が、機能の開発やコーディング活動に協力します。頻繁に、個々の開発者は、自分の開発環境内で独自のコードベースを構築し、その後、共同作業チームと共通のビルド環境で統合します。
要件分析と設計の選択はすでに定義されていますが、開発チームからのフィードバックは、設計戦略の方向性の変更の可能性についてレビューされます。
これは、SDLCパイプラインで最も長いプロセスであり、その後のソフトウェアテストおよびデプロイメントのフェーズに役立ちます。
(振る舞い駆動開発を探求する、ソフトウェア開発の一つのアプローチです。)
フェーズ5: テスト
このフェーズでは、次の目的でテストを使用します:
- ソフトウェアのパフォーマンスを調査する
- 修正または対処すべき潜在的な問題を発見および特定する
テストチームは、事前定義されたソフトウェア要件に基づいてテスト計画を作成します。テスト計画は以下を含むべきです:
- テストに利用可能なリソースを特定する
- テスターのための指示と割り当てを提供する
- 実施するテストの種類を選択する
- 技術的な経営者や意思決定者に報告すべき内容を決定する
テスターはしばしば開発チームと協力して作業し、テスト結果を改善するためにコードベースを再作業します。
開発とテストのフェーズを何度も繰り返すことは非常に一般的であり、その後、ソフトウェアのデプロイとリリースの最終段階に進みます。
(テストの自動化や、回帰テスト、BDD、TDDなどのテストフレームワークの利点を考慮してください。)
フェーズ6: デプロイメント
必要なテストに合格した完成品があると、SDLCパイプラインの最終フェーズに到達しました。今、実環境でエンドユーザーにリリースするために利用可能にします。ソフトウェア製品を出荷する前には、以下のような手続きや準備活動が含まれます:
- 文書
- 所有権とライセンスの移転
- 顧客システムへの製品のデプロイとインストール
(デプロイメントおよびリリースステージについてもっと学ぶ。)
従来のSDLC手法と現代のSDLC手法
従来のSDLC手法、例えばウォーターフォールでは、これらのフェーズは独立して異なるチームによって系列的に実行されます。アジャイル手法の下では、これらのフェーズは短い反復的で段階的なスプリントで実行されます。
SDLCパイプラインとフレームワークは、それを採用する組織の数と同様に多様であり、ほぼすべての企業は自社に最適な戦略を採用しようとします。
しかし、今日のソフトウェア開発の時代において、これらの段階は常に順次に従われるわけではありません。現代のSDLCフレームワークは、DevOpsとアジャイルを含み、クロスファンクショナルな組織がこれらのフェーズ間で責任を共有できるように促します。
たとえば、DevOps SDLCフレームワークは、開発者、運用者、QA担当者が共同で継続的な開発、テスト、およびデプロイ活動を行うことを促進します。さらに、テスト手順は左にシフトし、早期にSDLCパイプラインで実施されるため、ソフトウェアの欠陥が修正するには遅すぎる前に特定されます。
関連する読み物
- BMC DevOpsブログ
- ソフトウェアファクトリーになる方法と理由
- 継続的インテグレーション (CI)、デリバリー (CD)、デプロイメントの違い
- DevOpsのためのSDLCにおけるオーケストレーション
- アジャイルの役割と責任
- マイクロサービスアーキテクチャを構築するための15のベストプラクティス
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を表すものではありません。