瀑布模型/改进的瀑布模型 虽然瀑布模型仍然存在很多的问题有待解决，但瀑布模型仍然是最展本的和最效的?种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求-〉分析-〉设计?〉编码-> 测试的阶段进行，每-个阶段都可以定义明确的产出物和验证准则.瀑布模型在每?个阶段完成后都可以组织相关的评审和验证，只有在评审通过后才能够进入到下-个阶段. 由于需要对每?个阶段进行验证，瀑布模型要求每?个阶段都有明确的文档产出，对于严格的瀑布模型每?个阶段都不应该重叠,而应该是在评审通过，相关的产出物都己经基线后才能够进入到下?个阶段. 瀑布模型的优点仍然是可以保证整个软件产品较高的质量，保证缺陷能够捉前的被发现和解决. 采用瀑布模型可以保证系统在整体上的充分把握，使系统具备良好的扩展性和可维护性?但对于前期需求不明确,而又很难短时间明确淸楚的项目则很难很好的利用瀑布模型.另外对于中小型的项目，需求设计和开发人员往往在项目开始后就会全部投入到项目中，而不是分阶段投入，因此采用瀑布模型会导致项目人力资源过多的闲置的情况,这也是必须要考虑的问题. 很多人往往会以进度约束而不选择瀑布模型，这往往是?个错误的观点.导致这种情况的?个关键因素往往是概念需求阶段人力不足.冈此在概念需求阶段人力能够得到充分保证的情况下，瀑布模型和迭代模型在开发周期上并不会存在太人的差别.反而是很多项目对于迭代或嫩捷模型用不好，为了赶进度在前期需求不明确，没有经过?个总体的架构设计情况下就开始编码，后期出现大量的返工而严重影响进度. 架构设计是软件开发中?个重要的关注点.因此在RUP中也捉及到软件开发要以架构为核心.因此在架构设计完成后系统会彼分为相关的f?系统和功能模块.每个功能模块间的接口都可以定义淸楚.在这种情况下，当模块B的详细设计做完成后往往就没有必妥等到其它模块的详细设计都妥完全作完才开始编码，冈此在架构设计完成后可以将系统分为多个模块并行开发，每个模块仍然遵循先设计和编码测试的瀑布模型思路.这是瀑布模型的?种最重要的改进思路，也可以说这是?种增量开发的模型.
软件生存周期各个阶段的文档 项目开发计划的编写内容 一、引言 1. 编写目的 2. 背景 3. 定义 4. 参考资料 二、项目概述 1. 工作内容 2. 主要参加人员 3. 产品及成果 （1）程序 （2）文件 （3）服务 （4）非移交产品 4. 验收标准 5. 完成项目的最迟期限 6. 本计划的审查者与批准者 三、实施总计划 1. 工作任务的分解 2. 接口人员 3. 进度 4. 预算 5. 关键问题 四、支持条件 1. 计算机系统支持 2. 需要用户承担的工作 3. 需由外单位提供的条件 五、专题计划要点
可行性研究报告 一、引言 1. 编写目的 2. 背景 3. 定义 4. 参考资料 二、可行性研究的前提 1. 要求 2. 目标 3. 条件、假定和限制 4. 进行可行性研究的方法 5. 评价尺度 三、对现有系统的分析 1. 数据流程和处理流程 2. 工作负荷 3. 费用开支 4. 人员 5. 设备 6. 局限性 四、所建议的系统 1. 对所建议系统的说明 2. 数据流程和处理流程 3. 改进之处 4. 影响 （1）对设备的影响 （2）对软件的影响 （3）对用户单位机构的影响 （4）对系统运行的影响 （5）对开发的影响 （6）对地点和设施的影响 （7）对经费开支的影响 5. 局限性 6. 技术条件方面的可行性 五、可选择的其他系统方案 1. 可选择的系统方案1 2. 可选择的系统方案2 ...... 六、投资及收益分析 1. 支出 （1）基本建设投资 （2）其他一次性支出 （3）非一次性支出 2. 收益 （1）一次性收益 （2）非一次性收益 （3）不可定量的收益 3. 收益/投资比 4. 投资回收周期 5. 敏感性分析 七、社会条件方面的可行性 1. 法律方面的可行性
软件生命周期案例分析[编辑] 案例一:利用软件生命周期创建B2C电子商务网站[1] 一、软件生命周期 任何事物都有产生、发展、成熟、消亡或更新几个阶段，电子商务网站也不例外。 [2]任何一个电子商务系统在使用过程中随着其生存环境的变化，都需要不断维护、修改，当它不再适应的时候就要被淘汰，就要由新系统代替旧系统，这种周期循环称为生命周期。 根据软件生命周期的原理，电子商务网站可以划分为系统规划、系统分析、系统设计、系统实施、系统测试、系统运行和维护等几个阶段。 二、B2C电子商务网站建设的一般过程 (一)系统规划阶段 系统规划阶段的任务是对企业的环境、目标、现行系统的状况等进行初步调
查，根据企业目标和发展战略，确定信息系统的发展战略，研究新系统的必要性和可能性。在这个阶段给出备选方案，并进行可行性分析，写出可行性分析报告。待可行性分析报告审议通过后，编制系统设计任务书。 1、需求分析 为了进行可行性研究分析，首先对电子商务系统的需求进行分析。通过对企业的需求进行调查，明确电子商务网站需要做什么，做到什么程度。在此，通过查阅资料、实地观察、业务专题报告等方法将该电子商务网站的需求归纳为功能需求和性能需求。 功能需求：B2C电子商务网站就是Business To Consumer，也就是企业借助于Internet建立网点进行交易的一个系统。流程上，店家发布产品信息，消费者在线选购、在线支付，通过物流最后达成交易。所以从购买方看，需满足消费者在线选购、在线支付等；从销售方看，要能让店家整理网上商品、管理订单等。
性能需求：系统运行要稳定，在不同的系统中能正常运行，具有较强的适应性，可移植性。系统要有可扩展性，当出现新的需求时，能将其纳入系统，而不必改变原有的基本结构。 2、可行性分析 在电子商务网站需求已确定的情况下，对系统的进行判定，决定有无必要、有误可能完成系统的建设。在此，包括如下几个方面：运行可行性分析：考查方案在企业中合适程度，避免一个可以工作的方案由于最终用户和管理层的抵制而落选。 经济可行性分析：建立电子商务网站需要经费支出，所以在建站前要评估该开发项目的收益，分析带来的经济效益是否超过所需要的成本。 技术可行性分析：ASP电子商务网站是动态网站技术的产物，以目前计算机硬件、软件、网络，已经具备建立B2C电子商务网站的条件。
. 软件工程中的图 软件工程导论中一般把软件的开发分为八个阶段：１.问题定义２ .可行性研究 需求分析３.总体设计（概要设计）４.５.详细设计编码和单元测试６.综合测试７. .软件维护８ 下面我们就说说各个阶段中与图的难解难分。. 问题定义１ 问题定义阶段主要是根据用户的需求来定义用户需要解决的问题，用户要实现哪些功 能。可行性研究２. 利益最大化的情况下尽可能短的时间内，可行性研究阶段就是看是否有一种使其在最小的代价， 解决问题的方案。这个阶段的分析主要涉及以下几个图形工具。系统流程图 2.1 系统流程图是描述系统物理模型的一种传统工具。它是表达数据在系统各部件之间流动的情况， 系统流程图形象的呈现了而不是对数据加工处理的控制过程，它是物理数据流图而不是程序流程图。. . 软件的功能，即使不懂软件的人也可以轻松的看懂，可以说它是软件设计师与用户之间沟通、交流的有效工具。
2.2 数据流图 数据流图是从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。如果说系统流程图能让用户更好的明白系统的功能，那么数据流图则让用户更加明白系统的工作原理。 数据流图的基本符号： . .
数据流图的使用例子： 2.3 数据字典 数据字典就是数据的信息的集合，也可以说就是对上面提到的数据流图中的所有元素的定义的集合。数
据字典的主要作用就是在软件的分析与设计阶段方便我们查阅不甚了解的数据的描述信息。 . . . ３需求分析 需求分析阶段主要确定系统必须做什么。比如用户对系统的要求，确定目标系统所有的功能，确 定系统运行的硬件和软件环境，系统性能要求，出错处理要求，接口需求，验证软件需求等等。图3.1 E-R 图的主要作用就是把用户的数据要求用可视化的图形呈现出来。E-r
考试国标知识点（二）：GB/T 8566-2007 信息技术软件生存周期过程 本标准为软件生存周期过程建立了一个公共框架，以供软件产业界使用，它包括在含有软件的系统、独立软件产品和软件服务的获取期间以及在软件产品的供应、运行和维护期间需应用的过程、活动和任务。软件包括软固件的软件部分。 本标准了描述了软件生存周期过程的体系结构，但并未规定如何实施或执行各过程中包含的活动和任务的细节。 本标准并不打算规定要产生的文档的名称、格式或编写内容。 本标准并不规定一个特定的生存周期模型或软件开发方法。 术语： 协定：确定将要建立的工作关系的期限和条件。 审核：由授权人员对软件产品和过程进行的独立评估，以便评估与需求的依从性。 评价：系统地确定一个实体项目满足其规定准则的程度 固件：硬件装置和作为只读软件驻留在硬件装置中的计算机指令或计算机数据的组合，该软件不能在程序控制下方便地修改。 合格性认定：证实一个实体是否能够完成规定需求的过程 合格性需求：为了证明一个软件产品依从其规格说明且可以在其目标环境中使用，该软件产品必须满足的一组准则或条件。 合格性测试：由开发方进行并由需方见证的测试，以证明软件产品符
合其规格说明，并可以在其目标环境中使用。 确认：通过检查和提供客观证据来证实针对某一特定预期用途的需求已经得到满足 验证：通过检查和提供客观证据来证实规定需求已经得到满足。 验证：验证检查某样东西是否符合之前已定好的标准，如：文档评审，要检查的东西是文档，检查标准就是文档的评审标准，又如：测试软件，要检查的东西就是软件，检查的标准就是软件的规格说明，包括功能说明，性能要求等。 确认：检查软件在最终的运行环境上是否达到预期的目标。一般来说，就是调试、验收测试等，这些工作都是在真正的软件需要运行的环境上进行的，在最终环境上运行软件，确保软件符合使用要求。 其实确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。而验证更多的是从开发方的角度来做评审、测试来验证产品的需求、架构设计等方面是否和用户要求的一致 验证是代表你是否正确的做事情，而确认代表你是否做了正确的事情本标准把软件生存周期中可能执行的活动分为5个基本过程、9个支持过程和7个组织过程，每一生存周期过程划分为一组活动，每一活动进一步划分为任务 5个基本过程： 1、获取过程：为需方而定义的活动，启动，招标，合同，对供方监督，验收等 2、供应过程：为供方而定义的活动，启动，准备投标，签订合同，
数据库设计的基本步骤： 1.需求分析阶段： 准确了解与分析用户需求（包括数据与处理），是整个设计过程的基础，是最困难、最耗费时间的一步。这个不用多说吧？ 2.概念结构设计阶段： 是整个数据库设计的关键,通过对用户的需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。从实际到理论。 3.逻辑结构设计阶段： 将概念结构转换为某个DBMS所支持的数据模型,对其进行优化。优化理论。 4.数据库物理设计阶段： 为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。选择理论落脚点。 5.数据库实施阶段： 运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果,建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。理论应用于实践。 6.数据库运行和维护阶段： 数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。理论指导实践，反过来实践修正理论。
释：软件生存周期各个阶段活动定义_普通__行业透视_eNet硅谷动力商用软件 频道 首先讲一下软件生存周期的定义，即以需求为触发点，提出软件开发计划的那一刻开始直到软件在实际应用中完全报废为止可以认为是一个完整的软件生存周期，软件生存周期的提出是为了更好的管理、维护和升级软件。其中更大的意义在于管理软件开发的步骤和方法。它把整个的软件生存时间看作是一个整体，以时间的推移和软件开发的工作重心之间作为划分点，把软件开发和维护的工作细分为若干个相对独立的部份，从而更好的控制软件的开发进度和难度，同时也十分有利于降低软件的出错频律，协调各个部门间的工作配合和责任分配。 软件生存周期的各个阶段的划分并没有一成不变的法则，不同的开发方式、软件种类、软件规模和开发环境都会在不同程度上影响软件生存周期各阶段的划分，但无论最终把生存周期如果根据自己的实际情况进行划分，都是旨在更好的利用手中的资源（主要指人力资源、软件资源、技术资源和源码资源），降低软件的开发风险、复杂度和开发成本（主要以开发的时间和投入资源为衡量标准），要做到最好的对软件生存周期各阶段进行划分，就必须遵循一条基本的原则，那就是在各阶段的任务应尽可能的相对独立，同一阶段各项任务的性质应尽可能的相同，从而达到降低每个阶段任务的复杂度，减少不同阶段任务之间的联系。这样做对软件项目开发的组织管理是十分有必要的，同时对最终的软件项目开发成功是不可或缺的。 尽管软件的生存周期各阶段的划分没有一个明确的法则，但就一般性而言，软件生存周期包括可行性分析、项目开发计划、需求分析、概要设计、详细设计、编写代码、软件测试和软件维护等活动（有的文档资料和开发项目把概要设计和详细设计合在一起，统称为软件设计或设计），这些活动的每一个可以说是软件开发过程中必须要经历的，所以我们应该将它们按照项目的划分合理的安排到各个阶段里面去。 既然软件开发周期这么重要，无论对软件项目最终开发是否能取得成功或是对软件管理和资源投入，我们就应当充份的了解周期里各个活动的定义和任务，才能合理，准确，客观的安排每一阶段的工作，以下就对各种活动的定义和任务做一下
从软件生命周期说项目经理工作职责与流程 一、需求分析 需求分析是对用户的业务活动进行分析，确定系统的目的、范围、定义和功能，明确在用户的业务环境中软件系统应该"做什么"。只有在确定了客户需求后，知道要“做什么”，才能够分析和寻求系统的解决方法，开展后续的工作，所以需求分析是软件工程中的一个关键过程。 这一步骤要产生用户需求说明书，这个说明书既是给用户看的也是给开发人员看的，可以让用户更加确定自己的需求，让开发人员了解用户的需求。可以在需求说明说中包含业务流程图，来描述项目的业务流程。 二、软件设计 软件设计的主要任务是把需求分析得到的结果转换为软件结构和数据结构，建立目标系统的逻辑模型，从而形成系统架构。明确软件系统应该"怎样做" 概要设计 1. 软件结构设计：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。 2. 数据结构设计：数据特征的描述、确定数据的结构特性、以及数据库的设计。 详细设计 1．为每个模块确定采用的算法，选择某种适当的工具表达算法的过程，写出模块的详细过程性描述； 2．确定每一模块使用的数据结构； 3．确定模块接口的细节，包括对系统外部的接口和用户界面，对系统内部其它模块的接口，以及模块输入数据、输出数据及局部数据的全部细节。
4．要为每一个模块设计出一组测试用例，以便在编码阶段对模块代码（即程序）进行预定的测试。 这一步骤需要产生系统概要设计说明书和系统详细设计说明书。 三、软件编码 软件编码就是将上一阶段的详细设计得到的处理过程的描述转换为基于某种计算机语言的程序，即源程序代码。 1．制定项目开发计划文档，制订编码规范、量化任务，并合理分配给相应的人员。2．跟踪项目的进度，协调项目组成员之间的合作。 3．监督产生项目进展各阶段的文档，保证文档的完整和规范。 4．跟踪开发过程中的需求变更，与用户沟通确定变更需求，更改开发计划。 四、软件测试 软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，需要跟踪故障，以确保开发的产品适合需求。 项目经理需了解测试结果，根据测试的bug的严重程度来安排项目bug更改计划。 五、运行维护 软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改，修改时应充分利用源程序。修改后要填写程序改登记表，并在程序变更通知书上写明新旧程序的不同之处。 项目经理需要配合部署人员做项目部署，了解项目部署环境，跟踪项目运行期间产生的bug安排相关人员对相应bug进行更改
软件缺陷生命周期流程规范 软件测试部 吴XX 2015年12月05日
1. 目的 对软件功能评测过程中发现的问题进行记录、跟踪，从缺陷的产生开始，经过修正、验证等等一系列操作后，最终关闭，包含了软件缺陷的整个生命周期。同时，通过汇总缺陷和分析缺陷曲线，判断产品缺陷是处于发散期、平稳期乃至收敛期，由此作为评估产品稳定性的依据。 2. 范围 自主研发项目，合作研发项目和OEM项目及上市阶段样机的软件功能评测问题类。3. 定义 3.1 缺陷跟踪库：用于存储测试过程中的缺陷，并对整个缺陷生命周期进行跟踪的数据库，结合当前流行的测试工具，目前采用Mantis来处理和跟踪缺陷。 3.2 研发中心：负责提交测试申请，接收测试中心提交的问题点，并修正。 3.3测试部：负责接收测试申请，执行测试，并对测试问题进行汇总和校验，提交测试报告。 3.4测试经理/组长：对接收的测试任务进行合理的资源分配，并执行测试，过滤测试工程师提交的缺陷，并提交缺陷进行分流和执行关闭动作。 3.5测试工程师：执行测试并提交测试缺陷，同时对已经修改的缺陷在新版中进行验证。 4. 流程 4.1 缺陷处理流程图
4.2 流程解释 按照箭头的走向，所有能走通的路径都是有效路径。以下过程是按照主线来走的。详细请见状态转换说明 4.2.1测试部接收测试申请，并根据测试计划执行测试； 4.2.2测试工程师对测试过程中发现的问题进行初步筛选、判断，新建缺陷，并提交相应软件人员； 4.2.3测试经理/组长收到新提交的测试缺陷后，进行再次筛选和过滤，将状态改为“已审核”； 4.2.4软件接口人收到转移过来的缺陷后，进行过滤确认问题，并转给具体的工程师修改； 4.2.5软件工程师收到问题后，进行分析，发现了根本原因后则将状态设为“已确认”；4.2.6问题已经解决后则将状态设为“待验证”，并转移给问题提交人进行确认； 4.2.7问题暂时无法解决、优先级降低，将状态设置为“延期”，软件责任人不变； 4.2.8问题提交人确认问题已解决后将问题“已关闭”。如果问题本身路径已经修改完成但相关路径出现问题，则仍然将此问题“关闭”，同时提交新问题，并备注说明这是该问题的衍生问题； 4.2.9问题提交人确认未修改，则将问题“重新打开”给软件人员/软件接口人； 4.2.10测试经理对验证通过的问题进行再次筛选和过滤，然后将问题关闭； 4.2.11对于描述有问题的bug，相关人员将问题打回给问题创建人员，并简要说明理由；4.2.12对于不是问题、设计如此、重复提交的情况，相关人员将问题状态设为“打回”并转给问题提交人/测试经理，并简要说明理由； 4.2.13问题提交人/测试经理发现测试工程师提交的问题不是问题，则直接关闭问题； 4.2.14测试人员验证概率性问题，暂无法复现的，将状态改成“跟踪”，跟踪三个软件版本仍未复现，则将此bug关闭，如复现bug，则“重新打开”此bug。 附录： 5. BUG缺陷库解释 5.1 用户组成员及其权限
1.软件生命周期的最后的一个阶段是( ) A.书写软件文档 B.软件维护 C.稳定性测试 D.书写详细用户说明 2.软件维护工作的最主要部分是( ) A.校正性维护 B.适应性维护 C.完善性维护 D.预防性维护 3.在软件维护工作中进行的最少的部分是( ) A.校正性维护 B.适应性维护 C.完善性维护 D.预防性维护 4.软件维护工作中大部分的工作是由于( )而引起的。 A.程序的可靠性 B.适应新的硬件环境 C.适应新的软件环境 D.用户的需求改变 5.软件维护时，对测试阶段未发现的错误进行测试、诊断、定位、纠错，直至修改的回归测试过程称为( ) A.改正性维护 B.适应性维护 C.完善性维护 D.预防性维护 6.软件的可维护性变量可分解为对多种因素的度量，下述各种因素( )是可维护度量的内容。(1)可测试性(2)可理解性(3)可修改性(4)可复用性 A.全部 B.(1) C.(1)、(2)和(3) D.(1)、(2) 7.软件维护是保证软件正常，有效运行的重要手段，而软件的下述特性：(1)可测试性(2)可理解性(3)可修改性(4)可移植性哪个(些)有利于软件维护？( ) A.只有(1) B.(2)和(3) C.(1)、(2)和(3) D.都有利 8.在软件生命周期中，( )阶段所占工作量最大，约占70%。 A.分析 B.维护 C.编码 D.测试 9.软件维护大体上可分为四种类型，下列哪一个不属于其中？( ) A.校正性 B.可靠性 C.适应性 D.完善性 10.软件维护指的是( ) A.对软件的改进、适应和完善 B.维护正常运行 C.配置新软件 D.软件开发的一个阶段 11.软件的可维护性度量可分解为对多种因素的度量，下述各种因素中，哪些是可维护性度量的内容？( )
软件生命周期(SDLC，Systems Development Life Cycle,SDLC)是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。 七个阶段 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生存周期（软件生命周期）。 软件生命周期 把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。通常，软件生存周期包括可行性分析、项目启动、需求分析、设计（概要设计和详细设计）、编码、测试、维护等活动，可以将这些活动以适当的方式分配到不同的阶段去完成。 可行性分析
此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。 主要交付物有《项目规划书》、《立项报告》、《可行性研究报告》。项目启动 项目启动会、人员到位，初步分工、搭建开发环境、准备项目管理工具。 项目管理工具：可采用Project和JIRA结合管理。 Microsoft Project (或MSP)是一个国际上享有盛誉的通用的项目管理工具软件，凝集了许多成熟的项目管理现代理论和方法，可以帮助项目管理者实现时间、资源、成本的计划、控制。 JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。
软件生命周期 软件的生命周期是一个孕育、诞生、成长、成熟和衰亡的生存过程，也就是所谓的软件定义、软件开发和运行维护3个时期组成。而每个时期又有所要完成的不同的基本任务。 软件定义时期的主要任务是解决“做什么”的问题，通俗的讲就是做此项目的主要功能及可行性报告等。比如说网上选课系统，在软件定义阶段，要确定以下几个功能模块：管理员管理课程、教师、学生的增删改查和对教师、学生的权限授予等功能，教师对自己信息的修改和对自己课程的上传、修改、删除、查询等功能，学生对课程的选择、退选及查询等功能。针对此项目，从技术、经济、法律、成本、可获得的效益、开发的进度做出一系列的估算，制定出具体的实施计划。 软件开发时期的主要任务是解决“如何做”的问题，也就是如何完成此项目的过程，要解决每个构建所要完成的工作以及完成此工作的顺序。选择编写源程序的开发工具，把软件设计转换成计算机可以接受的程序代码。比如说网上选课系统，在软件开发阶段，我们确定先要进行管理员的模块编写，再进行教师模块的编写，进而进行学生模块的编写，另外也要确定是运用某种软件开发工具，如java、C语言等进行模块的开发等。 运行维护时期的主要任务是使软件持久地满足用户的需要，通常包括：改正性维护、适应性维护、完善性维护和预防性维护。在此阶段主要是把前期的各个模块组装起来进行测试，保证按需求分析的要求完成软件功能的测试并对此进行确认，交与开发方运行测试。比如网上选课系统，在运行维护阶段，要对前期的管理员、教师、学生这三个模块进行组合，并按照需求分析的功能进行核对，有不符合需求规格说明书之处进行修改，直到完全符合并测试成功，交与开发方测试及运用。 软件的生命周期是一个耗时长的工程。在软件工程生命周期的3个时期中，各个阶段又有着其不同的基本任务： 一、问题定义和可行性研究 此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。在这个阶段中我们需要从开发的技术、成本、效益等各个方面
文档编号：日期： 软件生命周期指南
1前言 软件生命周期是指软件产品或软件系统从产生、投入使用到被淘汰的全过程。在计算机技术发展的初期，人们把软件开发简单地理解为编写程序。随着软件复杂性的增长，人们认识到软件开发活动应划分为需求分析、设计、实现、测试等若干个活动，并将这些活动以适当的方式分配到不同的阶段中去完成。 软件生命周期模型是描述软件开发全部过程、活动和任务的结构框架。比较常见的软件生命周期模型是瀑布模型、增量模型、原型模型和螺旋模型等。 1.1目的和适用范围 本文档规定了<组织>适用的软件生命周期模型，作为项目经理在制定项目计划时根据项目需求、复杂程度、进度要求等项目特点确定采用何种开发过程的依据。如果确定的生命周期模型不在本文档中规定的范围内，必须经过SEPG和高层经理的审批才能使用。 本文档适用于<组织>的所有软件项目。 1.2缩略语 SPP 软件项目计划 SPTO 软件项目跟踪和监控 SQA 软件质量保证 SCM 软件配置管理 SOW 工作说明书 WBS 工作分解结构 SRS 软件需求规格说明书 1.3参考文献 《CMM 1.1》。 2瀑布模型 瀑布模型是最常用的软件开发模型，它的各个阶段是按线性序列组织的。开发过程中的阶段划分为项目策划、需求分析、概要设计、详细设计、编码和单元测试、软件集成和集成测试、系统测试、验收和安装等（图1）。尽管开发过程中定义了各个阶段的顺序，但这些阶段有时是相互交迭进行的，阶段间的依赖性由入口准则来确定。
图1 瀑布模型 瀑布模型的每个阶段均具有以下特征： ●从上一阶段接受本阶段工作的对象，作为输入； ●对上述输入实施本阶段的活动； ●给出本阶段的工作成果，作为输出传入下一阶段； ●对本阶段工作进行评审，如果本阶段工作得到确认，那么继续下阶段工作，否则返 回前一阶段，甚至更前阶段。 瀑布模型为软件开发与维护提供了一种有效的管理模式，根据这一管理模式制订开发计划、进行成本预算、组织开发人员，以阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品的质量。 ●优点：近30年来之所以广为流行，是因为它在支持开发结构化软件、控制软件的 开发复杂度、促进软件开发工程化方面起着显著作用。 ●缺点：缺乏灵活性，无法通过开发活动澄清本来不够确切的软件需求。这些问题可 能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成后才 有所察觉。 2.1项目策划 项目策划是每个项目的初始阶段，目的是为开发过程和过程管理做好必要的准备。项目策划的主要工作是进行可行性分析和研究，进行估计和制定管理项目的计划。
软件生存周期详解 1.问题定义 2.可行性研究 3.需求分析 4.总体设计 5.详细设计 6.编码 7.测试 8.运行维护 问题定义：问题定义阶段必须回答的关键问题是“要解决的问题是什么？”因此，分析员通过对系统的实际用户和使用部门负责人的访问调查，扼要地写出他们对问题的理解，并在用户和使用部门负责人的会议上认证讨论这份书面报告，澄清含糊不清的地方，改正理解不正确的地方，最后得到一份双方都满意的文档，此文档中系统分析员应该写明问题的性质、工程目标和规模。 可行性研究：研究问题的范围，探索这个问题是否值得去解决，是否有可行的解决方法。在这个阶段，系统分析员应该导出系统的高层逻辑模型，并且在此基础上更准确，更具体的确定工程规模和目标。然后分析员更准确的估计系统的成本和效益，对建议的系统进行仔细的成本/效益分析，这是这个阶段的主要任务之一。可行性研究的结果是使用部门负责人做出是否继续进行这项工程的重要依据。 需求分析：确定目标系统必须具备那些功能。系统分析员在需求分析
阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统模型。通常用数据流图，数据字典和简要的算法描述表示系统的逻辑模型。 总体设计：首先考虑以下解决方案：低成本的解决方案。系统只能完成最必要的工作，不能做一点额外的工作；中等成本的解决方案，这样的系统不仅能够很好的完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点；高成本的“十全十美”的系统。这样的系统具有用户可能希望有的所有功能和特点。系统分析员应该使用系统流程图或其他工具描述每种可能分系统，估计每种可能的方案的系统，估计每种方案的成本和效益，这应该在充分权衡各种方案利弊的基础上，推荐一个较好的系统，并且制定实现所推荐的系统的详细计划。要完成上述任务，通常采用结构设计的一条基本原理就是程序应该模块化，因此，总体设计还应设计软件的结构，通常用软件结构图表示。 详细设计：详细设计阶段的任务就是把解法具体化，设计出程序的详细规格说明，包括必要的细节，程序员可以根据他们写出实际的程序代码。通常用程序流程图，N-S图，PAD图，HIPO图或PDL语音描述详细设计的结果。 编码和单元测试：程序员根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用汇编语言），把详细设计的结果翻译成选定的语言书写的程序，并且仔细测试编写的每一个模块。程序员在书写模块时，应使它的可读性，可理解性和可维护性良好。
软件工程中的图 软件工程导论中一般把软件的开发分为八个阶段： １.问题定义 ２.可行性研究 ３.需求分析 ４.总体设计（概要设计） ５.详细设计 ６.编码和单元测试 ７.综合测试 ８.软件维护 下面我们就说说各个阶段中与图的难解难分。 １. 问题定义 问题定义阶段主要是根据用户的需求来定义用户需要解决的问题，用户要实现哪些功 能。 ２. 可行性研究 可行性研究阶段就是看是否有一种使其在最小的代价，尽可能短的时间内，利益最大化的情况下解决问题的方案。这个阶段的分析主要涉及以下几个图形工具。 2.1 系统流程图 系统流程图是描述系统物理模型的一种传统工具。它是表达数据在系统各部件之间流动的情况，而不是对数据加工处理的控制过程，它是物理数据流图而不是程序流程图。系统流程图形象的呈现了软件的功能，即使不懂软件的人也可以轻松的看懂，可以说它是软件设计师与用户之间沟通、交流的有效工具。
2.2 数据流图 数据流图是从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。如果说系统流程图能让用户更好的明白系统的功能，那么数据流图则让用户更加明白系统的工作原理。 数据流图的基本符号： 数据流图的使用例子：
2.3 数据字典 数据字典就是数据的信息的集合，也可以说就是对上面提到的数据流图中的所有元素的定义的集合。数据字典的主要作用就是在软件的分析与设计阶段方便我们查阅不甚了解的数据的描述信息。 ３. 需求分析 需求分析阶段主要确定系统必须做什么。比如用户对系统的要求，确定目标系统所有的功能，确定系统运行的硬件和软件环境，系统性能要求，出错处理要求，接口需求，验证软件需求等等。 3.1 E-R图 E-r图的主要作用就是把用户的数据要求用可视化的图形呈现出来。
今天和大家分享的是软件开发生命周期，主要介绍软件的生命周期和软件的设计模型。 国标（GB8566-88）中将软件生命周期分为8个阶段：可行性研究与计划、需求分析、概要设计、详细设计、实现（包括单元测试）、组装测试（集成测试）、确认测试、使用和维护。 这里出现了一个面试经常出现的问题，就是测试阶段的问题，测试阶段：单元测试、集成测试、系统测试、验收测试。 软件设计模型：瀑布模型、快速原型开发、增量与递归模型、螺旋模型。 1）瀑布模型：1970年由W.Royce提出，其开发过程依照固定顺序进行，各阶段的任务与工作结果。该模型严格规定了各阶段的任务，上一阶段的输出作为下一阶段的输入。此模型适用于用户需求明确、开发技术比较成熟、工程管理严格的场合使用。缺点是由于任务顺序固定，软件研制周期长，前一阶段工作中造成的差错越到后期越大，纠正的代价也就越高。
2）快速原型就是先用相对少的成本，较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用，以便及早澄清并检验一些主要设计策略，在此基础上再开发实际的软件系统。 快速原型模型主要有三种类型：探索型原型、实验型原型和演化型原型。探索型主要用于开发需求的阶段，目的是弄清用户的原型。实验型原型主要用于设计阶段，目的是考核实现方案是否合适，能否实现。演化型模型主要用于及早的向用户提交一个原型，得到用户认可后不断的修改演化成最终的软件系统。 快速原型的开发步骤：先快速分析需求，然后构造原型，之后是运行原型和评价原型，最后就是修改原型。 3）迭代模型：所有的阶段都能够细分为迭代，每一次的迭代都会产生一个能够发布的产品，这个产品是最终产品的一个子集。 4）螺旋模型：特别适合于大型复杂的系统。
《信息技术软件生存周期过程》——ISO/IEC 12207与GB/T 8566
摘要对于保证软件质量，提高软件工程能力,关键是科学地建立和管理软件工程过程。ISO/IEC12207 《信息技术一软件生存周期过程》总结了有关研究成果,描述了软件生存期的各个过程及其关系,成为当前关于软件质量管理和软件过程评估与改进方面国际标准的主要参照文献,也是美国、欧洲共同体等发达国家软件工程标准的基本参照文献。我国也发布了等同于国际标准的国标GB/T 8566。 1 ISO/IEC 12207 1.1 ISO/IEC 12207的主要内容 ISO/IEC 12207的主要内容是对软件生存期过程给出了明确的定义。它将软件生存期过程分为3类，即基本类过程、支持类过程和组织类过程，总共定义了17个过程；每个过程包含若干活动，总共74项活动；每个活动是一组相互协调的作业，总共232个作业。作业表示为某种要求、自我说明、建议或可允许的活动。 基本生存周期过程 基本生存周期过程是构成软件生存周期主要部分的那些过程，这些过程启动并执行软件产品的开发、操作或维护，含有5个过程。 l获取过程：定义需方（即获取一个系统、软件产品或软件服务的组织）的活动。 l供应过程：定义供方（即向需方提供系统、软件产品或软件服务的组织）的活动。 l开发过程：定义开发者（即定义和开发软件产品的组织）的活动。
l操作过程：定义操作者（即在计算机系统运行环境中为用户提供操作服务的组织）的活动。 l维护过程：定义维护者（即对软件产品进行维护服务的组织）的活动，这个过程包括系统移植和换代。 支持生存周期过程 支持过程是对另一个过程提供支持的过程。被支持的过程根据需要采用支持过程，并与该过程结合，帮助软件项目获得成功，并提高质量。支持生存周期过程包括8个过程。 文档开发过程：定义对某生存周期过程所产生的信息进行记录的活动。 配置管理过程：定义配置管理活动。 质量保证过程：定义保证软件产品和过程符合规定要求，遵守一定计划的活动。 验证过程：定义需方、供方或独立的第三方对软件产品进行验证的活动。这些验证活动的深度由软件项目的性质决定。 确认过程：定义需方、供方或独立的第三方对软件产品进行确认的活动。 联合评审过程：定义对某项活动的状态和产品进行评价的活动。这一过程可由任何双方共同采用，其中一方（评审方）评审另一方（被评方）。 审计过程：定义对是否符合要求、计划和合同进行确定的过程。这个过程可由任何双方采用，其中一方（审计方）审计另一方（被审方）的软件产品或活动。 问题解决过程：定义对开发、操作、维护或其他过程中发现的问题（包括不一致性）进行分析与排出的过程。 组织生存周期过程
软件开发流程软件项目生命周期模型
需求分析 需求分析流程图 过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优 先级，采用讨论表决的方法选择并确定最终的技术方案。 关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 工作量、工期、日程、人数 成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的管 理。） 质量目标
软件生存周期各阶段活动定义浅释 首先讲一下软件生存周期的定义，即以需求为触发点，提出软件开发计划的那一刻开始直到软件在实际应用中完全报废为止可以认为是一个完整的软件生存周期，软件生存周期的提出是为了更好的管理、维护和升级软件。其中更大的意义在于管理软件开发的步骤和方法。它把整个的软件生存时间看作是一个整体，以时间的推移和软件开发的工作重心之间作为划分点，把软件开发和维护的工作细分为若干个相对独立的部份，从而更好的控制软件的开发进度和难度，同时也十分有利于降低软件的出错频律，协调各个部门间的工作配合和责任分配。 软件生存周期的各个阶段的划分并没有一成不变的法则，不同的开发方式、软件种类、软件规模和开发环境都会在不同程度上影响软件生存周期各阶段的划分，但无论最终把生存周期如果根据自己的实际情况进行划分，都是旨在更好的利用手中的资源（主要指人力资源、软件资源、技术资源和源码资源），降低软件的开发风险、复杂度和开发成本（主要以开发的时间和投入资源为衡量标准），要做到最好的对软件生存周期各阶段进行划分，就必须遵循一条基本的原则，那就是在各阶段的任务应尽可能的相对独立，同一阶段各项任务的性质应尽可能的相同，从而达到降低每个阶段任务的复杂度，减少不同阶段任务之间的联系。这样做对软件项目开发的组织管理是十分有必要的，同时对最终的软件项目开发成功是不可或缺的。 尽管软件的生存周期各阶段的划分没有一个明确的法则，但就一般性而言，软件生存周期包括可行性分析、项目开发计划、需求分析、概要设计、详细设计、编写代码、软件测试和软件维护等活动（有的文档资料和开发项目把概要设计和详细设计合在一起，统称为软件设计或设计），这些活动的每一个可以说是软件开发过程中必须要经历的，所以我们应该将它们按照项目的划分合理的安排到各个阶段里面去。 既然软件开发周期这么重要，无论对软件项目最终开发是否能取得成功或是对软件管理和资源投入，我们就应当充份的了解周期里各个活动的定义和任务，才能合理，准确，客观的安排每一阶段的工作，以下就对各种活动的定义和任务做一下简单介绍，使之对它们有一个初步的了解。 一、可行性分析和项目开发计划 这两个活动通常被整合在一起进行，在实际工作中通常把它们归类到同一个阶段中。在某种程度上甚至可以把它们看成是一个活动整体，要做的事情就是回答“需要做什么？要如何去做？可不可能完成？” 在这个阶段中经验起到了决定性的作用，软件工程之所以难就难在没有固定公式可供使用，很多时候都是靠系统分析员的经验来判断是否可行，在这个阶段中，可行性分析要依靠项目开发计划提供依据，而项目开发计划只有在初步得到可行性研究后才能再深入制定，两个活动可以说是互相制约，互相促进的关系。 同时在这个阶段中对要解决的问题定义十分重要，要注意和各方多沟通，得到尽可能准确的问题定义，再和各方再次沟通看看各方的理解是否相同，一般对问题的精确定义和理解在项目开发计划里解决比在需求分析阶段决解更合理，也可以更符合各方利益的要求，同时不会对软件开发方向造成隐患，亦不会给双方就软件开发报酬的商议造成不必要的麻烦。 在用户提出一个软件开发要求后，系统分析员要对此用户的机构进行了解，明确它是一个什么样的机构，它的作用是什么，这有利于分析所开发的项目的原由，同时对使用此软件的最终部门要进行一系列的观察研究，组织开会讨论，通过这一系列工作就可以确定软件项目的性质、目标和规模，其实这工作有点像需求分析的简化版，但对项目的后期工作是一个奠基的作用。到现在应该能够得出可行性研究报告了。 如果可行性研究的结果是可行的，接下来的任务就是制定详细的项目开发计划，项目开发计划主要根据所开发的项目的目标、性能、功能、规模来确定所需的资源，主要包括三个
一、软件生命周期： 软件生命周期是指从软件定义、开发、使用、维护到淘汰的全过程。 1.软件定义期 是软件项目的早期阶段，主要由软件系统分析人员和用户合作，针对有待开发的软件系统进行分析、规划和规格描述，确定软件是什么，为今后的软件开发做准备。这个时期往往需要分阶段地进行以下几项工作。 1)软件任务立项 软件项目往往开始于任务立项，并需要以“立项申请报告”的形式针对项目的名称、性质、目标、意义和规模等做出回答，以此获得对准备着手开发的软件系统的最高层描述。 2)项目可行性分析 软件任务立项报告批准后，接着需要进行项目可行性分析。可行性分析是针对准备进行的软件项目进行的可行性风险评估。因此，需要对准备开发的软件系统提出高层模型，并根据高层模型的特征，从技术可行性、经济可行性和操作可行性这三个方面，以“可行性报告”的形式，决定项目是否继续进行下去。 3)制定项目计划 确定项目可以进行后，需要针对项目的开展，从人员、组织、进度、资金、设备等多个方面进行合理的规划，并以“项目计划”的形式提交书面报告。 4)软件需求分析 软件规格描述的具体化与细节化，是软件定义时期需要达到的目标。需求分析要求以用户需求为基本依据，从功能、性能、数据、操作等多个方面，对软件系统给出完整、准确、具体的描述，用于确定软件规格。其结果将以“需求规格说明书”的形式提交。 注：在软件项目进行过程中，需求分析是从软件定义到软件开发的最关键步骤，其结论不仅是今后软件开发的基本依据，同时也是今后用户对软件产品进行验收的基本依据。 2．软件开发期 在对软件规格完成定义以后，可以按照“需求规格说明书”的要求对软件实施开发，并由此制作出软件产品。这个时期需要分阶段地完成以下几项工作。 1)软件概要设计 概要设计是针对软件系统的结构设计，用于从总体上对软件的构造、接口、全局数据结构和数据环境等给出设计说明，并以“概要设计说明书”的形式提交书面报告，其结果将成为详细设计与系统集成的基本依据。 注：模块是概要设计时构造软件的基本元素，因此，概要设计中软件也就主要体现在模块的构成与模块接口两个方面。结构化设计中的函数、过程，面向对象设计中的类、对象，都是模块。概要设计时并不需要说明模块的内部细节，但需要进行全部的有关它们构造的定义，包括功能特征、数据特征和接口等。在进行概要设计时，模块的独立性是一个有关质量的重要技术性指标，可以使用模块的内聚、耦合这两个定性参数对模块独立性进行度量。 2)软件详细设计 设计工作的第二步是详细设计，它以概要设计为依据，用于确定软件结构中每个模块的内部细节，为编写程序提供最直接的依据。