关于实施RUP软件过程控制的方法和标准[只是一个个人总结]

第一部分:了解软件过程

 

1 引言

 

　　软件过程（Software Process）是人们建立、维护和进化软件产品整个过程中所有技术活动和管理活动的集合。目前，软件过程技术是一个非常活跃的研究领域，吸引了大批来自学术界和工业界的专家和学者。从1984年起每年有软件过程国际研讨会（ISPW），从1991年起开始召开软件过程国际会议（ICSP），每个国家几乎都有自己的软件过程改进网络（SPN）。软件过程技术的研究主要有三个方向：

 

（1）软件过程分析和建模。软件过程建模方法是软件过程技术的起点，其中形式化半形式化建模方法有基于规则的，基于过程程序的等等。过程分析和过程建模对于保证过程定义的质量、建立全面和灵活的过程体系具有重要的作用。

 

（2）软件过程支持。软件过程支持主要是指研究和开发支持软件过程活动的CASE工具，过程支撑工具作为一种技术基础设施能够很好地支持、管理并规范化软件过程。软件过程支持工具主要包括软件过程流程工具、过程文挡工具、评审工具和人员管理工具。

 

（3）软件过程评估和改进。软件过程改进对生产高质量软件产品和提高软件生产率的重要性已被越来越多的软件开发组织所认同。由美国卡耐基·梅隆大学软件工程研究所（CMU/SEI）提出的软件能力成熟度模型（SW-CMM）除了用于软件过程评估外，还向软件组织提供了指导其进行软件过程管理和软件过程改进的框架。

 

　　Rational Unified Process(RUP)是Rational软件公司的一个软件过程产品，是由Objectory过程演化而来的，其初始版本为5。0，先后经历了5。1、5。1。1、5。5等版本直到最新的Rational Unified Process 2000版本。RUP将项目管理、商业建模、分析与设计等统一起来，贯穿整个开发过程。RUP采用Internet技术，可以增强团队的开发效率，并为所有成员提供最佳的软件实现方案，它使团队中每个开发人员的见解和思想得到统一，使开发小组成员的沟通更为容易，而这正是任何项目要取得成功的关键因素；它可以增强开发人员对软件的预见性，最终的好处就是提高了软件质量，并有效缩短了软件从开发到投放市场的时间。RUP过程为软件开发提供了规范性的指南、模板和范例，可用来开发所有类型的应用。

 

2 基于RUP的软件过程

 

　　RUP中的软件过程在时间上被分解为四个顺序的阶段，分别是初始阶段(Inception)、细化阶段(Elaboration)、构建阶段(Construction)和交付阶段(Transition)。每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经满足。如果评审结果令人满意，就可以允许项目进入下一个阶段。

 

 

　　基于RUP的软件过程是一个迭代过程。通过初始、细化、构建和提交四个阶段就是一个开发周期，每次经过这四个阶段就会产生一代软件。除非产品退役，否则通过重复同样的四个阶段，产品将进化为下一代产品，但每一次的侧重点都将放在不同的阶段上。这些随后的过程称为进化过程。

 

　　用户需求的变化、运行环境的变更、基础技术方面的变更等都会引发进化过程。通常情况下，进化过程的初始阶段和细化阶段都比较简单，因为基本产品定义和体系结构在前面的开发过程就已经决定。但也有例外情况，例如对软件体系结构(Software Architecture)进行重新定义的进化过程。

 

2。1 初始阶段

 

　　初始阶段的任务是为系统建立业务模型并确定项目的边界。在初始阶段，必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特性。在这个阶段中所关注的是整个项目的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段可能很短。

 

 

（1）明确项目规模

 

　　建立项目的软件规模和边界条件，包括验收标准；了解环境及重要的需求和约束，识别系统的关键用例(Use Case)。

 

（2）评估项目风险

 

　　软件过程主要关心的是软件开发的已知方面，只能准确描述、计划、分配和评审那些已经知道将要完成的事情。风险管理则主要关心未知方面。在基于RUP的迭代式软件过程中，很多决策要受风险决定。要达到这个目的，开发者需要详细了解项目所面临的风险，并对如何降低或处理风险有明确的策略。

 

（3）制订项目计划

 

　　估计整个项目的总体成本、进度和人员配备。综合考虑备选体系结构，评估设计和自制/外购/重用方面的方案，从而估算出成本、进度和资源。在这个过程中，要通过对一些概念的证实来证明可行性，该证明可采用可模拟需求的模型形式或用于探索高风险区的初始原型。初始阶段的原型设计工作应该限制在确信解决方案可行就可以了，具体实现留到细化阶段和构建阶段。

 

（4）阶段技术评审

 

　　初始阶段结束时要进行一次技术评审，检查初始阶段的目标是否完成，并决定继续进行项目还是取消项目。在评审过程中，需要考虑项目的规模定义、成本和进度估算是否适中，估算根据是否可靠？需求是否正确，开发方和用户方对软件需求的理解是否达成一致?是否已经确定所有风险，并且有针对每个风险的规避策略等问题。

 

2。2 细化阶段

 

　　细化阶段的任务是分析问题领域，建立健全的体系结构基础，淘汰项目中最高风险的元素。在细化阶段，必须在理解整个系统的基础上，对体系结构做出决策，包括其范围、主要功能和诸如性能等非功能需求，同时为项目建立支持环境。

 

 

（1）确定体系结构

 

　　确保体系结构、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定开发所需的成本和开发进度。通过处理体系结构方面重要的场景(Scene)，建立一个已确定基线的体系结构。证明已建立基线的体系结构将在适当时间、以合理的成本支持系统需求。

 

（2）制订构建阶段计划

 

　　为构建阶段制订详细的过程计划并为其建立基线。

 

（3）建立支持环境

 

　　建立支持环境，包括开发环境、开发流程、支持构建团队所需的工具和自动化/半自动化支持。

 

（4）选择构件

 

　　评估现有的(构件库)和潜在构件，充分了解自制/外购/重用决策，以便有把握地确定构建阶段的成本和进度。集成所选构件，并按主要场景进行评估。

 

（5）阶段技术评审

 

　　评审时，需要检验详细的系统目标和范围、体系结构的选择以及主要风险的解决方案。在技术评审中，需要考虑的问题有：

 

（1）产品需求是否稳定，体系结构是否是稳定的？

 

（2）可执行原型是否表明已经找到了主要的风险元素，并且得到妥善解决？

 

（3）构建阶段的迭代计划是否足够详细和真实， 是否有可靠的估算支持，可以保证工作继续进行？

 

（4）所有与项目有关的人员是否一致认为，如果在当前体系结构环境中执行当前计划来开发完整的系统，则当前的需求可以实现？

 

（5）实际的资源耗费与计划的耗费相比是否有偏差，该偏差是否可以接受？

 

2。3 构建阶段

 

　　在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制操作，以优化成本、进度和质量。

 

　　构建阶段的主要任务是通过优化资源和避免不必要的报废和返工，使开发成本降到最低；完成所有所需功能的分析、开发和测试，快速完成可用的版本；确定软件、场地和用户是否已经为部署软件作好准备。

 

　　在构件阶段，开发团队的工作可以实现某种程度的并行。即使是较小的项目，也通常包括可以相互独立开发的构件，从而使各团队之间实现并行开发。这种并行性在较大幅度地加速开发进度的同时，也增加了资源管理和工作流程同步的复杂程度。

 

　　构建阶段结束时也要进行技术评审，评审产品是否可以在β测试环境中进行安装和运行。在评审中，需要考虑的问题有:

 

（1）该产品发布版是否足够稳定和成熟，可安装和运行在用户的实际环境中？

 

（2）所有与项目有关的人员是否已准备好将产品发布给用户？

 

（3）实际的资源耗费与计划的耗费相比是否有偏差，该偏差是否可以接受？

 

2。4 交付阶段

 

　　当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。交付阶段的重点是确保软件对最终用户是可用的。

 

　　交付阶段的主要任务是进行β测试，制作产品发布版本；对最终用户支持文档定稿；按用户的需求确认新系统；培训用户和维护人员；获得用户对当前版本的反馈，基于反馈调整产品，如进行调试、性能或可用性的增强等。

 

　　根据产品的种类，交付阶段可能非常简单，也可能非常复杂。例如，发布现有桌面产品的新发布版可能十分简单，而替换一个国家的航空交通管制系统可能就非常复杂。

 

　　交付阶段结束时也要进行技术评审，评审目标是否实现，是否应该开始进化过程，用户对交付的产品是否满意等。

 

2。5 技术评审

 

在每个阶段结束时都要进行一次技术评审，以确定在完成该阶段的最终迭代后是否应该让项目进入下一阶段。 技术评审要考虑的主要问题应该主要与项目管理有关，因为主要的技术问题应该已经在该阶段的最终迭代以及随后的活动中得到解决。

 

 

（1）安排评审会议日程

 

　　技术评审会议的参加者必须包括外部人员（用户代表和领域专家）、项目的管理团队（项目经理以及项目团队各功能区域的团队负责人）和项目评审委员会。

 

　　与会者一旦确定，就应安排会议的召开日期和时间，以便为与会者留出充足的准备时间，让他们能够评审有关材料。

 

（2）分发会议材料

 

　　在会议召开之前，应当将技术评审材料分发给评审人员。要在会议召开之前及早地将这些材料分发出去，让评审人员有充足的时间对其进行审阅。

 

（3）召开评审会议

 

　　在会议期间， 评审人员主要关注状态评估。在会议结束时，评审人员应作出是否批准的决定。技术评审会议可能会得到以下结果之一：

 

（Ⅰ）阶段被接受：评审委员会认为项目实现了该阶段的预期目标，可以进入下一阶段。

 

（Ⅱ）有条件接受：评审委员会同意项目可以进入下一阶段，但必须先完成指定的纠正操作。如果发现的问题很少并且不是很重要，则客户可能决定在项目团队执行某些纠正操作的同时有条件地接受该产品。在这种情况下，项目经理需要根据问题的重要性，或选择开始新的迭代，以处理所出现的问题，或只是通过延长最终迭代来处理问题，二者的差异在于所需的计划工作量。

 

（Ⅲ）阶段不被接受：项目没有实现该阶段的预期目标，项目经理就可能必须开始另一次迭代，甚至项目经理无法决定对问题的解决方案，而需要由有关人员根据合同重新确定项目规模或终止项目。

 

（4）记录会议决定

 

　　在会议结束时应完成评审记录，其中包括重要的讨论或活动以及评审的结果。如果结果是"阶段不被接受"，则应暂时安排一次后续复审。

 

3 应用实例

 

　　在项目的初始阶段，主要建立项目的软件规模和边界条件，明确用户的需求，形成规格说明书，作为验收标准。同时，估计整个项目的总体成本和进度，评估潜在的风险，作出具有20%资源预留的项目计划。最后，根据客户要求，选择分析和建模工具、项目管理工具。系统开发工具，后台数据库管理系统

 

　　在项目的细化阶段，根据实际需求，选择软件体系结构。对一些关键性的算法，制作探索型的原型。并在此基础上，为构建阶段制订了详细的迭代计划。在构件的选择方面，主要采用已有构件，对构件库中没有的构件，则重新开发。

 

　　在项目的构建阶段，完成新构件的开发和测试，集成所有构件，进行集成测试。在这一阶段，采用并行开发方式，大大地提高了开发效率。

 

　　在项目的交付阶段，把经过集成测试的软件制作安装盘，接受实际环境的测试。然后对有关用户和维护人员进行培训和指导。

 

　　基于RUP的软件过程，规范了管理和开发流程，有效地控制了资源，项目在尽少使用预留资源的情况下预计完成。在系统运行期间，软件进行进化过程，最终由软件项目过渡到一个产品。

 

4 结论

 

　　RUP在迭代的开发过程、需求管理、基于构件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。

 

基于RUP的软件过程可以降低产品风险，规范管理和开发流程，有效地控制资源，提高开发效率。

 

第二部分: RUP实施的步骤及建议

 

通过半年来对项目实施的实际情况做出如下标准提交讨论

 

1.    初始阶段

最终目的:

提供项目规模和项目风险的评估和项目实施计划.也就是说:我们要做那些工作[费力不讨好的事不做.]

需要人员:

了解需求所需人员素质:沟通能力比较强[语言表达能力],对技术风险有一定程度了解,善于引导客户[某些方面可以左右客户的思维.]

产生结果:

比较粗糙的项目中主要用例,评估结果文本,项目计划文档.

注意事项:

我认为了解需求最重要的就是详细分析客户的组织结构图,只要了解了组织结构的职能我想业务逻辑就不会有大的偏离,这对初始阶段勾画业务的典型用例已经足够了.而且对系统的扩展升级也提供了大的方针[具体一点就是设计时考虑的可能已经比较全面了]

讨论热点:

估计需求经常要变更的地方做何准备

关键技术储备是否可以满足需求[是否需要自研]

2.    细化阶段

最终目的:

提交详细的需求分析报告,完成系统设计和程序设计.

需要人员:

应使用有经验的开发人员,避免因为程序员不熟悉业务而延误进度;不要在界面设计上犹豫不决而占据时间;如果用户对原型提出了很多意见,其中部分比较明确的意见可以在开发过程中进行实现;和客户的交流应该简洁明了,而不是似是而非;另外,原型方法在项目过程中占据的时间应该在项目计划中保留出来,而不仅仅是隐含在需求调研与分析的一个部分.

注意事项:[有条件下,尽可能创建原型Demo给用户来搜集客户意见]

如何避免用户看了原型后漫无边际地提要求?

首先,应该充分尊重客户,想想其它行业的服务质量吧.有没有听说过这样的说法,项目管理也是客户满意度的管理;软件是一种对客户的关怀,等等.确实,客户提出的思路可能和你已经形成的思路不同,一下子打乱了你的思路,也许项目经理并不介意,但这确是让设计者特别心烦的事情.如果确有把握,或者你可以不做到原型中去.有时候,即使原型很完美,用户也会额外地提出一些意见,这也是人之常情.但不管怎样,你不能认为用户根本不懂软件,让他们到时用就行了,抱这样想法的多半会付出代价.

其次应该进行坦诚协商,多数用户其实都是通情达理的.如果你在签订合同时答应满足任何要求,而此时又无法忍受用户的要求,那么孰是孰非应是题外之意了.一般来说,比较合理的做法可以通过增加费用、延长进度或者把需求实现分阶段来提交,以保持工作的延续性.对有些软件,尤其是信息管理系统来说,客户的实施时间其实并不是主要的,客户最需要的不是及时,而是合用.

其实,客户有着很多种类型,确实,个别客户会参考同类产品来提要求,极个别用户并不真正懂得计算机技术而对技术路线、技术手段等提出其意见,等等.但我们为什么还可以反过来想一下,如果是等到软件全部提交的时候,这部分用户仍有会提出同样的意见.提早暴露并解决分歧,对双方睹是有利的.如果软件公司明知可能存在矛盾,仍然先做好,然后等到用户提出反对后,再提出补充收费.如果喜欢,也无话可说.

总之,原型应本着对软件需求的基本理解来做,这样才能预防不一致性的发生.尤其应该针对不清楚的地方制作原型,从而尽量暴露问题,引发用户的联想,不能回避问题,掩盖问题(以免用户提出太多的想法),很多问题虽然一时掩盖了,但最终还是要发生的.

讨论热点:

对初始阶段的需求进行迭代的完成标志,详细分析业务模型, 产生系统结构及模块划分

产生结果:

需求分析报告和程序设计文档

3.    构建阶段

最终目的:

完成编码工作

需要人员:

编码老手[能够长期稳定地编写出高质量程序的程序员]

注意事项:

代码运行环境的测试及处理办法[建议经常性常备一台裸机供代码测试运行环境]

产生结果:

含运行环境配置文档的打包后软件一套及各种版本的原代码

4.    交付阶段

最终目的:

坦白的讲就是项目报酬.

需要人员:

测试人员

注意事项:

软件测试(Software Testing)是发现软件中错误和缺陷的主要手段.在一般情况下,软件测试过程与整个软件开发过程基本上是平行进行的.当然,测试计划应该在需求分析阶段就已经开始制定了.随后的工作则会伴随着软件开发的过程逐步展开.我认为我们的软件在交付阶段由指定的专人测试就可以了[可以填写测试反馈表到代码编写者,如此重复]

产生结果:

在客户的环境中稳定运行.

一些概念解释:

无数据原型演示:

1.无数据演示版主要目标是将系统未来的概貌演示给直接用户,用户可很直观感受系统,以便提出更客观的需求.

2.建立无数据演示版应该放在需求流程中,RUP的精化阶段中.

3.无数据演示版只需包含系统表示层,不需要任何逻辑层和数据层的代码.

5.    无数据演示版一般由交互创意设计师完成,此岗位的人应该已与相关人员一同参与了业务和需求分析.

交互创意设计师:

不单指UI的设计,还包括工作流的优化,界面的考虑(美工和布局),工作流对客户的心理影响(用户心理的挖掘)和产品的创意.

创意设计员通过以下方法来领导和协调Web界面的原型设计和正式设计:获取对Web界面的需求(包括可用性需求),构建Web页面原型,使Web界面的其他涉众(如最终用户)参与可用性复审和使用测试会议,复审并提供对Web界面最终实施方案(由其他开发人员员创建,如设计员和实施员)的适当反馈.

人机界面总体规划和如何交好的表现业务流

备注

需求经验:

软件从使用范围的角度,可分为项目软件和产品软件.

　　项目软件:即针对特定某个客户的要求,并仅为其使用的软件.又称工程软件,特点是有明确的合同,严格的工期,约定的维护期等.

　　产品软件:即针对某一领域客户的共有需求而开发的软件.特点是通用、功能丰富而冗余,通过一次性的购买行为获得等.

　　就项目软件的需求分析,结合自身的体会,提出一些看法和建议.

1、 依据分析阶段确定合适的客户方配合人员

　　这一点对于获取真正的用户要求非常重要.通常,客户方会组织专工以上层次的人或在单位小有名气的计算机能手来和开发方分析人员配合,共同整理需求.

　　应该对客户方配合人员进行分类,层次化,使之和分析的各阶段相对应.

　　分析的初期,即总体分析阶段,需要得到整体意义上的轮廓需求,此时,应与客户方总工以上层次的人员进行交流,这一层次的人,对未来的系统会有完整的描绘,可以划分出子系统,及其之间的关系,这也是高级管理层对系统的期望.可以以此作为纲领性的文档指导进一步的分析,并约束后续的分析过程,避免需求范围漫无边际的扩大.

专业系统分析阶段,通常,客户单位都会有专业分工,彼此之间既相互独立,又会在某些点上发生联系.此阶段应与客户方专工层次的人员进行深入的讨论.这一层次的人,对自己的专业相当熟悉,对专业内的需求会非常到位,大都年富力强,有相当的阅历和理解能力,甚至自己都可以绘制业务流图,总结业务功能点.对他们应充分鼓励,尽量调动其积极性;

　　系统关联分析阶段,在各专业系统得到充分分析的基础上,紧接着就要理清它们之间的关系,这是提升需求档次的关键阶段,也是高级领导层和专工都关心的阶段.通常,客户单位都会有一些零散的软件,如财务软件,部颁软件等,这些专业软件都发挥着重要的作用,但都是些信息孤岛,客户会很自然的希望能把这些信息融合到整个系统中来,为更多的人所共享.同时,也希望数据能够在各专业系统间顺畅的流动,从而减少重复劳动,提高工作效率.此阶段应把总工层和专工层召集到一起,共同理清系统间的接口.

　　经过这三个阶段,对需求的描述将比较准确和完整.

2、 多方位描述同一需求

　　有一些需求贯穿了从基层人员到高层领导,对此需求应该从各个角度、各个方位给以描述,总结之后才能得到完整的表达,否则可能会漏掉一些信息.这也为后续的设计工作打好了基础.

3、 清晰化每一数据项

　　由于需求将作为设计的基础,弄清所有的数据项的来龙去脉对于设计是必不可少的.不能有模糊不清的地方,同时通过对数据项来源的分析,可以让分析人员更清楚的看到数据的流动情况,也会发现一些新的需求点.

4、 充分挖掘潜在需求

　　由于分析人员对软件技术非常熟悉,一些由于技术所带来的潜在需求对于客户来说,一般很难被发现.不实现这些需求,对整个系统也没什么实质性的影响;实现这些需求,则会锦上添花.

　　对这些潜在需求,会有两种处理方式:告诉客户,客户会得到启发,可能进一步提出新的需求,会有一些更大胆的想法,从而扩大了需求范围,增加了工作量,甚至会影响到工期;不告诉客户,等客户想到了再说.

　　这些需求如果对于产品软件,可能会是一个卖点,要尽可能的去挖掘.但对项目软件,考虑各种风险,有时候可能会回避,或对客户隐瞒.

　　我觉得,不管是否告诉客户,分析人员还是应该去挖掘,最起码可以作为自己的知识积累.[坦白的讲有个备用方案]

5、 采用科学的分析报告模板

　　分析完成后,需要形成《需求分析报告》,应采用规范科学的报告模板,通过ISO或CMM的企业,其模板大都非常详尽,不仅仅作为报告模板,还可以指导分析过程.

　　比如，我以前在的企业除了有规范的需求分析报告编写指南、报告模板，还有”需求分析矩阵”和”需求变更报告”用于管理需求和控制变更.

6、 积累领域知识

　　领域知识对于分析人员很重要,这些知识的广度和深度影响分析结果的准确性和分析进度.分析人员应该通过各种途径去获取这些,不断积累,并进行比较和总结.

7、 抱着学习与指导并存的态度

　　面对一个新的客户时,分析人员首先必须抱着谦逊的学习的态度,把这看成是丰富领域知识的机会.但并非客户单位的任何层次的人都有值得学习的东西,随着分析人员接触的领域客户不断增多,分析人员对该领域的理解也会越来越深,逐渐会成长为领域专家,会有很多地方超过客户对领域的理解,此时,要以自己的深入理解去指导客户,说服客户,甚至纠正客户的一些错误的认识,得到客户的信任与尊敬,这对迅速顺利的完成需求分析会很有帮助.

8、 误区

　　在进行需求分析的时候,容易陷入一些误区,导致分析结果不理想.

分析结果越复杂越好

　　这是技术型分析人员经常碰到的情况,认为分析出错综复杂的关系,花哨的图表才能显示出分析水平高,其实,分析经常要经历”简单-复杂-简单”的过程,前一个简单表现为分析人员”认为简单”;随着分析的深入,原以为简单的问题会越来越复杂;最后,经过概括、消化、分解,使得需求简单明了.

必须一次到位

　　由于项目工期紧,或者客户单位地理位置偏远,不想反复去现场,希望通过一次需求分析就能得到完整的不再改变的结果.有这种情况时,表现为分析人员对客户方配合人员穷追猛问,或坚持要求配合人员做出保证,承诺需求范围不再扩大等等.结果往往是双方关系紧张,配合人员怕担责任,提出过多的灵活的、可配置的一些要求,无端增加了后续设计和编码的工作量.一次到位的想法是不现实的,随着开发工作的进行,用户经常会提出以前没想到的需求,或者更改已有的需求.需求必然有一个迭代的过程,变是不可避免的,关键是对于变化的控制,比如通过正规而繁复的流程提高需求变化时客户付出的代价;告知客户如此变化将会使工期延长,或需要追加资金等等,尽管对于”软件属于买方市场”的现状来说,开发方往往叫不起这个板,但这样的控制还是有一定的效果的.

客户的需求必须全部满足

　　陷入这一误区的分析人员,往往自己的领域知识欠缺,对客户的需求是否合理,缺乏分辨能力,只能由客户牵者走,这样会带来很大的风险:造成需求冗余,项目返工,更有对需求变化失去控制的危险,随着项目的开展,整个开发团队会越来越痛苦.所以必须加深自己的领域知识,变被动接受为主动引导,进而拒绝客户的不合理需求.

实施细则:

界面设计与测试规则

界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象.而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用.同时界面如同人的面孔,具有吸引用户的直接优势.设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流.目前界面的设计引起软件设计人员的重视的程度还远远不够,直到最近网页制作的兴起,才受到专家的青睐.而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝.

 

第三部分: RUP实施的标准

关于文档的标准依据软件设计文档国家标准GB8567—88有一定改动

 

关于对RUP实施的中文资料放到Ftp站点上可以下载

Ftp://10.70.151.253/RUP_Plan/RupChinese/

各种文档模板参见

Ftp://10.70.151.253/RUP_Plan/Dot/

UML设计工具[我们采用微软的Microsoft Visio]参见:

Ftp://10.70.151.253/RUP_Plan/Tool/

版本控制工具[我们采用微软的Microsoft SourceSafe]参见:

Ftp://10.70.151.253/RUP_Plan/Tool/

 

文档规范:

1.    初始阶段:

粗糙业务典型用例[目的更好的了解需求]

项目计划书[根据分析的软件规模指定计划]

2.    细化阶段:

用户需求说明书[含细化需求后的业务用例和业务边界]

系统分析设计报告[提供方针及运行环境评估和开发平台工具,划分系统模块]

数据库设计报告[根据业务逻辑组合数据关系，重点对频率高的检索建立视图或者过程]

管理员手册[对运行环境配置和系统辅助模块描述]

用户手册[对界面设计进行描述,以利迭代]

测试样本[为代码测试提供依据]

程序设计文档[对模块的用例进行用例规约编写]

3.    构建阶段:

项目进展报告[项目进展反馈(每周一次)]

技术讨论稿[多人协作的项目定期举行讨论(时间周期依需要而定)]

4.    交付阶段:

培训计划书

项目总结报告[因应客户提供不同文档]

代码规范:

因不同开发工具不同,细则也不同.参见Ftp上的文档

在这里我主要说几点原则问题:

遵循匈牙利命名法

工程中不起作用的文件或类应删除,工程目录下的非工程文件也应该移走,保持工程的清洁,避免混淆难于管理.

将独立性比较强的模块抽出来,做成DLL,控件或COM组件或者JavaBean等,该模块可单独编写和测试,也增强了其可重用性.

一个比较大的工程应留有一定的消息接口或插件接口等

代码的注释必须达到20%以上.

我们的目的是为了让协同开发者尽量容易阅读代码,尽早上手,易于排错.[掌握这个原则就可以了.]

界面规范:

这个细则更是无法综述[参考细则在Ftp站点],我说几个原则问题:

屏幕对角线相交的位置是用户直视的地方,正上方四分之一处为易吸引用户注意力的位置,在放置窗体时要注意利用这两个位置.

长宽比接近黄金分割点.

色彩尽量用一个色系[以体现企业文化或者产品形象]

我们的目的是使软件的生命延长,良好的软件界面可以启到一定的帮助作用[傻瓜型,微软的视窗就是典范]还使用户心情愉快.

 

代码备份:

版本控制问题

补充问题:

 

第四部分: RUP实施的预计结果

 

年底展望

1.    初步形成企业的CMM管理思想和制度规范

2.    积累一定的可复用代码

3.    项目遇到的问题可以用数字来表示[做到计算机严谨度,可以把说不清楚的问题说清楚]

4.    通过各种规范使新人[阅读公司积累速度增加]培训时间减少,建立合理性的开发梯队.