面向对象软件过程质量控制

      软件作为一种逻辑组织，其发展趋势是规模越来越庞大，复杂程度(时间复杂度，空间复杂度)越来越高，求解领域越来越广泛。传统的结构化软件开发方法的求解能力已远远不能满足自然界客观存在的需求，因为面向结构的软件过程所采用的方法是函数或子程序的调用，其所表示的关系是函数或子程序间的依赖关系，用这种方法很难描述自然界中客观对象的属性(attribute)，行为(behavior)和关系(relationship)，而且当用结构化方法所开发软件的规模大到一定程度时，其维护和修改的难度、成本呈指数级增长趋势，软件的可维护性、稳定性、可靠性急剧下降，直至令人无法忍受。这给面向对象的软件开发方法和过程提供了生存空间、机遇和环境，因为面向对象的软件开发方法是通过对象(object)这样的逻辑实体，用类似于人类思维和自然语言的方式来摸拟和描述自然界中客观实体的属性、行为和相互关系。面向对象软件开发方法的任务是要表达对象的属性、行为和对象间的相互关系，是对自然界的逻辑摸拟，但是，如果对面向对象的软件开发过程不加以系统管理和有效控制，很难保证软件开发质量、进度和成本在可接受的控制范围之内。软件开发正在走向工程化，软件被看成是软件工厂生产、制造出来的产品，所以把ISO9001:2000过程质量控制的理念应用于软件开发过程， 用工程化的方法来组织和运作软件开发、控制软件质量水到渠成了。

      按ISO9001:2000过程的定义，面向对象软件过程需要有过程客户、过程目标、过程环境、过程输入、过程处理、质量检验、过程输出等过程元素。

      面向对象的软件开发过程可分为获得需求、需求分析、架构设计、详细设计、编码、测试、维护七个阶段，每个阶段又可看成是一个子过程，每个子过程又包含了一系列的活动(activities)。七个子过程按顺序依次相连，每个子过程的输出是下一个子过程的输入。每个子过程是其下一子过程的原料供应者，同时又是其上一子过程的客户。关键子过程(KPA)是需求分析子过程、架构设计子过程和详细设计子过程。

      面向对象的软件过程的终目标是：软件不但能够满足客户的当前需求，而且还要能够满足未来客户需求变化的需求，还要适应未来软件运行支撑环境的发展和变化， 所以，开发的软件要具有很好的演化能力来适应这些变化。 面向对象软件过程的终客户是软件使用者及相关利益人。

       子过程内部客户是需求分析子过程中的系统分析师。内部目标是充分获取客户需求，可能是合理需求，也可能是不合理需求。参加人员有：客户需求调查员，领域专家，系统分析师。子过程输入是软件开发合同、协议和可行性论证。子过程处理活动：调查员和系统分析师到甲方进行客户需求调查和采访，必要时请领域专家(可能来自第三方，也可能来自甲方)参加。获得客户需求的途径有：采访录音(征得甲方同意)，填表格，观察甲方现场工作情景，画用例图(use case diagram)，制作原型(prototype)等。将获得的客户需求以文字、图表的形式记录下来，并让客户进行验证和确认，可修改，直至客户认可。获取用户需求过程中的一条原则是不争论，不分析，把用户提出的需求都记录下来。所获得的原始客户需求是获得需求子过程的输出。

      内部客户是架构设计子过程的软件架构师。内部目标是充分表达出客户的必要合理需求。参加人员有系统分析员和领域专家。内部输入是获得需求子过程的输出，即所获得的原始客户需求。需求分析活动有：系统分析员运用自己所掌握的系统分析技术、软件工程知识、经验、技巧，在领域专家的协助下，对原始客户需求进行需求技术分析和论证，归纳客户的合理需求，去掉不合理的需求，增添客户没提到的必要合理需求，并形成客户需求规格说明书(requirement specification)。子过程的验证和确认工作由客户和系统分析员共同完成，验证的指标是：分析得到的客户需求的充分性、合理性、必要性、完整性、前瞻性。子过程的输出是：用例图(use case diagram)、协作图(collaboration diagram)、分析类图(analysis class diagram)、需求规格说明书。需求分析子过程是面向对象软件过程的关键子过程(KPA)，因为面向对象软件过程是用例(use case)驱动的，面向对象软件过程的一切子过程都要围绕满足客户需求(ISO9001:2000的客户至上原则)来运作，而用例(use case)是反映和描述客户需求的，所以若需求分析做不好，将直接影响到软件的终质量，软件无法满足客户需求，导致软件开发失败。

      内部客户是详细设计子过程中的设计师。内部目标是获得所开发软件的健壮的(robust)软件架构。参加人员是软件架构师。内部输入是需求分析子过程的输出。子过程的处理活动包括：软件架构师根据上一子过程生成的用例图、协作图、需求规格说明书、分析类图，运用软件架构设计知识和经验设计出所要开发系统的软件架构(software architecture)。软件架构的设计粒度是构件(component)，构件是可分布的物理单元，只要不同的构件实现了相同的接口，那么构件可以相互替换。保证架构设计质量的准则有：构件本身要保持高内聚性(high cohesion);构件间要保持低耦合性(low coupling);定义构件间的通讯机制(同步、异步、本地调用、远程调用)和通讯协议;构件内部类与类间的依赖关系和方法调用要做到对构件外部来说是透明的;每个构件只留有适量的接口供其他构件调用;设计构件的接口时，既要使构件间的交互方便，又要隐蔽构件内部的细节信息， 这样做的好处是降低面向对象软件过程的复杂度，提高对软件过程的可控制程度和软件的安全性，可运用代理(agent)或门面(facade)设计模式来设计和实现构件;把软件相对较稳定部分做到架构里，这包括软件的核心功能性需求和大部分非功能性需求。软件架构的设计准则可提高和保证软件的健壮性，另外使用已有的软件架构风格(software architecture style)也可提高软件的健壮性，如：管道过滤器(pipe filter)、顺序批处理(batch sequential)、分层(layers)、黑板(blackboard)、解释器(interpreter)等。面向对象软件过程是以架构为中心的，架构是软件的生命基线和骨架。架构设计子过程所设计出的健壮的软件架构能够保证软件的持续改善(continual improvement)，这是软件开发的高境界，也是具有挑战性的领域。 因为客户的需求是时间的函数，是随着时间变化的，而且软件运行的软硬件支撑环境也在快速发展和变化着，如果软件没有一个健壮的架构，那么软件将很难根据客户需求的变化进行扩展和维护，且软件的安全性、稳定性、可靠性、可复用性也很难得到保证，这些都是客户无法接受的，所以按ISO9001:2000的以客户为中心、客户至上的原则，设计健壮的软件架构是极其必要和重要的。架构设计子过程的内部输出有：构件图(component diagram)、分布图(deployment diagram)。子过程的检验标准是软件架构美好的可视性(安全性、稳定性、可靠性、可复用性、可维护性、可移植性)，验证和确认由架构师和系统分析师做，方法是测试已生成的软件架构，根据架构设计准则来衡量架构是否满足终用户的主要的功能性需求和大部分非功能性需求。

      内部客户是编码子过程中的程序员。内部目标是设计良好的类、类与类间的关系。参加人员有设计师和架构师。子过程的输入是架构设计子过程和需求分析子过程的输出。 设计处理活动：设计师运用面向对象分析与设计知识、经验和技术，设计结构良好的类、类与类间的关系。保证面向对象设计质量的经验准则有：类(class)是一级抽象，即它可直接实例化出对象(object);类元(meta class如：模板类)是二级抽象，即它直接实例化出来的是类而不是对象;类要保持高内聚性(high cohesion)，类与类间关系要保持低耦合性(lowcoupling);类本身的接口是类的方法的可视性(public、protect、private);定义类间的消息通讯机制(同步、异步、本地调用、远程调用)和协议;运用专家、控制者、创建者等类职责分配模式确定类的职责(类的方法);必要时使用设计模式，一设计模式是某类软件设计问题的通用解决方案，如：适配器、代理、装饰器、门面、组合、抽象工厂等设计模式，使用设计模式可提高系统的安全性和效率，但同时也增加了系统的复杂性，所以，是否使用设计模式要根据实际情况，权衡利与弊;接口类的作用是推迟实现与绑定，为提高系统的灵活性和可扩展性，可适量使用接口，但使用接口会在某种程度上增加系统的复杂性和降低系统的效率;不要仅仅只为了代码复用而使用类继承， 因为继承是强的类间耦合关系， 所以这种复用是糟糕的复用， 得不偿失;尽量避免使用多重类继承和多层类继承， 因为多重类继承和多层类继承在父类的方法重名时易导致混乱和难以理解;为类的方法设计算法时，要衡量算法的时间复杂度和空间复杂度，使两者被控制在可接受的范围之内;设计时用的建模语言，如UML在不断地发展和完善，还有一定的局限性，所以在设计时对UML目前还无法表达出的设计思想要采用适当的方式记录下来，使设计不被建模语言的局限性所限制;在详细设计子过程做得足够稳定后才过渡到编码子过程， 因为设计结果的易挥发性会导致后续子过程的混乱不堪、危机重重，甚至无法继续进行。详细设计子过程的输出是设计类图(design class diagram)、对象状态图(object state diagram)以及相关设计文档。设计子过程的验证和确认工作由架构师、系统分析师和设计师完成，根据设计准则来测试已生成的设计成果是否满足终用户的功能性需求和非功能性需求，以检验设计的有效性。