软件过程规范
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.需求分析完成后，形成正式的《软件需求说明书》，提交立项申请人确认；（需求分析过程参见开发过程规范部分）
7.根据立项申请人确认后的《软件需求说明书》，项目经理组织进行软件高层设计，并对工作任务进行分解，并根据实际需要向技术开发部经理申请资源，组建项目组队；
8.项目经理根据工作任务分解，下发《工作任务卡》，并协同组队成员进行任务估算；注：工作任务包括模块开发任务、其它任务（如安装）；模块开发任务主要包括：详细设
计、编码和单元测试
9.任务估算完成后，组队成员向项目经理提交《个人进度安排》（以甘特图的形式表示），项目经理根据每个组队成员的《个人进度安排》修订《软件项目计划》（必须包括总的计划甘特图），并提交立项申请人确认；
10.立项申请人确定后，项目经理根据软件项目计划基线，补充《工作任务卡》，下发到每个组队成员，开发工作开始。
项目立项与计划过程的工作流程如下图所示：
图表1项目立项与计划工作流程图
相关模板：
《软件需求规格说明书》、《软件项目计划》、《工作任务卡》
说明：如果计划确认、需求确认未通过，立项申请人与项目经理进行协商，进行修正，无法达成共识的，提交部门经理、总经理协调；
2.2项目实施
参与人员：项目经理，项目组成员；
入口准则：项目计划基线已建立，并通过立项申请人确定，带有工作进度要求的《工作任务卡》已下发到每个项目成员；
出口准则：立项申请人在《验收报告》上签字确认；
输入：《软件需求规格说明书》、《软件项目计划》、《工作任务卡》；
输出：经验收测试的可交付的程序、源代码及相关文档。
活动：
1、在开发期间，项目成员每周需上交一份《时间日志》、《缺陷日志》，每天向项目经理汇报工作任务进度；
2、在开发期间，项目经理负责填写《项目进度周报》报于技术开发部经理、立项申请人（格式不同，交予立项申请人的只需周报的第一页，报予技术开发部经理的项目进度周报的第二页为“跟踪甘特图”）；
3、项目经理必须根据实际的进度情况，及时调整项目计划，若发现进度延误，需采取措施。
相关模板：
《软件项目计划》、《开发任务卡》、《时间日志》、《缺陷日志》、《项目进度周报》2.3项目关闭
参与人员：技术开发部经理或经理助理、项目经理，项目组成员、立项申请人、[相关客户、公司总经理、公司副总经理]；
入口准则：立项申请人在《验收报告》上确认；
出口准则：形成《项目总结》，完成项目绩效考核，项目数据存入“过程数据库”；
输入：《时间日志》、《缺陷日志》、《项目开发计划》；
输出：《项目总结》、已完成的《项目绩效考核表》、过程数据库中的该项目记录；
活动：
1、项目经理主持召开项目总结会，交流项目实施过程中的心得体会，对项目实施中的成功处、不足处进行总结，并由项目经理形成《项目总结》；
2、由技术开发部经理组织对该项目进行绩效考核，并填写相应的《项目绩效考核表》；
3、项目经理组织所有成员对项目过程中的文档、源程序等资料进行整理、归档；
4、由项目经理根据过程数据库的需要，整理相应的数据，提交技术开发部经理，存入过程数据库。
相关模板：
《项目总结》、《项目绩效考核表》
3.开发过程规范
开发过程是提炼用户需求，设计、构建和测试满足这些需求的软件并最终将其交付给客户的过程。是软件过程中的主体过程之一。当开发新的应用或计划为现有的应用进行重要的增强时，需使用本规范所定义的开发过程执行。
项目管理过程是对开发过程进行计划、监控/管理、总结的辅助过程，但由于项目管理是保证进度、质量的重要手段，因此在软件项目中也是十分重要的过程之一。而需求管理过程与配置管理过程则是次重要的辅助过程，需求管理过程是一个需求变更管理的过程，以对变更进行统一的管理；配置管理过程的最重要工作就是版本控制，使得开发过程中的各种交付物能够有机地形成一个个整体。
因此以上四个过程是交织进行的，均是为成功完成软件项目的保障过程。
3.1过程总述
现在比较通行的开发过程模型包括：瀑布模型、演化模型、原型模型、螺旋模型等。根据公司的项目特点、队伍规模、组队情况等实际因素，决定选择最为简单、易于掌握的瀑布模型为基础，根据公司特点，进行合理的修改，使其成为公司本阶段的软件开发过程。
正如下图所示，本规范将整个开发过程分为：需求分析、高层设计、详细设计、编码和单元测试、集成计划与测试、系统测试、验收测试与安装、维护等八个阶段。
图表2开发过程总图
注：SRS：软件需求规格HLD：高层设计DD：详细设计
SRC：代码UT Plan：单元测试计划
注：“归档”在配置管理过程统一说明。
3.2需求分析阶段
需求分析的主要目的是生成一个正确说明客户所有需求的文档。换言之，软件需求规格（Software Requirement Specification，SRS）文档是该阶段的主要输出。正确的需求分析和确定需求规格对一个项目的成功是非常关键的。许多在系统和验收测试时发现的缺陷是在需求阶段产生的。在验收阶段去掉需求阶段产生的一个错误将比在需求阶段本身去掉该错误要多花100多倍的费用。很明显，在执行这阶段时，正确地生成具有最少缺陷的SRS是非常必要的。
参与人员：项目经理，[分析员]，立项申请人，[客户，最终用户]；
入口准则：项目立项，最初的项目计划已得到立项申请人的确认。
注：这里所说明的需求分析阶段是进行开发过程的需求分析阶段，在技术开发部出具初步的项目计划之前的需求沟通工作，不是该过程规范所定义的。最初的需求沟通工作可以参考本过程规范。
出口准则：立项申请人、[客户]在《软件需求规格说明书》上签字确认；
输入：《项目立项申请表》、最初的《项目计划》，需求相关的资料；
输出：经确认的《软件需求规格说明书》；
活动：
整个需求分析过程主要包括以下几个步骤：
图表3需求分析阶段活动总图
1、首先，项目经理与分析员一块，做好需求分析的准备，包括阅读相关的背景资料，熟悉客户的实际情况，准备用户访谈计划，准备会谈问题清单等；
2、然后通过面谈、专题讨论会等形式与客户进行沟通，采集需求的详细内容，澄清每一个需求点；从而界定出系统的目标和范围；
3、对所采集和澄清的需求进行分析，构建需求模型，从功能性、非功能性两个方面进行需求分析，深入领会客户需求；
4、形成《软件需求规格说明书》，建立软件需求基线，并为软件需求评审做好准备；
5、由项目经理安排软件需求评审，协同立项申请人、[客户]进行需求评审；
6、立项申请人[或客户]在《软件需求规格说明书》上确认。
相关模板：
《软件需求规格说明书》
3.3高层设计阶段
高层设计是软件开发过程中的一个重要阶段，在这个阶段将从计算机实现的逻辑角度开发针对用户需求的解决方案。这一解决方案是一个高级的抽象方案。高层设计要设计出各主要部分，并说明他们在技术上如何工作：1）相互间的协作；2）所需外在的硬件和软件环境；3）内在环境。也就是说，高层设计确定了组成产品的构件，定义了每个构件的功能任务，并且定义了构件间的接口及构件到运行环境的外部接口。
参与人员：项目经理，项目组员（设计团队）；
入口准则：《软件需求规格说明书》已通过立项申请人的确认；
出口准则：形成高层设计，实现任务分解，所有的问题得到解决；
输入：《软件需求说明书》
输出：《高层设计说明书》（功能与数据库设计）、详细设计、编码、文档和用户接口标准；
活动：
1、制定详细设计、编码、文档和用户接口的标准；
2、根据项目特点选择运行的目标平台和开发工具；
3、制定软件的体系结构，定义逻辑和物理的对象模型，包括确定类、类的属性、类方法、类之间的关系和对象间的动态交互。若采用结构化设计，则该活动应为功能设计；
4、从需求规格说明书中的数据模型中得到物理数据库结构，进行物理数据库设计：包括确定表/记录类型、域和其他部分。
5、生成高层设计说明书，并组织设计评审。
相关模板：
《高层设计说明书》
3.4详细设计阶段
在详细设计阶段，高层设计阶段开发出的整体应用被分成几个模块（或构件）和程序。为每个程序（或构件）进行逻辑设计，然后归档作为程序规格，同时为每个程序（或构件）生成一个单元测试计划。详细设计阶段的重要活动包括通用例程和程序的确定、框架程序的开发以及用于提高生产率的实用程序和工具的开发。
在详细设计阶段负责每个程序、模块（或构件）的内部设计，确定其程序流程，并且可以通过使用设计语言、图形流程图（如活动图、状态图）等，或通过简单地写叙述而将设计文档化。
参与人员：每个模块（或构件）的任务承担人；
入口准则：《高层设计说明书》已通过评审；
出口准则：完成详细设计，所有的问题得到解决，详细设计与单元测试计划文档化；
输入：《软件需求规格说明书》、《高层设计说明书》、详细设计标准
输出：《详细设计说明书》、《单元测试计划》
活动：
1、将高层设计中的每个程序（或构件）细分成小的组件；
2、对每个小组件进行详细设计，包括确定调用方法、输入和输出、程序逻辑、数据结构等；
3、根据组件的逻辑，制定单元测试计划，包括确定单元测试环境、测试用例、测试数据等；
4、向项目经理（或高层设计者）提交详细设计与单元测试计划；
相关模板：
《详细设计说明书》、《单元测试计划》
剪裁说明：对一些小项目，详细设计阶段的活动1、2可以省略。
3.5编码和单元测试
在编码子阶段，根据详细设计用编程语言编写所需的程序。这个阶段根据合适的编码规范产生源代码、可执行代码以及数据库（如果使用了数据库）。这个阶段的输出是随后测试和验证的主体。而单元测试子阶段则是根据详细设计阶段所制定出来的单元测试计划进行测试，验证每一个组件正确、可用。
参与人员：每个模块（或构件）的任务承担人；
入口准则：《详细设计说明书》已通过批准，编码规范已建立；
出口准则：成功执行所有单元测试计划中的测试用例；
输入：《软件需求规格说明书》、《高层设计说明书》、《详细设计说明书》、《单元测试计划》编码、用户接口标准；
输出：测试数据、源代码、可执行代码、《单元测试报告》
活动：
1、根据详细设计，按照编码、用户接口规范编写程序；
2、对程序进行代码复查、编译、调试，直到程序运行通过，符合详细设计的要求；
3、根据单元测试计划进行单元测试，生成单元测试报告。
相关模板：
《单元测试报告》
3.6集成计划与测试
集成是把设计阶段制定的，已通过单元测试的模块构建成一个完整软件结构的系统方法。可采用很多方式进行集成，集成计划必须指定模块集成的顺序。在该阶段，同时进行测试，以发现与接口相关的缺陷。集成按照集成计划中制定的顺序进行，并执行每个集成阶段的相应测试用例。集成计划描述了集成顺序、额外需要的软件、测试环境和资源需求。集成计划与集成测试计划通常一起完成。
参与人员：项目经理，集成团队；
入口准则：经批准的《高层设计说明书》；
出口准则：集成计划和集成测试计划经过评审和授权；
输入：《高层设计说明书》、源程序
输出：《集成计划》、《集成测试计划》
活动：
1、确定集成所需的环境，包括硬件的物理特性、通信和系统软件、使用模式等；
2、决定集成规程，确定将要集成的关键模块，集成的顺序，需要测试的接口等；
3、开发集成测试计划，确定测试用例和执行用例的规程，确定测试数据，确定期望输出等。
相关模板：
《集成计划》、《集成测试计划》
剪裁说明：对一些小项目，集成计划与测试阶段可以省略。
3.7系统测试
系统测试是依据需求规格验证软件产品有效性的活动。这个阶段是为了发现那些只有通过测试整个系统才能暴露的缺陷。就像外部接口、性能、安全、配置敏感性、共存、恢复以及可靠性等属性只有在这个阶段才能判断其是否有效。可以使用具有不同测试目的的一系列测试来验证所有系统元素都已经正确地集成，系统能够执行所有功能并满足所有非功能需求。系统测试开始之前，必须在系统测试计划阶段详细地制定计划。
系统测试计划工作从需求分析结束后就可以开始，一直到编码时结束。
参与人员：项目经理，系统测试团队；
入口准则：经确认的《软件需求规格说明书》和经批准的《高层设计说明书》；
出口准则：系统测试计划经过评审和授权，成功执行所有系统测试计划中的测试用例；；输入：《软件需求规格说明书》、《高层设计说明书》
输出：《系统测试计划》、《系统测试报告》
活动：
1、决定所需的测试环境；
2、决定系统测试的规程，包括：确定测试特性，如用户接口、软硬件接口、通信接口、主要业务过程；确定不需要测试的重要特性以及不测试的原因；确定关键测试；
3、开发测试用例，包括确定每个测试用例以及执行它的规程，确定每个输入、输出数据的要求，确定预期的结果。
相关模板：
《系统测试计划》、《系统测试报告》
剪裁说明：对一些小项目，系统测试阶段可以省略，直接准备验收测试，在验收测试之前，开发组队按验收测试计划做一次没有立项申请人、[客户]参加的预测试。
3.8验收测试与安装
验收测试和安装阶段的主要任务是将软件产品集成到它的操作环境中，并在这个环境中经受测试，以确保它按需求执行。这个阶段包括两个基本任务：使软件得以验收和客户处安装软件。验收指的是由立项申请人、[客户]根据早期准备的《验收报告》而进行正式的测试，并对测试结果进行分析，以确定系统是否满足验收准则。当分析结果满足验收测试时，用户接受软件。安装指的是把接受的软件置于实际产品环境中。
注：《验收报告》应附有验收测试计划
参与人员：项目经理，安装团队、立项申请人、[客户]；
入口准则：成功地完成了系统测试（或成功地完成了验收预测试）；
出口准则：立项申请人或客户在《验收报告》上签署确认意见；
输入：《软件需求说明书》、测试后的软件和《验收报告》
输出：签署了确认意见的《验收报告》和安装后的软件；
活动：
1、根据《软件需求说明书》，编写验收报告；
2、与立项申请人、[客户]一起按《验收报告》执行验收测试，包括：在验收环境下安装软件、进行实况运行、协助客户进行验收测试、改正验收缺陷、更新文档以反映所有变更、获得客户的验收确认；
3、执行安装，包括：在产品环境下安装软件、搭建产品环境、载入软件和数据、进行实况运行、修改安装缺陷、执行用户培训。
相关模板：
《验收报告》
3.9维护
维护支持阶段是指已安装的应用得到支持，直至其在生产环境中稳定运行的阶段。
参与人员：项目经理，系统安装人员；
入口准则：软件在生产中运行；
出口准则：合同中指定的维护支持阶段终止；
输入：安装后的应用、用户文档和《软件维护申请表》；
4.需求变更管理过程规范
需求变更，这是个永恒的真理。需求变更的一个重要原因是系统周围的世界在变化，从而要求系统适应这个变化。在项目生命周期的任何时候或者项目结束之后都可以有需求变更。与其希望变更不会来临，不如希望初始的需求在某种程度上做得很好而使得没有变更需求，最好是项目准备时想到对付这些变更，以防变更真的到来。不管做多少准备和计划都不可能阻止变更，说项目在需求冻结后再开始不过是个神话罢了。
4.1过程总述
需求变更管理过程定义了一系列活动，当有新的需求或对现有需求进行变更（我们可以称它们都是需求变更）时就会执行这些活动。需求变更可以在项目执行的任何一个点上发生。需求变更会影响项目进度，甚至会影响已经生产出来的产品。越是在生命周期后期的需求变更，对项目的影响越严重。不可控的需求变更导致对成本、进度以及项目质量的负面影响，这些极可能严重危害项目成功的概念。
需求变更管理过程用来控制需求变更并减少他们对项目的影响。这个目标需要理解需求变更请求的隐含意义，以及变更带来的总影响。同样，也需要立项申请人、[客户]意识到变更对项目影响的后果，使得可以友好地将变更反映到协商好的条款中。需求变更管理过程，从某种程序上说，试图保证在需求变更影响下项目依然可以成功。
需求变更管理有两个方面，一方面与立项申请人、[客户]就怎样处理变更达成一致，一方面是实际进行变更的过程。处理变更的整体方法必须与立项申请人、[客户]达成一致。一般来说，它制定怎样进行变更请求，当需要正式的批准时，为处理变更估计留出冗余空间等等。在整个方法的背景下，当需求变更到来时，需要执行需求变更管理过程。
4.2过程规范
参与人员：项目经理，立项申请人、[客户]、开发团队；
注：项目经理对将变更纳入项目中所需的过程执行负主要责任。立项申请人、[客户]以及开发队伍也需要参与这个过程。
入口准则：收到立项申请人提交的《需求变更请求单》
出口准则：变更已列入新的《软件需求说明书》，并体现在新的《软件项目计划中》；输入：《需求变更请求单》
输出：根据《需求变更请求单》，在充分协商与的基础上，提交新的《软件需求说明书》，并提交《软件项目计划变更表》；
活动：
1、记录需求变更请求，记录项中应包括变更请求数、变更的简要描述、变更的影响、变更请求的状态和关键数据；
2、分析变更请求对工作的影响；
3、估计变更请求需要的工作量；
4、修改项目计划，重新估计交付时间；
5、对总的成本花费的影响进行估计；
6、将修改过的项目计划提交立项申请人，并获得确认。
相关模板：
《项目计划变更表》
5.配置管理过程规范
软件项目在其执行过程会产生大量的工件，包括各种文档、程序、数据和手册。所有这些工件都是易于改变的。这是软件一个独有的特点。正如“需求变更管理”章节中所述，在软件项目中，在项目执行过程中的任何时候，需求本身都会发生变更。为避免项目在变更时失控，正确控制和管理变更是很必要的。配置管理（Configuration Management，CM）又称为软件配置管理，是项目管理中专用于关注系统地控制项目进行中发生的变更的那些部分，由用来识别机构软件产品并控制其修改的一系统活动构成。
配置管理需要满足项目基本目标之一：为客户提交高质量的软件产品。这个提交的产品，包括各种资源以及构成资源或目标代码的目标文件，还包括以这些文件来构建工作系统的脚本以及相关文档。在项目中，资源和文档通常以很多独立文件的方式来维护。
当项目进展时，文件发生了改变，产生了不同的版本。在种情况下，即使将项目的各部分组合起来，构建成系统，也是很困难的任务，怎样保证合并的是源程序的正确版本以及没有遗漏任何源程序？还有，怎样保证传送的文档的版本是正确的，该版本和最终交付的软件是一致？对于这类型的情况，必须正确跟踪软件开发过程中的各种中间产品、其版本以及软件产品的版本。没有这些信息，交付最终系统就成为繁重的任务。这个活动不是由开发过程完成的，而需要一个独立的过程，那就是配置管理过程。
5.1配置管理的目标
配置管理过程，需要达到以下目标：
1）能够随时给出程序的最新版本；
2）能够处理并发的文档、程序的更新/修改请求；
3）能够根据需要撤消程序的修改；
4）能够有效防止未授权的程序员对文档、程序进行变更或删除；
5）能够有效地显示变更的情况。
5.2配置管理过程规范
配置管理过程包括两个主要阶段：配置管理计划、实施配置管理。
5.2.1配置管理计划
参与人员：项目经理，配置管理团队；
入口准则：《软件需求规格说明书》已经确认；
出口准则：完成项目配置管理计划；
输入：《软件需求规格说明书》
输出：《配置管理计划》
活动：
1、识别配置项，配置项的典型例子包括需求规格、设计文档、源代码、测试计划、测试脚本、测试规程、测试数据、项目使用的编码、用户接口规范、验收报告等；
2、定义为配置项命名和编号的计划：如果使用CM工具，那么有时由工具处理版本编号，否则，在项目中必须明确地进行版本编号；
3、定义CM所需的目录结构；
4、定义访问控制；
5、定义变更控制规程；
6、确定CM工作人员的责任和权利；
7、定义跟踪配置项状态的方法；
8、定义备份制度
9、定义发布制度；
10、确定将配置项转移到基线的原则。
相关模板：
《软件配置管理计划》
5.2.2实施配置管理
参与人员：项目经理，配置管理团队、开发项目组队成员；
入口准则：《软件配置管理计划》已批准，项目开始；
出口准则：项目结束；
输入：《软件配置管理计划》
活动：
1、接受变更请求；
2、Check out需要变更、修改的配置项，并进行修改；
3、Check in变更、修改过的配置项。
6.附件
附件包括各种文档模板与工作指南。所有附件以单独的文档形式存储，文档名为xxxx模板、xxxx工作指南。具体包括：
6.1文档模板
6.1.1项目管理类
《软件项目计划模板》、《工作任务卡模板》、《时间日志模板》、《缺陷日志模板》、《项目进度周报模板》、《项目总结模板》、《项目绩效考核表模板》、《项目计划变更表模板》、《软件配置管理计划》
6.1.2开发过程类
《软件需求规格说明书模板》、《高层设计说明书模板》、《详细设计说明书模板》、《单元测试计划模板》、《单元测试报告模板》、《集成计划模板》、《集成测试计划模板》、《集成测试报告模板》、《系统测试计划模板》、《系统测试报告模板》、《验收测试报告模板》。
6.2工作指南
《软件需求分析工作指南》、《软件项目计划工作指南》、《软件需求管理工作指南》、《软件配置管理工作指南》
网站定量评估的度量指标
度量指标描述获得方法评估注意事项
点击数访问服务器上某个文件的请求日志文件目前该指标的有效性大大降低，因为一个页面可能伪造成多个点击。
页面访问次数访问服务器上一个HTML页面的请求日志文件注意主机、代理服务器和缓
存可能会误报页面访问次数
唯一用户数有不同IP地址或Cookie的用户日志文件/数据库分析动态分配IP会导致统一数大于实际数，而代理服务器会导致统一数小于实际数
用户会话数与网站连接的时间超过30分钟而且没有中断的对话日志文件可以在网络服务器上设定超时时间，默认设置为30分中。然而通过修改这个设置，使采集的结果产生偏差
用户会话平均的用户会话长度日志文件由于多个用户共享一台计算机或由于使用代理服务器上网，因此很难判断一个用户产生了会话，期间他离开了，而由另一个用户接替这个会话
访问网站的顶级路径当用户访问网站时，大多数人访问页面的顺序日志文件如果使用框架的话，可能会到“无人访问的结果”
进入和离开页面大多数用户进入或离开网站的页面日志文件有助于了解用户是否从外部的链接进入网站，或从一个标签页进入，而非从网站主要进入
与其它网站互相链接的点击数常常用来测量广告链条的情况日志文件(广告服务器)用来评测一个广告条的吸引力，不能用来评测品牌的知名度或链接的效果
涉及网站联系最紧密的网站日志文件用来了解网站最主要的流量从哪里来
繁忙时间段网站网络服务器使用率最高的时刻日志文件用于计划网站升级和对网络进行维护、管理的依据
客户/服务错误类别客户或服务器产生错误的详细情况日志文件很多错误不一定是真正的错误
用户浏览器和操作系统用户使用浏览器及操作系统的类型和版本日志文件用来了解设计的技术规格和实际情况间的差距，可以对未来的规划提供依据
用户地域分布地域分布统计日志文件基于国家域名后缀的统计不是很可靠
网站响应时间页面下载时间和数据搜索时间性能监控软件是一个很好的基准，网站随着流量的增加，可以了解其性能变化
服务器正常运行时间网站可用时间的百分比性能监控软件应该尽量使这个指标接近100%，对于那些以广告为主要业务的网站更重要
注册用户数带有用户个人详细信息的注册用户总数数据库要求用户使用时需注册和登录，操作更麻烦
个性化应用专家报告功能数据库分析包括分析购买趋势、销售转化率、用户生活方式等。
案例-某公司软件过程规范示例
编者说明： 软件过程管理中的一个很重要的工作就是制定项目、组织的过程规范，它是软件开发组织行动的准则与指南。该文档就是一个实际的过程规范的实例，通过该实例，相信对大家根据自身情况制定符合要求的项目过程规范、组织过程规范有很好的借鉴作用。 1.总则 最大限度提高Q&P（质量与生产率），提高Q&P的可预见性，是每一个软件开发机构的最大目标。而Q&P依赖于三个因素：过程、人和技术，因此要实现Q&P的提高，除了加强技术能力，引进、培育更多优质技术人才之外，规范、改进机构的过程是一个十分重要的手段。我们希望通过在制定软件过程规范标准，并在软件开发实践中不断地完善、修订，提高Q&P和Q&P的可预见性。 本规范采用CMM（软件过程成熟度模型）的指导，吸收RUP、XP、MSF、PSP、TSP 等过程规范指南的思想、方法及实践，充分结合xxx技术开发部的实际情况，引入先进的技术、方法、工具，为公司的软件开发工作提供一部详细、可操作的过程指南。在本规范的第一版本中，主要包括管理过程和开发过程两个部分，管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。 2.项目管理过程规范 项目管理过程是对软件项目过程进行计划、监控/管理、总结的辅助过程，包括需求、配置、成本、进度、质量和风险等的管理。项目管理过程主要包括三个阶段：项目立项与计划、项目实施、项目关闭。 2.1 项目立项与计划 参与人员：技术开发部指定的项目负责人（包括前期负责人、正式的项目经理）、立项申请人、[相关最终客户]以及实施该项目的开发组队成员； 入口准则：接到经公司总经理或副总经理批准的市场部门的《软件开发立项申请表》；
软件开发过程管理规范
软件开发过程管理规范文件管理序列号：[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）质量评价：一般地，根据度量综合指标值，有以下评分标准。 质量评价计分标准表 序号得分质量评价
软件设计文档国家标准GB8567
软件设计文档国家标准GB8567-88 一、文档编写标准化 在整个项目开发及使用过程中，应该有完备的文档支持，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性和可追溯性。 完备的文档对软件的开发及使用起了很大的作用。一般要求编写好十三种文档。 1、可行性分析报告 说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 2、项目开发计划 为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 3、软件需求说明书（软件规格说明书） 对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 4、概要设计说明书 是概要设计阶段的工作总结。主要包括功能分配、模块划分、程序总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理等，为详细设计作好准备。 5、详细设计说明书 着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 6、用户操作手册 详细描述了该软件的功能、性能和用户界面，使用该软件的具体方法等。 7、测试计划 包括测试内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。8、测试分析报告 测试计划的执行情况，对测试结果的分析，提出测试结论。 9、开发进度月报 按月提交的项目进展情况报告。包括计划与实际执行情况的对比、阶段成果、遇到的问题、解决的方法以及下一步的打算。 10、项目开发总结报告 项目完成以后，总结实际执行情况。如进度、成果、资源利用、成本和投入的人力，对项目开发作出评价，总结经验与教训。 11、软件维护手册 主要包括软件系统说明、程序模块说明、操作环境、支持软件说明、维护过程说明等。12、软件问题报告 记录软件出现问题的日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。13、软件修改报告 软件产品投入使用后，发现了需修改、更正的问题，要将出现的问题、修改意见、修改可能出现影响作出详细描述，提交审批。 二、可行性分析报告的撰写要求 可行性研究报告的编写内容要求如下： 1 引言
软件过程规范模板
软件过程规范模板 1. 总则 最大限度提高Q&P （质量与生产率），提高Q&P的可预见性，是每一个软件开发机构的最大目标。而Q&P 依赖于三个因素：过程、人和技术，因此要实现Q&P 的提高，除了加强技术能力，引进、培育更多优质技术人才之外，规范、改进机构的过程是一个十分重要的手段。我们希望通过在制定软件过程规范标准，并在软件开发实践中不断地完善、修订，提高Q&P 和Q&P 的可预见性。 本规范采用CMM （软件过程成熟度模型）的指导，吸收RUP、XP、MSF、 PSP、TSP等过程规范指南的思想、方法及实践，充分结合xxx技术开发部的实际情况， 引入先进的技术、方法、工具，为公司的软件开发工作提供一部详细、可操作的过程指南。在本规范的第一版本中，主要包括管理过程和开发过程两个部分，管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。 2. 项目管理过程规范 项目管理过程主要包括三个阶段：项目立项与计划、项目实施、项目关闭。 2.1 项目立项与计划 参与人员：技术开发部指定的项目负责人（包括前期负责人、正式的项目经理）、立项申请人、［相关最终客户］以及实施该项目的开发组队成员； 入口准则：接到经公司总经理或副总经理批准的市场部门的《软件开发立项申请表》； 出口准则：立项申请人签字确认了经修订正后的正式《软件项目计划》，并 通过《工作任务卡》下达了开发任务，开发工作正式开始；输入：经审批 的《软件开发立项申请表》、与需求相关的业务资料；输出：《软件项目 计划》、《软件需求规格说明书》、《开发任务卡》；活动：
软件开发过程规范
【最新资料,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.总则 最大限度提高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.需求分析完成后，形成正式的《软件需求说明书》，提交立项申请人确认；（需求分析过程参见开发过程规范部分）
软件项目标准开发流程
1、需求分析是怎样做的？（自己理解着说） 需求分析是构建软件系统的一个重要过程。 一般，把需求类型分成三个类型： 1、业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。 2、用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。 3、功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 业务需求和用户需求是软件需求分析的基础，也是软件构建的前提。系统分析员通过对业务需求和用户需求的分解，将其转换成克一形式化描述的软件功能需求。开发软件系统最为困难的部分，就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨,使系统更加详尽,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。 4、客户也经常是矛盾的。事实上，很少有客户能够明确的知道怎样的一个系统对自己是最有益处的，他们往往在集中方案之间徘徊，于是经常产生需求的变动。生产厂商经常陷入客户自己的矛盾之中。 客户的负面影响可能对于能够在预算内按时完成项目产生很大的影响。尽管客户需要对需求的质量负责任，但是，当一个软件项目因为客户事先没有预料到的情况而导致失败的时候，即使客户不会追究开发方的责任，就软件项目本身而言，也已经是失败的。 总结： 良好的需求分析是软件成功的基础。以上是作者对需求分析工作实践的一次小结以及综合性的思考，是对需求分析本身所做的一次分析。在此基础上，作者提出了逆向沟通的设想，即系统分析员主动进行沟通，提出指导性意见。当软件融合了客户和系统分析员双方智慧，其质量将会进一步得以提高。 2、 6周 （比较合理的代码行数是多少，如果多了，我是怎么切割的）500行，例如：实现数据3、如何将用户登录的信息保存？ 用户登陆页面将每个用户的信息使用session保存下来,例如: session.setAttribute("UserID","ytang"); 如果用到用户的登陆信息，再从session根据session.getAttribute("userID")所存储的信息例如在项目1中的应用 4．软件项目开发流程应该是什么样子的？ 1。需求分析和获取； 2。界面的设计和修改，直到用户可以接受； 3。后台数据库的建立，做成几张表，写几个存储过程； 4。前台模块的编写和调试； 5。项目的实施和维护；
软件开发过程规范
软件开发过程规范 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内容变更：开发项目干系人可对申请对《开发立项申请书》的内容进行变更，变更后按申请的流程进行签字确认，变更后的内容重新填写《开发立项申请书》并附在原申请书后。项目组成员的变更由开发内部掌握，不必进行变更申请。变更可在结项前的任何阶段提出。
标准的软件开发过程
标准的软件开发过程 软件开发的标准过程包括六个阶段，而六个阶段需要编写的各类文件达14种之多，在每个阶段需要编写哪些文件，以及这些文件的主要内容见下： 1.可行性与计划研究阶段 可行性研究报告：在可行性研究与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编制的文件。 项目开发计划：编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度、所需经费预算、所需软、硬件条件等问题作出的安排记载下来，以便根据本计划开展和检查本项目的开发工作。 2.需求分析阶段 软件需求说明书：软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。内容包括对功能的规定对性能的规定等。 数据要求说明书：数据要求说明书的编制目的是为了向整个开发时期提供关于被处理数据的描述和数据采集要求的技术信息。 初步的用户手册：用户手册的编制是要使用非专门术语的语言，充分地描述该软件系统所具有的功能及基本的使用方法。使用户（或潜在用户）通过本手册能够了解该软件的用途，并且能够确定在什么情况下，如何使用它。 3.设计阶段 概要设计说明书：概要设计说明书又可称系统设计说明书，这里所说的系统是指程序系统。 编制的目的是说明对程序系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计。运行设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。
详细设计说明书：详细设计说明书又可称程序设计说明书。编制目的是说明一个软件系统各个层次中的每一个程序（每个模块或子程序）的设计考虑，如果一个软件系统比较简单，层次很少，本文件可以不单独编写，有关内容合并入概要设计说明书。 数据库设计说明书：数据库设计说明书的编制目的是对于设计中的数据库的所有标识、逻辑结构和物理结构作出具体的设计规定。 测试计划初稿：这里所说的测试，主要是指整个程序系统的组装测试和确认测试。本文件的编制是为了提供一个对该软件的测试计划，包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整理方法及评价准则。4.实现阶段 模块开发卷宗（开始编写）：模块开发卷宗是在模块开发过程中逐步编写出来的，每完成一个模块或一组密切相关的模块的复审时编写一份，应该把所有的模块开发卷宗汇集在一起。 编写的目的是记录和汇总低层次开发的进度和结果，以便于对整个模块开发工作的管理和复审，并为将来的维护提供非常有用的技术信息。 用户手册完工 操作手册：操作手册的编制是为了向操作人员提供该软件每一个运行的具体过程和有关知识，包括操作方法的细节。 测试计划终稿： 5.测试阶段 模块开发卷宗(此阶段内必须完成) 测试分析报告：测试分析报告的编写是为了把组装测试和确认测试的结果、发现及分析写成文件加以记载。 项目开发总结报告：项目开发总结报告的编制是为了总结本项目开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。
软件过程规范
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.最初的《软件项目计划》通过立项申请人的确认后，项目经理计划安排需求分析；
软件设计规范
软件设计规范 概述 软件设计是把需求转化为软件系统的最重要的环节，系统设计的优劣在根本上决定了软 件系统的质量。 在此，主要阐述软件系统设计的5个核心内容：体系结构设计、用户界面设计、数据库设计、模块设计、数据结构和算法设计。旨在帮助开发人员搞清楚“设计什么”以及“如何 设计”。 一般把设计过程划分为两个阶段：概要设计阶段和详细设计阶段，如下所示： *概要设计阶段的重点是体系结构设计。 *详细设计阶段的重点是用户界面设计、数据库设计、模块设计、数据结构与算法设计 等。 可根据项目的情况进行文档裁减和过程合并，如项目开发过程只有一个设计阶段和设计 文档。 体系结构 体系结构如同人的骨架。如果某个家伙的骨架是猴子，那么无论怎样喂养和美容，这家 伙始终都是猴子，不会成为人。 由此可见，体系结构乃是系统设计的重中之重。 目前业界比较流行的软件结构模式有C/S（客户/服务器）、B/S（BROWSE/SERVER）、层次结构（上下级层次结构、顺序相邻的层次结构、含中间件的层次结构） 体系结构设计原则 ● 合适性 即体系结构是否适合于软件的“功能性需求”和“非功能性需求”。高水平的设计师高就高在“设计出恰好满足客户需求的软件，并且使开发方和客户方获取最大的利益，而不是 不惜代价设计出最先进的软件。 ● 结构稳定性 详细设计阶段的工作如用户界面设计、数据库设计、模块设计、数据结构与算法设计等等，都是在体系结构确定之后开展的，而编程和测试则是更后面的工作，因此体系结构应在 一定的时间内保持稳定。
软件开发最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现实。人们希望在需求发生变化时，最好只对软件做些皮皮毛毛的修改，可千万别改动软件的体系结构。如果当需求发生变化时，程序员不得不去修改软件的体系结构，那么这个软件的系统设计是失 败的。 高水平的设计师应当能够分析需求文档，判断出哪些需求是稳定不变的，哪些需求是可能变动的。于是根据那些稳定不变的需求设计体系结构，而根据那些可变的需求设计软件的 “可扩展性”。 ● 可扩展性 可扩展性是指软件扩展新功能的容易程度。可扩展性越好，表示软件适应“变化”的能 力越强。 可扩展性越来越重要，这是由现代软件的商业模式决定的： *社会的商业越发达，需求变化就越快。需求变化必将导致修改（或者扩展）软件的功能，现代软件的规模和复杂性要比十年前的大得多（对比一下操作系统的变化就明白了），如果软件的可扩展性比较差的话，那么修改（或者扩展）功能的代价会很高。 *现代软件产品通常采用“增量开发模式”，开发商不断地推出软件产品的新版本，从而不断地获取增值利润。如果软件的可扩展性比较差的话，每次开发新版本的代价就会很高。虽然开发商抓住了商机，但却由于设计水平差而导致没有赚取多少利润，真是要活活气死。 ● 可复用性 由经验可知，通常在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具有高质量），而大量成熟的工作可以通过 复用来快速实现（即具有高生产率）。 可复用性是设计出来的，而不是偶然碰到的。要使体系结构具有良好的可复用性，设计师应当分析应用域的共性问题，然后设计出一种通用的体系结构模式，这样的体系结构才可 以被复用。 用户界面设计 为了提高用户界面的易用性和美观程度，总结了十个设计原则。用于提高易用性的界面 设计原则有8个： *用户界面适合于软件的功能 *容易理解 *风格一致
软件开发规划项目规范标准
软件项目开发和管理规范 本文阐述软件项目开发和管理的流程规范，作为软件项目开发的高级指引，本规范定义了软件开发的各个阶段以及每个阶段的工作活动和工件，但不对活动和工件的细节作过多规定。在项目开发过程中，每个项目根据自身的需要确定这些活动和工件的细节。 项目阶段 图2-1 项目开发的五个阶段 ?启动阶段 这个阶段的工作目的是决定一个项目是否需要启动。为了达到这个目的，首先要明确项目的总体战略目标，对项目的需要建立认同。即确定到底需要做什么、开发什么产品或提供什么服务，以及需要解决什么样的问题和需要满足客户或市场的什么要求等，同时还要总结项目工作的范围、所需资源、大约开支、各种风险，以及该项目不执行的其他替代选择等。这些代表了对整个项目目标从战略角度和宏观层次所进行的分析，通过项目的意向书总结出来，由此确证客户或项目发起人和赞助者的要求与期望，并帮助他们判定项目是否上马。项目意向总结书的通过及项目被批准上马形成了这个项目的起始点。 ?计划阶段 这个阶段的工作是为整个项目做计划。项目开始后，首先要确定项目的具体范围，明确定出项目到底要做什么，总结、归纳并定出产品的功能。然后进一步制定项目的计划，列出每项具体工作，并建立所有工作任务的重要性及顺序；确定每项工作的执行人和所需资源；根据人员的配置和能力设定各项工作和整个项目的完成时间表。 ?执行阶段
这个阶段的工作是通过执行项目的计划来完成项目的任务。它包括落实一切所需资源，如：人员、设备、费用、技术、信息，由管理者领导全体项目参与者开展各项工作。同时跟踪各项具体工作和整个项目的进度，定期向全体项目人员及项目的发起人报告项目状态。 ?控制阶段 这个阶段的工作是确证项目工作的结果符合项目的计划。它通过对项目结果的衡量和审核，与项目计划所期望的结果进行比较，找出实际结果与计划的差别，并制定处理措施。这个阶段的工作还包括对项目进程中出现的任何更改要求进行审核和批准。同时调解项目进程中出现的各种问题，如：对缺乏的资源的补偿调节；对项目的进度表及各项具体工作的优先级或顺序的修订。 ?结束阶段 这个阶段的工作是确保项目的最终结果或提交物达到计划的要求，并对完成的结果作可接受的确认。还包括在项目完成之后的收尾工作，对整个项目的经历进行总结，修订项目文档，用户培训等。 阶段完成标志 在项目开发过程中，当一个阶段完成后才会开展下一个阶段的工作；另外，“某个阶段完成”通常被定义为项目的一个里程碑，里程碑标识了项目的进度，它是项目开发和控制的重要参考，对整个项目有重要的意义。因此，“确证某个阶段是否已经完成”的工作非常有重要。 ?每一个阶段的结束以它特定任务的完成为象征 只有当某个阶段中被规定的所有工作任务都完成了，这个阶段才算真正结束，整个项目才可以进入到下一个阶段中去。反过来说，要是阶段中某个任务没有全部完成，按照项目的定义，整个阶段就不能算是完成，因此项目就不能进入到下一个阶段去。 ?衡量阶段结束的工作结果必须是实在的交付品 阶段中的任务是否完成是透过任务活动中产生的交付品来体现的，交付品必须是可交付的、非抽象的、实质的并且可以通过用衡量的方法来判断是否真正地完成了的具体事物。如：某一阶段的完成是以建造一个样品或完成某分文件作为象征。任何项目阶段的结束，都应该有这样的实质性东西的完成作为象征。 ?跨阶段的进程以阶段结尾的合格验证和审核来决定 当一个阶段结束时，在进入到下一个阶段之前所需要做的工作应包括对交付品进行合格验证，并检查这一阶段的工作质量和效率，由此判断是否可以进入到下一个阶段。这些检验象征了一个阶段的结尾终点，表示项目的进程离开了上一个阶段而进入了下一个阶段。
软件界面设计规范
软件界面设计规范 1.界面规范 .总体原则以用户为中心。 设计由用户控制的界面，而不是界面控制用户。清楚一致的设计。所有界面的风格保持一致，所有具有相同含义的术语保持一致，且易于理解拥有良好的直觉特征。以用户所熟悉的现实世界事务的抽象来给用户暗示和隐喻，来帮助用户能迅速学会软件的使用。较快的响应速度。简单且美观。 .原则详述 1.2.1.用户控制用户界面设计的一个重要原则是用户应该总是感觉在控制软件而不是感觉被软件所控制。操作上假设是用户--而不是计算机或软件--开始动作。用户扮演主动角色，而不是扮演被动角色。在需要自动执行任务时，要以允许用户进行选择或控制它的方式来实现该自动任务。提供用户自定义设置。因为用户的技能和喜好各不相同，因此他们必须能够个性化界面的某些方面。Windows为用户提供了对许多这方面的访问。您的软件应该反应不同的系统属性--例如颜色、字体或其他选项的用户设置。采取交互式和易于感应的窗口，尽量避免使用模态对话框，而使用"非模式"辅助窗口。"模式"是一种状态，它排除一般的交互，或者限制用户只能进行特定的交互。当最好使用一个模式或该模式只是可替换的设计时--例如，用于在一个绘图程序中选定一个特定感觉--请确保该模式是显然的、可见的，是一个明确的用户选定的结果，并且容易取消。在后台运行长进程时，保持前台式交互。例如，当正在打印一个文档，即使该文档不能被改变，用户也应该可以最小化该窗口。谅解。用户喜欢探索一个界面，并经常从尝试和错误中学习。一个有效的界面允许交互式的发现，它只提供一组合适的选择，并在用户可能破坏系统或数据的情况时发出警告。如果可行，还应提供可逆转或可还原的操作。即使在设计得很好得界面中，用户也可能犯错误。这些错误既可以是物理上得（偶然地指向了错误的命令或数据），也可以是逻辑上的（对选定哪一个命令或哪些数据做出了错误的决定）。有效的设计避免很可能导致错误的情况。它还包容潜在的用户错误，并且使用户易于还原。 1.2.2.清楚一致的设计一致允许用户将已有的知识传递到新的任务中，更快地学习新事物，并将更多的注意力集中在任务上。这是因为他们不必花时间来尝
华为软件开发行为规范
软件开发行为规范 第一版 深圳市华为技术有限公司 版权所有不得复制
软件开发行为规范 (第一版） 为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以达到过程控制的目的。 与软件开发相关的所有人员，包括各级经理和工程师都必须遵守本软件开发行为规范。对违反规范的开发行为，必须按照有关管理规定进行处罚。 本软件开发行为规范的内容包括：软件需求分析、软件项目计划、概要设计、详细设计、编码、需求管理、配置管理、软件质量保证、数据度量和分析等。 本软件开发行为规范，采用以下的术语描述： ★规则：在软件开发过程中强制必须遵守的行为规范。 ★建议：软件开发过程中必须加以考虑的行为规范。 ★说明：对此规则或建议进行必要的解释。 ★示例：对此规则或建议从正或反两个方面给出例子。 本软件开发过程行为规范由研究技术管理处负责解释和维护。 研究技术管理处
目录 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 引言......................................................错误!未定义书签。 编写目的..........................................错误!未定义书签。 适用范围..........................................错误!未定义书签。 定义..............................................错误!未定义书签。 流程图............................................错误!未定义书签。 2 需求调研..................................................错误!未定义书签。 概述..............................................错误!未定义书签。 需求调研..........................................错误!未定义书签。 注意事项..........................................错误!未定义书签。 3 可行性分析................................................错误!未定义书签。 4 需求分析..................................................错误!未定义书签。 概述..............................................错误!未定义书签。 产物/成果.........................................错误!未定义书签。 需求分析任务......................................错误!未定义书签。 需求分析方法......................................错误!未定义书签。 原型化........................................错误!未定义书签。 需求报告..........................................错误!未定义书签。 划分需求的优先级..................................错误!未定义书签。 评审需求文档和原型................................错误!未定义书签。 5 系统设计..................................................错误!未定义书签。 概述..............................................错误!未定义书签。 产物/成果.........................................错误!未定义书签。 产品设计..........................................错误!未定义书签。 概述..........................................错误!未定义书签。 流程图........................................错误!未定义书签。
软件设计国家标准
操作手册（G B8567——88） 1引言 编写目的 说明编写这份操作手册的目的，指出预期的读者。 前景 说明： a．这份操作手册所描述的软件系统的名称； b．该软件项目的任务提出者、开发者、用户（或首批用户）及安装该软件的计算中心。 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 参考资料 列出有用的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所列出的这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2软件征述 软件的结构 结合软件系统所具有的功能包括输入、处理和输出提供该软件的总体结构图表。 程序表 列出本系统内每个程序的标识符、编号和助记名。 文卷表 列出将由本系统引用、建立或更新的每个永久性文卷，说明它们各自的标识符、编号、助记名、存储媒体和存储要求。 3安装与初始化 一步一步地说明为使用本软件而需要进行的安装与初始化过程，包括程序的存载形式，安装与初始化过程中的全部操作命令，系统对这些命令的反应与答复，表征安装工作完成的测试实例等。如果有的话，还应说明安装过程中所需用到的专用软件。 4运行说明 所谓一个运行是指提供一个启动控制信息后，直到计算机系统等待另一个启动控制信息时为止的计算机系统执行的全部过程。 运行表 列出每种可能的运行，摘要说明每个运行的目的，指出每个运行各自所执行的程序。 运行步骤 说明从一个运行转向另一个运行以完成整个系统运行的步骤。 运行1（标识符）说明 把运行1的有关信息，以对操作人员为最方便最有用的形式加以说明。 运行控制 列出为本运行所需要”的运行流向控制的说明。 操作信息 给出为操作中心的操作人员和管理人员所需要的信息，如：
软件发布管理流程规范
软件发布管理流程规范 编制： 审核： 日期： 版本： 编号： 密级：
修改历史 第 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 概述 本规范中将软件开发的整个技术过程分为四个顺序实施的阶段，分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。在对技术过程规范的描述，按阶段内部的活动和产物对四个阶段分别说明。 在本规范中对阶段内活动的说明，是按顺序性活动和持续性活动两类分别进行说明。对于顺序性活动是按该阶段中活动的总体顺序进行的描述，而在实际工作中，从各活动的具体实施的细节来看，各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的技术活动进行说明。