快速原型法在PLM系统二次开发项目中的应用
时间：2021-04-06 07:53:31 来源：达达文档网 本文已影响 人 
摘 要：以某EPC企业PLM实施及二次开发项目中的软件工程实践为基础，介绍一种裁剪的基于进化式原型的快速原型过程，对其角色、中间产品、行动和前后条件加以描述，并对该过程的风险和适用性进行了分析。
关键词：软件工程；快速原型法；PLM
DOIDOI：10.11907/rjdk.171816
中图分类号：TP319
文献标识码：A 文章编号：1672-7800（2017）007-0122-03
1 PLM系统实施项目的特点
产品生命周期管理（Product Lifecycle Management，PLM）作为一项能够解决产品生命周期范围内产品信息共享、交互与管理问题的技术，在研发、设计、制造和工程等领域有着日趋广泛的应用。大部分企业会选择实施成熟的商业PLM系统。但PLM系统向来无法“开箱即用”[1]，必须结合客户的战略和业务需求，进行二次开发，而且产品数据的灵活性决定了PLM实施的技术开发量通常显著多于ERP等软件的实施。因此，PLM项目的实施可看作由一个以实现PLM思想、梳理业务流程和实现管理提升为目标的业务咨询活动，和一个以交付软件产品为目的的软件开发活动共同组成。
本文围绕某EPC企业PLM实施项目中的软件二次开发过程展开分析，项目中使用了一个裁剪的基于进化式原型的快速原型过程，具有完整的生命周期。该软件过程对PLM的实施有借鉴意义。
2 快速原型法在项目中的应用
快速原型法的核心思想就是通过构造能够体现目标系统主要特征的原型（Prototype），将目标系统以可视化的形式展现给用户，在经过评估后对原型进行修改，逐步求精，继续评估、修改，直到用户满意为止，它是一个循环迭代的过程[2]。快速原型法可以应用于需求采集，也可应用于技术方案验证和整个系统的开发。
参考业内对PLM实施方法论的研究[3-4]，本文提出的PLM项目的软件过程是一个裁剪的基于进化式原型的快速原型过程。进化原型是创建软件系统的一种形式，它不会在构建后被抛弃，而是通过修改和追加功能逐渐丰富，直至产生覆盖用户和系统需求的可运行的系统。该快速原型过程经过裁剪来适应开发的需要。
2.1 角色定义
以软件工程中原型法的角色定义为基础[5-6]，本软件过程涉及9个角色，一个人可任多个角色，多个人也可共同承担一个角色。按同样的方式，这些角色被分为3个组。
（1）软件工程组。负责引导项目方向，促进配置管理，支持项目建议书编写、领导文档编写工作及相关业务工作。组内角色有：①项目经理，负责执行项目的总体监管，确保配置管理的执行，维护项目计划，委派人員进行需求收集，执行项目实施，裁定出现的问题；②技术文档工程师，负责监督和维护文档，处理会议记录和会议文档，担任配置管理专家，编写保密和安全管理规定，并保证项目产出物遵循规定，如有需要，执行项目实施；③需求工程师，负责领导需求收集工作，与干系人、客户和最终用户沟通，组织与干系人的访谈，担任与用户的接口人，按照策略将需求文档化；④业务经理，负责制定和维护业务蓝图。
（2）软件质保组。负责编写对原型的测试用例和脚本，审查代码和文档，包括项目计划、需求文档和设计文档。组内角色有：①总架构师，负责监督系统的总体设计，对实施工作进行归类，完成资源计划，执行项目实施；②质保工程师，负责设计测试用例，执行测试，维护缺陷/错误报告，执行项目实施。
（3）软件开发组。负责支持用户界面图样（UI）的创建，领导原型的开发工作。组内角色有：①主程序员，负责委派人员进行实施工作，监督缺陷的解决，执行项目实施；②领域专家，负责熟悉和理解某些特定的领域，执行项目实施；③用户界面设计师，负责用户界面图样（UI）设计。
2.2 软件过程
PLM项目使用的快速原型法分为4个阶段。第一阶段是项目规划阶段，该阶段建立业务蓝图，制定项目计划，更好地理解用户需求，建立对新软件需求的基本认识。第二阶段是软件设计开发的第一轮迭代，该阶段确保团队理解系统所追求的大致方向。通过一个抛弃式的用户界面原型，向用户演示项目组的意图，该原型在项目中被称为“一次原型”。第三阶段是第一轮的进化式原型，是一个可运行的原型作为需求的一种真正具体化体现。用户评价该原型并且增加和修改需求。在最后一个开发迭代中，原型按照新的及修改后的需求演化。系统经过测试后交付给用户。
配置管理和质量保证需要在项目的整个生命周期中执行。配置管理依据配置管理计划，由技术文档工程师负责，并由项目经理确认。质量保证由软件质保组负责，文档和原型本身都受到质量保证的控制。
2.2.1 项目规划阶段
项目规划阶段如图1所示，业务经理以初始用户输入为基础编写业务蓝图。使用该信息，项目经理和技术文档工程师编写项目计划，包括角色、职责、排程和项目描述等信息；同时，创建项目管理程序。团队按照创建的管理程序合作，管理程序以及对程序的遵守将会体现在产出的系统质量上。
管理程序建立之后，一组初始的需求可以从用户、其它软件系统和项目团队获得，以便于理解系统必须实现的功能。需求工程师负责需求收集和文档化。该阶段最后通过会议的形式进行一次项目组内审查/风险审查，分析项目组的工作量、方向、问题和解决方案。
2.2.2 第一轮迭代阶段（一次原型）
为促进用户和开发团队间的理解，并提供一条更具体的沟通途径，第一轮迭代致力于创建抛弃式的用户界面原型，以确保开发按正确的方向进行。该原型被称为“一次原型”。该原型强调快速和低成本[7]。基于一次原型讨论的用户界面由技术文档工程师根据适当的配置管理规则来存档。与此同时，总架构师开始基于识别出的需求进行系统设计。该阶段活动如图2所示。
一次原型建立起用户和项目团队之间沟通的桥梁，这使得参与方可以讨论系统，发现沟通的不足和缺失的需求。本次迭代同样有助于确保将来的开发沿着正确的路线进行。在用户与开发者讨论原型时，新的或修改的需求会被发现。这些需求全部被技术文档工程师文档化，附加在原需求文档上。该阶段最后通过会议的形式进行一次项目组内审查/风险审查，给出项目状态的一个公共性的理解，除发现和评估风险之外，还包括创建风险消除策略，并判断风险消除策略的有效性。一次原型会被存档，不会被再次使用。
2.2.3 第二轮迭代阶段
在该阶段初始，需求已经创建并验证，系统设计已开始，并且用户提供了其意见作为输入，确定了最初的软件界面和功能模式。
结合新需求及用户意见，对系统设计作出修改，作为已存在的需求与要实现的原型之间的桥梁。总架构师负责监督设计的完成，主程序员及其委派的开发人员按照系统设计开始构建系统，质保工程师基于需求创建软件部件和系统测试。接下来，执行系统的编码、调试以及测试直到满足需求和系统设计。
原型完成后，将其展现给用户。用户和开发者一起检查创建的系统，可能发现新的需求，或已有需求需要变更。与之前的迭代一样，新的或修改的需求全部被文档化，附加在原需求文档上。在最后阶段，与上一轮迭代一样，通过会议的形式进行一次项目组内审查/风险审查。该阶段活动如图3所示。
2.2.4 第三轮迭代阶段
如图4所示，在该阶段的开始，一份最终需求已经创建并验证，用户已对形成的原型提供了反馈。
与上一轮迭代一样，结合新需求及用户意见，修改系统设计，开始构建系统。执行系统的编码、调试以及测试直到满足需求和系统设计。
作为系统实施工作的结束，开发者使用软件质保组创建的测试脚本及其它全覆盖测试所需的测试脚本来彻底地测试系统，修正发现的缺陷或错误。在系统通过测试之后，通过会议的形式进行一次项目组内审查/风险审查，总结完成的系统构建工作，讨论未解决的问题。最终，完整的系统将交付给用户，该系统涵盖所需功能，并达到用户对质量的要求。
3 快速原型法的风险点
PLM项目中应用快速原型模型不可避免地引入了其自身的风险[8-9]，针对本文提出的快速原型过程分析如下：
（1）人力和成本原型建立。在项目初期建立原型需要付出前期投入和人力成本，如果原型设计不佳导致受客户牵制而在原型上反复修改，则成本更高。原型法要想体现出其优势，需要在前期尽快并且廉价地建立抛弃式原型，用最少的投资开发那些用于回答问题和解决需求不确定性的原型，不要努力去完善一个抛弃式原型的用户界面。在建立原型的过程中，充分利用重用机制。
（2）原型进化方向控制。使用进化原型时，在软件开发的方向和目标上与所有干系人都达成一致是很困难的。下一个原型的内容也会难以决定，在管理上会形成数个版本和决策。最终，原型系统的完成度通常是很难评判的，原型系統有可能被过度进化或过早的交付。目前，有很多方法用于解决此问题。以控制进化过程为目的，主要方法有：有限制的迭代周期、使用风险分析。发现和培养关键用户也十分重要。
（3）功能漂移的可能性。选择进化原型作为过程模型的主要优点是，它使得系统符合已知的用户需求，但可以改变，以满足后续发现的需求，这有助于生产出用户想要的系统。然而，这同样也带来负担，用户经常会一再要求增加新的特性，这些特性将增加开发的时间和成本。可以使用严格的时间限制和迭代次数限制来缓和这种缺点。
（4）软件结构上的不足。由于制作原型时常希望快速提供原型，往往缺乏软件结构的细致设计，并且用户新的或修改的需求可能会颠覆之前的设计，导致进化原型总是伴随着一定数量的不精良的软件结构，使得可维护性降低。这个结构上的缺陷主要由进化模型的迭代过程导致。通常，与传统瀑布模型相比，进化原型形成的系统结构在效率上较低。在迭代中对原型进行改良时必须格外注意，来保持设计的整洁性。
（5）能否有用户的持续参与。对于基于进化原型的项目，最终用户是改进需求和评估原型过程中不可缺少的部分。与其它传统过程相比，需要他们更长时间的参与。用户必须意识到原型的状态，并表达出对原型的期望。业务部门的真正投入和部门之间的沟通协作是项目顺利推进的关键。
4 结语
在PLM实施项目二次开发过程中应用的快速原型法，具有用户需求清晰化、允许需求变更、逐步集成元素、尽早降低风险等优点。项目上线后，得到了用户的充分肯定。快速原型方法是否适用，可以从系统结构、逻辑结构、用户特征和应用约束等多方面考虑[10]。从系统结构方面而言，联机事务处理类系统适合采用原型化方法，而批处理等结构不适于用原型化方法；从逻辑结构方面而言，管理信息系统、记录管理系统等适合用原型化方法，而基于大量算法的系统不适合用原型化方法；从用户方面来讲，对难以预先作系统说明、不容易肯定详细需求、愿意为定义和修改原型投资的用户，适合采用原型化方法；从系统应用情况来看，对已经运行的系统作修补，不适合用原型化方法。从PLM系统的特点来看，在PLM实施项目中使用快速原型法是十分合适的。
参考文献：
[1]孙康明.国内航空制造企业PLM系统实施项目管理研究[D].上海：复旦大学， 2013.
[2]祝世海，孟炯，李胜利，等.采用原型法减少软件需求分析的风险[J].信息技术，2002（2）：2-3.
[3]SCHUH G，ROZENFELD H，ASSMUS D，et al.Process oriented framework to support PLM implementation[J].Computers in Industry，2008，59（2）：210-218.
[4]BOKINGE M，MALMQVIST J.PLM implementation guidelines - relevance and application in practice： a discussion of findings from a retrospective case study[J].International Journal of Product Lifecycle Management，2012，6（1）：79-98.
[5]BLEEK W G，JEENICKE M，KLISCHEWSKI R.Developing web-based applications through e-prototyping[C].International Computer Software and Applications Conference，2002：609-614.
[6]MOE N B，AURUM A，DYBA T.Challenges of shared decision-making：a multiple case study of agile software development[J].Information & Software Technology，2012，54（8）：853-865.
[7]LANA S，AL-SALEM，ALA M，et al.Strategy-focused requirements engineering method for web applications[J].International Journal of Web Engineering and Technology，2007，3（4）：397-419.
[8]CARTER R A，N A I WILLIAMS L，et al.Evolving beyond requirements creep：a risk-based evolutionary prototyping model[C].IEEE International Symposium on Requirements Engineering，2001：94-101.
[9]LICHTER H，SCHNEIDER-HUFSCHMIDT M，LLIGHOVEN H.Prototyping in industrial software projects—bridging the gap between theory and practice[C].International Conference on Software Engineering，1993：221-229.
[10]COOPER K G.Rapid prototyping technology：selection and application[M].New York：Marcel Dekker，2001.
