一般に、企業がソフトウェアを開発する場合、ベースラインとカスタマイズという 2 つの方法でプロジェクト開発作業を並行して実行します。どのような企業であっても、より高品質の製品を生産するには、成熟した製品開発プロセスシステムに従う必要があります。したがって、プロジェクトが多数ある場合は、ベースライン製品ができるだけ多くのユーザーの一般的なニーズを収集し、カスタマイズ プロジェクトの進行に技術サポートを提供し、多数のプロジェクトの数を減らすことができるように、カスタマイズ前のベースラインとマイルストーンを合理的に配置する必要があります。カスタマイズ プロジェクトでコードが変更されると、新しいモジュールを追加する必要が生じます。また、製品開発のプロセス体系も、実際のビジネスの時間要件に応じて変更する必要があり、ウォーターフォール方式やアジャイル方式に固執することなく、すべてを自分に合った方法で管理する必要があります。靴が自分の足に合うかどうかは足にしか分かりません。 当社では、プロセスの説明の基礎としてベースラインの製品開発プロセスを使用しています。以下で説明する各段階について、
各段階の目標を明確に定義し、計画を指定し、それを明確に伝達する必要があることに注意してください。プロジェクトが実行される前にタイムリーに実行し、すべてのメンバーが各期間でプロジェクトについて一貫した理解を確実にします。 プロジェクトキックオフミーティング
ユーザー要件
ソフトウェアの開発を開始する前に、コストと得られる価値の比較、つまり ROI (投資収益率) を決定する必要があります。このソフトウェアの存続をサポートするには、作成する必要があり、一連のリソースを手配する必要があります。これは要件の最も原始的な説明です。 ユーザー ニーズと製品ニーズの両方が必要なのはなぜですか?両者には違いがあるため、ユーザーニーズはユーザーによって提案され、一般的にテクノロジーについては説明されず、製品の目標のみが説明されます。製品要件は、ユーザーのニーズを技術的な実装要件に変換したものであり、ユーザーが提案する製品目標を細分化し、具体的な機能点ごとにまとめた上で、各機能点をさまざまな業務プロセスに細分化し、それぞれの業務プロセスを技術的に定義する必要があります。
ユーザーニーズとプロダクトニーズは相違しやすいもので、同じニーズといっても出発点が異なるため、双方の悩みや考え方が異なる場合があります。
ユーザー要件は、システムがビジネス プロセスをどのようにサポートするかに焦点を当てており、その根底にある要件は「ビジネス目標を達成する」ことです。技術スタッフは合理的な技術的解決策に焦点を当てており、その背後にある要件は「作業負荷」、「実装の難易度」、「システムのパフォーマンス」です。
製品要件製品マネージャーまたはプロジェクト要件の提案者がなぜこのプロジェクトをやりたいのかを理解する必要があります。これは最も重要なビジネス要件です。需要分析によって決定されるビジネス ニーズはすべてビジネス ニーズに由来しており、ビジネス ニーズに応えなければなりません。
が含まれます。製品要件マトリックスは、一般に、サブシステム、機能セット、および実行ユニットの構造に従ってすべての機能要件をリストし、各列は各機能の作業ステップと各ステップの作業負荷に対応します。
製品要件を作成したら、レビューする必要があります。要件検討会議では、製品および技術の詳細な検討要件は完了していますか? 製品機能の通常のシナリオは何ですか?閉ループを形成しているのでしょうか？珍しいシナリオとは何ですか?思慮深いですか？ 要件レビューの後、開発リーダーとテスト リーダーはそれぞれ技術ソリューションとテスト ケースを作成します。
技術計画のレビューでは、開発リーダーが他のシステムに関わるリーダーを集めて議論します。技術計画には業務フローチャートとシーケンス図が必要です。
業務フローチャートは業務の流れを整理するものです。開発がビジネスに与える影響を理解し、それがニーズと一致しているかどうか。シーケンス図は、この要件に関係するシステムの相互作用を整理するものです。技術計画が審査・承認された後、作業量や納期を確認し製品にフィードバックします。
設計フェーズの目的は、主に、開発するシステムのアーキテクチャを分析および設計し、その後の実装作業に安定した基盤を提供するために、システム アーキテクチャのベースラインを確立することです。
。例えば、家を建てる場合には建築図面が必要ですが、図面があって初めて工期を計算することができます。
全体設計はシステム全体の骨格設計であり、非常に重要な部分であり、通常は省略することができません(ベースラインプロジェクトが設計されているため、全体設計を省略できるのは保守プロジェクトのみです) 全製品開発プロジェクトでは、まず全体設計を実行する必要があります。これは設計の最初のステップです。最初にコーディングしてから設計するという本末転倒は決して許されません。これがソフトウェア開発における 2 番目に大きな問題点です (1 つ目は不明確な要件と要件の恣意的な変更!) 。
全体的な設計は 3 つのフェーズに分かれています。:
最初のフェーズ : 初期設計。与えられたデータ フロー図のレビューと改良に基づいて、初期モジュール構造図に変換されます。
第二段階: 洗練されたデザイン。モジュールの「高凝集性と低結合性」の原則に従って、初期モジュール構造図が洗練され、グローバルデータ構造と各モジュールのインターフェースが設計されます。
第 3 段階 : 設計レビュー段階。最初の 2 つの段階で得られた高レベルのソフトウェア構造をレビューします。また、場合によっては、必要に応じてソフトウェア構造、化学作業。
概要設計の目的は、システムの各モジュールの内部設計を記述し、全体設計と詳細設計の間の接続の役割を果たすことです。デザイン。
概要設計は構造化設計手法に従って設計されます。構造化設計手法の基本的な考え方は次のとおりです: 問題領域に応じて、ソフトウェアは段階的に洗練され、分解する必要のないモジュールに分解されます。各モジュールは特定の機能を完了し、1 つ以上の親モジュールとして機能します。 (つまり、呼び出しを受け入れます)、1 つ以上のサブモジュールからのサービスも受け入れます (つまり、サブモジュールを呼び出します)。モジュールの概念は、プログラミング言語のサブルーチンまたは関数に対応します。
概要設計段階では、ソフトウェアを一定の原則に従ってモジュールレベルに分解し、各モジュールに一定のタスクを与え、モジュール間の呼び出し関係やインタフェースを決定します。
この段階では、設計者は通常、モジュールの内部実装を検討して処理しますが、それにあまり巻き込まれないようにします。主に モジュールの分割 、 タスクの割り当て 、呼び出し関係の定義 に焦点を当てます。 モジュール間のインターフェイスとパラメータ転送この段階では、それらを非常に慎重かつ明確に定式化する必要があり、その後の設計での混乱や誤解を避けるために厳密なデータ ディクショナリを作成する必要があります。概要設計は通常一度では完了せず、構造の調整を繰り返し行う必要があります。一般的な調整は、重複した機能を持つモジュールをマージするか、再利用可能なモジュールにさらに分解することです。概要設計段階では、再利用可能なモジュールを最大限に抽出し、合理的な構造システムを確立し、後続のリンクの負荷を軽減する必要があります。
アウトライン設計ドキュメントの最も重要な部分は、階層データ フロー図、構造図、データ ディクショナリ、および対応するテキストの説明です。概要設計書を基に、各モジュールの詳細設計を並行して行うことができます。
詳細設計段階は概要設計段階の分解に基づいて、各モジュールのアルゴリズムや処理を設計し、各モジュールで実現する機能を設計します。機能の説明を正確で構造化されたプロセスの説明に変換する必要があります。
詳細設計のこの段階では、並列設計のために各モジュールを異なる担当者に割り当てることができます。設計者の作業対象はモジュールであり、設計者は概略設計で割り当てられたローカルタスクや外部インタフェースをもとに、モジュールのアルゴリズムやプロセス、状態遷移などを設計・表現します。 ここで注意すべきは、構造調整（サブモジュールの分解等）が必要と判明した場合には、概要設計段階に戻り、概要設計書に反映させる必要があることです。 , しかし、挨拶せずにその場で解決することはできません 。詳細設計文書の最も重要な部分は、 モジュールのフローチャート 、状態図 、ローカル変数 、および対応する テキスト説明 です。等1つのモジュールが詳細設計書に相当します。
概要設計段階ではソフトウェアの構造図を取得することが多く、詳細設計段階ではフローチャート、N-S図、PAD図、擬似コードなどの記述方法が一般的です。詳細設計の目的は、あるモジュールの内部処理の流れや開発方法、コーディングスキルを記述することです。一般的に、詳細設計は、プロジェクトの紹介、モジュールの説明 (具体的には、各モジュールの内部プロセス、機能、ロジック、消費および未解決の問題を説明します)、インターフェイス設計で構成されます。 （内部インターフェースおよび外部インターフェースを含む）、データ構造設計（物理構造および論理構造を含む）、特殊処理およびその他の部分。ソフトウェアの詳細設計は、最終的には、ソフトウェア システムの各部分の具体的な設計方法、ロジック、機能を文書化したものです。このようにして、実装プロセス中に、コーダーはこの原則に従って厳密にコードを実装できます。
コードの記述は次の原則に従うことができます:
最初にコア モジュールのストレス テストを実行します: 多くのプログラマーは物事を終わらせることに慣れており、オンラインになる直前まで待ってからパフォーマンス テストを実行します。以前のデザイン これは大きな問題です。もちろん、その後オンライン化する際にもパフォーマンステストは行われますが、それでも初期段階では非常に重要だと思います。もちろん、これをうまく行うには、ある程度のビジネスを理解する必要があります。ビジネスのプレッシャーがどこにあるのか、ビジネスの要求の焦点がどこにあるのかを知る必要があります。多くの場合、プロダクト マネージャーが説明しない場合は、明確に質問する必要があります。
プロセスが制御可能であることを確認する: コードの実行時に中間出力を維持する必要があります。たとえば、100,000 ログが処理されるごとに、ステータス ログを次の場所に書き込みます。処理のログエントリ数と現在の実行時間を記録します。
ログをもっと見る: 多くの場合、私は自分が書いたコードにあまり満足していません。たとえば、特定の処理効率が十分に最適化されておらず、特定の処理効率が十分に最適化されていないなど、処理方法が十分に簡潔ではない、またはスケーラビリティが相対的に低く、コードが非常に遅れて書かれているが、最適な解決策を短期間で見つけ出すことは不可能である可能性があります。立ち上げの段階では、意図的に最適化することはありませんが、この場合、私はよくメモを残し、次の最適化に向けてどのようなアイデアが考えられるか、またはどのような実現可能な解決策が考えられるかを説明します。
シンプルでわかりやすいロジック: 自分で関与しないでください。時間が経つと、誰もあなたのロジックを理解できなくなります。ロジックを関数内で完成させるのが非常に難しい場合は、分割してみてください。
フレームワークに執着しないでください: フレームワークの最大の問題は何ですか?入れ子が面倒すぎる。なぜ私はいつもフレームワークに悩まされるのでしょうか? 1 秒あたり数千のリクエストを必要とする処理シナリオに頻繁に遭遇するため、チューニングの際には、無数のフレームワークからデータ処理ロジックとパフォーマンスの障害点を探す必要があります。コードを 2 行変更するだけで済みますが、問題を見つけるには 2 日かかります。プログラマーは、技術的な能力がフレームワークによって制限されてはならないことを覚えておいてください。
使い慣れた成熟したテクノロジーを使用する: 多くの人は、自分自身の障害や問題をまったく理解しておらず、関連するテクノロジー製品の長所と短所も知りません。大量のサードパーティデータの評価を見るたびに、興奮して新しい技術を学び、その後、落とし穴に落ちて抜け出せなくなります。スタートアップ企業であれば、プロジェクトがその中で消滅する可能性があります。 。新しい技術を使用する前に、その技術の特性、適用範囲、非適用範囲を十分に理解することをお勧めします。
ご存知のとおり、チーム内でコード レビュー (コード レビュー) を実施すると、コードの品質を向上させ、プロジェクトの知識を共有し、責任を明確にし、最終的にはビルドを行うことができます。より良いソフトウェア、より良いチーム。
コード レビューは非常に重要です。一般的に、コード レビューは毎週行う必要があります。まず、コード レビューはプロジェクトの進捗状況を追跡するのに役立ちます。私たちの部下がどのように進んでいるのかを実際に確認でき、彼らが道から外れていないかを早期に知ることができます。時々、「もうすぐ完成です！」と言われることがありますが、コードを見てみると、何もなかったり、ゴミの山があったりするだけですが、まだ完成には程遠いです。経営者にとってはこの状況が一番厄介なので、このトラブルを回避するにはコードレビューが一番良い方法だと思います。
単体テストを理解するには、まず「ユニット」とは何かを理解する必要があります。いわゆる「ユニット」とは、コード呼び出しの最小単位を指し、実際にはファンクション ブロック (Function) またはメソッド (Method) を指します。したがって、単体テストとは、これらのコードを呼び出すユニットをテストすることを指します。
単体テストはホワイトボックス テストの一種で、単体のコードの詳細を明確にする必要があるテストです。したがって、単一単体テストの作成と実行はソフトウェア エンジニアによって行われます。単体テストと比較して、統合テストもあります。 結合テストは基本的にブラックボックステストであり、主にテスターがソフトウェアの機能マニュアルに従って実施します。には専用のテスト環境の協力が必要です。結合テストは機能テスト、回帰テストなどに分かれます。
単体テストが必要なコードは、実際には開発者自身が作成したロジックであり、そのロジックが依存する環境が正常であるかどうかをテストすることは単体テストの目的ではありません。環境アクセス コードにロジックを導入すると、ロジックのテストがさらに難しくなり、ロジック コードの単体テストが不可能になります。したがって、単体テスト可能なコードは単体テストできます。テスト可能なコードを判断するもう 1 つの方法は、メソッドが main 関数を使用して直接実行できるかどうかを確認することです。そうであれば、それは単体テスト可能なコードです。テスト可能なコードのもう 1 つの特徴は、外部環境に依存することなく、開発者がメソッド ユニットのパラメータを自由にシミュレートできることです。 統合テスト
統合テスト。アセンブリ テストまたはジョイント テストとも呼ばれます。単体テストに基づいて、すべてのモジュールは統合テストの設計要件に従ってサブシステムまたはシステムに組み立てられます。実際にやってみると、統合テストは、ソフトウェアシステムの統合プロセスで実行されるテストであり、その主な目的は、ソフトウェアユニット間の言い訳が正しいかどうかを確認することです。統合テスト計画に従って、システムを実行しながらモジュールや他のモジュールを組み合わせてより大きなシステムを構築し、構成されたシステムが正しいかどうか、さまざまなコンポーネントが適合しているかどうかを分析します。統合テストには、トップダウンとボトムアップの 2 つの主な戦略があります。 は、ソフトウェア設計ユニットと機能モジュールが組み立てられてシステムに統合されるときに、アプリケーション システムのさまざまなコンポーネント (ソフトウェア ユニット、機能モジュール インターフェイス、リンクなど) を共同テストして、それらが適切であるかどうかを判断することとしても理解できます。連携して動作するコンポーネントは、コードのブロック、スタンドアロン アプリケーション、ネットワーク上のクライアント側またはサーバー側のプログラムになります。 システム テスト
、機能テスト、パフォーマンス テストが含まれます。 、安定性テスト。 要件分析によって決定された機能が完全で正しく実装されているかどうかを検証するには、インストール、展開、適応性、セキュリティ、インターフェイスなどの非機能要件もテストする必要があります。システムテストもテスターの責任であり、要件分析が完了した後に設計し、結合テストが完了した後に実装する必要があります。
機能テスト
は通常、ブラックボックス手法を使用して独立したテストチームによってテストされ、主にシステムが「要求仕様」を満たしているかどうかをテストします。上記のテストと確認の段階を経た後、システムは完全にシミュレートされ、顧客環境をテストします。 システムテストとは、確認済みのソフトウェア、コンピュータのハードウェア、周辺機器、ネットワークなどを組み合わせて、情報システムのさまざまな組み立てテストや確認テストを行い、システム要件と比較して調べることを目的としています。開発されたシステムがユーザーのニーズと一致しない、または矛盾する場合は、より完全なソリューションが提案されます
。 パフォーマンス テスト
パフォーマンス テストでは、通常、多数のユーザーが同時にシステムを使用したときにシステムが安定しているかどうかを確認するために、いくつかの代表的な機能が選択されます。パフォーマンス テストはテスターの責任です。システム テストの完了後に実行することも、重要なモジュールのパフォーマンス テストを最初に実行することもできます。テスト サイクル全体を通じて実行できます。目的は、システム パフォーマンスのボトルネックを早期に発見することです。できるだけ早く解決してください。
安定性テストもパフォーマンステストも、システムに基本的に問題がなく安定するまで待たないと効果が得られず、スムーズにテストを行うことができません。システム アーキテクチャに問題があるのか、それとも機能的な欠陥なのかを判断します。
システムに特定のビジネス圧力を負荷し、システムを一定期間 (通常は 7x24 時間) 実行し続けることにより、システムが実行できるかどうかをテストします。安定して走ります。
製品リリース
プロジェクトの経験と教訓を要約する目的は、誰かに責任を問うことではなく、問題を要約し、原因を分析し、今後同じ間違いを繰り返さないようにすることです。
要件の理解に欠陥があったとします。要件の段階で発見された場合、修正には 1 時間しかかかりません。しかし、設計が完了した時点で欠陥が発見された場合、関係する人員や文書が増えるため、所要時間は 1 日かかると推定されていますが、コードを作成した後でのみこの欠陥が発見された場合は、10 日から 8 日かかる可能性があります。欠陥が発見されず、実稼働システムに直接影響を与えた場合はどうなるでしょうか?これはもはや作業負荷の問題ではなく、推定損失を見積もることは困難です。 品質管理の理論では、欠陥の発見が遅れるたびに、修理費用が10倍になります。
アジャイル開発、エクストリーム開発、その他のモデルは、要件が不明確で時間に余裕がない場合に迅速に反復するという問題を解決するものであり、研究開発プロセスを根本的に否定するものではありません。まだ設計が必要な場合は、ライフサイクルを分割し、プロセスをいくつかのサイクルに水平方向に分割するだけです。ソフトウェア開発はエンジニアリング要件が厳しい分野ですので、厳格な姿勢と効率的な作業方法を遵守して、可用性が高く高品質なソフトウェア製品を作成しましょう。
この記事は転載されたものです、原著者: 周明耀、元のアドレス: https://mp.weixin.qq.com/s/-XDomowMhz9rX-zeCIJuaA
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
