系统开发进程.docx
《系统开发进程.docx》由会员分享，可在线阅读，更多相关《系统开发进程.docx（26页珍藏版）》请在冰豆网上搜索。
系统开发进程
系统开发进程
□五个阶段
各类系统开发方式学在范围、复杂性、完善程度和方式上有专门大的不同。
虽然有的方式学分三个阶段，有的分15个阶段，可是每一个方式学所描述的要完成的活动大体上是相同的。
本章要论述的最重要的一点是：
最好的方式学是那些始终把用户考虑进去的方式学。
过去的情形是，用户管理人员与信息服务开发组合作来完成系统的一般功能说明书，然后，由信息服务人员来进行系统开发。
此刻，系统开发是各占50%的比例；因此，用户管理人员应该超级熟悉系统开发的大体进程，特别应该熟悉他们单位自己利用的方式学。
系统开发进程可分为五个阶段来描述。
这五个阶段是：
1.第Ⅰ阶段—系统开始和可行性研究
2.第Ⅱ阶段—系统分析和设计
3.第Ⅲ阶段—程序设计
4.第Ⅳ阶段—转换和实现
5.第Ⅴ阶段—实现后的评价
第Ⅰ阶段—系统开始和可行性研究是在为开发一个建议的系统提供人力和资源之前完成的。
第Ⅰ阶段多数的工作和编写的资料是第Ⅱ阶段的输入。
在第Ⅱ阶段—系统分析和设计期间，系统分析员与用户一路工作以编写详细的功能和系统的说明书。
将这些说明书交给程序员，然后开始第Ⅲ阶段——程序设计。
在第Ⅵ阶段—转换和实现期间，一旦软件开发出来，则成立数据文件，转换现有系统，而且实现新系统。
第Ⅴ阶段—实现后的评价。
在开始了系统寿命期中的生产阶段以后，提出（常常被忽略的）实现后的评价要求。
□具体开发进程
下面将慢慢地描述系统开发进程。
至于具体的细节、彼此的影响、方式、形式等，用户管理人员应该与信息服务领导联系，与他们讨论公司当前利用的方式学，同时再看看公司内部描述方式学的手册。
1.第Ⅰ阶段—系统开始和可行性研究
在第Ⅰ阶段的活动中很少有与其他四个阶段的活动相一致的。
此处所提供的方式包括对于受拒绝后的再次服务请求的方式和将技术转移可能性的研究归并到诸进程中这些内容。
第Ⅰ阶段最终的产品有两个部份。
第一部份是实际的可行性研究报告，它包括对建议的或改良的系统的描述和利润/本钱分析。
第二部份是系统的初步设计。
它对于估价本钱和利润是必要的。
该初步设计是第Ⅱ阶段—系统分析和设计的直接输入。
将系统的初步设计并入可行性研究的依据是，多数可行性研究是以概念而不是以设计为基础的。
若是在描述系统目标上花的时刻太少，那么本钱估量，乃至利润估量将是错误的。
用概念来指导可行性研究注定会致使本钱太高，而且用户不满意。
在系统初步设计上所花费的时刻是值得的，即便拒绝可行性研究也是如此。
因为所编写的资料将必然会被证明其他项目中是有价值的。
下述编号的活动与表的系统开发责任矩阵相对应。
（1）提交服务请求
图说明了包括对受拒绝的请求再次请求处置的一种方式。
所请求的服务毕竟是用户做的，因此，应该由用户着手进行。
咱们鼓励用户管理人员请求信息服务人员的帮忙，可是应该再一次强调，业务领域的管理人员应该对各类大小的服务请求都提供适合的资料。
（2）估价服务请求
正如在责任矩阵中所注释的那样，信息服务管理人员只能许诺小的项目（由公司的方针所肯定的小项目）。
（3）指定可行性研究组
信息服务领导和用户领导一路来指定适当的混合的人选以组成可行性分析研究组。
该组至少由一名系统分析员和一名用户代表组成。
可行性研究组的大小取决于可行性研究的范围和时刻限制。
用户代表应该熟悉当前专业领域的所有工作，用户领导、总领导助理，或专业领域分析员是合理的候选者，用户的系统分析员，具有运算机信息处置基础知识的情形已经愈来愈普遍了。
必需指定一个人担任可行性研究组的组长，哪怕只是两个人的可行性研究组也需要一个组长。
直到1980年为止，多数的可行性研究组和项目组是由一个高级系统分析员或一个项目负责人来领导的。
在信息服务部门中，这两种人是固定分工做这项工作的。
目前愈来愈多的公司采取如此一种政策，即由用户担任项目组组长。
这种将主要责任下放给最终用户的做法将进一步鼓励用户参与系统设计。
在这种政策上取得成功经验的那些公司已经指派了一些具有杰出管理经验和具有某些运算机和信息处置知识的用户人员担任项目组组长。
在任何情形下，组长必需对该组的工作有一个总的安排。
若是要求一个用户代表既作为可行性研究组或项目组的组长而同时又要求他继续履行业务领域的职责，那么该项目是肯定要失败的。
有好些公司已经采用了一种政策，即自动地指派受系统影响最大的业务领域的领导作为可行性研究组和项目组的领导以后该领导将从原来的工作职责中摆脱出来，而用他（她）的全数时刻管理可行性研究（或项目）组。
这种人事安排已经成为现今的主流，其困难是用户领导需要离开原来主管的业务部门少则两个月多则三年后才能回他原来的工作职位上。
（4）标列约束条件
在系统开发的进程一开始，可行性研究组与信息服务人员和用户领导紧密合作标列出设备、本钱、进度、规程、软件和操作上的约束条件。
它们可能限制建议的系统的概念和设计。
（5）整理现有系统的资料
整理现有系统资料的主要理由是：
若是可行性研究组不充分了解现有系统，那么他们就不可能有效地完成所建议的系统的初始设计。
已经成立起来的多数人工系统并无通过真正的设计。
在这些系统中，必需从手稿整理出资料。
若是一个建议的系统是改良一个现有的运算机信息系统，那么可行性研究组只需要保证现有资料的完整性和维持最新版本就好了。
现有系统所形成的任何资料将给设计阶段提供有价值的输入（若是批准开发该系统）。
即便建议的系统受到拒绝，也能对现有系统提供大体的资料，而且可能透彻地理解理有系统。
现有系统的资料由四部份组成：
①系统报告和资料；②系统数据文件；③系统数据元和④说明现有系统的数据、信息和工作流程的图表。
前三部份（报告、文件和数据元）可分类如下：
①当前利用的，而且在建议的系统中以目前的形式保留下来；
②当前利用的，可是修改后才在建议的系统中利用；
③当前利用的，可是在建议的系统中将被删除而再也不保留的。
例如，列出所有现有的报告和标准的资料，并按上述分类给定一种状态。
在报告上将标明相对周期（如，天天，每周）和分发范围。
对于现有系统的所有数据文件都标明有关的存储介质（如，3×5的卡片，磁带，马尼拉折纸机，磁盘等等）和存储方式。
例如，一个名字一地址文件能够存储在许多张3×5的卡片上，而且按名字的字母顺序排列。
一个人工系统所保留的文件数老是令人吃惊的，即便对于业务领域管理人员也是如此。
为了完善现有文件的资料，将每一个文件的记录的样式和简单描述附在文件表中。
系统数据元（即，社会保险号，顾客名，货号等等）是直接列出的，而没必要关系有关的文件。
数据元常常在几个文件中重复出现。
除状态指示符之外，若是数据的名字不能自我说明，则必需对每一个数据数据元进行描述。
有关数据元的其他信息还包括更新要求（如，天天，每周，每一个月，或按照需要更新等等）、来源（如，代办处，资料，系统，工作人员等等）和职责（如，部门名和负责更新者的职务）。
图说明在整理现有系统资料时数据元可能采用的一种典型格式。
咱们通过将系统简化为输入、处置和输出等几个大体组成部份来表示整理现有系统资料的工作进程。
然后用图形描画出各部份之间的逻辑关系。
有多种图像表示技术来做这件事。
最为流行的（虽然不必然是最好的）是流程图。
其他的更为结构化”的技术还有：
IBM公司的层次化输入—处置—输出图（HIPO），汽泡图，数据流框图，南茜—斯奈德曼（Nassi-Shneiderman）图，渥尼尔（Warner）框图和判定表。
当前工作进程的图像描述提供了系统的数据、信息和工作流程的一个概貌。
它着重强调系统中控制工作流程的那些数据元。
这些图应该刻划人工和运算机的处置步骤，而且以适当的顺序安排每一处置步骤。
通常以能最好地显示出工作进程的方式来组织和提供这些图。
它们能够是由一些随机事件、功能或按小的和大的周期来驱动的子系统，也能够是若干子系统；既能够是层次的，也能够是混合的。
很少有几个系统是完全顺序的，因此，在多数情形下能够应用模块方式。
（6）调查研究技术转移的可能性
为了更好地利用现有的技术，许多公司正在进行将有关技术转移到他们的系统开发方式学中可能性的调查。
鼓励调查技术转移的可能性和（或）可行性的政策必将带来人力资源的大量节省。
特别对程序员和分析员更是如此。
适合的技术转移将使这些人的工作集中于尚未现成软件的特定行业的应用领域。
技术转移可能性的调查是从走访那些已经实现的，而且与所建议的系统有类似规模和工作的系统。
可行性研究组还应该调查商品软件目录，以便找到适合的可应用的软件。
若是以为技术转移是可行的，则可行性研究组说明如何利用这些技术和为适应现有环境所要求的修改范围。
若是利用标准的方式来进行技术转移潜力调查，那么提出要求的公司应该采取与具有类似要求的其他公司合作的政策。
（7）完成建议系统的初步设计
可行性研究组要走访专业人员以取得一般的系统要求，然后，将这些要求转换成初步的系统设计。
设计进程是交互的，用户领导和可行性研究组需要常常就设计思想和方式等互换意见，用生动的文字和图形说明来形成建议的系统初步设计的资料，这些生动的文字（用非技术辞汇）描述了所建议的系统的大体工作进程，而且常常同时附有图形说明。
这些文字图表也将列举出那些大大违背现有工作方式而建议的系统所期望的手续、手腕和方式。
这些文字图像也将描述建议的系统与人工系统和建议系统必需与之兼容的自动系统之间的关系。
图形说明将建议的系统的进程简化为它们的组成部份，同时强调各部份之间的逻辑关系。
（8）肯定项目范围
可行性研究组与信息服务人员和用户管理人员合作估量初步设计中所刻划的系统的复杂程度。
并对开发项目此后的每一个阶段进行人力资源要求的估量（用户，信息服务人员及其他人员）。
另外，还注意到培训和运算机机时要求。
（9）预备利润/本钱分析报告
一旦完成初步设计而且肯定了项目的范围，则能够开始利润/本钱分析。
不幸的是，由于用户和信息服务管理人员都希望加速可行性研究阶段，所以，一些关键的步骤被省略了，因此造成在利润、本钱估量上的错误。
仅仅按照一种概念是不可能精准的反映出利润和本钱的。
设计中的某些步骤是必不可少的。
另一种在形成公司决策进程中所隐含的错误将不可避免地把那些难以肯定的利润也算成资金收入。
现今许多复杂的，综合的系统为公司的利益做出了重大的奉献，而做到如此程度是因为它们经历了漫长的、不可捉摸和难以预见的道路。
评价信息服务项目的益处和价值是一个主观的进程，它要求具有本钱和利润方面的实际的知识。
另外，决策者对于正的和负的不肯定的利润要有透彻的理解。
利用美元作为所有本钱和利润的统一的计量标准大大地简化了评价工作。
那种把不肯定的利润引入盈利图表（为了“成立更好的顾客关系”或“提高威信”）的作法会造成在“底线”中复合的错误。
底线常常被盲目地同意作为一种信条。
事实上，在那种情形下，估价是取最好的情形（理想的）和最坏的（荒谬的）情形之间。
但是，若是将不肯定的利润化成美元，那么决策者将以更好的判断代替那种不准确的估量。
估价建议的信息系统的最好途径是针对系统净值（收入减去本钱）估量正的和负的不肯定利润。
为了便于理解不肯定利润（例如，增加服务，减少发票上的错误，加速周转期等），应该产生一个本钱和收入的一览报表。
表说明如何利用最少的本钱类别来表示一次性的和重复利用的本钱。
这些本钱可由预算中心提出，而且把公司作为一个整体来考虑。
本钱类别有：
劳力，材料和设备，旅差和其他各类本钱。
对于每一类，在第一列指出一次性本钱估量（开发），而在系统寿命期的水平线上指出可重复利用的本钱估量（生产）。
公司项目在净值能够从估量收入中扣除本钱计算出来，而且按照公司政策对流动现金打折扣。
（10）按照可行性研究做出决策
完成可行性研究后，除技术补充之外所有报告和资料全数交给信息处置政策委员会以便实施。
技术补充包括预备可行性研究所要求的背景信息。
它还包括一般的系统设计和开始第Ⅱ阶段（系统分析和设计）的一个框架。
信息服务政策委员会感兴趣的主如果初始服务请求、范围、图讲解明和利润/本钱分析。
信息服务政策委员会能对可行性研究施加影响。
信息服务政策委员会能够：
①拒绝建议。
②批准建议并对该建议的开发和实现指定一个最高优先数。
③批准系统并给它指定一个比最高优先数小的优先数，同时将请求放在所有建议的系统队列的适当位置（按期检查队列，当所请求的资源可历时，委员会给那时是最高优先数的项目发出通行命令）。
2.第Ⅱ阶段—系统分析和设计
很少有几个项目能在批准可行性研究后当即实现。
在取得批准和项目开始之间的估量时刻可能是两年或两年以上。
一旦项目获如通行命令，则开始第Ⅱ阶段—系统分析和设计。
在第Ⅱ阶段，将描述所有输入/输出的格式和内容，而且完成详细的系统设计。
第Ⅱ阶段的最后一步活动是预备程序说明，其中包括各类程序模块的说明书。
重要的是牢记在第Ⅰ阶段和第Ⅱ阶段不编制程序。
一个普遍容易犯的错误（常常与系统的质量和运行保护的水平紧密相关）是紧缩第Ⅱ阶段，使它提前完成以便开始第Ⅲ阶段—程序设计。
粗糙的系统设计必将成倍、乃至三倍地增加项目所要求的程序设计量。
（11）指定项目组
与可行性研究组一样，项目组也应该有一个或多个系统分析员和一最多个来自所建议的系统范围内各业务方面的用户代表。
若是可能的话，还要给项目组指派一名信息服务审计员，他不作为专职人员，而作为安全和控制方面的顾问。
因为在第Ⅱ阶段结束之前程序员实际上并非参与进来，所以能够将指定程序员一事推延到第Ⅱ阶段结束时再进行。
可行性研究组的成员不必然都是项目组成员。
在第Ⅰ阶段结束到第Ⅱ阶段开始之间的这一段时刻里，通常委派他们到其他项目去。
但是咱们建议，只要可能则尽可能将原有可行性研究组的人员指派到项目组。
项目组的组长能够是信息服务人员，也能够是用户。
某些单位有按业务领域组织的固定的项目组。
例如，某个项目组专门负责人力资源开发方面的老的系统的保护和新系统的开发，而另一项目组则负责会计和财务方面等等。
另一种办法是项目组必需由信息服务人员和用户专业人员一路组成，而且是以项目为基础来指定项目组。
究竟如何组成项目组为宜，显然要进行衡量。
按专业组成的项目组很难预料在任务过量时或任务不足时由于人员不足或多余所带来的损失。
但是，这种项目组织使得项目组成员有更多的机缘积累开发专业领域应用的经验。
信息服务项目组组织的最好方式或许是既按专业领域组织而同时又维持必然的灵活性，使得项目组成员能在各项目组织之间流动，以便达到饱满的工作负荷。
按照项目的复杂程度和涉及范围的大小，每一个项目组都有不同的最佳人数。
项目组长的能力是一个重要的因素。
有些地方，一个领导能有效地管理20个以上的人员，而另一些领导却连管理3个人都有困难。
项目组的大小和相对进度这些是用户、信息服务人员和公司的领导感兴趣的问题。
许多公司的领导人员有一种错误的概念，即若是将项目组人员增加一倍，那么完成项目的时刻就应该减少一半。
实际情形并非如此。
一个能够直接分成若干个相同大小模块的简单项目，用两倍的人力，能够在原定的一半时刻里实现。
但是，绝大多数的项目是复杂的，有的乃至是极为复杂的，这就要求在所有项目组成员间进行内部协调。
说明增大项目组的规模时，将会发生的情形。
在某肯定的数量之前，每增加一个指派到项目组的人员都增大了对项目的奉献。
在这以后，每增加一个人实际上减少了项目组每一个人对项目工作的奉献。
图上有一点是增人员的反射界限，超过那一点，再增加人对于项目的目标来讲反而起相反作用。
由于项目成员之间的关系复杂，因此使得生产效率降低。
在为了知足项目限期而采取紧急办法的情形下，有时领导人员要求将所有资源转移到紧急的项目上，形象的说明了当一个项目组人员太多时，将会出现的情形。
这时将不可能进行内部协调。
当头都不明白尾在做什么的时候，即便每一个成员都忙于从事某种与项目有关的工作，项目的进度仍是要停顿下来。
对于每一个肯定的项目组都有最佳规模。
与项目有关的所有领导和公司行政人员都应当专门好地掌握如此一个格言：
与其过度地扩大项目组织规模，造成欲速则不达的局面，还不如推延项目的实现时刻。
（12）估量人员要求并进行人员委托
一个项目的成功与否在专门大程度上依赖于用户与公司领导、其他专业领域人员和某些范围内信息服务人员（如，数据库管理员，联系用户的人员等等）。
由于某人（或某部门）忘记或不承认以前的口头上的委托，会使得许多紧急项目被延误。
因此有必要签署一个书面的人员委托书。
应该造表列出在系统开发进程中所直接参与到的项目组的人员和其它人员（如访问用户人员、搜集数据人员等），并同时列出在每一阶段对他们的相对的时刻要求。
项目的人力要求来自于可行性研究报告。
没有书面人员委托而进行的项目肯定会产生没必要要的延误，乃至可能失败。
本书把项目开发的重要性放到一个适当的位置。
在项目中所涉及到的许多人并非在项目组内。
由于这些的多数都理解他们的例行活动比项目所涉及的任何外部事物更为重要，所以一个书面委托是必不可少的。
不幸的是，项目委托有时超过了他们按常规分派的工作负荷。
在这种情形下，需要领导直接参与、按期催促和采取干与办法。
对于在各个阶段人员委托的相对要求上给读者一个感性的熟悉。
的底部描画了在系统开发的每一阶段占总的项目工作量的百分比，对每一阶段提供了项目工作量百分比的一个范围。
公司的政策和系统开发方式学将影响到相对百分比。
例如，一种强调设计阶段（Ⅲ）的方式学将一定有更为清楚概念的程序功能说明书。
因此减少了程序设计工作所要求的时刻。
作为一个规则（到目前为止），花在第Ⅱ阶段（系统分析和设计）上的工作量是与花在第Ⅲ阶段（程序设计）上的工作量成反比的。
在一个设计良好的系统中，第Ⅱ阶段将具有比第Ⅲ阶段更大的工作量。
的上端说明了由项目组（用户和信息服务人员）和非项目组成员的用户对项目工作奉献的相对百分比。
注意，在第Ⅱ阶段期间，30%的工作量是由不在项目组的用户做的。
在第Ⅱ阶段（系统分析和设计）期间，项目组必需不断地在每一级与用户进行通信。
在程序设计期间，仅仅在外围才涉及到用户。
在第Ⅳ阶段（实现和转换），在培训、测试、数据转换和并行操作中都涉及到用户。
在第Ⅳ阶段中项目组和用户肩并肩工作，直到实现系统。
在第Ⅴ阶段，将系统转交给用户。
（13）人员培训
为了在系统开发进程中进行有效的交流，可能要求对于在设计数据库时所涉及的用户和在生产调度中所涉及的信息服务人员进行培训。
按照经验，信息服务人员负责信息系统方面的培训，而用户则负责专业领域的培训。
那个活动的产品是一张表，表中列出要求某种培训的人员的名字和头衔。
每行表中都注明那种培训的简单描述，包括地址、负责人和计划的时刻等。
有些培训将要求马上进行，而另一些培训（比如数据录入）将推延到项目接近实现时进行。
（14）成立详细进度表
通过利用一种标准的系统开发方式，管理人员能够成立阶段标志然后，利用历史统计数据和经验来估量中间和最后活动完成的日期。
项目组组长必需与信息服务人员和业务领域的管理人员紧密合作以保证在系统开发进程中在各关键点有足够的人员。
系统开发进程本质上是线性的（一个活动接着一个活动），而且是不难用适当的准则（方式学）和合理的估量来监视的说明了一个典型的信息系统项目进度表。
在活动点上加上三种标志之一以指出该活动的状态。
若是情形表明该活动是没必要要的，则在活动号上加一个圆圈。
若是一个特定的活动正在着手进行，则在相应的活动号上划一个对角线。
一旦活动完成则将对角线改成交叉线“×”。
有时也用甘特表来给出项目进展的图形轮廊。
在开始一组有阶段标识的活动之前，要预备一个更为详细的进度表，来单独安排这些中间活动。
对于要求多于两周时刻的那些活动将以两周为增量来安排进度。
说明了对具有阶段标志E的那些活动的一个详细的信息系统项目进度表。
阶段
+具有阶段标志完成的活动
阶段标志活动
估量的开始时刻实际的开始时刻提前或推延的天数估量的
完成日期实际完成的日期提前或推延的天数
A12345DS198W
.12B
B67891014B22B
C1112B1314151617181919813A3A
DB20212223DS24252627282930313233343536=已开始的活动
×=已完成的活动
0=不要求采取办法
+对应于图中的方式学
*直到实现可行性研究之前，并非进行第Ⅱ阶段活动Ⅴ的估量
A=提前的工作天数B=推延的工作天数
DS=正在进行
标志E—细节
活动估量的开始时刻实际的开始时刻提前或推延天数
估量的完成日期实际的完成日期提前或推延天数
24指定程度组长198y,198y,
25安排顺序和分派程序198y,198y,
26安排程序预备进度198y,198y,
27a[KG*2]编定、测试程序并编写程序资料198y,198y,
27b[KG*2]同上198y,198y,
27c[KG*2]同上198y,198y,
27d[KG*2]同上198y,198y,
27e[KG*2]同上198y,6.198y,
27f[KG*2]同上198y,198y,
*以阶段标志D的活动A=提前的工作天数
B=推延的工作天数
实际开始时刻为准os=正在进行
下面的方式能够用来估量价钱、人员和相应的时刻要求。
这种循环利用的方式使得一组人能意见一致，而且对于信息服务项目特别适合。
咱们假定参与估量的那些人能够提出问题或具有任务方面的知识，而且能够提出支持自己意见的重要的理由。
参与成立信息系统项目进度表的人能够包括项目组长、起作用的用户领导和其他有经验的信息服务人员（他们不必然与本项目有关）。
咱们通过以下几个步骤来描述进行合理估价的方式。
①项目组长介绍任务（例如，肯定项目进度表的阶段标志的日期）和相应的背景信息。
②每一个参加者提交一个书面估量（本钱、人员要求或时刻）。
③项目组长（以线性比例）绘出该组每一个成员的估量。
④计算上、下四分点和中点，而且标上迟度。
⑤要求其估量低于上、下四分点的那些参加者解释他们低或高估量的理由。
⑥项目组长就所标绘的估量召集一次公开的讨论会。
⑦重复步骤②至⑥，直抵达到精准性要求不需要再循环为止。
通过每一次循环，将降低估量的误差。
⑧估量是取中间值或（在适合时）取平均值。
估量的误差是包括危险的一种标志。
（15）与用户人员交谈
与用户交谈的进程从本活动开始。
为了解决问题和肯定系统要求，项目组成员按期与有关用户见面。
与用户交谈及反馈的进程贯穿于系统开发的全进程。
对于详细设计的大体输入是：
（A）初始设计（来自可行性研究），（B）对现有系统及其成份的评价（也是来自可行性研究）和（C）输入、处置和输出的要求（由用户提供）。
①项目组与有关的用户人员检查在可行性研究的初始设计中所描述的输入/输出要求和频率，并按照需要及价值对每一种输入/输出进行评价。
许多输出是“有了更好”，可是却不值得去产生它们。
还能够按照周期和时帧来估量输入/输出。
通过估量频率/价值比的平衡来优化周期的输入和输出。
例如，若是每周情形报告能够知足需要，那么就没有必要再产生天天的情形报告。
在联机系统中，检查响应时刻要求以肯定这种时刻要求是不是太紧迫，可否适当放宽要求而又致于对运行效率产生较大的影响；或肯定这种响应时刻的要求是不是不能知足。
②目前系统的资料对设计提供了有价值的输入。
现有的报告、表格、原始资料等等，实际上能够追踪最终用户以便肯定该资料是不是适合，是不是及时等。
若是是，还能做哪些工作来改良它们?
项目组负责对现有的所有输入和输出进
升级会员 