201771010110-Kong Weiying-Case Study of Experiment 4 Software Project

実験4


プロジェクト	内容
コースクラスのブログリンク	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE/
この求人リンク	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
私のコースの学習目標	チームソフトウェアプロジェクトプロセス（TSP）の学習、チームメンバーのコラボレーション要件。アジャイルプロセスの原則と関連する概念をマスターします。
この課題はどのようにして学習目標を達成するのに役立ちますか	ソフトウェアプロジェクトプロセス（TSP）、チームメンバーのコラボレーション要件、アジャイルプロセスの原則および関連する概念
学生ID名	王志城-201771010130
相手をこのブログ割り当てリンクにリンクする	https://www.cnblogs.com/847118824wang/p/12675836.html

タスク1：3つの優れたケースを実験する

研究会：ヤンイェ＆ワンフイヘグループ

ブログのリンク：https : //www.cnblogs.com/http-www-whh0601-cnblogs-com/p/12553743.html
https://www.cnblogs.com/2017xinghui/p/12554158.html
GitHubリポジトリリンク：https : //github.com/yy202901582/DieaseSubmitSystem
ブログのコメント：
機能操作とまとめ
- プロジェクトは基本的に4つの主要機能、クエリ、レポート、チャート統計表示、およびリマインダーを実現しました。
- （1）個人情報の入力を実現
- （2）名前で情報を問い合わせ、大学で情報を問い合わせ、感染者に感染する
- （3）分類された統計、大学別の統計、アイデンティティ別の統計（教師、学生）、月別の統計、日別の統計、症状別の統計、地域別の統計のヒストグラム表示
- （4）時間通りに思い出させる機能を実現し、特定の時間を入力してください、それは時間通りに思い出させます
実装されていない機能とバグ
- 期間内にクエリはありません

タスク2

与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则

ソフトウェアプロジェクトチームの機能：
（1）明確で挑戦的な共通の目標を持っている

明確で挑戦的な目標を持つチームは、明確でない目標を持つチームや大きな挑戦的な目標がないチームよりもはるかに効率的です。システム設計者として、いつ実行すべきか、いつ開始すべきかを知ることは明らかです完了しなければならないときに、作業を完了するために直面する必要のある課題、これらの困難を解決する方法などを行い、高品質のソフトウェアプロジェクトを設計するための重要な保証を提供し、漠然とシステムを設計するか、漠然と実行するコードの記述は非常に危険であり、高額の費用がかかるため、効率的なソフトウェア開発チームは共通の目標に挑戦しています。

（2）チームの結束力が強い

効率的なソフトウェア開発チームでは、メンバーが集まって共同作業を行います。メンバーは、責任を負い、保守的になり、互いに非難するのではなく、お互いをサポートし、互いにコミュニケーションをとり、お互いを尊重します。多くの場合、そのような問題があります。より保守的なプログラマーもいます。別のモジュールは、作成されたプログラムコードを使用する必要があるが、いくつかの問題があることを知っています。彼はそれを取り出して他のプログラマーと共有したくありません。システム設計者と連絡を取ると、プロジェクトの進行にいくつかの計り知れない要因が生じます。

（3）調和のとれたコミュニケーション環境を持っている

開発チームでは、要件仕様を開発するための要件アナリスト、システムの概要設計と詳細設計を行うためのシステムデザイナー、プロジェクト開発環境を構成してプロジェクト計画を開発するためのプロジェクトマネージャーなど、全員が独自の責任を果たしますが、全員の作業は完璧であることは不可能です。たとえば、システムの概要設計のドキュメントに、不十分なローカルワードが含まれている可能性があります。詳細設計を行うと、誤解が生じる可能性があります。プロジェクトマネージャーが計画を策定するとき、特定のリスクの存在を無視し、実行者も過度になる可能性があります。緊張やプレッシャーなどの状況では、コミュニケーションとフィードバックを通じて全員が解決する必要があるため、効率的なソフトウェア開発チームは、単純なコマンド実行タイプではなく、調和のとれたコミュニケーション環境を持っています。

（4）仕様とフレームワークが共通している

効率的なソフトウェア開発チームは、規範的で共通のフレームワーク作業、プロジェクト管理のための標準化されたプロジェクト開発計画、分析と設計のための標準化された統一されたフレームワークを備えた文書化とレビューの標準、手順の規則とコードの規制、およびテストのための標準を持っています。合理的な試験計画、試験報告書などそして、すべてのメンバーは自分の責任を理解し、どのような計画を完了する必要があるかを知っていますか？誰がやるの？いつ始まるの？いつ終わるの？どんな順番で？要するに、効率的な開発チームは、作業内容とワークフローの両方の観点から、さまざまな程度の標準化と標準スタイルのフレームワークを持っています。

（5）合理的な開発プロセスを採用する

ソフトウェアの開発は、一般的な商品の研究開発および生産とは異なります。開発プロセス中に、需要の変化、人員の変更、技術的なボトルネック、および競合他社などの予測不可能なさまざまなリスクに直面します。効率的なソフトウェア開発チームは、合理的な開発プロセスを使用して、開発プロセスのリスクを制御し、ソフトウェアの品質を向上させ、開発コストを削減します。このようなチームは、自分の必要性に応じて実行する作業を決定しますか？構成管理、リソース管理、バージョン管理、コード管理などのチームは、開発プロセスのマイルストーンを合理的に分割および定義し、各アクティビティの内容とレビュー基準の最終的なラインを決定し、各アクティビティのシーケンスまたは反復関係を決定します等つまり、効率的なソフトウェア開発チームの開発プロセスの原則は、高効率、高品質、低コストです。

2.ソフトウェアチームのモデル

 (1)一窝蜂模式：像小朋友踢球一样，球在哪里，人就一窝蜂跟在哪里
     优点：欢乐而随意
     缺点：这种团队模式很难存活，并不是一种好的团队模式

 (2)主治医师模式：像在手术台一样，有一个主刀医师，其他人负责协助主刀医师
     优点：初衷很好，一个软件团队中，有首席程序员，负责主要模块的设计和编码，其他人尽可能从各个方面支持他的工
     缺点：在一些学校的软工课上，这种模式逐渐退化成“一个学生干活，其他学生打酱油”

 (3)明星模式：主治医师模式运用到极点
     优点：对“明星”个人的成长进步可能会有所帮助
     缺点：团队模式强调的是团队的作用，而不是个人的独角戏，这种模式显然违背了团队模式的初衷，效率也很低

 (4)社区模式：由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬
     优点：“众人拾柴火焰高”，成功案例：开发和维护Linux操作系统的社区，成功案例往往需要严格的代码复审和签入的质量控制
     缺点：“只烤火，不拾柴”，“拾到的柴火质量太差”

 (5)业余剧团模式：团队中各人扮演各人的角色
     优点：在业余玩票、培训的环境中，每个人都可以尝试不同角色，大家可以比较平等地讨论
     缺点：在竞争性强烈、创造性要求高的团队，不会存在完美主义的民主气氛。

 (6)秘密团队：有一些软件项目在秘密状态下进行，别人不知道他们具体在做什么
     优点：团队内部有极大的自由，较高的热情，没有外界的干扰。
     缺点：不可能成为普遍模式，只会针对个别项目。

 (7)特工团队：软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题
     优点：效率高
     缺点：对成员的知识面要求十分广，较为针对技术人员，不可能成为普遍模式

 (8)交响乐团模式：各司其职，想交响乐队一样
     优点：各司其职，重在执行
     缺点：呆板

 (9)爵士乐模式：与交响乐模式存在相当多的对立
     优点：领导给出一个主题，然后成员们百花齐放，各显本领，快收尾时再总结
     缺点：人员不能太多

 (10)功能团队模式：具备不同能力的同事们平等协作公共完成一个功能
      优点：效率高
      缺点：每个小组必须与其他小组就编程规范达成一致

 (11)官僚模式：脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次向上
      优点：有助于技术的交替与互补
      缺点：容易掺杂一些追名逐利，往往会使团队效率大打折扣

3.ウォーターフォールモデルと変形

ウォーターフォールモデルの核となる考え方は、プロセスに従って問題を簡素化し、機能の実現と設計を分離し、分業とコラボレーションを容易にすることです。つまり、構造化分析と設計方法を使用して、論理的実装と物理的実装を分離します。ソフトウェアのライフサイクルは、計画、要件分析、ソフトウェア設計、プログラミング、ソフトウェアテスト、運用と保守の6つの基本的なアクティビティに分かれており、上から下に固定されており、ウォーターフォールなどの相互接続の固定シーケンスは段階的に行われます落ちる。

利点：

1）プロジェクトは、ステージごとに分割されたチェックウォーターフォールモデルチェックポイントを提供します。
2）現在のステージが完了したら、次のステージに集中するだけで済みます。
3）ウォーターフォールモデルは、反復モデルに適用できます。
4）テンプレートを提供し、分析、設計、コーディング、テスト、およびサポートの方法で、テンプレートの下に共通のガイドを作成できます。

短所：

1）各ステージの分割は完全に固定されており、ステージ間に大量のドキュメントが生成されるため、ワークロードが大幅に増加します。
2）開発モデルは線形であるため、ユーザーはプロセス全体の終わりまでしか開発結果を見ることができず、開発リスクが増大します。
3）過剰な必須の完了日とマイルストーンを通じて、さまざまなプロジェクトの段階を追跡します。
4）ウォーターフォールモデルの顕著な欠点は、ユーザーのニーズの変化に適応しないことです。
5）開発のテスト段階の後半まで早期のエラーが発見されない可能性があり、深刻な結果をもたらす可能性があります。

Winstonは、製品を成功させるには、このモデルを2回歩くのが最善であると指摘しました。最初にシミュレーションバージョン（Simulation of FinalProduct）を基に、フィードバックを収集し、さまざまな手順を改善して、最終バージョンを提供します。

4.プログレッシブ配信プロセス

Steve McConnell（Steve McConnell）は1996年に要約されましたが、実際には、誰もが今話題にしている反復的な開発プロセスに非常に近いものです。システムの主な要件とアーキテクチャが明確な場合、ソフトウェアチームは進化の進化サイクルに入りました。[開発→リリース→フィードバックを聞く→フィードバックに基づいて改善する]

アジャイルプロセスの
利点：

1）アジャイル開発の高い適応性と人間指向の特性。より柔軟であり、各開発者の利点を最大限に活用して、全員の作業熱意を動員します。

短所：

プロジェクトサイクルが長いため、開発者が置き換えられないようにすることは困難であり、ドキュメントがないと、引き渡しプロセスに大きな困難が生じます。

6.カーネギーメロン大学（CMU）のソフトウェア工学部が要約したTSPの原則

TSP設立の基本原則

（1）定義されたプロセスに従って迅速なフィードバックを得るには、学習が最も重要です。
（2）効率的なチームの共同作業には、具体的で一貫した目標、優れた作業サポート環境、強力なガイダンスなど;
（3）ソフトウェア開発で実際的な問題に直面し、議論し、分析し、最終的に効果的なソリューションを取得する場合、ソフトウェア開発者は大きな利益を得ます。

説明文

（1）ソフトウェア開発チームを計画および管理する
方法（2）チームの作業に必要な戦略を策定する
方法（3）チームの各役割の責任を定義および決定する方法（4）
チームの各役割を計画する方法メンバーはさまざまな役割を割り当てます;
（5）チームマシンのさまざまな役割が、開発プロセス全体のさまざまな段階で何をすべきか、およびより良い方法

効果

（1）チームメンバー間でタスクを調整し、1日を通してチームのタスクの進捗状況を追跡および報告する
方法（2）チームのコラボレーション機能を向上させるために使用される方法。

7.ディスカッションのスクリーンショット

タスク3

1.ジョブリリースアカウントhttps://www.cnblogs.com/PureMan6/p/10739662.htmlに
リンクします 2. GitHub https://github.com/swearitagain/EduCnblogs2.0にリンクします
3.チームを選択する理由

これは本当に携帯電話で使えるソフトウェアです。ユーザーのダウンロード体験はある程度あります。モバイルアプリの開発に参加した経験はほとんどありません。今学期はAPPのデザインに関連したコースデザインを持っています。そこから学んでほしいと思います利益。

4.プロジェクトチームメンバーの分割と協力の概要

このソフトウェアの開発は合計6人で行われ、最初にPMが2人で構成され、次に6人に異なるタスクが割り当てられ、プロジェクトの計画、ファイルの調査、毎日の定期的な会議、監督、ブログの作成を完了します。機能の追加、機能の変更、APPリリース、ソフトウェアテストなど誰もが明確な分業を行っており、2、3人で完了する部署もあり、タスクが均等に分散され、機能チームモードがよく使われています。

5.プロジェクトのソフトウェアプロジェクトプロセス特性（TSP）の評価

プロジェクトには、ソフトウェアプロジェクトプロセスの特性が明確に反映されています。チームの全員が明確な責任と合理的な分業を行っています。タスクの各段階には、対応するタスクがあり、タスクの各段階には、報告する明確な時間があります。 7つの原則がよく反映されています。

6.チームプロジェクトのgithubウェアハウスのソースコードファイル構造を確認します。コード仕様ドキュメントが含まれていますか？

コード仕様書が含まれています

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

最初にソフトウェアを開き、ログインインターフェイスを表示して、ログインおよびログイン検証機能を提供します
ログイン後に個人のホームページを表示すると、個人のブログを表示できます
クラスを選択してクラスのホームページに移動すると、クラスのお知らせ、課題、ブログ投稿、投票を表示できます
クラスの割り当てを選択します。割り当ての要件を表示し、割り当てを送信できます
ホームページでは、個人情報、毎日のリマインダー、お気に入りリスト、閲覧履歴、設定、ログアウトなどを表示できます。

8.既存のバグ

パスワードを忘れた場合、アプリケーションを終了するには、Returnキーを押す必要があります
ブラウジングレコードは常に空で、履歴レコードを表示しません
クラスの課題の提出リストを表示しても何も表示されない

9.チームプロジェクトが継続的な開発の価値があるかどうかを評価し、その理由を述べますか？

このプロジェクトは開発にとって非常に価値があると思います。通常、ブログパークはWebページにのみログインできます。携帯電話のサイズとページサイズは一致しないことが多く、いつでも携帯電話でブログパーク内のあらゆる種類の情報を表示できるので便利です。ジョブを送信するためにWebサイトにログインする必要がないため、ユーザーの作業が非常に簡単になります。一部の機能を改善し、一部のエラーを修正し、ソフトウェアのセキュリティ保護を強化すると、成熟したソフトウェアになります。したがって、このプロジェクトは開発を続ける価値があります。

タスク4

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


タスク	内容
実験1	60分
実験2	70分
実験3	90分

まとめ

この課題を完了することの気持ちと経験について話してください。

この実験を通じて、チームソフトウェアプロジェクトプロセス（TSP）、チームメンバーのコラボレーション要件を学び、アジャイルプロセスの原則と関連する概念を習得しました。また、ウォーターフォールモデル、プログレッシブデリバリー、アジャイルプロセスなど、ソフトウェア開発におけるさまざまな開発プロセスをマスターしました。今後の研究では、この知識を実際の運用に組み込み、専門知識を向上させ、実際の戦闘能力を高めていきます。同時に、他のチームのプログラムコードを学ぶことで、新しい知識もたくさん学びました。比較を通じて、自分の欠点を認識し、関連する知識やスキルをたくさん学び、将来の経験から学び、将来の学習課題に蓄積することができました経験。