传统和大数据商业智能的需求工程





5.00/5 (7投票s)
比较传统和大数据商业智能的需求工程
1. 引言
本文档的目的是展示一个论点并获得对该论点的反馈,作为研究项目的一部分。
该论点是,传统数据系统和大数据系统的商业智能需求工程在许多方面具有相似性,但在许多方面也存在很大差异。
2. 摘要
任何项目的需求工程过程都取决于许多因素,例如公司文化、风险、技术等。对于高知名度、高价值和高风险的项目,我们通常会采用瀑布式需求工程方法。
传统数据系统试图与数据系统中的数据对象以及现实世界中的实际对象或事件进行一对一的匹配。这需要系统来确保数据的一致性和稳定性。传统的商业智能系统会定期拍摄数据快照,以便数据分析师能够获取趋势数据,这些数据存储在数据仓库中。由于我们无法回溯到过去,数据仓库中的数据,我们的需求工程过程需要足够详尽,以确定数据仓库中需要包含的内容,同时又不会超出可用的处理和存储限制。
每千兆字节的处理和存储成本的持续下降,使企业能够存储比运营需求多得多的数据,这也称为大数据。这些数据的处理和存储要求大不相同,例如,数据不必立即可用、一致、完整,这与传统数据系统相反。新数据技术的可用性带来了新的商业模式,并影响了普通市民的生活。大数据系统中详细的数据使商业智能技术能够创建人类和其他实体的预测模型。我们可以将这些模型投入生产并监控结果,以获得竞争优势。从将生产中的变更引入到衡量结果的时间缩短,以及拥有详细的历史数据视图,意味着我们可以对需求工程采取更具迭代性的方法。
3. 需求工程
3.1. 什么是工程?
“科学家研究的是已有的事物;工程师创造的是从未有过的事物。” - 阿尔伯特·爱因斯坦
工程是创建和遵循一个过程的学科,该创建可以是一个文档、一个过程、算法、机械装置、软件等构件。一个工程过程的创建可以作为另一个工程过程的组成部分。例如,我们可以设计一个捕获大数据系统需求的流程,这个流程可以用于大数据系统的需求工程过程[15]。
工程过程包含许多活动,如需求收集、设计、调度、执行、测试、维护等。
3.2. 什么是需求工程?
我们使用需求工程过程来识别我们想要创建的系统的能力、特性和质量因素,以便交付的系统对所有相关利益相关者都有价值和效用[28]。简单来说,我们需要了解最终结果应该实现什么,以便利用机会并解决许多问题。
需求工程是不同利益相关者之间的一种沟通形式,以理解并同意每个需求的价值和优先级。
需求工程并不规定实现或设计。然而,新的需求会随着设计、测试、部署、操作使用和其他在需求之后进行的活动而产生。因此,需求工程过程是连续的、迭代的、动态的、交互式的,并且永远不会完成。
3.3. 为什么需求工程很重要?
高达 53% 的技术投资都用于失败的项目或项目超支,在许多这些案例中,根本原因在于需求工程不足或根本没有需求工程[28]。需求工程过程很重要,因为它为后续所有工作提供了基础:设计、开发、测试、部署、操作、维护、支持和处理任何要构建的系统[28]。
许多时候的重点只在于实现(所谓的“真正工作”或“解决方案”),客户和项目经理认为如果代码生成了,就是有进展。问题在于,如果没有需求工程过程,开发团队就无法感受到业务对产品的设想以及“真正的需求”是什么[28]。
对需求的误解会导致开发时间的浪费和精力的消耗,从而导致系统过度复杂化、返工和沮丧[28],因为正在构建的内容与业务愿景不符,也无法解决实际问题。时间的浪费和精力的消耗也意味着经济损失,因为昂贵的资源被用于无法解决“真正问题”的“解决方案”[28]。没有真正的需求,测试团队只能测试呈现给他们的内容,而无法验证任何真正的需求是否已满足。
“陈述”需求与“真实”需求之间存在实质性差异。陈述的需求是由客户在项目开始时提供的,说明他们的需求,例如信息请求、提案、报价或工作说明。真实需求包括客户对特定系统或功能的经过验证的需求[28]。在许多情况下,检查系统审计日志中的实际用户使用情况,以确定系统所有者认为用户将使用什么与实际使用什么之间的差异,是有益的。
在许多已开发的软件系统中,高达 45% 的功能从未被用户使用。这意味着我们需要确保我们理解每个迭代的真正和最小需求,任何更多都是过度的。
这符合所有人的最佳利益,因为它降低了风险、成本、进度、复杂性等[28,第 85 页]。
识别真实需求是一个动态的、交互的和迭代的过程,由方法、技术和工具支持[28]。
3.4. 计划
与需求工程相关的活动之一是计划。大多数人都同意,一点点计划就能走得很远。需求工程计划对大多数人来说是一个陌生的概念,但它具有巨大的力量和影响。需求计划定义了需求将如何演变以获得“真实的”需求,以及需求活动将如何得到解决[28]。
计划始于理解公司文化、业务模式和参与度、利益相关者可用性、知识产权归属、风险和预期利润等,仅举几例[26][11]。我们可能会选择一个高度迭代的需求工程过程,边走边学。这在社交媒体公司中是可能的,这些公司拥有宽容的公司文化、冒险精神和幽默感,并且利益相关者随时可以澄清开发过程中不清楚的任何需求。另一方面,我们可能会为矿业公司选择一种瀑布式需求工程过程,其中包含大量的需求测试,因为错误的成本过高,而且利益相关者很难联系到。
理解所需工程过程必须交付的内容(完整性、正确性和涉及的风险)有助于选择正确和相关的需求工程方法,而不是选择最近项目奏效的方法或仅仅跟随最新趋势。
3.5. 需求类型
以下列表包含各种需求类别,列表并非详尽无遗。许多需求属于一个或多个需求类别[28]。
- 业务:业务需求是我们首先开发系统的原因。描述业务将如何使用系统、赚钱、省钱、提高业务效率、广告等。当这个过程完成并传达给其他利益相关者时,会出现许多问题。
- 用户:这些需求描述了将使用该系统的用户的配置文件以及他们的需求。
- 业务规则:这些需求构成了功能需求的核心。
- 功能:系统必须做什么
- 设计:将需求工程过程与设计活动分开并不总是可能的,因为新系统可能建立在现有系统之上,或者需要与现有系统进行接口。
- 性能:描述所需的响应和扩展要求。
- 接口:描述各种系统之间的物理和软件接口。
- 用户界面:外观和感觉、流程、错误处理和品牌。
- 可测试性:描述软件将如何进行测试。例如,对自动化测试和模拟器的需求。也可能需要能够在生产环境中测试整个系统或其组件。
- 部署:描述部署所需的特性,例如最大停机时间、部署地点和时间等。
- 支持:描述支持人员的配置文件以及服务级别协议等。
- 培训:描述对支持人员和系统用户的培训需求。
- 开发过程:软件开发过程应是什么样的。例如,源代码可用性、源控制、构建等。
- 操作:描述新系统应在哪个环境上运行。并发用户数等。
- 监控:指示应测量哪些性能计数器以及升级流程。
3.6. 需求工程师的角色
需求工程师需要与客户、用户、系统架构师和设计师等所有利益相关者合作,识别计划系统或软件开发工作的真实需求,以定义需要解决的问题。他需要审查客户陈述的需求,研究业务目标,与客户和用户合作,演变业务需求并对其进行优先级排序,并让技术负责人和架构师参与[28]。
需求工程师还需要与客户和用户等利益相关者有效合作,以管理新的和已更改的需求,从而使项目保持可控。他创建了控制变更的机制。我们应该欢迎那些能进一步阐明需求但不会影响成本、进度或功能的对需求的变更。根据行业经验,需求变更 20% 将使项目开发成本翻倍[28]。
需求工程师需要促进构件的重用,以实现可重复性,方法是使用设计模式并从以前完成的工作中提取模板[28]。
需求工程师负责与业务所有者合作,设想一个从产品的第一版或版本开始,通过一系列分阶段发布到最终系统或产品的增长路径。无论进行多少讨论和测试,总会有遗漏的需求,直到系统投入生产才会发现[28]。
需求工程师还必须就可用的方法、技术、技术和自动化工具向利益相关者提供建议,以最佳地支持与需求相关的项目工作和活动。团队应广泛使用他们熟悉的工具、流程和技术,以减少学习新流程和获得新技能的负面影响。团队应探索、试验并熟悉他们不习惯的工具和技术[28]。
需求工程师应促进使用指标来衡量、跟踪和控制与需求相关的项目工作活动和结果。被衡量和跟踪并且管理层关注的事情就是会改进的事情。我们不应为了测量而测量,而应利用它来评估项目工作并采取纠正措施[28]。
人际交往能力对需求工程师来说是绝对必要的。他必须能够促进讨论并调解冲突。他必须确保想法和方法作为团队进行讨论,因为团队会产生比他独自一人更好的想法和方法。需求工程师不必成为所有方面的专家,他的专业知识应该是促进和调解[28]。
需求工程师应该研究系统或软件将使用的领域的领域。如果不了解使用领域,需求工程师就无法有效地向软件开发团队解释他们需要构建什么[28]。
3.7. 理解业务参与
需求工程师还必须理解业务以及谁应为业务和技术决策负责。
哈佛大学 Ross 和 Weill 的一项研究[18]表明,大多数关键的 IT 业务决策都方便地转交给了技术高管,因为他们没有意识到这些决策构成了业务挑战,而不仅仅是技术挑战。随后,他们没有为技术所需的组织和业务流程变革承担责任。
IT 高管是制定架构、标准、技术等决策的合适人选。但不应让他们单独决定 IT 如何影响组织的业务战略。在必要时, IT 部门应与非技术管理人员合作,为他们提供选项和权衡,以便高级管理人员能够做出明智的决策。
3.7.1. IT 应该花多少钱
许多 IT 项目都无法确定投资回报率。许多高管查看行业趋势和标准,以确定他们是否在 IT 上花费过多或过少。这些公司无法建立战略平台,因为它们没有获得足够的资金[18]。
成功的公司实际上是确定 IT 在组织内的战略作用,以确定足够的资金水平来实现战略业务目标。这些公司将其支出水平与其战略目标相匹配,而不是行业基准[18]。
3.7.2. 哪些业务流程应该获得我们的 IT 资金
在许多组织中,想法和人数一样多。自然,并非所有这些想法都同等重要。至关重要的是,高级管理层要对 IT 项目进行优先排序,以便对公司成功产生重大影响的项目以及带来最大效益的项目排在最前面[18]。
如果做不到这一点,IT 部门就会试图做所有事情,却一事无成[18]。
3.7.3. 哪些 IT 能力需要是公司通用的?
将 IT 能力和标准集中到整个组织可以节省成本和带来战略利益。然而,集中式方法也会抑制个别业务单元的灵活性和对特定客户的响应能力,并可能引起某些业务单元的抵制[18]。
如果这个决定留给 IT 经理,他们要么会选择非常宽松,要么会选择非常严格的集中化[18]。
高级管理层应就能力应集中和标准化的地方以及应放在业务单元内的位置做出决定,同时牢记关键的权衡和战略业务目标[18]。
3.7.4. 我们的 IT 服务需要多好?
产品特性,如功能数量、可靠性、响应速度和数据可访问性,都是有成本的。高级管理层必须决定他们愿意在各种服务和功能上花费多少[18]。
IT 服务适当级别的决定应由高级业务经理做出。如果 IT 部门自行决定,他们将选择最高的服务级别,提供“凯迪拉克”服务,而“别克”就足够了,因为 IT 部门是根据服务中断次数等因素进行衡量的。IT 系统通常会考虑更高服务级别的成本,但从未单独列出[18]。
IT 人员应提供服务产品菜单及其价格,以帮助企业了解他们支付的费用。业务经理应与 IT 经理协商,以确定合适的服务级别以及企业可以负担的价格[18]。
3.7.5. 我们将接受哪些安全和隐私风险?
增加的安全性会带来经济成本、不便和系统互操作性降低的成本[18]。
高级管理层有责任决定是需要更高的安全性并接受其运营方式的成本,还是吸引新客户并让客户满意[18]。
几乎所有的经理和高管都会说安全和业务灵活性同等重要。一旦机会出现,同样的经理会忽视安全和隐私问题,以确保交易的达成[1]。
3.7.6. 如果 IT 计划失败,谁来负责?
IT 系统本身没有价值,需要将其集成到业务中并由用户使用[18]。
高级管理层需要任命一位业务主管来负责实现 IT 项目的业务效益[18]。
我们可以构建一个技术上优雅且架构上纯粹的系统,但如果它不被使用,就没有价值[18]。
4. 传统数据系统的需求工程
当我们想到传统系统时,我们通常会想到一个有前端、后端和高度结构化数据库的三层系统[3]。在过去的 40 年里,这就是企业和组织创建数据系统的方式。这些系统是针对特定业务目的而构建的,其中实体的数据具有明确定义的属性和相互关系。
这些系统的典型操作要求包括
- 已插入的数据应立即提供给所有可以访问该系统的人。
- 数据实体可以根据其几乎所有属性进行查询和更新。
- 可以根据数据条目构建报告。
- 系统中的数据正确地代表了当前状态。
凭借明确的数据需求以及数据模型中已知的关系和属性,大多数情况下使用关系数据库存储数据是明智的,并具有详细的数据模式。
4.1. 传统数据系统 - 经典方法
直到 90 年代末,瀑布式方法一直是系统工程和实现的主导方法。原因如下:计算机软件和设备的访问成本昂贵且稀缺,对现有数据结构的更改成本也很高,需要 extensive downtime,软件的任何更改的分发成本也过高。这需要彻底、完整和正确的系统需求工程,然后是设计,首先专注于创建完整和正确的数据结构,完成后再处理功能。
4.2. 传统数据系统 - 更现代的方法
从 90 年代末左右开始,系统设计和实现转向了更具迭代性的方法,因为数据系统的变更成本和软件分发成本随着允许在生产中对用户几乎没有影响地更改数据模式的数据系统的可用性以及互联网的普及而急剧下降。
许多较新的关系数据系统开始支持复杂数据类型,如 blob、XML、JSON 和地理空间对象,从而实现更动态的模式。
通过这种新方法,软件开发人员首先专注于添加功能,并在需要时更改数据模式。企业利用精益创业模型来利用迭代方法,当产品达到最低价值主张点时即可创收[2][12]。今天的美元原则。
4.3. 一致性模型
许多传统系统的另一个非常重要的要求是完整性和准确性,这需要一个一致且稳定的系统。例如,当从一个账户向另一个账户进行电子资金转账时,所有操作必须成功才能使交易成功,否则所有操作都必须回滚。为了实现这一点,传统数据系统中的一致性模型使用 ACID(原子性、一致性、隔离性、持久性)一致性模型,这意味着一旦交易完成,系统中的数据在磁盘和内存中就是一致且稳定的[4]。调查和修复信息以及人们不信任系统的成本可能非常高昂。
4.4. 体积
传统数据系统仅处理和存储其满足目的所需的信息,所有其他信息都被忽略。我们已经有了大型数据库一段时间了,非常大型数据库国际会议自 1975 年以来一直在举办,但这并不能使任何大型数据库成为大数据系统[25]。
仅存储实际使用的数据是有意义的,因为维护包含未使用数据的系统的成本可能非常高。
4.5. 速度
传统数据系统使用悲观数据并发,并对接收到的数据进行大量处理。只处理和存储操作环境运行所需的数据是明智的。
4.6. 什么是 ACID 事务?
ACID 首字母缩略词代表以下内容[4]
- 原子性:构成完整交易的所有操作都需要成功,否则交易需要回滚。
- 一致性:每次交易完成后,数据系统都处于结构健全的状态。
- 隔离性:事务不会相互竞争以访问数据。数据访问由数据系统控制,以确保看起来就像事务是顺序运行的。
- 持久性:应用事务后,结果是永久的。这是在出现错误时。
5. 大数据系统
“大数据”一词有多种定义,许多定义指的是技术的某个方面、缺乏数据模式、数据量等。在本文档中,我们将大数据视为一种数据存储和处理方法,而不是一项技术、标准或实现,而是行业术语[10]。
数据存储、处理和互联网可访问性的成本降低带来了新的商业机会、商业模式以及不可避免的存储、处理和分析数据的新需求。
这些企业包括谷歌和 Facebook,它们不是传统的企业类型。在这些企业中,消费者使用服务来换取广告曝光。这些企业的付费客户是广告商,他们会在消费者点击进入他们的网站时付款。对特定用户最相关的广告将确保点击。这些企业了解并理解每个消费者,并通过尽可能多地收集每个消费者的信息来实现这一点。
这些系统的需求与传统数据系统非常不同,特别是现在消费者不为提供的任何服务付费。例如,当 Facebook 用户发布消息时,Facebook 不必确保该帖子立即对该用户的所有朋友都可用。
利用许多传统数据系统提供的功能过于受限,且不提供任何业务价值。
5.1. 无状态
大数据系统不以主要保持当前值状态为目标,而是接收并附加所有新数据到现有数据存储中,并带有日期和时间戳。
这些示例包括安装在机动车中的设备,这些设备报告需要存储的各种数据位。
5.2. 多样性
构建和不断修改传统数据系统以适应它可以接收的所有各种数据模式排列的复杂性和成本过高。当它需要存储和处理它从未打算接收的数据时,也很难确保传统系统在高负载下表现良好。
大数据系统旨在有效地存储具有各种数据模式排列的数据。进入大数据系统的数据存储在数据湖[6]中。数据被映射和归约到一定的总体程度,以便根据数据在设备上的生成时间以及由大数据系统接收的时间来检索数据。这使得大数据系统更适合存储将来可能需要或分析的数据。
这种松耦合的数据模式意味着将更多责任放在开发人员身上来提取和处理数据。这并不意味着根本没有数据模式。
模式广泛多样的一个缺点是,它不适合使用通用和复杂的查询来搜索数据。
一个适合使用大数据系统存储数据的例子是拥有各种跟踪设备的车辆跟踪公司。跟踪设备的功能范围很广,从报告基本位置数据的单元(如日期、时间、经度、纬度以及点火开启和关闭)到提供丰富数据集的设备,其中包括加速度计数据、发动机探头集成和环境数据。将这些数据存储在传统系统中是没有意义的。
5.3. 体积
在传统数据系统中,系统只处理和存储其为实现其系统目标所需的数据。所有其他数据都被忽略。在大数据系统中,我们希望保留尽可能多的相关信息。拥有足够的存储容量很重要。
5.4. 速度
大数据系统接受推送到它处的所有数据,因此它需要非常快速地存储数据。
5.5. 一致性
在大数据系统中,ACID 事务的使用远比大数据系统所需的要求更严格和悲观。可伸缩性和弹性在大数据系统中更为重要,并且倾向于使用 BASE(基本可用性、软状态、最终一致性)一致性模型。
5.6. 重复
数据可能重复、丢失、顺序错误或延迟。在传统数据系统中,会有过滤重复数据集的要求,而在大数据系统中,会存储重复数据以帮助调查与创建重复数据集的设备相关的问题。
5.7. 什么是 BASE 事务?
BASE 首字母缩略词代表以下内容[4]
- 基本可用:数据系统大部分时间似乎都在工作。
- 软状态:数据不需要写一致,数据系统的任何副本也不需要处于相互一致的状态。
- 最终一致性:数据最终是一致的。
6. 大数据系统应该取代传统系统吗?
绝不应将大数据系统视为传统系统的替代品。我们建议大数据系统应与其他传统系统共存,因为每个数据系统都满足不同的数据存储和访问要求。
传统数据系统和大数据系统满足截然不同的业务和技术要求。当将 SOLID 原则[9]应用于企业系统时,拥有独立的系统是有意义的。这意味着传统系统将仅包含和处理其实际使用的数据,并且无需保存有趣的数据或我们将来可能需要用于分析的数据,因为它已存储在数据系统中。
构建一个单一的大数据系统来替换一个或多个传统数据系统通常会变成一个复杂的噩梦,难以优化和管理,导致无法维护的复杂性。
7. 传统商业智能
商业智能是一个术语,指的是并包括各种分析数据和解释数据的方法。活动和学科包括数据处理、查询、报告、分析和数据挖掘[14]。
商业智能主要用于战略决策、削减成本和识别新的商业机会[14]。
7.1. 数据仓库
传统的运营数据系统包含有关特定域当前状态的信息,并且是为运营需求而构建的,并且随着数据被插入和更新到数据系统中而经常发生变化。对于几乎所有用于战略决策的报告来说,一个非常重要的要求是了解数据随时间的变化,这些时间变化数据通常单独存储在数据仓库中[17]。
“数据仓库”一词最早由 Bill Inmon 在 1990 年提出,它提供了面向主题的、集成的、随时间变化的、非易失性的数据集。数据仓库定期收集、汇总和整合来自各种数据源的数据,以提供随时间的通用数据快照视图[17]。
生产数据系统和数据仓库的要求差异如下[17]:
数据仓库 | 运营系统 | |
Data | 历史概览 | 当前状态 |
用户 | 高管、经理和分析师 | 职员和数据管理员 |
用法 | 战略性的 | 运营业务 |
Data | 概览 - 汇总和整合 | 原始和详细数据 |
用户 | 少量用户 | 尽可能多的用户 |
查询 | 复杂查询 | 简单查询 |
访问 | 仅读取访问 | 读写访问 |
事务 | 不需要事务 | 需要事务 |
恢复 | 不需要恢复 | 需要恢复 |
并发 | 不需要并发控制 | 需要并发控制 |
7.2. 分析
数据分析过程可以从对某些值随时间变化的简单报告到更复杂的处理,例如统计分析、复杂的多维分析和数据挖掘(知识发现)[17][14]。一个简单的报告示例是客户群增长与特定时间段内的利润增长。
数据分析是发现新的和确认现有的有用且有趣的模式和关系的过程。这使得企业能够做出明智的决策[8]。
数据仓库用于所有需要历史趋势的分析查询。
这种分析活动的一个例子是仓库库存,我们需要确定每个产品的最佳库存水平,以便避免我们不得不报废卖不掉的库存,或者因为无法充分供应客户而失去客户给竞争对手。
7.3. 需求工程
从我们开始将数据处理到数据仓库的那一刻起,我们只有时间序列数据。这意味着我们需要对我们所处的业务、我们组织的特定需求以及我们对客户和其他业务互动提供的独特价值主张有透彻的预先了解。这将使我们能够预测未来分析某些业务方面的重要需求,估算足够的数据存储间隔,并牢记相关的存储和其他资源约束需求。
大多数传统的分析数据系统包含汇总和聚合的数据,这意味着我们可以进行以下类型的分析:[25][5]
-
描述性分析
- 我们做得怎么样?
- 我们做出的一些决策产生了什么效果?
-
预测性分析
- 如果我们继续这样做,我们在可预见的未来会去哪里?
反过来,这意味着我们需要做出重大的业务影响决策,以能够衡量任何应用变更所产生的效果[25][5]。这些重大的决策当然伴随着重大的风险。
8. 大数据商业智能
通过访问大数据系统中的大量多样化数据,可以找到个体类型项目(如产品、人员、设备等)的普遍趋势。利用这些信息,我们可以为这些项目在不同设置下的典型行为构建模型。
我们日常生活中存在许多模式:人们是习惯性的生物,机器在停止工作之前会表现出某种模式,雨水在特定时间落下,等等。
通过分析这些模式,我们可以构建模型,使我们能够进行以下类型的分析[25][5]:
- 描述性:个体到目前为止做了什么?
- 预测性:在这种特定情况下,个体将如何行事?
- 规定性:我们需要对个体做什么?
预测模型的一个例子可以在客户保留中找到,我们需要预测哪些客户可能会离开。这些模型可以进行细化,只联系那些我们可以说服他们留下来的客户,而留下那些本来就会取消合同的客户,因为我们联系了他们[25]。
通过大数据分析,重点是获取我们获得的所有相关信息,并将其与尽可能多的外部数据联系起来。外部数据包括地图、日历和天气数据。这意味着我们不仅拥有大数据,还拥有了大数据排列[26]。
8.1. 实验
我们可以通过构建用于优化性能的模型来以小迭代方式应用这些模型。一旦这些模型投入运行,我们就能衡量变更的效果。因此,我们可以在实时环境中进行小规模的可控实验并衡量结果。通过这种方法,我们可以让许多积极变化的累积效应产生重大影响。例如,我们可以衡量广告、营销活动等的效果。
我们甚至可以对特定人群进行实验,衡量我们对他们的影响,并与未进行实验的对照组进行行为比较,以确认我们所做的就是效果的原因或不是。
大数据分析在所有情况下都不能证明一件事导致另一件事,但它可以表明存在联系。将这些关联性见解与其它研究项目结合使用可能有助于找到因果关系。
8.2. 模型准确性和一致性
从分析数据构建的模型不一定总是 100% 正确。一位股票市场交易员通过自己的分析表示,他的模型只需要 50% 的时间正确就能带来平均 80% 的利润[7]。
花费大量时间和计算力来找到高精度模型。了解模型何时足够好可以使用,或者何时应该停止改进模型很重要。当我们进一步改进模型的价值很小时,或者我们可能会错过使用该模型来改进模型的机会时,就会停止改进模型。停止改进预测模型的另一个原因是,当模型记忆了所有过去的事件而没有创建通用的预测模型时。模型生成的预测平均而言通常比人做出的预测更好、更稳定[26][25]。
不一定总是能提供绝对的价值和真相,因为价值和真相很多时候取决于你如何衡量。许多企业更关心一致的模型,以确保一致的测量和结果。这能让投资者和监管机构安心,并使企业运转[26]。
8.3. 变革
我们生活在一个不断变化的世界。消费者权益团体游说活动的影响可能会改变人们的购物和注册服务方式。例如,在欧洲,当消费者拥有从一个 GSM 移动电话服务提供商转到另一个的权利成为法律后,Telenor 过去用来减少客户流失的许多方法都不再起作用了。他们为这个新环境创建了新模型[25]。
我们需要确保我们的预测模型定期更新以保持最新。
8.4. 大数据分析输出
我们有可能从构建的数据模型中衍生出新的业务。
8.5. 数据仓库
来自大数据系统的数据也写入数据仓库,以节省查询聚合数据的时间。大数据系统最棒的地方在于它们包含历史和详细信息集,这意味着我们可以重建数据仓库中的数据集,如果它们不正确。
因此,我们不需要在数据仓库中保留任何聚合数据,以防万一我们需要它。这意味着我们可以对数据分析的需求工程采取更具迭代性的方法,只在有需求时才进行处理。
8.6. 市场研究
传统的市场研究记录人们的观点,然后试图确定他们的观点与他们实际行为之间的相关性。
传统的市场研究在很大程度上已被实验与大数据商业智能系统相结合的市场研究平台所取代。该平台允许研究人员衡量任何细微方法改变对客户的影响。
这还使研究人员能够在不同环境中有效地了解什么有效,什么无效。
8.7. 工程流程
像 MineRP 这样的公司在整个工程过程中都使用大数据商业智能。他们将业务需求与传感器、安全、监管、法律和其他采矿数据叠加,以提取采矿需求,例如,我们如何开采才能在 20 年内获得最大利润。这些需求被用作另一个进行设计和调度的商业智能过程的输入,该过程使用设计模型和来自其他矿山的经验。实际采矿过程的传感器和测量数据被反馈到大数据系统中,以创建计划与实际模型。这些经验数据又被用于其他项目[26]。
8.8. 隐私和道德
通过公开可用的元数据和公司收集的数据,追踪和理解人们的行为变得异常容易[19]。
人们越来越重视公司的道德义务,即保护数据并以合乎道德的方式使用数据[25][5]。
从个人那里收集的私人数据对公司来说非常有价值,以至于这些公司愿意免费为这些人提供大量的服务。大多数人并不了解用个人信息换取免费服务的后果,而且几乎没有法律界限来限制这些数据的用途和利用[13]。
8.9. 工作场所的变化
大数据商业智能改变了我们做生意和雇佣人的方式。Uber 可以被视为一个数字老板或主管,在职业中增加了一个软件层[16]。
在现代社会,人们的就业与否是基于对在线社交媒体平台的数据分析,并考虑到他们的在线活动和关联[16]。
8.10. 影响我们的日常生活
大数据商业智能正在使用的算法收集社交媒体数据,以确定我们的信用评分、贷款利率、是否适合某份工作等。不幸的是,这些算法并不总是公平的,纠正错误是一个艰难的斗争[16]。实际上,人类的判断被算法取代[23]。
有许多不受监管的数据经纪人会在我们不知情或未经我们同意的情况下创建我们的个人资料。我们甚至无法纠正或审查这些数据,这会影响我们租房、贷款等的能力[16]。
8.11. 审计追踪
大数据商业智能可用于通过文本文件、追踪设备甚至照片等信息,法医重现任何事件[20]。
8.12. 欺诈性数据
谷歌等大数据公司从各种数据源收集数据。其中一个来源是众包,如谷歌的我的商家和地图制作[22]。
这种骗局的一个例子是,个人和企业利用大数据平台谋取私利,骗子说服谷歌他们的企业存在于许多地点,而实际上并不存在[22]。
当用户搜索本地商家时,骗子会报低价。当商家出现进行工作时,他们会收取更高的费用。谷歌没有商业动机来彻底解决这个问题,因为它目前并没有从骗子那里亏损[22]。
声誉是我们社会中用来相互信任的重要社会手段。我们今天管理声誉的方式涉及技术。我们使用 eBay、Amazon、Uber、Facebook 等系统的评论。通过创建或购买虚假关注者(由公司创建,然后利用这些关注者撰写正面评论)来提高声誉和感知可信度变得异常容易[24]。
9. 传统和大数据商业智能的需求工程为何相同?
需求工程的目的是理解我们面临的机会或问题。需求工程过程取决于许多因素,例如公司文化、成本、风险技术等。例如,我们可以分多个小阶段交付,还是只有一次机会才能让一切正常工作。一旦我们理解了机会或问题,我们就会知道它是否能或应该使用传统分析、大数据分析或两者的组合来解决。
9.1. 业务案例
许多项目都始于热情,因为一个伟大的想法为客户提供了价值。不幸的是,客户并不总是愿意为产品或服务付费,这意味着项目失败了。
需求工程师需要与业务部门合作,创建能满足客户需求并让他们愿意付费的产品和服务。
9.2. 数据分析需要人
尽管许多数据分析系统广告可能让人认为分析数据就足够了,但事实并非如此。数据是由人创建和管理的,需要专业技能。这些技能包括对组织业务模式有深刻理解的业务人员,对销售产品有良好理解的产品经理,了解他们所销售客户的销售和营销人员,以及知道如何将业务需求转化为技术解决方案的技术人员。
只有人才能做出战略性的业务和技术决策,并运用智慧,数据和算法本身无法做到这一点。电脑算法最多只能帮助提供一个好的答案,但它不能告诉我们我们没有问对问题。
9.3. 耗时
收集和准备数据进行分析以及确认分析结果由于需要处理的数据量庞大,绝大多数情况下都非常耗时[27]。
因此,遵循需求工程过程以了解业务正在做什么以及哪种分析结果能提供实际业务价值非常重要。
9.4. 以数据为中心 vs 以业务为中心
采用以数据为中心的方法,我们可能会获得从数据角度来看有意义的结果,但从业务角度来看则不然。例如,我们可能会告诉一个矿山,他们的大多数事故都发生在地下。我们可能会呈现已知的信息,仅仅是有趣但没有业务价值[27]。
数据本身如果没有业务计划就没有太大价值。公司随意收集和存储数据,会将其客户暴露于数据泄露的风险中,并使自身面临严重的严重安全和责任风险[21]。
我们需要与业务部门合作,首先了解哪些信息将提供业务价值并有意义[27]。
10. 传统和大数据商业智能的需求工程有何不同?
传统数据系统和大数据系统的商业智能过程的需求工程在业务模型、粒度和迭代长度方面存在差异。
10.1. 现实的表示
传统数据系统本质上是以一对一的方式模拟当前现实。系统中的每个对象和操作都被建模为一个存储条目,因此要求数据保持一致并与当前现实状态正确。
大数据系统收集尽可能多的关于对象和操作的数据,以提供历史视图。主要目标是模拟行为,这使我们能够预测未来行为。
10.2. 粒度
使用大数据系统,我们拥有精细粒度的详细数据,我们可以从中构建模型并预测个人类型的人或对象的行为。使用传统数据系统和数据仓库,我们只有一般的趋势数据,这意味着我们只能为每种类型的产品或人提供一般性预测[25][5]。
10.3. 迭代
10.3.1. 传统数据系统
从在业务环境中应用变更到能够衡量效果的迭代长度为几天到几周或几个月。实施长期战略性变革需要经验丰富且技能娴熟的业务人员,他们对即将应用的变更有良好的直觉,而无需立即测量。
只有利用传统数据系统,才能成为一名成功的企业主,这需要远见和毅力。
10.3.2. 大数据商业智能
大数据技术和商业智能带来了许多新的机会和挑战,特别是在需求工程方面。大数据系统带来的一个机会是允许非常短的产品和软件开发和部署迭代,我们可以将想法在几小时内投入生产并几乎立即衡量效果。
这种更短的迭代和“快速失败”的概念有一个缺点,那就是一个好想法可能会被丢弃,而实际上需要一段时间的承诺才能确保该想法的成功。
许多人错误地认为更短的迭代意味着更少的计划。围绕技术设计和实施业务在许多情况下仍然需要瀑布式的方法。例如,当我们创建一个健身服务并为用户提供可穿戴设备(如智能手表)时,确保设备的可用性确实需要一些计划。
更短的迭代确实有一个优点,那就是我们可以在产品达到最低价值主张时发布产品,这意味着我们的上市时间更短,并收集用户反馈。我们还通过将开发精力集中在用户实际使用并愿意付费的内容上,而不是花费精力在“有更好”或“想知道”的功能上,从而最大限度地降低风险。
10.4. 商业模式
使用传统数据系统的商业智能与大数据商业智能的商业模式差异很大。传统的商业模式要求我们了解业务的当前状态,并且信息必须正确,我们将使用传统的商业智能系统,例如,谁目前账户逾期或我的哪些车辆应该进行保养。需要我们根据过去的信息进行预测的预测性商业模型,例如,哪些客户会购买我们的产品,谁会流失,哪些交易可能会被欺诈等。收集的数据比提供的服务更有价值[13]。
传统的商业智能系统通常构成主要创收产品和服务的一部分。通常,我们从中创建发票。例如,谷歌这样的公司将为实际点击事件创建发票。
预测性业务用于优化和简化传统业务。在许多情况下,收集到的数据非常有价值,以至于许多这些企业愿意免费为人们提供服务和设备,只是为了能够收集和分析数据。我们正真正走向数据经济[11]。
11. 结论
任何系统的需求工程都不必是一个漫长、乏味且复杂的过程。做得对,我们可以在短短几天内确定实现业务价值的期望。需求工程使所有利益相关者能够共同努力开发相同的服务或产品。结果是一个统一的产品或服务,该产品或服务正在被营销、销售、实施和支持。
业务成熟度、业务模型、公司文化、技术能力、风险和机遇,决定了我们选择使用什么样的需求工程过程[11]。
传统和大数据商业智能系统的需求工程在许多方面具有共性,但在许多方面也存在差异。
12. 参考文献
- [1] Balabit. Balabit CSI Report. In: (2015).
URL: https://pages.balabit.com/rs/855-UZV-853/images/Balabit-CSI-Survey.pdf (访问日期:2016年1月4日)。 - [2] Stave Banks. Why the Lean Start-Up Changes Everything. In: (May 2013).
URL: http://host.uniroma3.it/facolta/economia/db/materiali/insegnamenti/611_8959.pdf - [3] H. M. Chen et al. \Big Data System Development: An Embedded Case Study with a Global Outsourcing Firm. In: Big Data Software Engineering (BIGDSE), 2015 IEEE/ACM 1st International Workshop on. May 2015, pp. 44{50. doi: 10.1109/BIGDSE.2015.15.
- [4] John Cook. ACID versus BASE for database transactions. 2009.
URL: http://www.johndcook.com/blog/2009/07/06/brewer-cap-theorem-base/ (访问日期:2016年4月20日)。 - [5] Thomas Davenport. Big data at work: Dispelling the myths, uncovering the opportunities. Boston Massachusetts: Harvard Business Press, 2014. ISBN: 1422168166.
- [6] Marin Fowler. DataLake. In: (2015).
URL: https://martinfowler.com.cn/bliki/DataLake.html (访问日期:2016年4月20日)。 - [7] D Garnet-Benet. Interview with D Garnet-Benet (Solutions Architect, Consultant). Feb. 17, 2016.
- [8] Lynn Greiner. What is Data Analysis and Data Mining. 2011.
URL: http://www.dbta.com/editorial/trends-and-applications/what-is-data-analysis-and-datamining-73503.aspx (访问日期:2016年4月20日)。 - [9] W. Haoyu and Z. Haili. Basic Design Principles in Software Engineering. In: Computa-tional and Information Sciences (ICCIS), 2012 Fourth International Conference on. Aug. 2012, pp. 1251{1254. doi: 10.1109/ICCIS.2012.91.
- [10] D Ives. Interview with D Ives (Director, Karabina). Jan. 7, 2016.
- [11] Q de Kok. Interview with Q de Kok (Product Development Manager, Altech Netstar).
- [12] Marko Lepp•anen and Laura Hokkanen. Four Patterns for Internal Startups. In: Pro-ceedings of the 20th European Conference on Pattern Languages of Programs. EuroPLoP '15. Kaufbeuren, Germany: ACM, 2015, 5:1{5:10. isbn: 978-1-4503-3847-9. doi: 10.1145/ 2855321.2855327.
URL: http://0-doi.acm.org.innopac.up.ac.za/10.1145/2855321.2855327. - [13] Rebecca Lipman. Online privacy and the invisible market for our data.
URL: http://poseidon01.ssrn.com/delivery.php?ID=710087064097088098072117012077082122015017&EXT=pdf (访问日期:2016年4月20日)。 - [14] Ryan Mulcahy. Business Intelligence De nition and Solutions. 2007.
URL: http://www.cio.com/article/2439504/business-intelligence/business-intelligence-definition-and-solutions.html (访问日期:2016年4月20日)。 - [15] University of New South Wales Department of Engineering. What is Engineering. 2016.
URL: http://www.engineering.unsw.edu.au/about-us/what-is-engineering (访问日期:2016年4月20日)。 - [16] Frank Pasquale. Algorithms are producing profiles of you. What do they say? You probably don't have the right to know. Aug. 2015.
URL: https://aeon.co/essays/judge-jury-and-executioner-the-unaccountable-algorithm (访问日期:2016年4月20日)。 - [17] Tutorials Point. Data Warehousing - Overview.
URL: https://tutorialspoint.org.cn/dwh/dwh_overview.htm (访问日期:2016年4月20日)。 - [18] Jeanne W Ross and Peter Weill. Six IT decisions your IT people shouldn't make ". In: (Nov. 2002). URL: https://www.researchgate.net/profile/Peter_Weill/publication/11043243_Six_IT_decisions_your_IT_people_shouldn't_make/links/00b49518ae03f7653a000000.pdf
- [19] Bruce Schneier. Bruce Schneier Blogs.
URL: http://www.schneier.com (访问日期:2016年4月20日)。 - [20] Bruce Schneier. Cheating in Marathon Running. Apr. 2016.
URL: https://www.schneier.com/blog/archives/2016/04/cheating_in_mar.html (访问日期:2016年4月20日)。 - [21] Bruce Schneier. Data Is a Toxic Asset. Mar. 2016.
URL: https://www.schneier.com/blog/archives/2016/03/data_is_a_toxic.html 访问日期:2016年4月20日)。 - [22] Bruce Schneier. Exploiting Google Maps for Fraud. Feb. 2016.
URL: https://www.schneier.com/blog/archives/2016/02/exploiting_goog.html (访问日期:2016年4月20日)。 - [23] Bruce Schneier. Replacing Judgment with Algorithms. Feb. 2016.
URL: https://www.schneier.com/blog/archives/2016/01/replacing_judgm.html (访问日期:2016年4月20日)。 - [24] Bruce Schneier. Reputation in the Information Age. Nov. 2015.
网址:https://www.schneier.com/blog/archives/2015/11/reputation_in_t.html (访问日期:2016年4月20日)。 - [25] Eric Siegel. 预测分析:预测谁会点击、购买、撒谎或死亡的力量。霍博肯,新泽西州:Wiley,2013年。ISBN:1118356853。
- [26] E Strydom。E Strydom 访谈(销售副总裁,MineRP)。
- [27] P Vermaak。P Vermaak 访谈(SAP 数据分析顾问)。2015年11月15日。
- [28] Ralph Young。需求工程手册。波士顿:Artech House,2004年。ISBN:978-1580532662。