| 软件研发过程 |
| ASE上海的软件研发过程如下。 |
| 软件研发流程图 |
 |
|
 |
| １．制定项目计划 |
| 项目启动后，要制定一系列的项目计划来进行项目管理，共包括以下一些内容： |
1） 定义职责表
2） 资源使用计划
3） 培训计划
4） 规模估算和工作量估算
5） 工作进度计划
6） 风险管理计划
7） 计划的审核 |
|
|
| ２．解析要求书 |
| 要求书是由客户提供的一种文档，包含了对客户需求的一些简单的描述。在收到客户的要求书以后，应该以此文档为出发点去理解客户的要求。在理解的过程中，可以使用包括Notes和Email在内的各种手段同客户保持沟通，这将非常有利于准确地把握客户的要求。把客户原本非常简单和粗略的要求转化成详细，充实，准确的需求，并最终反映到确定书中去。 |
|
|
| ３．做成确定书 |
| 在完成”解析要求书”的步骤以后，可以着手进行确定书的制作。这一步骤所作的工作带有设计的性质。而设计工作的依据就是”解析要求书”步骤中所得到的客户需求。确定书既包含对”解析要求书”步骤中得到的需求分析结果的描述，也包含了根据需求分析所作出的详细设计的描述。（具体内容在《系统设计》一文中已经详细说明） |
|
|
| ４．做成CheckList |
| CheckList的目的是供开发人员在开发完成以后进行单体测试所用。公司对单体测试采用的方法还是黑盒测试的方法，开发人员在制作CheckList的时候还是以确定书为出发点，侧重于被测软件的功能正确实现与否。 |
|
|
| ５．编写代码 |
| 公司目前进行开发的项目使用了多种开发工具和语言，包括C++,VB,.Net。在项目开发过程中每个开发人员都必须遵循适当的编码规范，这对项目开发的规范性以及以后的可维护性都有重大的意义。 |
|
|
| ６．做成TestCase |
| Test Case的制作由测试人员负责，并作为后续”测试”步骤的基础，由于在”测试”步骤中采用的也是黑盒测试的方法，所以测试人员也是以确定书为出发点，旨在检验软件的功能是否被完整，正确的实现。 |
|
|
| ７．单体测试 |
| 单体测试是由开发人员根据先前拟定的CheckList，对每个模块进行测试。 |
| 当测试用例造成模块输出的实际结果与预期结果不匹配的情况时，存在两个可能的解释：要么该模块存在错误，要么测试用例不正确。为了将这种混乱降低到最小程度，应在测试执行之前对测试用例进行审核或检查。另外，程序员不应测试自己编写的模块，而应交换模块进行测试，但对模块的调试还是应当由程序员本人进行。 |
| 最后要注意，单体测试的目的不是证明模块能够正确地运行，而是证明模块中存在着错误。 |
|
|
| ８．软件代码检查 |
| 软件开发人员在编码的过程中需要进行代码检查。因为错误发现的越早，改正错误的成本越低，正确改正错误的可能性也越大。 |
| 所谓代码检查，是以组为单位阅读代码，它是一系列规程和错误检查技术的集合。 |
| 代码检查的优点在于：A.一旦发现错误，通常就能在代码中对其进行精确定位，这就降低了调试的成本。 B.这个过程通常发现成批的错误，这样错误就可以一起得到修正。 |
| 在典型的程序中，代码检查通常会有效地查找出30%-70%的逻辑设计和编码错误。但是，这些方法不能有效地查找出高层次的设计错误，例如在软件需求分析阶段的错误。 |
| 代码检查的关键是使用检查表来检查程序是否存在常见错误，常见的错误有： |
1） 数据引用错误
2） 数据声明错误
3） 运算错误
4） 比较错误
5） 控制流程错误
6） 接口错误
7） 输入/输出错误
8） 其他检查 |
| 最后，不但代码检查对新开发的程序有着不可估量的作用，而且对于更改后的程序具有相同的作用，甚至更大。根据我们的经验，修改一个现存的程序比编写一个新程序更容易产生错误。因此，除了回归测试方法之外，更改后的程序还要进行代码检查。 |
|
|
| ９．综合测试 |
| 完成了对程序的单体测试之后，整个测试过程才刚刚开始。即使完成了一次非常完美的单体测试，仍然不能保证已经找出了程序中的所有错误。因此需要通过综合测试来进行更高级的测试。综合测试主要包括以下几方面（具体内容在《综合测试》一文中已经详细说明）： |
1） 功能测试
2） 系统测试
3） 验收测试
4） 安装测试 |
|
|
| １０．正式发布 |
|
|
|
| １１．编写最终文档 |
| 在某些项目中客户要求开发方提供一种最终的总结性文档，一般被称为式样书。 |
|
|
| １２．应用说明 |
| 以上内容适用于开发作业中的一般应用场景，各开发小组在实际应用时，会根据客户要求做适应性调整。 |
|
|