201771010115-Liu Zhimei-Case Study of Experiment 4 Software Project

201771010115-Liu Zhimei-Case Study of Experiment 4 Software Project

内容	プロジェクト
<コースクラスブログリンク>	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
<宿題依頼リンク>	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
<目標を記入>	チームソフトウェアプロジェクトプロセスとチームメンバーのコラボレーション要件の学習、アジャイルプロセスの原則と関連する概念の習得
<関連コンテンツ>	ケーススタディ
<学生番号名>	ヤンリン-201771010133
<ブログジョブアドレス>	https://www.cnblogs.com/yanglinga/p/12618515.html

タスク1：実験3優れたケースの推奨： Wang Zhitai＆Han Lamei Group
https://www.cnblogs.com/hackerZT-7/p/12544280.html
https://www.cnblogs.com/hanlamei/p/12574378.html
1、对案例博文作业阅读并评论截图如下

2、克隆案例项目源码到本地机器，阅读项目代码并运行代码截图如下


以前に選択したWang Zhitaiのブログ投稿の操作に問題があるため、こちらがWang Yingqiのブログ投稿のクラスです。







对案例系统的功能总结
学生のブログ投稿でシステムの機能が詳しく説明されています。実際の運用テスト後、伝染状況報告システムが全体の伝染予防情報の概要表示を実現しました。対応する情報内容を入力後、情報を入力した時間に応じて問い合わせることができます、入力された防疫情報で確認したり、入力名（学生番号）で問い合わせたり、氏名や日付でより的確な問い合わせをしたり、入力した防疫情報を削除したり、人事機能を追加したり、グラフィカルな要約の実行とは、情報の入力、情報の削除などの対応する操作を実行した後にシステムを終了することを意味します。
3、总结本组实验三博客作业及代码设计存在问题与不足，未实现的功能及代码运行存在问题的截图等。
私の実際の操作の結果から判断すると、王英起の実験3ブログジョブの実験デザインは合理的に標準化されており、当面の欠陥は見つかりませんでした。デザインされた伝染病報告システムは、教師が必要とする機能モジュールを実装しています。全体的なインターフェースは特に美しいわけではありませんが、より実用的です。
タスク2：実験3でパートナーと協力する：「現代のソフトウェアエンジニアリング-構築方法」の第5〜6章を読み、ソフトウェアプロジェクトチームの特性を理解して習得し、ソフトウェアチームのモデルを理解し、理論的なレッスンと合わせてウォーターフォールを理解するモデルとその変換、プログレッシブ配信プロセス、アジャイルプロセス、およびその他の典型的なソフトウェアプロセスモデルの特性は、カーネギーメロン大学（CMU）のソフトウェアエンジニアリングスクールで要約されているTSPの原則を理解し、体験します。
结对伙伴交流截图如下

タスク3：クラスブログパークには、大学のチームプロジェクトを完了する必要のあるソフトウェアエンジニアリングコースが数多くあります。実験の3つのパートナーに相談し、次の3つのクラスで共同学習のための高品質のチームプロジェクトケースを選択してください。チームプロジェクトによって投稿されたすべてのブログの割り当てを追跡し、プロジェクトのソフトウェアコードをダウンロードします。
1.2016级计算机科学与工程学院软件工程 (西北师范大学) 2.2019秋福大软件工程实践Z班 (福州大学) 3.2019春季计算机学院软件工程 (北京航空航天大学)
1.私たちは、2016 School of Computer Science and Engineeringのソフトウェアエンジニアリング（Northwest Normal University）を選択しました。チームのプロジェクト割り当てアカウントリンクはhttps://www.cnblogs.com/KHBang/p/10836447.htmlです。
2.チームプロジェクトウェアハウスのgithubリンクはhttps://github.com/ss140522/bookStore.gitです。
3.分析用のチームプロジェクト
を選択する理由教師から与えられた3つのオプションクラスを実験した結果、チームの全体的なコードとドキュメントがより詳細で理解しやすいことがわかりました。
4.プロジェクトチームのブログドキュメントのシリーズを組み合わせて、プロジェクトチームメンバーの分割と協力を要約します。

人事	分業
ヤン・スチューデント	チームプロジェクトの「ソフトウェアプロジェクト仕様」の最初のドラフトの欠点、特にモデリングの不完全な記述を分析します。さらに、「ソフトウェアエンジニアリング-構築方法」機能の位置付けと優先順位を参照し、4つの機能分析を行います。象限
同級生の張	Leangooソフトウェアツールを理解し、取得したユーザーのニーズに基づいてプロジェクトのWBSを準備する
クラスメートチェン	システム設計方法とモデリングツールを設定し、システム全体のデータとデータベースの設計を分析し、ソフトチームメンバーを分割する
沙の同級生	チームプロジェクトシステムの全体的な構造とデータベースの論理構造を設計し、チームプロジェクトのシステム設計プロセスを説明し、プロジェクト分析経験を要約する

5.プロジェクトの一連のドキュメントと組み合わせて、プロジェクトのソフトウェアプロジェクトプロセス特性（TSP）を評価します。
TSPの原則：1.明確に定義されたプロセスを使用します。プロセスの各ステップを繰り返し、結果を測定できます。
2.チームの各メンバーは、チームの目標、役割、製品を統一的に理解しています。
3.できるだけ多くのデータを収集します。
4.チームリーダー全体が現実的な計画を立てます。
5.品質の向上に重点を置き、ソフトウェアのライフサイクルの早い段階で問題を発見するよう努めます。
6.チームプロジェクトのgithubウェアハウスのソースコードファイル構造にコード仕様ドキュメントが含まれているかどうかを確認します。

7.チームプロジェクトコードをダウンロードし、プロジェクトの運用環境を展開してソフトウェアを使用し、最も単純で直感的なユーザーエクスペリエンスを記述し、少なくとも2つの重大な機能上のバグを見つけて、ブログのスクリーンショットに表示します。

（1）システムのメインインターフェース

（2）書籍カテゴリ管理インターフェース


（3）ユーザー情報インターフェース

（4）商品情報表示インターフェースシステム

の最も簡単で直感的な使用方法は、最初に使用するときに少し面倒ですが、全体的に使い慣れています後で、この機能は包括的であることがわかりました。シンプルなシステムのインターフェース設計の実現だけでなく、情報と記録のリアルタイム更新、およびメールの管理機能も使いやすくなり、特に、書籍の関連情報の変更時間は、書籍データベースの時間よりも少なくなっています。 3s;違いは、ユーザーがシステムを使用するときの関連サービスの頻度に応じて、1日あたりの安定した運用システムで受け入れられるクリック数が特定の範囲内にあることです。この範囲を超えると、サーバーとハードウェアのパフォーマンスの向上、バージョンのアップグレードなどに使用できます。達成する方法。
8.チームプロジェクトが継続的な開発に値するかどうかを評価し、理由を述べますか？
個人的には、システムですでに実装されている機能はオンラインの大学生の書籍や管理の使用を満足させることができるので、もう開発する必要はないと思います。さらに、関連する管理システムは数多くあり、継続的な開発の価値は高くありません。セキュリティ面では、主に支払い面でのセキュリティ上の問題がありますが、この問題は解決されたので、この点について研究開発を続ける必要はありません;最後に、現在の市場環境では、学生が独自に中古本の取引を行っていますまれに、関連する物理的な書店にはこのビジネスが含まれており、市場で比較的競争力があるため、これ以上の開発は必要ありません。
タスク4：「Case Analysis of Experiment 4 Software Project」のブログ投稿を完了する
完成《实验四 软件项目案例分析》各项任务实际花费的时间

タスク	時間
タスク1	2.5時間
タスク2	1.5時間
タスク3	4時間
タスク4	2時間

この課題を達成した感想と経験：プロジェクトのケースを分析する過程で、プロジェクトコードの仕様のケース、ケースはよくできている、プロジェクトの仕様など、まだ学ぶべきことがたくさんあることがわかりました。詳細な仕様が記述されている;タスク3を実行するとさまざまな問題（さまざまなソフトウェアバージョンや文字化けの状況などが原因で発生した問題）が発生し、全員が使用するソフトウェアも異なる;他の人のコードを実行すると問題が発生するあなたがそれを行うときに同じ問題があるかどうか、そしてそれを解決する方法を見つけてください。