精华内容
下载资源
问答
  • 自助取数

    千次阅读 2019-08-26 21:07:31
    写过一篇《为什么BI取数这么难?》,今天来来谈一谈如何打造一个自助取数平台,仅是一家之言,欢迎拍砖。 首先,自助取数平台很难买到。 也就是,你很难找到符合你企业要求的通用产品,诸如BAT等企业内部的自助取数...

    为什么BI取数这么难?

    • 取数的量非常大。取数的量远远超过报表的量,因为报表往往是成形的指标的系统固化,而取数往往是具有探索性和分析型
    • 沟通成本高 。做分析,讲究的是个数据探索,探索本来是个不确定的事情,而且需要反复迭代,取数中业务人员和取数人员的沟通成本是很大的,两个不同背景的人,在业务口径和数据口径上要达到统一,对于双方要求都很高。
    • 取数对于BI的人员要求其实很高。要成为取数专家,特别强调的一点是一定要理解源系统数据,只有这样才能理解数据仓库模型的本质,才能更好的理解业务需求,通过刻意训练,你成为了公司内唯一能够连接起业务人员、仓库人员、源系统开发人员的桥梁,你才可能成为专家。专家不仅仅是满足需求的人,还能主动创造需求和给出建议,比如能对于数据仓库的模型提出改进意见,能对业务人员提出的需求进行质疑,这都来源于你对于数据认知的深度,但这样的人,其实很少,因为需要刻意训练。当然取数人员不仅需要专,也需要广,这又是为什么?数据分析的价值在于多领域数据的融合分析,这就需要取数人员对于公司的大多领域数据要有充分的掌握,数据广度往往决定了取数人员的视野,也决定了其发展潜力。
    • 取数要能自动化,但这个真得很难。除了增强取数人员本身能力,还有什么办法让取数越快呢?那就是自动化,平台化。取数不总是那么变幻万千,它也是有一定规律的,这为自动化提供了可能,比如有两类典型取数类型,营销清单型和复杂分析型,营销清单型,往往跟一线执行相关,70-80%的规则是比较简单的,通过配置往往就可以提供,复杂分析型,则规则比较难抽象,但也是有规律可循的。当然这类取数平台建设比较艰难,除了体验要好,性能要高,还要去做持续的运营,而且改变业务人员取数习惯很难。
    • 在这个大数据时代,取数人员还是要与时俱进。以前报表取数人员横跨业务和数据,号称是企业的综合型人才,但现在已经远远不够了。为什么?大数据时代技术突飞猛进,随着数据量的变化,IOE已经无法走遍天下了,你要取数取得快,需要升级你的平台引擎了,我能打造更牛逼的自助取数平台吗?最近也一直在问,我们传统企业的取数挖掘,能不能全部搬到SPARK?大数据结构越来越复杂,业务场景越来越多,SQL显然不够用了,我们的取数人员未来是不是要掌握各类语言,以适应不同的取数场景?比如,能否取出近3分钟的上网流数据并统计给我?能否临时爬虫看看公司的负面舆情如何?大数据时代更强调算法了,我们半路出家的取数人员,如果面对业务人员这个问题,该如何作答?能否给我取个数,看看杭州的公交司机有多少?这个还是传统的取数吗,是吗?不是吗?没必要去质疑业务人员,这个可能就是未来的临时取数需求,取数人员,准备好了吗?

    自助取数的优点

    (1) 能自助解决至少50%以上的取数需求;
    (2) 取数标准化,不易出错;
    (3) 速度更快,一般在30分钟;
    (4) 取数在线化,经验获得传承;

    BI自助取数是怎么炼成的

    自助取数平台是依据企业现状提供的数据解决方案

    首先,自助取数平台很难买到。

    也就是,你很难找到符合你企业要求的通用产品,诸如BAT等企业内部的自助取数工具,一般也是自研的,为什么?

    一是自助取数是个极度重视数据处理的工具,不仅需要一张可视化的皮,更需要依据企业现状提供数据解决方案,也就是数据和功能紧耦合,很多功能需要根据数据的特点量身定做。

    比如,我这个企业有个上百亿记录的HBASE指标库,自助取数产品需要基于这个引擎进行,如何抉择?

    二是BI产品越往上走越垂直,到达客户操作一层,操控更加难以抽象,报表可视化可能业界已经有些操作的规则,无非是选择维度和指标,但取数到底怎么个取法并没有固定的套路,它又写又读又查询又分析的,一个字:复杂。

    三是自助取数受企业的业务特点影响太大了,有些企业,以清单级的关联取数为主,有些企业,以复杂的汇总分析取数为主,有些企业,取数逻辑简单,但查询的速度要求却很高,不同的业务需求对于自助取数引擎要求可能很大不同,只有基于企业的特点才能得到一个妥协的方案。

    四是自助取数迭代要求偏高,企业的数据和分析变换万千,取数要素也必然随之要不停更新,这个工具显然要持续运营的,而产品化的东西,感觉很难跟上。

    话说,淘宝魔方本质上也是个自助取数平台,但这个能买得到吗?它其实也很难抽象成通用的产品,只适合电商,甚至只适合淘宝。

    其实可以类比,为什么这么多行业分别需要建立自己的C R M系统,市面上不是有很多C R M产品吗,自助取数道理跟它一样,没有包打天下的C R M,也就没有包打天下的取数工具,况且,数据的维度组合无限,而CRM好歹功能算是有限。

    BI自助取数要么自研,要么定制开发,很难奢望能有一个通用产品能真正符合要求,这由其特点决定。

    自助取数只能解决通用类取数问题

    其次,务必做好自助取数的可行性判断。

    自助取数很能完全替代人,想想也不可能,比如市场综合分析人员冒出的那种海阔天空的分析取数要求,在取数的时候涉及复杂的关联、跟踪等操作,自助取数很难支撑,即使勉强支撑,也会导致功能的极其复杂,带来体验的极度下降。

    取数有个特点,越偏向管理,越难取,规则越无法抽象,比如一般取数的难度排名如下:老大-领导-主管-分析-营销-执行,原因很简单,层级越高,人的自主性越大,越不可捉摸,如果老大怎么想的规律被你抓到了,就不要玩了。

    因此,自助取数实际只能解决部分问题,到底有没有价值,值不值得做,这就需要事先进行客观的评估

    幸好,一个企业的取数,往往简单通用类的取数还是占据了大部,这为特定企业自助取数工具的成功奠定了基础,比如某些运营商,一线简单的营销清单类取数,规则比较简单,且占到总取数量的60%到80%,而大多时候,这些取数还是在靠IT支撑人员写一个个脚本在取,效率可想而知,这让自助取数工具有了用武之地。

    因此,自助取数也是有点时势造英雄的感觉,不在那个行业,没有那个条件,就不要轻易上马一个自助取数项目。

    做好数据需求分析和功能分析

    第三,做好自助取数需求的分析,这决定了工具的成败。

    自助取数的需求分析是很艰难的工作,有两项最为重要的工作,一是数据需求分析,二是功能分析。

    针对数据进行分析,需要对历史的取数工单进行系统分析,至少能得出以下结论,字段属性的排名并作取舍,模型的分析并作取舍,要做到这个,需要对于企业的业务和数据有全局而深入的理解。

    本质上,自助取数是面向业务的,不是一个纯技术活,这也是自助取数很难产品化的原因。

    有一点特别要提,理论上做一张大宽表是体验最好的,但由于维度的限制,这是不可能的,因此,数据建模师就很重要了,设计需要达到很高的性价比,为了符合取数的特点,甚至需要全新打造一套新的取数数据模型。

    功能则需要调研,类似于设计产品,必须到一线中去了解需要哪些功能,怎么设计最好的配置方式,如何方便的找到相关模型、如何做好业务和数据的映射、如何方便的进行关联、如何方便的选择属性、如何方便的进行在线分析、如何方便的调度和监控、如何方便的导入导出数据、如何与现有的取数流程进行自动衔接、如何进行SQL解析、是否需要打造一个取数社区等等。

    下图是一张系统架构的示例,供参考。
    在这里插入图片描述
    最后就是要做出高保真设计,让业务人员试用,一定要简单简单再简单。最好不要培训也会配,你可以设计成4步法或者5步法,步数越多,则会大幅增加工具的使用门槛,比如:

    第一步,基本信息填写:填写取数的基本信息,包括业务目的、业务口径等信息。

    第二步,选取合适的取数模型:可以通过标签及搜索的方式从取数模型库中选取合适的模型。

    第三步,取数模型配置:对取数模型的配置主要包括三个方面,一是对模型输出结果的勾选,二是业务筛选条件的配置,三是外部数据的配置,允许导入外部数据,以及对取数结果进行特殊剔除等。

    第四步,模型间组合(可选):选择两个以上的模型,可以通过拖拽的方式对模型进行自由组合。

    第五步,取数任务执行:配置完数据的地域和时间范围之后即可提交取数。 取数模型选择
    在这里插入图片描述
    在这里插入图片描述
    取数任务执行

    第四,运营是临门一脚,业务人员不是一张白纸。

    取数作为企业的一项基础工作,传统取数的方式和流程已经成为套路,自助取数工具作为一种新的支撑手段,是对传统方式的挑战,即使产品再好,也需要做好内部的运营推广。

    曾经将研发的自助取数叫作取数机器人,强调了其自动化的特性,宣传口号是“完全自助,永远在线,极简操控,知识共享”。

    事实上,很多企业业务人员提出取数需求的代价并不高,取数也是企业的一项刚性成本投入,要改变流程和习惯并不容易,这就更考验产品的能力。

    况且自助取数与一般的企业内生产系统不同,其并不是必需的,人工取数是它最大的竞争对手,需要接受业务人员的最挑剔眼光。

    即使做过很多企业内部推广,还是有不少一线单位没有使用,究其原因,一是工具还没好到一定程度,二是缺乏持续的运营推广,三是企业人工取数成本太低,如果搞个虚拟结算估计会好很多,呵呵。

    第五,不同企业效果可能不同,但成功还是可期。

    当然,运营的效果还是要数据说话,说啥都是虚的,可以看到,后续自助的比例稳定在50%左右。不少企业能做到80%以上,也是令人非常羡慕的。
    在这里插入图片描述
    同时发现,一旦自助取数被投入实用,往往会大幅激发潜在取数需求,这对于公司是好事,说明原有的靠人工取数的方式已经抑制了大量的数据需求,信息技术的确是生产力,它让我们分析的成本、迭代的成本间接降低了。

    自助取数的速度依赖于使用的技术引擎和取数复杂度,一般可以达到小时或半小时,这个已经远远低于传统的按天的人工取数周期了。

    同时,自助取数的永远在线、口径的标准化、知识传承及很少出错也是其天然的优势。

    第六,给用户足够的自主权。

    自助取数最大的变数是业务,业务会带来数据模型的快速变化,因此需要最大可能的提供一线用户的模型自主权,因此,即使项目前期做了大量的数据调研,也务必能够让一线人员能够自行定制模型表,这也是一种开放化的思维。

    实际上,自助取数演变到现在,一线专业人员自行开发配置的模型已经占到了60%以上。因此,我们需要做这个发动机,一旦自助取数工具能够启动,也许,星星之火,就能燎原了。

    当然,自助取数工具还有大量的问题,需要去持续解决。

    自助取数强调关联查询的实时分析能力,原来的自助取数工具,是基于IOE的,这个性能的瓶颈显然是很难解决的,包括在线、实时等计算分析能力,这给用户的体验造成了极大的困惑,对于自助取数,平均半个小时显然也太长了。

    因此很羡慕BAT,其较传统企业,通过技术自主创新,还是能领先一步,诸如淘宝魔方这种所见即所得的取数方式,正是我们孜孜以求的,而这个靠购买产品的方式,显然很难。

    当然,如果有厂家能解决前面我提到的问题,也许真的能打造出通用的PaaS取数平台也不一定,但相信肯定是一体化解决方案,而不是轻量级的一个工具。

    由此想到了大数据,最近也在考虑MPP等数据库替代方案,比如GBASE、EXDATA啥的应该更好一点,但显然无法达到实时水平,也许IMPALA/SPARK等也可以尝试一下,无论如何,如果自助取数能移植到大数据平台上,还是能推动企业数据生产力的大幅提升。

    要承认,当前自助取数工具对于清单级的取数也许支撑的还可以,但对于汇总分析类的取数支撑难度就上了一个量级,因为一旦分析表格太复杂,自助配置复杂度也将达到一个量级,这就失去了自助的意义。

    也许,并不存在完美的自助取数,直接开放最终数据给业务人员,可能才是终极解决之道,再牛逼的工具或产品,在无边的数据形式面前,也需要妥协。

    参考:《BI自助取数是怎么炼成的》傅一平 链接:https://www.jianshu.com/p/9ea284bbb33a 来源:简书
    《为什么BI取数这么难?》 傅一平 链接:https://www.jianshu.com/p/4e240eba4b7f 来源:简书

    展开全文
  • 十幅图读懂BI自助取数系统!

    千次阅读 2019-12-04 08:15:00
    点击上方蓝字关注公众号!请您点击“与数据同行”以“关注”,关于数据的实践与思考,每周一我在这里等你!作者:傅一平 浙江大学博士毕业 当前就职于浙江移动有5年没有做报表取数了,但现在总...

    点击上方蓝字关注公众号

    请您点击“与数据同行”以“关注”,关于数据的实践与思考,每周一我在这里等你!

    作者:傅一平 浙江大学博士毕业  当前就职于浙江移动 

    有5年没有做报表取数了,但现在总是会想起取数的事,想到了现在还在欢乐运行着的自助取数系统,亲切的叫它”取数快点吧”,今天就来谈一谈这个系统 。


    一、总体思路

    在活字印刷出现以前,要印一本书很困难,需要根据书的内容刻成雕版,由于每本书的内容各不一样,需要为每本书单独刻成雕版,这样做既费事又费力。但是后来发现虽然每本书的内容千变万化,但是构成书的基本单元“字”是不变的,常用的中文字也就几千个,书无非是这些字的组合。后来毕昇发明的活字印刷术将每个字雕刻下来,形成活字,通过对活字的排版和组合来印刷书籍,大大提高了效率。

    我们的临时统计取数需求也面临着同样的问题,每个需求千变万化,口径各不一样,BI人员需要为其单独开发代码,效率低下。但是通过仔细分析可以发现,虽然业务口径各不一样,但是业务口径基本上是客户信息、各种业务量、产品订购关系和各种费用等条件的组合,也就是说构成业务口径的基本单元是有限的,只要具备了这些基本能力,就可以通过对这些基本能力的组合来满足各种业务需求。


    取数快点吧正是基于这样的思想,通过梳理出一系列原子的取数模型,每个取数模型对应一种基本的数据提取能力,然后采用向导式的、图形化的方式,通过对各个取数模型的组合来满足一个复杂的业务取数需求,改变过去依赖人工的方式,使得业务人员能够直接按需从数据仓库获取分析数据,包括以下几点:

    • 构建统一取数模型库,丰富基础的、单元性的数据提供能力

    • 打造向导式的数据机器人自助取数引擎,使得业务人员能够直接操作

    • 实现灵活的自助分析,满足业务人员更深层次的统计分析需求

    • 形成学习型的取数社区,通过不断的知识沉淀和共享来提升智能化数据提取能力

    二、取数模型

    一个取数模型由三大部分组成,分别是数据模型、业务筛选条件和输出业务指标。数据模型对应于数据库中的一个或者多个物理实体表,业务筛选条件是在数据模型基础上定义的条件参数,输出业务指标定义了取数模型最终能够输出的结果信息。取数模型本质上是对数据模型的一种封装,业务筛选条件是数据模型的输入,输出业务指标则是数据模型的输出。

    为了方便业务人员理解和使用,数据模型配置器中的“业务-数据转换配置”起到了数据向业务进行映射的作用,从而达到向业务人员隐藏技术细节,以业务语言进行展现的目的。以数据模型中的“套餐编号”这个属性为例,如果业务人员直接对“套餐编号”这个属性进行配置会觉得非常困难,而通过“业务-数据转换配置”可以将“套餐编号”重定义成“套餐类型”这个筛选条件,这个筛选条件下可以选择“动感校园套餐”、“动感社会套餐”等条件值,使得业务人员使用起来更为简单。

    在构建模型库的过程中,为提升业务人员的可用性和易用性,遵循了如下原则:

    • 可配置性原则:为了提高取数模型的灵活性,取数模型中的数据模型、业务筛选条件和输出业务指标均是可配置,可根据实际需求灵活调整,例如新增业务筛选条件等。

    • 业务指标相近性原则:通过分析历史的需求,将经常需要同时获取的信息放在一个模型中,使得模型更符合业务人员的使用习惯,例如模型同时提供客户最近三个月的ARPU信息等。

    • 筛选条件业务化原则:所有的筛选条件均需定义成业务人员可理解的形式,降低使用人员门槛。

    基于上述原则,对最近6个月的所有取数需求进行了分析和梳理,最终确定了近50个统一的取数模型,取数模型覆盖了业务人员常用的各种业务场景,以下是示例:


    三、自助向导

    如果说取数模型库解决了活字印刷术中制作活字问题的话,那么数据机器人引擎就用来解决对活字进行排版及印刷的问题。数据机器人引擎为业务人员提供了三个方面的核心能力:

    • 提供了一个公用的取数模型展现和对其操作的平台:数据机器人就像一个容器,允许取数模型库中的所有模型在这个平台上进行展示,并向业务人员提供了一个友好的操作界面,可以按照业务人员能够理解的方式对取数模型进行操作。

    • 提供了一个根据业务需求对取数模型进行自由组合的能力:单个取数模型的能力有限,无法满足一些复杂的业务需求,数据机器人允许业务人员对取数模型进行组合,从而具备了灵活应对各种业务需求的能力。

    • 提供了一个将业务操作结果转化为技术语言并提供最终结果的能力:数据机器人中的SQL解析和执行器负责将业务人员对取数模型的操作转化成机器能够识别的SQL语言,并提交数据库执行,最终将得到的取数结果反馈给业务人员。

    为了使得业务人员能够方便地完成自助取数,构建了一个向导式的、图形化的数据机器人引擎,通过自助数据机器人五步法即可快速地获取数据:

    第一步,基本信息填写:填写取数的基本信息,包括业务目的、业务口径等信息。

    第二步,选取合适的取数模型:可以通过标签及搜索的方式从取数模型库中选取合适的模型。

    第三步,取数模型配置:对取数模型的配置主要包括三个方面,一是对模型输出结果的勾选,二是业务筛选条件的配置,三是外部数据的配置,允许导入外部数据,以及对取数结果进行特殊剔除等。

    第四步,模型间组合(可选):选择两个以上的模型,可以通过拖拽的方式对模型进行自由组合。


    第五步,取数任务执行:配置完数据的地域和时间范围之后即可提交取数。


    当然,除了可视化配置,SQL高级模式也必然是要支持的。


    四、自助分析

    基于数据机器人自助取数结果,业务人员可以根据系统提供的自助分析功能进行灵活的、自由的分析,可以对结果按多个维度对指标进行汇总和分析,同时提供了图形分析和基础统计学分析能力,满足业务人员更深层次的分析需要。业务人员还可以将自助分析结果发布成周期性的统计报表,改变传统依靠技术人员手工开发报表的模式。


    五、取数社区

    取数快点吧同时是一个全省性的取数社区,大家的模型可以共享有无,系统对每次取数的业务口径、技术口径等信息进行了结构化,同时允许使用人员通过标签的方式对取数知识进行沉淀,以实现取数知识的全省共享。

    六、效果情况

    取数快点吧是一个相对比较简单的系统,但的确可以有效的提升取数效率,首先,人工取数量会下降,降幅达到30%左右,其次,业务人员潜在的需求得到释放,取数量增长了10倍,再次,取数需求的处理时间由原来人工方式的1-2天下降到30分钟左右 ,最后,取数可配置化后,错误会降低,知识会有传承,这是实实在在的好处。

    七、几点体会

    • BI自助取数系统是否建设依赖企业自身的情况,取数到达一定规模都可以考虑,但不是必须的,建设相对简单但运营困难,后续的优化迭代很重要。

    • BI自助取数系统适用场景是有限的,针对一线清单类取数需求最为合适,支撑的比例可以超过70%,探索类的复杂统计分析并不适用,但要相信一个企业主要的取数需求其实是非常简单的,要靠机器替代它。

    • 这里提的方式对于很多企业并不适用,更好的方式肯定是教会业务人员写简单的代码+提供租户能力,那个才是真正的搭台唱戏,但这个又有赖于企业的数据文化。

    • BI自助取数系统要尽量开放,特别是模型一块,可以让一线自主导入或开发,建系统的是无法理解一线的奇思妙想的数据需求的。

    • BI自助取数的后台引擎如果是ORACLE啥的,可以考虑大数据解决方案了,关联一下要30分钟跟几秒钟那是几何级的差距,对于一线体验影响是巨大的。

    • BI自助取数是只是取数的一种方式,需要与人工取数协同,让用户有多种选择,抢占入口,这样流量总会有的,初期对于提升用户很重要。



    • 这类系统前期最好定制建设,因为跟业务强相关,没人持续的呵护肯定会死的,大家都懂得。

    取数是BI最为重要的数据支撑手段,如果你从事取数相关工作,无论是新手还是老手,在疲惫的完成取数的时候,还是要留点时间给自己,想想有没有更好的支撑方法,这对于BI很重要。

    与数据同行

    ysjtx_fyp

    长按二维码识别,关注此号!

    展开全文
  • 需求分析

    万次阅读 多人点赞 2018-09-28 18:32:02
    1、确定对系统的综合要求:功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束(设计约束或实现约束描述在设计或实现应用系统时应遵守的限制约束条件)、逆向需求(说明软件系统不应该做什么)...

    (一) 需求分析的目标和任务

    他的基本任务是:准确地回答“系统必须做什么”这个问题,也就是对目标系统提出完整、准确、清晰、具体的要求

    1、确定对系统的综合要求:功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束(设计约束或实现约束描述在设计或实现应用系统时应遵守的限制约束条件)、逆向需求(说明软件系统不应该做什么)、将来可能提出的需求

    2、分析系统的数据需求

    3、导出系统的逻辑模型

    4、修正系统开发计划

    (二) 软件系统的可行性分析

    (三) 需求获取

    ①访谈

        正式访谈:系统分析员将提出一些事先准备好的具体问题

        非正式访谈:分析员将提出一些用户可以自由回答的开放性问题。

        调查表:需要调查大量人员的意见。

    ②面向数据流自顶向下求精

    ③建议的应用规格说明技术

    ④快速建立软件模型

    (四) 需求规格说明书

    是需求分析阶段得出的最主要的文档。

    结构化分析模型

    (五) 数据流建模(数据流图)

        描绘系统逻辑模型,图中没有具体的物理元素,只描绘信息在系统中流动处理情况。是非常好的通信工具和软件设计出发点。

    1、数据流图符号

            正方形(立方体):表数据的原点或终点

            圆角矩形(或圆形):代表数据的处理

            开口矩形(或两条平行线):代表数据存储(临时或永久:可能文件、文件的一部分、一个表、记录的一部分都行,不用考虑怎么存储)

            箭头:表数据流,即特定数据的流动方向(有流动的数据项或数据集合)

            数据流图附加符号

    2、解法:

    ①从问题描述提取数据流图四种成分

                    原点、终点、处理、数据流、数据存储

    ②着手画数据流图的基本系统模型

                    即一个原点一个处理一个终点,确定边界

    ③把基本系统模型细化,描绘系统主要功能

    ④主要功能进一步细化

    ⑤结束,或进一步分解到涉及如何具体实现功能时,不再分解。

    3、分层数据流图:为表达数据加工情况,需采用层次结构数据流图

            顶层、中间层、底层

            分层数据流图的几个问题

                ①编号的设置父为2则子为2.1、2.2 。。。

               ②父子图的平衡

               ③局部数据存储不用平衡

    4、数据流图的命名规则

        ①数据流:用名词;代表整个数据流(数据存储)内容,不仅仅反应某些成分;不用缺乏具体含义的名字如“数据”“信息”等

        ②处理命名:用动宾词组,避免使用“加工”“处理”等笼统词;反应整个处理的功能,不是一部分功能;通常只包括一个动词,否则分解

        ③数据原点/终点:在问题域习惯用命(如“采购员”“学生”)

    5、数据流图的用途

        ①作为交流信息工具

        ②作为分析和设计工具:自动化边界划分

    (六) 实体-关系建模(E-R 图)

    描述数据对象之间的关系

    图中数据对象属性用“数据对象描述”表达

    1、组成:数据对象:软件必须理解的符合信息表达,复合信息是具有一系列不同性质或属性的事务

    2、数据对象间关系:一对一、一对多、多对多

    3、属性:定义数据对象的性质

    4、实体关系图

    (七) 系统行为建模

    1、软件行为模型:状态、事件、行为

            状态:被观察到的系统行为模式

            事件:引起状态转换的外界事件抽象

            行为:进入某状态所作动作

    2、状态转换图符号

            状态:

                   初始状态(只能有一个)

                    最终状态(可能多个)

                    中间状态

                    事件:

                            箭头:箭头上事件名。保安条件   [  ] 这种标志条件为真时导致改变

            行为:

                    状态框内加   "do:行为名"

    3、贼经典的例子

     

    (八) 用例建模(用例图)

    用例图描述外部执法者与系统的交互,表达系统功能,即系统提供服务

    1、主要元素用例和执行者

            用例:执行者与计算机一次典型交互,代表系统某一完整功能

            执行者:描述与系统交互的人或物,代表外部实体(如用户,硬件、设备等)

                    直线表示关系

    2、建立用户模型

            ①发现执行者

                    谁使用该系统;谁改变系统的数据;谁从系统取信息;谁需要系统的支持以完成日常任务;谁负责维护管理并保持系统正常运行;系统需要应付那些硬件设备;系统需要和哪些外部系统交互;谁对系统运行产生的结果感兴趣;

            ②获取用例

                   向执行者提出问题(从用户观点)

                           执行者需要获取何种功能,需要做什么;执行者需要读取产生、删除、修改或存储;系统发生时间和执行者间是否要通信;

                    用户观点非系统观点

            ③执行者间关联:

                    泛化关系:一般特殊关系(特殊者指向一般执行者)

            ④用例间关系

                    泛化关系

                    包含关系:一个基本用例包含另一个用例行为(要实现基本用例必须满足另一个用例行为)

                    扩展关系:允许一个用例扩展另一个用例提供的功能,与泛化类似,但有更多限制:基本用例必须声明“扩展点”,扩展用例只能在扩展点上增加新行为

    3、我自己画的一个用例图---不对请留言指正,正在研究,有更好的画法,风格更好更正规的画法,请留言指正。

    (九) 面向对象建模

    展开全文
  • 如何避免重要需求遗漏?

    千次阅读 2019-09-11 18:21:14
    避免重要需求遗漏的思路 避免重要需求遗漏,首先我们需要反问一句 —— 为...我们是否有提高或改善响应能力的空间,如果我们可以更快调整和响应,使得这些临时需求对我们产生不了什么影响,那么这个问题也就不再是...

    避免重要需求遗漏的思路

    避免重要需求遗漏,首先我们需要反问一句 —— 为什么这些紧急重要的需求无法更早预见?同样的,我们需要了解:

    • 具体是哪些外界原因?这些原因是否有共性,有的话,那就针对性处理;
    • 增加的需求有无共性特点?有的话,可以针对性处理;
    • 临时增加有多临时?我们是否有提高或改善响应能力的空间,如果我们可以更快调整和响应,使得这些临时需求对我们产生不了什么影响,那么这个问题也就不再是问题了;
    • 既然是常态,为何我们的流程没有做出调整去应对?是调整过流程或工作方式,还是无法解决问题,还是说不知道该怎么调整流程或工作方式去适应?

    具体操作方法

    具体操作,可以按照事前、事中、事后各个阶段来采取不同的措施处理。

    一、事中的处理

    根据具体情况不同,在发现需求遗漏的当时,可以采取如下一些做法:

    • 重要需求遗漏,不紧急:既然不紧急,按照常规做法增加进去即可,但如果经常出现遗漏,就要考虑是否是需求分析和规划的实践做法有问题,才会导致问题持续出现,这种情况,应强化需求结构化管理,从全局出发进行思考和规划,避免因为思考的片面化和局部性导致的遗漏;
    • 重要需求遗漏,紧急:既然是又重要又紧急的需求,那么必然就得调整当前开发工作的顺序,把这个遗漏的重要紧急需求插进去,把工作安排下去;然后就要考虑从需求的优先级和需求的结构化管理两个方面入手复盘,并切实改进,避免类似情况再次发生;
    • 需求遗漏:如果是不太重要的需求遗漏,按照常规做法处理即可;可以根据其紧急程度和影响,决定是否调整工作顺序让这个需求插队;如果这种情况反复出现,那建议可以考虑进行复盘,从需求结构化管理的角度进行分析,并商讨改进措施;

    二、事后的处理

    事后其实就是复盘,复盘的关键是要基于盘来推演和分析,这个盘就是事前制定的模型和规范。是我们有模型有规范,但执行出了问题?还是说这几个需求情况特殊,模型比较简单没有覆盖到这些特殊情况?还是说模型和规范都没问题,就是人员能力不足,导致判断偏差大?只有找到正确的根因,才能够真正有效的解决问题,所以我们不复盘则已,要复盘就务必要认真严格地进行复盘。

    怎么复盘?复盘也是有方法有套路的,业界也有相关书籍可供我们参考借鉴。例如温伯格在《成为技术领导者》中提出的MOI模型就可以用作复盘的一种思路。

    • M:激励(Motivation),是不是人们没有动力去做这件事情?
    • O:组织(Organization),是不是无组织无纪律、一片混乱,人们不知道自己或别人该做什么?
    • I:想法或创意(Idea/Innovation),是不是缺少如何解决这些问题的点子或创意,不知道有什么办法解决这个问题?

    复盘时要注意,受限于能力或经验以及出问题次数多少的影响,我们可能无法得出一个准确的结论和必然有效的解决方案。此时一方面需要秉持持续改进的心态,我们可以先落实当前已经比较明确的改进措施,后续再观察效果,持续复盘、持续改进即可。另一方面我们也可以先采取一些临时措施。

    1. 预留时间:比如,如果确实很难分析清楚为什么总是会遗漏需求,无法进行非常有针对性的处理时,也可以采取较为模糊应对的方式。可以拉取过去一段时间的工作记录,评估这段时间每个迭代的突发需求所消耗的工作量投入,可以取个平均值,然后在后续进行迭代工作安排的时候,固定的预留出一定量的时间,用于应对极有可能会出现的突发需求。
    2. 需求拆细:当出现突发需求,导致我们需要调整工作顺序时,很有可能会因为需求颗粒度大以至于腾挪余地有限,而难以避免突发需求带来的影响,因而还应该尽可能地采取拆细需求的方式,将颗粒度比较大的需求拆分为较小颗粒度的需求,可以增加调整需求工作顺序时的灵活性;

    要确定到底要预留多少时间,可以利用DevCloudEpic-Feature-Story结构,把突发需求汇集在一起,便于统计。例如创建一个特殊的Epic“突发需求,下一级是为每个迭代创建的Feature,用来承载各个迭代里面具体的那些突发需求(体现为Story),并做好工时的记录,迭代结束后,就可以来计算出现了多少个突发需求、投入了多少工作量了。

    也可以采用模块字段来辅助记录和统计突发需求的数据。例如,新建一个模块,取名突发需求,所有突发需求都标注为这个模块,那么后续就可以基于模块进行筛选或查看报表等方式来统计突发需求所消耗的工作量了。

    三、事前的处理

    事前的处理放到最后来介绍,是因为之所以会出现问题一般都是因为事前没有做好,但已经出现了问题就需要在当时尽快处理,所以先介绍了事中的处理。但当我们处理完问题也完成了事后复盘,就需要考虑未来的事前,尽可能的避免问题发生。
    简单来讲,事前的话,就是要做好需求的结构化管理和需求的优先级管理,以及做好相关规范的宣导、人员的动员和能力的培养,这样就能够有效的避免或减小突发需求带来的影响了。

    参考附录

    相关书籍

    1. 杰拉尔德·温伯格:《成为技术领导者》
    2. 邱昭良:《复盘+:把经验转化为能力》
    展开全文
  • db2 系统临时表空间

    万次阅读 2014-05-26 14:28:15
    确保系统临时表空间的页大小符合要求 更大记录标识符(RID)的使用增加了来自查询或定位更新的结果集的行大小。如果结果集中的行大小接近于现有系统临时表空间的最大行长度限制,那么可能需要创建具有更大页大小...
  • 华为新软件全过程管理资料,包括“需求分析+概要设计+详细设计+接口设计”的全套模板,方便您学习和临时取用。
  • 经常我们的程序中需要访问一些特殊的路径,比如程序所在的路径、用户目录路径、临时文件夹等。在 Qt 中实现这几个功能所用的方法虽然都不难,但是各不相同,每次用到时还要现去查,很不方便。因此就写了这篇博客,把...
  • 开发业务需求,需要对一个表作数据分析,由于数据量较大,而且分析时字段会随条件相应变化而变化
  • 即使父类的析构函数设置为虚函数,那么当父类指针指向子类对象的时候,也...该章节三个知识点比较重要:第一对象的构造和析构,第二new和delete运算符 第三个是:临时变量。 ---》C++支持栈上的对象,所以栈上的变量的
  • 文章目录1.数据需求2.数据分析需求3.沟通要点3.1 评估类分析3.2 原因类分析3.3 预测类分析 1.数据需求 什么是数据需求?数据需求就是用数据来描述一个具体事务的需求。比如周报,每周的数据...取数的指标:比如PV,...
  • 表变量与临时表的优缺点

    万次阅读 2016-02-28 17:57:21
    表变量:   DECLARE @tb table(id int identity(1,1), name varchar(100))     INSERT @tb  SELECT id, name FROM mytable WHERE name like ‘zhang%’  ...临时表:   SELECT name, address  INT
  •  “在正式讲解需求之前,咱们先来了解一下公司的业务现状,”,小Q觉得即便是程序员,也非常有必要先了解一下业务背景,以需求为出发点,才能设计出更贴合业务的系统,而且也会更加有参与感。    “①咱们...
  • 共享单车需求预测

    千次阅读 多人点赞 2018-06-25 20:59:36
    共享单车需求预测 数据集介绍 数据集来自Kaggle的一个Playground竞赛。数据产生于记录了骑行时间,出发地点,到达地点,到达时间的共享单车传感器网络,其可用于研究城市中的移动特性。本次比赛中,参与者要求将...
  • 如何写好PRD(产品需求文档)+范例

    千次阅读 2014-05-05 23:21:31
     产品需求文档(product requirements document,PRD)描绘出公司将要创造的产品。它影响着公司的产品团队的成果,公司的销售额、市场和客户满意程度。它要为公司提出更重要,更有价 值的产品。产品需求文档需要清楚...
  • 话说小P刚刚加入到一个项目组里面,项目经理安排他做需求分析,小P一听需求分析就有点不乐意,心里嘀咕:“需求有什么分析的啊?客户要什么给什么呗,简直是浪费我这个人才!”  虽然不乐意,但毕竟工作还是要做...
  • 避免重要需求遗漏的思路 避免重要需求遗漏,首先我们需要反问一句——为什么这些紧急重要的需求...我们是否有提高或改善响应能力的空间,如果我们可以更快调整和响应,使得这些临时需求对我们产生不了什么影响,那...
  • 软件需求分析摸板

    千次阅读 2011-02-25 16:39:00
    软件需求分析规格说明书模板
  • 摘要:高端内存页框的内核映射分为三种情况:永久内核映射、临时内核映射和非连续内存映射。那么这三者有什么区别和联系呢?临时内核映射如何保证不会被阻塞呢?本文主要为你解答这些疑问,并详细探讨高端内存映射的...
  • 软件工程需求分析文档模板

    万次阅读 2014-02-25 09:45:00
     许多有经验的开发团队在开始需求调查的时候,总会将“软件客户需求权利书”和“软件客户需求义务书”提交给客户,让客户明确其权利与义务,将会对需求调研、分析的工作带来意想不到的效果,你可以一试。...
  • 需求分析类文档模板

    千次阅读 2008-10-15 08:57:00
    需求分析类文档模板编者说明: 许多有经验的开发团队在开始需求调查的时候,总会将“软件客户需求权利书”和“软件客户需求义务书”提交给客户,让客户明确其权利与义务,将会对需求调研、分析的工作带来意想不到的...
  • Ad-Hoc简而言之是“临时命令”,英文中作为形容词有“特别的”,“临时”的含义。 Ansible提供两种完成任务方式:一种是Ad-Hoc命令集,即命令ansible,另外一种就是Ansible-playbook了,即命令Ansible-playbook。 ...
  • 对于大部分人来说,可能并没有机会进行需求分析,因为在大部分的公司里面,需求分析都是有很多工作经验的资深人员,或者是对系统很熟悉的老的开发人员。   所以,很多人都会对需求分析有一种景仰的心态,认为既然...
  • 表变量与临时表的优缺点?

    千次阅读 2011-07-13 13:01:42
    通常情况下,应尽量使用表变量,除非数据量非常大并且需要重复使用表。在这种情况下,可以在临时表上创建索引以提高查询性能。但是,各种方案可能互不相同。
  • 最近在使用spark处理一个业务场景时,遇到一个小问题,我在scala代码里,使用spark sql访问hive的表,然后根据一批id把需要的数据过滤出来,本来是非常简单的需求直接使用下面的伪SQL即可: select * from table ...
  • 性能测试需求指标分析方法

    千次阅读 2013-11-20 18:32:08
    本文目的是提供性能测试分析人员在测试需求分析阶段提供技术指导作用,指导其对采集的业务数据进行整理并转换为合理的项目性能需求指标,并提供测试执行人员在执行过程中以此为目标。 二、 名词解释 Ø 业务模型...
  • 计算机软件需求说明编制指南

    千次阅读 2006-05-20 01:35:00
    计算机软件需求说明编制指南1 引言 1.1 目的和作用 本指南为软件需求实践提供了一个规范化的方法。本指南不提倡把软件需求说明(Software Requirements Specifications,以下简称SRS)划分成等级,避免把它定义成更...
  • mysql大数据量下两张表的差集

    千次阅读 2020-02-12 21:07:32
    两张表的关联id的并集并作为临时表temp的id,然后count(id)=1即为两张表的差集(因为两张表union all后同一个关联id出现次数必然会大于等于2) 表结构 A: id,name,status B: id,sid,create 关联: B.sid=A.id 之前sql...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 70,902
精华内容 28,360
关键字:

临时取数需求