|
首先您是否将其识别为:在实现软硬件(系统集成)前,“需要鉴定和确认其能力的过程(术语3.4.1注3;7.5.2)”? ?我们暂且不定义为“特殊过程”。因表述的术语和标准本身的定义就有矛盾。。识别为““需要鉴定和确认其能力的过程”比较恰当。
; X$ X* K' I: U4 P$ g# I1 B3 P* j) T
我的意见是存在这些“过程”!
+ y" x& E: \0 r4 D8 E! P- Y0 s. ~/ U! X4 p& b, Z
在类别为(33.01.00,33.02.02,33.06.00)计算机软、硬件提供中,确实存在着标准术语3.4.1注3;7.5.2所定义的“过程”。实际上,软硬件服务的提供组织在项目开发和实施前,都必须根据项目的复杂程度、规模、所涉及的技术领域、技术难度等方面,挑选、确认项目的人员配置、开发和实现的资源配置,建立模型和流程、确定采用方法、选择软件工具等。并对其进行“能力鉴定”,“确认”能力满足要求后才与安排!
! s1 F; h4 d; b9 a, J+ W 即使这样控制,也难免在产品交付后还有“BUG缺陷”显现出来(其实,世界上就没有无缺陷的软件产品和它的载体---硬件系统)!7 a3 G+ |, Y& @0 N; i* h
所以,我的意见是 软硬件开发企业不能删减7.5.2 !删减后不能确保有能力实现7.1,7.5.1策划的结果。& C/ V* n. u9 h+ |9 C$ N
有盆友提出用“模拟”来控制“错误和缺陷”的发生,也可能对小型的软件系统可行,对大型的系统软件和软硬件集成的系统如何用“模拟”来控制BUG? 由于软硬件集成的系统的唯一性、使用场地和用途的特定性,除特别重大的项目外,目前尚无组织在系统安装实施前先在组织内部搭建一个模拟环境来验证控制。毕竟,模拟的环境不能替代软硬件集成的系统的唯一性、使用场地和用途的特定性环境!1 Y, ^( h/ `' j
9 T8 J' h! s" s) V( H
windows系统从WIN32到目前的WIN8,一直在通过“补丁”和升级来纠正交付后运行中才发现的BUG(缺陷),就是典型的案例。microsoft 公司对软硬件开发、实施人员的能力、开发模型、流程、方法和工具的控制已经非常严格,但还是免不了“BUG缺陷”出现。。。。2 g2 Q- b; l/ A$ e$ T7 c
( d$ n& q# O8 @/ \6 b, T) F
以上意见仅供参考。欢迎讨论! |
|