SDLCフェーズ[説明]:2021年に優れたソフトウェアを作成する方法
公開: 2019-10-02目次
SDLCプロセスを理解する
ソフトウェア開発プロセスの構造
SDLCモデル
要約
ソフトウェア開発業界は活況を呈しています。 私たちは毎年大量のコードを作成し続けています。
業界の中核となるのは、ソフトウェア開発ライフサイクル(SDLC)です。これは、ソフトウェアチームが作業を構造化および計画する方法をガイドするプロセスです。
それでは、ソフトウェア開発の危険な領域を旅してみましょう。
SDLCが実際に何であるかを見て、その進化を追跡します。 業界で使用されている主なモデルを確認します。
ソフトウェアの一部が日の目を見る前に通過するSDLCフェーズと、各フェーズの主要な実行者について説明します。
最終的には、プロセス全体の鳥瞰図を提供します。
SDLCプロセスを理解する
ソフトウェアの構築はプロセスです。 そのため、明確に定義された目標、それを達成するための手段、および結果を測定、維持、改善する方法が必要です。 ソフトウェア開発へのさまざまなアプローチがそれらすべてを提供します。 ただし、すべてが同じ布から切り取られているわけではありません。 状況によっては、大きく異なるアプローチを選択する必要がある場合があります。
これは、次のような多くの変数に依存します。
- 業界
- 組織の規模
- チームとプロジェクト
- 推定時間枠
- と割り当てられた予算。
一般的なのは、ソフトウェアの各部分が特定のSDLCプロセスフローに従うことです。
このフレームワークは、完了までに必要なフェーズ、必要なリソース、および途中で実行するタスクを具体化します。
SDLCプロセスは、最終的に達成する必要があるものの十分に構造化スケジュールです。 推定時間とコストの制限内で最適なソフトウェア開発アプローチを決定します。
SDLCは、情報システムを開発するための最も古いフレームワークである、より広い用語「システム開発ライフサイクル」のサブセットと見なされることがよくあります。
大量のデータを処理できるビジネスシステムの必要性への対応として、1960年代初頭に登場しました。 最初の十分に文書化されたSDLCフレームワークは、1969年の構造化プログラミングパラダイムです。
1990年代には、さまざまなソフトウェア開発手法が登場しました。 それらのいくつかは、オブジェクト指向プログラミング、スクラム、およびRational UnifiedProcessです。 アジャイル統一プロセスは2005年に登場しました。
ソフトウェア開発プロセスの構造
ソフトウェア製品の開発は、よく調整された一連の段階です。 選択した開発アプローチに応じて、 SDLCステップの数は異なります。
SDLCの5段階および7段階のフレーバーを確認します。
5段階バージョン
ソフトウェア開発プロセスの5段階バージョンは次のようになります。
要件と分析
これは、クライアントや利害関係者とのやり取りが不可欠な重要なフェーズです。 彼らは期待される結果、すなわちソフトウェア製品の目標を決定する必要があります。 顧客の要求に加えて、考慮すべき他のあらゆる種類の要因があります。 これらには以下が含まれます:
- 建築
- 機能的
- 機能しない
- パフォーマンス
- そしてデザイン関連のもの
この段階を正常に完了するために、「ソフトウェア要件仕様」と呼ばれるドキュメントが作成されます。 それは、この瞬間から起こるすべての基盤です。
開発プロジェクトの成功は、要件分析に大きく依存します。 この段階での主要な実行者は、ビジネスアナリスト(BA)です。 彼はすべてのコミュニケーションを管理して、ビジネス要件を収集し、徹底的な分析を実行し、最も重要なこととして、利害関係者と開発者の間でその情報を翻訳します。
設計
ソフトウェアの設計は、確立された要件に基づいています。 ここで、開発環境、プログラミング言語、アーキテクチャフレームワーク、ハードウェアなどを把握します。また、使用するテスト戦略を決定する時期でもあります。 ここでは、システムアーキテクトの役割が不可欠です。 彼らは、「要件仕様」ドキュメントのすべての前提条件を検討し、次のステップで使用する設計用紙を提供する必要があります。
コーディングフェーズ
今では、開発者はすでに設計仕様をよく知っています。 作業はモジュールに分割され、コーディングが始まります。 お客様もこの段階で関与する必要があります。 彼らは、製品が彼らの期待に応えるためにすべての措置が講じられていることを確認します。 動作するソフトウェアを作成することは、この段階での最終的な結果です。
テスト
実行可能な製品ができたので、テストフェーズを開始できます。 設計仕様書に概説されているテスト戦略に応じて、これはさまざまな方法で発生する可能性があります。
それにもかかわらず、目標は同じままです。 まず、すべての初期要件が満たされていることを確認し、次に、コードにバグがあるかどうかを判断します。 ここでは、テスターが主要なパフォーマーです。 彼らの努力の結果、完全に機能するソフトウェアがリリースされる準備が整いました。
メンテナンス
完璧なソフトウェア製品というものはありません。 そのため、開発プロセスではカスタマーサービスが大きな役割を果たしています。 エンドクライアントに配信されると、リアルタイムの問題が発生し、修正する必要があります。 顧客を満足させたいのであれば、継続的なメンテナンスは必須です。
7段階バージョン
さて、このプロセスの7段階のフレーバーは少し異なります。 それにはいくつかの追加の段階があり、必然的に他の段階も変化します。 見てみましょう:
計画
SDLCプロセスを開始するもう1つの方法は、計画フェーズを使用することです。 要件の収集に先行し、主にフィードバックを求めます。 利害関係者、ビジネスパートナー、エンジニア、およびエンドクライアントからの意見が、プロジェクトの範囲を形作ります。 このフェーズでは、次のような質問に答えます。
- 何をしなければなりませんか?
- どのようなリソースが必要ですか?
- どれくらいの時間がかかりますか?
- いくらかかるでしょうか?
要件と分析
ここで、ビジネスアナリストは、クライアントからのフィードバックに基づいて、要件のリストを作成します。 次に、これらをソフトウェアエンジニアに提供します。 コミュニケーションは不可欠です。
このフェーズでは、すべての要件の概要を説明するドキュメントを作成する必要があります。これは、次のフェーズの基盤として機能します。
システムデザイン
ソフトウェア要件は、システムアーキテクチャに組み込まれるようになりました。 この時点で、プロジェクトを提供するために必要な機能的な手段と操作を決定できます。 準備ができたら、設計計画がビジネスに提示されます。 実際のプログラミングを開始する前に、すべてのフィードバックを組み込みます。
ソフトウェア開発
要件が明確になると、ソフトウェアエンジニアは作業を開始できます。 この段階での目標は、テストの準備ができている作業プログラムです。 これは、 SDLCプロセスでの生産の開始でもあります。
テスト
品質保証チームの役割は、最初のビジネス要件が満たされているかどうかを確認することです。 彼らはソフトウェアコードの品質を検査します。 バグが修正されます。 機能、統合、パフォーマンステストなど、実行するソフトウェアテスト方法の全リストがあります。
自動化テストは、BambooやJenkinsなどの外部ソフトウェアを使用して反復テストを実行するプロセスを自動化する方法です。
実装
コードがテストフェーズに合格すると、本番環境にデプロイする準備が整います。 会社の方針によっては、このプロセスには承認が必要な場合があります。 ただし、ほとんどの場合、これはソフトウェア開発ライフサイクルの自動化されたステップです。
メンテナンスと運用
ソフトウェアが本番環境でリリースされると、あらゆる種類の問題が発生する可能性があります。 監視を通じて、それらを識別して解決することができます。 新機能も製品に取り入れることができます。 これは、パフォーマンスを測定して改善できるフェーズです。
SDLCモデル
ソフトウェアを開発するプロセスは、おおむね普遍的です。 ステージを追加したり、既存のステージを簡素化したりする余地はありますが、ほとんど同じです。
これは、開発方法を見ると当てはまりません。 彼らは皆、プロセスを観察していますが、それを行う方法は大きく異なります。
最適なものを選択するには、考慮すべきいくつかの重要な要素があります。 それは常に、クライアントのニーズとソフトウェア開発の実際的な詳細との間のバランスです。 次のような要因があります。
- プロジェクトの複雑さ
- 選択したテクノロジー
- とチームのサイズ。
これらすべてが、どのアプローチが最も効果的かを決定します。 最も広く知られ、使用されているSDLC方法論の概要を説明します。
滝
ウォーターフォールモデルは、線形の順次設計プロセスです。 これは、ソフトウェアエンジニアリングで使用される最も古い既知の方法論です。 それは1970年代に製造業と建設業で始まりました。
ウォーターフォールモデルに従った開発プロジェクトの進捗は、厳密にSDLCパイプを下っていきます。 進行は、SDLCの前のフェーズが正常に完了した場合にのみ可能です。 後戻りするための定義されたプロセスはありません。
SDLCの滝は非常に体系的なアプローチです。 次の場合にうまく機能します。
- 要件とアクティビティは明確に定義され、理解されています
- 技術は信頼できます
- サポートチームが利用可能であり、短期プロジェクトを見積もります
この方法の欠点は、柔軟性の欠如に関連しています。 途中で新たに出現する要件を実装することはできません。 開発プロセスの後半まで具体的な製品が生産されないため、リスクと不確実性が高くなります。 プロジェクトの要件や範囲をその場で変更することにした場合、非常に費用のかかるアプローチになる可能性があります。
反復
この方法は、一連の反復サイクルを通じてソフトウェアを構築できるという概念に基づいています。 それは、単純な一連の要件から始まります。 各ラウンドで、エンジニアは以前のバージョンのソフトウェアの動作から学び、その機能を強化することができます。
このアプローチの最大の利点は、各サイクルが完了した後にソフトウェアの実用的なプロトタイプが作成されることです。 これにより、変更の実装、リスクの特定が容易になります。 各反復で行ったときにSDLCテストは比較的簡単です。
ソフトウェア開発の反復モデルの欠点は、リソースとコストにあります。 反復回数を増やすと、より多くのリソースが消費されます。 プロジェクトの完了期限は未定であり、リスクも未定です。 したがって、この方法を機能させるには、リスク分析を実行する高度なスキルを持つ専門家が必要です。
この方法論は、小規模なプロジェクトには適していません。
アジャイル
ソフトウェア開発へのアジャイルアプローチは比較的新しいものです。 それでも、それは世界中で急速に人気を得ています。
アジャイルSDLCは、ワーキングソフトウェアの小さな部分を提供し、クライアントからの即時のフィードバックを求めているに基づいています。 このアプローチの中核となるのは、チーム間の強力なコラボレーションと継続的なコミュニケーションです。 各サイクルは約1〜3週間続き、その時点で作業モジュール/機能がクライアントに配信されます。 その後、このプロセスが繰り返されます。
テストは各反復で実行されるため、問題を早期に解決できます。 ソフトウェア機能のデモンストレーションとフィードバックの取得を奨励します。 モデルは、結果の明確な可視性を提供します。 チームワークを提唱し、ソフトウェアエンジニアに柔軟性を与えます。
大量の文書化の要件がないため、特定の個人に依存するリスクがあります。 これは、チームの新しいメンバーへの知識の伝達に関しても課題となる可能性があります。
傾く
リーンソフトウェア開発方法論は、アジャイルソフトウェア開発方法の一部と見なされます。 リーン方法論以下のSDLCプロセスは7つの原則から構成されています。
- 無駄をなくす
- 学習を増幅する
- できるだけ遅く決定する
- できるだけ早く配信する
- チームに力を与える
- 整合性を構築する
- 全体像を見る
このモデルを理解するための鍵は、これらの原則を通してです。 それは、それらを機能的なアジャイルプラクティスに変換し、それらを作業プロセスに実装することにつながります。
リーン原則は、品質、速度、コスト、およびビジネスの期待を最適化しながら、エンドユーザーに可能な限り多くの付加価値を生み出すという考えに基づいて構成されています。 この目的のために、いくつかのタスクは排除され(重いドキュメント)、他のタスクは最適化されます(会議の頻度)。
DevOps
DevOpsモデルは、部分的にアジャイルとリーンの両方に基づいています。 これは、開発ライフサイクル全体を通じてソフトウェア開発チームと運用チームの間の緊密なコラボレーションを結び付ける、新たに出現したアプローチです。
この方法論の重要な側面は、開発プロセスの自動化に重点を置いていることです。 最終的な目標は、SDLCを短縮すると同時に、ビジネス要件に沿った高品質で革新的な結果を提供することです。
このアプローチでは、開発者、運用チーム、および品質保証メンバーがすべて同じページにいます。 彼らは同じツールを使用し、同じプロセスに従います。 これによりコミュニケーションが改善され、より良いタイムリーな結果が得られます。
螺旋
これは、反復型開発とウォーターフォールモデルのいくつかの概念の組み合わせです。 これにより、各反復サイクルでソフトウェアを部分的にリリースできます。
4つの段階と繰り返しは「スパイラル」と呼ばれます。 SDLCのフェーズは以下のとおりです。要件のプランニングと収集。 設計; 開発とテスト。
リスク分析は重要な役割を果たします。 各スパイラルでリスク分析が実行されるため、潜在的なリスクを特定して回避または克服できます。 管理とプロセス自体は複雑になる可能性がありますが、大規模なプロジェクトに適しています。
要約
ソフトウェア開発への適切なアプローチを選択するには、重要な調査が必要です。 プロジェクトの範囲、要件、および目標を定義することにより、製品が実行する必要のあるSDLCフェーズを決定できます。
選択する方法論は、機能的な製品を開発するためのプロセスだけではありません。 これは、組織とチームの価値観を調整して、調和のとれた作業環境を作成する方法です。
よくある質問
選択した方法に応じて、ソフトウェアはさまざまな数の段階を経ます。 次のアクティビティは、どちらの方法でもその一部である必要があります。
- 計画、要件の収集、および分析
- 設計またはシステムアーキテクチャについて合意する
- コードの生成
- 生成されたコードのテスト
- 実稼働環境へのコードのデプロイ
- 継続的なメンテナンスと改善
プレーニング; 要件と分析; 設計; 発達; テスト; 実装; メンテナンス。
それはあなたのプロジェクトに依存します! 業界の分析、プロジェクトの目標、利用可能な機能とリソース、時間とコストのメトリックは、最適なSDLC方法論を選択する際の指針となります。