みなさん、こんにちは、私は11だった、と今日は、ソフトウェアライフサイクルの説明を詳細に説明しました。彼はソフトウェアの総合的な理解の下で「育った」だから。
ソフトウェアのライフサイクルとは何ですか？
ソフトウェアの作成から廃棄物のプロセス全体にソフトウェアのライフサイクルで、問題が定義された期間内であり、実現可能性の分析、分析を必要とする、システム設計、コーディング、デバッグ、テスト、導入/開発版、メンテナンスフェーズをスクラップしてアップグレードしてください。
ソフトウェアのライフサイクルのすべての段階は、それがあることは何ですか？
私たちは（私の目には、このチャートはまた〜をスクラップしたい）張ショッピングチャートを見て
図は、それが何を問題ではない、私たちのソフトウェアを使用して、その後ショッピングプロセスの完全なカスタム淘宝網のショッピングプロセス図ですか？ソフトウェアのライフサイクルにおける「浅いチャットソフトウェアの開発」対全体のプロセスは、あなたがそれに対応することができ、チャート？
まず、（〜あなたの目を閉じて考えるように）〜自分のことを考えます
まあ、私は答えを明らかにするだろう、我々はあなたが右見てみたいです！
まず、それが心臓と呼ばれ、当分の間、心にカスタマイズニーズの物語のためのヒーローを見つけた後、（実現可能性の分析ニーズ）を行うかどうか、顧客との通信など、スタイル、サイズ、などの選択の受注連絡後、企業は基づいて注文を取得ご注文は、デザイン（プロトタイプ）を必要と内部生産、品質検査員の検査（テスト）が完了した後に正の返信、チェックを受け、通信はハートハートが続いているかどうかを確認するためにマップが、（ニーズの確認）望んでいる生産（開発） （オンライン/脂肪版）ハートに正しい納品後、ハートの服を閉じるように命令を与えた後、賞賛に満足し、試してみて、ショッピングに非常に満足して品質問題（テスト）は、あるかどうかを確認するために開始します、全体のショッピングプロセスは完了です。
あなたはそれが保守サポートを反映していないことを言うかもしれませんか？
その心は、週フェード/パターンのために着用する服を見つけ、それを洗浄品質の問題を取った場合は？など、顧客サービスに関連して発見し、顧客サービス事業との通信の後に処理されます、交換/リターン/修理ではない、これはそれの維持をサポートすることです。
まあ注意：図にショッピング、ソフトウェア設計で、このフローチャートに「デザインスタイルのビジネス要件によれば」ものではありません！
- プロトタイプ設計、顧客に同様のショー静的な完成品を行い、彼らは確認を要求する所属するかどうかを確認するために顧客を可能：デザインスタイルのビジネス要件によると、
-
対応する数字の企業は、いくつかのショッピングを生産、企業はラインで、どのような布のすべての種類の生産の前に決定する必要があり、縫い目;デザインは、あなたがそうで言語、フレームワーク、技術とを使用する必要がある製品を達成するための設計開発である：ソフトウェア設計のフローチャート図材料/方法等とシステムの実施形態、。
実際には、ソフトウェア製品の実際のプロセスと手順全体を通してより適切です。あなたはまだ理解できますか？私は〜あなたの参照のための完全なソフトウェアフロー図を描きました
下面我们依据上图来分别介绍各个阶段。着重介绍每个阶段的概念以及参与者。 需求定义（Ruquest for Proposal）：
描述：定义出本次任务都需要做什么，做成什么样子（比如，买家跟卖家说我要什么样子的衣服，然后双方开始协商，最终达成一致意见，这个过程就是需求定义）。
参与者：产品经理，需求，客户
可行性分析：
描述：由项目组相关成员去研究需求是否可行，能不能做出来（比如：商家拿订单需求去找设计和工厂，问设计图形或者样式能否做出来；问工厂在相应的布料上能不能做出设计图样式的衣服，这个过程就是可行性分析）
参与者：产品经理，项目经理，开发，架构师
需求分析/用户需求（Requirements Analysis）：
描述：需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个框每个按钮的样式，输入输出等各项值（比如：设计和工厂分别就这个衣服做材料分析，分析出这个衣服需要多少布料，扣子什么样式、颜色，不同布料具体用多少等等，这个过程叫做需求分析）；统一整理编写成《需求说明书/需求规格说明书》。
参与者：产品经理，项目经理，测试/质量管理员(很多公司把这个统称为QA)，开发，架构师
评审：（从图中可以看出，各个阶段几乎都需要做评审，在此处统一描述）
描述：评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与
参与者：每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试、开发一起评审；系统设计一般是项目经理、开发评审；测试策略评审一般是测试组内部评审等等
开发线
设计（Design）：
描述：
架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口参数、参数等。此处设计会形成概要设计文档和详细设计文档。
参与者：项目经理，架构师，开发，测试
编码（Coding）：
描述：开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计和编码以及自测，对产品功能进行一一实现
参与者：开发
提测：
描述：开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测下)，于是向测试部门发起提测，一般以邮件方式或者任务管理工具任务流方式向测试部门通知xxx模块/功能可以测试
参与者：任务责任人(开发)、测试
测试线
测试策略：
描述：测试组长要根据《任务说明书》和《需求说明书》来决定此次测试的思路/类别（功能测试/性能测试/文档性测试或者几种组合）、测试方式方法、flag（任务指标，做到什么程度）等。也有很多公司把测试策略作为测试方案中的一部分。
参与者：测试组长/测试leader/自身的测试工程设计师
测试计划（Testing plan）：
描述：测试组长要根据《任务说明书》和《需求说明书》开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
参与者：测试组长/测试leader
测试方案：
描述：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《需求说明书》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。
参与者：测试工程师
测试设计：
描述：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。同样，测试用例也需要评审。
参与者：相关测试工程师
测试执行（Testing）：
描述：
根据测试用例对开发提测部分进行，通过的标记通过，不通过的提交有质量的Bug（问题缺陷）。这里要说下bug，测试对出问题的部分提交bug到相关开发工程师，开发根据问题描述，进行修订，修订完成后会将bug流转给相关测试人员（通过缺陷管理工具分配/邮件通知相关测试人员bug修订完成，可测)，测试需要对bug以及bug相关模块进行测试回归。
参与者：相关测试工程师、责任开发工程师
テストレポート：
説明：最終テストが完了した説明を要約する上記テストでテストレポートであろう（すべてのテストケースは中断/パス）。
参加者：テストエンジニア関連
展開/脂肪のバージョン（配備）：
説明：前のさまざまな段階の後、すでに製品を販売したり、公衆に会う;煙のテスト構成管理担当者は、バージョンが渡された密閉され、テストによって煙試験を実施、製品の生産バージョン（スピーキング）/）プロジェクトのためのアプリケーションのために（オンライン展開。
参加者：構成管理、テスト
サポートメンテナンス（プロダクションサポート）：
説明：サポートメンテナンスは、ほとんどのプロジェクトの定期的なメンテナンスのために、私たちの日常の売却に似ているが製品を販売してきましたが/行にされています。是正メンテナンスなど、メンテナンスの側面を改善します。
参加者：保守要員のためのサポート/セールスエンジニア
以上就是整个软件的流程介绍了，内容有点多，但是我希望你能认真的看完，并且加以理解变成你自己的知识。注：上記のソフトウェア開発プロセスは、基本的なテンプレートであるが、同社は独自の内部組織構造を持ち、プロジェクトに応じて適宜調整することができます。限り権利である、独自のプロジェクトとして、それは良いです。
好了今天的内容到此结束，欢迎进群与我沟通！我们下次再见～