英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料
移动应用程序开发的持续需求工程
Elza Stepanova和Marite Kirikova
拉脱维亚里加技术大学
marite.kirikova@rtu.lv
摘要 移动行业可以被定义为最快速增长和动态的IT行业之一，其中用户需求变化非常频繁。这是项目经理正在寻找灵活的软件过程模型的主要原因，这些模型可以适应那些经常变化的系统需求，并在短时间和低预算的情况下生产有价值的软件。本文的目的是提出一种移动应用开发项目的连续需求工程方法。所提出的方法满足了移动应用需求变化频繁、开发时间短、必须强调用户界面的挑战。虽然这些挑战不仅在移动应用程序开发上下文中面临，但该方法是从移动应用程序域中出现的，并在移动应用程序域中进行了测试；因此，目前还不能为其他领域提供建议。
关键词：需求工程·连续工程·敏捷方法·移动应用开发项目。
1 导言
通常，建立市场领导力可以通过以较低的成本交付或基于高质量的差异化来实现。此外，人们认识到，现在首先满足消费者不断变化的需求的设备或产品将具有竞争优势。
移动产业可以被定义为增长最快、最具活力的IT产业之一。在移动行业，用户需求变化频繁。 这是项目经理正在寻找灵活的软件过程模型的主要原因，这些模型可以适应不断变化的系统需求，并在短时间和低预算的情况下生产有价值的软件。
本文的目的是提出一种移动应用开发项目的连续需求工程方法。由于第一作者在这一领域的工作经验，移动应用行业在这里得到了解决。 在实践中观察到，这种快速增长的移动应用行业遇到了结构恶劣的工程过程，这可能对软件开发过程和产品成功造成严重后果。重点是两个设计时间以及运行时间问题。在本文中，我们将设计时间视为创建用户界面和执行实际应用程序开发过程的时间；将运行时间视为应用程序实际运行或发布以供使用的时间。
需求工程涉及应用程序开发的生命周期。 一般来说，移动应用程序开发的生命周期与Web或桌面应用程序的软件开发生命周期相同，其中定义了许多不同的生命周期模型，例如瀑布模型、螺旋模型、原型模型、敏捷模型和其他模型。 这些模型中的每一个通常由特定的活动序列描述。
开发软件的模型选择取决于软件项目的特点。 选择或开发最适合移动应用开发项目的流程模型，应考虑移动应用的以下主要特点：
1.用户需求随着时间的推移而变化；这种变化是频繁的。
2.开发时间短。
3.更强调用户界面。
在许多方面，开发移动应用程序类似于嵌入式应用程序的软件工程。常见的问题包括与设备硬件的集成，以及安全性、性能、可靠性和存储限制问题。
论文的其余部分结构如下。 第二节回顾连续需求工程中的相关工程。第三节提出了移动应用开发的连续需求工程方法。第四节讨论了该方法在实践中的应用。 第五节总结了这篇论文。
2 相关工作
Nauman A.Qureshi和Anna Perini讨论了连续需求工程过程的制定和实施，特别是自适应系统的过程。它们一起和单独研究了自适应软件工程中的挑战，并将重点放在具有双重长期目标的需求工程问题上。第一个目标是支持系统分析人员在需求时间设计自适应需求；第二个目标是使软件能够在运行时对需求进行推理，以实现面向目标的自适应。所进行的研究试图从规划问题的角度深入研究需求规范问题，目的是指定开发的软件系统应该做些什么来满足给定的 领域假设下的用户目标、质量约束和偏好。这首先是通过分析应用领域和操作上下文中的可变性级别来完成的。其次，应该确定用户的目标和偏好，以定义可能在不同上下文条件下发生的替代软件行为。
此外，在基于服务的应用程序(SBA)中，开放系统依赖于全球基础设施（即互联网），需要管理其异质性服务提供商和上下文和设备的可变性可以从SBA中访问，仍然保持应用程序的预期功能和质量。 使SBA能够不断地改变自己的主要特征是自加性。这一特性有助于管理SBA操作环境在设计时中的不确定性、动态性、异质性和变异性。
一般来说，需求工程活动允许系统地为即将开发的系统构建一个能够满足其计划用户目标的规范。在开放和适应性系统中，例如SBA，用户目标或在其他情况下，优先级可能在运行时发生变化。此外，应当实现目标的环境条件也可以改变。 因此，需要在运行时感知需求工程活动。
需求工程可以与开发联系起来，在系统与其环境之间运行接口；它从环境信 息或领域模型中收集要开发的系统。 在需求工程中，这些过程和工件之间的信息共享是通过不同的活动-手工活动，例如，可行性研究、需求激发方法等来处理的。或半自动活动，例如，需求验证、需求管理等。信息来源通常共享贯穿各领域的关切，而这些关切是通过它们之间的可追溯性链接获取的。 可追溯性可以从初始阶段工件执行到以后阶段工件-正向可追溯；或者从以后阶段工件执行到初始阶段工件-向后可追溯。模型联合可以用来连接这些工件和信息源，以允许连续和不间断的需求工程过程。
最近Golra和Beugnard等人。提出了一个模型联邦定义，它是一种提供集成多个模型的方法-模型符合不同的范式，概念空间被多个技术空间所包围。 这些技术空间中的每一个都是一组模型，它们代表着一个共同的范式，为它们的解释提供了一个共 同的基础。通常，每个技术模型都是为某些特定的问题而开发的；它们甚至可能影响或以某种方式影响某些不同的项目或系统。功能空间是一种特定的技术空间，用于设置验收标准的功能和设计表示。
技术空间B
功能空间
1.建模空间之间的映射（每个空间由特定的颜色描述：通用-蓝色、技术-绿色和功能-黄色）
第二节中讨论的模型联合，在这里通过虚拟模型实现，以开发新的概念。 作者调整了模型联合框架，使其更适合移动应用项目和敏捷软件开发方法。
将现有模型中的概念结合起来的通用部分不能访问技术模型的元素，除非它能够解释其技术空间中使用的形式主义。这可以使用技术空间和称为连接器的通用空间之间的连接来完成。 这些连接器允许读取、编辑和同步先前开发的通用模型和技术模型之间的信息。当模型被开发时它可以序列化为一个新的或现有的技术空间，以供进一步开发。 除了链接不同模型的概念外，模型联合还允许维护这些动态链接。需求工程过程中使用的这些模型仍然与需求模型相连接，因此一旦信息资源被修改，就有可能更新特定的需求。
通常，需求工程过程中的每个涉众对开发的系统都有不同的观点。 这些观察点中的每个都对应于与完整的软件开发过程相关的关注子集。这些不同的观点通常是作为不同的构件创建的，例如需求规范文档、系统模型、目标模型等。
从敏捷系统开发的角度来看，移动应用程序需求也可以来自不同的涉众群体。传统的产品所有者更侧重于功能需求的实现；在这种情况下，过程操作的技术方面可能被忽略。故对要求的一些要求管理也出现在敏捷方法中，以确保考虑到所有利益相关者的期望。
应用程序开发过程从定义移动应用程序的目标开始——为什么开发团队会聚集在一起，为什么项目会启动——这是工作的基本目标。这一步之后是利益相关者识别；这一步包括分析利益相关者的“利害关系”：利益相关者希望从系统中得到什么，他们施加的限制；项目将如何为他们创造价值等等。当团队成立时，下一个共同的步骤是创造一个愿景。愿景既扩展了，又满足了第一步设定的目标。例如，如果目标指定了需要解决的问题，则视觉给出了答案。这一步骤是通过角色分配来进行的；这些角色缩小了利益攸关方的基础，以考虑 那些将按照愿景的设想与系统实际互动的人。 由于角色持有者是与应用程序交互的人，因此在确定功能时必须考虑它们。 它们扩展和阐述某些角色，为需求分析人员添加纹理。由于这些信息，用户界面设计专家和软件开发人员可以更好地理解和关注那些将使用应用程序的人。在此步骤之后，可以启动需求工程过程。
2.移动应用程序开发中连续需求工程模型联合会
2描述了如何在敏捷移动应用程序开发项目的连续需求工程过程中实现适应的模型联合技术的过程。 当目标和用户被很好地理解时，它就是开始指定应用程序将做什么的时间。在模型通用空间中，第一部史诗被创建。史诗抓住了大量的作品。它本质上是一个大的用户故事，可以分解成一些较小的故事。 基本上，史诗是通过包含需求的泛型空间和技术空间之间的链接来实现的-泛型需求被上传到泛型空间中，可以作为史诗开发的基础。在史诗和用户故事开发过程中，验收标准也被确定下来，这些都是满足的条件-定义价值主张、用户工作流或解决方案特征的清晰描述。 下一个阶段是在较小的用户故事中分解这些史诗。 这可以通过几种方式进行。例如，史诗可以通过用户界面组件来分解；用户所需的每个工作流可以是一个单独的用户故事。 或者史诗可以分阶段分解；首先做一个简单的实现，然后在每个附加的用户故事中添加新的功能。 当这个阶段完成后，技术空间应该随着任务而更新。 任务是较小的工作项目，建立一个故事，没有商业利益。Epic创建和任务定义也应该在需求规范中表示；这也可以通过通用空间和技术空间之间的相同链接来表示。
这种模型联合的方法可以通过基于组件的设计的类比来解释，其中模型作为组件，技术连接器作为连接器。该方法允许在软件开发的后期阶段将更多的信息资源连接到需求规范模型。 当工件在以后开发或在以后的迭代中开发时，它们可以很容易地与现有需求链接。这种支持将新的信息资源与需求连接起来并维护它们以进行同步，允许在软件开发生命周期中执行连续的需求工程过程，而不管新需求出现时的阶段和迭代。为了更好地理解所提出的方法，应该澄清它如何改变传统的需求工程方法。
3 说明拟议方法所涉及的活动
1. 收集
信息
来源
2. 整理资
料
来源
6. 分开
的要求
3. 明确
的要求
5. 将需求映射 4. 分析并注到特定元素 明
[EPIC-AGILE] 要求
7. 为新元素定义
目标
来自要求[感觉]
8. 定义目标
[接受
克里泰里亚- AGILE
要求[记录-档
从步骤4重复
过程。
失败了
9. 综合起来
需求 10. 验证
创造 要求[8还有 步骤]通过测试
3.需求工程过程与模型联合会
在此过程中，所有基本要求工程活动都被涵盖。 区别在于活动的相关方式和组织方式按照示范联合会。 连续需求工程方法通过以下步骤进行说明：
1.收集信息来源。此活动从可用于引出需求的信息源标识开始。 这些资源可 能从早期信息资源（例如可行性报告、标准、会议记录或说明）到测试计划、涉及数据分析等后期信息资源不等。
2.组织信息来源。在收集信息资源时，需要将其与现有需求联系起来。该过程基于模型联合方法，其中需求被开发为通用空间中的模型，其他模型被放置在各自的技术空间中。
3.明确的要求。一旦信息资源与需求模型链接，就可以从这些来源引出需求。
4.分析并注明需求。 当需求从多个信息来源识别时，对它们进行分析，并且在特定需求已经指定的情况下，可以添加附加描述。
5.将需求映射到特定元素。 在此活动中，指定的需求被映射到主要项目元素。几个需求可以映射到单个项目元素。
6.分开的要求。 映射到项目元素的需求描述了该元素的预期功能。主要元素的分解可以完成-每个子元素实现映射到其父元素的需求子集。
7.从需求中定义新元素的目标。 应该定义与项目元素相关的所有新需求的目标。
8.对需求定义目标。 为所有需求创建任务和验收标准。
9.整合需求。 对每个需求进行任务集成过程。
10.验证需求。 通过测试每个已解决的任务来验证验收标准。
上述方法解决了本文导言中提到的移动应用程序开发的基本特征。 它也很好地支持了移动应用程序开发的另一个特点，即应用程序的长维护周期。 该方法在第四节描述的实际案例中进行了测试。
4 拟议方法的应用
4.连续需求工程方法的重复循环
为了说明所提出的方法如何在实践中确保持续的需求工程，讨论了移动Androi
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[260232]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
