7

「忠実度の低いプロトタイピングと忠実度の高いプロトタイピング」の議論で勝っているのは誰ですか? プロトタイプ ゼロ (P0) を最終製品の最初のバージョンにする必要がありますか? それとも、常に P-0 を使い捨てにするべきですか? 業界はどのようなアプローチを支持していますか?

ウィキペディアの優れた記事: Software prototyping

4

4 に答える 4

9

プロトタイプは常に使い捨てである必要があります。プロトタイプは、コンセプトを迅速に証明し、実際の製品の設計に影響を与えるために使用されます。そのため、実際の製品にとって重要な多くの事柄 (考え抜かれたアーキテクチャと設計、信頼性、セキュリティ、保守性など) が脇に追いやられています。プロトタイプを作成するときにこれらのことを考慮に入れると、プロトタイプを実際に作成することにはなりません。

コードが実際の製品に直接進化したプロトタイプでの私の経験は、それが原因で最終結果が損なわれることを示しています。実際のアーキテクチャの欠如により、新しい機能を追加するために絶えずハッキングしなければならない多くの石畳のコードが生じました。プロトタイプの迅速な開発のために選択された元のテクノロジが、実際の製品には最適な選択ではなく、V2 では完全な書き直しが必要になったというケースも見てきました。

于 2009-07-03T00:23:37.003 に答える
3

私たち衒学者は、この特定の戦いに敗れたと思います -- 「プロトタイプ」と主張されているもの (定義上、ゼロから書き直すべきです!!!-) は、実際には (多くの場合、中途半端な「ベータ版」) に「進化」しています。等

今日でも、たとえその用語が負け戦だったとしても、私の同僚によるコンセプトを取り戻すための賢明な試みに拍手を送りました。彼は概念実証の小さなプロジェクトを開発する方法を設定しています実証され、実際のプロトタイピングと開発のためにソフトウェア エンジニアに転送されます)。

私たちの部門には、ソフトウェア開発者ではない (実際にはそうあるべきではない!) 人がたくさんいます、非常に頭が良く、コンピューターに精通しており、日常的に現実と接触しているということです。塹壕」 --彼らは、「本番対応」のソフトウェア プロジェクトとして実装されると、実際に影響を与える可能性のある潜在的なイノベーションの機会を最も嗅ぎつける可能性が高い人たちです。営業担当者、アカウント マネージャー、ビジネス アナリスト、テクノロジー マネージャーなど、当社では全員がこの説明に当てはまることがよくあります。

しかし、彼らは C++ でプログラミングするつもりはなく、Java でプログラミングすることはほとんどなく、おそらく Python でプログラミングすることも考えられますが、「製品化」には程遠いものです。 、bash、Excel+VBA、およびその他のさまざまな「クイック アンド ダーティ」テクノロジを、製品化して永遠にサポートすることなど夢にも思わない!- )

そのため、彼らのプロトタイプを「概念実証」と呼ぶことで、彼らの大胆なコンセプトを具体的な形で具現化することを奨励したいと考えています (あいまいな自然言語でのぼんやりとしたおしゃべりやたくさんの手を振ることは、最も役に立たないものであり、とにかく会社の文化とは異質なものです;-)。しかし、そのようなプロジェクトがソフトウェア エンジニアの目標と優先事項の中に存在するように促進された場合、DO は最初からプログラムする必要があることを明確に示しています。エンジニアが目指しているのは、段階的に充実させるのではなく、根本からやり直すことです!-)。

このアイデアがどれほどうまく機能するかを言うのは時期尚早です.3か月後に四半期の取り組みを評価するときに私に尋ねてください.賢明な取り組みです!-)。

于 2009-07-03T05:01:36.207 に答える
2

プロトタイプを書き、それが製品になるまでリファクタリングを続けます。重要なのは、必要に応じてリファクタリングを躊躇しないことです。

最初に作業する人が少ないと助かります。何かに取り組む人が多すぎると、リファクタリングが難しくなります。

于 2009-07-03T00:22:48.080 に答える
1

HAMISI、BUNDALLAHからの返信

プロトタイプは通常、最終的なプログラムの機能のいくつかの側面のみをシミュレートし、最終的な実装とは完全に異なる場合があります。他の同僚が上で提案したこととは反対に、私は上司に使い捨てのプロトタイプモデルを選ぶように勧めません. 私はこれについてアニタと一緒です。2 つのプロトタイプ モデルと提供された状況を考えると、経営陣 (私の上司) には、進化型のプロトタイプ モデルを選択することを強くお勧めします。会社は大規模であり、コードの複雑さ、使用するプログラミング言語の新しさなど、他のすべての変数が与えられているため、プロトタイプ モデルを破棄することはしません。使い捨てプロトタイプモデルは、ユーザーが期待を再検討し、要件を明確にするための出発点になります。これが達成されたとき、プロトタイプモデルは「システムは、特定された要件に基づいて正式に開発されます (Crinnion, 1991)。しかし、この状況では、この特定の状況で与えられる要因が複雑であるため、ユーザーは一度にすべての要件を把握できない場合があります。進化的プロトタイピングは、段階的な改良のプロセスによってコンピューター システムを開発するプロセスです。システムの各改良には、システム仕様とソフトウェア開発フェーズが含まれます。従来のウォーターフォール アプローチとインクリメンタル プロトタイピングの両方とは対照的に、このアプローチでは参加者が前のサイクルから学んだ教訓を振り返ることができます。通常、このような段階的な改善のサイクルを 3 回繰り返します。しかし、多くのシステムでよく見られる継続的な進化のプロセスを止めるものは何もありません。Davis (1992) によると、進化的プロトタイピングは、すべての要件を理解しているわけではないことを認めています (システムが複雑で、会社が大きく、コードが複雑で、言語がかなり新しいと前述したように)。プログラミングチーム)。Evolutionary Prototyping を使用する際の主な目標は、構造化された方法で非常に堅牢なプロトタイプを構築し、それを絶えず改良することです。その理由は、進化型プロトタイプが構築されると、新しいシステムの心臓部を形成し、改善とさらなる要件が構築されるためです。この手法により、開発チームは機能を追加したり、要件や設計段階では考えられなかった変更を加えることができます。システムが有用であるためには、意図した運用環境での使用を通じて進化する必要があります。製品は決して「完成」していません。使用環境の変化に合わせて常に成熟しています。開発者は、最も使い慣れた参照フレーム、つまり現在の場所 (または現在のシステム ステータス) を使用してシステムを定義しようとすることがよくあります。彼らは、ビジネスがどのように実施されるか、およびビジネスが実装されるテクノロジーベースについて仮定を立てます。機能を開発するための計画が制定され、遅かれ早かれ、想定されたシステムに似たものが配信されます。(SPC、1997)。進化型プロトタイプは、機能的なシステムであるという点で、使い捨て型プロトタイプよりも優れています。ユーザーが計画したすべての機能を備えているわけではありませんが、最終的なシステムが配信されるまで暫定的に使用される場合があります。進化的プロトタイピングでは、開発者は、システム全体の開発に取り組むのではなく、システムの理解できる部分の開発に専念できます。リスクを最小限に抑えるために、開発者は十分に理解されていない機能を実装しません。部分的なシステムが顧客のサイトに送られます。ユーザーはシステムを操作する際に、新機能の機会を見つけ、開発者にこれらの機能のリクエストを出します。次に、開発者はこれらの拡張要求を独自のものと一緒に受け取り、適切な構成管理手法を使用して、ソフトウェア要件の仕様を変更し、設計を更新し、再コーディングして再テストします。(Bersoff と Davis、1991 年)。ただし、進化的プロトタイピングの主な問題は、管理が不十分なためです。定義されたマイルストーンの欠如、達成の欠如 - 常に現在のプロトタイプにあるものを次のプロトタイプまで先延ばしにする、適切な評価の欠如、プロトタイプと実装されたシステムの間の明確さの欠如、ユーザーからの継続的なコミットメントの欠如。このプロセスでは、従来よりも長い期間にわたって、ユーザーによる持続的な取り組みが必要になります。ユーザーは、何が起こっているかについて常に知らされ、「プロトタイプ」の期待を完全に認識している必要があります。

参考文献

Bersoff、E.、Davis、A.(1991)。ソフトウェア構成管理のライフ サイクル モデルの影響。通信 ACM。

クリニオン、J.(1991)。Evolutionary Systems Development は、構造化されたシステムの方法論におけるプロトタイピングの使用に関する実用的なガイドです。プレナムプレス、ニューヨーク。

Davis、A.(1992)。運用プロトタイピング: 新しい開発アプローチ。IEEE ソフトウェア。

ソフトウェア生産性コンソーシアム (SPC)。(1997)。進化的急速な開発。SPC ドキュメント SPC-97057-CMC、バージョン 01.00.04。

于 2010-11-11T11:13:41.083 に答える