「法の構築、」個人的な概要

この作品は、コースに属し	システム分析と設計
運用要件	運用要件
ジョブズゴール	プロジェクトやプログラム上の要約のレビューを行って
オープン質問ブログのリンク	最初の仕事

質問の（A）開始が答え

「成長のソフトウェア工学」第三章では、質問1で

専門と洗練の3.3議論。一部の人々は、人はすぐに、これは、彼らが、私たちはすぐにいくつかの曲を再生することができますどのような、ワンマンバンドの大道芸を思い出させる、フルスタックエンジニアを育てることができると言います。対決は、ちょうどあなたがそれを再生するためにお金を費やすことをいとわないものに耳を傾け、楽器ミュージシャンを学んでいますか？
また、私はこの議論で困惑しています：私は1つがチームの開発にコミュニケーションと技術者のコストを削減するスキルの多くの側面を理解することであるならば、人々は、利点をより技術的な側面を理解するだろうと思いますので。第二には、より多くのスキルを学び、また、将来的にはより多くの選択肢を持つことになります。しかし、技術に特化した場合、それは方向に多くの時間を意味しますが、人、知識の狭い範囲で通信コストの高さは、そうまだ比較的混同される広範なバランスでスポットを調整する方法。

A：テレビで、生活の中や書籍であるかどうか、私たちは常に人々のサクセスストーリーの様々なを参照してください、彼らは最初のすべての側面のエリートであり、彼らが唯一の自分の分野に焦点を当てていると思いますが、後ろのしかし、彼はことを発見し
、人々の簡単な教師、その要件の状態、ティーチに学生に彼らの専門的な知識を向上させるために継続するだけでなく、心理学を勉強するだけでなく、教育の「複数の役割を」持っていましたそして、他の知識を理解するために、学生を発見。
だから、私の個人的な見解を追加するために、法律の建設と併せて、私が思うに、エンジニアとして、我々は最初にその分野を見つける必要があり、その後、第二に、小さなに関連する順序を理解するために行く、罰金科学に、特化する
プロジェクトにあなたは、独自に開発し、プロジェクトの前と後に知ることができますが、大規模なプロジェクトのために、我々はそれだけで自分のフィールドを完了する必要があること。

第四章、「彼らの協力」に質問2.

、4.7での議論で述べた「と人々はMBTIタイプ......、好きではない、別の性格タイプは、協力のすべての段階での対処方法、協力に大きな影響を持って話し合う？」そのチーム文字のメンバーは、プロジェクトチームの品質に影響を与える可能性がある、と私はMBTIテストがより良いに結合されるために、チームの設立前に行われる必要がありそうならば、人々は物事のスタイルで違う個性に大きな違いがあると思うし、態度の問題を扱いますチーム

：教室での学習とBaiduは、関係の私の仕事、そして彼らの人格の特定の理解がある場合MBTIは人々を扱う様々な種類の通じ、それは仕事で競合の数を削減する、チームワークの効率を大幅に向上させることができるので、チームメンバーは、チームメンバー間の理解と協力を支持しているときMBTIテストを設定することができます。

中問3では、第5章、「チームとプロセス」

こうした「ウォーターフォールモデル」、「統一プロセス、」インクリメンタルモデル話した学校の教師が、これらの開発プロセスなどの古典的な「ソフトウェアプロセスモデル」、の多くがある、開発文書で使用されていることを認識し、5.2を読んで文書は、スキルのテストです文書によって駆動されて、私はよりよい解決策があるかどうか、それはソフトウェア開発のより面倒なプロセスだったと思う、または他の文書は、そのソフトウェアエンジニアリングモデル、それに焦点を当てていませんか？

A：練習プロジェクトを学習し、教室では、私はプロジェクトの開発プロセスの文書を開発することを学んだの役割は当面に代わるものではありません、両方の要件分析とソフトウェアの設計は、キャリアのために理解することは直感的かつ簡単に必要開発者や顧客が通信や規程を策定し、文書がそのソフトウェア開発のいくつかのモデルでは、非常に適切なキャリアであるために、ソフトウェア開発およびドキュメンテーションは欠かせない、でもアジャイル開発のままでなく、弱体化いくつかは、文書の特徴、まだ交換することはできません。

質問4では、第10章、「典型的なユーザーシナリオ」で

エンジニアは10.3.3デザイナー体現し、以下の原則に言及した方法：オペレーティング環境に対応したプログラムモジュール、関連モジュール、入力および出力パラメータは任意の仮説を持っていますか？これらの仮定は、それを検証していますか？私はそれについて考えていたプロジェクトをやってこの最後の夏、仮定と実際のデータの入力および出力パラメータのエラーがあるとき、方法を調整するには？再調整のコードは、おそらく多くのコードを移動します。どのようにデータの非互換性の問題を回避し、データが正式に動作していることを前提とします。

：授業やプロジェクトと一緒に練習することで、私はオペレーティング環境やプログラムの入力および出力パラメータを考えると、それは要件文書の仕様や設計文書で良いことがありますので、パラメータに関する仮定は経験が必要、それは一般的に経験されますプロジェクトに関わる専門家は、入力パラメータの精度を保証するために、分析および設計プロセスを必要とするだけでなく、リワーク文書デザインのテストケースの量に基づいて、ソフトウェアモジュール間の結合度に依存するべきで、コードは、テストフェーズ中に試験に合格しません。

質問5.第13章、「ソフトウェアテスト」

13.3.2ここでテストケースを議論するには、この本は、ソフトウェアが可能な入力と環境パラメータの多くがあると言う、我々はすべての可能性も必要な排気する余裕はありません。ここでの唯一の同値分割、境界値分析、デシジョン・テーブル、テーブルと因果機能チャートの方法および他の方法は、この規格に沿ったものであるか、有効な試験を構成する指定しない方法の一部のみを言及しました。

A：先生と一緒に平和プロジェクトを作成するための時間、私は良いテストケースを考えて、それは三つの特徴持っている必要があります：
1。全体的な完全性：「良い」テストケースが完了し、全体でなければならないが、効果的に組み合わせて使用する例集ですテスト要件の完全なカバレッジを完了することができ。
2.同値分割精度は、各等価クラスは次のように保証されているため、長い入力テストパスの一つとして、他の入力は、試験に合格しなければならない指します。
3.等価クラスは、コレクションの完全：すべての可能な境界値と境界条件が正しく識別されていることを確認する必要があります。
三点の上に行うことができます、あなたはテストが完了し、テストカバレッジのニーズを行うために、あること、十分かつ完全であることを確認することができます。

（B）は、この学期の後、あなたはどのように把握し、以前に存在しなかったスキルをマスターしています。

教室では、私がどのようなソフトウェアエンジニアリングとソフトウェア開発のエンジニアリングプロセスを学びました。また、教師に焦点を当てたが、ソフトウェア開発プロセスに教示されたクラスの先生の知識と組み合わせて練習した後のプロジェクトと組み合わせるアジャイル開発モデルを、説明しながら、などいくつかの主要なソフトウェアプロセスモデルウォーターフォールモデル、プロトタイプモデル、インクリメンタルモデル、の理解実際の横方向のコードの実施形態と、その後のテストソフトウェア開発プロセスを実現するための解析ソフトウェアを求めています。一方、チームはプロジェクト管理のためのプロジェクトマネージャー、プロダクトマネージャーを決定するために、アジャイル開発モデルを使用して、ソフトウェア開発計画のための合理的な取り決めは、厳密ので、プロジェクトの品質の保護そのプロジェクトの進行を制御します。実際には、私は、オープンソースgithubの上などを探して、easyapiバックエンドインターフェイス設計の分業、ブレードプロトタイピングの使用を使用して、gitのバージョン管理ソフトウェアの使用を習得しました。

（C）の経験と概要

このコースを学習することによって、我々は恩恵を受け実践プロジェクトと組み合わせるソフトウェアプロジェクトの開発プロセスの明確な理解を持っています。開発ツールで、開発ドキュメント、バージョン管理ツール、プロトタイピングツール、インタフェース、管理ツールと開発ツールのシリーズと接触します。前方のプロジェクトと組み合わせる要件文書、設計文書や他の開発文書の準備が完了した後、予備的な文書の作成をよく知っては明らかに他の問題に進めることができない未定義の機能・ポイント・プロジェクトにはつながりません。我々はプロジェクトを管理するためにgitを使用して、バージョン管理では、これは私たちのソフトウェア開発のために多くの時間を節約するためのソフトウェア管理ツールの最初のバージョンです。我々はプロジェクトの初期段階では多くの問題に遭遇したプロジェクトの開発プロセスでは、労働者の私達の部門が合理的である、分離の前後端は、多機能分割は理想的であるため、プロジェクトの全体的な進歩の進展はまだ比較的満足ですが、とき半ばに何の集中管理機能・ポイントは、これらには、新しいモジュールは、後者に多くのプロジェクトを更新していない、より多くの設計の面でうまくいっていない、準備不十分な感じに長い時間のために、プロジェクトを促進するために非常に遅く、その結果、チームメンバー間のコミュニケーションを減らすこと、ありません残りの問題は、設計とあまりにも少ないによって引き起こされる分業で時間を過ごすために早いです。場合には、特に私たちのレベルは、プロジェクトチームの実際の行為の時には非常に高いものではない、誰もがモジュールの時間のコレクションに自分のアイデアのリードを持って、より多くの人々ことを、デザインとコミュニケーションの難しさが大きくなりました多くの問題。良いニュースは、時間の経過とともに、メンバー間の理解度が改善された通信の問題の多くは解決することができるということです。全体のプロセスが少し欠陥があるが、私は、プロジェクトの開発プロセスと関連する人気のある開発ツールの一定の理解を持って、ソフトウェア開発業界における将来の仕事のための基礎を築きます。