软件开发流程

快视信息软件开发流程规范：

用户需求：软件项目首先由客户经理(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

系统测试计划

在SRS阶段完成后一般安排比较很短的时间进行UTP、STP的写作。即单元测试计划、系统测试计划。这两个需要输出提交的是两个表格。单元测试计划按预置条件（即需要设置的先决条件）、输入、期望的输出、实际的输出这样设计的表格来填。即每个单元测试用例都按这样的黑盒测试方法来写。另外还有一种需要编写测试代码来进行测试用例的设计，即对每个被测类需要设计一个测试类，用这个测试类来调用和驱动被测类的数据成员和方法，然后给出断言。测试用例的设计同一个主要功能的要多设计几个例子，对异常也要设计用例进行测试。尽可能多的覆盖。STP 是在单元测试基础之后用的，是项目组把产品交到专门的测试部门前的项目组的联调和测试。这时需要写出系统测试计划。为了到后面单元测试阶段和系统联调阶段使用。这两个文档也需要按照前面的方法和流程进行Review（评审）、汇总、会议评审、修改返工、定稿。最后关闭这个阶段。也按前面的方法需要进行所用工时的填写。QA和PM进行分析。

QA

Quality Assurance

质量保证

四、SD阶段

System Design

系统设计

这个阶段是逻辑设计阶段。按照前面的SRS文档，一般一个人连续性地负责前面PM在项目开工会分配给你的一个需求的各个阶段的设计和其他工作。进行LD文档的写作。要非常具体，比如按照前面设计出的SRS文档中的一个需求，这个阶段你需要设计出具体的数据结构，要设计出哪些类，每个类的各个数据成员是什么，是什么类型的，每个类要设计哪些函数，函数要很具体，函数名称、返回值，参数（输入参数、输出参数），该函数由谁来调用它，它又由调用了哪些函数，函数的具体处理过程要写成伪码的形式。这个阶段需要使用Rational Rose

画出设计出的每个类的成员和函数。以及类之间的关系。这个阶段的输出就是LD文档。也按前面的方法进行Review（评审）、汇总、会议评审、修改返工、定稿。也进行工时的记录和统计、分析。

五、CODE阶段

SRS、LD阶段完成后，在CODE(编写代码阶段)就比较容易和轻松了。只需要找到添加代码的地方，然后写上标志，比如

Begin infoX–MDSP V200102 2006-9-1 liuyongping add(modify,delete)

代码

End infoX–MDSP V200102 2006-9-1 liuyongping add(modify,delete)

Add表示中间这段代码是你写的，modify表示是你修改的，delete表示你把这段代码删除了。然后参照前面设计的LD文档，编写代码。对每个类、每个类成员的命名都要符合规范，比如类成员以m_开头。对每个类对象（变量）命名也要符合规范。尤其需要注意指针的使用，好的程序也是灵活使用指针的程序，对内存的申请、释放一定要小心。最后编出的代码自己首先要进行编译、调试、保证自己添加和负责的这一部分编译通过。然后正确无误才能合入配置库。要对合入配置库的代码进行负责，因为配置库中的代码是大家一个项目一起使用的代码，只要你的有编译错误，然后大家再此基础上Check Out出来的代码肯定不能编译通过。但是逻辑错误允许有，这些逻辑错误在后面的单元测试和系统测试中会暴露出来，到时修改掉错误，重新合入配置库。在Code阶段，每个人完成自己的代码写作后，需要相互进行代码走读，代码走读阶段能发现一些问题，这些都要进行记录统计和分析，然后要不允许留一个错误地修改掉。代码的格式一定要符合规范，格式要对齐，需要有一个空格的地方不能没有空格或者多一个空格。要求很严，这样代码比较整齐、规范、可读性强。对自己新设计的文件，在文件头有说明，说明文件名，作者，创建时间，修改时间，功能。对函数都要有说明：返回值，输入参数、输出参数（没有输出参数的不写该项），功能。文件的命名也有规范。能不重新创建文件的就不进行重新创建文件，完成同一功能的放到同一文件中。对重要和难懂的地方可以简明扼要地加点注释说明。

六、UT（unit test）：单元测试阶段

在产品所有代码编译通过的基础上，按照前面的UTP设计的测试用例进行测试。主要检查主要功能性测试用例和异常测试用例的测试结果，看是否达到了设计目的，与设计是否相否。对测试的结果要进行记录和填表，反馈给代码编写人员，然后代码编写人员修改错误，并把修改方法和修改结果报告给测试人员。这个属于项目组内部自测，一般自己测自己的。一般自己测出来问题修改掉合入配置库即可。

七、ST：System Test系统测试阶段

联合测试，系统需要与其他系统进行通信和连接的，这时把其他系统安装好，然后与我们的系统进行对接，在配置好后，从其他系统进行数据模拟和交互来测试所开发产品系统的功能和性能、结果等。记录测试结果，并修改错误，最后合入配置库。

八、打包、归档、转交测试部进行测试

在以上各个阶段完成后，且软件系统的缺陷率满足项目设定和要求的情况下，项目经理进行项目版本的打包、归档，归档以后这个版本就不能更改了，在测试部测出Bug后，需要走测试电子流填单经过测试经理审核、项目经理审核、定位人员进行问题定位、解决问题人员写出修改Bug或者错误的方法，然后经项目经理审核修改意见和方法正确后，授权和指定一个修改人员进行修改，这时项目经理会通知配置管理人员给该修改人员开放配置库修改权限。这个修改人修改后先自测、再让测试部人员重新测试正确后，最后才合入配置库。归档后提交给测试部的有编译过的代码文件、用户使用说明书（即如何安装、配置和环境的说明，让测试部的人员模拟最终用户使用该产品的软件）。一般测试部能发现很重要和大部分Bug，在最后少于缺陷率的情况下，标志着该产品软件符合质量。这个阶段主要是测试部测试人员测试，项目组人员进行问题单的定位和修改。

在经过以上各个阶段的严格流程后，在QA进行文档审计和质量指标收集、统计、分析后，认为该产品软件满足设计要求，符合CMM质量指标之后，还需要有TM(测试经理)的测试结果报告及产片合格报告之后，该产品软件才可进入市场，交于最终用户使用。在产品上线运行后，出现个别错误后，可以填单，项目组定位、修改后，可进行打补丁。

推荐使用的项目开发工具和管理工具如下：

Visual Source Safe(VSS) 配置库管理工具

Source Insight 代码编写和阅读工具，对每个类的视图和函数代码显示和管理比较好。

Visio 要熟练使用，会画流程图和对象序列图。

Rational Rose 要会使用此工具进行画出每个类的类图（包括类数据成员和函数），及类之间的关系。

Beyond Compare 代码比较工具，查看代码变化，包括新增、删除。

还需要制作一些统计表格，要带有智能化，即使用VBScript脚本。能进行自动统计和计算。

缩略语：缩写

英文全称

说明

CM

Custom Management

客户经理

PM

Project Management

项目经理

TM

Test Management

测试经理

CMM

Capability Maturity Model

软件能力成熟度模型

WAP

Wireless Application Protocol

无线应用协议

URL

Uniform Resource Locator

统一资源定位器