ソフトウェア工学 - 個人課題 - 質問のレビューと個人的な要約
過去の質問に答える
Q1: 単体テストは本当に再現性のある一貫した結果を生成できますか
単体テストは再現性のある一貫した結果を生成する必要があります単体テストの結果が間違っている場合は、プログラムに問題があり、このエラーは繰り返し発生する必要があります。
第 2 章では、上記の結論がありますが、OO ユニット 2 での私のテストに基づいて、テスト結果を繰り返すことはできないと思います. マルチスレッドでは、さまざまな小さなマルチスレッドの問題が頻繁に発生し、これらの Minor問題は、プログラムが非常に長い間実行された後、非常に過酷な状況でトリガーされるバグです. このコードを繰り返し実行すると、バグが再びトリガーされることはほとんどなく、結果は自然に発生します.現在あらゆる種類のソフトウェア プロジェクトの中で、マルチスレッド プロジェクトが圧倒的多数を占めていると思います。
A: 実際のテストでは、再現性のある一貫した結果が得られました。後者は当社の不具合記録で再現可能であり、各不具合も修理済みです。
Q2: 単体テストは誰が書くべきですか?
単体テストは、コードに最も詳しい人 (プログラムの作成者) が作成する必要があります。2章に上記の記述がありますが、ユニットテストを書くのに最も適している人は、モジュールの要件に最も精通している人、またはテストする要件を提示する人だと思います。プログラムの作成者は要件に従うだけでよい コードを完成させた後、テストするとき、彼は自分のコードの理解に従ってテストを完了し、コードを書くときに要件を誤解した場合は、どのようにテストしても、彼は彼の目には、これは正しいが、実際の要件に関しては、この機能には問題がある可能性があるため、問題を検出することはできません。そのため、テストは要件に最も精通している人が作成する必要があると思います.
A: 私たちのチームにはテストを担当する同級生がいます. チーム会議の後、要件に対する全員の理解は同じであるべきだと思います. 機能要件に対する2人の理解に違いはありません.もちろん、コードをテスト生に渡す前に、この関数はコードを書いた学生によって何度もテストされています。
Q3: シックス シグマ法を時間通りに使用することは正しいですか?
しかし、標準偏差を見ると、Al の分散は 5.3 で、Bob の分散は 1 です。3章に納期比較の分析がありますが、個人的には実際の完成時間と見積時間の評価にシックスシグマを使うのはあまり適切ではないと思います。シックス シグマの定義を見てみましょう: (Baidu Encyclopedia)
シックス シグマ (Six Sigma, 6 Sigma) は、1986 年に当時モトローラのエンジニアであったビル スミスによって提唱された経営戦略です。この戦略は、高い目標を設定し、データを収集し、結果を分析して、製品とサービスの欠陥を減らすことを強調しています。シックスシグマの背後にある原則は、プロジェクトにいくつの欠陥があるかを検出した場合、それらを体系的に削減してプロジェクトを可能な限り完璧にする方法を見つけ出すことができるというものです。
この方法は実際にプロジェクトの欠陥を評価していることがわかります.6 シグマ = 3.4 ミス/100 万機会、つまりプロジェクトのエラー率を評価しており、プログラマーはタスクを早く完了しすぎていると考えられますか?個人的には、平均時間と超過時間で評価する方が適切だと思います。
A: 実際、私たちのチームは評価にこの方法を選択しませんでしたが、完了したタスクの数と品質を評価に使用しました。・作業ができない状況。
Q4: goto の使用は本当に推奨されますか?
Q: goto は使えますか?回答: 関数は単一の出口を持つ方がよい. これを実現するには、goto を使用できます. プログラムのロジックを明確に反映するのに役立つ限り、goto を含む任意のメソッドを使用できます。
第 4 章のコード設計仕様では、上記のように記述されています。しかし、私の個人的な開発では、コメントが言うように、goto を使用したことはありません。
goto ステートメントは、プログラムの静的構造を動的構造と一致させないため、プログラムが理解しにくく、エラーをチェックしにくくなります。
goto ステートメントの結果: goto ステートメントは、C/C++ などの高級プログラミング言語で予約されていますが、使用しないか、あまり使用しないことをお勧めします。Java など、goto ステートメントを提供しない一部の新しい高級プログラミング言語では、キーワードとして goto を指定しますが、goto ステートメントの使用をサポートしていないため、プログラムが簡潔で読みやすくなっていますが、その後の c# では引き続きサポートされています。 goto ステートメント、1 つの goto ステートメント 利点は、入れ子になった場合に大きくなりすぎないように、プログラムに一意の出口があることを保証できることです。
goto はプログラム構造を奇妙にすることが多く、ペアの相手が goto を使用することはめったになく、理解の難しさが増します。goto は、コードで goto を見ることにあまり慣れていない別のものに置き換えることができると思います。
A: 私たちのチームの誰もこの種のものをまったく使用していません. これは最終的に使用すべきではないと思います. 私たちの協力では、他の人々のコードはすべておなじみの構造であり、goto と goto がないことがわかります. . チームの規範の問題です。
Q5: PM は本当に全員に平等になれるのでしょうか?
一部の企業のプログラム マネージャーとプロジェクト マネージャーの違い:
プロジェクトマネージャ プログラムマネージャー チームのエグゼクティブ リーダーであり、全員をプロジェクトに取り組むように導きます。 全員と平等に協力して、チームがソフトウェアの機能を完成できるようにします。 通常、外の世界を扱うチームの唯一の代表者 チームは多くの PM を持つことができます プロジェクトの機能について最終決定権を持つ 他のチーム メンバーと決議案を作成する モノと人を管理する 人の世話をします 必ずしも特定の作業を行う必要はありません 特定の仕事をしなければならない 第 9 章プロジェクト マネージャーを読むと、上の表があり、プログラム マネージャーは全員と対等な立場で協力し、他のメンバーと意思決定を行い、人に関係なく物事を管理するものとして説明されています。しかし、私の大学での実際のプロジェクトでは、これは非常に難しいと思います。私が初めてプロジェクトチームのリーダーを務めたとき、最初に考えたのは、全員が平等で、プロジェクトに関する提案を一緒に行い、プロジェクトの方向性を決定するために投票するなどでした。司会. 会議は全員が参加して意見を述べる会議のはずですが, 実はほとんどのプロジェクトは最後に私が取り持つ. この場所をどのように完成させるべきか, 詳細はどうあるべきかについても説明しています.先人たちのブログが参考になるところでは、他の人は基本的に口をきかないかもしれません。とはいえ、すでに関連ブログを見つけて実装した機能の入力と出力を記述している. まだまだ作業を急がなければならない. たとえば、冬休み中にプロジェクトを立ち上げてタスクを整理した. その効果を見せて.しかし、この作業は夏休みに延期され、結局、以前に彼に送ったブログを一晩かけて再現しました. 実際、その記事に従えば、奇妙な問題はまったくありません. 誰が何と言おうと、少なくとも大学では、PM のようなタスクを完了するのは難しいと思います。もちろん、仕事は違うかもしれませんが、PMが全員に平等になれるかどうかはまだ疑問です. PMは、すべてのプロジェクトで人を管理し、進捗についていけない人をプッシュする必要があります. どうすれば真の平等を実現できますか? ?
A: 今回のソフトエンジニアリング連携では、打ち合わせを重ねてきましたが、PMはある意味でイコールだと思います。私たちのグループには 2 人の PM がいて、1 人は主にフロントエンドを担当し、もう 1 人はバックエンドを担当していますが、通常はコーディング プラットフォームを使用して特定の人にタスクを割り当て、完了時間を指定するためです。 PMが押しかけてくると、PMがモデレーターの役割をするので、その必要はありません。
各ステージの知識ポイント
必要
典型的なユーザー。このプロジェクトは中国通信社と協力しているため、彼らの一般的な要件の一部を取得した後、典型的なユーザーに置き換えて要件が妥当かどうかを検討し、漠然とした要件をさらに洗練して統合し、最終的に具体的なニーズに変換します。
デザイン
グラフィカルなモデリングと分析方法。グラフィカルな方法で物事をモデル化すると、物事間のつながりをうまく反映できるため、ソフトウェア開発者はその後の設計の内容を正確に把握できます。リアルタイム設計を採用しており、ジャンプの仕方など、ソフトウェア全体の動作ロジックを明確に見ることができます。必要な機能は？その後の開発に大変役立ちます。
達成
進捗管理。CODING ではチームワークを使用して進捗管理を行います。ここでは、全員のタスクと欠陥を確認し、全体的な進捗状況を確認し、全員がタスクまたは欠陥を他の人に割り当てることができ、誰が特定の部分を行ったかを簡単に見つけることができます。
テスト
バグレポート。ある人がバグを見つけた場合、そのバグを他の人にどのように報告しますか? これには、エラーレポートまたは欠陥レポートの仕様が必要です.コーディングプラットフォーム上でチームワークを使用して、各欠陥を詳細に説明します.どのようにそれをトリガーしますか? トリガー結果？修理後の効果は？そうすれば、誰もがバグを修正する方法を知っています。
リリース
機能を切り取る。機能を完了できませんか? ちょうどそれを切り取ってください。実際に開発した時はAR顔機能を作ろうと思っていたのですが、この機能は一部の人のケータイでしか使えず、完成させるのが難しいことが分かり、結局この機能は実装しませんでした。そして真っ直ぐに切る。
維持
構造化されたメンテナンス。新しい要件が発生するたびに、要件分析から始めて、プロセス全体を分析し、変更が他の場所に与える影響を判断し、できるだけ他のバグを発生させずに新しい要件を追加し、バックエンドを使用する必要があります。動的展開は、ユーザーの使用には影響しません。
経験
やっとソフト作業が終わりました.今回のプロジェクトでは主に多人数同期の部分を担当しています.AR部分もあります.今ではUnityでの多人数同期についての理解が深まり,自力でステーションbに行ける多人数参加型オンラインゲームの実装方法を動画で撮影しました. 実は現在のブログや公式の技術文書には書かれていないことがたくさんあります.シーン招待の実装、チーム招待の実装方法など その中で多くのことを学びました。先週は基本的に3時から4時頃に就寝し、朝起きて仕事を続けるという、基本的にソフトジョブの研究開発に全時間を費やしたと言えますが、得たものもありました。 、それだけの価値があると思います。
技術的な側面に加えて、チームで仕事をする方法、より便利なコミュニケーション チャネルを確立する方法、タスクを合理的に割り当てる方法などについても学びました。今回の経験と同じなので、私もこのチームワークを経験して、より良いチームワークを作っていきたいと思います。たとえば、WeChat などを使用するよりも多くのチーム コラボレーション ツールを使用する方が効率的であり、全員のタスクと進捗状況を簡単に追跡できます。
最後に、ペアリング パートナーとチームメイト、そして先生方とティーチング アシスタントの方々の多大な努力に感謝します。