| 運用要件 | https://edu.cnblogs.com/campus/jssf/infor_computation17-31/homework/10584 |
|---|---|
| このコースでの私の目標です | ソフトウェア開発の知識を習得 |
| このジョブは、どのような具体的な目標の面で私を助けました | ソフトウェアエンジニアリングのための方法論 |
| ジョブのテキスト | https://www.cnblogs.com/dragonD/p/12652714.html |
| リファレンス | https://www.cnblogs.com/katniss-smile/p/5982643.html https://www.baidu.com/ |
滝
ウォーターフォールモデルの核となるアイデアは、分業を容易にするために、デザインの特徴とは別に実施される、工程を簡略化する問題に基づいて、すなわち、構造解析および設計を使用して、物理論理は別々に実装実装されています。ソフトウェアのライフサイクルのウォーターフォールモデルは滝のように、彼らのトップダウン、固定オーダーの相互の収束を綴りの6段階のソフトウェア設計、ソフトウェアの実装、ソフトウェアテスト、ソフトウェアの運用・保守、ソフトウェアの計画、要件分析と定義に分かれています水が徐々に落ちます。
大規模なソフトウェア開発スタッフの組織と管理に資するモデル滝、それは研究や大規模ソフトウェア開発プロジェクトの品質と効率を改善するためのソフトウェア開発手法やツールの使用を助長しています。
ウォーターフォールモデルの利点
分割段階でのチェックポイントを提供するために、プロジェクトの1）。
2）前の段階の完了後、あなただけの後続のフェーズに焦点を当てる必要があります。
3）反復モデルでウォーターフォールモデルに適用することができます。インクリメンタル反復ウォーターフォールモデルを適用しました。1反復が最大の問題を解決します。各繰り返しは、より多くの機能を追加しながら実行することができますバージョンを生成します。各繰り返しは、品質と統合テストでなければなりません。
4）それは、分析、設計、コーディング、テストを行い、テンプレートを提供し、この方法をサポートし、このテンプレートに共通の指針を持つことができます。
泥のビッグボール
泥のいわゆるビッグボールは、コードのランダムな山の混沌と複雑な、汚い耐え難い、コラージュを指します。長年にわたり、この泥ボールに対処するために、一緒に案内するための様々な方法を見えたが、実際の状況はあまり変化はありませんが、「泥のビッグボールは」まだ設計ソフトウェアアーキテクチャへの最も一般的な方法のようです。アーキテクチャの変更に対処するためには遅すぎる、遅すぎる高まる需要変動への対応を断片化設計前の不足、：私たちは今、直接含め、泥ボールの開発につながる多くの方法の俊敏性で慣用されています。
私はこのような状況で、精度を高め、コードの可読性を向上させるためには、コード、レビューコードを強化するために、このような厳しい経営陣として、コードの管理を強化すべきだと思います。
教会
大聖堂モード（大聖堂モデル）：パブリックリリース後のソフトウェアのソースコードが、ソフトウェア開発プロセスの各バージョンでは、専用のチームのコントロールで。著者GNU EmacsとGCCの両方のソフトウェアの例として。
市場
バザー（バザーモデル）：すなわち、ソースコードは、開発プロセス、開発及び視聴のために利用可能で、インターネット上で開示されています。Linus Torvalds氏は、Linuxカーネルの開発が率いるLinuxカーネルの創設者の著者は、例えば、また、fetchmailのための一例として挙げています。
シルバーバレット
ウルフ：モンスターの中で最も恐ろしい種類の西洋の伝説は、多くの場合、準備するのが最も困難なので、ソフトウェアの開発中に発生した厄介な問題の多様性を記述するために使用され、それ以外のモンスターをプログラミング見慣れた顔を凝集します。
シルバーバレット：ロングは、シュートの人々の特効薬にソフトウェア開発プロセスのアナロジーの問題を解決する効果的な方法を使用していました。
彼の最も有名でブルックス「特効薬-ソフトウェアエンジニアリングおよび偶発の性質は、」記事は、ソフトウェア開発プロセスは、最終的な破壊兵器には万能薬（すなわち銀の弾丸）、種々の方法の唯一の統合に使用されていないことを指摘しましたこれは、ソリューションです。どのようにどのように魔法の理論や方法の様々な主張は、「ソフトウェアの危機」この村長オオカミの特効薬を殺すことができません。
そして、私はまた、「特効薬」を表示しない傾向があり、ソフトウェア自体の内部設計が複雑ある程度のを持って、私はこれは時々 、やむを得ない必要があると思います。実際のプロセスの複雑さのすべての側面を考慮するために必要な洗練されたソフトウェアは、解決するためだけの技術に頼ることはできません。
アジリティ
アジャイルマニフェストは、12件の原則に従います。
- 私たちの最も重要な目標は、すぐにその顧客満足そうできるだけ貴重なソフトウェアの連続的送達を介して行われます。
- 我々はあまりにも、開発後期では、需要の顔の変化に満足しています。顧客の競争上の優位性、アジャイルプロセス制御の変更のため。
- ソフトウェアは、多くの場合、作業を届ける、数週間または1,2ヶ月で区切られた、彼らは短い期間を取る傾向にあります。
- ビジネスの人々と開発者がお互いに毎日のプロジェクトに協力しなければならない例外ではありません。
- 自社のコアプロジェクトを構築するために、個々の士気を刺激します。環境とは、目標を達成するように、信頼と組み合わせる必要なサポートを提供します。
- かかわらず、内側と外側のチームの、最良の情報伝達が最も効率的な方法は、顔の会話に顔です。
- ソフトウェアの作業は進行中の主要な尺度です。
- アジャイルプロセスは持続可能な開発を推進します。スポンサーは、一緒に開発者やユーザーは、その安定したペースで続けて維持することができるようにします。
- 卓越した技術と優れたデザインの追求の忍耐力は、それによって、敏捷性を向上させることができます。
- 芸術の不必要な負担を軽減しようとしている、単純な信仰、と。
- 最高のアーキテクチャ、要件、およびデザインは、自己組織化チームから出てきます。
- チームは、定期的に有効性を改善し、パフォーマンスので、彼らの行動を調整する方法に反映されます。
アジャイル点
1、概念およびアーキテクチャ設計に焦点を当て、詳細設計ライト
2、SWOT分析（参照：使用https://www.cnblogs.com/katniss-smile/p/5982643.html）
3、及び需要主導型市場むしろ、技術主導型よりも
4、常に互換バージョン考える
5、光の文書ではなく文書なしに