201771030113-Li Zhilong実験4ソフトウェアプロジェクトケース分析

プロジェクト	内容
コースクラスのブログリンク	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
割り当て要件リンク	https://www.cnblogs.com/nwnu-daizh/p/12369881.html
コースの学習目標	チームソフトウェアプロジェクトプロセスとチームメンバーのコラボレーション要件を学び、アジャイルプロセスの原則と関連する概念をマスターします。
この課題はどのようにして学習目標を達成するのに役立ちますか	さらにペアになったピアラーニングを通じて、チームの能力とチームワークに対する意識を高めます。
学生ID名	201771030114-馬強
相手をこのブログ割り当てリンクにリンクする	https://www.cnblogs.com/AlexCrizs/p/12676098.html

実験3の宿題で100点以上の点数で評価するケースを選択してください

• 実験3の優れたケースの推奨事項：Zhang Qin＆Li Peishan Group

  • プロジェクトウェアハウスリンクのグループ
  • ブログの割り当てのこのグループへのリンク-張秦
  • ブログの割り当てのこのグループへのリンク-Li Peishan

• コメントのスクリーンショット
  

• プロジェクトのソースコードを体験し、問題を要約し、ケースのブログ投稿を体験してください。

  • 相手のケースのソースコードを本機にコピーします。
    

  • ログインを実行
    

  

  • 二次部門のお問い合わせ
    
    
  • テーブルが正常にエクスポートされました
    
  • 統計ヒストグラムを生成する
    

• 選択されたケースの分析とそれらの欠陥の補足

  • この実験のケースを通して、そのコードをテストして実行します。欠点は、その中の人事情報を効果的に管理することができない、つまり、うまく追加および削除できないことです。生成された統計テーブルの明確なストレージパスもありません。結果として、トライアル中にエクスポートされたテーブルを見つけるのは困難です。

共同学習：「最新のソフトウェアエンジニアリング-建設の法則」の5〜6章を読む

• ソフトウェアプロジェクトチームの特性を理解して習得する
  • チームには一貫した集団目標があり、チームはこの目標を一緒に達成する必要があります。
  • チームメンバーには独自の分業があり、互いに依存し、協力してタスクを完了します。
• ソフトウェアチームモデル
  • 医師モードへの参加：チーフプログラマーはメインモジュールの設計とコーディングを担当し、他のメンバーはさまざまな角度からサポートを提供します。
  • 群れモード：初期の非常にカジュアルなソフトウェアチームモード。進化の期間の後、他の後続モードに変換されます。
  • コミュニティモデル：メンバーの配布は時間とスペースに制限されず、全員が好みに応じて開発するプロジェクトを選択し、通常は報酬を必要としません。
  • スターモード：主治医モードを使用する際の最も重要な点である、「スター」を付けるチームの能力は、すべてのチームメンバーの欠点と利点を覆い隠します。
  • アマチュア劇場会社モード：固定されたチームはなく、メンバーにはさまざまなプロジェクトで固定された仕事の割り当てがありません。すべてのメンバーは「セントラルコマンド」によって指示されます
  • 秘密のチーム：外部の干渉なしに秘密の状態で実施され、チームは独自の使命を負い、内部のメンバーは高い自由度と熱意を持っています。
  • 特別エージェントチーム：チームは専門家で構成され、いくつかの緊急の問題を解決する責任があります。
  • 交響楽団モデル：多くの大規模なソフトウェア会社で使用されており、メンバーとリーダーは強力な能力を持ち、同様のプロジェクト開発経験があり、すべてのメンバーがその職務を遂行しますが、リーダーのリーダーシップの下で統一されます。
  • ジャズモード：交響楽団モードとは逆に、比較的ルーズで、リーダーがフレームワークを完成させ、他のメンバーがこれに基づいて作成し、最後にリーダーが終了します。
  • 機能チームモード：固定チームはなく、異なる能力のメンバーがプロジェクトを完了するために組み合わせることができます。プロジェクトが完了すると、メンバーは他の異なるプロジェクトを実行するために再編成します。
  • 官僚的モデル：大きな機関の組織構造から生まれた何人かの人々は小さなボスに報告し、小さなボスは大きなボスに報告します。悪質な競争を形成することは簡単です。
• ウォーターフォールモデルとその変換、プログレッシブ配信プロセス、アジャイルプロセスなどの一般的なソフトウェアプロセスモデルの特性を理解します。
  • 　ウォーターフォールモデルは、予測的ライフサイクルおよび完全に計画主導のライフサイクルとも呼ばれる、古典的なソフトウェアライフサイクルモデルです。このモデルでは、プロジェクトのライフサイクルの最も早い時期に、プロジェクトの範囲と、プロジェクトの提供に必要な時間とコストを決定する必要があります。
  • このモデルでは、プロジェクトが開始すると、プロジェクトチームは製品とプロジェクトの全体的な範囲の定義に集中し、製品（および関連する成果物）の配信計画を策定し、各段階で計画を実行します。プロジェクトスコープの変更は慎重に管理する必要があります。新しいスコープがある場合は、再計画して正式な確認を行う必要があります。頻繁に変更されるプロジェクトの場合、ウォーターフォールモデルは役に立ちません。
• プログレッシブ配信プロセス
  • Steve Mike Cornellおよび1996によって要約された段階的な配信プロセスは、反復的な開発プロセスに近いものです。これは主に、システムの主な要件とアーキテクチャが明確な場合、図に示すようにソフトウェアチームがサイクルに入り、プロジェクトが資金不足になるか、プロジェクト時間が不足するか、製品がユーザーを満足させるまで、サイクルが継続することを意味します。
    
• アジャイルプロセスが続く開発原則
  • 顧客のニーズを満たすための貴重なソフトウェアの早期かつ継続的な提供;、
  • アジャイルプロセスは需要の変化を歓迎し、この変化を使用してユーザーの競争上の優位性を向上させます。
  • 利用可能なソフトウェアを定期的にリリースします。リリース間隔は数週間から数か月まで可能で、可能な限り短くすることができます。
  • ビジネス担当者と開発者は、プロジェクト開発プロセス中に毎日一緒に作業する必要があります。
  • 野心的な人々をプロジェクトの中心として、彼らを完全にサポートし信頼します。
  • チームの内外を問わず、対面式のコミュニケーションが常に最も効果的なコミュニケーション方法です。
  • 利用可能なソフトウェアは、プロジェクトの進捗状況を測定するための主要な指標です。
  • アジャイルプロセスは持続可能な開発を維持する必要があります。リーダー、チーム、ユーザーは現在のペースで協力し続けることができるはずです。
  • テクノロジーとデザインに常に焦点を当てることによってのみ、私たちはますます俊敏になることができます。
  • 簡潔にすることは非常に重要です。できるだけワークロードを単純化するスキルです。
  • 優れたアーキテクチャ、要件、設計を作成できるのは、自己管理チームだけです。
  • チームの効率を改善する方法を常に要約し、それを実行に移します。
• TSPの原則
  • 明確に定義されたプロセスを使用して、プロセスの各ステップを繰り返し、結果を測定できます。
  • チームの各メンバーは、チームの目標、役割、製品を統一的に理解しています。
  • 成熟した技術と慣行を使用するようにしてください。
  • 可能な限り多くのデータ（チームにとって悪いデータを含む）を収集し、そのデータを使用してチームが合理的な意思決定を行えるようにします。
  • 現実的な計画とコミットメントを作成し、チームプランは特定の実行役割によって（上司からではなく）開発する必要がある
  • チームの自己管理能力を高める。
  • 品質の向上に重点を置き、ソフトウェアのライフサイクルの早い段階で問題を発見するよう努めます。品質を改善する最も効果的な方法は、包括的かつ綿密な設計作業を行うことです（後で問題を修正するために急いで行うのではなく）。
• ディスカッションのスクリーンショット
  
  
  

大学チームプロジェクトテスト分析を選択する

• 北京航空宇宙学大学のコンピュータソフトウェアエンジニアリングの春の学校のPureManチームプロジェクトを選択してください

  • 選択したプロジェクトのブログリンク
  • 選択されたプロジェクトGitHubリポジトリリンク

• チームプロジェクトを選択した理由

  • 主な理由は、プロジェクトがモバイル端末に実装され、APPであることです。このプロジェクトを通じてモバイル端末の開発に慣れたいし、チームプロジェクトの開発方法を学ぶことができます。

• チームメンバーの分割と協力

  • 私の意見では、チームは主にシンフォニーモデルを使用して開発し、開発者は主にクライアントの機能とインターフェースの実装を担当します。当初、分業は各人がそれぞれの機能に責任を負い、定例会議で遭遇した障害を伝えたり、会議を進行させたり、機能を追加する場所を決定したり、全員の団結を確保したりすることです。同時に、2人の開発者が定期的にすべてのインターフェースを統合します。そして美化しなさい。テスターは、互換性テスト、クライアントのストレステスト、および各機能の統合テストを完了する責任があります。プロジェクトマネージャーは、さまざまなドキュメントの記入、会議の開催、プロジェクトを進めるためのタスクの手配、関係者とのコミュニケーション、調査、および促進を担当します。

• プロジェクトのソフトウェアプロジェクトプロセス特性を評価する

  • チームのプロジェクト開発プロセスは、私の意見では、主に開発用のシンフォニーモデルを採用しています。各メンバーにはそれぞれの役割があり、統一されており、この部分の実現は主にプロジェクトマネージャーの全体的な計画に依存し、開発プロセス中のリアルタイム調整はプロジェクトを非常にスムーズに進行させます。

• 次の図に示すように、プロジェクトウェアハウスファイルには仕様書が含まれています。
  

• デプロイして使用し、バグを見つけます。
  
  上記は、モバイル端末にデプロイするために使用したレンダリングです。問題が見つかりました。モバイル端末のインターフェースには、背景がなく、インターフェースは非常に単一です。もう1つは、ナイトモードを私の電話に直接表示できないことです。これは、彼がブログで言ったことと矛盾しています。

• チームプロジェクトが継続的な開発に値するかどうかを評価する

  • このプロジェクトは継続的な開発に非常に価値があると思います。目の前にあるものについては、このコースの研究ではブログが広く使用されています。このプロジェクトの実装は、使用するのに非常に便利です。長期的に見ていきましょう。開発者の家、つまりブログガーデン。さらに機能を追加すると、開発者がエクスペリエンスを使用するのに非常に便利になります。

「実験4ソフトウェアプロジェクトケース分析」のさまざまなタスクに費やされた実際の時間

タスク	費やした時間（時間）
タスク1	5.0
タスク2	3.0
タスク3	10.5
タスク4	2.0

まとめ

この実験の研究を通して、私は最後の実験の欠点とチーム開発のプロセスを学びました。特に課題3を勉強しているときはとても助かりましたが、気持ちがとても良かったので、自分と他の人とのギャップをはっきりと理解できました。教材の知識を学ぶことで、チーム開発のモデルやプロセスを明確に把握でき、今後のプロジェクトに役立てられます。