ソフトウェア工学の主要な事業（学生管理システム）は、Web側の個人的な要約レポート
まず、グループ情報
1、グループ：第二グループ
2、グループのトピック：学生管理システム
3、ソースコードプロジェクトのリンク：
プロジェクトドキュメントリンクの4、様々な種類
第二に、プロジェクトの作業はじめに
大規模なグループのコースワークは、彼らが三の大具体的な作業について持っています：
1、Webデザインと開発の終わり
1.1 Webデザインステージ
私はWebデザインと開発側を行っております場合は、私の仕事は、次の4つの段階に分かれています。
- フェーズワン：ニーズと仕上げを理解し、良い機能モジュール、機能モジュールとどのように多くのサブ機能モジュールが含まれているに分割され、必ず良い接点を作り、様々な機能モジュール間のリンクのいずれかの種類があるかどうかをされたどのように多くのWeb端末を決定します、ウェブデザインの方向端を設定します。
- フェーズII：下段、プロトタイプの設計と開発の方向を決定するためによれば、全体的なデザインは、実質的に完全な静的ページです。
- ステージIII：前とドッキングした後、各機能モジュールが完成します。
- フェーズIV：デザインのテストデータ、およびWebテストを行っています。
各機能モジュールの1.2ウェブ終了
私は、Webは、主に以下のモジュールに分割されて終了し、その設計と実装作業、異なる機能モジュールに対応し、ユーザー別のアクセス権のすべてを完了します、ユーザー権限機能が明確に定義され、それがこのプロジェクトの主なハイライトは以下のとおりです。
- 登録モジュールにログインします。
- 人事管理モジュール
- セクター管理モジュール
- イベント管理モジュール
- 休暇管理モジュール
- 監査管理モジュール
- 鑑定管理モジュール
- 通知管理モジュール
- 情報メンテナンスモジュール
1.3 Web開発技術を導入します
使用HTML + CSS + JavaScript開発。
メインのWebフロントページを使用すると、フロントエンドのフレームワークLayui Vue.jsビルドは、使用Echart.jsは、ページのグラフを描きます。
2は、一緒に必要なインタフェースの仕上げ終わりを入れ、ニーズ分析に関与します
最初のプロジェクトは、すべてのチームメンバーは、ニーズ分析に関与している、前方に自分の意見を置きます。
プロジェクトが遅れたら、するために、より優れたプロジェクトチームの全体的な効率を高めるために、バックエンドとの通信、私はそれぞれの端部（WEB、APP、アプレット）コメントを整理し、統一する担当しています、再び避け、必要なバックエンドAPIを上げました条件作業同一または類似のニーズの各端部の後端部に受け入れました。
図3に示すように、インタフェースは、テスト、およびバックエンド・フィードバックと通信します
- 私がそれをテストする最初のそれぞれの端に、私は積極的に再び、リリースの各端にフィードバック、インターフェイスや正しい確認を通信する誤ったインターフェイスとバックエンドのため、およびヘルプ会員が利用できるバックエンドのインターフェイスは、各エンドを理解するためにと呼び出しAPI。
第三に、プロジェクトの概要と洞察
グループの大仕事、私はチームが1 + 1 <2は、一般的に次のような感情を持っているような状況に陥る避けるために、より効率的になり、一緒に動作するはずですどのように学習し、ソフトウェア開発プロセスの深遠な経験をしました：
チームメンバー内の定期的なコミュニケーションが非常に重要であり、私たちは自分の考えや意見を表現するためにタイムリーに毎週のミーティング、プロジェクトチームのメンバーのグループを招集、現在の問題とタイムリーな解決の存在を提案し、より良い仕事を一緒には、改善することができますプロジェクトチームの開発効率;
Aは、小さなターゲットは毎週のタスク毎週を開発することが重要である段階的、およびプロジェクトのタイムリーな完了は早く、当社グループにおけるマイルストーンのほとんどのメンバーは特に、明確な低開発効率はなく、幸いにも我々は発見しますこの問題を解決するために、システムは、一週間の目標を開始し、目標日後に、プロジェクトチーム全体の開発効率が大幅に改善されました。
予備的分析と設計作業はプロジェクト全体、早期の混乱のための基礎であり、ワークロードは、データベースの初期の設計では、特定のプロセスの詳細がありますが、後でこのプロジェクトの開発プロセスを倍になります完璧ではありません、それぞれの要求を実現するために各端でワークロードを倍増における後半の結果。
適切な状況においては、同様の機能を、モジュールコードの独立性を高めるため、開発効率を向上させるために適切であってもよいが、変更後の作業圧力を減らすことができ、私はウェブ開発プロセスで午前、いくつかのいくつかの小さな機能モジュール機能的に類似するが、タイムリーな抽象化ではない、後の作業の重複の欠点を感じました。
第四に、カリキュラムの提言
研究のほぼ学期ことで、私だけでなく、専門的な知識を学び、多くのソフトウェア工学コース朱先生の興奮を感じましたが、また、私はいくつかの少しを持って、個人的に、私たちの視野を広げます次のように提言は以下のとおりです。
グループプロジェクトでは、我々は、これら3つのステージの機能実現のプロトタイプを作成する、より完全な主要な要件分析を経験しても、多くのことを学びましたが、ソフトウェアのテストは、グループプロジェクトではないソフトウェアの開発が不可欠リンクあり完全な経験。たとえば、機能を確認した後、開発とソフトウェアテスト、テストケース、テストレポートを書くの設計のフェーズをテストするソフトウェアを入力するには、この段階で達成し、発生する可能性のあるソフトウェアの異常を分析し、レポートにすることができます適切な解決策を与えられました。
ソフトウェア開発のプロセス全体では、各グループは、プロジェクトの調整の特別な役割をスケジュールし、積極的に各端のコンセンサス、協調と決意既存の問題のそれぞれの端部と通信するように設定する必要があることをお勧めします、我々は意思決定における役割を行う必要があり、かつこの役割は、技術の各最終用途の理解の特定の学位を持っている必要があり、この役割は、常にソフトウェア開発プロセスを介して実行する必要があり、ヘルプが不要な問題を避けるために、グループ全体の開発効率を向上させます。しかし、サブメカニズムのメインコースは一人一人の作業負荷に基づいており、ほとんどの人が自分のワークロードをアップグレードするために、開発者としての分数を追求することを選択するだろう、この役割の作業負荷を評価することは困難であるので、少数の人々はそれを選ぶだろう仕事。
これらは私が気分を害している場合は、私を許してください、私の個人的な思考の一部です