案例-某公司软件过程规范示例
编者说明：
软件过程管理中的一个很重要的工作就是制定项目、组织的过程规范，它是软件开发组织行动的准则与指南。该文档就是一个实际的过程规范的实例，通过该实例，相信对大家根据自身情况制定符合要求的项目过程规范、组织过程规范有很好的借鉴作用。
1.总则
最大限度提高Q&P（质量与生产率），提高Q&P的可预见性，是每一个软件开发机构的最大目标。而Q&P依赖于三个因素：过程、人和技术，因此要实现Q&P的提高，除了加强技术能力，引进、培育更多优质技术人才之外，规范、改进机构的过程是一个十分重要的手段。我们希望通过在制定软件过程规范标准，并在软件开发实践中不断地完善、修订，提高Q&P和Q&P的可预见性。
本规范采用CMM（软件过程成熟度模型）的指导，吸收RUP、XP、MSF、PSP、TSP 等过程规范指南的思想、方法及实践，充分结合xxx技术开发部的实际情况，引入先进的技术、方法、工具，为公司的软件开发工作提供一部详细、可操作的过程指南。在本规范的第一版本中，主要包括管理过程和开发过程两个部分，管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。
2.项目管理过程规范
项目管理过程是对软件项目过程进行计划、监控/管理、总结的辅助过程，包括需求、配置、成本、进度、质量和风险等的管理。项目管理过程主要包括三个阶段：项目立项与计划、项目实施、项目关闭。
2.1 项目立项与计划
参与人员：技术开发部指定的项目负责人（包括前期负责人、正式的项目经理）、立项申请人、[相关最终客户]以及实施该项目的开发组队成员；
入口准则：接到经公司总经理或副总经理批准的市场部门的《软件开发立项申请表》；
出口准则：立项申请人签字确认了经修订正后的正式《软件项目计划》，并通过《工作任务卡》下达了开发任务，开发工作正式开始；
输入：经审批的《软件开发立项申请表》、与需求相关的业务资料；
输出：《软件项目计划》、《软件需求规格说明书》、《开发任务卡》；
活动：
接到《软件开发立项申请表》后，技术开发部经理指定前期负责人，并告知立项申请人；
前期负责人阅读《软件开发立项申请表》后，通过与立项申请人的沟通、阅读立项申请人提交的材料、通过立项申请人与客户直接交流等方式，了解项目目标、范围与基本需求；并形成最初的《软件需求规格说明书》；
前期负责人会同技术开发部经理以及其它相关人员，制定最初的《软件项目计划》，并组织评审；
向立项申请人提交最初的《软件项目计划》；
最初的《软件项目计划》通过立项申请人的确认后，项目经理计划安排需求分析；
需求分析完成后，形成正式的《软件需求说明书》，提交立项申请人确认；（需求分析过程参见开发过程规范部分）
根据立项申请人确认后的《软件需求说明书》，项目经理组织进行软件高层设计，并对工作任务进行分解，并根据实际需要向技术开发部经理申请资源，组建项目组队；
项目经理根据工作任务分解，下发《工作任务卡》，并协同组队成员进行任务估算；
注：工作任务包括模块开发任务、其它任务（如安装）；模块开发任务主要包括：详细设计、编码和单元测试
任务估算完成后，组队成员向项目经理提交《个人进度安排》（以甘特图的形式表示），项目经理根据每个组队成员的《个人进度安排》修订《软件项目计划》（必须包括总的计划甘特图），并提交立项申请人确认；
立项申请人确定后，项目经理根据软件项目计划基线，补充《工作任务卡》，下发到每个组队成员，开发工作开始。
相关模板：
《软件需求规格说明书》、《软件项目计划》、《工作任务卡》
说明：如果计划确认、需求确认未通过，立项申请人与项目经理进行协商，进行修正，无法达成共识的，提交部门经理、总经理协调；
2.2 项目实施
参与人员：项目经理，项目组成员；
入口准则：项目计划基线已建立，并通过立项申请人确定，带有工作进度要求的《工作任务卡》已下发到每个项目成员；
出口准则：立项申请人在《验收报告》上签字确认；
输入：《软件需求规格说明书》、《软件项目计划》、《工作任务卡》；
输出：经验收测试的可交付的程序、源代码及相关文档。
活动：
在开发期间，项目成员每周需上交一份《时间日志》、《缺陷日志》，每天向项目经理汇报工作任务进度；
在开发期间，项目经理负责填写《项目进度周报》报于技术开发部经理、立项申请人（格式不同，交予立项申请人的只需周报的第一页，报予技术开发部经理的项目进度周报的第二页为“跟踪甘特图”）；
项目经理必须根据实际的进度情况，及时调整项目计划，若发现进度延误，需采取措施。
相关模板：
《软件项目计划》、《开发任务卡》、《时间日志》、《缺陷日志》、《项目进度周报》2.3 项目关闭
参与人员：技术开发部经理或经理助理、项目经理，项目组成员、立项申请人、[相关客户、公司总经理、公司副总经理]；
入口准则：立项申请人在《验收报告》上确认；
出口准则：形成《项目总结》，完成项目绩效考核，项目数据存入“过程数据库”；
输入：《时间日志》、《缺陷日志》、《项目开发计划》；
输出：《项目总结》、已完成的《项目绩效考核表》、过程数据库中的该项目记录；
活动：
项目经理主持召开项目总结会，交流项目实施过程中的心得体会，对项目实施中的成功处、不足处进行总结，并由项目经理形成《项目总结》；
由技术开发部经理组织对该项目进行绩效考核，并填写相应的《项目绩效考核表》；
项目经理组织所有成员对项目过程中的文档、源程序等资料进行整理、归档；
由项目经理根据过程数据库的需要，整理相应的数据，提交技术开发部经理，存入过程数据库。
相关模板：
《项目总结》、《项目绩效考核表》
3.开发过程规范
开发过程是提炼用户需求，设计、构建和测试满足这些需求的软件并最终将其交付给客户的过程。是软件过程中的主体过程之一。当开发新的应用或计划为现有的应用进行重要的增强时，需使用本规范所定义的开发过程执行。
项目管理过程是对开发过程进行计划、监控/管理、总结的辅助过程，但由于项目管理是保证进度、质量的重要手段，因此在软件项目中也是十分重要的过程之一。而需求管理过程与配置管理过程则是次重要的辅助过程，需求管理过程是一个需求变更管理的过程，以对变更进行统一的管理；配置管理过程的最重要工作就是版本控制，使得开发过程中的各种交付物能够有机地形成一个个整体。
因此以上四个过程是交织进行的，均是为成功完成软件项目的保障过程。
3.1 过程总述
现在比较通行的开发过程模型包括：瀑布模型、演化模型、原型模型、螺旋模型等。根据公司的项目特点、队伍规模、组队情况等实际因素，决定选择最为简单、易于掌握的瀑布模型为基础，根据公司特点，进行合理的修改，使其成为公司本阶段的软件开发过程。
本规范将整个开发过程分为：需求分析、高层设计、详细设计、编码和单元测试、集成计划与测试、系统测试、验收测试与安装、维护等八个阶段。
3.2 需求分析阶段
需求分析的主要目的是生成一个正确说明客户所有需求的文档。换言之，软件需求规格（Software Requirement Specification，SRS）文档是该阶段的主要输出。正确的需求分析和确定需求规格对一个项目的成功是非常关键的。许多在系统和验收测试时发现的缺陷
是在需求阶段产生的。在验收阶段去掉需求阶段产生的一个错误将比在需求阶段本身去掉该错误要多花100多倍的费用。很明显，在执行这阶段时，正确地生成具有最少缺陷的SRS 是非常必要的。
参与人员：项目经理，[分析员]，立项申请人，[客户，最终用户]；
入口准则：项目立项，最初的项目计划已得到立项申请人的确认。
注：这里所说明的需求分析阶段是进行开发过程的需求分析阶段，在技术开发部出具初步的项目计划之前的需求沟通工作，不是该过程规范所定义的。最初的需求沟通工作可以参考本过程规范。
出口准则：立项申请人、[客户]在《软件需求规格说明书》上签字确认；
输入：《项目立项申请表》、最初的《项目计划》，需求相关的资料；
输出：经确认的《软件需求规格说明书》；
活动：整个需求分析过程主要包括以下几个步骤：
首先，项目经理与分析员一块，做好需求分析的准备，包括阅读相关的背景资料，熟悉客户的实际情况，准备用户访谈计划，准备会谈问题清单等；
然后通过面谈、专题讨论会等形式与客户进行沟通，采集需求的详细内容，澄清每一个需求点；从而界定出系统的目标和范围；
对所采集和澄清的需求进行分析，构建需求模型，从功能性、非功能性两个方面进行需求分析，深入领会客户需求；
形成《软件需求规格说明书》，建立软件需求基线，并为软件需求评审做好准备；
由项目经理安排软件需求评审，协同立项申请人、[客户]进行需求评审；
立项申请人[或客户]在《软件需求规格说明书》上确认。
相关模板：
《软件需求规格说明书》
3.3 高层设计阶段
高层设计是软件开发过程中的一个重要阶段，在这个阶段将从计算机实现的逻辑角度开发针对用户需求的解决方案。这一解决方案是一个高级的抽象方案。高层设计要设计出各主要部分，并说明他们在技术上如何工作：1）相互间的协作；2）所需外在的硬件和软件环
境；3）内在环境。也就是说，高层设计确定了组成产品的构件，定义了每个构件的功能任务，并且定义了构件间的接口及构件到运行环境的外部接口。
参与人员：项目经理，项目组员（设计团队）；
入口准则：《软件需求规格说明书》已通过立项申请人的确认；
出口准则：形成高层设计，实现任务分解，所有的问题得到解决；
输入：《软件需求说明书》
输出：《高层设计说明书》（功能与数据库设计）、详细设计、编码、文档和用户接口标准；
活动：
制定详细设计、编码、文档和用户接口的标准；
根据项目特点选择运行的目标平台和开发工具；
制定软件的体系结构，定义逻辑和物理的对象模型，包括确定类、类的属性、类方法、类之间的关系和对象间的动态交互。若采用结构化设计，则该活动应为功能设计；
从需求规格说明书中的数据模型中得到物理数据库结构，进行物理数据库设计：包括确定表/记录类型、域和其他部分。
生成高层设计说明书，并组织设计评审。
相关模板：
《高层设计说明书》
3.4 详细设计阶段
在详细设计阶段，高层设计阶段开发出的整体应用被分成几个模块（或构件）和程序。为每个程序（或构件）进行逻辑设计，然后归档作为程序规格，同时为每个程序（或构件）生成一个单元测试计划。详细设计阶段的重要活动包括通用例程和程序的确定、框架程序的开发以及用于提高生产率的实用程序和工具的开发。
在详细设计阶段负责每个程序、模块（或构件）的内部设计，确定其程序流程，并且可以通过使用设计语言、图形流程图（如活动图、状态图）等，或通过简单地写叙述而将设计文档化。
参与人员：每个模块（或构件）的任务承担人；
入口准则：《高层设计说明书》已通过评审；
出口准则：完成详细设计，所有的问题得到解决，详细设计与单元测试计划文档化；
输入：《软件需求规格说明书》、《高层设计说明书》、详细设计标准
输出：《详细设计说明书》、《单元测试计划》
活动：
将高层设计中的每个程序（或构件）细分成小的组件；
对每个小组件进行详细设计，包括确定调用方法、输入和输出、程序逻辑、数据结构等；
根据组件的逻辑，制定单元测试计划，包括确定单元测试环境、测试用例、测试数据等；
向项目经理（或高层设计者）提交详细设计与单元测试计划；
相关模板：
《详细设计说明书》、《单元测试计划》
剪裁说明：对一些小项目，详细设计阶段的活动1、2可以省略。
3.5 编码和单元测试
在编码子阶段，根据详细设计用编程语言编写所需的程序。这个阶段根据合适的编码规范产生源代码、可执行代码以及数据库（如果使用了数据库）。这个阶段的输出是随后测试和验证的主体。而单元测试子阶段则是根据详细设计阶段所制定出来的单元测试计划进行测试，验证每一个组件正确、可用。
参与人员：每个模块（或构件）的任务承担人；
入口准则：《详细设计说明书》已通过批准，编码规范已建立；
出口准则：成功执行所有单元测试计划中的测试用例；
输入：《软件需求规格说明书》、《高层设计说明书》、《详细设计说明书》、《单元测试计划》编码、用户接口标准；
输出：测试数据、源代码、可执行代码、《单元测试报告》
活动：
根据详细设计，按照编码、用户接口规范编写程序；
对程序进行代码复查、编译、调试，直到程序运行通过，符合详细设计的要求；
根据单元测试计划进行单元测试，生成单元测试报告。
相关模板：
《单元测试报告》
3.6 集成计划与测试
集成是把设计阶段制定的，已通过单元测试的模块构建成一个完整软件结构的系统方法。可采用很多方式进行集成，集成计划必须指定模块集成的顺序。在该阶段，同时进行测试，以发现与接口相关的缺陷。集成按照集成计划中制定的顺序进行，并执行每个集成阶段的相应测试用例。集成计划描述了集成顺序、额外需要的软件、测试环境和资源需求。集成计划与集成测试计划通常一起完成。
参与人员：项目经理，集成团队；
入口准则：经批准的《高层设计说明书》；
出口准则：集成计划和集成测试计划经过评审和授权；
输入：《高层设计说明书》、源程序
输出：《集成计划》、《集成测试计划》
活动：
确定集成所需的环境，包括硬件的物理特性、通信和系统软件、使用模式等；
决定集成规程，确定将要集成的关键模块，集成的顺序，需要测试的接口等；
开发集成测试计划，确定测试用例和执行用例的规程，确定测试数据，确定期望输出等。
相关模板：
《集成计划》、《集成测试计划》
剪裁说明：对一些小项目，集成计划与测试阶段可以省略。
3.7 系统测试
系统测试是依据需求规格验证软件产品有效性的活动。这个阶段是为了发现那些只有通过测试整个系统才能暴露的缺陷。就像外部接口、性能、安全、配置敏感性、共存、恢复以及可靠性等属性只有在这个阶段才能判断其是否有效。可以使用具有不同测试目的的一系列测试来验证所有系统元素都已经正确地集成，系统能够执行所有功能并满足所有非功能需求。系统测试开始之前，必须在系统测试计划阶段详细地制定计划。
系统测试计划工作从需求分析结束后就可以开始，一直到编码时结束。
参与人员：项目经理，系统测试团队；
入口准则：经确认的《软件需求规格说明书》和经批准的《高层设计说明书》；
出口准则：系统测试计划经过评审和授权，成功执行所有系统测试计划中的测试用例；；
输入：《软件需求规格说明书》、《高层设计说明书》
输出：《系统测试计划》、《系统测试报告》
活动：
决定所需的测试环境；
决定系统测试的规程，包括：确定测试特性，如用户接口、软硬件接口、通信接口、主要业务过程；确定不需要测试的重要特性以及不测试的原因；确定关键测试；
开发测试用例，包括确定每个测试用例以及执行它的规程，确定每个输入、输出数据的要求，确定预期的结果。
相关模板：
《系统测试计划》、《系统测试报告》
剪裁说明：对一些小项目，系统测试阶段可以省略，直接准备验收测试，在验收测试之前，开发组队按验收测试计划做一次没有立项申请人、[客户]参加的预测试。
3.8 验收测试与安装
验收测试和安装阶段的主要任务是将软件产品集成到它的操作环境中，并在这个环境中经受测试，以确保它按需求执行。这个阶段包括两个基本任务：使软件得以验收和客户处安装软件。验收指的是由立项申请人、[客户]根据早期准备的《验收报告》而进行正式的测试，并对测试结果进行分析，以确定系统是否满足验收准则。当分析结果满足验收测试时，用户接受软件。安装指的是把接受的软件置于实际产品环境中。
注：《验收报告》应附有验收测试计划
参与人员：项目经理，安装团队、立项申请人、[客户]；
入口准则：成功地完成了系统测试（或成功地完成了验收预测试）；
出口准则：立项申请人或客户在《验收报告》上签署确认意见；
输入：《软件需求说明书》、测试后的软件和《验收报告》
输出：签署了确认意见的《验收报告》和安装后的软件；
活动：
根据《软件需求说明书》，编写验收报告；
与立项申请人、[客户]一起按《验收报告》执行验收测试，包括：在验收环境下安装软件、进行实况运行、协助客户进行验收测试、改正验收缺陷、更新文档以反映所有变更、获得客户的验收确认；
执行安装，包括：在产品环境下安装软件、搭建产品环境、载入软件和数据、进行实况运行、修改安装缺陷、执行用户培训。
相关模板：
《验收报告》
3.9 维护
维护支持阶段是指已安装的应用得到支持，直至其在生产环境中稳定运行的阶段。
参与人员：项目经理，系统安装人员；
入口准则：软件在生产中运行；
出口准则：合同中指定的维护支持阶段终止；
输入：安装后的应用、用户文档和《软件维护申请表》；
4.需求变更管理过程规范
需求变更，这是个永恒的真理。需求变更的一个重要原因是系统周围的世界在变化，从而要求系统适应这个变化。在项目生命周期的任何时候或者项目结束之后都可以有需求变更。与其希望变更不会来临，不如希望初始的需求在某种程度上做得很好而使得没有变更需求，最好是项目准备时想到对付这些变更，以防变更真的到来。不管做多少准备和计划都不可能阻止变更，说项目在需求冻结后再开始不过是个神话罢了。
4.1 过程总述
需求变更管理过程定义了一系列活动，当有新的需求或对现有需求进行变更（我们可以称它们都是需求变更）时就会执行这些活动。需求变更可以在项目执行的任何一个点上发生。需求变更会影响项目进度，甚至会影响已经生产出来的产品。越是在生命周期后期的需求变更，对项目的影响越严重。不可控的需求变更导致对成本、进度以及项目质量的负面影响，这些极可能严重危害项目成功的概念。
需求变更管理过程用来控制需求变更并减少他们对项目的影响。这个目标需要理解需求变更请求的隐含意义，以及变更带来的总影响。同样，也需要立项申请人、[客户]意识到变更对项目影响的后果，使得可以友好地将变更反映到协商好的条款中。需求变更管理过程，从某种程序上说，试图保证在需求变更影响下项目依然可以成功。
需求变更管理有两个方面，一方面与立项申请人、[客户]就怎样处理变更达成一致，一方面是实际进行变更的过程。处理变更的整体方法必须与立项申请人、[客户]达成一致。一般来说，它制定怎样进行变更请求，当需要正式的批准时，为处理变更估计留出冗余空间等等。在整个方法的背景下，当需求变更到来时，需要执行需求变更管理过程。
4.2 过程规范
参与人员：项目经理，立项申请人、[客户]、开发团队；
注：项目经理对将变更纳入项目中所需的过程执行负主要责任。立项申请人、[客户]以及开发队伍也需要参与这个过程。
入口准则：收到立项申请人提交的《需求变更请求单》
出口准则：变更已列入新的《软件需求说明书》，并体现在新的《软件项目计划中》；
输入：《需求变更请求单》
输出：根据《需求变更请求单》，在充分协商与的基础上，提交新的《软件需求说明书》，并提交《软件项目计划变更表》；
活动：
记录需求变更请求，记录项中应包括变更请求数、变更的简要描述、变更的影响、变更请求的状态和关键数据；
分析变更请求对工作的影响；
估计变更请求需要的工作量；
修改项目计划，重新估计交付时间；
对总的成本花费的影响进行估计；
将修改过的项目计划提交立项申请人，并获得确认。
相关模板：
《项目计划变更表》
5. 配置管理过程规范
软件项目在其执行过程会产生大量的工件，包括各种文档、程序、数据和手册。所有这些工件都是易于改变的。这是软件一个独有的特点。正如“需求变更管理”章节中所述，在软件项目中，在项目执行过程中的任何时候，需求本身都会发生变更。为避免项目在变更时失控，正确控制和管理变更是很必要的。配置管理（Configuration Management，CM）又称为软件配置管理，是项目管理中专用于关注系统地控制项目进行中发生的变更的那些部分，由用来识别机构软件产品并控制其修改的一系统活动构成。
配置管理需要满足项目基本目标之一：为客户提交高质量的软件产品。这个提交的产品，包括各种资源以及构成资源或目标代码的目标文件，还包括以这些文件来构建工作系统的脚本以及相关文档。在项目中，资源和文档通常以很多独立文件的方式来维护。
当项目进展时，文件发生了改变，产生了不同的版本。在种情况下，即使将项目的各部分组合起来，构建成系统，也是很困难的任务，怎样保证合并的是源程序的正确版本以及没有遗漏任何源程序？还有，怎样保证传送的文档的版本是正确的，该版本和最终交付的软件是一致？对于这类型的情况，必须正确跟踪软件开发过程中的各种中间产品、其版本以及软件产品的版本。没有这些信息，交付最终系统就成为繁重的任务。这个活动不是由开发过程完成的，而需要一个独立的过程，那就是配置管理过程。
5.1 配置管理的目标
配置管理过程，需要达到以下目标：
能够随时给出程序的最新版本；
能够处理并发的文档、程序的更新/修改请求；
能够根据需要撤消程序的修改；
能够有效防止未授权的程序员对文档、程序进行变更或删除；
能够有效地显示变更的情况。
5.2 配置管理过程规范
配置管理过程包括两个主要阶段：配置管理计划、实施配置管理。
5.2.1 配置管理计划
参与人员：项目经理，配置管理团队；
入口准则：《软件需求规格说明书》已经确认；
出口准则：完成项目配置管理计划；
输入：《软件需求规格说明书》
输出：《配置管理计划》
活动：
识别配置项，配置项的典型例子包括需求规格、设计文档、源代码、测试计划、测试脚本、测试规程、测试数据、项目使用的编码、用户接口规范、验收报告等；
定义为配置项命名和编号的计划：如果使用CM工具，那么有时由工具处理版本编号，否则，在项目中必须明确地进行版本编号；
定义CM所需的目录结构；
定义访问控制；
定义变更控制规程；
确定CM工作人员的责任和权利；
定义跟踪配置项状态的方法；
定义备份制度
定义发布制度；
确定将配置项转移到基线的原则。
相关模板：
《软件配置管理计划》
5.2.2 实施配置管理
参与人员：项目经理，配置管理团队、开发项目组队成员；
入口准则：《软件配置管理计划》已批准，项目开始；
出口准则：项目结束；
输入：《软件配置管理计划》
活动：
接受变更请求；
Check out需要变更、修改的配置项，并进行修改；
Check in变更、修改过的配置项。
6. 附件
附件包括各种文档模板与工作指南。所有附件以单独的文档形式存储，文档名为xxxx 模板、xxxx工作指南。具体包括：
6.1 文档模板
6.1.1 项目管理类
《软件项目计划模板》、《工作任务卡模板》、《时间日志模板》、《缺陷日志模板》、《项目进度周报模板》、《项目总结模板》、《项目绩效考核表模板》、《项目计划变更表模板》、《软件配置管理计划》
6.1.2 开发过程类
《软件需求规格说明书模板》、《高层设计说明书模板》、《详细设计说明书模板》、《单元测试计划模板》、《单元测试报告模板》、《集成计划模板》、《集成测试计划模板》、《集成测试报告模板》、《系统测试计划模板》、《系统测试报告模板》、《验收测试报告模板》。
6.2 工作指南
《软件需求分析工作指南》、《软件项目计划工作指南》、《软件需求管理工作指南》、《软件配置管理工作指南》
案例-某公司软件过程规范示例
编者说明： 软件过程管理中的一个很重要的工作就是制定项目、组织的过程规范，它是软件开发组织行动的准则与指南。该文档就是一个实际的过程规范的实例，通过该实例，相信对大家根据自身情况制定符合要求的项目过程规范、组织过程规范有很好的借鉴作用。 1.总则 最大限度提高Q&P（质量与生产率），提高Q&P的可预见性，是每一个软件开发机构的最大目标。而Q&P依赖于三个因素：过程、人和技术，因此要实现Q&P的提高，除了加强技术能力，引进、培育更多优质技术人才之外，规范、改进机构的过程是一个十分重要的手段。我们希望通过在制定软件过程规范标准，并在软件开发实践中不断地完善、修订，提高Q&P和Q&P的可预见性。 本规范采用CMM（软件过程成熟度模型）的指导，吸收RUP、XP、MSF、PSP、TSP 等过程规范指南的思想、方法及实践，充分结合xxx技术开发部的实际情况，引入先进的技术、方法、工具，为公司的软件开发工作提供一部详细、可操作的过程指南。在本规范的第一版本中，主要包括管理过程和开发过程两个部分，管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。 2.项目管理过程规范 项目管理过程是对软件项目过程进行计划、监控/管理、总结的辅助过程，包括需求、配置、成本、进度、质量和风险等的管理。项目管理过程主要包括三个阶段：项目立项与计划、项目实施、项目关闭。 2.1 项目立项与计划 参与人员：技术开发部指定的项目负责人（包括前期负责人、正式的项目经理）、立项申请人、[相关最终客户]以及实施该项目的开发组队成员； 入口准则：接到经公司总经理或副总经理批准的市场部门的《软件开发立项申请表》；
软件过程规范模板
软件过程规范模板 1. 总则 最大限度提高Q&P （质量与生产率），提高Q&P的可预见性，是每一个软件开发机构的最大目标。而Q&P 依赖于三个因素：过程、人和技术，因此要实现Q&P 的提高，除了加强技术能力，引进、培育更多优质技术人才之外，规范、改进机构的过程是一个十分重要的手段。我们希望通过在制定软件过程规范标准，并在软件开发实践中不断地完善、修订，提高Q&P 和Q&P 的可预见性。 本规范采用CMM （软件过程成熟度模型）的指导，吸收RUP、XP、MSF、 PSP、TSP等过程规范指南的思想、方法及实践，充分结合xxx技术开发部的实际情况， 引入先进的技术、方法、工具，为公司的软件开发工作提供一部详细、可操作的过程指南。在本规范的第一版本中，主要包括管理过程和开发过程两个部分，管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。 2. 项目管理过程规范 项目管理过程主要包括三个阶段：项目立项与计划、项目实施、项目关闭。 2.1 项目立项与计划 参与人员：技术开发部指定的项目负责人（包括前期负责人、正式的项目经理）、立项申请人、［相关最终客户］以及实施该项目的开发组队成员； 入口准则：接到经公司总经理或副总经理批准的市场部门的《软件开发立项申请表》； 出口准则：立项申请人签字确认了经修订正后的正式《软件项目计划》，并 通过《工作任务卡》下达了开发任务，开发工作正式开始；输入：经审批 的《软件开发立项申请表》、与需求相关的业务资料；输出：《软件项目 计划》、《软件需求规格说明书》、《开发任务卡》；活动：
软件开发过程详解
软件开发过程详解 软件开发过程即软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。 生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件开发过程覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。 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
4+1模型案例
案例教学1：4+1视图方法进行软件体系结构设计 要开发出用户满意的软件并不是件容易的事，软件体系结构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。本文从理解需求种类的复杂性谈起，通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行体系结构设计，从而确保重要的需求一一被满足。 1、呼唤体系结构设计的多重视图方法 灵感一闪，就想出了把大象放进冰箱的办法，这自然好。但希望每个体系结构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。 需要体系结构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。以工程领域的例子开道吧。比如设计一座跨江大桥：我们会考虑"连接南北的公路交通"这个"功能需求"，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及"大桥的使用期质量属性"，比如为了"能在湍急的江流中保持稳固"，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，"建造期间的质量属性"也很值得考虑，比如在大桥的设计过程中考虑"施工方便性"的一些措施。 和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所示。
图1 软件需求分类的复杂性 2、超市系统案例：理解需求种类的复杂性 例子是最好的老师。为了更好地理解软件需求种类的复杂性，我们来分析一个实际的例子。在表1中，我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。
软件过程规范
1.总则 最大限度提高Q&P （质量与生产率），提高Q&P的可预见性，是每一个软件开发机构的最大目标。而Q&P依赖于三个因素：过程、人和技术，因此要实现Q&P的提高， 除了加强技术能力，引进、培育更多优质技术人才之外，规范、改进机构的过程是一个十分重要的手段。我们希望通过在制定软件过程规范标准，并在软件开发实践中不断地完善、修订，提高Q&P和Q&P的可预见性。 本规范采用CMM （软件过程成熟度模型）的指导，吸收RUP、XP、MSF、PSP、TSP 等过程规范指南的思想、方法及实践，充分结合xxx技术开发部的实际情况，引入先 进的技术、方法、工具，为公司的软件开发工作提供一部详细、可操作的过程指南。 在本规范的第一版本中，主要包括管理过程和开发过程两个部分，管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。 2.项目管理过程规范项目管理过程主要包括三个阶段：项目立项与计划、项目实施、项目关闭 2.1项目立项与计划参与人员：技术开发部指定的项目负责人（包括前期负责人、正式的项目经理）、立项申请人、［相关最终客户］以及实施该项目的开发组队成员； 入口准则：接到经公司总经理或副总经理批准的市场部门的《软件开发立项申请表》； 出口准则：立项申请人签字确认了经修订正后的正式《软件项目计划》，并通过《工作任务卡》下达了开发任务，开发工作正式开始； 输入：经审批的《软件开发立项申请表》、与需求相关的业务资料；输出：《软件项目计划》、《软件需求规格说明书》、《开发任务卡》； 活动： 1.接到《软件开发立项申请表》后，技术开发部经理指定前期负责人，并告知立项申请人； 2.前期负责人阅读《软件开发立项申请表》后，通过与立项申请人的沟通、阅读立项申请人提交的材料、通过立项申请人与客户直接交流等方式，了解项目目标、范围与基本需求；并形成最初的《软件需求规格说明书》； 3.前期负责人会同技术开发部经理以及其它相关人员，制定最初的《软件项目计划》，并组织评审； 4.向立项申请人提交最初的《软件项目计划》； 5.最初的《软件项目计划》通过立项申请人的确认后，项目经理计划安排需求分析; 6.需求分析完成后，形成正式的《软件需求说明书》，提交立项申请人确认；（需求分析过程参见开发过程规范部分）
嵌入式Linux应用软件开发流程
从软件工程的角度来说，嵌入式应用软件也有一定的生命周期，如要进行需求分析、系统设计、代码编写、调试和维护等工作，软件工程的许多理论对它也是适用的。 但和其他通用软件相比，它的开发有许多独特之处： ·在需求分析时，必须考虑硬件性能的影响，具体功能必须考虑由何种硬件实现。 ·在系统设计阶段，重点考虑的是任务的划分及其接口，而不是模块的划分。模块划分则放在了任务的设计阶段。 ·在调试时采用交叉调试方式。 ·软件调试完毕固化到嵌入式系统中后，它的后期维护工作较少。 下面主要介绍分析和设计阶段的步骤与原则： 1、需求分析 对需求加以分析产生需求说明，需求说明过程给出系统功能需求，它包括：·系统所有实现的功能 ·系统的输入、输出 ·系统的外部接口需求（如用户界面） ·它的性能以及诸如文件/数据库安全等其他要求 在实时系统中，常用状态变迁图来描述系统。在设计状态图时，应对系统运行过程进行详细考虑，尽量在状态图中列出所有系统状态，包括许多用户无需知道的内部状态，对许多异常也应有相应处理。 此外，应清楚地说明人机接口，即操作员与系统间地相互作用。对于比较复杂地系统，形成一本操作手册是必要的，为用户提供使用该系统的操作步骤。为使系统说明更清楚，可以将状态变迁图与操作手册脚本结合起来。
在对需求进行分析，了解系统所要实现的功能的基础上，系统开发选用何种硬件、软件平台就可以确定了。 对于硬件平台，要考虑的是微处理器的处理速度、内存空间的大小、外部扩展设备是否满足功能要求等。如微处理器对外部事件的响应速度是否满足系统的实时性要求，它的稳定性如何，内存空间是否满足操作系统及应用软件的运行要求，对于要求网络功能的系统，是否扩展有以太网接口等。 对于软件平台而言，操作系统是否支持实时性及支持的程度、对多任务的管理能力是否支持前面选中的微处理器、网络功能是否满足系统要求以及开发环境是否完善等都是必须考虑的。 当然，不管选用何种软硬件平台，成本因素都是要考虑的，嵌入式Linux 正是在这方面具有突出的优势。 2、任务和模块划分 在进行需求分析和明确系统功能后，就可以对系统进行任务划分。任务是代码运行的一个映象，是无限循环的一段代码。从系统的角度来看，任务是嵌入式系统中竞争系统资源的最小运行单元，任务可以使用或等待CPU、I/O设备和内存空间等系统资源。 在设计一个较为复杂的多任务应用系统时，进行合理的任务划分对系统的运行效率、实时性和吞吐量影响都极大。任务分解过细会不断地在各任务之间切换，而任务之间的通信量也会很大，这样将会大大地增加系统的开销，影响系统的效率。而任务分解过粗、不够彻底又会造成原本可以并行的操作只能按顺序串行执行，从而影响系统的吞吐量。为了达到系统效率和吞吐量之间的平衡折中，在划分任务时应在数据流图的基础上，遵循下列步骤和原则：
软件工程案例分析
一、 阅读下列系统需求陈述，回答问题1、问题2、问题3和问题4。 某银行准备开发一个网上信用卡管理系统CCMS，该系统的基本功能为： （1）信用卡申请。非信用卡客户填写信用卡申请表，说明所要申请的信用卡类型及申请者的基本信息，提交CCMS登录。如果信用卡申请被银行接受，客户会收到银行的确认函，并告知用户信用卡的有效期及信贷限额；否则银行会发送一封拒绝函给该客户。客户收到确认函后，需再次登录CCMS ，用信用卡号和密码激活该信用卡。激活操作结束后，CCMS将激活通知发送给客户，告知客户其信用卡是否被成功地激活。 （2）月报表生成。在每个月第一天的零点，CCMS为每个信用卡客户创建一份月报表，对该客户上月的信用卡交易情况及交易额进行统计。信用卡客户可以登录CCMS查看月报表，也可以要求CCMS提供打印出的月报表。 （3）信用卡客户信息管理。信用卡客户的个人信息可以在 CCMS中进行在线的管理。每个信用卡客户可以在线查询其个人信息。 （4）信用卡交易记录。信用卡客户使用信息卡进行的每一笔交易都会记录在CCMS中。 （5）交易信息查询。信用卡客户可以登录CCMS查询并核实其信用卡交易记录及交易额。在系统的需求分析阶段，使用用例对系统需求建模。表1—1和表1—2给出了其中两个用例的概要描述。 ［问题1］） 将表1—1和表1—2中的（1）~（10）填充完整。 ［问题2］ 除了表1—1和表1—2给出的用例外，从上述系统陈述中还可以获取哪些由信用卡客户发起的用例？（给出用例名称即可）
［问题3］ 用400字以内文字，简要说明用例获取的基本步骤。 ［问题4］ 用例除了使用表1—1和表1—2所示的形式描述外，还可以使用UML的用例图来表示。分别用50字以内文字，解释UML用例图中扩展用例和抽象用例的内涵。 二、 阅读以下关于工作流系统性能分析的叙述，回答问题1、问题2和问题3。 某企业正在创建一个工作流管理系统，目前正处于过程定义阶段，即创建工作流模型阶段。对于这些工作流模型，除了要考虑工作流的正确性外，工作流的性能也是十分重要的。工作流性能主要反映工作流定量方面的特性，例如，任务的完成时间、单位时间内处理的任务数量、资源的利用率以及在预定的标准时间内完成任务的百分比等等。 图2—1所示的是一个简单的工作流模型（其中单位时间为1小时），它表示这样一个执行过程：每小时将会有20个任务达到c1，这20个任务首先经过处理taskl，再经过处理task2，最终将结果传递到c3。处理taskl和处理task2相互独立。 图2-1 假设性能评价模型符合M/M/1排队模型，在计算性能指标的过程中可以使用下列公式进行计 算：,其中ρ表示资源利用率，表示单位时间内到达的任务数，表示该资源单位时间内能够完成的任务数。 ［问题1］ 计算图2—1所示的工作流模型的下列性能指标： （1）每个资源的利用率； （2）每个处理中的平均任务数L； （3）平均系统时间S； （4）每个处理的平均等待时间W。 ［问题2］
软件开发过程规范
软件开发过程规范 1．目的 为了规范软件开发各个阶段的开发行为，特制定此规范。2．适用范围 本规范适用于软件产品开发从立项，到开发实施、测试、结项的各个阶段，规定了各开发阶段的文档编制、代码编写和资料备份内容与要求。 3．术语和缩写 开发项目干系人：公司内部与开发项目有关联的任何人。 项目计划周期：从项目立项到计划完成时间的实际工作日数。 项目实际周期：从项目立项到实际完成时间的实际工作日数。 项目质量目标：项目允许出现的总的缺陷数的加权平均值。 项目实际质量：项目实际出现的总的缺陷数的加权平均值。 软件缺陷：在测试过程中被发现的软件bug，按照不同的严重程度分为四级： 一级，系统崩溃，无法自动恢复，加权系数为100。
?二级，系统功能无法实现或性能指标无法达到，但不影响其 他功能的使用，加权系数为2。 ?三级，系统功能实现不完整，加权系数为1。 ?四级，不影响系统功能和性能的小错误，忽略此错误系统可 正常运行，加权系数为0.5。 加权缺陷数量：测试中出现的各种缺陷的数量乘以其对应的加权系数，求和。 4．内容和要求 4.1开发立项 4.1.1立项申请，产品开发经过申请后才能立项，立项申请人可以是公司员工，也可以是公司各职能部门。 4.1.2立项申请人或委托其部门负责人召集相关人员讨论通过，确定项目经理并初步确定项目组成员。 4.1.2.1《开发立项申请书》由项目经理负责编制。 4.1.2.2项目编号规则为，软件项目：CS+编制日期。 4.1.2.3《开发立项申请书》要规定开发的产品的具体名称，以及所属各个系列的规格型号定义。
4.1.2.4《开发立项申请书》规定开发的产品的属性，包括功能详细描述，性能要求详细描述和稳定性要求详细描述。 4.1.2.5《开发立项申请书》明确项目经理和项目组成员。 4.1.2.6《开发立项申请书》明确项目的开始日期和计划完成日期。 4.1.2.7《开发立项申请书》概要说明项目开发的资源需求，包括硬件设备、软件工具、场地环境等。 4.1.2.8《开发立项申请书》确定项目的质量目标，包括各级缺陷的数量和测试周期，所制定的质量目标不允许有一级缺陷。 4.1.2.9《开发立项申请书》的编制格式参照《开发立项申请书模板》。 4.1.3《开发立项申请书》由开发项目经理、开发部经理、技术部经理认可，总经理最终确认。 4.1.4内容变更：开发项目干系人可对申请对《开发立项申请书》的内容进行变更，变更后按申请的流程进行签字确认，变更后的内容重新填写《开发立项申请书》并附在原申请书后。项目组成员的变更由开发内部掌握，不必进行变更申请。变更可在结项前的任何阶段提出。
软件开发过程概述
第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）质量评价：一般地，根据度量综合指标值，有以下评分标准。 质量评价计分标准表 序号得分质量评价
软件过程规范
1.总则 最大限度提高Q&P（质量与生产率），提高Q&P的可预见性，是每一个软件开发机构的最大目标。而Q&P 依赖于三个因素：过程、人和技术，因此要实现Q&P 的提高，除了加强技术能力，引进、培育更多优质技术人才之外，规范、改进机构的过程是一个十分重要的手段。我们希望通过在制定软件过程规范标准，并在软件开发实践中不断地完善、修订，提高Q&P 和Q&P 的可预见性。 本规范采用CMM（软件过程成熟度模型）的指导，吸收RUP、XP、MSF、PSP、TSP等 过程规范指南的思想、方法及实践，充分结合xxx 技术开发部的实际情况，引入先进的技术、方法、工具，为公司的软件开发工作提供一部详细、可操作的过程指南。在本规范的第一版本中，主要包括管理过程和开发过程两个部分，管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。 2.项目管理过程规范 项目管理过程主要包括三个阶段：项目立项与计划、项目实施、项目关闭 2.1项目立项与计划参与人员：技术开发部指定的项目负责人（包括前期负责人、正式的项目经理） 、立 项申请人、[相关最终客户]以及实施该项目的开发组队成员；入口准则：接到经公司总经理或副 总经理批准的市场部门的《软件开发立项申请表》 ； 出口准则：立项申请人签字确认了经修订正后的正式《软件项目计划》，并通过《工作任务卡》下达了开发任务，开发工作正式开始； 输入：经审批的《软件开发立项申请表》、与需求相关的业务资料；输出：《软件项目计划》、《软件需求规格说明书》、《开发任务卡》；活动： 1.接到《软件开发立项申请表》后，技术开发部经理指定前期负责人，并告知立项申请人； 2.前期负责人阅读《软件开发立项申请表》后，通过与立项申请人的沟通、阅读立项申请人提交的材料、通过立项申请人与客户直接交流等方式，了解项目目标、范围与基本需求；并形成最初的《软件需求规格说明书》； 3.前期负责人会同技术开发部经理以及其它相关人员，制定最初的《软件项目计划》，并组织评审； 4.向立项申请人提交最初的《软件项目计划》； 5.最初的《软件项目计划》通过立项申请人的确认后，项目经理计划安排需求分析；
软件开发过程规范
【最新资料,Word版，可自由编辑！】
目录 1.前言 (3) 1.1 目的 (3) 1.2 对象 (3) 1.3 要求 (3) 1.4 适用范围 (3) 1.5 软件开发过程模型 (3) 1.6 开发过程划分 (4) 2.技术过程规范部分 (4) 2.1 概述 (4) 2.2 业务建模阶段 (4) 2.3 需求阶段 (6) 2.4 分析设计阶段 (8) 2.5 实现阶段 (10) 3.管理过程规范部分 (11) 3.1 概述 (11) 3.2 接受项目 (12) 3.3 重新评估项目范围和风险（对于较大项目） (12) 3.4 制定开发计划 (13) 3.5 迭代开发管理 (13) 3.6 监控项目的实施 (14) 3.7 结束项目 (15)
软件开发过程规范 前言 目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。 对象 本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。 要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。
华为软件开发行为规范
软件开发行为规范 第一版 深圳市华为技术有限公司 版权所有不得复制
软件开发行为规范 (第一版） 为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以达到过程控制的目的。 与软件开发相关的所有人员，包括各级经理和工程师都必须遵守本软件开发行为规范。对违反规范的开发行为，必须按照有关管理规定进行处罚。 本软件开发行为规范的内容包括：软件需求分析、软件项目计划、概要设计、详细设计、编码、需求管理、配置管理、软件质量保证、数据度量和分析等。 本软件开发行为规范，采用以下的术语描述： ★规则：在软件开发过程中强制必须遵守的行为规范。 ★建议：软件开发过程中必须加以考虑的行为规范。 ★说明：对此规则或建议进行必要的解释。 ★示例：对此规则或建议从正或反两个方面给出例子。 本软件开发过程行为规范由研究技术管理处负责解释和维护。 研究技术管理处
目录 1 软件需求分析 5 2 软件项目计划9 3 概要设计11 4 详细设计14 5 编码18 6 需求管理19 7 软件配置管理21 8 软件质量保证23 9 数据度量和分析25
1 软件需求分析 1-1：软件需求分析必须在产品需求规格的基础上进行，并保证完全实现产品需求规格的定义。 1-2：当产品的需求规格发生变更时，必须修订软件需求规格文档。软件需求规格的变更必须经过评审，并保存评审记录。 1-3：必须对软件需求规格文档进行正规检视。 1-4：软件需求分析过程活动结束前，必须经过评审，并保存评审记录。 1-5：在对软件需求规格文档的正规检视或评审时，必须检查软件需求规格文档中需求的清晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。 说明：参考建议1-1到1-16。 1-1：采用以下检查表检查软件需求规格文档中需求的清晰性。 1-2：采用以下检查表检查软件需求规格文档中需求的完备性。
软件工程案例教程
第一章 1.下列所述不是软件特点的是（A） A.软件是有形的 B.软件不存在磨损和消耗问题 C.软件开发成本高 D.软件没有明显的制作过程 2.软件工程的出现主要是由于（C） A.程序设计方法学的影响 B.其他工程学科的影响 C.软件危机的出现 D.计算机的发展 3.以下（C）不是软件危机的表现形式 A.开发的软件不满足用户的需要 B.开发的软件可维护性差 C.开发的软件价格便宜 D.开发的软件可靠性差 4.软件工程的目的是（C) A.建造大型的软件系统 B.开发的软件可维护性差 C.软泥吉安质量的保证 D.研究软件开发的远离 5.下列所述不是软件组成的是（D） A.程序 B.数据 C.界面 D.文档 6.下列对“计算机软件”描述正确的是（A） A.是计算机系统的组成部分 B.不能作为商品参加交易 C.是在计算机硬件设备生产过程中生产出来的 D.之存在语计算机系统工作时 7.软件工程的方法的产生源于软件危机，下列（D)是产生软件危机的内在原因 A.软件的复杂性 B.软件维护困难C软件成本太高. D.软件质量难保证 8.软件工程方法的提出源于软件危机，其目的应该是最终解决软件的（D）问题 A.软件危机 B.质量保证 C.开发效率 D.生产工程化 9.软件工程学中除重视软件开发的研究外，另以重要组成内容是软件的（A）和过程改进 A.项目管理 B.成本核算 C.人员培训 D.工具开发 10.软件工程设计软件开发技术和项目管理等方面内容，下述内容中（D)不属于开发技术的范畴 A.软件开发方法 B.软件开发工具 C.软件工程环境 D.软件工程经济
二、填空题 1.软件工程的目的是成功的建造大型的软件系统，主要内容是开打软件开发技术、软件项目管理和软件质量管理。 2.螺旋式开发模型主要是针对风险比较大的项目而设计的 3.由于软件产生的复杂性和高成本，使大型软件产生出了很多问题，即出现软件危机，软件工程正是为了克服它而提出的一种概念及相关方法和技术。 4.增量模型假设需求可以分段，成为一系列增量产品，每一增量可以分别开发。 5.喷泉模型比较适合用于面向对象的开发方法。 三、判断题 1.软件开发方法的主要目的是克服软件手工生产带来的问题，使软件开发能进入工程化和规范化的环境（Y） 2.软件工程的提出起源于软件危机，其目的书最终解决软件的生产工程化（Y） 3.软件工程改进也是软件工程的范畴（Y） 第二章 一、选择题 1.结构化分析方法是面向（B）的自顶向下逐步求精的分析方法。 A.目标 B.数据流C功能. D.对象 2.在进行软件设计时应该遵循的最主要的原理是（C） A.抽象B模块化. C.模块独立D信息屏蔽. 3.在结构化分析方法中，常用的描述软件功能需求的工具是（C） A.业务流程图、处理说明B软件流程图、模块说明. C.数据流程图、数据字典 D.系统流程图、程序编码
软件发布管理流程规范
软件发布管理流程规范 编制： 审核： 日期： 版本： 编号： 密级：
修改历史 第 II 页
目录 1. 目标 (4) 2. 发布流程 (5) 3. 产品实施流程 (6) 第 III 页
1.目标 软件的发布过程，需要形成有序的良性循环。否则，各环节流转中容易发生相互等待、被动接应的局面。无形中，不断增加了沟通成本，扩大了软件的风险。且对后期造成的影响并不能够完全预知、完全估量。 因此，根据公司内部前期已有的习惯，总结过去产品的发布经验，分析统计结果后，特制定本发布过程规范。预期达到如下目的： 1、减少交叉沟通。通过将发布过程流程化，使每一个环节的执行者都非常清楚自己的产入产出，受谁的影响，将影响谁。当遇到困难时，能明确的定位寻找到关键人物沟通解决。避免当需要获取一件事情的进展情况时，需要广泛征询才能掌握的现象。减少交叉沟通成本。 2、提高工作预见性。流程一旦启动，流程中的所有人员便被触动。各环节执行人能迅速在早期预算出自己的“参与时间”、“参与内容”、“参与工作量”，主动提前做出安排、准备，避开人力、时间等资源上的冲突。且一旦发现冲突，便能立刻“报警”，报得越早，越能提前应对，减少损失。
2.发布流程 2.1.发布准备 发布之前，软件由测试人员进行确认测试；检查需求内登记的所有bug都已经被fixed，或者遗留的bug不影响系统的使用，如果有严重bug未解决将不能发布。 2.2.测试负责人及产品部编写产品质量报告进行质量分析和总结。 2.3.资料准备 文档包括需求、设计、测试文档，安装手册、使用手册、产品简介、对外宣传所有资料。 2.4.正式发布通知 正式发布，须通知开发、测试、运营、市场、销售各相关部门并附上产品发布说明和产品介绍；说明本次发布包含或者新增的功能特性说明；遗留问题及影响说明。 2.5.后续工作 产品发布后，在使用过程中可能还会发现一些bug。在不影响正常使用的情况下，这些bug将在系统升级后发布时解决；如果bug严重影响使用，必须提交需求进行系统修复后按照流程重新发布 2.6.临时发布
软件开发过程规范
软件开发过程规范 版本 <1.0> 修订历史纪录
目录 1.前言 (3) 1.1 目的 (3) 1.2 对象 (3) 1.3 要求 (3) 1.4 适用范围 (3) 1.5 软件开发过程模型 (3) 1.6 开发过程划分 (3) 2.技术过程规范部分 (3) 2.1 概述 (3) 2.2 业务建模阶段 (4) 2.3 需求阶段 (5) 2.4 分析设计阶段 (6) 2.5 实现阶段 (7) 3.管理过程规范部分 (7) 3.1 概述 (7) 3.2 接受项目 (8) 3.3 重新评估项目范围和风险（对于较大项目） (8) 3.4 制定开发计划 (8) 3.5 迭代开发管理 (9) 3.6 监控项目的实施 (9) 3.7 结束项目 (10)
软件开发过程规范 1. 前言 1.1 目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。 1.2 对象 本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。 1.3 要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 1.4 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。 1.5 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。 1.6 开发过程划分 开发过程包括多次迭代，每次迭代的目标和侧重点不同；较早的迭代侧重于业务建模和需求建模；而后的迭代则侧重于分析设计和编码。 2. 技术过程规范部分 2.1 概述 本规范中将软件开发的整个技术过程分为四个顺序实施的阶段，分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。在对技术过程规范的描述，按阶段内部的活动和产物对四个阶段分别说明。 在本规范中对阶段内活动的说明，是按顺序性活动和持续性活动两类分别进行说明。对于顺序性活动是按该阶段中活动的总体顺序进行的描述，而在实际工作中，从各活动的具体实施的细节来看，各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的技术活动进行说明。
软件开发流程规范方案
软 件 开 发 流 程 规 范 V1.0 德联软件有限责任公司
编制人：侯秀美审核人：2015 年8 月19 日
目录 目录 0 一、概述 (2) 二、开发流程规范 (3) 2.1 系统软硬件开发环境 (3) 2.2 系统架构（系统组成） (5) 2.3 系统功能模块设计 (6) 2.4 系统功能开发流程图 (6) 2.5 开发修改记录 (7) 三、开发代码规范 (8) 3.1 文件结构 (8) 3.1.1 文件信息声明 (8) 3.1.2 头文件的结构 (10) 3.1.3 定义文件的结构 (11) 3.1.4 头文件的作用 (12) 3.1.5 目录结构 (13) 3.2 命名规则 (13) 3.2.1 共性原则 (13) 3.2.2 Windows变量命名规则 (14) 3.3 程序风格 (17) 3.3.1 空行 (17) 3.3.2 代码行 (18) 3.3.3 代码行内的空格 (19) 3.3.4 对齐 (21) 3.3.5 长行拆分 (22) 3.3.6 修饰符的位置 (23) 3.3.7 注释 (23) 3.4 函数设计 (26) 3.4.1 参数的规则 (26) 3.4.2 返回值的规则 (27) 3.4.3 函数内部实现的规则 (30) 3.4.4 其它建议 (32) 3.4.5 使用断言 (32) 3.4.6 引用与指针的比较 (33) 3.5 变量类型定义 (35) 四、软件测试规范 (36) 4.1 单元测试 (36) 4.2 系统测试 (37) 4.6 业务测试 (38)
4.7 验收测试 (38) 4.8 用户现场测试 (39) 五、软件版本管理 (39) 4.1版本管理的必要性 (39)
软件委托开发流程及相关规范
软件外包流程及相关规范XXXXXXXXX网络科技有限公司
目录 一、外包前的准备工作 (3) 1.1项目负责人的确定 (3) 1.2需求文档的制定 (3) 1.3《软件开发方案》及接包方的确定 (3) 1.4接包方责任人的确定 (4) 二、软件在开发过程中的管理 (4) 2.1软件需求的细化 (4) 2.2开发过程中的管理及协调 (4) 2.3软件需求变动 (4) 三、交付验收过程管理 (5) 3.1软件交付前的内测 (5) 3.2软件交付时的公测 (5) 3.3软件验收交付的内容 (6) 3.4软件的验收 (6) 3.5软件验收报告 (6) 四、交付后的程序及源代码管理 (7) 4.1软件交付后的程序BUG处理 (7) 4.2软件交付后的功能更改 (7) 4.3程序发布及源代码管理 (7)
一、外包前的准备工作 1.1项目负责人的确定 外包项目确定启动前，我方应制定一个专门人员，作为软件外包的项目负责人，全权处理外包项目的所有事务。 1.2需求文档的制定 由项目负责人，对项目软件的使用范围、用户人群定位等进行详细分析，规划出软件的主要功能，同时结合我们现有平台软件，对软件的开发环境、应用环境做出规范要求，以此制定出《软件需求文档》。 《软件需求文档》在经项目组讨论后生效。 《软件需求文档》应包括以下内容： ●项目软件的中英文名称、预计开发周期； ●软件的技术规范，如开发环境、应用环境、数据库标准、数据交换接口等； ●软件的适用范围、主要应用思想； ●主要功能模块及功能详细说明； ●业务基本流程； 1.3《软件开发方案》及接包方的确定 1.《软件需求文档》确定后，根据需求文档预选定接包方； 2.接包方同项目负责人沟通技术细节后，由项目接包方根据需求方案，对开发流程进行细 化，制定《软件开发方案》及相关DEMO； 3.项目负责人根据《软件开发方案》和DEMO确定最终的接包方，双份针对软件开发、 后期应用、源代码交付方式等细节进行磋商，签订《软件开发合同》。 《软件开发方案》中应包括以下内容： ●项目整体的开发进程，应包括开发、测试、验收、交付等关键环节的进度安排； ●软件各模块划分及定义； ●软件开发计划，应包括开发进度安排、详细的工期明细；