EDITORIAL：
| 良い気分今日は、この本の内容の残りの部分は、私はちょうどそれらの理論的な理解を読んものの、本当に素晴らしい収穫を読み終えた時間を吸っが、私はソフトウェア工学ソフトウェア工学コースのこのような理解を感じる長いプロセスを持っています私は、ソフトウェアエンジニアリングのための完全な本を読んだ後、実際のソフトウェアを行う方法がわからない、少なくとも前に大きな進展は、次の学期はそれを実践するために学ぶことができることを期待してプロセスの全般的な理解を持っています。 |
本体：
1.ソフトウェアの設計と実装
この章では、ソフトウェアを分析し、設計する方法を説明します。分析と設計方法は、グラフィカルモデリングとして、多くがあります。マインドマップを確立することにより、エンティティ関係図は、さまざまな役割間の関係を説明し、その後ニーズ及び機能を分析します。しかし、多くのコンピュータは、そのような形式的な方法、文学などの種々の方法の出現の開発の方法、プログラミングなどがあります。これらの方法には長所と短所を持って、誰もが本当に完璧ではありません。私たちが書かれた文書の分析と設計を終えた後ので、我々はこれらがそれを必要とするどのように実現しましたか？ブックリストこの開発プロセスを介して取得するために設計ドキュメントの後に開発プロセスのプログラマは、開発プロセスをより標準化することができます。開発段階では、さまざまな状況は毎日起こります。たとえば、密室でいくつかのプログラマは、いくつかのプログラマが修理BUGの時にいくつかの特別な状況をデイリービルドに注意を払っていないが、また次のようになります。気性の正義がある、埋め込まれたコードのための要件は、幅広いまたは厳格であるかどうか、であること、間違っています間違っています。これらは、2を組み合わせる必要があります。最後に、地獄のバグであるバグ地獄を、そこに表示されることがあり、開発者が唯一の開発機能に焦点を当て、ない注意を払うのバグ、バグの状況を修復するために一緒に人々の唯一のチームを作ること以上になるバグを行います。開発プロセスの同じ時刻ソース管理では、ソースコードのための一定の要件があり、我々は、最新に保つことができるだけでなく、学ぶための新入社員のための最終的なコードのリリースに最初から保持しているはずですが、また、バグの修復を助長します同様に表示および変更する未来。最後に、コードは完了です。また、このプロセスは、正式に終わりました。
2.ユーザーエクスペリエンス
最後の章の話、コード開発は完了です。しかし、ソフトウェア開発は終わりません。私たちはより良いユーザーや顧客のニーズを満たすために、さらに最適化するために、ユーザーエクスペリエンスのフィードバックを我々のソフトウェアをしたいです。私たちは、アカウントに、このような利用者の第一印象として、様々な状況を、取らなければならない、利用者がよりよい設計に私たちを必要とするいくつかの簡単なミスを、作ることはできません。ユーザーエクスペリエンスデザインソフトウェアの現在の状態を再現するために、このような紙のモデルを使用して、迅速なプロトタイピングの研究、など多くの方法が、ありますが、ユーザーが裁判官に行きます。または直接、既存ユーザーへのA / Bテストでは、新機能をテストし、顧客満足度かどうかを確認します。それでは、どのように本当の良いユーザーエクスペリエンスとは？できるだけ早く本のいくつかの基本的な原則は、ユーザーの現実的な練習に触覚フィードバックを提供するために、ユーザーは、右のコントロールになどを持っている必要があります。これらは、評価の基礎の一部です。異なるデバイスが異なるニーズを持っているため、同時に実際の状況に応じて検討します。
3.ソフトウェアテスト
ソフトウェアのテスト、リスニング、語彙の両方興奮と悲しい人。以前のすべてのソフトウェアリリースはありません確かに戦うバックをテストすることによって、テストすることにバインドされています。それでは、どの市場で入手可能なソフトウェアの様々な著者が、それを分類するためにテストされましたか？非機能テストの目的、機能テストを、テストすることによって分類;試験のタイミングで分類このようなスモークテストのような試験方法が分類されている設計によるような分類の様々な角度を介して、白象とブラックボックステストがあります。これは、その後、どのような具体的な試験方法、メソッドをテストするために設計されて？著者は特に、もはや開始などのユニットテスト、ビルド検証テスト、受け入れテストを含むテスト方法の12種類を、ご紹介します。あなたは理論を持っていたら、実際の戦闘テストで、実際の戦闘での理論に、著者はいくつかの問題のために彼の視点を提唱しました。そして、間違った行動のいくつかは正しかったです。私はプロジェクト、フィールドを拡大する方法はありません、レッツ・スキップを持っていないので、その後、実際のテストツールは、ここで使用されています。
4.品質保証
ソフトウェアが完了したら、テストを通じて、考慮すべき多くのものがあります。品質保証は、最も重要なことを行うためには、プログラムのソフトウェアの堅牢性で、そのうちの一つです。ソフトウェアは、随時堅牢なクラッシュがない場合には、そのようなソフトウェアを解除することができません。まあ、概念から最初のソフトウェアの品質を含め、起動して、何をしますか？著者はプログラムの質の面で分離されたソフトウェアの品質= +プログラムの品質のソフトウェアエンジニアリングの品質は、非常に単純である、式を示唆しています。プログラムの安定した動作は、アルゴリズムが十分に速くあるかどうか、することができます。高品質のソフトウェアエンジニアリングは、ソフトウェア開発プロセスの可視化、リスク管理ソフトウェア開発プロセスなどのように複数の側面が含まれます。それをエンジニアリングソフトウェアの品質を測定する方法？あなたはCMMI、CMMIのソフトウェアエンジニアリングは、この分類によって、5つの段階に細分化することができるというシステムは明らかにソフトウェアエンジニアリングの品質を見ることができます使用することができます。ソフトウェアの品質が何であるかを知って、品質を守る方法を学ぶ必要があります。まず、テスト、テストこの役割は、それとは独立してすべきですか？著者は、彼らの視点を提唱：それはする必要があります。実際の状況によると、いわゆる専門家でブラインド信託としての顔の役割をテストするためのいくつかの質問に、提案し、明確な分業などはありません。これらのテストは解決する必要が役割です。
5.安定しており、公開舞台
最終的には、コードは完了です。最後に、安定性とリリースの段階があります。私たちは、グループの相談は、相談のソフトウェアはバグのいくつかによって解析することができ、そしてその分類は、修理のために最高の優先順位になります様々なカテゴリーに細分化。アルファ/ベータ版を投稿。ではα/β相、ユーザーはこのフィードバックを通じて多くのフィードバックを求められますとき、それはまだ、優先度の高いニーズを優先し、優先順位に従って配置を必要とします。同時に、私たちは、新しいバグの出現が再び拡張ソフトウェアのリリースサイクルを作り、連鎖反応の形成を防止した後、開発プロセス、見た古い修正のバグが、修復することを保証しなければなりません。これは、直接、機能の一部をカットされていません。また、許容可能です。安定した一連の動作の後、ソフトウェアが正式にリリース。リリースはすべての権利を言っていないされた後に、いわゆる後知恵の会議を行うことが、私たちは、プロジェクトの開発問題を通じて出てくるだけでなく、需要の進展など、後に、より良い支援するために、要約しただろう。
6.IT業界の技術革新
イノベーションは、非常に素晴らしい言葉を聞いて。しかし、最終的には技術革新がどこから来るのか？イノベーションは本当に公共のDOに受け入れられますか？これらは、技術革新を考えるの作者です。私は自分の見解について話を自分でここにいますよ。イノベーションは、様々な知識技術革新の登場の蓄積だけでなく、知識の蓄積を必要とするだけでなく、機会の多様性を必要としますが、彼らは、定量的な原因を定性的あることは疑いがあり、定量的かつある程度までしか、いわゆるブレークスルーが表示され、本当の質的な変化を達成。しかし、たとえ提案革新場合、特に破壊的技術は間違いなく世界の構造を変更します、ということだけでなく、携帯電話の普及としてWWWが登場、というように、これらの技術革新は、世界を変えてきました。しかし、これらの技術革新は、すべての側面からの妨害によって提示されるとき。人々は常にこの変更は自身が自分のスティック、私はいつも信仰されていた何かを失う聞かせてきましたもちろんのこと、変化に慣れています。あなたがリーダーシップに提出し、カリキュラムの内容を変更したい場合は、大学、教師では、一部の指導者たちはそのそのような前例を理由に却下されます。そのような前例が、それはありませんでしょうではありませんか？だから、技術革新は非常に複雑で困難です。かかわらず、拡張子によってたかった彼らが本当に出たい場合、出てくる難易度、より多くのハードワークです。したがって、私たちは本当に革新の境界に触れることができる、独自の定量的、肯定的な思考を蓄積する不動でなければなりません。
7人、パフォーマンスと倫理
ここで、著者はその上の人々、パフォーマンスと言及しています。しかし、ボーッの内容を見てみると、2つだけを理解すると言うことができます。時間についてまとめていないされています。
概要：この本は執筆の著者のスタイルは非常に面白いです、と著者らは、時間の概念を提案し、あなたが理解するために鮮やかな例を添付しなければなりません。これは私が感謝するものです。70〜80ページを見ての突然の感情のこのすべてを行うのは難しい。この知識クラスの本、。「法の建物」でした。彼は私が実際のソフトウェア・エンジニアリング、様々な処理のためのソフトウェア開発は、一定の理解を持っているだけでなく、もう少し次の学期のコースを楽しみにして、自分自身の成長を楽しみにして何かを理解しました。