2020年の個人的な読書のブログソフトウェアエンジニアリングの求人

2020年の個人的な読書のブログソフトウェアエンジニアリングの求人

プロジェクト	コンテンツ
コースリンク	春2020コンピュータソフトウェア工学研究所（ロジャー・レン建）
運用要件	個人ブログのジョブ
コースの目的	理論とシステムソフトウェア開発プロセスの学習、実践を通して蓄積したソフトウェア開発経験
このブログの収穫	良い本を読んで、ソフトウェアとエンジニアリングソフトウェアの予備的な理解、そして自分自身の思考を行います

一つの問題：フル教科書（「法の構築」）、リストをざっと見てあなたはまだ理解していない、あなたの個人ブログに掲載5-10の質問に、。

• 完了の最も適したプログラムをテストユニット？

  元のテキストは、2.1で述べました：

  ユニットテストは、コードに最も精通し人々（プログラムの作者）によって書かれている必要があります。コードの目的、特徴および実装の制限のコードの最高の理解。そこで、著者らはこれ以上の適当な候補よりもユニットテストを書くません。

  ここでは、私はプログラムロジックのほとんどを理解し、プログラムの書かれた手順を実行しているを理解することができ、ユニットテストを書くことで、100％のコードカバレッジを達成することが可能です。しかし、100％のテスト範囲は、それが正しく機能しなければならないことを意味しますか？

  ビューの私自身の経験ポイント、テストケースを書くことができるプログラムの作者は、動作中のプログラムを作るものの、モジュール機能要件を完成するに至った、すべての後に、たった一人、思考上の制限があり、コードのすべての部分が、プログラムの作者を実行するから、抜け穴は、いくつかの特別な場合を行方不明、でもテストフェーズを書くためにこの考え方の抜け穴は、ケースには誰が見つからなかったときに思い出していません。

  たとえば：そのプログラムが攻撃に対して脆弱になっているので、以前のOOの授業発現導出では、我々は、3つのベッドルームの極端なテストケースを作成し、その後、睡眠幸せに進みます。結果は次の日の朝、誰かが私たちは、プログラムを爆破するために、アカウントに非常に簡単なテスト・ケースを取り、関数の完全なコードを再起動し、デバッグ、テストなどではなかった領収書を発行しました。

  また、10.3節でも述べました：

  スペックではユニットテストを書く方法を知ることができます仕様の記述から、機能の説明を確認する方法を説明したい、それがリンクのテストケースに最高です。

  スペックは、PMの機能要件の最良の理解が書き込みにユニットテストを行う方法最も適した人物計画であるとして、完璧ですので、機能を確保するために言って、PMによって行われますか？著者は、単に異常が実行時に発生することができないことを保証するために、いくつかのテストケースを追加する良いユニットテストコードのカバレッジを計画しますか？

• 最後の問題で推定作業時間？

  6.2の元、我々はアジャイル開発を導入し、あなたは、開発プロジェクトの進捗状況を追跡するために、バーンダウンチャートを使用することができます。残り時間を推定する、私は一人一人のアジャイル開発の熱意を見て決めた、それはすべての後に、非常に重要であり、ほとんどの場合、締め切りは常に最初の生産力です。

  以下は、実用的なプロジェクトバーンダウンで、追跡日の3倍の値があります。

  実際の残り時間（残り時間）：各チームメンバーのすべてのタスクの残り時間の合計。

  予測によると、一日を通して残り時間誰も理論上の進捗状況：残り時間（投影残り時間）を推定しました。

  費やした実際の時間（完成時）：実際の時間を費やしました。

  しかし、プロジェクトの実際の開発では、それは非常に困難である時間を推定しました。時間は、特にこれらの私たちのために、学生たちは、実際の難易度と比較して違いを推定することができるか、ほとんどエンジニアリングの経験ではない、短すぎる長すぎるために、それは仲間の熱意を動員することができない、仲間からの圧力、ピア影響労働条件が原因である可能性がありありそれが動作し、残りの少しの時間？私は質問をお読みください。

  ただし、テキストも8.6節で述べました

  ではない、むしろ躊躇「準推測」するためには、または元のルックスは、トリッキーな推測正直に進捗状況を報告しないようにします。アジャイル開発プロセスでは、一見コテージは、私がしていると接触多くの方法があります：

  数日間の代わりにパンチ、複数の指が、少数の人々は悲鳴 - ゲームの推定を推測

  ちょうど仕事がに残り時間を推定することを言うときに我々は推定時間を決定することができないとき思えるそれはそう？だから、気軽に時間が過労タイトすぎると言うかもしれないこの仲間は、それが長すぎるため、たるみのものとすることができる、またはあなたがその「時間を言い訳することができますので、ちょうど、これを言った場合には、常にばかり与えてきた、私はできません時間のような短い期間でタスクを」完了します。装飾はそれが重要な多くの意味をなすようには見えませんので、この時間は、私たちは、タスクを完了するために一緒に推定時間を合理的な力を使用するより良い目標の彼らの共通の追求に頼ることができますか？

• ユーザーの典型的なタイプは、少しすぎですか？

  オリジナルは、私たちのために、一般的なユーザーの次の種類の10.1節で述べました

  典型的なユーザは、次を含めることができます：

  1.名前（より自然な、より良いです）

  .......

  ユーザの前記嗜好

  これの名前以外の削除ユーザコンテンツ情報は問題ではない、完全な9限り、我々は、ユーザーの6種類を岩の例を販売するサイトを構築するための本を与えた、とリストが。しかし、実際にはソフトウェアプロジェクトの広い範囲が、ステージはまだそれを構築するために詳細典型的なユーザーのレベルを決定するためにどのような調査を開始していませんか？どのように多くの種類の典型的なユーザーのは、それを定義する必要がありますか？この本は、一般的なユーザーの例を示し、それによって、それは事前に一般的なユーザーのさまざまな内容の範囲を減らすことは、これらの2つの工程順に変更するかどうか、フィルタユーザーにユーザー調査を行い、その後構築することです、と？

• バグテスターが直ちに開発者に引き渡さ表示されるかどうか？

  オリジナル章11.5で述べました

  ダンボ：また、私は多くの場合、テスターに行くには、時にはあなたが調査し、それらを修正する時間を取るどのようなバグを発見しました。
  スーパー：あなたが相談した後、次の日を待ってから、それは価値がすぐに修復されているかどうかを調べることができます。

  ボート：だから、新しいバグが開発者に次の日の協議プロセスの後まで待つ、それは進行に影響を与えるではないでしょうか？

  スーパー：必ずしもそうではありません。なぜなら - 開発段階（1）開発者の中で最も重要な課題は、特定の機能を完成させます！（2）プロジェクトの初期段階では、それは集団的協議、開発者/テスターは待つことなく、直接、「欠陥」に対処することができますすることはできません。いつでも、テスターことができます開発者に「欠陥」が、決定を変更するには、スタッフとの協議の唯一の協議で、（3）。

  私の意見では、バグが開発者への迅速なフィードバックが最良の選択肢であるテスター。私は非常に可能性もある基底バグ開発されたコードの入力処理のバグに基づいて行うので、速やかに切断されていない場合、入力処理にバグが発生したため、バグが、それは真剣に、さらににつながる、などOOコース一回として、開発の効率に影響を与えます開発、そして最終的には大幅な体重変化。そして、開発者にバグテスターは、開発者が即時修理のバグかどうかを決定するために、バグの後に理解できるように、害よりも良いことがありますか？

• 成功した企業は本当に簡単にアクセスイノベーターのジレンマそれ？

  オリジナルの16.1に言及

  成功した企業は、中年を入力する場合、それらはまた、成熟市場では「技術を維持する」と技術的な環境を維持するとして知られている成熟した技術の主流に革新的な技術の市場は成熟し、今年の成功、繁栄に技術革新、技術は、企業の成否に影響を与える主な要因ではありません。しかし、破壊的技術は驚異的な製品および市場リスクをもたらすでしょう、これらの企業プロセス、価値観や文化が破壊的技術を撃退します。

  破壊的技術は確かに巨大なリスクになりますが、おそらく破壊的技術は、企業が独自の文化や製品のすべてを捨てる必要があることを意味するものではありません。成功した企業は、スタートアップと接続よりも多くの固体の資本を持っている試行錯誤のためのより多くの機会を持って、新製品はまた、便利な一般化されています。このような、より魅力的でなく、新製品のプロモーションをすることがより便利にグーグル、マイクロソフト、テンセントの才能として。本当に回のパルスを把握することができる中小企業の一握りとは対照的に、市場に到達し、我々はそれが破産をロールバックされますと信じています。だから、私が思うより成功するビジネス革新は、より合理的な数です。

質問2：ウィル「ソフトウェア」および「ソフトウェアエンジニアリングは、」これらの単語が表示される方法です - いつ、どこで、誰が？

2000年には、フレッド・シャピロ、イェール大学ロースクールの図書館員は、より以前のTukeyの1958年論文「コンクリート数学の教授は、」JSTORの電子アーカイブの検索で見つかった用語「ソフトウェア」の最古の使用を含んでいることが明らかに書簡を公表しますターキーはそのような貨幣の信用を主張したことがないが、2 years.ThisによってOEDの引用は、特にその同じ年に出版され死亡記事では、用語をコイニングで信用テューキーの多くを導きました。1995年、ポール・Niquetteは、彼は、エンジニアリング文脈における用語「ソフトウェア」の彼のclaim.The最古の出版をサポートしているすべての文書は、リチャードR.カーハートによって1953年8月にあった見つけることができませんでしたが、彼はもともと、1953年10月に用語を造語した主張しました、RANDコーポレーションインチ

用語「ソフトウェア」のうち、3つのバージョンがあります：

• ジョン・ワイルダーテューキーで1958発表論文コンクリート数学の教授がで述べました。
• ポールNiquette 1995年には、彼があったと主張し、1953年に最初の10月に提案したが、証拠はありません。
• リチャードR.カーハートで1953年 8月の中のエンジニアリングのコンテキストで提示。

[独立し、マーガレット・ハミルトンは、彼らが正当性をやっていたものを与えるためにアポロ計画の間に規律「ソフトウェア工学」と命名します。

「についてソフトウェア工学」、ウィキも非常により、最終的に詳細、および言ったマーガレット・ハミルトンにアポロ計画規律の間には、「ソフトウェア工学」と命名されます。

質問3：私たちは、すべてのソフトウェアおよびソフトウェアエンジニアリング、ソフトウェアエンジニアリングの開発プロセスの起源を知っているあなたが面白いトリビアや物語を見つけるものの中にあるのでしょうか？

• グーグルは、Googleと呼ばれるスペルミスますので最初は、それがでした。実際には、ドメイン名を登録するにグーゴルをしたいと思い登録されています。アメリカの数学者エドワード・カスナーの9歳の偉大な甥によって作成された数学的な用語のグーゴルは、ある、と10 100の電源を意味し、100ゼロに続く1を表します。これはちょうど、同社の野心的な科学技術の意思、それを満たすためではない、非常に大きな数でしたか？
• Googleがオンライン広告の世界最大のプロバイダーであるが、一方で、GoogleのChromeブラウザ、最も人気のあるプラグインは、プラグインの広告自分好みプラスを遮断され、これはGoogleの独自の開発です。プラグインをインストールするには、ユーザーが気になりますグーグルでインターセプト、にあなたを取得しようとしながら、でも、広告を見た広告を提供しながら、しかし、コンバージョン率は、同様に、実際のユーザーエクスペリエンスを向上させる、それらを見てみましょうかもしれませんが、非常に低いです。

質問4：現在人気のあるソースのバージョン管理ソフトウェアとプロジェクト管理ソフトウェアに関するオンライン調査、何、何の利点と欠点？

以下からのユーザー数、上のソートウィキは、ショーの人気下表に見つけることができます：

各種ソフトウェアの利点と欠点について、参照を含むがこれらに限定されない文書1、文書2、文書3

• ギット

  • 利点：個々の分散開発に適した、強調。サーバと大きすぎることはありませんデータの量に世論の圧力。高速かつ柔軟な。あなたは簡単に二人の開発者の間で矛盾を解決することができます。オフライン作業。

  • 短所：学習サイクルが比較的長いです。型破りな思考。悪いセキュリティコードは、ライブラリ全体のクローンダウン開発者いったんすべてのコードとバージョン情報を完全に開くことができます。

• SVN：

  • 利点：一般的な思考の習慣に沿って簡単に管理、明確なロジック、。より高いセキュリティを確保するための集中サーバー。コードの整合性は非常に高いです。プロジェクト開発の数が少ないの発展のために。
  • 短所：サーバー、データベース容量の急増にあまりにも多くの圧力。サーバーに接続できない場合は、本質的でない作業、サーバーは接続しないで、提出することができないことができれば、削減、コントラストと同様に、第二段階の上に見ることができます。オープンソース開発には適していません。しかし、階層管理を、達成することができ、非常に明確な著作権管理の仕組みは、一般的に経営を集中されているので、開発問題の多数に優れたソリューションいます。

• Microsoft TFS：

  • 优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM，能与 VS 无缝接合。

  • 缺点：搭建、维护tfs比较复杂，硬件要求也比较高。

• GitHub:

  • 优点：GitHub是一个非常万能的工具。对于任何大小的项目，他都是理想的工具；他也是伟大的web工作流工具。首先，他可以作为一个版本控制系统和协作工具，用它来发布工作。利用GitHub，你可以将项目存档，与其他人分享交流，并让其他开发者帮助你一起完成这个项目。优点在于 ，他支持多人共同完成一个项目，因此你们可以在同一页面对话交流。创建自己的项目，并备份，代码不需要保存在本地或者服务器，GitHub做得非常理想。你可以通过Github评论，提交错误。在GitHub页面，你可以直接开始，而不需要设置主机或者DNS。
  • 缺点：如果，你是Github使用新手，首先的挑战就是摆正心态——需要不断实践和时间。他可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。

• Trac：

  • 优点：Trac做一个SCM配置管理平台，意味着它有良好的扩充。Trac的权限体系是比较完备的设计。非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
  • 缺点：不支持多项目，需求和缺陷没有分离，用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了，中文化不完整，美术人员接触起来困难重重，不显示中文名，本地化做得很差，核心功能很少，不安装插件基本上没法用。

• Bugzilla：

  • 优点：BUGZILLA不收费, BUGZILLA现在有中文版支持
  • 缺点：BUGZILLA只能管理缺陷

• Apple XCode

  • 优点：可以自动创建分类图表。自动提供撤消、重做和保存功能，无需编写任何编码。
  • 缺点：更新版本后，某个插件可能会失效。

• Rational：

  • 优点：建立在非常优秀的软件工程原则基础上的，例如迭代，需求驱动，基于结构化的过程开发。
  • 缺点：仅仅包含了开发过程。它没有完全覆盖软件过程。不支持组织内的多项目开发，导致组织内的大范围的重用无法实现。