软件开发标准化工作流程V10.docx

1、软件开发标准化工作流程V10软件开发标准化工作流程1引言1.1编写目的说明编写这份软件开发标准化工作流程的目的，指出预期的读者。1.2适用范围互联网开发中心所有项目。1.3定义列出本文件中用到的专门术语的定义、外文首字母组词的原词组。1.4流程图2需求调研2.1概述需求调研对于一个应用软件开发来说，是一个系统开发的开始阶段，需求调研的质量对于一个应用软件来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。2.2需求调研总体而言，需求调研可按照业务流程、业务规则、表单数据、贯穿系统的关系四个方向来进行调研

2、。业务规则各个流程、功能点等事项的办理，都会有相关约束或条件，那么需要对其前置条件、后置条件、数据验证、条件判断等进行分析调研。调研对象一般为操作员。表单数据对各个功能点的业务数据、数据项、表单格式、查询条件以及其它相关数据进行明确的分析调研。调研对象一般为操作员。贯穿系统的关系各个模块或科室之间的数据交换、传递以及数据共享等，需要我们调研人员与各个模块或科室的相关负责人进行多方沟通，确定一个多方满意的需求调研结果。2.3注意事项调研过程中，用户说的很快，不可能等我们全部记录之后，再讲下一个问题。因此，只能在笔记本上速记，有时只能记录1、2个关键字。因此，每天调研结束之后，当天晚上必须整理当天

3、的调研情况，写成一份调研日记。整理当天的调研记录时，还要整理出待明确的问题，下一次再找机会与用户再沟通、确认。调研的各个阶段，必须出具相关文档或文件，比如调研计划、流程图、表单样式、报表格式、背景图片、数据项列表、讨论记录、问题列表等。所有疑问必须等到明确的答复，不能出现相互矛盾、似是而非的需求。需准确理解客户的讲解，如果有问题的先做记录，之后将整理的问题向客户询问，得到明确的结果。需求必须是客户接受和确认的，不能有臆测的需求。要合理安排好时间和进度。有时候客户还有自己要做的事情，不一定能及时相应。所以必须提前预约好时间，保证整个需求调研的进度。能积极引导客户。当客户出现疑虑，而调研人员能明白

4、且能做好客户想要的东西的时候，调研人员能及时积极引导客户，详细讲解我们所知道的东西，并能让客户接受与确认。如遇公司有相关原型或产品，调研人员需先详细了解公司的相关原型和产品，根据成品，找出本地化的差异化需求。3可行性分析这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。在问题定义阶段提出的对工程目标和规模的报告通常比较

5、含糊。可行性研究阶段应该导出系统的高层逻辑模型（通常用数据流图表示），并且在此基础上更准确、更具体地确定工程规模和目标。然后分析员更准确地估计系统的成本和效益，对建议的系统进行仔细的成本效益分析是这个阶段的主要任务之一。可行性研究的结果是使用部门负责人做出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入更多的人力物力。及时中止不值得投资的工程项目，可以避免更大的浪费。4需求分析4.1概述这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具

6、备哪些功能。用户了解他们所面对的问题，知道必须做什么，但是通常不能完整准确地表达出他们的要求，更不知道怎样利用计算机解决他们的问题；软件开发人员知道怎样使用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。因此系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法描述表示系统的逻辑模型。在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础，因此必须准确完整地体现用户的要求。系统分析员通常都是计算机软件专家，技术专家一般都喜欢很快着手进行具体设计，然而，一旦分析员开始谈论程序设计的细节，就会脱离用户，使他

7、们不能继续提出他们的要求和建议。较件工程使用的结构分析设计的方法为每个阶段都规定了特定的结束标准，需求分析阶段必须提供完整准确的系统逻辑模型，经过用户确认之后才能进入下一个阶段，这就可以有效地防止和克服急于着手进行具体设计的倾向。需求分析是软件工程中的一个重要环节。是关乎软件开发成败的重要因素。现在软件项目中返工开销几乎占了总开发的一半，而导致返工的主要原因是需求分析不明确。从而引发软件开发中的一些列更改。这些更改可能导致浪费大量资源、软件项目无法按时完成等严重问题，所以需求分析是软件设计和实现的基础，是软件项目迈向成功的重中之重。4.2产物/成果项目阶段/角色项目经理产品团队(BA/BAS/

8、Product M）开发团队TTL/Developer）测试团队(Test Lead /Tester）需求阶段活动：1、建立CQ/QC中的项目目录；2、在SVN中建立项目目录；1、分析项目所需资源，风险等2、预估项目周期产出：1、项目计划(大致时间规划)活动：1、收集整理需求产出：1、需求说明书参与：1、需求分析2、环境分析参与：1、需求分析2、环境分析4.3需求分析任务简言之，需求分析的任务就是解决“做什么”的问题，就是根据需求调研，全面理解用户的各项要求并准确的表达所接受的用户需求。4.4需求分析方法4.4.1原型化原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。原型

9、化方法就是尽可能快地建造一个粗糙系统，这系统实现了目标系统的某些或者全部功能，但是这个系统可能在可靠性，界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性，技术的可行性，或考察是否满足用户的需求等。如，为了考察是否满足用户的需求，可以用某些软件工具快速建造一个原型系统，这个系统只是一个界面，然后听取用户的意见改进这个原型。以后的目标系统就在原型系统的基础上开发。原型主要有三种类型：探索型目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。实验型用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。进化型目的不在于改进规

10、格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。在使用原型方法是有两种不同的策略。废弃策略先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改，形成比较好的思想，据此设计出比较完整，准确，一致，可靠的最终系统。系统构建完成后，原来的模型系统被废弃不用。探索型和实验型属于这种策略。追加策略先构造一个功能简单而且质量要求不高的模型系统，最为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。4.5需求报告需求报告及软件需求说明书，作用在于便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开

11、发工作的基础和依据，并作为确认测试和验收的依据。通过从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决办法和其他信息。通过这些分析，形成一份软件需求说明书，此份说明书使开发人员和客户之间针对要开发的产品内容达成协议。客户需要评审此文档，以确保内容准确完整的表达其需求。一份高质量的“需求说明书”有助于开发人员开发出真正需要的产品。输出：软件需求说明书，格式参照附录1软件需求说明书4.6划分需求的优先级绝大多数项目没有足够的时间或者资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求的优先级，因为开发者不可能按照

12、客户的观点决定需求优先级。开发人员将为确定的优先级提供有关每个需求的花费和风险的信息。在时间和资源的限制下，关于所需特性能否完成或者完成多少，开发人员必须给出意见。4.7评审需求文档和原型客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户人为编写的“需求分析报告”不够准去，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，是他们更好的理解需求。原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。5系统设计制定项目计划软件项目计划是一个用来协调所有其他计划，以指导项目执行和控制的可操作文件。它

13、体现了对客户需求的理解，是开展项目活动的基础，也是软件项目跟踪与监控的依据。确定开发过程根据软件项目和项目组的实际情况，建立起一个稳定、可控的软件开发过程模型，并按照该过程来进行软件开发。加强过程控制过程控制主要包括过程管理、变更控制和配置管理。5.1概述此阶段主要是根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。5.2产物/成果项目阶段/角色项目经理产品团队(BA/BAS/Product M）开发团队TTL/Developer）测试团队(Test Lead /Tester）设计阶段活动：1、监控项目进度，2、组织安排本阶段的评审1、任务分解，责任到人2、细化项目计

14、划产出：1、项目计划（具体到各功能）参与：1、系统功能设计产出：1、界面原型活动：1、系统功能技术设计2、数据库设计产出：1、系统功能的技术设计2、数据库设计说明书活动：1、组织测试计划评审产出：1、项目测试估计测试计划书5.3产品设计5.3.1概述产品设计是专业的技术人员根据软件项目需求分析的结果来对整个软件系统进行定制、开发、设计的一个过程。5.3.2流程图5.4软件设计5.4.1概述软件设计阶段主要工作可分为软件概要设计、详细设计两个分阶段。对于复杂程度不高、规模较小或关键性级别较低的软件，可将概要设计和详细设计合并为一个阶段执行。5.4.2流程图5.4.3概要设计在概要设计阶段，项目组

15、应根据软件总体框架、软件模型和软件工程实现的要求，提出软件设计方法，建立软件的总体结构，划分功能模块（软件部件），确定总体结构和部件间的关系，定义各个软件功能模块的功能、数据接口和控制接口，设计全局数据库/数据结构，规定设计限制，编写概要设计说明，由研究室或项目组负责人审批。对于复杂软件，研究室或项目组应组织对软件概要设计进行评审，以保证软件结构、全局数据结构、主要算法、模块划分、接口关系和软件模型的合理性、正确性、完整性，与软件需求的一致性。项目组应保持评审结果及任何必要措施的记录。输出：软件概要设计说明书（概要设计部分）,格式参照附录2软件概要设计说明书5.4.3.1数据库系统设计此数据库

16、设计可单独成册，尤其对大型的数据库应用系统，即有一个单独的数据库设计说明书。输出：数据库设计说明书,格式参照附录3数据库设计说明书5.4.3.1.1信息模型设计确定系统信息的类型（实体或视图），确定系统信息实体的属性、关键字及实体之间的联系，详细描述数据库和结构设计，数据元素及属性定义，数据关系模式，数据约束和限制。5.4.3.1.2数据库设计5.4.3.1.2.1设计依据说明数据被访问的频度和流量，最大数据存储量，数据增长量，存储时间等数据库设计依据。5.4.3.1.2.2数据库种类及特点说明系统内应用的数据库种类、各自的特点、数量及如何实现互联，数据如何传递。5.4.3.1.2.3数据库逻

17、辑结构说明数据库概念模式向逻辑模式转换所采用的方法论及工具，完成数据库概念模式向逻辑模式的转换。详细列出所使用的数据结构中每个数据项、记录和文件的标识、定义、长度及它们之间的相互关系。此节内容为数据库设计的主要部分。5.4.3.1.2.4物理结构设计列出所使用的数据结构中每个数据项的存储要求、访问方法、存取单位和存取物理关系等。建立系统程序员视图，包括：数据在内存中的安排，包括对索引区、缓冲区的设计；所使用的外存设备及外存空间的组织，包括索引区、数据块的组织与划分；访问数据的方式方法。5.4.3.1.2.5数据库安全说明数据的共享方式，如何保证数据的安全性及保密性。5.4.3.1.2.6数据字

18、典编写详细的数据字典。对数据库设计中涉及到的各种项目，如数据项、记录、系、文卷模式、子模式等一般要建立起数据字典，以说明它们的标识符、同义名及有关信息5.4.4详细设计在详细设计阶段，项目组应对概要设计中产生的软件部件进行方法和过程描述，对程序单元内部细节(算法模型、数据结构、详细接口信息等)进行设计，为源代码提供必要的说明，并编写软件详细设计说明，由研究室或项目组负责人审批。详细设计过程中开始编制软件测试计划初稿。研究室或项目组应组织对详细设计说明进行评审（顾客参加），以保证程序单元功能、控制结构、数据结构和算法模型的正确性、合理性，程序单元接口的明确性、一致性。项目组应保持评审结果及任何必

19、要措施的记录。输出：软件详细设计说明书（详细设计部分）格式参照附录4软件详细设计说明书6软件开发6.1建立项目开发团队依据业务需求开发任务书中，对项目完成时间、费用的要求，确认项目开发团队人员数量，明确项目经理，建立以项目经理为项目负责人的开发团队。团队组建完成后，项目经理组织团队人员进行交流学习和互相熟悉，说明项目任务、目标、规模、人员组成、规章制度和行为准则，个人岗位和责任，建立团队与外界的初步联系及相互关系，确立团队的权限，建立团队的绩效管理机制，争取公司各方面支持，根据团员特点分配职责，收集有关项目信息。6.2实施项目开发测试依据公司软件项目设计开发制度要求和软件项目管理规范，按照需求

20、实现方案为项目具体开发做好准备。1技术人员在项目实现方案框架下2根据项目实际要求准备好开发环境和测试环境;3程序员编写程序代码，测试人员设计测试方案和应用案例;4是对需求实现功能说明书和测试计划、测试案例进行评审;5撰写测试问题报告，改正软件Bug;6按照要求定时提交相关的项目管理信息资料。6.3工作内容软件实现阶段的主要工作是根据软件设计结果，进行软件代码编制、调试、代码审查和程序单元测试，验证程序单元与设计说明的一致性。本阶段的代码审查和单元测试应以开发人员自查自测为主。实现过程中应规定编码实现规则、编程语言、数据结构、命名约定和注释规则等并遵守这些规则；尽可能使用辅助设计工具；尽可能地重

21、用已有的软件实现规范、实现方法、代码片段、数据结构、标准函数等。进行规范化编程，采用统一的编码风格；实现过程中应全面考虑软件测试工作；充分地考虑到软件的可维护性。软件实现过程中，项目组应组织程序调试、代码自查和程序单元自测，主要包括对软件各功能模块编码的正确性、程序设计准则的符合性、程序单元测试过程与结果的合理性和正确性以及测试辅助程序的合理性和充分性进行审查和验证，以保证交付测试的软件与软件设计说明完全符合。与外部存在多系统交联时，需要组织或参与联合调试试验，以验证接口的正确性。软件实现阶段应开始编写用户使用手册和软件测试说明文档。输出：1、用户使用手册，格式参照附录5用户使用手册2、软件测

22、试说明，格式参照附录6软件测试说明6.4产物/成果项目阶段/角色项目经理产品团队(BA/BAS/Product M）开发团队TTL/Developer）测试团队(Test Lead /Tester）开发阶段活动：1、监控项目进度2、调整人员安排3、跟踪解决技术难点产出：1、项目计划（更新进度）活动：1、具体功能开发产出：1、功能单元代码活动：1、编写测试用例和.自动化脚本组织测试用例评审产出：1、测试用例2、自动化脚本单元测试阶段活动：1、监控项目进度2、踪解决问题列表产出：1、项目计划（更新进度）2、项目进度报告活动：1、组织代码走查2、单元测试产出：1、功能单元代码2、单元测试报告7项目测

23、试7.1软件测试阶段7.2概述软件的错误是不可避免的，所以必须经过严格的测试。通过对本软件的测试，尽可能的发现软件中的错误，借以减少系统内部各模块的逻辑，功能上的缺陷和错误，保证每个单元能正确地实现其预期的功能。检测和排除子系统（或系统）结构或相应程序结构上的错误，使所有的系统单元配合合适，整体的性能和功能完整。并且使组装好的软件的功能与需求保持一致。7.3流程7.4软件测试准备测试组从软件需求分析阶段开始介入，对需求进行分析，风险分析，测试范围等等。即开始编制软件的测试计划，在软件概要设计、详细设计和编程实现的过程中逐步完善，最终形成软件测试计划，并组织测试计划评审。软件测试计划完成后开始编

24、写相关测试方案，编写测试用例，搭建测试环境。测试用例完成后进行评审，冒烟测试用例覆盖率必须达到100%，系统测试用例达到95%，输出：1)软件测试计划，格式参照附录8软件测试计划；2)软件测试说明（含测试用例和测试程序），格式参照附录6软件测试说明；3)软件测试方案，格式参照附录9软件测试方案；4)测试用例文档，格式参照附录10测试用例文档；7.5软件测试执行测试人员依据测试用例进行软件测试，对发现的错误进入缺陷管理流程，并进行回归测试以验证修改的正确性。测试结束后，测试人员应编写缺陷报告，及软件测试报告。在测试阶段的后期，组织软件测试报告评审，主要对软件测试方法、测试过程和测试结果的有效性和

25、正确性进行审查和评价。项目组应保持评审结果及任何必要措施的记录。输出：缺陷报告，格式参照附录11缺陷报告；软件测试报告，格式参照附录12软件测试报告。8内部验收项目完成集成测试和系统测试后进行项目内部验收，主要有三个步骤：8.1文档准备项目经理提交内部验收计划、项目开发总结报告、产品发布清单；财务主管提交项目财务预算报告。8.2内部验收测试内部验收测试的测试内容与方法虽然与系统测试基本相同，但应站在用户验收的角度进行，因为它是试运行的基础，通过这一步，为用户验收作充分的准备。8.3内部评审对提交的所有文档及测试结果进行内部评审，完成项目开发总结报告。9项目试运行与验收试运行与用户验收阶段的主要

26、任务是，使所有的工作产品得到用户的确认。主要工作有：9.1验收前的准备项目经理负责检查产品的完整性，包括文档、介质和中间产品等，以确保现场实施的成功；负责应用软件的现场安装调试，完成安装调试总结报告；负责制定用户验收计划，并得到客户的确认。9.2用户测试用户进行验收测试和系统试运行，进行文档和系统的移交。9.3用户确认项目经理负责与客户协调，协助用户进行项目验收，形成用户验收报告。10项目维护10.1错性维护由于前期的测试不可能暴露软件系统中所有潜在的和隐含的错误，诊断和改正这些错误的过程。10.2完善性维护在软件正常使用过程中，用户还会不断地提出新的需求，为了满足用户新的需求而增加软件功能的

27、活动称为完善性维护。如果需求变更很大，那完善性维护将转变为软件新版本的开发。系统维护的宗旨就是提高客户对软件产品的满意度。确保系统的正常运行是系统维护的根本目的。11需求变更流程11.1目的指导项目部、软件部、质量部、测试部对产品的软件变更需求（简称CR）进行控制和管理，规范相应的作业流程,详细地定义了各流程环节中状态、角色和动作。明确流程中各角色的职责规范软件缺陷的变更过程11.2适用范围所有项目的软件变更需求控制管理。11.3作业流程11.4流程描述1项目需求确定，项目计划确认后。在项目的任何阶段，如有任何需求变动发起。2判断是否有必要做需求变更？3如确定需要需求变更，评估是否对项目现有设

28、计或实现有影响？4如果有影响：暂停设计或实现，考虑新需求，重新需求分析，设计，实现，修改项目计划。5如果没有影响：评估新需求是否紧急？需要加入当前项目，或在下一项目实现？6如果加入当前项目：增加新需求工作量，更新项目计划。7如果在下一项目实现：在下一项目开始前，收集所有的可加入下一项目的需求变更。在下一项目范围内考虑。11.4.1内部项目用户提出需求-项目组对问题进行分析（不明确的问题要进行确认，区分问题的优先级和解决方案）-提交变更申请表（包含估计和计划）-高层领导决策-审批通过-依照项目计划执行。内部项目一般需求的控制权在高层领导中，有时候不一定关注成本，偏重于系统产生的价值，对用户而且主

29、要关注实用和易用性上。项目经理或团队主要侧重分析用户需求的合理性。11.4.2外部项目用户提出需求-项目组对问题进行分析（过滤需求是否合理、是否在本版本来做、能否放到二期、需求的必要性等）-与客户讨价还价（把不合理的需求、不必要在本期实现的功能推掉）-必须要实现的需求-提交需求变更申请（初步的计划和解决方案）-高层领导决策-详细分析需求和解决方案-评估工作量-设定计划-客户签字确认-依照项目计划执行。外部项目首先应该考虑是公司投入的成本和获取的收益，比如变更会给公司增加合同额或后期市场拓展的机会和对产皮的提炼（有的项目是项目型的产品）。如果上述条件不满足，则首要考虑的是如何推掉需求。11.5提

30、交需求变更编写要尽量详细，并经过客户、高层经理和项目组内部人员的认可。比如测试人员对测试的工作量要参与评估，开发人员对开发工作量要进行评估。数据来源基于基层，确保数据的准确性。同时补充一点变更带来的质控工作量也应该纳入到变更需求表中，比如可能设计项目总结和数据统计的工作量。 客户提交的问题要做好详细的记录，保证有据可查，对问题要进行面对面的确认，避免含糊其词的用户需求。对确认结果进行记录。输出：需求变更申请表，格式参照附录13需求变更申请表；11.6审核评审11.6.1工作内容评审组织者组织相关评审者对需求表进行评审。评审者提出评审意见，组织者汇总所有的评审意见，并通过开会讨论的方式决定对需求表的最终评审意见。11.6.2相关角色发起者：需求表的发起者。评审组织者：公司领导、部门领导，特别是策划部的领导。评审者：公司领导、部门领导、发起者等其他人员。11.7反馈产品经理按评审结论修改相应需求条目，并发布需求版本。12附录12.1附录1软件需求说明书12.2附录2概要设计说明书12.3附录3数据库设计说明书12.4附录4详细设计说明书12.5附录