对软件项目治理的探讨(1)(1)(3)
2015-11-23 01:06
导读：1、软件质量保证计划 在进行软件开发前，需要有一个《软件质量保证计划》。目前较常用的是ANSI/IEEE STOL 730--1984，983--1986标准，包括以下内容： 1.计划目
1、软件质量保证计划
在进行软件开发前，需要有一个《软件质量保证计划》。目前较常用的是ANSI/IEEE STOL
730--1984，983--1986标准，包括以下内容：
1.计划目的
2.参考文献
3.治理
3.1.组织
3.2.任务
3.3.责任
4.文档
4.1.目的
4.2.要求的软件工程文档
4.3.其他文档
5.标准和约定
5.1.目的
5.2.约定
6.评审和审计
6.1.目的
6.2.评审要求
6.2.1.软件需求的评审
6.2.2.设计评审
6.2.3.软件验证和确认评审
6.2.4.功能评审
6.2.5.物理评审
6.2.6.内部过程评审
6.2.7.治理评审
7.测试
8.题目报告和改正活动
9.工具、技术和方法
10.媒体控制
11.供给者控制
12.记录、收集、维护和保密
13.
培训 14.风险治理
2、质量治理的基本原则
。控制所有过程的质量；
。过程控制的出发点是预防分歧格；
。质量治理的中心任务是建立并实施文件化的质量体系；
。持续的质量改进；
。有效的质量体系应满足顾客和组织内部双方的需要和利益；
。定期评价质量体系；
。搞好质量治理关键在于领导。
3、软件质量因素
正确性：系统满足规格说明和用户目标的程度，即，在预定环境下能正确地完成预期功能的程度。
健壮性：在硬件发生故障、输进的数据无效或操纵错误等意外环
境下，系统能做出适当响应的程度。
效率：为了完成预定的功能，系统需要的计算资源的多少。
（科教范文网http://fw.ΝsΕΑc.com编辑）
完整性（安全性）：对未经授权的人使用软件或数据的企图，系统能过控制（禁止）的程度。
可用性：系统在完成预定应该完成的功能时另人满足的程度。
风险：按预定的本钱和进度把系统开发出来，并且为用户所满足的概率。
可理解性：理解和使用该系统的轻易程度。
可维修性：诊断和改正在运行现场发现的错误所需要的工作量的大小。
灵活性（适应性）：修改或改进正在运行的系统需要的工作量的多少。
可测试性：软件轻易测试的程度。
可移植性：把程序从一种硬件配置和（或）软件系统环境转移到另一种配置和环境时，需要的工作量多少。有一种定量度量的方法是：用原来程序设计和调试的本钱除移植时需用的用度。
可再用性：再其他应用中该程序可以被再次使用的程度（或范围）。
互运行性：把该系统和另一个系统结合起来需要的工作量的多少。
4、软件评审
软件评审并不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。由于在软件开发的各个阶段都可能产生错误，假如这些错误不及时发现并纠正，会不断地扩大，最后可能导致开
发的失败。下面这组数据可以清楚的看出前期的错误对后期的影响。
软件评审是相当重要的工作，也是目前国内开发最不重视的工作。
（1）评审目标
。发现任何形式表现的软件功能、逻辑或实现方面的错误；
。通过评审验证软件的需求；
。保证软件按预先定义的标准表示；
。已获得的软件是以同一的方式开发的；
。使项目更轻易治理。
（2）评审过程
A、召开评审会议：一般应有3至5人参加，会前每个参加者做好预备，评审会每次一般不超过2小时。
（科教作文网http://zw.ΝsΕAc.Com编辑整理） B、会议结束使必须做出以下决策之一：接受该产品，不需做修改；由于错误严重，拒尽接受；暂时接受该产品。
C、评审报告与记录；所提出的题目都要进行记录，在评审会结束前产生一个评审题目表，另外必须完成评审扼要报告。
