：実験名：チームプロジェクトレビュー＆コースの概要
II：実験目的と要件
（1）ソフトウェアプロジェクトのプロセスを評価するマスター;
（2）コースの内容を要約反映します。
3：実験手順
タスク1：プロジェクトグループBの結び目のチームプロジェクトに応じて再生するには、リストを確認するには、結び目プレイングプロジェクトチームにパーティーを、独自のソフトウェア製品の受入れレビュー（ミーティング・プロセスは、実験13ソフトウェアプロジェクトの受け入れの知識を参照）、および受け入れ意見の形成のための各。
タスク2：学び、学期のプロジェクトを実践し、個人的な学習のまとめブログを完了するために、各学生を依頼するソフトウェアエンジニアリングの経験。
4：ウェブテスト
|
|
|
|---|---|
|
|
|
|
|
|
|
|
（1）ソフトウェアプロジェクトのプロセスを評価するマスター; （2）コースの内容を要約反映します。 |
タスクを1：
GitHubのリポジトリに提出したこのチームのフィードバックフォームの受け入れ：https://github.com/maomaochongzu/tuanduizuoyeshiyanba
タスク2：
（1）ブログリンク「実験的ソフトウェア工学準備する」使命に5つの質問をするために：https://www.cnblogs.com/wangxuegang/p/10512539.html
：回答する質問の
次の要因から、チームのパフォーマンスの発展の展望：
ビジョンの1。一般的な原因：共通のビジョンがある場合に起因するチームに、より長く、より遠く移動する機能を持つ組織、つまり、チーム信念、信仰組織は、チームメンバーが厚いと薄いを通じて、すべての困難を克服することができるようにすることです。
2相補的メンバーの種類：組織のメンバーで構成される組織の強力かつ効果的なチームが、重要であることを確保するためには、組織は短気、または女々しいであることを想像することは困難です;または一部の専門家は表面あり、彼らは一緒にチームにもたらすことができるものの組み合わせは、したがって、基礎部材の補完的なタイプは、「のり」組織である
最大の敵の1：3のシステムをアップグレード学習しますそれは、組織が自身の最悪の敵である、彼自身、です。組織の仕事は悪循環「経験主義」に陥る可能性があるとして、チームは経験に依存する場合は、「剛性」の中に閉じ込めされる可能性があり、維持するために、組織を「自分の手で死ぬ」ことが可能です最後に建てられた、活力を維持するためには、学習を強化するためにシステムに依存する必要があります。
3.不合理な場合、最初は、合理的な場合には、顧客の要求は、合理的であるかを決定し、適切なソリューションを作り、落ち着いて、両側に受け入れ可能な解決策を見つけるために、通信する穏やかな顧客の感情的な影響はありません。
把握する方法を学習/練習/議論を通じて明確化：
このチームプロジェクトの開発プロセスの中で、最初にすべてのだけでなく、どのように私はだけでなく、技術的な側面を学ぶためにチームワークのプロジェクトチームの重要性を感じさせ、多くの知識を学びましたチームワーク、形成の優れた側面のチームが考えることが、専門的な知識の多くを習得する必要があります。
（2）自分のプロジェクトの実現可能性の分析/要求分析/ソフトウェアの設計/実装/テスト/プロジェクトの受け入れを要約/どのような「知識」を学びました
- 要件分析：私はいくつかの機会使用して彼らのニーズを取得する方法を知っている
サイトの観測：てこ（サイトは実際に起こった）と、bの
インタビュー：おせっかいを、
C調査：撮影;
D会議セミナー：ブレインストーミングを; E
プロトタイプの評価：インタフェース（機能プロトタイピングを有する）（サンプル）の反復;. Fの
シーン解析：模造（役割と遊ぶ）; G
他：文書考古学、分析ケース。 - 実現可能性の分析：ソフトウェアのライフサイクルの最初の段階では、プロジェクトのフィージビリティスタディがソリューションではなく、やる価値ソフトウェアプロジェクトは、可能な限りでは、可能な価格な限り使用することができるかどうかを判断するために判断するために、プロジェクトの実現可能性を研究することです開発時間の短い期間内に。
タスクの実行可能性調査は、次のとおり決定する問題は解決する価値はありません。問題がない場合に実行可能な解決策は、時間、資源、人材と時間の浪費を避けるために、このソフトウェアプログラムにないことをお勧めしなければならないbは、問題が価値がある場合cは...解決策は、その後、良い解決策を推奨し、予備プロジェクト計画を策定します。
フィージビリティスタディの内容は次の側面を分析するためのフィージビリティスタディ..開発プログラムのD法的なフィージビリティ・実現可能性のオペレーティングシステムC電子のF-効果的な選択肢Bの技術的、経済的実行可能性の実現可能性.... - ソフトウェア設計：ソフトウェアの設計目標は、これらの要件を達成する方法を説明するためにユーザー機能、パフォーマンスおよびその他の要件で表現ソフトウェアの要求仕様を変換することで、結果は、後続のコードの実装、テストを導くことができます。
ソフトウェア設計段階とタスクは：伝統的な構造設計方法は、ソフトウェアアーキテクチャ設計、設計データ、プロセス設計及び四つの部分のインターフェースの設計に分割され、オブジェクトBのオブジェクト指向ソフトウェア設計方法は、構造設計システムに分割されます。システム・コンフィギュレーション・データ構造及びソフトウェアのソフトウェア要件を変換するための四つの部分;. Cアウトライン設計（システム設計）のクラス設計/データ・デザイン、インターフェース設計、コンポーネント・レベルの設計;. D詳細設計（設計工程）、構造の表現ソフトウェアやアルゴリズムの詳細なデータ構造を得ることが洗練。
だけでなく、UMLモデリング図を学習するためにこの段階でソフトウェア設計：ユースケース図、クラス図、オブジェクト図、シーケンス図、コラボレーション図、状態図、アクティビティ図、コンポーネント図、図配備、図クラスました主な研究。 - 実装：私たちは理解した上でC＃言語、情報への経験豊富なアクセス、コードの統合を実行するためにコードモジュールを記述し、システムテスト、バグ修正とプロジェクト開発のコーディング標準の他の側面を使用しているプロジェクトの開発チーム。
- 試験：リリーブラックボックステストのこの部分は、構造試験ホワイトボックステスト、ブラックボックステストは、ホワイトボックスと相補的なブラックボックステストホワイトボックスの代わりに機能テストソフトウェアに焦点を当て、そしてないとしても知られている、学習しました試験方法、それはホワイトボックステストで見つかった他のタイプのエラーを発見する可能性があることは容易ではありません。
- プロジェクトの受け入れ：ソフトウェアプロジェクトの実施後、だけでなく、プロジェクトの実施、維持管理のため。
（3）個人の持ち物/ジャンクションプログラム/プロジェクトチームの個人的な経験の組み合わせを、経験について話
プロジェクトの開発チームの2ヶ月間、すでにタスクを完了するために、最初から最後までチームの形成を終了さは、経験豊富なプロジェクトのトピック、プロトタイピング、......分析は、コーディングは、バグ修正を実行しているシステムをテストし、ほぼすべての時間が時々期待される結果を得ていない、長い時間がかかる必要がありますが、我々は、受け入れの準備をしようとします行われ、達成感があります。何度も何度もショートで、まだ結果を持って、私たちのプロジェクトのステップによって完成ステップなって、文書化要件文書、システム設計文書、コーディング標準および他の一連の文書を変更します。
（4）まとめの練習のコースを要約し、あなたのリフトを与えます：
- 統計ソフトウェア工学の実践は、コードあなたどのように多くの行を完了しましたか？
アクセスからの情報に固有のコードに書かれている、長い時間の後に、特定の書き込みの中で変化の時に覚えているが、私はそれを書くためにどのように多くの行は問題ではないと思うし、このプロジェクトを通じてませんどのように多くの行マスタークラスを開発するためにどのくらいのプログラミングの知識、それは意味があります。 - あなたは、ソフトウェアエンジニアリングのジョブの2実際には多くの時間を過ごすことでしたか？
|
|
|
|---|---|
| 準備する実験的ソフトウェア工学 |
|
| ソフトウェア工学実験2つの個々のイベント |
|
| 3回の操作でのピアレビューの改善 |
|
| 実験4つのソフトウェアエンジニアリングツイニング・プロジェクト |
|
| 実験5チームワーク1：あなたがソフトウェアのR＆Dチームを設置 |
|
| 実験6チームの割り当て2：プロジェクトの選択チーム |
|
| 実験7チーム割り当て3：プロトタイピングおよび開発プロジェクトチーム |
|
| プロジェクトチームのプロトタイプに基づいて需要調査と分析：実験8チームワーク4 |
|
| 実験9人のチームワーク5：チームプロジェクトを改善し、システム設計を必要とします |
|
| プロジェクトチームの改良されたシステムの設計と詳細設計：6実験10人のチームワーク |
|
| 実験11のチームワーク7：チームプロジェクトの設計＆完璧なコーディング |
|
| 実験12チームワーク8：ソフトウェアテストとアルファスプリント |
|
| 実験13チームワーク9：BETAチームスプリントとプロジェクトの受け入れ |
|
- どちらの仕事はあなたの最も印象を作るには？なぜ？
実験7 3チームの仕事：実験では、我々はプロトタイピングの方法の無知であると言うことができるので、この作業のチームプロジェクトのプロトタイピングおよび開発は、かつて私に最も大きな影響され、実験が完了してからに委任を受けましたプロジェクトを完了するために必要な9回の実験に改善し、システム設計を必要とするだけでなく、再調査および分析のためにオンデマンドで、タスクが比較的大きい、時間となるよう私たちは、アンケートには適用されません。私たちのチームの倉庫管理システム・エラーを投影し、需要の調査方法ので、私はより深い感銘を受け、より多くを費やしています。 - 時間の累積数は、ソフトウェア工学の実践に費やさ？週あたりの時間の平均数は、使用済み？
ソフトウェアエンジニアリング時間のほぼ2ヶ月累計支出は、週あたりの時間の4日以上を費やしました。 - あなたは学び、新しい言語、新しいプラットフォームを習得しますか？
などのブログ、GitHubの、Visio2013、Mockplus、ブレード、SQL Server2014、Visual Studioの、新しい言語、新しいプラットフォームを学び、習得するには - ソフトウェアエンジニアリング開発ツール、開発手法とモデリングの方法あなたが学ぶまたは使用、研究の学期をまとめたもので、下記のフォームに必要事項を記入
| ソフトウェア開発ツール、プロジェクト管理ツール | ソフトウェア開発手法 | モデリングソフトウェア |
| Githubに、SQL sever2014、Visual Studioの | プロトタイピング、構造化プロセス、オブジェクト型現像方式の面 | 物体面タイプのモデリング |
- 収穫やリフティングの他の側面：
プロジェクトチームの開発プロセスにおけるいくつかの問題のためには、予期せぬ自体に遭遇し、プロジェクトチームのチームの他のメンバーは他にいくつかの知識を学んだアドバイスや提案を与えるだろう、とのプロジェクトを作ります開発スピード。労働、協調の各プロジェクトメンバーの部門、チームワークが良い賞品ことができます。
（5）あなたが任意のより良い提案を持っているか、当然の現在の問題をどう思いますか？
過度の授業：この研究のソフトウェア工学の科目の学期の後、私はを証明することができます。私は基本的にこのテーマに関する多くの時間毎週実験しています。私はすべての先生が助手評価作業は容易ではない、思考実験の多くを費やすことをコンテンツであることを知っています。これは、たるみを結果としてあまりに割り当て、時には精神的疲労、かもしれないが、実験の本来の目的に反するだろう。だから、私の提案は次のとおりです。実験的なタスクの適切な妥協の高効率、高品質を達成します。