《软件开发标准化工作流程v10》由会员分享，可在线阅读，更多相关《软件开发标准化工作流程v10（20页珍藏版）》请在金锄头文库上搜索。
1、软件开发标准化工作流程目录1引言31.1编写目的31.2适用范围31.3定义31.4流程图32需求调研42.1概述42.2需求调研42.3注意事项43可行性分析54需求分析54.1概述54.2产物/成果64.3需求分析任务64.4需求分析方法64.4.1原型化64.5需求报告74.6划分需求的优先级74.7评审需求文档和原型75系统设计75.1概述85.2产物/成果85.3产品设计85.3.1概述85.3.2流程图95.4软件设计95.4.1概述95.4.2流程图95.4.3概要设计95.4.3.1数据库系统设计105.4.4详细设计116软件开发116.1建立项目开发团队116.2实施项目开
2、发测试116.3工作内容126.4产物/成果127项目测试137.1软件测试阶段137.2概述137.3流程137.4软件测试准备137.5软件测试执行148内部验收148.1文档准备148.2内部验收测试148.3内部评审149项目试运行与验收159.1验收前的准备159.2用户测试159.3用户确认1510项目维护1510.1错性维护1510.2完善性维护1511需求变更流程1611.1目的1611.2适用范围1611.3作业流程1711.4流程描述1711.4.1内部项目1811.4.2外部项目1811.5提交需求变更1811.6审核评审1811.6.1工作内容1811.6.2相关角色1
3、911.7反馈1912附录2012.1附录1软件需求说明书2012.2附录2概要设计说明书2012.3附录3数据库设计说明书2012.4附录4详细设计说明书2012.5附录5用户使用手册2012.6附录6软件测试说明2012.7附录7项目开发计划2012.8附录8软件测试计划2012.9附录9软件测试方案2012.10附录10测试用例文档2012.11附录11缺陷报告2012.12附录12软件测试报告2012.13附录13需求变更申请表20软件开发标准化工作流程1 引言1.1 编写目的说明编写这份软件开发标准化工作流程的目的，指出预期的读者。1.2 适用范围互联网开发中心所有项目。1.3 定义
4、列出本文件中用到的专门术语的定义、外文首字母组词的原词组。1.4 流程图需求调研系统设计软件开发软件测试内部验收客户验收系统维护需求分析阶段概要设计阶段详细设计阶段系统编码阶段系统测试阶段集成测试阶段系统测试阶段项目管理过程评审过程软件监督与审核过程软件配置管理过程软件需求管理过程变更控制过规程文档控制规程文档开发与管理规范项 目 流 程项目开发的各阶段过程管理思想需求分析2 需求调研2.1 概述需求调研对于一个应用软件开发来说，是一个系统开发的开始阶段，需求调研的质量对于一个应用软件来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用
5、户需求就成为调研人员最重要的任务。 2.2 需求调研总体而言，需求调研可按照业务流程、业务规则、表单数据、贯穿系统的关系四个方向来进行调研。l 业务规则各个流程、功能点等事项的办理，都会有相关约束或条件，那么需要对其前置条件、后置条件、数据验证、条件判断等进行分析调研。调研对象一般为操作员。 l 表单数据对各个功能点的业务数据、数据项、表单格式、查询条件以及其它相关数据进行明确的分析调研。调研对象一般为操作员。 l 贯穿系统的关系各个模块或科室之间的数据交换、传递以及数据共享等，需要我们调研人员与各个模块或科室的相关负责人进行多方沟通，确定一个多方满意的需求调研结果。 2.3 注意事项l 调研
6、过程中，用户说的很快，不可能等我们全部记录之后，再讲下一个问题。因此，只能在笔记本上速记，有时只能记录1、2个关键字。因此，每天调研结束之后，当天晚上必须整理当天的调研情况，写成一份调研日记。整理当天的调研记录时，还要整理出待明确的问题，下一次再找机会与用户再沟通、确认。l 调研的各个阶段，必须出具相关文档或文件，比如调研计划、流程图、表单样式、报表格式、背景图片、数据项列表、讨论记录、问题列表等。 l 所有疑问必须等到明确的答复，不能出现相互矛盾、似是而非的需求。需准确理解客户的讲解，如果有问题的先做记录，之后将整理的问题向客户询问，得到明确的结果。需求必须是客户接受和确认的，不能有臆测的需
7、求。l 要合理安排好时间和进度。有时候客户还有自己要做的事情，不一定能及时相应。所以必须提前预约好时间，保证整个需求调研的进度。 l 能积极引导客户。当客户出现疑虑，而调研人员能明白且能做好客户想要的东西的时候，调研人员能及时积极引导客户，详细讲解我们所知道的东西，并能让客户接受与确认。l 如遇公司有相关原型或产品，调研人员需先详细了解公司的相关原型和产品，根据成品，找出本地化的差异化需求。3 可行性分析这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较抽象的高层次上进行的分析
8、和设计的过程。可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。在问题定义阶段提出的对工程目标和规模的报告通常比较含糊。可行性研究阶段应该导出系统的高层逻辑模型（通常用数据流图表示），并且在此基础上更准确、 更具体地确定工程规模和目标。然后分析员更准确地估计系统的成本和效益，对建议的系统进行仔细的成本效益分析是这个阶段的主要任务之一。可行性研究的结果是使用部门负责人做出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入更多的人力物力
9、。及时中止不值得投资的工程项目，可以避免更大的浪费。 4 需求分析4.1 概述这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。 用户了解他们所面对的问题，知道必须做什么，但是通常不能完整准确地表达出他们的要求，更不知道怎样利用计算机解决他们的问题；软件开发人员知道怎样使用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。因此系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法描述表示系统的逻辑模型。在需求分析阶段确定的系统逻辑模型
10、是以后设计和实现目标系统的基础，因此必须准确完整地体现用户的要求。系统分析员通常都是计算机软件专家，技术专家一般都喜欢很快着手进行具体设计，然而，一旦分析员开始谈论程序设计的细节，就会脱离用户，使他们不能继续提出他们的要求和建议。较件工程使用的结构分析设计的方法为每个阶段都规定了特定的结束标准，需求分析阶段必须提供完整准确的系统逻辑模型，经过用户确认之后才能进入下一个阶段，这就可以有效地防止和克服急于着手进行具体设计的倾向。需求分析是软件工程中的一个重要环节。是关乎软件开发成败的重要因素。现在软件项目中返工开销几乎占了总开发的一半，而导致返工的主要原因是需求分析不明确。从而引发软件开发中的一些
11、列更改。这些更改可能导致浪费大量资源、软件项目无法按时完成等严重问题，所以需求分析是软件设计和实现的基础，是软件项目迈向成功的重中之重。4.2 产物/成果项目阶段/角色项目经理产品团队(BA/BAS/Product M）开发团队TTL/Developer）测试团队(Test Lead /Tester）需求阶段活动：1、建立CQ/QC中的项目目录；2、在SVN中建立项目目录；1、分析项目所需资源，风险等2、预估项目周期产出：1、项目计划(大致时间规划)活动：1、收集整理需求产出：1、需求说明书参与：1、需求分析2、环境分析参与：1、需求分析2、环境分析4.3 需求分析任务简言之，需求分析的任务就
12、是解决“做什么”的问题，就是根据需求调研，全面理解用户的各项要求并准确的表达所接受的用户需求。4.4 需求分析方法4.4.1 原型化原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。原型化方法就是尽可能快地建造一个粗糙系统，这系统实现了目标系统的某些或者全部功能，但是这个系统可能在可靠性，界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性，技术的可行性，或考察是否满足用户的需求等。如，为了考察是否满足用户的需求，可以用某些软件工具快速建造一个原型系统，这个系统只是一个界面，然后听取用户的意见改进这个原型。以后的目标系统就在原型
13、系统的基础上开发。原型主要有三种类型：l 探索型目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。l 实验型用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。l 进化型目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。在使用原型方法是有两种不同的策略。l 废弃策略先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改，形成比较好的思想，据此设计出比较完整，准确，一致，可靠的最终系统。系统构建完成后，原来的模型系统被废弃不用。探索型和实验型属于这种策略。l 追加策略先构造一个功能简单而且质量要求不高的
14、模型系统，最为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。4.5 需求报告需求报告及软件需求说明书，作用在于便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开发工作的基础和依据，并作为确认测试和验收的依据。通过从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决办法和其他信息。通过这些分析，形成一份软件需求说明书 ，此份说明书使开发人员和客户之间针对要开发的产品内容达成协议。客户需要评审此文档，以确保内容准确完整的表达其需求。一份高质量的“需求说明书”有助于开发人员开发出真正需要的产品。输出：软件需求说明书，格式参照 附录1软件需求说明书4.6 划分需求的优先级绝大多数项目没有足够的时间或者资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求的优先级，因为开发者不可能按照客户的观点决定需求优先级。开发人员将为确定的优先级提供有关每个需求的花费和风险的信息。在时间和资源的限制下，关于所需特性能否完成或者完成多少，开发人员
