チームの3番目のジョブデマンド分析

この課題はどのコースに属していますか < クラスW、2020年春(福州大学) >
この求人はどこにありますか < 職務要件 >
この割り当ての目標 プロジェクトのニーズ分析
宿題 < 宿題文 >
その他の参考文献 <「建設の法則」

part.01チーム全体の配置

指導の取り決めに従って、初期段階で、ブログのオープン、ペアプログラミング、トピック選択レポート、システム要件分析の作業を完了しました。

私たちのグループは比較的複雑なプロジェクト機能を持っているため、プロジェクトを予定どおりに完了するために、私たちのグループは教育の手配に加えて追加の計画を作成しました。

システム分析の必要性:トピックを選択する当初の目的は、実用的で保守可能な製品を作成できるようにすることであるため、プロジェクトの構造は非常に重要です。教育体制の「システム要件分析」の際に、要件-関連するオープンソースプロジェクトを見つけて、プロジェクト全体のアーキテクチャプロセスと方法を学びます。

システム設計時およびデータベース設計時:配置の指導のタスクを完了することに加えて、バックエンドでプロジェクトの構築を完了する予定です。WebおよびAndroidもプロジェクトの構築を完了し、オープンソースUIコントロールの使用を見つけてテストを開始しました。

プロジェクトのアルファスプリント中:この12日以内にプロジェクトの開発を完了し、バージョン1.0をリリースする予定です。

Zhuge Liang氏の余波:テスターを探し始め、テストフィードバックを収集する予定です。

プロジェクトのベータ版スプリント中:プロジェクトの改善、バージョン2.0のリリース、オンラインでの積極的な宣伝を開始する予定です。


part.02分業と作業負荷の割合

  • メンバーの熱意を動員し、チームメンバー間の協力を高め、将来的に合理的な分業を強化するために、チームは今回からメンバーの分業の重み付けを導入し、それを文書に記録し、最終的に総重みに応じた貢献率を割り当てます

  • チーム分割ドキュメントのダウンロード:< チーム分割ドキュメント >

学生証 仕事内容 寄付
221701412 インターフェースプロトタイプ設計防御PPT(1)、要件仕様改訂(1)、要件分析レポートPPT(1)、プロトタイプ設計への参加(1)、2つの防御(2)、タイミング図(1) 21.875%
221701414 インターフェイスのプロトタイプ設計レビューフォーム(1)、要件分析レビューフォーム(1)、完全なブログ(1)、プロトタイプ設計への参加(2) 15.625%
221701417 Webフロントエンドプロトタイプデザイン(1)、レコードQ&Aレコード(0.5)、要件仕様の導入部分(0.5) 6.25%
221701418 Androidプロトタイプ設計(2)、要件仕様の機能説明、および受け入れ検証標準パーツ(2) 12.5%
221701420 Webバックグラウンドプロトタイプ(1)、アクティビティ図(2) 9.375%
221701429 防御には2倍のスコアが付けられます(1)、要約要件仕様(1)、要件仕様の全体的な説明部分(1)、Webフロントエンドプロトタイプ設計(2)。 15.625%
221701431 Androidプロトタイプ設計(2)、クラス図(1) 9.375%
221701439 Webバックグラウンドプロトタイプ(0.5)、レコードQ&Aレコード(0.5)、要件仕様の機能説明、および受け入れ検証標準パーツ(1) 6.25%

Part.03インターフェースプロトタイプ設計


Part.04インターフェースプロトタイプ設計回答PPT


Part.05要件仕様


Part.06需要分析レポートPPT


Part.07評価フォーム


Part.08このブログのすべての添付ファイル

一つ一つ面倒だと感じた方は、こちらのブログの添付ファイルをすべてダウンロードできます(チーム分割ドキュメント+インターフェースプロトタイプ設計防御PPT +デマンド仕様+デマンド分析レポートPPT)


Part.09回答のまとめ

トピックの回答

  • 1.プラットフォームは卒業生のレンタルアイテムをサポートしていますか?

    • A:同窓生はサポートされていません。社会に入った同窓生は多くの隠れた危険を追加します。キャンパスで生徒カードと教師カードを読み取るにはorcを使用してください。学校の教師と生徒のみをサポートしてください。タイマーを作成してそれを年に1回更新できます。データベースのユーザーは、定期的に一致する学生番号が3年間遡って有効期限が切れたユーザーの機能の使用を制限します。
  • 2.これらのプラットフォームで重要なのは「メンテナ」ですが、これをどのように保証できますか?

    • A:在校中はメンテナーですが、退学時には後輩や女子に世代を超えて継続していく計画です。フォローアップでは、製品の商業的収益性を検討しますが、利点があるため、メンテナンスと開発がより容易になります。
  • 3.過去にも同様の製品は数多くありますが、時間と技術の関係で、期待される機能がすべて開発できていません。

    • A:チームメンバーのプロジェクトエクスペリエンスは、同じレベルの一部の学生よりも比較的豊富で、pptで表示され、この製品で検討されている主要な3つのモジュールは、以前と同じように記述されています。これは主に、以前のコードベースを再利用して新しい機能を拡張し、それを最適化することに基づいています。現在、チームはこのプロジェクトの準備を始めています。
  • 4.新しい考え方

    • A:Qishanの誇りとして、私たちはチームであり、常に一貫した目標と明確な開発の分業を維持する必要があります。私たちの目標は、保守可能、反復可能、そして実際に使用できる製品を開発することです。このために、関連する知識の準備を始めました。

プロトタイプの返信

  • 1.リースには手数料がかかりますが、どのように取引しますか?

    • A:キャンパスメソンスペースプラットフォームは、包括的なキャンパスプラットフォームです。現在、私たちのプラットフォームの位置付けは情報共有です。これは、競合製品(たとえば、黒板などの大小の公共アカウント)の比較分析によって得られた情報共有プラットフォームです。塩漬け魚などのショッピングプラットフォームとは異なり、買い手と売り手がプラットフォームで関連情報を取得した後、トランザクションはオフラインで両方の当事者によって交渉されます。
  • 2.取引紛争にどのように対処しますか?(リース品が破損しており、リース業者はそれを自分の問題とは見なしていません)

    • A:キャンパスメソンスペースプラットフォームは、包括的なキャンパスプラットフォームです。現在、私たちのプラットフォームの位置付けは情報共有です。これは、競合製品(たとえば、大小の黒板などの大小の公共アカウント)の比較分析によって得られた情報共有プラットフォームです。塩漬け魚などのショッピングプラットフォームとは異なり、購入者と販売者がプラットフォームで関連情報を取得した後、取引は双方の当事者によって交渉されます。リース商品が破損しており、リース業者が自分の問題ではないと考えている場合、このプラットフォームは両方の当事者が使用できます。取引紛争は、証拠としてプラットフォームのチャットコンテンツを提供します。
  • 3.シークレットなどの機密性の高いトピックについて、どのアルゴリズムを使用する予定ですか?

    • A:シークレットが関係するデリケートなトピックには、主に2つの方法があります:1つはバックグラウンドでの管理者による予備レビュー、もう1つは回答者の教師が通知する追加のレポート機能です。シークレットなどのデリケートなトピックがフロントデスクに投稿された場​​合レポートの数が特定の数(100回など)に達すると、ロジック処理モジュールはこの記事をバックグラウンドでアラーム用にポストし、手動で検証します。
  • 4.デポジットは必要ですか?

    • A:私たちのキャンパスメソンスペースプラットフォームは包括的なキャンパスプラットフォームです。現在、私たちのプラットフォームの位置付けは情報共有です。これは、競合製品(たとえば、黒板などの大小の公共アカウント)の比較分析によって得られた情報共有プラットフォームです。塩漬け魚などのショッピングプラットフォームとは異なり、買い手と売り手がプラットフォームで関連情報を取得した後、トランザクションは両方の当事者によってオフラインで交渉されるため、このプラットフォームには預金が含まれません。
  • 5.プラットフォームに関連するトランザクションを完了するにはどうすればよいですか?

    • A:キャンパスメソンスペースプラットフォームは、包括的なキャンパスプラットフォームです。現在、私たちのプラットフォームの位置付けは情報共有です。これは、競合製品(たとえば、黒板などの大小の公共アカウント)の比較分析によって得られた情報共有プラットフォームです。塩漬け魚などのショッピングプラットフォームとは異なり、買い手と売り手がプラットフォームで関連情報を取得した後、トランザクションはオフラインで両方の当事者によって交渉されます。
  • 6.プラットフォームがレポート機能を提供することが推奨されます。

    • A:回答した教師が追加のレポート機能を思い出させると、機密情報などの機密トピックについて報告されたレポートの数がフロントインターフェースで一定の回数(100回など)に達すると、ロジック処理モジュールはこの記事をアラームのバックグラウンドで投稿します手動検証。

おすすめ

転載: www.cnblogs.com/aahorse/p/12738757.html