（计算机软件与理论专业论文）结合cmm的web界面开发工具的探讨.pdf

计算机软件与理论专业硕士研究生论文 结合c m m 的w e b 界面开发工具的探讨 专业：计算机软件与理论 硕士生：谢强彬 指导老师：张治国副教授 马仁勇奔步电脑有限公司软件工程总监 摘要 在h he r p 项项目中采用三层架构，w e b 界面的开发在开发流程中占了相 当大的比重。该项目采用c m m 5 来规范项目的整个开发流程，而该开发流程存 在不少不合理的地方如u i 开发人员在书写u l 设计文档的时候，必须把系统分析 员设计的逻辑界面上的元素逐个重新描述一次在文档上；另外对界面元素的修改 必须重新修改文档上的元素描述，也就是修改了两次。为此，我们开发了一个工 具a u t o g e n e r a t o r 来改进w e b 界面开发的流程。系统分析员和u i 开发人员通过 该工具可以把w e b 界面的开发以及文档的生成很好地结合在一起。 关键词：w e b 界面开发，c m m ，开发工具，文档，a u t o g e n e r a t o r 计算机软件与理论专业硕士研究生论文 a 勋o lf o r 黝u s e ri n t e r f a c e m a j o r ：c o m p u t e r s o f t w a r ea n d t h e o r y n a m e ：q i a n g b i n x i e s u p e r v i s o r ：z h a n gz h i g u o v i c e - p r o f e s s o r m i c h a e lm a s q e i nb a m b o oc o d e v e l o p m e n t w i t hc m m a b s t r a c t h he r p a p p l i e s t h r e et i e rs y s t e m s p l i tb e t w e e nt h em a i n t i e rt y p e s ：u it i e r , b u s i n e s sl o g i ct i e r , a n dd a t at i e r ；w e bp a g e d e v e l o p m e n t i nu iu e rt a k e su p m u c ht i m ei nt h ew h o l e d e v e l o p i n gp r o c e s s t h i sp r o j e c ta p p l i e sc m m 5 s p e c i f i c a t i o nt os t a n d a r d i z et h ew h o l ed e v e l o p i n gp r o c e s s ，h o w e v e r , t h e r e a r e m a n yu n r e a s o n a b l e s u c ha sw h i l e w r i t i n gu id e s i g nd o c u m e n t u id e v e l o p e r h a st or e d e s c r i b ee a c he l e m e n ti nl o g i c a ls c r e e np r e - d e s i g n e db ys y s t e m a n a l y z e r ；w h i l em o d i f yt h e e l e m e n ti nu s e r i n t e r f a c e d e v e l o p e rh a s t om o d i f y t h ed e s i g nd o c u m e n ti na d v a n c ea n dt h e nc h a n g et h ee l e m e n t so np a g e c o n s i d e r i n gt h a t w ed e v e l o p at o o lt oi m p r o v et h eu id e v e l o p i n gp r o c e s s t h i s t o o lf a c i l i t a t e ss y s t e m a n a l y z e r a n du id e v e l o p e rt oi n t e g r a t et h eu ia n d d o c u m e n t d e v e l o p m e n tt o g e t h e r s oa st oe l i m i n a t et h eb o r i n ga n d d u p l i c a t e p r o c e s s k e yw o r d s ：w e bu s e ri n t e r f a c e d e v e l o p m e n t ，c m m ，i d e ，d o c u m e n t ， a u t o g e n e r a t o r i l 第一章绪论 1 1 研究背景和意义 第一章绪论 h he r p 系统是为小康之家而设计的，小康之家是中国最大邮政直销服务公 司。该系统的架构运用了三层架构的b ，s 模式，该架构包括表示层，商业逻辑层 和数据访问层。其中表示层旨在为最终用户提供所有的操作界面，在该项目中， 其表示层主要由w e b 页面和表示层简单的应用逻辑组成，而w e b 页面可能为 a s p n e t 页面或h t m l 页面用户主要通过这一层来跟系统打交道。在h he r p 系统中的界面设计全部采用w e b 页面。与逻辑层和数据访问层相比，它的开发 比较琐碎，而且可能由于其调用的底层逻辑的问题而难于开展调试。为此，它已 经成为该e r p 系统开发过程中进度的关键路径中重要一环。 现今，很多软件公司在从事软件开发的时候都没有严格的文档要求，也没有 很严格的开发流程控制，特别是对于描述琐碎而易于变动的界面开发。然而，在 h he r p 系统中，整个开发流程采用了c m m 5 级作为开发规范。与普通的开发 流程相比，该开发流程就显得更严格，而严格的流程中却出现了很多问题，而在 界面开发这一环节就突出了以下两个问题。 首先，在逻辑界面和物理界面的设计的时候，开发人员需要用文档详细地描 述页面的设计，这其中需要把该页面的每个设计元素的特点描述清楚。然而，在 h he r p 系统中，项目采用了m i c r o s o f t v i s u a l s t u d i o n e t 作为主要的开发工具， 而该工具的界面设计部分却没有很好把设计和文档整合起来。为此，系统分析员 和界面开发人员需要使用另外的文本编辑工具例如m i c r o s o f tw o r d 来进行文档 编辑。由于界面设计工具和文档编辑工具的不一致，使得系统分析员在设计逻辑 界面，界面开发人员设计物理界面的时候不得不重新把很多界面设计元素的属性 搬到文档上。然而，对比逻辑界面设计和物理界面设计的文档就会发现，其实很 多元素的描述例如页面的功能，页面上各元素的基本属性在页面代码和文档上的 表现形式都是很类似的，而界面开发人员却不得不重新把逻辑界面文档上的描述 重新照搬到物理界面的设计文档上。这个重复性的文档操作无疑是很费时、重复 第l 页 第一章绪论 和令人厌烦的。可幸的是，这些操作是有规律的，它意味着使用辅助的软件工具 来自动完成该任务是可行的。 其次，根据c m m 5 级里s c m 规范规定，编码必须在设计b a s e l i n e 以后才 能歼展，b a s e l i n e 以后如果编码过程中发现需要修改设计，那么首先得先修改设 计文档。譬如，如果页面中某个设计元素需要修改，那么其相应的设计文档描述 就要修改，然后才能修改该元素。也就是说，该元素的修改，界面开发人员需要 修改两次，包括文档和w e b 页面，这样该过程无疑是熏复和需要改进的。 鉴于以上出现的问题已经很大程度地影响了项目的开发进度，我们开发了一 个针对w e b 界面开发的代码和文档自动生成工具。该工具主要由两部分组成， 它们分别为w e b 界面设计环境，w e b 界面元素的文档描述编辑界面。在w e b 界面设计环境中，它提供了一个用于w e b 页面设计豹i d e ，该i d e 可以生成多 种w e b 界面代码例如a s p x 、h t m l 等等。当设计人员把所有的界面设计元素 进行布局以后，该设计元素就会自动添加到文档编辑界面，然后设计人员就可以 根据该页面的设计在该编辑界面设景和描述该界面。该文档编辑界面的组成元素 是和该项目的文档结构一致的，设计人员可以随意地生成相应的设计文档。通过 这个i d e ，系统分析员和界面开发人员就可以统一地在该i d e 上进行开发，以方 便他们共享他们的开发成果。首先，由于该文档编辑界面是跟w e b 界面设计的 i d e 相关联的，所以系统分析员和界面开发人员就很方便地在文档界面上编辑页 面元素的描述而不需要应用到第三方文档编辑软件；而且该文档编辑是增量的， 这样界面开发人员就不用在下一阶段的设计中重新照搬上一阶段的某些文档描 述。其次如果开发人员需要修改页面元素，他们不再需要首先修改文档，只要他 们打开该页面设计的文件进行页面元素的修改，这样就能同时修改页面上的元 素，文档也能重新地同步生成。该工具是为了改进h he r p 项目的开发而设计 的，然而针对当前的w e b 页面开发工具，它们几乎都没有很好把页面设计和文 档整合在一起。尤其是运用c m m 进行项目控制的开发流程中，设计和文档的不 一致性导致开发人员耗费更多地时间用于文档的编辑和流程控制上。为此，这个 工具将会针对结合c m m 的w e b 界面开发流程存在的问题提出改进的思想和初 步的思想实践。 第2 页 第一章绪论 1 2 研究现状 m i c r o $ o f tv i s u a ls t u d i o n e t 当前，m i c r o s o f t v i s u a l s t u d i o n e t 是a s p n e t 页面的主要开发工具。该丁 具很好地把界面开发和底层的逻辑开发结合在一起而且通过该w e b 界面设计环 境优秀的所见即所得技术，界面开发人员可以很方便地进行页面布局和设置。然 后，像很多其他页面开发环境一样，m i c r o s o f tv i s u a ls t u d i o n e t 并没有把文档 很好地整合到开发环境中。结果，当设计w e b 页面以后，其开发人员不得不通 过其他文档编辑工具例如m sw o r d 把该页面的设计元素重新描述一次。 u m l i 建模 统一建模语言( u m l ) 是在面向对对象设计中用于描述软件设计的。 然而在u m l 建模中，却包含了很少的界面设计元素。于是界面开发人员很 难用u m l 来描述界面的组成和程序的交互。 u m l 图中没有提供用来表示容器和交互对象的元素： u m l 图中没有提供图形元素来识别界面中的交互对象的抽象角色( 例如 显示给用户的信息，从用户接收的信息，触发的动作等等) 在交互系统里经常观察到的某些类别的活动的建模( 例如，重复执行一 个动作【重复性行为】，以任意顺序来执行一套行为以确保每个动作都会 至少执行一次【顺序独立行为，等等】，它们在u m l 图例如顺序图、交互 图和活动图等表示中是很复杂的： 用来表示用户和非交互( 域) 对象之间的数据流程的交互对象是很难在 u m l 图中确定和表示的。 总而言之，u m l 图在界面建模中是很难使用的，即使是非常简单的用户界 面也是很复杂。 基于模型的用户界面开发环境( m b - u i d e s ) 是一种针对用户界面开发的状 态描述方法，它能够以系统的方法来设计和执行用户界面。然而，当前的 第3 页 第一章绪论 m b - u i d e 技术却只能用于设计用户界面而不能运用于程序中。所以，就有了一 条明显的分裂在用户界面的设计和他们底层应用程序的设计和执行。 u ml | 是曼切斯特大学的信息管理组织自1 9 9 8 年开始研究的项目。u m l i 旨在结合u m l 和m 良u i d e 技术来解决界面设计和执行的问题。实际上，个 支持用u m l 设计的界面模型的m b - u i d e 提供了用户界面和它底层应用程序的 必要整合。例如，通过使用单一的建模表示方法，用户界面和它们的底层应用程 序的一般结构和行为能够在设计阶段得以共享。不仅如此，用户界面开发人员能 够通过一个系统和标准的方法来设计用户界面。 u m l i 是u m l 的扩展，这意味着u m l i 比u m l 拥有更多的构造元索。再者， 学习u m l 已经是一项很艰辛的任务，毕竟它有一套用于描述软件系统结构和行 为方面的符号。于是，学习u m l i 就绝对不是一项轻松的工作，这样也许不值得 用于一个界面的建模。然而，交互程序的设计不仅只能用来表示用户界面，也同 样可以用来表示其他方面。所以，学习u m l i 有利于完整的交互程序的建模。 用户界面的设计不仅仅只是包括简单地列出设计元素，它还包括元素的表现 设计，而且很多设计元素在u m l i 中的表示是一样，这样界面设计人员就很难通 过u m l i 来呈现出界面设计的最终成果，这样就很难保证界面设计与系统规定的 风格相一致。所以现今的逻辑界面设计大多是在实际的开发环境中把最终的界面 效果用草图的形式呈现出来，而不是用符号来表示。 动态文档生成系统 现在很多公司组织和研究人员都发现了在项目开发中文档编辑所呈现的问 题，也提出了解决该问题的一些方案，其中一个就是动态文档生成系统。这个系 统运用了对象存储技术，o l e 和c o m + 技术。开发人员通过把文档元素存储到 相应的数据库表格中，然后运用该开发环境中的c o m + 插件来生成文档。它有 以下这些优点： 1 文档组成元素独立地放在数据库中，这样的数据和程序分离就保 证了那些文档元素就能够依照各种各样的文档风格来生成文档。 第4 页 第一章绪论 2 它能很方便地提供一个搜索引擎来搜索所需要地文档元素，这样 开发人员就能轻松地定位到相应的文档元素以供查询和修改。 3 它建立了文档元素和程序代码片断的映射，该映射通过一个链接 呈现在代码元素的附近。这样，当进行代码编辑的时候，只要开发人员点 击该链接就能轻松地定位到该代码片断所相关的文档以进行查询和修改。 然而，这个系统仅仅支持那些支持c a s e 、对象存储、c o m + 技术的开发 环境例如o r a c l e 。无疑这个系统技术的运用范围是很有限的，尤其难推广到界 面开发中，因为很多界面开发的w e b 页面都是使用所见即所得技术的拖拉来完 成而不是用代码编写，这样就很难保证代码和文档链接的一致性。 再者，这个系统的技术只是方便程序员来查询和生成各种各样文档格式的文 档，而对于由总多元素组成的界面设计，程序员仍然需要另外单独地在数据库表 格中进行页面的描述。虽然这个系统能够把元素单独抽出，方便了系统分析员和 界面开发人员之间的文档共享；但是由于数据库表格数据难于很直观的表现出 来，这样就不大方便开发人员进行文档元素的书写和修改。况且页面元素的更改， 除了修改页面上的设计以外还是要另外修改文档。 1 3 研究重点 w e b 界面开发的开发效率已经很大程度地影响了整个e r p 项目的开发进 度。这篇论文通过分析当前w e b 界面开发流程中不合理的地方，以及提出改进 的思想和实践。 从以上的分析可以看出，当前的w e b 界面开发流程中，存在的问题中关键 是没有很好把界面设计和文档结合在一起。这篇论文会探讨一下怎样既能保证 w e b 界面开发的易用性，又能很好把文档结合起来。 第5 页 第二章c m m 概述 2 1c m m 的概念 第二章c l v l l v l 概述 c m m 是软件开发中代表过程管理的观念模型。c m m 由以下五个成熟度级 别组成 1 级别1 ，初始级：软件开发过程是一个混乱和英雄式的过程。只有极少 的过程是被定义和遵从的，而且项目的成功依赖于个人的努力。没有任 何正规的管理控制来进行软件开发。 2 级别2 ，重复级：这个级别展现了一个初步的规范和文档化的过程。对 于成本、进度和功能都建立了基本的管理控制。必要的过程控制规范能 够重复过去某些相似应用程序的成功。从级别1 进化到级别2 意味这公 司已经建立很项目管理控制，建立了一个软件工程过程小组( s e p g ) ， 而且正式引入了软件工程方法和技术。 3 级别3 ，已定义级：这个级别通过对过程参数建立必要的过程管理功能 来提供一个持续的过程改进。这个对于管理和工程活动的软件过程会被 文档化，标准化，以及整合到公司的标准的软件过程中。所有的项目都 使用公司统一的有版本控制的标准软件过程来知道开发和维护软件。 4 。级别4 ，已管理级：软件过程和产品质量的详细度量标准得至b 收集。并 且软件过程和产品能够通过量化来理解和控制。 5 级别5 ，优化级：从过程中得到的量化反馈会用来指导持续的过程改进， 并且领导创意和技术的革新。 级别2 到级别5 被分解为1 8 个关键过程域( k p a s ) 每个k p a 都由五部分组 成，称为共同特性： 1 巍痧约定? 执行能力描述了组织为保证过程得以建立和继续作用所采取 的必要行动。执行约定一般包括制定组织的方针和建立高级管理者的支 持。 第6 页 第二章c m m 概述 2 巍颓能力：执行能力描述为了能实施软件过程，项目或者组织中必须存 在的先决条件。执行能力一般包括资源、组织机构和培训。 3 巍痧的抒霞知执行的活动描述为了实现个关键过程域所必须的岗位和 规程。执行活动一般包括制定计划和规程、进行工作和跟踪，并在需要 时采取纠正措旌。 4 嬲宣瓣9 锄睨测量和分析描述了对过程进行测量和对测量结果进行分析 的需要。测量和分析一般包括为了确定所执行活动的状态和有效性所能 采取的测量的例子。 5 验证巍，异验证执行描述了那些保证遵循已建立的过程进行活动的措 施。验证一般包括管理者和质量保证部门所作的评审和审计。 关键实践( c m m 有3 1 6 个建议) 描述了有利于实现和制度化关键过程域而 做出基础框架和活动。关键实践描述了“应该做什么”，但是却不硬性规定“怎 样去做”。它们不要求使用某个特定的软件生命周期模型例如瀑布或者螺旋模型。 他们不会要求搭建某种公司组织架构。它们不会指定一个进行产品开发的技术方 法或者开发工具。它们仅仅是建议：也就是说，它们不会硬性规定具体的操作。 它们会交由每个独立的公司来决定怎样来执行。c m m 仅仅是一个管理模型，它 给予你一个怎样管理软件过程的指引，但是却不会涉及产品开发的技术方面或者 开发的表现。 c m m 统一了软件开发组，并且提供了以下导引和领导工具，通过它们可以 提高他们管理软件项目的方法： 对软件开发人员应该完成的任务有清晰的了解。 明确所有资源、技能以及知识的工作流程和充分性。 定义那些影响到客户质量的交叉功能过程。 提高公司、过程和产品质量的机会。 2 2b a m b o o 公司的c m m 开发流程介绍 图2 - i 所示是b a m b o o 公司运用于h h e r p 项目的主要开发流程： 第7 页 第二章c m m 概述 需求 图2 - 1b a m b o o 公司在皿e r p 项中的开发流程图 需求管理的目的是为了在客户及软件项目之间围绕软件项目所获取的用户 需求之间建立一致的认识。它的大致开发流程如下： 首先，项目经理负责通过多种途径来收集用户高层的需求，譬如r f p ，用 户建议、客户面谈记录和客户调查结果等。然后用户需求的关键特点他们的依赖 关系要根据用户的需要来进行确认。在确认的过程中，关键的依赖关系和验收标 准都会跟客户磋商，已经在项目计划中文档化。 然后，用户需求就会交由系统分析员进行分析和落实到具体的软件产品中。 测试人员也应该包括在该分析中。项目需求管理小组( 业务分析员和系统分析员) 第8 页 第二章c m m 概述 会根据其分配到的需求部分而进行详细的需求分析，而且这些需求会由业务分析 员在s r s 中文档化，使用s r s 模板或者用例模扳来书写相应的用例文档。 当详细的用户规格说明书完成以后，在需求发布的过程中，项目经历要跟客 户解释和确认需求。然后项目组会通知s e p g ，测试人员和其他相关的小组s r s 文档的完成，所有需求规格说明书文档( 例如s r s 或者用例文档) 会在项目公 布栏上审批通过以及由用户签字确认。 最后，项目跟踪矩阵会更新原来的用户需求，中间工作成品和最终工作成品 的跟踪信息。然后项目经理就要通知s c m 协调人员来b a s e l i n e 已确认的需求规 格说明书。 逻辑界面设计 逻辑界面设计是用来帮助用户更好地明晰他理想的界面模型，修改他的理想 系统并且提出新的界面需求。 首先在软件的架构设计阶段，美工总监设计小组组长设计人员通过高层的 美工设计模板来准备好美工设计的概念，并运用高层的美工设计确认表格来对比 审批该高层的美工设计是否通过。如果该高层的美工设计不能通过审批，那么就 要重新修改来关闭该项工作。然后最终的设计产品必须交由客户来确认通过。当 进行每个模块的逻辑界面的设计的时候，系统分析员必须根据相应的用例来准备 好逻辑界面设计，然后交由客户和业务分析人员进行复查。客户确认以后，项目 经理就通知s e p g 、测试小组和其他相关的小组关于逻辑界面完成的信息，以及 通过i n s p e c t i o n 进行审查。审查以后，项目经理要通知s c m 协调人员来 b a s e l i n e 。 高层设计 高层设计是指架构设计，当需求规格说明书完成分析和b a s e l i n e 以后就会 开始架构设计。在架构设计的过程中，系统分析员和数据库管理员会分析该需求 规格说明书( 如果必要的话就进行修改) 和设计出该系统的架构。系统分析员负 第9 页 第二章c m m 概述 责确认其中的主要组成组件和实体，然后书写高层设计文档。之后，如果客户要 求的话，那么该高层设计文档就会送交客户审阅，以及送往其他利益相关者审阅。 低层设计 低层设计是指实现各个模块里详细的用户需求的详细设计。它包括s d m 设 计，该s d m 设计包含了物理数据库设计，业务对象设计，数据对象设计以及用 户界面设计等等。 首先，系统分析员在设计前应该选择适当的设计方法。然后，系统分析员和 数据库管理员就会基于公司的数据库设计标准来设计逻辑数据库表。数据库管理 员就会根据该逻辑数据库表来设计相应的物理数据库表以及协助系统分析员做 出相应的物理数据库模型。 其次，系统分析员会根据每个需求设计出类和画出它们的交互图。然后该设 计会写成低层设计文档，它包括了s d m 设计文档、d a t a s e t 设计文档和数据库 设计文档等。然后该文档会送往项目经理和其他利益相关人员进行审阅。当它们 通过验证和b a s e l i n e 以后，就会进行物理数据库的设计。相应的m i t ( 模块间 集成测试) 的测试用例设计就会开始。同时，开发人员基于s d m 的设计就会开 始详细的业务对象设计、数据访问对象设计和界面设计。所有的这些设计都都必 须用文档描述和互相进行b u d d yc h e c k 。审阅以后，它们就会被b a s e l i n e 。 编码 当所有的低层设计完成以后，程序员就要根据以上的那些设计分别进行编 码。它同样要求在编码完成后互相进行b u d d yc h e c k 。在程序员重新修改以后， 程序员就会执行相应的单元测试来确认那些代码是否完备和有效。如果单元测试 通过以后，所有的代码就会被b a s e l i n e 。 模块集成测试 模块集成测试是用来测试应用程序相连的部分是否它们的功能能够正确地 执行。其中该相连的部分可以是代码模块，独立应用程序，网络上的客户端和服 第1 0 页 第二章c m m 概述 务器端应用程序等等。这种测试跟那些客户，服务器模式和分布式系统尤其相关。 测试者执行每个文档化的测试用例。当发现错误的时候，该错误会被记录起来， 并且分配给相应的开发人员来修改它。当问题解决后，修改后的代码会被重新测 试，直至该代码对应的需求部分会被完全测试完毕并且不会在其他任何地方产生 问题。当模块集成测试完成后，当前的模块就宣告结束，该模块就会交由s c m 协调人员进行b a s e l i n e 。 以上那些步骤执行于每个模块，然而以上的活动都需要以下这些活动来支持 和控制，而这些活动会贯穿整个项目的开发周期。 同行评审 同行评审是为了更有效地在早起阶段除去软件开发成品中的缺陷。其中包括 了两种类型的同行评审，它们分别是b u d d yc h e c k 和i n s p e c t i o n 。 对于b u d d yc h e c k ，作者会跟项目经理磋商以确定谁是复查人员。然后作 者会跟复查人员共同拟定b u d d yc h e c k 的进度安排。当需要复查的工作成品完 成后，该成品就会送往相应的复查人员来进行复查。在复查期间，该工作成品相 关的环节不应该修改除了需要返工的地方。复查人员应该认真核对复查的标准列 表来复查该工作成品。然后复查人员和作者需要开一个小型的复查会议来确认那 些由复查人员发现的缺陷。在复查会议后应该生成相应的会议记录报告。然后作 者就会根据那些提交的缺陷报告来修改相应的工作成品。当该工作成品完成以 后，复查人员应该跟进并使用b u d d yc h e c k 的报告文档来记录和关闭该活动， 已经交给该报告给项目经理。 对于i n s p e c t i o n ，它是比b u d d yc h e c k 更加正式的同行评审活动，它一般 由3 到8 个人员组成，包括主持人，阅读人和一个负责记录的笔记人。典型的 i n s p e c t i o n 的对象都是文档，例如需求规格说明书或者测试计划。它的目的就在 于发现问题和看看是否有遗漏的地方，但在过程中不修改任何东西。 首先，主持人是整个i n s p e c t i o n 从计划到结束自始到终的负责人。在计划阶 段，相关人员应该执行以下活动： 第1 1 页 第二章c m m 概述 识别那些需要复查的项目( 根据项目计划的要求) ； 项日经理挑选合适的i n s p e c t i o n 主持人( 他应该经过培训和来自开发小 组内部) ； 做出复查计划； 决定i n s p e c t i o n 小组的组成人员： 识别出所有必要的输入文档( 资源、规则和核对标准) ： 检查入口标准； 计划i n s p e c t i o n 的启动会议，准备阶段，缺陷记录会议和关闭阶段； 分配角色和责任，分配相应的进度安捧给i n s p e c t i o n 小组，以及分发工 作成品和其他相关的输入文档给i n s p e c t i o n 小组的成员来复查( 如果主 持人觉得必要，这个可以在启动会议中进行) 相关的工作成品，直至i n s p e c t i o n 完成，都不应该被修改除了返工以外。 i n s p e c t i o n 小组的成员分另n 对其分发的工作成品进行复查，并且每个 i n s p e c t i o n 小组成员都要生成一个自我准备记录，该记录记录了所有的缺陷以及 他们在准备过程中发现d e f e c t 所耗费的时间。当所有的i n s p e c t o r 参加缺陷记录 会议的时候，所有自我准备记录上记录的缺陷都会被讨论。记录人员应该记录所 有被讨论确认为缺陷或者问题的部分以及它们相应的耗时。记录人员应该把 i n s p e c t i o n 报告交由每个i n s p e c t i o n 小组成员传阅。作者应该针对提出的缺陷和 问题对工作产品进行修改。主持人应该跟进那些缺陷的修改情况，并且最后负责 关闭该活动。 系统配置管理 系统配置管理的目的是贯穿整个项目的软件生命周期来对软件项目的所有 工作成品的建立和维护进行管理。它包括系统配置管理计划，系统配置项目识别， 变更控制，系统配置项目状态的统计，配景审批和发布控制。 首先，系统配置管理经理和协调人员需要从项目经理那里获取软件项目计 划，并且随同项目计划一起准备一份系统配置管理计划。当项目经理和系统配 第 2 页 第二章c m m 概述 置管理经理进行复查和同意该计划后，该配置管理计划就会开始被项目管理和控 制。 其次，对于系统配置项目的识别，系统配置管理协调人员应该随同项目经理 一起根据命名规范来识别配置管理项目。当系统配置管理经理对相关的配置管理 项目进行审阅以后，他就会在存储库里创建一个系统级别的架构，然后交由系统 配置管理协调人员在系统级别架构里创建项目架构。 如果需要进行变更，作者应告知项目经理关于该变更以及它的影响。任何人 需要对配置项进行变更都需要提交变更要求，以及在变更请求表格中填写变更描 述部分，然后提交给项目经理和系统配置管理协调人员。项目经理会分配给合乎 要求的人员来分析该改变，已经在变更请求表格中填写对该变更部分的详细评 估。然后项目经理向s c c b 提交变更申请表。然后会进行一个非正式或者正式 的s c c b 会议来决定该变更。对于任何大的变更，正式的s c c b 会议都要举行。 s c c b 要在变更请求表格中填写其变更决定。如果该变更被拒绝，变更就会被关 闭并通知该发起者。如果它被推延了，那么它需要重新评估和批准才能被重新激 活。如果变更获得批准，那么系统配置管理协调人员需要用配置审批报告表格来 进行c h e c k o u t 审批。任何在审批中发现的问题都要报告给s c c b 和采取相应的 行动。系统配置管理协调人员发送审批报告到任何一个相关人员以及填写记录到 配置管理记录中。授权人员就能进行变更修改。 当该变更经过审查或者单元测试以后，s c c b 中负责该变更的人员就会通知 系统配置管理协调人员来关闭该变更。系统配置管理协调人员根据配置审批报告 表格的要求对其进行审查。在审查过程中发现的任何问题都需要向s c c b 报告 和采取相应的行动。系统配置管理协调人员c h e c k i n 该配置项并且把审批报告递 交给相关的人员。系统配置管理协调人员最后要完成配置管理的记录表格。 经过一段时间，一般惯例为一个星期，系统配置管理协调人员就会填写和发 布状况统计表到s e p g 和其他相关人员。然后系统配置管理协调人员就会完成 该配置管理记录表格。 第1 3 页 第二章c m m 概述 对于配置项审批，它有四种类型的审批。当工作产品在b a s e l i n e 前，系统 配置管理协调人员需要进行b a s e l i n e 审批；当有变更请求的时候，需要进行变 更审批( c h e c k i n 和c h e c k o u t ) ；当s c c b 统一发布请求时进行发布审批和物理 审批。此外，系统配置管理协调人员还负责定期地物理审批和负责跟踪所有的变 更项直至它们被关闭。 第1 4 页 第三章结台c m m 的w e b 界面开发及存在问题 第三章结合c m m 的w e b 界面开发及存在问题 3 1 用户界面设计 用户界面设计是指整合了人机对话，操作逻辑和用户界面美工设计于一起的 开发。在不同的软件开发阶段，用户界面设计的流程可能不同。然而在e r p 项 目中，它一般包括逻辑界面设计，物理界面设计，界面逻辑设计和编码以及模块 集成测试。该流程如图3 1 所示 逻辑界面设计 图3 - 1 e r p 项目的界面开发流程 在软件开发的早期阶段，客户对用户界面需求比较模糊，同样他的心里也没 有一个理想的界面模型。这样，用户提出的需求就很难进行量化控制，这样就导 致了很多特性被需求分析人员忽略了。于是当用户角色被完全定义以后，逻辑界 面就会用来辅助客户来尽早地塑造出他心中的理想模型。 其中一个方法就是创建一个最终产品的模拟产品，它跟最终的用户界面的外 观和感观很相似，还加入了很多复杂的交互动作和页面流转。一旦出现这样的模 拟系统，需求分析人员就能把它展示给客户来决定它是否真的跟心里的理想模型 相一致。该原型是可以随意修改的。通过跟客户共同讨论该原型系统的界面设计， 需求分析人员就能及时的发现和进行必要的设计改动。软件原型的频繁开发会导 致软件工程师能够对应用程序的需求有更好的理解，从而促进了系统设计的进一 步完善。 物理界面设计 物理界面设计需要基于逻辑界面设计来运用实际的页面运行控件来设计页 面，该页面可以被最终用户操作并实现需求规定的逻辑。由于逻辑界面设计的界 面元素只是对最终用户界面的简单感观描述，甚至它还可能不是一个运行控件， 第1 5 页 第三章结合c m m 的w e b 界面开发及存在问题 而只是一个贴图而已，所以物理界面设计人员需要根据逻辑界面的设计要求来选 择适当的界面运行控件并组成最终页面。该组件的内部逻辑必须能够保证完成它 所定义的功能。当控件选择完毕以后，如果必要的话，该页面就会交由美工来根 据美工设计要求来装饰页面。 界面逻辑设计 物理界面只是一个空的页面外观的展示，它并不包含实际的运行逻辑，也就 是说当它被用户操作的时候，并不会实现它的内部逻辑，也就是不能完成实际的 需求的逻辑规定。于是它需要补充相应的逻辑来实现某些组件的功能例如按钮和 菜单等。界面开发人员必须根据系统分析员的低层设计和s d m 上的界面设计要 求来调用由业务逻辑开发人员实现的业务对象逻辑来实现需求。通常那些方法的 设计和定义都会明确地在s d m 文档中说明。 模块集成测试 模块集成测试是对模块内的三层对象即界面对象、业务逻辑对象和数据库逻 辑对象进行整体的运行测试，以决定它是否能够完成用例文档的每项要求。当界 面的外观设计以及它相关的业务逻辑的编码和单元测试完成以后，该模块的集成 测试就可以开始执行了。 3 2 蛐e p j p 系统中的界蕊开发问题 基本上，在h he r p 中的界面开发是遵循以上的开发流程的。然而，该项 日的开发严格遵循了c m m 5 级规范的，该开发规范在第2 2 节中有基本的介绍。 如果遵从该规范的流程要求，那么就会出现以下列出的问题： 1 首先，根据c m m 开发流程的要求每个界面的设计都必须用文档详细 地描述出来。h he r p 系统的开发采用的是微软的n e t 技术，而开发人员都是统 一在微软的v i s u a ls t u d i o n e t 上进行开发。该开发环境虽然很好地把界面开发和 底层的逻辑开发很好地结合在一起，但是它却没有提供友好的文档编辑环境。在 该系统的开发中，开发人员都是在m sw o r d 上进行文档编辑的。该文档编辑工 具并没有很好地跟界面开发环境结合在一起，结果系统分析员编写的逻辑界面设 第 6 页 第三章结台c m m 的w e b 界面开发及存在问题 计文档和界面开发人员编写的物理界面设计文档都需要重新地描述界面元素，这 个工作是相当费时的，因为一个页面的元素有几个到几十个不等，而一个模块至 少就有好十几个页面，仅仅是对页面元素在w o r d 文档上用文字描述都需要花费 大量的时间。加上由于文档编辑必须跟公司的文档模板要求相一致，那么开发人 员还需要花费相当的时间在文档的版面布置。而且由于很多页面和页面元素的描 述跟设计界面的设置是很相似的，譬如它们的名字、控件类型、对应的数据库域 等，都可以通过界面的设计直接获取界面的描述信息填写到设计文档中。为此这 些都可以通过跟界面的设计与文档编辑的结合来提高文档的编写速度，从而有效 地缩短文档编写的进度。 2 根据c m m 开发流程中s c m 的规定，当需要修改设计的时候，必须先 修改文档，然后才能修改相应的设计。譬如，当需要修改一个元素从文本框修改 为标签的时候，它需要修改名字、控件类型以及它的长度限度。一般情况下，界 面开发人员需要先修改在文档中该元素的控件名字、控件类型和长度描述，然后 再修改它的界面设计。这样无疑是重复进行了两次操作和需要更好地改进。 第1 7 页 第四章改进方蹇 4 1 改进思想 文档和程序结合的概念 第四章改进方案 如果对以上提出的开发过程中出现的问题进行进一步分析就会知道是界面 开发中文档的编写效率造成了界面开发进度的一大瓶颈。为此，接下来我们将会 探讨一下如何来通过文档和程序的结合来消除或者缓解这个开发瓶颈。 对于一个优秀的文档系统，它应该具备以下特点： 它能够准确地描述该软件系统，而且该文档内容容易理解； 能够迅速定位以方便地进行分析和修改； 能够提高软件的维护质量； 在修改程序的时候，能够很好地帮助开发人员理解系统。 为此提出了程序与文档合一的概念。这概念使软件成为真正意义上的软件： 程序+ 文档，程序就是文档，文档集成在程序中。它要求在选择开发环境时不仅 要考虑环境对设计、开发的完美支持，而且要考虑对维护、文档的支持；它要求 软件人员在设计、开发过程中要考虑维护问题、文档问题；它要求程序与文档存 储在同一位置、同一系统中；它要求使用相同工具进行程序与文档的书写、检索； 它要求在编写和维护程序的同时形成文档，在书写文档时编写、维护程序。程序 与文档合一的概念不仅存在于系统的设计、开发阶段而且存在于系统的维护阶 段，它贯穿软件的生命周期。 动态文档系统是建立在程序与文档合一的概念基础上的、文档与程序一致 的、简单易懂的联机文档系统。它包括构件说明与数据描述、对构件与构件之间、 构件与数据之间的关系进行的描述。动态文档系统是提高了文档的可用性、易用 性和连贯性，使文档更加有效，是解决维护问题的有效途径。 为了实现以上的构想，需要解决的问题是：软件文档的内容划分与获取、 文档的存储与维护、文档的检索、软件文档的生成打印。 第1 8 页 第四章改进方案 一、软件文档的内容划分成：语义文档、结构文档、过程文档 语义文档是对软件的功能、概念、总体设计、流程、规约等用自然语言的描 述，是软件人员根据规范在使用c a s e 工具编写并填入程序的文档，它也是为 更全面的解释文档而灵活加入的额外信息。 结构文档是在软件设计工具、开发环境中对象的属性、构件间接口、构件间 引用关系、软件的结构等的描述。利用词法、语法分析程序对整个系统的对象、 构件进行识别、分析，获取上述描述并形成表格文件。 过程文档是对软件的设计、编码、维护过程中形成的过程描述和程序注释， 如设计目的、设计人、时间等说明，利用开发环境对软件人员在设计、开发、维 护过程中操作的记录形成操作跟踪。 二、程序与文档的统一存储与维护 根据程序与文档合一的概念和文档从程序中提取的要求，文档必须存放在程 序中，甚至文档固有的源代码中。结构如此的程序源代码的存储必须采用一种新 技术一对象仓储( r e p o s i t o r y ) 技术，而不能采用流式文件，这样才能使程序与 文档既结合又分离。程序与文档结合在一个对象仓储中，结合在统一的开发环境 中：结合在修改代码时可以同时修改文档、修改文档时可以同时人工检查和修改 程序，并在多次文档生成而不会丢失手工输入的文档。程序与文档应当分别存放 在对象仓储中的不同表或不同的字段中，在编译与运行时分离。 三、文档的检索 对单个对象、构件文档的检索方式是若于文档存放在一个对象仓储中，它可 以随源代码一起检索和维护。这种检索给分析和维护单个构件、对象提供文档支 持。建立多种视图、编写程序对整个系统进行文档的检索和获取，完成对整个系 统的分析，对整个系统进行实时文档支持。这将在例子中较详细的描述。 四、软件文档的生成打印 编写程序检索和获取整个系统的文档，按照国家软件标准的文档式样建立文 档模板并将按模板生成文档和利用文字处理软件强大的功能进行创建、编辑文档 并打印。 第1 9 页 第四章改进方案 a u t o g e n e r a t o r 系统是为改进h he r p 项目的界面开发流程而开发的。在 h he r p 项目的开发过程中，界面开发人员首先需要书写界面设计文档然后基于 界面设计文档来书写界面的页面代码。这样同样的设计信息在文档里就重新搬到 了界面的页面代码了，例如页面的元素定义，页面的布局等。在此过程中这些冗 余的操作的工作量是很大的，而且那些冗余的工作很容易让开发人员感到厌烦。 为此我们开发了一个a u t o g e n e r a t o r 系统来改进该流程，如图4 - 1 所示，整 个a u t o g e n e r a t o r 工具能够把逻辑界面设计、物理界面设计和部分的界面逻辑整 合在一起，系统分析员和界面开发人员通过这个工具设计出相应的逻辑界面和物 理界面以及输入部分界面逻辑代码相关的信息，然后就能够输出相应的界面设计 文档，界面的页面代码包括完整的a s p x 页面和部分的v b n e t 代码。 4 2a u t o g e n e r a t o r 的概述 图4 _ 1 改进的思想 这个工具分为文档信息编辑界面( 如图4 2 所示) 和w e b 界面设计环境( 如 图牟3 所示) 。w e b 界面设计环境提供了一个用于w e b 界面设计的布局面板。 它包含了三个窗体，它秆】分嗣为w e b 页面布局设计面板，属性窗口和控件栏。 w e b 页面设计环境相当于一个可以用来布局页面元素来组成一个w e b 页面 的设计面板，它跟一些商业w e b 界面设计环境例如d r e a m w e a v e r ， v i s u a l 第2 0 页 第四章改进方案 s t u d i o 是很类似的。对于摆放到容器里的每个组件，系统会实例化一个约束对象 或者产生一个约束值，它们都附有相应的信息来表示该布局环境怎样来规范每个 控件的大小和位置。而约束对象或者约束值的类型的创造取决于使用的布局管理 器的类型。设计环境会显示每个控件的相关约束信息，然后设计人员就能够对它 们进行编辑，就像这些约束信息是它们的内部固有信息一样。就g r i d - l a y o u t 来 举例而言，很多小格会分布在顶层面板中，当用户操作一个控件到面板的时候， 它就会自动地被摆放到它最坐落的格子里，这样控件就会很容易地通过表格的规 则位置来进行对齐。控件栏里列出了在h he r p 项目里可能用到的控件。它们 分为四种类型，分别是h t m l 控件、w