CMMI软件开发流程1

软件开发流程软件项目生命周期模型

需求分析

需求分析流程图

过程描述

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、测试负责人与临时项目组确定项目关键参数。

工作量、工期、日程、人数

成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预

算的管理等同于计划工作量的管理。）

质量目标

14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。

15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。

16、PM、测试负责人编制项目计划书。

17、PM、测试负责人编制项目日程表。

18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。

19、PM指示配置管理员建立配置基线。

20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。

设计

设计流程图

过程描述

1)项目经理组织项目组人员学习需求规格书；

2)项目经理组织项目组中的开发人员确定设计约束，这些约束可能包括一下几个方面：

需求约束，需求规格书中约定的设计约束；

隐含约束，需求规格书中没有，但对系统的设计或者使用带来潜在影响的特殊约束。

3)项目经理及开发人员根据需求规格书、架构设计书进行设计，编制《设计说明书》。

基于对业务和现有系统结构的理解，划分/调整系统模块。

描述各系统模块协作实现各业务场景的处理流程(可用序列图)。

必要时(通常要反复几轮)，修正系统模块划分和处理流程。

描述各处理流程中的各活动的输入、处理、输出和可能的异常。

系统模块构成及其相互关系。(可用类图、包图。)

系统模块内部设计。(功能、管理的数据、对外的服务、对内的服务,要求明确各模块的对外接口。)

4)开发人员根据《需求规格书》、《架构设计书》进行设计、《设计说明书》进行用户界面

和数据库以及接口等方面的详细设计，纳入《设计说明书》。

用户界面设计。(建议使用Visio中的窗口和对话框、工具栏和菜单、公共控件这几个形状组来绘制，具体操作方法是：点击“文件”选项→选定“形状”→选定“软件和数据库”→选定“软件”→依次选定上述三类形状组。)

数据库设计。

文件设计(文件的存贮位置与名称、格式与内容定义。)。

接口设计。(含内部通讯接口、外部通讯接口、用户图形界面、报表、其它接口。)

5)项目经理组织开发人员、测试人员及其他技术骨干评审《设计说明书》。

6)配置管理员建立设计阶段配置基线；

7)项目经理编制阶段报告(项目总结报告中的度量数据页面)，组织项目组人员并邀请部门

经理召开阶段会议，并形成会议纪要。

编码流程

编码流程图

过程描述

a)根据准入条件中的设计文档，绘制详细类图，以指导编码。

b)对生成的类图进行审核。

c)项目经理组织开发人员学习编码规范、用户界面规范，以保障程序的可靠性、可读

性、可修改性、可维护性、一致性以及界面的规范性。

d)开发环境的配置

项目经理或其指定人员在公司的《开发环境指南》的基础上编制开发环境配置说明，项目组成员遵照开发环境配置说明配置统一的开发环境。

e)编写及调试

开发人员根据设计说明书和编码规范、用户界面规范的要求编写代码，自行进行检查、调试并解决BUG。

f)评审代码

项目经理组织开发人员、项目组外的专家等对本项目修订的所有代码进行评审或审批。

g)进行自测

开发人员对代码进行联调，对照测试人员编制的测试用例中的正常业务流程部分（在测试用例中已明确标出）进行测试，并全部通过测试。联调测试中，不要求记录BUG，不须编制测试报告。

h)编写阶段报告

项目经理编制阶段报告，召开阶段会议。

编码规范（见规范说明书）

测试流程

测试流程图

过程描述

1、测试负责人组织测试人员学习、评审《用户需求列表》、《需求规格书》。在学习、评审过程中

充分理解客户及业务需求，确保文档信息的正确性、充分性、一致性。

2、测试负责人组织测试人员完成编写整个项目的测试方案。

3、测试负责人组织测试人员基于《需求规格书》编写测试用例。当《设计说明书》通过评审后，

测试人员基于《设计说明书》对测试用例进行必要的调整。测试用例的组织分类须遵循以下

原则：

测试用例的组织分类(例如，文档名、页面名、一级标题、二级标题等)必须与需求规格书中的各需求点明确对应起来。

4、测试负责人组织测试人员、开发人员、PM评审测试方案、测试用例。

5、测试负责人指示配置管理员将测试方案及测试用例文档入库。

6、测试负责人组织PM、开发人员、测试人员召开阶段会议并形成阶段报告。

验收流程验收流程图

过程描述

1)项目经理与客服人员沟通验收事项。

2)客服人员在客户指定的环境下参照《安装维护手册》进行产品安装调试，并把合同

约定的文档、源程序等交给客户。

3)客服人员对客户进行系统操作方法培训。

4)客户试用系统开展业务，测试人员收集客户反馈的问题；如果客户验收测试环境与

生产环境差异明显时，要进行性能测试，以保证满足系统性能需求。

5)测试人员在验收中发现缺陷并告知项目经理，项目经理将缺陷记录到BugFree中。

某些情况下（例如，缺陷描述不详、明显不是缺陷等）项目经理可以向相关人员（测试人员、客户）解释、说明，达成一致后驳回相关人员（测试人员、客户）提出的问题。

6)项目经理将缺陷分派给适合的开发人员。

7)开发人员分析缺陷的原因及解决该缺陷，并将该缺陷的解决方法及解决状态更新

BugFree。

8)项目经理将所有已处理的缺陷转移至测试人员进行缺陷修复的确认。

如果测试结果表明缺陷仍未解决，项目组内测试人员通过项目经理将该缺陷返回给处理该缺陷的开发人员。

如果测试结果表明缺陷已解决，项目组内测试人员告知项目经理，项目经理关闭该缺陷。

9)在更新验收版本之前，测试人员要进行一次回归测试。对即将发布的新版本，进行

一次整体的测试。

10)验收中发现的缺陷累积到一定程度或严重缺陷导致验收无法继续时，应更新验收版

本。

必须解决的缺陷全部解决后，配置管理员更新代码及配套文档并标识验收的产品版本，项目经理指定人员更新验收版本并部署至验收环境中。

测试人员分析本次更新涉及的范围，确定回归测试的范围，并在此范围内进行回归测试。

如果更新验收版本之后，要回到活动4，直至验收通过。

11)项目经理和客户代表根据验收期间的测试记录等依据验收通过准则，达成一致，根

据所签署的商务合同，向客户交付合同中要求提供的交付物，包括《用户手册》、《安装维护手册》等，并取得客户验收通过的书面确认。

12)项目经理收集整理项目相关的资料和数据，在项目组内分配项目关闭各项工作，包

括技术总结、软件产品总结，相关数据整理等。

13)配置管理员对配置库进行更新，整理相关工作产品。

14)项目经理收集项目组成员反馈的建议，根据对项目的监控过程进行项目总结，编制

项目总结报告。

15)项目经理召开项目总结会议，邀请项目组成员、QA、技术总监、技术部骨干人员参

加。必要时可邀请客户参加。

16)项目经理向QA、配置管理员发出项目结束通知，申请配置库归档。配置管理员收回

该项目配置库权限，在《研发部配置项列表》中更新相关信息，并通知项目组、QA。

研发部释放项目组占用资源。项目正式关闭。

2012/2/16

zsinba

软件开发流程图.docx

软件开发流程图 项目前期 需 求 变 化项目启动 需 要系统实变现 更系统调测 开始 获取用户需 编制初步方 编制进度 / 跟踪 需求基本确定 编制详细预 配置内部资 分配开发任 系统实现 控制/调 无需变更 技术调测 PM：获取 EU主要的关键性需求 PM：根据 GM安排编制简略 / 详细的建设方案 PM：基于内部预算对 EU提供费用报价 PM：与 EU确认需求变动及方案、费用调整 PM：完成详细内部预算并提交给GM PM：通过内部项目管理系统配置详细人员、进度安排 PM：移交 EU需求给PG，安排 PG开发任务 PG：根据 EU需求及 PM要求，执行开发任务 PM：通过内部项目管理系统审核PG工作日志， 确认 EU需求变动，执行进度控制，必要时变 更人员安排及内部预算 PG：技术调测及修改；根据TE 测试文档调试修改集成测

部署试

TE：进行集成测试，编制测试文档，提交PM，送达PG 未 通 过通过 通过项目后期 系统验收 结束PG：部署至外部服务器 PM：系统初验 EU：试用 PG ： 部署正式上线，编制开发字典，提交PM M 获得试用意见 TE：编制系统操作手册、功能列表，提交PM PM：提交开发字典、操作手册、功能列表给EU,通过内部项目管理系统结项，向 GM汇报 备注： PM (Project Manager)：项目经理PG (Programmer)：程序员EU (End-User)：最终用户TE (Test Engineer)：测试工程师GM (General Manager)：总经理 硬件开发流程图

产品调研 / 新产品立设计开发执行子项目分支执 首样评审业务部主导 研发部 研发部主导 业务部 研发部主导 研发部主导 业务部 采购部 研发部主导 业务部 工程部 1、资料搜集并拟定产品需求表 ① 预期的用途，特定的功能、性能和安全要求； ② 类似产品的名称，型号或参考实物样板； ③ 细化客户对产品的外观、功能、价格等要求； ④拟定《产品需求表》展开评审会议 , 并形成《技术可行性分 析报告》同时交总经理审批。 2、研发经理组织结构、电子与ID 协调定义，进行3D 图形设计 与修改，形成《产品外观效果图》《产品3D 图》、《产品规 格书》会同业务、总经理展开评审会议，若评审通过，由业 务形成《立案通知书》和《产品研发任务书》交总经 理审批，输出交研发部进行设计开发工作。 注： B 类项目可直接评估形成《产品研发任务书》 3、研发部签收《产品研发任务书》 , 项目负责人根据《产品外 观效果图》、《产品 3D 图》、《产品规格书》、《产品研发 任务书》的要求对设计工作进行策划形成《项目进度表》，包括： ① 设计过程中各阶段时间和工作内容的安排； ② 设计评审、设计验证、设计确认的安排； ③ 设计过程中各项工作的分工及各小组之间的接口及工 作顺序等； 4、项目负责人根据《项目进度表》推进设计，每设计阶段 必须与研发部经理进行设计评审，设计评审完成后研发部 完成硬件打样，首样制作由该项目各负责工程师共同制作， 并完成《样机测试记录表》、《操作说明》、《首样评审表》， 并填写《线路板通知书》、《开模申请表》交研发经理审核。研发 部根据设计评审结论编制 BOM、电路原理图、贴片图的PDF电子 版、结构爆炸图、《样机测试记录表》、《软件测试 记录表》、《样机测试记录表》并存档。 5、结构电子依《首样评审表》内容，对需要做设计变更的 尤其产品外观改动的，需经总经理批准的《设计变更表》， 才能对其模具设计修改，并填写《改模记录表》。首样评审完 成修改通过后，发放至工程部由工程部汇总完成《工程 样机测试汇总表》，3 个工作日后由项目负责人组织电子、 结构、工程、品质、业务进行项目首样评审。

cmmi软件生产过程标准

何谓CMM? CMM是由美国卡内基-梅隆大学的软件工程研究所(SEI)推出的评估软件能力与成熟度的一套模型。它侧重于软件过程开发的管理及软件工程能力的改进与评估，是目前国际上最流行、比较实用的一种软件生产过程标准，成为当今企业从事规模软件生产不可缺少的一项内容。CMM模型共分为五个级别：初始级、可重复级、定义级、管理级和优化级。 软件工程：什么是CMMI? CMMI全称是Capability Maturity Model Integration, 即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进 CMMI分为五个等级，二十五个过程区域（PA）（如图所示）。 1．初始级软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 2．已管理级建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 3．已定义级已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 4．量化管理级分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。5．优化管理级过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性： 每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。 CMMI的原则、目标和方法 一、CMMI的原则： 1．强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的，大力度的、一致的支持是过程改进的关键。 2．仔细确定改进目标，首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。 3．选择最佳实践，应该基于组织现有的软件活动和过程财富，参考其他标准模型，取其精华去其糟粕，得到新的实践活动模型。 4．过程改进要与组织的商务目标一致，与发展战略紧密结合。 二、CMMI目标:

软件开发过程详解

软件开发过程详解 软件开发过程即软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。 生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件开发过程覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。 1.需求分析 1.1 需求分析的特点和任务 需求分析是软件开发的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。 需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系（分析）。然后，你可以使客户信息结构化，并编写成文档和示意图（说明）。下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。这四个过程贯穿着需求分析的整个阶段。需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。确定用户已经理解：对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。 1.2.需求分析的一般方法

软件开发流程

快视信息软件开发流程规范： 用户需求：软件项目首先由客户经理(CM，Custom Management)接洽客户的较大的需求。这时的需求叫市场需求（或叫用户需求），客户经理会进行各个项目的安排，即对项目的启动时间和发布时间进行规划和设置。 项目经理(PM，Project Management)对客户经理负责。项目经理的需求是根据客户经理给的，项目经理不和用户（客户）直接接触（通过客户经理接触），负责和用户进行需求洽谈和沟通的是客户经理。一个项目的需求在一般情况下是不准变更的，如果有需求理解方面的不清楚可以进行沟通，但是需求是不变更的。如果用户有新的需求，一般规划在下一个版本中。因为需求变更了，这个目的时间就要进行调整，就不能按计划进行和完成。客户经理提交给项目经理的是需求规格说明书。 一、项目开工会 在项目经理领到客户经理分配给的需求后，做项目计划，具体做项目人员的确定、需求的分解（需求分解到每个人）、代码量的估计，项目各个阶段时间的划分和工作量的计划、质量指标的设定。这时项目经理需要输出的文档是项目需求分解任务书、项目计划PPT、及做好整个项目需要填写的一系列表格。然后组织项目组成员和客户经理CM、QA(质量审计经理)进行项目开工会。这时这个项目就算真正启动，计算工作量时，即计算这个项目总共花了多少个工时，工时是项目经理做计划的时间也算在内，再加上项目开工会和后续各个阶段总共花的总工时数，还有各个阶段开会所花的时间。在项目开工会上，各个成员就明确了这个项目是属于增强型项目，还是其他项目的项目性质，增强型项目的意思是说在原来上一版本的基础上又根据新的需求进行增强型开发。还有要明确项目最后开发出的新增代码量有多少，最后要明确每个人的需求任务，接下来着手进行SRS的写作。 二、SRS阶段：System/Software Requirment Specification 软件需求规格说明 在项目开工会后，项目组就开始按照在项目开工会上项目经理的需求任务分解的任务开始进行SRS的写作。 一般项目经理给你的一个子需求任务，你这时需要分解为更小的需求。一般一个需求的写作是按这样进行的。先简单介绍这个需求，然后把这个需求设计成黑盒的形式，即输入，处理过程、输出。这些都需要写详细，任何一个需求都写成这种形式，输入是什么，处理过程是什么，输出结果是什么。处理过程需要用Visio或者PPT画出处理流程图，流程图要很详细。每一步的各种情况都要表示和考虑到。对异常情况也要考虑和进行处理。还有要说明在原来的基础上怎么改动，具体方法要进行说明。设计的数据库表结构，要给出脚本，SQL语句，表结构需说明每个字段，哪些是主键，你在这个需求处理过程中哪里使用了哪些表，需要进行哪些操作，都需要说明。这里需要设计和编制《数据库设计说明书》文档。该文档中描述该系统中设计出的所有的数据库表结构和各字段类型。还有多个操作对象要画序列图表示出按时序的处理过程。这个SRS文档就相当于我们平时毕业设计或者一个题目的详细设计阶段达到的水平，甚至比它更详细。每个项目组成员都把自己的需求的SRS文档写出来之后放到配置库中，然后每个人对项目组其他成员的（非自己的）SRS文档进行Review（评审）,对每个SRS文档在每页发现或者纠正的错误数不能低于一定的数目，而且要保留批注记录，经过Review的（保留批注的）文档要放到配置库的Review文件夹下，这是进行项目质量指标收集的重要依据，是QA 进行调阅和审计的资料。项目经理要对SRS文档、SRS Review文档进行汇总。在汇总后组织项目组全体成员进行SRS阶段会议，对每个人写的SRS进行评审会议（讨论和提意见），对别人给你提的修改意见你要一一进行说明，说明为什么不改，怎么改的，是什么问题，问题严重程度属于什么级别，而且都要填表，也是QA进行审计的内容。开完会后如果每个人完成的都差不多，然后安排半天或者一天的时间进行返工，主要是进行修改文档，按在会上讨论的结果和别人给你的Review 文档结果（评审结果）进行准一修改和完善。然后再进行SRS阶段开会，如果都做的比较到位和具体、符合要求，即关闭SRS阶段。这时SRS阶段的花费的工时数和一些质量活动指标就出来了，比如你这个SRS文档写了几页，每页的错误数是多少，返工修改用了多少时间，然后这些这个比率也会自动计算出来。进而可以判断这个阶段的质量。每个项目组成员在每天工作完毕后都要进行Time Sheet 的填写，必须具体到半个小时，这是统计和分析的需要。填写必须真实。 三、UTP、STP阶段（UTP、STP写作） UTP Unit Test Plan 单元测试计划 STP System Test Plan

cmmi软件开发流程

软件开发流程软件项目生命周期模型

需求分析 需求分析流程图 过程描述 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、测试负责人与临时项目组确定项目关键参数。 工作量、工期、日程、人数 成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预 算的管理等同于计划工作量的管理。） 质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。

嵌入式Linux应用软件开发流程

从软件工程的角度来说，嵌入式应用软件也有一定的生命周期，如要进行需求分析、系统设计、代码编写、调试和维护等工作，软件工程的许多理论对它也是适用的。 但和其他通用软件相比，它的开发有许多独特之处： ·在需求分析时，必须考虑硬件性能的影响，具体功能必须考虑由何种硬件实现。 ·在系统设计阶段，重点考虑的是任务的划分及其接口，而不是模块的划分。模块划分则放在了任务的设计阶段。 ·在调试时采用交叉调试方式。 ·软件调试完毕固化到嵌入式系统中后，它的后期维护工作较少。 下面主要介绍分析和设计阶段的步骤与原则： 1、需求分析 对需求加以分析产生需求说明，需求说明过程给出系统功能需求，它包括：·系统所有实现的功能 ·系统的输入、输出 ·系统的外部接口需求（如用户界面） ·它的性能以及诸如文件/数据库安全等其他要求 在实时系统中，常用状态变迁图来描述系统。在设计状态图时，应对系统运行过程进行详细考虑，尽量在状态图中列出所有系统状态，包括许多用户无需知道的内部状态，对许多异常也应有相应处理。 此外，应清楚地说明人机接口，即操作员与系统间地相互作用。对于比较复杂地系统，形成一本操作手册是必要的，为用户提供使用该系统的操作步骤。为使系统说明更清楚，可以将状态变迁图与操作手册脚本结合起来。

在对需求进行分析，了解系统所要实现的功能的基础上，系统开发选用何种硬件、软件平台就可以确定了。 对于硬件平台，要考虑的是微处理器的处理速度、内存空间的大小、外部扩展设备是否满足功能要求等。如微处理器对外部事件的响应速度是否满足系统的实时性要求，它的稳定性如何，内存空间是否满足操作系统及应用软件的运行要求，对于要求网络功能的系统，是否扩展有以太网接口等。 对于软件平台而言，操作系统是否支持实时性及支持的程度、对多任务的管理能力是否支持前面选中的微处理器、网络功能是否满足系统要求以及开发环境是否完善等都是必须考虑的。 当然，不管选用何种软硬件平台，成本因素都是要考虑的，嵌入式Linux 正是在这方面具有突出的优势。 2、任务和模块划分 在进行需求分析和明确系统功能后，就可以对系统进行任务划分。任务是代码运行的一个映象，是无限循环的一段代码。从系统的角度来看，任务是嵌入式系统中竞争系统资源的最小运行单元，任务可以使用或等待CPU、I/O设备和内存空间等系统资源。 在设计一个较为复杂的多任务应用系统时，进行合理的任务划分对系统的运行效率、实时性和吞吐量影响都极大。任务分解过细会不断地在各任务之间切换，而任务之间的通信量也会很大，这样将会大大地增加系统的开销，影响系统的效率。而任务分解过粗、不够彻底又会造成原本可以并行的操作只能按顺序串行执行，从而影响系统的吞吐量。为了达到系统效率和吞吐量之间的平衡折中，在划分任务时应在数据流图的基础上，遵循下列步骤和原则：

一个完整的软件开发流程

一个完整的软件开发流程 一、开发流程图 二、过程产物及要求 本表主要列出开发阶段需要输出的过程产物，包括产物名称、成果描述、负责人及备注，即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。 三、过程说明 (一)项目启动 1、产品经理和项目干系人确定项目方向，产品型项目的干系人包括公司领导、产品总监、技术总监等，项目的话则包括客户方领导、主要执行人等。

2、公司领导确认项目组团队组成，包括产品经理、研发项目经理、研发工程师、测试团队等。 3、明确项目管理制度，每个阶段的成果产物需要进行相应的评审，评审有相应的《会议纪要》;从项目启动起，研发项目经理每周提供《项目研发周报》;测试阶段，测试工程师每周提供《项目测试周报》。 4、产品经理进行需求调研，输出《需求调研》文档。需求调研的方式主要有背景资料调查和访谈。 5、产品经理完成《业务梳理》。首先，明确每个项目的目标;其次，梳理项目涉及的角色;再来，每个角色要进行的事项;最后，再梳理整个系统分哪些端口，要有哪些业务模块，每个模块再包含哪些功能。 (二)需求阶段 1、进入可视化产物的输出阶段，产品经理提供最简单也最接近成品的《产品原型》，线框图形式即可。在这个过程中还可能产生的包括业务流程图和页面跳转流程图。业务流程图侧重在不同节点不同角色所进行的操作，页面跳转流程图主要指不同界面间的跳转关系。项目管理者联盟 2、产品经理面向整个团队，进行需求的讲解。 3、研发项目经理根据需求及项目要求，明确《项目里程碑》。根据项目里程表，完成《产品开发计划》，明确详细阶段的时间点，最后根据开发计划，进行《项目任务分解》，完成项目的分工。 4、研发工程师按照各自的分工，进入概要需求阶段。《概要需求》旨在让研发工程师初步理解业务，评估技术可行性。 (三)设计阶段 1、UI设计师根据产品的原型，输出《界面效果图》，并提供界面的标注，最后根据主要的界面，提供一套《UI设计规范》。UI设计规范主要是明确常用界面形式尺寸等，方便研发快速开发。UI设计常涵盖交互的内容。 2、研发工程师在界面效果图，输出《需求规格》，需求规格应包含最终要实现的内容的一切要素。 3、研发工程师完成《概要设计》、《通讯协议》及《表结构设计》，及完成正式编码前的一系列研发设计工作。 (四)开发阶段项目经理博客 1、研发工程师正式进入编码阶段，这个过程虽然大部分时间用来写代码，但是可能还需要进行技术预研、进行需求确认。

软件开发过程概述

第1章软件开发过程概述 1.1 软件开发过程概述 1.1.1 软件的概念 软件（Software）简单的说就是那些在计算机中能看的着，但摸不着的东西，概念性的说软件也称为“软设备”，广义地说软件是指系统中的程序以及开发、使用程序所需要的所有文档的集合软件分为系统软件和应用软件。 软件并不只是包括可以在计算机上运行的程序，与这些程序相关的文件一般也被认为是软件的一部分。 软件被应用于世界的各个领域，对人们的生活和工作都产生了深远的影响。 1. 系统软件 系统软件是负责管理计算机系统中各种独立的硬件，使得它们可以协调工作。系统软件使得计算机使用者和其他软件将计算机当作一个整体而不需要顾及到底层每个硬件是如何工作的。 一般来讲，系统软件包括操作系统和一系列基本的工具（比如编译器，数据库管理，存储器格式化，文件系统管理，用户身份验证，驱动管理，网络连接等方面的工具）。 2. 应用软件 应用软件是为了某种特定的用途而被开发的软件。它可以是一个特定的程序，比如一个图像浏览器。也可以是一组功能联系紧密，可以互相协作的程序的集合，比如微软的Office软件。也可以是一个由众多独立程序组成的庞大的软件系统，比如数据库管理系统。较常见的有：文字处理软件如WPS、Word等；信息管理软件；辅助设计软件如AutoCAD ；实时控制软件；教育与娱乐软件。 1.1.2 编程与软件开发 软件开发的内容是：需求、设计、编程和测试。 （1）需求：不仅仅是用户需求，应该是开发中遇到的所有的需求。比如，你首先要知道做这个项目是为了解决什么问题；测试案例中应该输入什么数据......为了清楚地知道这些需求，你经常要和客户、项目经理等交流。 （2）设计：编码前，肯定有个计划告诉你要做什么，结构是怎样等等。你一定要按照这个来做，否则可能会一团糟。 （3）编程：如果在项目截止日，你的程序不能跑起来或达不到客户的要求，你就拿不到钱。

软件开发过程管理规范

软件开发过程管理规范文件管理序列号：[K8UY-K9IO69-O6M243-OL889-F88688]

0 引言 如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。目前研发对软件开发的过程缺乏细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。此绩效考核办法旨在结合实际情况合理客观地评价开发效率和质量。 1 目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 2 软件项包括 1）技术文档：主要包括：可行性分析报告、需求分析报告、软件功能规格说明、开发计划、系统设计报告、测试文档、用户手册、总结报告等； 2）计算机程序。 3 度量数据的来源 1）项目计划； 2）评审报告； 3）测试报告； 4）问题报告； 5）软件维护记录； 4 质量度量

4.1 度量指标 主要根据各类软件项检查表的检查指标来确定，例如，软件需求规格说明书检查表（见附录1），有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。 4.2 质量等级 1）软件项的质量等级的确定根据度量综合指标进行。 2）度量综合指标计算公式为：Total = ∑QiMi。 3）其中i=1,2,...n代表指标数量； 4）Q代表度量的指标； 5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。 度量指标权重系数表： 序号指标权重 1 指标1 权数1 2 指标2 权数2 3 指标3 权数3 4 指标4 权数4 5 指标5 权数5 加权平均分 1.0 6）质量评价：一般地，根据度量综合指标值，有以下评分标准。 质量评价计分标准表 序号得分质量评价

cmmi软件开发流程

c m m i软件开发流程 Prepare d on 24 November 2020

软件开发流程软件项目生命周期模型

需求分析 需求分析流程图 过程描述 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、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的 管理。） ?质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。

软件开发方法与过程

（1）软件开发过程是什么？ 软件开发过程是按照软件工业化的标准定义的心之所向，所向披靡 ?在软件开发中必须具有的一系列过程规范； ?软件开发过程是定义在软件中的软件需求、软件设计、软件编码、软件测试、软件部署的实现目标和规范化的管理方法论； ?软件开发过程是保证软件工业化生产的法典；?软件开发过程做的是：定义标准和为了达到标准的路； ?软件开发过程要改善的是：软件开发的效率和质量； ?软件开发过程的实现最重要的是：人。 （2）大多数软件项目失败的原因： a)不完整、不现实的项目需求 b)对需求的变更束手无策 c)脆弱的架构 d)采用不成熟的技术 e)测试的不充分性 f)拙劣的进度计划和评估 g)缺乏资源 h)不具备项目管理方法 i)缺少管理层的支持 （3）软件工程的三个要素：方法、工具和过程（4）A software project failed if It is delivered late It is runs over the budget It does not satisfy the customer’s need It is of poor quality Classical software development methods have not solved software crisis.传统的软件开发方法没有能够解决软件危机。 （5）A software engineer’s job: a)Make a working plan.制定工作计划 b)Carry out it.(Do their work according to this plan)按照此计划工作 c)Try his/her best to produce high-quality products.尽最大努力生产 出高质量产品 (6)3 Key aspects a)Quality products 高质量产品 b)Expected costs c)On agreed schedule （7）Summary of PSP PSP is a framework designed to teach software engineers to do better work Estimate and plan →track →improve quality Quality methods take time to learn and practice,but it will help you in you engineering career Establish goals →measure quality → understand the process → change and reure process → measure & analyze the results → recycle improving Identify the tasks you do (8)敏捷软件开发宣言 个体和交互胜过过程和工具 可以做到工具的软件胜过面面俱到的文档 客户合作胜过合同谈判 响应变化胜过遵循计划 敏捷开发的原则： 1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 尽早交付具有部分功能的系统和质量系统之间具有很强的相关性 2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 关于态度的声明，敏捷过程的参与者不惧怕变化，努力保持软件结构的灵活性。 3、经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间越短越好。 关注的目标是交付满足客户需要的东西。它们是敏捷实践区别其他过程的特征所在。 4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 有意义的、频繁的交互，必须对软件项目进行持续不断地引导。 5、围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。 人被认为是项目取得成功的最重要的因素。 6、在团队内部，最具有效果并且富有效率的传递信息的方法就是面对面的交谈。首要的、默认的沟通方式。 7、工作的软件是首要的进度度量标准。 敏捷项目通过度量当前软件满足客户需求的数量来度量开发速度。 8、敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期、恒定的开发速度。不是 50米短跑，而是马拉松。以快速但是可持续的速度行进。 9、不断关注优秀的技能和好的设计会增强敏捷能力。

软件开发过程

软件开发过程 一. 规范 规范应当是从简单到复杂的，我们首先制定的规范并不复杂，只是对如何使用异常机制的一些定义。要获得这些规范并不困难，大部分介绍异常的技术资料中都给出了很多的建议。理解并使用它们，仅此而已。 1、对不正常的条件使用异常，尽可能准确的使用预定义的异常。这一目标来自于Effective Java中的条款39和条款42。其目的是为了能够正确的使用异常。使用系统提供的异常能够减少代码，提高代码的可读性（特别是新人不需要了解自定义的异常结构）。大多数情况下，系统提供的异常已经足够用了。 2、尽可能多的收集异常发生时的上下文信息。异常之所以比返回码优秀的一个原因就是它能够将错误类型化，提供比错误代码多得多的信息。因此，我们实在没理由不使用这一功能。 3、正确的使用异常转义，并保留原异常信息。异常转义的目的是为了让客户端能够得到易于理解的类型。我们想象一个用户登录的情境，假设用户数据保存在一个文件中，当文件中找不到用户名的相关记录的时候抛出一个RecordNotFoundException异常，系统截获了这个异常，并将其发布给用户，问题在于，用户会觉得非常的奇怪，为什么会是记录没有找到呢？因此，建立一个IllegalUserException异常会更适合于这种情况。 4、针对不同的抽象层次定义不同的异常。正如我们在第三点中提到的，RecordNotFoundException异常并不适合于用户这个层次。但是，这个异常对于程序员调试代码就很有意义了。 5、将异常发布到合适的地方。有计算机的地方就一定有输入和输出。如果把异常发生时的信息收集看作输入，那么异常的输出是什么呢？可能是错误的提示信息，可能是一个显示错误信息的网页，可能是日志中的记录，可能是一条短信，也可能是一封EMail。这些就是异常的输出形式。此外，异常的输出还需要正确的确定对象，对用户来说，异常只要有一个友好的提醒方式就够了，但对于管理者来说，异常需要记录下来，或是通过异步消息进行通知。 这就是规范，你也可以把它称为最佳实践、建议等名词。当然，它还可以更加的细化，但事情总有个过程，一开始把问题弄得过于复杂未必是一件好事，你说呢？ 二．技能 有了规范是一回事，能否把规范运用起来则取决于人员的技能。在有一部描述清末的电影中，有这样一个情节，留学归来的知识分子为了提高民众的知识水平，不惜花费巨资免费发放报纸，这一举措大受欢迎，可惜大部分的民众都不识字，他们要报纸的原因只是这东西烧火很方便。 所以其次要解决的问题就是，大部分的程序员没有足够的异常处理经方面的技能。如果程序员没有这方面的概念，你把一本异常管理最佳实践放在他的面前会有用吗？ 学会使用异常并不困难，困难的是如何让程序员正确的使用异常。什么时候使用系统定义的异常。什么时候使用自定义的异常，自定义异常又该如何设计。这些都是程序员的技能问题。基于这种思路，首先做的是培训，而培训的目标是让程序员理解异常的机制，让程序员能够把异常运用到工作中。培训不等于上课，因为我们的目标是能够影响程序员的行为，单靠上课是无法达成目标的，因此我们把几种方式综合使用。一般来说，程序员对未知的技术总是

软件开发流程-论文

毕业设计（论文）题目：软件开发流程管理 班级：11工升 学号：1000303071 姓名： 指导教师： 2014年11月

从软件开发最初至今，不断地有新的软件开发技术产生，但是在软件开发能力和质量方面却始终存在达不到预计目标这一问题。每一个软件开发的最大目标，就是最大限度提高质量与生产率。而影响质量与生产率的三个关键因素：过程、人和技术，因此，我们除了提高技术能力，培养更多优质人才之外，还需要制定一套软件开发过程管理标准，并在软件开发过程中对这一标准不断地完善，以达到提高软件质量与生产率的目标。 本文结合CMM（软件过程成熟度模型），对软件开发、维护全过程进行标准化、规范化管理，制定出软件开发管理标准。 关键词：软件开发过程，管理标准

第一章软件开发的概念及目的 (4) 第二章软件开发流程划分及开发环境 (4) 2.1.软件开发阶段划分 (4) 2.2.软件开发环境需求........................... 错误！未定义书签。第三章软件开发过程中存在的问题 .................... 错误！未定义书签。 3.1.对用户方需求的掌握不全面................... 错误！未定义书签。 3.2.对软件的价值认识不清晰..................... 错误！未定义书签。 3.3.跟用户方的合作不顺利....................... 错误！未定义书签。 3.4.开发队伍的结构不合理....................... 错误！未定义书签。 3.5.软件开发管理制度不健全..................... 错误！未定义书签。 3.6.开发团队人员不稳定......................... 错误！未定义书签。第四章软件开发流程管理规范 . (10) 4.1.什么是CMM (10) 4.2.结合CMM制定开发流程管理方案 (11) 4.2.1软件项目生命周期模型................... 错误！未定义书签。 4.2.2需求分析流程图及描述................... 错误！未定义书签。 4.2.3设计流程图及描述....................... 错误！未定义书签。 4.2.4编码流程图及描述....................... 错误！未定义书签。 4.2.5测试流程图及描述....................... 错误！未定义书签。 4.2.6验收流程图及描述 (22) 第四章软件开发行业前景 (23) 参考文献........................................... 错误！未定义书签。

软件开发流程规范-详细流程

软件开发流程规范 目录 目录 0 一、概述 (2) 二、开发流程规范 (3) 2.1系统软硬件开发环境 (3) 2.2系统架构（系统组成） (5) 2.3系统功能模块设计 (6) 2.4系统功能开发流程图 (7) 2.5开发修改记录 (8) 三、开发代码规范 (9) 3.1文件结构 (9) 3.1.1 文件信息声明 (10) 3.1.2头文件的结构 (12) 3.1.3定义文件的结构 (15) 3.1.4 头文件的作用 (17) 3.1.5 目录结构 (18) 3.2命名规则 (18) 3.2.1 共性原则 (19) 3.2.2 Windows变量命名规则 (21) 3.3程序风格 (24) 3.3.1 空行 (25) 3.3.2代码行 (26) 3.3.3代码行内的空格 (29) 3.3.4 对齐 (31) 3.3.5 长行拆分 (33) 3.3.6修饰符的位置 (35) 3.3.7 注释 (35) 3.4函数设计 (40) 3.4.1 参数的规则 (40) 3.4.2返回值的规则 (42) 3.4.3函数内部实现的规则 (47) 3.4.4其它建议 (50) 3.4.5使用断言 (50) 3.4.6 引用与指针的比较 (52) 3.5变量类型定义 (56)

四、软件测试规范 (56) 4.1单元测试 (57) 4.2 系统测试 (57) 4.6 业务测试 (59) 4.7 验收测试 (59) 4.8 用户现场测试 (59) 五、软件版本管理 (60) 4.1 版本管理的必要性 (60)

、概述 本文制定烟台开发区德联软件有限责任公司计算机软件开发规范文档。本规范的目的是使公司软件开发项目阶段清晰、要求明确、任务具体、编写的代码规范，使之规范化、系统化和工程化，向公司内从事软件开发的工程师和管理人员提出一系列规范和要求，从而有利于开发过程的控制和管理，提高所开发软件系统的质量，缩短开发时间，减少开发和维护费用，以保证项目高质量、顺利进行。 本规范包含：开发流程规范和开发代码规范等，开发流程规范需要技术开发人员编写相关内容，希望每个技术人员形成习惯，如有新的内容更新会及时通知大家，如有好的规范要求也可通知编制人员及时更新。 本规范为烟台开发区德联软件有限责任公司内部材料，严禁其他商业应用。

cmmi软件开发流程

c m m i软件开发流程 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-

软件开发流程软件项目生命周期模型

需求分析需求分析流程图

过程描述

1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。 2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事 先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠 性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨 论表决的方法选择并确定最终的技术方案。 关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、 测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本 在项目可接受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。