CN113655995A - 一种基于需求原型化的软件开发方法 - Google Patents

Abstract

本发明提出的一种基于需求原型化的软件开发方法，该方法是基于系统原型自动生成工具RM2PT，具体方法如下：1、需求分析与迭代：包括初始迭代和需求迭代；对于初始迭代，进行并完成初始的需求分析，将抽象需求转化为形式化的具体需求，为需求迭代提供初始的原型；根据对需求的分析以及现实情况，作出一份对于需求工程和系统设计的粒度与风格的指导，并确立软件框架；对于需求迭代，使用系统原型自动生成工具RM2PT，通过对原型系统的确认和验证，收获用户反馈；2、系统设计与实现；3、验证与交付。本发明将将RM2PT需求原型化技术集成融入软件开发过程，实现了从UML需求模型到原型系统的自动生成。

Description

一种基于需求原型化的软件开发方法

技术领域

本发明涉及软件技术领域，具体涉及一种基于需求原型化的软件开发方法。

背景技术

随着流通业界大规模零售企业的成长以及生产社会化的快速发展，原本企业之间较为孤立的商业关系和贸易方式，逐渐不能满足日益开拓的产品市场的需求，供应链的概念应运而生。对软件工程行业来说，供应链管理系统是一种为终端客户提供商品、服务或信息，并对整条产业链上各企业的关键业务流程和关系进行集成的系统。目前供应链管理系统(SCM)在大型企业的生产管理领域已经有了广泛的应用，而大部分中小型企业受资金技术等因素影响，尚未参与、部署和使用SCM系统。国内大量的中小型企业都是SCM系统的潜在用户。

国内企业部署使用供应链系统的方案主要分为两种：一是使用专业供应链服务供应商开发的通用系统，其优点为不需要聘请专业开发团队与技术维护团队，缺点为与本企业业务适配代价高，需要额外支付培训费用；二是开发使用定制化系统，其优点为可以适配企业的具体情况，缺点为开发成本很高，且存在更新维护成本高的问题。由此可见，成本成为制约该类系统开发和使用的一个重要因素。因此，如何降低此类系统的开发和使用成本成为相关工程领域中有待解决的一个关键问题。

从工程角度来说，中小型企业供应链管理系统的开发主要有两个难点：一是中小型企业发展相对较快，其对SCM系统的需求更迭速度也更快。工程中需要动态捕捉系统需求的变化，并进行快速确认；二是这些企业的信息化水平往往不高，依靠抽象的UML(统一建模语言)可能无法满足沟通需求，客户往往更需要依靠更直观的演示物进行需求确认，例如具体页面设计或可执行程序。这两个难点为SCM系统工程的需求工程部分带来了较大的困难。而软件原型法与原型自动生成技术解决的恰恰是这两个问题。

软件原型法是一种软件开发方法，同时也可以视作一类软件过程模型。软件原型法是指在软件开发初期，开发者根据用户提出的需求，以最少的代价、最短的时间开发出一个实验性的、反映软件主要特征的系统，这个系统被称为原型(Prototype)。通过原型，可以快速验证需求、演示概念并发现需求缺失。根据原型的抽象级别，可以将原型大致分为两类。一次性原型仅提供设计思想的粗略表述，但这类原型能以非常快的速度创建，具有较低的开发成本；但由于实现过于粗糙，几乎不具备实用性，在后续的开发阶段几乎需要全部抛弃。相比之下，演化型原型可以提供清晰的交互接口，在实用性上接近最终系统的要求。尽管此类模型的开发成本较高，但在客户审查中采用演化型原型时，讨论的质量也会相应提高，客户提供的反馈也更加详细。

在软件自动化领域，研究者们已经在原型自动生成工作中取得了一定的成果，其中基于UML模型的需求原型化方法已经趋于成熟。杨溢龙等人提出了一种通过模型映射实现原型自动生成的方法(参见文献：Yilong Yang,Xiaoshan Li,Zhiming Liu,Wei Ke.“RM2PT:A Tool for Automated Prototype Generation from Requirements Model”.presented at the 41th International Conferences on Software Engineering(ICSE’19),Montreal,QC,Canada,May 2019.)，并为该生成方法的验证环节提出了理论依据(参见文献：Yilong Yang,Wei Ke and Xiaoshan Li.“RM2PT:Requirements Validationthrough Automatic Prototyping”.presented at the 27th IEEE InternationalRequirements Engineering Conference(RE’19).Jeju Island,South Korea,September2019.)。演化型原型自动生成的实现，使得软件原型法在工程领域和可用性上有了巨大的发展。然而在该领域，大部分的技术和工具都无法用于解决背景中工程面临的问题。此外，目前尚未存在一种软件开发方法融入了原型自动生成技术。

发明内容

本发明主要目的针对供应链管理系统等相关工程领域出现的需求和问题，同时基于演化型原型自动生成技术的实现，对传统的软件开发方法和软件过程模型进行改良和拓展，提出一种基于需求原型化的软件开发方法，达到降低该类信息管理系统软件开发成本的目的。

为了实现上述发明目的，本发明提供了如下的技术方案：

一种基于需求原型化的软件开发方法，该方法是基于系统原型自动生成工具RM2PT，具体方法如下：

步骤1、需求分析与迭代：包括初始迭代和需求迭代两部分；对于初始迭代，首先进行并完成初始的需求分析，将抽象需求转化为形式化的具体需求，为需求迭代提供初始的原型；然后根据对需求的分析以及现实情况，作出一份对于需求工程和系统设计的粒度与风格的指导，并确立软件框架；对于需求迭代，使用系统原型自动生成工具RM2PT，通过对原型系统的确认和验证，收获用户反馈；

步骤2、系统设计与实现：当判断需求不会产生较大变化时，即可开始进行系统的设计与实现；

步骤3、验证与交付：系统通过单元测试和集成测试后，即可进入验证与交付流程。

更进一步地，所述步骤2中的需求迭代包括分析与原型生成、需求的确认与验证两个阶段。

所述分析与原型生成阶段是采用反馈分析和生成原型这两种子阶段交替进行，反馈分析子阶段的主要任务是对上一次迭代产生的客户反馈进行分析，评估其合理性和可行性，并据此产生精化后的需求；生成原型子阶段的主要任务是通过系统原型自动生成工具RM2PT生成系统原型，并进行早期测试，通过将上一子阶段产生的UML模型输入到RM2PT，即可产生演化型的MVC原型。

所述需求的确认与验证阶段分为验证verification和确认validation两个主要部分，其对象皆为软件需求，其中，验证verification主要围绕对原型的测试进行，在首次需求迭代生成原型系统时，对原型系统的测试用例需要与需求文档一同给出，后续在对需求文档进行修改或重构时，也需要对测试用例进行修改，若在当次迭代之前已经完成了部分系统实现，对需求的迭代就需要考虑和已实现系统的一致性；确认validation主要围绕对客户演示该轮迭代生成的原型展开，原型系统由用例构成，演示同样也是围绕用例展开，根据在分析阶段形成的用例描述，对每个用例进行测试和演示。

本发明所达到的有益效果：本方法选择将需求原型化技术RM2PT作为实现手段，将RM2PT需求原型化技术集成融入软件开发过程，实现了从UML需求模型到原型系统的自动生成，解决了背景技术中提到的主要问题。

附图说明

图1为本发明方法流程图。

图2为本发明软件生命周期图。

图3为本发明初始迭代流程图。

图4为本发明模型关键环节概述图。

图5为本发明需求迭代流程图。

具体实施方式

为了使本发明的目的、优势能够被清晰的了解，下面结合附图和具体实施方式对本发明内容做进一步详细的阐述。

本发明的主要目的是降低需求沟通难度，缩短需求确认周期，最大化需求工程的价值，使交付的产品符合客户的设想。本发明方法流程的主要阶段分为需求分析与迭代、系统设计与实现和验证，这些主要阶段中包含一些子阶段，目的是更详细地描述过程。

本发明方法基于迭代的思想。在工程的开始初期，包括一次称为初始迭代的特殊迭代。此迭代的主要目的是将客户给出的抽象需求具体化，为需求迭代提供初始的原型；并对整个开发过程进行一定的规划。后续的每次迭代都包含一个确认与验证阶段，这为该次迭代提供了一个控制点(里程碑)，从而确保了生命周期的连续性。通过使用原型对需求进行迭代，使得所设计的系统能充分吸纳客户的反馈，大大提升了客户的参与度。

我们将本方法模型化，并命名为“基于需求原型化的软件过程模型”，简称为RM2PT-SPM(即RM2PT-Software Process Model)。通过该模型开发的软件，其流程图如图1所示。

1.初始迭代

初始迭代的主要工作是对系统进行常规性分析。在该次迭代中，由客户和分析人员进行并完成初始的需求分析，即将客户提出的具有较高抽象级别的需求具体化为形式化的表达方式，通常以用例的方式文档化。接下来分析人员需要与客户商定需求的优先级，确定花费在各个需求上的时间，并规定团队各成员的工作范围。在此阶段，需求已经被开发团队接受，并与客户进行了第一次的沟通。

具体来说，初始迭代的首要任务为将客户提供的抽象需求转化为形式化的具体需求。除此以外，初始迭代中还需要，(通常是一套模板)，并讨论软件架构。最后，根据需求的规模、难度以及开发团队的具体情况，构建本次开发的团队分工和项目计划，如图2所示。

2.需求迭代

本方法使用RM2PT技术将需求生成为原型系统，并通过对原型系统的确认和验证，收获用户反馈，从而使需求工程更加透明、高效。

需求迭代是本方法的重要阶段，主要包括分析与原型生成和确认与验证两个子阶段。在这一阶段中，开发团队的主要任务是对初始需求或用户评估的结果进行进一步的分析，并通过生成原型来确认系统的整体结构，还会进行部分非正式的系统设计。在每轮需求迭代开始前，开发团队需要给出迭代计划，完成给该次迭代各阶段的时间分配。如图3所示。

1)分析与原型生成阶段

在分析与原型生成阶段中，本方法通过反馈分析和生成原型这两种子阶段的交替进行解决上述问题。在首次需求迭代中，开发团队将在初始迭代中获取自客户的初始需求通过RM2PT被转换成原型，并通过早期测试和客户审查对需求进行确认与验证，形成需求反馈。此后迭代的该阶段均基于上一次迭代产生的客户需求反馈进行。由于RM2PT实现了原型的自动生成，本阶段的输入仅包括需求和反馈，因此开发团队可以将注意力集中在对需求反馈的处理上。

反馈分析子阶段的主要任务是对上一次迭代产生的客户反馈进行分析，评估其合理性和可行性，并据此产生精化后的需求。在首次需求迭代的这个子阶段中，开发团队将通过反馈得出详细的需求，并将其分解为RM2PT规定的输入，即用例图、概念类图、时序图和系统操作合约，并最后通过用例的方式文档化以供查阅；在后续的需求迭代中，开发团队根据需求的变化程度，对上述的输入进行修改或重构。这一系列文档非常重要，其作用将贯穿整个工程周期，不仅作用于需求获取与确认，还将作用于后续的系统设计和编码。

在这个阶段，开发团队需要与客户保持密切联系，以保证对客户反馈的理解环节没有产生偏差。由于反馈分析子阶段是客户和开发人员一起完成的，所以在这一过程中产生的文档代表了项目中所有涉众达成的共识，体现了客户和开发团队的责任，增进了双方的信任。

生成原型子阶段的主要任务是通过RM2PT工具生成系统原型，并进行早期测试。通过将上一子阶段产生的UML模型输入到RM2PT，即可产生演化型的MVC原型。在初始迭代中，开发团队根据开发经验和现实情况创建用于指导本次项目的粒度风格模板，以指导完成用例图、概念类图、时序图和系统操作合约的编写。生成的原型可以直接用于向客户展示开发团队对客户需求的理解状况，并以此展开讨论。在这个子阶段中，还可以对原型进行早期测试，以发现需求缺失与需求漏洞。

2)需求的确认与验证阶段

需求的确认与验证阶段是本方法的核心，也是开发团队和客户交互的主要场合。该阶段建立了本方法的决策机制，通常也标志着本次需求迭代的结束。

该阶段分为验证(verification)和确认(validation)两个主要部分，其对象皆为软件需求。其中，验证确保了原型的设计和需求的一致性，而确认则是通过与客户的交互，从客户的角度来验证产品需求是否是他们想要的。

验证过程主要围绕对原型的测试进行。在首次需求迭代生成原型系统时，对原型系统的测试用例需要与需求文档一同给出；后续在对需求文档进行修改或重构时，也需要对测试用例进行修改。若在当次迭代之前已经完成了部分系统实现，对需求的迭代就需要考虑和已实现系统的一致性；因此，当对最近更新过的需求进行实现时，它将与相应的原型用例进行相同的可用性测试。

确认过程主要围绕对客户演示该轮迭代生成的原型展开。原型系统由用例构成，演示同样也是围绕用例展开，根据在分析阶段形成的用例描述，对每个用例进行测试和演示。这些用例在每次迭代后都可能被更新，展示的重点正是这些被更新的用例。用户可以提出修改意见，也可以提出新的需求。对于较小的修改，开发团队可以在短时间内响应并捕捉需求的变化，迅速修改需求模型并再次生成原型，实现当场修改演示。在评估阶段失败的需求(方案)会产生反馈，并被发送回分析阶段进行修订。最终，由用户和开发团队共同提出对于本次迭代需求的反馈意见。系统中的用例和系统整体要经过客户需求满意度测试，并在得到客户的批准后进入系统实现阶段。

综上，需求迭代的流程如图4所示，RM2PT-SPM通过这一流程，实现了客户对需求工程的参与和一定程度的控制。

3.系统设计与实现

该阶段往往发生在数轮需求迭代之后。当开发团队判断工程的需求不会产生较大变化时，即可开始进行系统的设计与实现。由于本方法吸纳了快速原型法和增量模型的优点，对迭代开发和增量开发均具有较好的适配性。经过需求迭代过程，开发团队对需求已经有了较为深入和准确的理解，在此基础上进行系统设计与实现时，往往可以具有更高的效率。

此外，通过RM2PT生成的原型不仅用于分析阶段，而且还用于系统实现阶段。首先，系统实现的测试阶段可以参考原型系统的测试用例；其次，通过选取合适的技术实现，可以复用部分原型的程序代码，或是参考原型的代码结构，有助于开发团队快速上手开发。

4.验证与交付

由于系统的设计与实现其前提是客户对需求的认可，因此RM2PT-SPM可以省略传统软件开发方法和软件过程模型的系统确认的阶段(确认过程事实上在需求迭代阶段已经完成)，直接进入验证与交付阶段。

系统通过单元测试和集成测试后，即可进入验证与交付流程。开发团队依次对系统进行软件功能测试和逻辑流程测试。结束验证流程后由开发团队进行部署，并对使用人员和运维人员进行相关培训，最终完成交付。

Claims (4)

1.一种基于需求原型化的软件开发方法，其特征在于：该方法是基于系统原型自动生成工具RM2PT，具体方法如下：

步骤1、需求分析与迭代：包括初始迭代和需求迭代两部分；对于初始迭代，首先进行并完成初始的需求分析，将抽象需求转化为形式化的具体需求，为需求迭代提供初始的原型；然后根据对需求的分析以及现实情况，形成一份对于需求工程和系统设计的粒度与风格的指导，并确立软件框架；对于需求迭代，使用系统原型自动生成工具RM2PT，通过对原型系统的确认和验证，收获用户反馈；

步骤2、系统设计与实现：当判断需求不会产生较大变化时，即可开始进行系统的设计与实现；

步骤3、验证与交付：系统通过单元测试和集成测试后，即可进入验证与交付流程。

2.根据权利要求1所述的一种基于需求原型化的软件开发方法，其特征在于所述步骤2中的需求迭代包括分析与原型生成、需求的确认与验证两个阶段。

3.根据权利要求2所述的一种基于需求原型化的软件开发方法，其特征在于所述分析与原型生成阶段是采用反馈分析和生成原型这两种子阶段交替进行，反馈分析子阶段的主要任务是对上一次迭代产生的客户反馈进行分析，评估其合理性和可行性，并据此产生精化后的需求；生成原型子阶段的主要任务是通过系统原型自动生成工具RM2PT生成系统原型，并进行早期测试，通过将上一子阶段产生的UML模型输入到RM2PT，即可产生可演化的MVC原型。

4.根据权利要求2所述的一种基于需求原型化的软件开发方法，其特征在于所述需求的确认与验证阶段分为验证verification和确认validation两个主要部分，其对象皆为软件需求，其中，验证verification主要围绕对原型的测试进行，在首次需求迭代生成原型系统时，对原型系统的测试用例需要与需求文档一同给出，后续在对需求文档进行修改或重构时，也需要对测试用例进行修改，若在当次迭代之前已经完成了部分系统实现，对需求的迭代就需要考虑和已实现系统的一致性；确认validation主要围绕对客户演示该轮迭代生成的原型展开，原型系统由用例构成，演示同样也是围绕用例展开，根据在分析阶段形成的用例描述，对每个用例进行测试和演示。

Images