ISO评审过程记录
|
版本 |
V1.0 |
||
|
创建者 |
XXXX |
创建时间 |
2013-02-27 |
|
修改者 |
修改时间 |
||
1、项目获得的形式：
是否进采取了招投标的形式？
如果回答通过招投标的形式较好，因为对招投标这个流程没什么可考察的，如果回答没有走招投标的形式，评审员会问什么问题未知。
2、进度控制(MPP)的制定时机：
项目评审通过之后就应该编写项目进度文件了，而不是需求分析之后采取编写。
3、概要设计的确认工作：
评审员可能会采取反问的形式，举例：软件项目的概要设计客户可能都看不懂，你们也要拿去确认吗？概要设计肯定是要做确认工作的，可以这样解释：我们的概要设计采取的是用户语言(自然语言而不是程序语言)，并且概要设计里会有大量的图示的形式，很直观，用户很容易能看懂。
4、详细设计的确认工作：
详细设计采取的是内部评审的方式进行，无需客户参与。内部评审的过程记录要有；评审过程中发现的修改项目要记录下来，包含修改的项目、解决方案、在详细设计里体现的部分。
5、开发用的是什么原型：
当初回答的是瀑布模式，审查员也没提出什么异议。
6、国家标准、行业标准、项目标准：
都要有一份列表，列表里特别注意的地方：标准编号里年份信息一定不能太早了，举例某个标准文档编号SL 323-1988,1988年的标准太过陈旧了是不允许的。
编码规范一定要有，每个语言(C#,VB,SQL)都要有,不要混用一套编码规范。
7、整个项目过程中所有的模板文件列表：
需要有一个这样的列表，项目进行的每个环节都应该有模板。
8、进度控制(MPP)的一些注意事项：
进度控制文件里要体现出各种评审的环节；进度控制里任务与任务之间要有前置任务关系，消除信息孤岛。
9、所有的文档的一些注意事项：
版本信息都要体现出来；都要有封皮较好；
10、需求分析注意事项：
把性能要求体现出来比较好；如果有第三方接口的话要写清楚。
11、配置管理的认知注意事项：
这一点答的不太好，需要根据配置计划的标准文件，把配置管理需要管理哪些资料；怎么管理等事情捋清楚。
12、概要设计要与需求分析对应起来，所有需求文档的项目都要在概要设计里有所体现，针对这个问题，推广开来就是所有的项目过程文件都要有前后合理关系。
13、概要设计要体现出软件系统的软硬件运行环境。
14、Bug管理有没有使用工具：
回答的是没有使用工具，采用的是excel的形式进行。
15、配置计划：
配置计划一定要有，要不然会产生不合格项的。
针对配置计划，评审员可能会考一些问题举例：项目组做不做备份呀？备份计划是什么呀？备份的介质是什么呀？(备份一定要注意物理隔离)，备份是手工进行还是脚本化进行呀？(当时回答的是手工进行，评审员没有提出什么异议)。
16、安全机制的控制：
项目组每个人安不安安全软件呀?（回答是公司统一要求每台机器必须安装安全软件，一般个人都是安装的360安全软件）；
整个公司怎么保证项目组的安全呀?(最好回答：软件研发部跟其他部分采取的物理隔绝的形式，其他部分的人员绝对不可以访问开发人员的电脑的，公司外的电脑更是绝对的绝对不能访问开发人员的电脑的)。
附件：
1、软件项目流程参见下图：
