さて、Web 2.0とスタートアップに関するほとんどすべての記事で、アドバイスの中からアドバイスを見ることができます。いくつかの考えとプロジェクト前のドキュメントを放棄して、プロジェクトを作りましょう！ そして非常に頻繁にこのアドバイスは文字通りに取られ、アイデアが最終的に形成される前であってもコードの最初の行が現れます。 結果は何ですか？ そして最終的に、開発期間全体のシステムのコアは、フロントエンドはもちろんのこと、15回書き換えられます。 その結果、1〜2か月で構想されたプロジェクトは、半年-1年に及ぶことになります。 そして、コードは多くのバグに変わります。
これを回避し、半年を計画しないために何ができますか？
率直に言って、私はこのレーキを何度も踏んだ。 多くのプロジェクトは、不十分または質の低いトレーニングのために死亡しています。 したがって、「ソフトウェアプロジェクトの開発の標準」という簡単なことを一度も満たさなかったなら、それは続くでしょう。 大規模なソフトウェア会社で働いていた人は、おそらく特定の方法論や標準を聞いたり、使用したりしました。
一部の人々の不快な顔を前もって想像しますが、これは余分な官僚主義であり、役に立たないと言っています。 幸いなことに、これは完全に真実ではありません。 実際、多くの標準は非常に広範であり、特定のプロジェクトで不必要なものが大量に記述されています。 しかし、それがベースに基づいて構築するための標準である理由です。 本当に必要な部分だけを選択する必要があります。
なぜ標準を使用するのですか？ まず、チームが何をしているのかを説明するために。 プロジェクトの途中のどこかで、参加者の一人が、何も占有しないと言っているという状況を避けるために、 約束しなかった、または方法がわからない。 第二に、最終的に何を取得したいのかを正確に決定します。 最終結果の要件のリストを作成する必要があります。 そうでない場合、出力の品質の程度をどのように決定しますか？ 第三に、両方のプログラマーが同時にクラスを開発している状況を防ぐために、一方がそのバージョンをリポジトリにアップロードし、もう一方が以前のものを置き換えて独自のロードを行った後、コードを更新する方法を決定し、ルールを設定する必要があります。
あなたのプロジェクトを少なくとも最小限に文書化してみてください、そうすればあなた自身があなたが何をしているかをよりよく理解し始めると思います。
十分な説明ができたら、練習しましょう。 プロジェクト全体をいくつかの部分に分割します。
初期化 -ここでは、大まかに受け取りたいものについて話し合い、アイデアを交換します。
デザイン -ここで忘れられているのはステージです。 詳細については、以下をご覧ください。
コーディング -すべてが明確であることを願っています:)
テスト -しかし、この段階は設計なしでは発生しません。受け取りたいものがわからない場合、取得したものをどのように確認しますか？
統合 -プロジェクトを開始します。
次に、設計について詳しく説明します。
小さなチームの場合、私はある種の超洗練されたソフトウェアの使用を提案しません。 wikiにしましょう。 私は自分用にDokuWikiを選択しましたが、他のものも使用できます。 プロジェクト管理にはIEEE規格を使用しますが、逐語的には従いません。
最初に必要なドキュメントは、SPMP（ソフトウェアプロジェクト管理計画）別名「ソフトウェアプロジェクト管理計画」です。 ここでは、プロジェクトの誰が責任を持ち、管理がどのように行われるか、どの方法を使用するかを示します。 特定の例を必要とする人のために、最後にいくつかのリンクを提供します。
次に、SRS（ソフトウェア要件仕様）別名「ソフトウェア要件仕様」が必要です。 これは非常に重要な文書です。ここでは、システムに実装する必要のあるすべての機能に署名しています。 インターフェース要件とユースケース。 サイトの構造を描き、プロトタイプを作成します。 プロトタイプとは、実際に機能するものを意味するものではありません。 プロトタイプは、ユーザーインターフェイスのスケッチです。 たとえば、MS Visioを使用できます。 すべてが単純に見える場合でも、常にフロントエンドのプロトタイプを作成することをお勧めします。 簡単な場合-5分かかりますが、何かを忘れたらどうしますか？ グラフィックデザインなどの話はありません。 ボタン、フォーム、入力フィールドだけでなく、ページ上のそれらの実際の位置も、今では決定的な重要性はありません。
次に、SCMP（ソフトウェア構成管理計画）、別名「ソフトウェア構成管理計画」に移りましょう。 ここではほとんど標準に準拠していませんが、それでもドキュメントが必要です。 開発で使用するソフトウェアの種類、バージョンの順序について説明します。 アセンブリなどはどうですか
そして最後に、SDD（Software Design description）もデザインドックです。 SRSで説明されている要件のリストを準備して、システムの設計を開始します。 プロジェクトのアーキテクチャ、主要なパッケージおよびクラスについて説明します。 説明の詳細度は個別に決定されます。
それだけで、思ったほどではありません。 個人的な実践から：wikiのSRSセクションは、要件管理システムとして使用できます。 各機能に独自の番号、ステータス、優先度を与えるだけです。 過剰なソフトウェアで問題を作成しないでください。
いくつかのリンク：
オープンソースのMOORPG Ireon ドキュメントは、いくつかのドキュメントに記入する実用的な例です。
SPMP（英語）はこちら
オリジナル
必要に応じて、すべての標準はグーグルです。
忘れられた設計段階
All Articles