最適なソフトウェア開発方法論を選択するためのフローチャート

エントリー

方法論の選択方法は？ 多くの場合、方法論の選択について決定を下す必要がある場合、頭の中には異種の情報が多すぎて、プロジェクトにとって最適なものを正確に理解することは困難です。 この記事では、最も重要な側面のいくつかに注意を引くためのヒントとして、最適な方法論を選択するフローチャートを示します。









まず第一に、特定の方法論を選択する際に、すべての状況に対して普遍的な一連の条件は存在しないことに注意してください。 いずれの場合も、プロジェクトの詳細に集中する必要があります。 考慮されるフローチャートは、主な側面のみを概説し、主な方法論の機能を思い出すことができるようにします。 いずれにしても、方法論を選択するための唯一の正しいガイドとしてそれを扱うことをお勧めしません。 さらに、オペレーティングシステムの作成、航空機のアビオニクス、核反応のシミュレーションなどの複雑なプロジェクトに拡張する価値はありません。



第二に、方法論の選択は盲目的にそれに従う必要はありません。 多くの場合、プロジェクトに合わせて「仕上げ」が必要です。 何かを捨てたり、他の方法論から何かを追加したり、何かを追加したりできます。 たとえば、ウォーターフォールモデルでペアプログラミングなどのプラクティスを使用することに煩わされる人はいません。 Habréには、スクラムとカンバンの特定のプロジェクトへの適応に関する優れた記事があり、この原則をよく示しています。



次の章では、記事で初めて耳にした人のために、記事で言及したライフサイクルの方法論とモデルについて簡単に説明します。 ウィキペディアでそれぞれについて詳しく読むことができます。 すでに知っている場合は、第2章「フローチャートの分析」に進んでください。

1.簡単な説明

ライフサイクルモデルは、開発プロセスが行われる方法の一般的な説明です。



方法論 -特定のモデルを実装する方法としての、ルール、プラクティス、および原則のより詳細なセット。 たとえば、スクラム方法論は反復開発モデルを実装します。



プロセスフレームワーク -大まかに言うと、これは多数のルールを含む方法論ですが、すべてのルールを使用する必要はありませんが、必要なものだけを選択して開発プロセスを構築できます。 ルールを表示および編集できる特別なアプリケーションが含まれています。 例：RUP、EssUp。



カスケードモデル （または滝のモデル、滝）-開発、分析、設計、実装、テストなどの段階が次々に進むという事実が特徴です。 開発プロセスを編成するための追加のオーバーヘッドコストなしで、システムを迅速に作成できます。 ただし、要件が安定しており、開発中に変更されない場合にのみ機能します。 すべての要件をすぐに説明し、すぐにシステム全体を設計します。



Vモデル -政府プロジェクトで使用するカスケードモデルを改善する方法として、ドイツとアメリカで発明されました。 V-Modelには、政府機関向けのプロジェクトの仕様があります：固定要件、コスト、時間。 違いは、分析および設計段階がテスト段階に関連付けられていることです。 たとえば、要件の分析中に、テストアプローチが同時に研究され、システムアーキテクチャの設計中に、高レベルのテスト計画とテストシナリオが開発され、システムコンポーネントの設計中に、コンポーネントとそれらの相互作用をテストする方法が研究され、テストスクリプトが作成され、テストを支援するためのユーティリティが記述され、スクリプトなど これらはすべて、要件をよりよく理解し、システムを設計するのに役立ちます。 ただし、ここでは、カスケードモデルと同様に、開発中に要件を変更することは望ましくありません。



スパイラルモデル -深刻なリスクがあるプロジェクトに焦点を当てています。 開発はスパイラルの形で提示されます。 スパイラルの各ターンは反復です。 スパイラルコイルは、計画、リスク分析、開発、顧客評価の4つの段階で構成されています。 各反復の終わりに、プロジェクトを続行するかどうかが決定されます。 特徴的な機能は、リスク分析の段階で、初期段階でリスクを解決するように設計されたプロトタイプ、コンセプト、モデルが作成されることです。 スパイラルムーブメントが遠いほど、製品開発が増え、プロトタイプとコンセプトが少なくなります。 このモデルの典型的なアプリケーションは、研究プロジェクトです。 これは非常に高価なモデルであり、リスクが無視できるシステムでは正当化されません。



反復モデル -開発中に要件が変更される可能性のあるプロジェクトに焦点を当てています。 プロジェクトは、反復で構成されます（1〜2週間から6週間）。 各反復には、分析、設計、実装、テストの段階を含めることができます。 カスケードモデルよりもプロセスの整理に大きなオーバーヘッドがありますが、プロジェクトの期間に応じてエラーを修正するコストはそれほど高くありません。 次の方法論は、反復モデルを実装します：スクラム、XP、一部カンバン。



スクラム方法論 -反復はスプリントと呼ばれます。 チームは3つの役割で構成されています：製品所有者（顧客代表）、スクラムマスター（プロセスを監視）、チームの残りの部分。 スプリントは、チームが反復のためのタスクを選択して配布し、スプリントバックログを形成する計画会議から始まります。 スプリントは、製品のデモが行われるスプリントレビューと、改善を議論するためのスプリントの回顧集会で終了します。 15分間のスクラム会議が毎日開催されます。



Extreme Programming Methodology （XP）-12のプラクティスで構成されます：ペアプログラミング、テストによる開発、リファクタリング、シンプルなアーキテクチャ、集合的なコードの所有権、継続的な統合、チームの顧客、頻繁なリリース、ゲームの計画、週40時間の作業、コーディング標準システムのメタファー。 必ず12のプラクティスすべてを使用してください。



かんばん方法論は、タスクのパイプラインです。 ルールは3つのみです。かんばんボードを使用した開発プロセスの視覚化、各段階でのタスク数の制限、チームのパフォーマンスの継続的な測定と改善です。



RAD （Rapid Application Development） 方法論は、迅速なアプリケーション開発に焦点を当てており、最も単純なアーキテクチャ、最小限のプロセスコストで、既成のコンポーネントと強力なツールを最大限に活用します。 プロジェクトの期間に制限があります-60〜90日。 私は半完成パテとの類推が好きです。 だから、RAD-既製のコンポーネントのパイをすばやく成形する必要がある場合。

2.フローチャートの分析

スタートアップの特徴は、特に初期の段階では、すべてが熱意に基づいて構築されているという事実です。 人々が1日8時間働くとは限りません。 彼らが何らかの方法論を課し、特定のフレームワークに入れると、すべての熱意が薄れてしまうか、誰も規則に従わないでしょう。 たとえば、コーディングの嵐の夜の後、午前中にスタートアップイニシエーターがスクラムラリーに参加することを期待するのはかなりばかげています。 将来、すべてが安定したら、適切な方法論の使用に進むことができます。







各プロジェクトにはリスクがあります。 ただし、この場合、リスクは非常に深刻であるため、システムをまったく実装できるかどうかは事前にはわかりません。 そのようなリスクが存在する場合、ほとんどの場合、プロトタイプ、概念、モデルなどで開発を開始します。 考えられたことの根本的な可能性を見つけるために。 この場合、スパイラルモデルが最適なモデルです。 このモデルのアプリケーションの典型的な例は、研究プロジェクトです。 しかし、このモデルの使用は研究プロジェクトだけに限定されません。



小売業界の実例：Bluetoothを介して特定の機器と積極的に対話することになっているモバイルアプリケーションを開発する必要がありました。 これらは、さまざまなカード、さまざまな種類のプリンター、バーコードスキャナーのリーダーでした。 これがモバイルプラットフォームでも可能かどうかはわかりませんでした。 そのため、私たちはプロトタイプとコンセプトから始めました。そこでは、機器との相互作用の基本的な可能性と既存の制限を見つけようとしました。 その後、お客様と会い、何が起こったのかを実証し、実装できないものの回避策について議論しました。







あなたの場合、そのような深刻なリスクがない場合、次の質問が発生します。要件が変更されますか。 要件が事前によく知られており、顧客が開発プロセス中に大きな変更を加えないことが確実な場合は、カスケード開発モデルを選択する必要があります。 プロジェクトの期間が短い場合は、カスケードモデルを選択することをお勧めします。 要件が明確で不変であり、所要時間が短い場合、カスケードモデルは反復モデルと比較してプロセスのオーバーヘッドが少なくなります。 プログラマーの実装の全段階で、コードの作成を妨げるものは何もありません。前回のイテレーションからバグを緊急に修正する必要も、無限の集会とリリースもありません。



ただし、長いプロジェクトの場合、カスケードモデルはうまく機能しません。 要件を変更するリスクはありませんが、技術的なリスクがあります。 たとえば、誤ったアーキテクチャを開発した場合、間違ったテクノロジーやツールを選択した場合、必要なパフォーマンスを計算しなかった場合など、最後にそのことを知る可能性が高く、修正する時間がない場合があります。 プロジェクトが長引くほど、エラーを修正するコストが高くなります。 初期段階でリファクタリングと基本コードの変更が簡単な場合、プロジェクトの最後にこれを行うことはかなり「苦痛」です。



実践例：デスクトップコンピューターの同じアプリケーションとまったく同じことを行うモバイルアプリケーションを実装する必要がありました。 したがって、要件はプロジェクト全体で既知であり、変更されていません。







次の質問は、要件が複雑かどうかです。 質問はまた曖昧であり、プロジェクトに依存します。 プロジェクトを開始するとき、分析と設計の段階でテストする方法を考えることが役立つ場合があります。 これにより、潜在的な問題を早期に特定し、アーキテクチャをより適切に実装したり、要件を解決したりすることができます。 要件が複雑な場合は、すべてのテストシナリオを注意深く検討し、分析と設計の段階で、テストアプローチ、テスト計画、およびテストケースを開発することをお勧めします。 この場合、カスケードモデルの一種であるVモデルが役立ちます。



要件が非常に単純なVモデルの適用は、システムがより高価になるという事実につながります。 さらに、Vモデルは多くのドキュメントと官僚主義を生み出し、実際に顧客を満足させる高品質のソフトウェアを作成するのではなく、プロジェクトの最後にシステムが本来必要だったように機能することを証明するという事実のために批判されています、本当に必要なものを開発する代わりに。







正式なアプローチでは、アプリケーションライフサイクルのすべてのプロセスが詳細に規制されます。 これは、大規模なチームを持つ複雑な大規模プロジェクトで必要です。



例は、人々の生活が依存するシステムです：医学、輸送、エネルギー。 通常、このようなシステムは業界標準に従って開発され、繰り返しテストされ、ライセンスの対象となります。 そのようなシステムでの簡単な方法論は機能しません。 ご存じのように、ドキュメントでのライブコミュニケーションはドキュメントよりも望ましいですが、たとえば、アプリケーションが異なるチームによって何度もテストされる場合は、このプロセスを慎重にドキュメント化する方が適切です。 チームに何十人もいる場合、製品所有者（スクラム用語の顧客担当者）は、すべての人に要件を絶えず説明できません。



したがって、形式化されたアプローチが必要な場合、RUP、OpenUp、EssUpなどの方法論を選択します。 このような方法論は方法論以上のものであり、プロセスフレームワークと呼ぶ方が正確です。 これらはもともと反復モデル用に作成されたものですが、修正によりカスケードモデルで使用することもできます。







正式なアプローチが必要ない場合は、いわゆる柔軟な方法論を使用します。 速度または品質？ 実際、ここではやや複雑な定式化が示唆されています。生産性ですか、それともエンジニアリングですか？



生産性は、アプリケーションに機能を追加する最速のプロセスと理解されています。 エンジニアリングとは、経験豊富なチームのみが適用できる高度な開発組織、革新的なアプローチ、高度な技術を意味します。 テストによる開発、継続的インテグレーション、ペアプログラミングなどの極端なプログラミングプラクティスについて話しています。 極端なプログラミングの特徴は、12のプラクティスすべてを使用する必要があることです。その場合にのみ、それらの効果が最大になります。 練習を行わない場合、他の全員を確実に引き寄せます。 たとえば、単体テストを拒否した場合、頻繁にリファクタリングを行うことはできません。リファクタリングを行わないと、単純なアーキテクチャを提供できません（単純なアーキテクチャは複雑なアーキテクチャよりも開発が難しいため）。



ただし、他の方法論では極端なプログラミング手法を使用できます。さらに、非常に便利です。 たとえば、スクラムのペアプログラミングを使用して、新規参入者がプロジェクトにすばやく参加できるようにすることができます。 したがって、極端なプログラミングは、より高度なエンジニアリングにより高品質を提供できますが、この方法論を選択すると、プロジェクトがより高価になる可能性があります。 また、アプリケーションを成功させるには、この方法論を使用した経験のあるチームが必要です。







最大の生産性が必要な場合は、オプションもあります。 スクラムは、継続的なプロセス改善に焦点を当てています。 これを行うために、彼はスプリントの終わりに開催される回顧集会を持っています。 また、スプリントのレビューでは、何がうまくいったか、何が悪いか、何を改善すべきかについて議論されます。 経験豊富なチームがあり、確立されたプロセスがあり、基本的に改善する必要がない場合、スクラム方法論に従うことはあなたからより多くの時間を奪い、あなたはより有益に過ごすことができます。 たとえば、スクラムによると、スプリントが1か月続く場合、スプリントレビューには4時間かかり、スプリント振り返りには3時間かかります。 さらに、8時間続くスプリント計画と15分の毎日のスクラムラリーがあります。



たとえば、実証済みのテクノロジーを使用するチームや、アプリケーションに馴染みのないアプリケーションのスコープを使用するチーム、またはすべてをまとめて使用するチームがある場合、スクラム手法を選択することは優れたソリューションになります。 新しいプロジェクトが始まると、スクラムの使用を開始できます。プロセスがより合理化され、アーキテクチャが安定し、継続的な改善の必要性がなくなったら、カンバンなどの別の方法論に進むことができます。







改善が必要ではなく、必要なことはタスクに集中することだけであれば、RADまたはかんばんが適しています。 RADにはアジャイル手法と多くの共通点がありますが、プロジェクトの期間に大きな制限があります。 好ましくは、60〜90日以内です。 かんばんは、いつまでも続くことができるある種の連続的なコンベヤのようなものです。 サポートプロジェクトでは適切に機能しますが、複雑なアーキテクチャが必要な場合は不十分です。 アプリケーションへの機能の迅速な追加に焦点を当てました。 機能とは、ユーザーに表示され、ユーザーの問題の一部を直接解決する機能を意味します。 たとえば、ロギング、最適化、およびスケーラビリティはユーザーには表示されません。これらはかんばん用語の機能ではありません。 しかし、新しいページ、レポート、検索の追加フィルターはユーザーに表示されるものであり、機能です。

ソース：

1.博士 ウィンストン、W。ロイス。 大規模なソフトウェアシステムの開発の管理。 1970. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

2. W Boehm、ソフトウェア開発および拡張のスパイラルモデル。 1986. http://csse.usc.edu//TECHRPTS/1988/usccse88-500/usccse88-500.pdf

3. W Boehm。 スパイラル開発：経験、原則、および改良。 2000. http://www.sei.cmu.edu/reports/00sr008.pdf

4. S. Belousova、I。Bessonova、Ruggiero Gilyarevsky。 ソフトウェアシステムとその開発の概要。 HSE。 http://www.intuit.ru/studies/courses/3632/874/info

5. C.シュヴァーバー、D。サザーランド、スクラムハイド。 包括的なスクラムガイド：ゲームルール。

http://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-RUS.pdf#zoom=100

6. Rational Unified Process。 ソフトウェアのベストプラクティス。 開発チーム。 http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

OpenUPの概要。 http://epf.eclipse.org/wikis/openup/

7. H. Kniberg、M。Skarin。 スクラムとかんばん：最大を絞る。 InfoQ。 2010

8. C. Auer、R。Miller。 極端なプログラミング。 プロセスの設定。 -SPb。：Peter：2004

9.極端なプログラミング-現実と神話。 skipy.ru/philosophy/xp.html

10. M.スティーブンス、D。ローゼンバーグ。 リファクタリングされたエクストリームプログラミング：XPに対するケース。 APress、米国、2003

11.ジェームス・クリスティ。 誘惑的で危険なVモデル。

http://www.clarotesting.com/page11.htm

12.アデルアルシャムラニ。 3つのSDLCモデルの比較ウォーターフォールモデル、スパイラルモデル、およびインクリメンタル/反復モデル。 http://www.academia.edu/10793943/A_Comparison_Between_Three_SDLC_Models_Waterfall_Model_Spiral_Model_and_Incremental_Iterative_Model