PLM系统分析及设计和开发过程

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

12．3 系统开发概貌
无论它们的范围和目标如何，新的信息系统是组织问题解决过程的一个分支。一个新的信息系统的建立是一个公司就其面对的某种问题或问题集合的解答。这个问题可能是经理和雇员认为组织表现不像他们想象的那么好的问题，或来自组织应当充分利用更好的优势和机会的现实。
对一个组织的问题或机会提出一个信息零售系统解决方案的活动，叫做系统开发(systemsdevelopment)。系统开发是具有清晰活动的结构化的问题解。这些活动包括系统分析、系统设计、编程、测试、切换、运行和维护等。

    图12-5表示了系统开发的过程。这里描述的系统开发活动通常按顺序进行。但某些活动可能重复或同时进行，取决于所用的系统建设方法。
12．3。1 系统分析
    系统分析是对组织试图通过信息系统来解决的问题进行分析。它包括问题的定义、识别其原因、指明具体的解、识别满足系统解的信息需求。
    系统分析员建造一个现在组织和系统的路线图，识别主要的数据所有者和用户，以及现存的硬件和OA软件。然后系统分析员细化现在系统的问题。通过考察文件、工作纸张和过程，观察系统运行，调查系统的主要用户，系统分析员就可识别问题领域和解所要达到的目标。通常，这个解要求建立一个新的信息系统或改进现有的系统。
    系统分析应包括一个可行性研究(feasible study)，它从财务、技术和组织视角来分析，确定解是否可行，或者目标能否达到。可行性研究应确定所建议的系统是否是一个好的投资，系统所需的技术是否已能用，并能被公司的信息系统专家所掌握，以及组织是否能控制系统所带来的变革。
    通常，系统分析过程确认几个组织追求的解决方案。然后评价每一个方案的可行性。一个书面的电子商务系统建议报告描述了成本和收益、每个方案的优缺点。由管理层确定怎样的成本、收益、技术特性和组织影响以选择较优的方案。建立信息需求
    或许B2B系统分析中较具挑战性的任务是定义满足所选系统解决方案的特殊信息需求。在较基本的层面，一个新系统的信息需求包括谁需要什么信息，何时、何处和如何获取(即4W1H，Who、What、When、Where、How)。需求分析谨慎地定义新系统或修改后的系统的目标，开发一个新系统应执行的功能的详细描述。有缺陷的需求分析是系统失败和高开发成本的主要原因。围绕着一组错误的需求设计的系统或者必须放弃，或者要承受重大的修改。下节我们将讲述提取需求的各种方法以使该问题的影响较小化。
    有些问题并不要求用一个信息系统来解决，可以通过管理的调整、附加的培训、完善现有的组织办事过程来解决。如果这个问题与信息系统相关，系统分析员就要去诊断这个问题，并找到适当的解决方案。
12．3．2 系统设计
    系统分析描述为了满足信息需求应开发什么样的PLM系统。而系统设计(systems design)则说明如何设计该系统以实现这个目标。信息系统的设计是该系统的总体计划或模型。像一栋建筑或房子的蓝图，它包括给出这个系统形式和结构的所有说明。
    系统设计员细化系统说明，提供系统分析识别的功能的说明。这些说明应当阐述系统解决方案的所有管理、组织和技术因素。表12-3给出了系统设计产生的说明的类型。

    与房子和建筑一样，信息系统可能有许多种可行的设计。每一个设计表达一个唯——的技术和组织部件的组合。确定设计好坏的标准是易用性和效率，是它在一定的技术、组织、财务和时间约束下实现用户需求的程度。终端用户的作用
    用户信息需求驱动整个系统建设的努力。在设计的过程中，用户需有足够的控制能力，以保证系统反映他们的业务优先性和信息需求，不至于偏听于信息技术人员。参与设计增加用户对系统的了解和接受。如前所述，用户参与设计的努力不够是系统失败的主要原因。然而，有些系统比其他系统要求更多的用户参与，下节将展示各种系统开发方法如何强调用户的参与问题。
12．3．3完成系统开发过程
    系统开发过程剩下的几步就是将系统分析和设计建立的解的说明转换为一个完全运行的信息系统。这些步骤由编程、测试、切换、运行和维护组成。
1．编程
    在编程(programming)阶段，设计阶段准备的系统说明被转换成为软件码。今天，许多组织不再自己为新系统编程了。而是从外源购买符合新系统要求的软件，这些软件包来自一个外部商业软件供应商，软件服务来自应用服务供应商，或为顾客开发顾客应用软件的外源化公司。
2．测试
    必须进行无遗漏的和彻底的测试(tesitng)以确定系统是否产生了正确的结果。测试答案的问题是“系统是否产生了在已知条件下要求的结果?”回答该问题所需的时间在系统项目计划中经常被低估。测试是费时的：测试数据必须细心准备，结果要评审，系统要校正。在某些情况下，系统的一部分可能必须要重新设计。虚掩这个步骤造成的风险是巨大的。
    系统的测试活动可分为3种：单元测试、系统测试和接受测试。单元测试(unittesting)或程序测试，分别测试系统中的每一个程序。这个测试的目的被广泛地认为是保证程序没有错误，但是这个目的实际上是不可能达到的。测试应被看成是找到程序错误的方法，集中于发现使一个程序失败的所有途径。一旦被指出，问题就能被解决。
    系统测试从整体上测试信息系统的功能。它试着去确定离散的模块是否可以将功能合在一起，像计划的那样，并确定系统的实际工作方式与设想的方式之间是否存在矛盾。在该阶段检测的是执行时间、文件储存和处理能力负荷、恢复和重启动能力以及手工作业过程。
    接受能力测试提供较终的认证，确保该系统已准备好并可用于一个生产环境。系统测试被用户评价，并被管理层审阅。当所有部分均满意时，新系统就达到它的标准，并可以被正式接受进行安装。
    系统开发队伍和用户一起工作，提出一个系统测试计划。这个计划包括我们所说的一系列测试的所有准备。
    图12-6显示了一个测试计划的例子。被测试的通常情况是一个记录变化。文件由一系列测试屏幕组成，在数据库上进行维护，这很适合这种类型的应用。

3．切换
    切换(conversion)是一个由旧系统到新系统转化的过程。可以使用的转换策略有4种：并行策略、直接切换策略、导航研究策略和分段进入策略。
    在并行策略中，旧系统和它的潜在的替代系统同时运行一段时间，直至每个人均确信新系统的每个功能均正确无误为止。这是较安全的切换过程，因为，在错误和处理中断的情况下，旧系统作为一个后备系统仍然可用。然而，这种方法是十分昂贵的，为了运行额外的系统可能要求附加的人员和资源。
    在直接切换策略中，在一个指定的日期新系统完全代替旧系统。这是一个很冒险的计划。如果在新系统中发现严重的问题，可能会造成更大的损失。这时已无其他系统来进行补救。不到位、中断和矫正的费用可能很大。
    在导航研究策略中，引入新系统仅限于组织的一个有限的区域，如一个部门或运行单位。当这个导航模型完成和工作顺利时，同时或按阶段再对组织的其余部分进行安装。
    在分段进入策略中，新系统按职能或按组织单位分阶段引入。如果系统按功能引入一个新的工资系统，先应用于每周发工资的计时工人工资，6个月以后将领薪职工(按月发工资)加入到该系统。如果系统是按组织单位引入，公司总部可能先切换，4个月后下属单位再切换。
    由旧系统移向一个新系统，需要培训终端用户来使用新系统。当切换时，说明系统如何工作的详细文件应被完成，该文件包括技术观点和终端用户观点两种，可用于培训和日常运行。缺少适当的培训和文件将可能导致系统的失败，这部分系统开发过程也是很重要的。
4．运行和维护
    当新系统已经安装和完成切换后，该系统就被认为是投入运行了。在运行和维护(productionand maintenance)阶段，系统将由用户和技术专家双方评审，以确定它实现其原始目标的情况如何，并决定是否要安排修改或修正。在某些情况下，要准备一个后实施审计文件。在系统调整以后，投入运行时，必须对它进行维护，以校正错误，满足要求，改进处理效率。对运行系统改变硬件、软件、文件、作业程序，以校正错误、满足新需求、改进处理效率这一过程叫做维护。
    维护的研究可以考察出各种维护任务所占用的时间数量。大约20％的时间用于调试或校正紧急运行问题，20％关注于数据、文件、报告、硬件、系统软件的改变，60％的维护工作由用户提高、改进文件和记录