精华内容
下载资源
问答
  • 如何了解人工智能产品体系 我们从搭建一个人工智能产品需要一个怎样的基础架构,到剖析架构中每个组件的含义以及对整个系统起到的作用和扮演的角色,最后对每个组件展开讲起。 1、人工智能产品实现逻辑 通常的一...

    如何了解人工智能产品体系

    我们从搭建一个人工智能产品需要一个怎样的基础架构,到剖析架构中每个组件的含义以及对整个系统起到的作用和扮演的角色,最后对每个组件展开讲起。

    1、人工智能产品实现逻辑

    通常的一款人工智能产品涉及了很多技术,包括语音识别、语音合成、机器视觉、自然语言处理、文本/语义理解等多项技术等交互集成。人工智能的目标是模拟和延伸人的感知、理解、决策、学习、交流、移动和操作物体的能力。感知是人工智能实现的第一步,目前已经有了实质性的进展。理解和决策需要机器学习和人类指导相结合的方式才能实现。

    目前阶段的人工智能还是弱人工智能,产品的流程可以概括为:海量数据训练和学习,从中识别规律和经验,新数据通过得到的经验用接近人的思维处理。

    通过对角色分工、处理过程、功能价值三个不同的角度,一个人工智能产品的体系包含四个重要角色:
            1、基础设施提供者。
            2、数据提供者。
            3、数据处理者。
            4、系统协调者。

    我们从数据流开始说起。
    人工智能的产品体系是一个动态流程,本质上是围绕数据采集、存储、计算展开的。
    1)数据提供者使用各种手段获得原始数据。
    2)数据处理者对数据进行加工。
    3)数据处理者进行模型训练,获得可以使用对模型。
    4)用模型对新数据进行预测。

    以上我们就完成了“数据--信息--知识--智慧”的过程,再随着动态循环,就是“训练--推断--再训练--再推断”的过程。产品经理需要完成系统集成、需求定义、资源协调、解决方案封装的保障工作。

    2、基础设施

    1)传感器:对信号模式进行转换。主要应用于可穿戴应用、高级辅助驾驶、健康监测、工业控制。举个例子,无人车对传感器有激光、毫米波、超声波、红外线等,产品经理需要对不同对传感器有自己对了解。
    2)芯片:完成训练和推断的强大计算能力的计算核心。模型训练:对神经网络和海量数据计算对核心部件应该有充足对了解。云端推断:服务器对CPU、GPU、TPU等计算单元。终端设备:手机、摄像头等。
            按照定制化程度,芯片又分为:
                    通用芯片:CPU、GPU、TPU等,可以处理通用任务类型。
                    FPGA半定制化芯片:延时低,用硬件实现软件算法。
                    ASIC:算法模型可以烧到芯片中,运行效率高。理论上先用FPGA在市场中试错,之后用ASIC量产。
    3)基础平台
            1、大数据技术:算法虽好,数据决胜。
            2、云计算技术:降低了研发成本。

    3、数据收集

    数据收集类似于人类对各种感觉,没有感觉就无法判断。

    1、数据来源:直接购买行业数据和免费的数据源;自行采集和爬取;第三方合作。
    2、数据质量:(1)关联度;(2)时效性;(3)范围;(4)可信性。

    4、数据处理

    对原始数据对加工。可以概括为:数据  ---  机器学习给出规则  ---  新数据通过规则得到结果  ---  伴随着输入/输出的过程自我优化

    5、机器“大脑”处理过程:识别、理解和推理、决策

    1)识别:大量大量的数据存在计算机中计算得到一个模型,对于新数据判断。
    2)理解和推理:识别侧重于人对环境的感知,理解和推理强电深层次的理解和归纳能力,是对识别之后的数据的再次处理过程。
    3)做决策:通过对外界客观事物、环境、推理和理解来判断采取怎样的行动。

    6、系统配置统筹的关键环节:系统协调 

    构建一个人工智能系统需要多方协调:包括基础设施提供者、信息提供者、信息处理者在内的各种公司或公司内部各个部门。系统协调者需要在人工智能的不同阶段:需求定义、设计开发、系统优化、运行保障、售后支持、监控和审计发回资源协调和统筹作用。

    人工智能产品体系最常见的发展规律是:一开始以项目交付解决单个场景的具体需求为主,看重个性化;当项目的技术和产品需求验证完毕后,就可以使产品走向千人千面的产品化;接下来是服务化,通过对外开放和输出各种服务能力,逐渐与终端用户具体业务解耦,统一数据中心和算法平台;最终实现平台化,帮助用户实现根据自身需求完成各种功能模块的在线快速封装和灵活配置。

    考虑到企业的发展速度、市场规模、技术实现瓶颈及业务特殊性多方面因素,需要人工智能产品经理具有成本意识、市场敏锐度、前瞻性和大局观等综合素质。

    7、不可逾越的红线:安全、隐私、伦理、道德

    (1)安全:人工智能产品认为可控;人工智能产品不会影响公共安全。

    (2)隐私:人工智能产品经理至少要评估一下四项:
            1、评估所有产品流程中涉及用户权利的风险。
            2、评估产品在设计或运行过程中的系统描述。
            3、基于产品设计或运行的目的,评估过程是否是必要的。
            4、针对识别出的风险,给出针对风险的管理措施。

    在涉及到隐私数据保护措施中,我们可以从三个方面着手:
            1、减少对训练数据量的需求
                    1)生成对抗网络(GAN):通过轮流训练判别器和生成器,令其互相对抗,从复杂概率分布中取样,生成文字、图片、语音等。
                    2)联合学习(Federal Learning):部分训练过程放到用户手机,将模型传回服务器,不涉及用户敏感数据。
                    3)迁移学习(Transfer Learning):把一个场景学习到的模型举一反三迁移到类似的场景中的方法。

            2、在不减少数据的基础上保护隐私:
                    1)差分隐私技术(Different Privacy):在数据库检索时,加入满足某种分布的噪声,使查询结果随机化。
                    2)同态加密技术(Homomorphic Encryption):在密文上进行计算,生成加密结果,解密后的结果与对明文进行相同操作产生的结果一致。核心在于,支持在加密的数据上进行查询操作,解决数据委托给第三方如云计算公司时的安全问题。
                    3)提高算法可解释性,避免黑盒子事件的发生。

    (3)伦理道德
    在产品设计时,主要从以下三个方面重点关注人工智能的特殊性所带来的伦理问题:
            1、人工智能产品算法的“可解释性差”、“不透明”,使得一旦发生伦理道德事故无法评判。
            2、人工智能代替人履行社会职能的时候,产品的“不可预见性”有可能导致伦理道德争议。
            3、人工智能产品的道德地位值得思考。

    8、运维管理

    人工智能产品的运维和传统IT运维的出发点都是让业务高效稳定的运行。评价标准:
            1、系统能否第一时间发现异常。
            2、发现异常后能否第一时间找出原因。
            3、从原因能否定义到具体问题。
            4、问题能否自动修复或者自我修复。
            5、未来出现类似问题能否提前预警。

    展开全文
  • 数据产品-指标标签体系构建

    千次阅读 2020-04-14 11:37:07
    数据产品-指标标签体系构建 作为刚毕业不到一年的数据产品经理,今天和大家分享一下我接触到和认知范围内的数据产品经理关于数据指标标签体系的构建过程是什么样子的 1、解读数据库数据 ①在我们公司(家居互联网...

    作为刚毕业不到一年的数据产品经理,今天和大家分享一下我接触到和认知范围内的数据产品经理关于数据指标标签体系的构建过程是什么样子的

    1、解读数据库数据

    ①在我们公司(家居互联网行业),我们作为数据部门,能够查看公司全部的数据,所以我们日常会接收到来自其他部门的提数申请,有简单的导出关于家居行业中设计方案的素材的使用情况、也有需要我们经过数据加工分析后的数据分析表等,说这个不是想说我们日常工作只是提数分析,而是想说,在一个数据中台和业务中台还没成体系化的公司中,开放这样一个数据出口,能够让我们快速接触到各条业务线中对于数据的需求情况,以及各业务线关注的业务信息。
    ②通过自己试用期期间的业务积累,当然不当当通过上面的提数通道了解到的,以及每次数据需求的积累,给我最大的感受就是:作为试用期的数据产品经理,最需要的就是对公司底层数据的熟悉度,已经能够运用sql查询出业务方所需要的数据,并能在excel进行分析。
    ③回顾自己对解读数据库数据的认知经历,大概就是:业务需求->业务对应的数据库是什么->不同库之间是怎么关联的,包括业务关联和字段关联->该库里面存放的表的业务是什么->表里面的字段含义是什么。对于前部分的业务和数据库、数据库和数据库之间的关联,在我入职时去年的师姐已经整理好了好几份比较详细的文档,我觉得这样的数据逻辑图非常重要,非常能够辅助我快速认知业务关系和数据库关系,样例如下图:
    在这里插入图片描述

    2、解读业务需求

    通过试用期期间对底层数据有了很好的认知之后,这里的很好认知我认为至少是你知道大部分数据库都是存放什么样子的业务数据,每个库里面经常用的表有哪些,这些表里面那些字段是比较常用的,并能够在不看相关的解释文档的前提下,运用sql快速查找出你想要的数据。有了数据认知后,我觉得对自己核心竞争力有帮助的不是你对底层数据的了解情况,更重要的是你能够把你接触到的数据需求汇总成为具体的业务共性,就比如:常用部门想知道某些东西的拖拽频率、使用频率。但他们的最终需求都是想要把更好的东西推荐给用户,这就是一个共性的东西,而作为数据产品经理,就是需要把这些共性的需求聚合成为整个能够指导业务发展的东西,并用相关的指标标签进行描述。下面这个是之前的一个项目中构建的一些指标标签的部分截图:
    在这里插入图片描述

    3、指标逻辑实现

    ①构建完相关业务的指标标签体系之后,就是又要回归底层数据了。像我之前做的项目,我们所有新构建的指标和标签,都是需要通过大数据部门,重新建立新的数据库和数据表,因此我们需要对每个字段的源数据逻辑和数据聚合逻辑进行详细的中文说明和sql说明,一方面是便于大数据进行开发建表,另一方面是方面后面内容推出后,其他部门的人对我们东西使用的方便性。在这个过程中,我才后知后觉原来数据产品已经是半个开发了,不仅要梳理底层指标sql,对于可视化在BI界面上面的sql也要我们来梳理。但是有个好处就是,作为数据产品,我暂时还不需要考虑到sql的效率问题,因为我们的sql只是辅助大数据的人员理解指标和标签,他们在新建表的时候会对你的sql进行优化提升。
    ②为了方便指标的实现,前期还是需要做很多相关的整理工作的,比如对指标进行分类整理,因为你不可能把所有的指标标签都建在一张表里面,所以还需要了解一下建表的一些简单事项,比如标关联、索引等,比如要是大数据的小伙伴人比较好的话,会帮你一起想这些东西。这里说下指标和标签的区别,指标可能就是最基础,常用用户认知的,比如使用量,近七天活跃这些,但是标签是对这些进行分层处理,比如使用量,那多少时高,多少是低,可能你就需要通过聚类算法,构建出一个能够衡量高低的定义了。比如我当初构建的其中一个标签:素材价值度,通过对历史使用数据的聚类分析,后面构建出的公式和定义为:

    价值度划分=>划分为五个等级:一星-两星-三星-四星-五星
    价值量=搜索次数0.3+在优秀方案中使用次数0.4+收藏数*0.3
    一星:价值量=0
    二星:0<价值量<=1.5
    三星:1.5<价值量<=10
    四星:10<价值量<=40
    五星:价值量>40

    接下来讲下指标标签的具体实现过程,这里我会拿一些例子来做解释,主要是讲解一下sql的实现,当然,其实我自己的sql也不是很好,但是我觉得够用就行,能够满足自己日常业务工作的数据提取需求,很多函数都是在业务中在慢慢去百度查找。之前的项目我是把全部构建的指标和在BI上面可视化的逻辑分成了五个表,下面只对部分进行说明:
    在这里插入图片描述
    数据逻辑分层表
    ①基本信息表中:主要是对一些不可或缺的字段的直接迁移,因为不管构建什么样子的标签,有些基本属性是不可或缺的,所以这一块 的逻辑一般是比较简单的,一般是直接从源库中把字段提取出来就行。这里有个建议就是:竟然我们的逻辑是写给大数据开发看的,所以就尽可能的解释的详细,可以减少很多后面的沟通工作

    #素材的基本信息#
    #放置位置:pmc.designmaterial#
    #字段:素材名称-素材id-素材url-上传时间-上传人员-上传部门-上传机构-产品id#
    #是否在3D中-是否公用-是否可渲染-素材标志-材质属性-使用区域#
    #-素材是否有商品-零售价格-批发价格-成本价格-搭配组合内容-放置规则-素材颜色-是否关联到组合#
    select materialid,materialname,imagepath,posttime,author,deptid,organid,
    productid,IS3D,ispublic,isrender,modelflag,property,usearea, 
    ishasproduct,retailprice,wholesaleprice,costprice,placeheight,placerule,color,isrelate
    from pmc_kudu.designmaterial
    

    ②使用信息表中:主要是对一些常用的使用情况进行统计,因为有很多业务部分会经常想知道某些商品素材的七天使用情况、30天使用情况、收藏情况等等,每次我们查询的时候都需要关联很多表才能够查出来,效率非常低下,所以就考虑直接构建相关字段,便于后面查找。当然,这里不是说想构建啥就能构建啥的哈,因为每个字段后台每天都回去更新,都会消耗服务器资源的呀,而且后面项目结束时,所有构建的字段都需要有合理的解释,说明你构建的意义的。所以还是回归产品的初心,做什么都要讲价值。

    #以下的使用信息都只统计一个时间段,其他时间段的只要改变时间信息就可以#
    #统计素材的拖拽信息,近30天拖拽次数#
    select materialid,sum(dragTimes) as darg_cnt30,substr(sendtime,1,10) as nowtime from 3D_point_kudu.materialDragInfo 
    where datediff(now(),sendtime )<=30
    group by materialid,substr(sendtime,1,10)
    
    #统计素材在UGC中的使用次数,近30天#
    select a.materialid,sum(a.dragtimes) as use_yx_cnt30,a.nowtime from
    (select materialid,dragtimes,schemeid,substr(sendtime,1,10) as nowtime from 3D_point_kudu.materialInfo
    where datediff(now(),sendtime )<=30)a
    left join 
    (select id,scheme_name from ugc_scheme_kudu.home_scheme)b
    on a.schemeid=b.id
    group by a.materialid,a.nowtime
    

    ③标签表:标签表是构建指标标签的核心,因为这里的所有标签的合理程度一定要明确,而且逻辑一定要说得通,要不很容易别人就质疑你构建的标签合不合理或者必不必要。特别是用了相关数据挖掘的东西的话,也需要做相关的技术说明。我觉得构建标签也是最难的一块,当你对业务认知不深的时候,你所构建的标签所描述的东西就很浅,这也是我在做完这个项目后一直在思考的问题。但是东西总是循序渐进的,那时候的自己也懂的很少。所以我建议以后再做相关的数据产品时,一定要多调研,不管是对自己公司内部的还是对公司外部竞品相关的,都要有足够的认知。还有就是标签的sql逻辑一般比较复杂,当初有好几个都是我中文描述逻辑,然后让同组的小伙伴帮忙写的,还好她们人都比较好,所以我学的sql很多也是她们教我的,还是挺感谢的。下面就只举两个标签吧,偷偷说下,查询效率超级低,要跑很久才能跑出数据哈哈,不过大数据的小伙伴会帮你优化的,不用管那么多。

    --1、素材价值度
    #价值度划分=>划分为五个等级:一星-两星-三星-四星-五星#
    #字段名:active_value#
    #价值量=搜索次数*0.3+在优秀方案中使用次数*0.4+收藏数*0.3
    #一星:价值量=0
    #二星:0<价值量<=1.5
    #三星:1.5<价值量<=10
    #四星:10<价值量<=40
    #五星:价值量>40
    select  z.materialid,
    case when (isnull(z.sc_cnt,0)*0.3+isnull(h.ss_cnt,0)*0.3+isnull(y.yxsy_cnt,0)*0.4)=0 then '一星'
         when (isnull(z.sc_cnt,0)*0.3+isnull(h.ss_cnt,0)*0.3+isnull(y.yxsy_cnt,0)*0.4)>0 and (isnull(z.sc_cnt,0)*0.3+isnull(h.ss_cnt,0)*0.3+isnull(y.yxsy_cnt,0)*0.4)<=1.5 then '两星'
         when (isnull(z.sc_cnt,0)*0.3+isnull(h.ss_cnt,0)*0.3+isnull(y.yxsy_cnt,0)*0.4)>1.5 and (isnull(z.sc_cnt,0)*0.3+isnull(h.ss_cnt,0)*0.3+isnull(y.yxsy_cnt,0)*0.4)<=10 then '三星'
         when (isnull(z.sc_cnt,0)*0.3+isnull(h.ss_cnt,0)*0.3+isnull(y.yxsy_cnt,0)*0.4)>10 and (isnull(z.sc_cnt,0)*0.3+isnull(h.ss_cnt,0)*0.3+isnull(y.yxsy_cnt,0)*0.4)<=40 then '四星'
         when (isnull(z.sc_cnt,0)*0.3+isnull(h.ss_cnt,0)*0.3+isnull(y.yxsy_cnt,0)*0.4)>40 then '五星'
         end as active_value
    from 
    (
    --统计素材的收藏次数,没有时间信息#
    select c.materialid,d.collectcount as sc_cnt from
    (select materialid,materialname from pmc_kudu.designmaterial)c
    left join 
    (select materialid,collectcount from pmc_kudu.modelcollectext)d
    on c.materialid=d.materialid
    )z
    left join
    (--统计素材在优秀方案总的使用次数,近30天#
    select a.materialid,sum(a.dragtimes) as yxsy_cnt from
    (select materialid,dragtimes,schemeid from 3D_point_kudu.materialInfo
    where datediff(now(),sendtime )<=90)a
    inner join 
    (select id,scheme_name from ugc_scheme_kudu.home_scheme)b
    on a.schemeid=b.id
    group by a.materialid
    )y
    on z.materialid=y.materialid
    left join 
    (--统计被搜索次数
    select d.materialid,a.cnt as ss_cnt from pmc_kudu.designmaterial d 
    left join 
    (select value,count(uuid) cnt from 3d_point_kudu.datainfo 
    where value in (select materialid from pmc_kudu.designmaterial) and datediff(now(),sendtime )<=90
    group by value)a
    on d.materialid = a.value
    )h
    on z.materialid=h.materialid
    
    --20、优推指示
    #字段名:advantage_level
    #一级指示(近7天都被拖拽)-二级指示(近14天都被拖拽)-三级指示(近21天都被拖拽)-四级指示(近28天都被拖拽)-五级指示(近35天都被拖拽)
    select materialid,
    case when max(cnt)=7 then '一级指示'
         when max(cnt)=14 then '两级指示'
         when max(cnt)=21 then '三级指示'
         when max(cnt)=28 then '四级指示'
         when max(cnt)=35 then '五级指示'
         end as advantage_level
    from (
    select materialid,count(distinct substr(sendtime,1,10)) as cnt from 3D_point_kudu.materialDragInfo 
    where datediff(now(),sendtime )<=7 group by materialid having count(distinct substr(sendtime,1,10))=7
    union all
    select materialid,count( distinct substr(sendtime,1,10))as cnt from 3D_point_kudu.materialDragInfo 
    where datediff(now(),sendtime )<=14 group by materialid having count(distinct substr(sendtime,1,10))=14
    union all
    select materialid,count( distinct substr(sendtime,1,10))as cnt from 3D_point_kudu.materialDragInfo 
    where datediff(now(),sendtime )<=21 group by materialid having count(distinct substr(sendtime,1,10))=21
    union all
    select materialid,count( distinct substr(sendtime,1,10))as cnt from 3D_point_kudu.materialDragInfo 
    where datediff(now(),sendtime )<=28 group by materialid having count(distinct substr(sendtime,1,10))=28
    union all
    select materialid,count( distinct substr(sendtime,1,10))as cnt from 3D_point_kudu.materialDragInfo 
    where datediff(now(),sendtime )<=35 group by materialid having count(distinct substr(sendtime,1,10))=35
    )a
    group by materialid
    

    4、可视化产品

    经过上面的指标和标签逻辑梳理后,就是要可视化成数据产品了。在对于一个数据中台还很不完善的公司来说,要想让别人看到我们的价值,最好的方式就是拿出实际的产品出来,因此作为数据产品,我们需要想数据将构建的指标和标签通过业务方所需要的方式进行可视化,而且数据产品和传统的产品有很大的不同,在我认为哈,就是我们的数据产品面向的群里是很分散的,因此我看可视化的东西要很有共性并能够满足绝大部分的需求,而且数据产品最注重的就是逻辑性,这点也是我现在在不断学习的。这里涉及到相关隐私问题,就不把我们最后实现的产品放出来了哈。

    5、对外输出

    通过这段时间的工作,我深深感受到对外输出的重要性,需要准备好相对应的材料,而且一定要让别人看到你的专业性,因为其实公司很多人都不知道你的水平,你只有准备的足够充分,东西做的足够好,他们才会感受到你的专业性,才会认同你。像我们当初的上线会发很正式的邮件,画出对应的逻辑图,我觉得当初画的这个还挺好看的哈哈
    在这里插入图片描述
    最后,这篇文章是基于我毕业不到一年的认知所写的,有写得不对的地方欢迎和我交流。因为自己认识的做数据产品经理的朋友也比较少,不太清楚别人的数据产品经理是什么样子的。所以有想一起学习成长的朋友可以加个qq:624488342 ,一起交流沟通哈!

    展开全文
  • 软件产品线体系结构

    千次阅读 2017-11-01 13:43:08
    软件产品线在软件工程中地位 软件产品线的基本概念 将利用了产品间公共方面、预期考虑了可变性等设计的产品族称为产品线(Weiss和Lai)。 产品线就是由在系统的组成元素和功能方面具有共性和个性的相似的多个...

    软件产品线在软件工程中地位




    软件产品线的基本概念

    将利用了产品间公共方面、预期考虑了可变性等设计的产品族称为产品线(Weiss和Lai)。
    产品线就是由在系统的组成元素和功能方面具有共性和个性的相似的多个系统组成的一个系统族。
    软件产品线就是在一个公共的软件资源集合基础上建立起来的,共享同一个特性集合的系统集合(Bass,Clements和Kazman)。
    一个软件产品线由一个产品线体系结构、一个可重用构件集合和一个源自共享资源的产品集合组成,是组织一组相关软件产品开发的方式(Jan Bosch)。
    CMU/SEI:产品线是一个产品集合,这些产品共享一个公共的、可管理的特征集,这个特征集能满足选定的市场或任务领域的特定需求。这些系统遵循一个预描述的方式,在公共的核心资源基础上开发的。
    根据SEI的定义,软件产品线主要由两部分组成:核心资源、产品集合。核心资源是领域工程的所有结果的集合,是产品线中产品构造的基础。也有组织将核心资源库称为“平台”。
    核心资源必定包含产品线中所有产品共享的产品线体系结构,新设计开发的或者通过对现有系统的再工程得到的、需要在整个产品线中系统化重用的软件构件。




    软件产品线的过程模型 – 双生命周期模型





    软件产品线的过程模型 – SEI模型





    软件产品线的过程模型 – 三生命周期模型 





    软件产品线的组织结构 – 典型结构





    软件产品线的组织结构 – SEI产品线组织结构

      市场人员是产品线和产品能力、客户需求之间的沟通桥梁;
      核心资源组负责体系结构和其他核心资源的开发;
      应用组负责交付给客户的系统的开发;
      管理者负责开发过程的协调、商务计划等。
    设有独立核心资源小组的组织结构通常合适于至少由50到100人组成的较大型的软件开发组织,设立独立的核心资源小组可以使小组成员将精力和时间集中在核心资源的认真的设计和开发上,得到更通用的资源。
    不设立独立的核心资源小组,核心资源的开发融入各系统开发小组中,只是设立专人负责核心资源开发的管理。这种组织结构的重点不在核心资源的开发上,所以比较适合于组成产品线的产品共性相对较少,开发独立产品所需的工作量相对较大的情况。也是小型软件组织向软件产品线开发过渡时采用的一种方法。




    软件产品线的组织结构 – Jan Bosch产品线组织结构

    开发部门:所有的软件开发集中在一个部门,每个人都可承担领域工程和应用工程中适合的任务,简单、利于沟通,适用于不超过30人的组织。
    业务部门:每个部门负责产品线中一个和多个相似的系统,共性资源由需要使用它的一个和几个部门协作开发,整个团体都可享用。资源更容易共享,适用于30-100人的组织,主要缺点是业务部门更注重自己的产品而将产品线的整体利益放在第二位。
    领域工程部门:有一个专门的单位——领域工程部门负责核心资源库的开发和维护,其他业务单位使用这些核心资源来构建产品。这种结构可有效的降低通讯的复杂度、保持资源的通用性,适于超过100人的组织。缺点是难以管理领域工程部门和不同产品工程部门之间的需求冲突和因此导致的开发周期增长。
    层次领域工程部门:对于非常巨大和复杂的产品线可以设立多层(一般为两层)领域工程部门,不同层部门服务的范围不同。这种模型趋向臃肿,对新需求的响应慢。




    软件产品线的建立方式

    演化方式

    革命方式

    基于现有产品

    基于现有产品架构设计产品线的架构,经演化现有构件,开发产品线构件

    优点:风险最小,第一个产品面世时间早

    缺点:完成产品线核心资源的总周期和总投资较大

    核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集

    优点:开发一个不受现有产品集存在问题限制的、全新的平台,总周期和总投资较少

    缺点:风险大,第一个产品面世的时间会推后

    全新产品线

    产品线核心资源随产品新成员的需求而演化

    优点:先期投资少,风险小,第一个产品面世时间早,可以减少因经验不足造成的初始阶段错误的修正代价

    缺点:已有的产品线核心资源会影响新产品的需求协调,使成本加大

    开发满足所有预期产品线成员的需求的核心资源

    优点:一旦产品线核心资源完成,新产品的开发速度将非常快,总成本也将减少

    缺点:风险大;对新领域的需求很难做到全面和正确,使得核心资源不能像预期的那样支持新产品的开发




    软件产品线的演化

    从整体来看,软件产品线的发展过程有三个阶段,开发阶段、配置分发阶段和演化阶段。
    引起产品线体系体系结构演化的原因:产品线与技术变化的协调、现有问题的改正、新功能的增加、对现有功能的重组以允许更多的变化等等。
    产品线的演化包括产品线核心资源的演化、产品的演化和产品的版本升级。这样在整个产品线就出现了:核心资源的新旧版本、产品的新旧版本和新产品等。它们之间的协调是产品线演化研究的主要问题。




    框架和应用框架技术 – 一般框架的定义 

    Deutsch:多个抽象类和它们相关算法的集合可组成一个框架,该框架在特定应用中可以通过专用代码的添加来将具体子类组织在一起运作。框架由抽象类及其实现的操作和对具体子类的期望组成。
    Johnson和Foot:框架是封装了特定应用族抽象设计的抽象类的集合,框架又是一个模板,关键的方法和其他细节在框架实例中实现。
    Buschmann:框架是一个可实例化的、部分完成的软件系统或子系统,定义了一组系统或子系统的体系结构并提供了构造系统的基本构造模块,还定义了对特殊功能实现所需要的调整方式。在一个面向对象的环境中,框架由抽象类和具体类组成;框架的实例化包括现有类的实例化和衍生。
    Johnson:框架=模式+构件。框架是由开发人员定制的应用系统的骨架,是整个系统或子系统的可重用设计,由一组抽象构件和构件实例间的交互方式组成。




    框架和应用框架技术 – 应用框架的定义 

    Gamma:应用框架又称为通用应用,是为一个特定应用领域的软件系统提供可重用结构的一组相互协作的类的集合。
    Buschmann:特定领域应用的框架被称为应用框架。
    Froehlich:应用框架就是某个领域公共(generic)问题的骨架式解决方案。框架为该领域所有应用提供公共的体系结构和功能基础。
    Batory:应用框架技术是用于应用产品线的、通用的、面向对象的代码结构化技术。一个框架就是表达抽象设计的抽象类的集合;框架实例就是为可执行子系统提供的抽象类的子集的具体类的集合。框架是为了重用而设计的;抽象类封装了公共代码,具体类封装特定实例的代码。




    框架和应用框架技术 – 框架的特征 

    反向控制:类库是客户代码调用库中已存在类的方法。框架内嵌了控制流,框架调用客户代码——加入框架的新构件和抽象类的方法实例。
    可重用性:框架提供了设计和代码的重用能力。
    扩展性:为规划的变化提供了“热点”(hotspot)或“钩子”(hook)等显式说明方式。
    模块化或构件化:框架有固定的、稳定的接口和封装的热点。




    框架和应用框架技术 – 框架的建立方式 

    一般框架有三种建立方式:自顶向下,自底向上和混合方式。
    因为应用框架和软件产品线之间的密切关系,前两种框架建立方式与建立全新的软件产品线时的革命方式和演化方式十分类似,也具有相同的过程和优缺点。
    混合方式指在大型应用框架的建立过程中,先将应用领域划分为不同的子区域,再分别解决,最终集成为一个完整框架的做法。




    框架和应用框架技术 – 框架的分类 

    黑盒框架通过构件/类的组合来支持重用和扩展。应用中的类由框架的不同构件组合而成。在框架所在领域中,每个构件都有一个预定义的标准接口,一组共享相同接口但能满足不同应用需求的构件组成一个“插接兼容”的构件集合。
    白盒框架一般使用类的继承机制实现,由未完成的类(抽象类)组成,类有一个或多个抽象接口或虚方法。应用需要在抽象类的继承子类中提供特定意义的方法实例来重用框架。开发者通过虚方法的实例化将特定应用的代码联入框架来生成应用。
    灰色框架可以分成三部分:固定的、可选择的和开放的。框架的固定部分包含了该领域最基本的功能、内建了应用的控制流,由框架主干实现,对应着领域共用部分。框架的可选择部分为该领域中相对固定的、应用特定的功能特征即领域个性部分,用可组合的类或构件实现,在应用构造时在这些构件或类中进行选择、组合。对一些无法准确估计和预测的功能特征即框架的开放部分,只能为其规定统一的接口和与框架的挂接点,用可继承的抽象类的方式来实现,这些部分可以根据应用的具体需求变化进行单独的调整。




    软件产品线体系结构的设计 – 概述

    软件产品线体系结构指一个软件开发组织为一组相关应用或产品建立的公共体系结构。 
    同领域模型一样,软件产品线体系结构中也可以分为共性部分和个性部分。 
    产品线体系结构是产品线核心资源的早期和主要部分,在产品线的生命周期中,产品线体系结构应该保持相对小和缓慢的变化以便在生命周期中尽量保持一致。产品线体系结构要明确定义核心资源库中软件构件集合及其相关文档。 




    软件产品线的演化 – 概述




    软件产品线的演化 – 需求和演化的分类 – 需求分类




    软件产品线的演化 – 需求和演化的分类 – 体系结构演化的分类




    软件产品线的演化 – 需求和演化的分类 – 构件演化的分类




    软件产品线的演化 – 需求和演化的分类 – 各种演化之间的关系



    展开全文
  • 产品设计-电商中商品体系

    万次阅读 2017-01-04 16:17:37
    您也许是购物达人、您也许是资深码农、或者您也是产品精英,可是什么是商品,您真的懂么? 从宏观上讲,2016年的中国,是实体经济和制造业萎缩的一年。互联网充斥着别让曹德旺跑了的惊悚言论。但不论跑与不跑,...

    您也许是购物达人、您也许是资深码农、或者您也是产品精英,可是什么是商品,您真的懂么?
    从宏观上讲,2016年的中国,是实体经济和制造业萎缩的一年。互联网充斥着别让曹德旺跑了的惊悚言论。但不论跑与不跑,税负在那里,只增不减。走与不走、商业模式在这里,只多不少。
    头疼于产品妹子对于设计和分析的浅见,胡乱写下本文,勿喷。

    有人说是电商逼死了实体经济。其实电商只是多了一种售卖途径。2014年 020的那片饕餮盛宴之后,留给 2016年寒冬的,除了雾霾.还是走不出去的彷徨。 依稀见得17年的宠儿,共享经济的来临。
    经济学上的破事儿牵动不了码农的神经,追本溯源回眸看看,目前的APP分类,从产品架构来说,我认为只有两套体系,一是社交、二是电商。
    不论B2B/C2C/O2O/P2P各类炫酷的名词多么扯人眼球。落在纸上,总是售卖商品的一套体系。从古至今,社会的基础建设就在于流通,流通的载体就是商品。从古时学得文武艺、卖与帝王家 到今日的共享服务、共享经济。 都可归纳于电商体系。在电商系统中,商品模型至关重要,是整个电商的核心,本文的重点,就落在商品。
    首先商品是什么? 政治课有讲商品是用于交换的劳动的产品。那么在电商体系中,只要用于售卖不止是物品,还有服务,都可以看做一个商品。
    其次商品由哪些部分组成?这点对于我们产品设计和数据结构设计很重要。 以淘宝为例。请看下图
    这里写图片描述
    上图是一款运动鞋的商品详情。在以上术语中,对于单品与商品的关系,规格与单品的关系做了详细描述。综上所述,一件商品的基本构成如下:

    1. 品类(类型) 商品分类,一种抽象概念,如登山鞋、手机。
    2. 商品 在电商中上架销售的产品,如可口可乐,我们可以称为一种商品.
    3. 单品 特指出售给客户的实际产品,比如,超市货架上摆放的355毫升的可口可乐(易拉罐)是一种单品,2.5升的大瓶的可口可乐是另一种单品。换句话说,一种商品由多种单品组成,每种单品,其库存量和单价一般不同。
    4. 规格 规格是用来区分单品的主要指标。如鞋类商品,由颜色、尺码两种规格区分单品。
      如可口可乐,以容积来区分单品。规格选项,即某种规格的具体选项,如可口可乐的容积有355毫升,600毫升,2.5升。 如Nike的男子运动鞋 819803, 颜色有炭黑、星蓝、夜红.
    5. 属性/参数 商品的产品参数/属性,以运动鞋为例. 鞋帮高低、功能、闭合方式、材质等都可能是其产品参数
    6. SPU 可理解为商品编码,对应一个商品
    7. SKU 可理解为单品编码,对应一个单品

    这里写图片描述

    弄清楚商品的产品设计结构后,我们参考有赞,设计一个极简的商品上架.
    商铺需要提供商品,首先有管理、上架商品的入口。我们需要在管理后台提供商品管理模块,供协会管理、上架商品使用。
    在淘宝、京东或各类微商都有类似的模块,但目标对象、平台规模、使用场景不同,复杂度和功能点也有繁简之分。我们平台的特点是社交活动为主、电商为辅,商品种类不多、售卖量不大,因此应走简单路线。 这里选择有赞作为参考平台,以此为模板实现商品上架的功能.请注册有赞,并发布数个商品,体会其流程。
    有赞:https://login.youzan.com/sso/index?service=kdt#id=319340757
    新增商品,应首先选择商品类型,之后录入商品基本信息,设置商品规格,再填写各单品信息、库存、单价。最后完成商品上架。
    在商品上架后,依然可以修改、删除商品信息,均不作限制。
    商品类型
    品类目前分为三类:服装、装备、鞋.
    由运营管理员维护在数据字典中,无需专门的品类维护模块,商铺不能自定义品类. * 想想为什么商铺不允许自定义品类。
    商品规格
    商品规格的设置请参考有赞,因前期只上架会服、少量户外装备,因此注意以下限制:
    这里写图片描述
    1.规格种类:包含颜色、尺寸、尺码、款式、型号 五类. 维护在数据字典中.
    2.规格选项:由用户自定义,最多录入60个汉字.
    3.规格限制:默认可*不选择规格. 用户可添加至最多3种规格.
    4.规格图片:V1.0不考虑
    允许上传规格图片,目前只支持为第一个规格设置不同的规格图片,设置后,用户选择不同规格会显示不同图片
    Note:
    1.*不选择规格代表该商品只有一种单品,无需选择。这种场景从结构上来讲,依然是商品和单品是一对一的关系. 换句话说,单品表中必须有一条数据,其规格设置为默认.库存为总库存.
    2.关于元素的最小、最大长度,有效性判断请参见有赞,不做特殊说明,但务必符合实际业务场景。
    单品单价/库存设置
    单品数量依赖于商品规格,每种单品的单价/库存通常不同.允许批量设置单品价格和库存,单品的最低价格就是商品的展示价格。例如下图所示就有4种单品。
    这里写图片描述
    图例供参考,仅包含以下元素:
    元素 必填 有效性 说明
    单品所属规格选项 显示 依据商品规格自动生成
    价格 是 默认0,最大为10万 *单品的最低价格=商品展示价格
    库存 是 默认0,最大为10万 总库存为各单品库存累计. 当库存为0时,代表单品缺货
    销量 显示 默认0 销量为实际单品销售数量,新增时默认为0.

    商品信息
    商品信息包含商品名、价格、总库存、商品展示图、商品简介、详情这六个元素.
    这里写图片描述

    售卖规则
    电商的售卖规则包括售卖形式(如定价、拍卖、众筹、一元拍)、是否折扣、是否允许使用卡券、积分抵扣、售卖对象等.

    以上就是极简的商品分析及商品管理设计。尚未涉及上下架、订单、多价格、售卖规则。以管窥豹,其实一个简单的商品,并不是想象的那么简单。产品之路,也非看起来那么简单。

    详细结构可参考另一篇好文
    http://www.cnblogs.com/leefreeman/p/4060227.html
    Note:该文的货品理解我有保留意见,对于单品的解析并不严格。

    展开全文
  •  产品经理 8k-10k /深圳 / 经验3-5年 / 本科及以上 / 全职 职位诱惑:项目前景好,弹性上班,公司氛围好,扁平制度职位描述:岗位职责:1. 在整个产品周期里,负责产品的规划、设计、落地;2. 负...
  • Atitit 几大研发体系对比 Stage-Gate体系 PACE与IPD体系 敏捷开发体系 CMMI体系 艾龙 著 1. 3. 1.5:业界领先的研发管理体系简介 2 12. 《产品及生命周期优化法》(简称PACE——Product And Cycle-time ...
  • 发展到现在,做了几个产品的数据工作,对指标体系概念以及规划方法有一定的积累,总结出来作为知识储备。 What is指标体系 百度百科的专业定义“评价指标体系是指由表征评价对象各方面特性及其相互联系的多个指标,...
  • 数据产品-指标体系与数据采集

    千次阅读 2020-06-12 11:05:48
    本文章是通过学习GrowingIO所发布的《指标体系与数据采集》方案的一些知识总结,具体方案的详情可以去GrowingIO官网上查看 一、科学规划指标体系 1、指标规划阶段常见问题 数据指标体系建立的第一步,就是要做好数据...
  • 作者:Zevol全文共 2716 字,阅读需要 7 分钟———— / BEGIN / ————相比把用户成长体系玩得贼的C端产品,B端产品在用户成长体系上却一片空白。今天我们一起聊一聊:在B端产品中,应不应该建立用户成长体系,...
  • 产品开发管理之流程和体系(总篇) 产品开发管理之流程和体系(总篇) 前言 秋风瑟瑟,夏日的灼热犹在,就瞬间迎来刺骨寒风。凛冬将至,今天对我们来说,像贴面的利刃一样冰冷而真实。农民、建筑...
  • 本文关注IPD体系中的研发执行团队,包括产品开发团队(PDT)、技术开发团队(TDT)、产品预研团队(PRT)和技术预研团队(TRT),定义了这四种团队的职责、团队组成和运作规则,以及这四个团队之间的相互关系。...
  • 使用Atlassian的产品已经有三年多,但是大部分主要以JIRA和Confluence为主,今年年初加入一创业团队负责技术团队的搭建,从零开始通过部署Atlassian产品、制定开发流程,由于创业团队人手不够,自身也参与了大部分的...
  • Confluence的使用几乎贯穿了整个敏捷过程,如:在产品设计时编写产品需求,在会议讨论时编写会议笔记,在冲刺结束后编写冲刺回顾……Confluence自身也为这些需求提供了丰富的文档模板,本文就其提供的模板结合我们的...
  • 软件体系结构设计|描述与架构风格

    千次阅读 2017-05-15 16:16:52
    架构描述 AD 架构风格计算机硬件系统中包含的两个重要因素: 基本硬件模块:控制器、运算器、内存储器、外存储器、输入设备…… 硬件模块之间的连接关系:总线(控制总线、地址总线、数据总线) 计算机系统体系结构...
  • 软件体系结构 张友生

    热门讨论 2009-05-14 00:53:06
    软件体系结构 张友生 希赛IT教育研发中心 课 程 内 容 ◇ 软件体系结构概论 ◇ 软件体系结构建模 ◇ 软件体系结构风格 ◇ 软件体系结构描述 ◇ 动态软件体系结构 ◇ We b 服务体系结构 ...◇ 软件产品线体系结构
  • 2. 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义了一个系统家族,即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将...
  • IEEE P1471的软件系统体系结构描述

    千次阅读 2008-08-07 20:37:00
    IEEE P 1471是体系结构推荐实践草案(Draft Recommended Practice for ArchitecturalDescription ),由IEEE体系结构工作组(IEEEsArchitecture Working Group)开发并得到了IEEE计算机学会软件工程标准委员会的许可与...
  • 软件体系结构

    千次阅读 2014-10-30 20:28:50
    体系结构的非形式化描述 通常使用自然语言描述概念和原则该阶段是创造性和开拓性需要与软件用户进行不断地交互 体系结构的规范描述和分析 运用合适的形式化理论对上一阶段的非形式化描述进行规范定义要求做到...
  • 软件体系结构基础

    千次阅读 2020-12-27 12:57:33
    软件体系结构基础,对软件体系结构做简要总结,通用模型可以应用于许多不同类型的系统。此部分选择有代表性的结构进行总结。体系结构的模式选择设计模式做阐述,风格选择典型的三种体系结构风格做阐述,框架选择MVC...
  • 受众定向标签体系

    2018-12-08 09:20:22
    如何规划合理的标签体系对广告产品的运营影响非常大,因此,这是产品策略中特别关键的一环。一般来说,这样的标签体系有两种组织方式:一种是按照某个分类法(taxonomy)制定一个层次标签体系,其中上层的标签是下一...
  • CMM体系

    千次阅读 2011-07-25 01:21:08
    第一级实际上是一个起点,任何准备按CMM体系进化的企业都自然处于这个起点上,并通过这个起点向第二级迈进。除第一级外,每一级都设定了一组目标,如果达到了这组目标,则表明达到了这个成熟级别,可以向下
  • web 体系结构_Web服务体系结构概述

    千次阅读 2020-06-22 19:46:25
    Web服务体系结构描述了三个角色:服务提供者,服务请求者和服务代理。 和三个基本操作:发布,查找和绑定。 网络组件可以扮演任何或所有这些角色。 两个单独的文档描述了Web服务:定义良好的服务(WDS)文档描述...
  • i386体系结构

    千次阅读 2012-05-15 20:54:20
     Intel公司的80386是一个里程碑式的产品,之后的486、Pentium、Pentium II虽然在性能上有不小的改进,但都属于同一种体系结构,统称为i386结构。  为了与以往产品兼容,80386选择了在段寄存器的基础之上构建保护...
  • 指标体系建设

    2020-09-03 18:06:00
    1.背景 结合业务场景将多个不同指标和维度进行组合,从而针对某一真实业务场景进行数据分析和决策导向,并能在整体业务变化中发现和定位问题。... 文字类描述 城市,性别,职业 定量维度 数值类...
  • 软件体系结构期末复习总结

    千次阅读 多人点赞 2020-08-18 21:14:41
    软件体系结构是具有一定形式的结构化元素,抽象的讲,软件体系结构包括构成系统的设计元素的描述,设计元素的交互,设计元素组合的模式,以及在这些模式中的约束。具体的讲,体系结构 = 组件+连接件+约束 组件:...
  • 计算机体系结构

    万次阅读 2017-12-14 15:00:26
    详解计算机体系结构  计算机体系结构是指那些对程序员可见的系统属性,还包括设计思想与体系结构。今天课课就来和大家分享这篇文章,全面概述了计算机体系结构。要认真阅读~  计算机体系...
  • 软件体系结构风格介绍

    千次阅读 2020-02-18 12:46:38
    文章目录软件体系结构...软件结构风格的定义:软件结构风格是描述某一特定应用领域中系统组织方式的惯用模式(idiomatic paradigm)。体系结构风格定义了一个系统家族,即一个体系结构定义一个词汇表和一组约束。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 107,918
精华内容 43,167
关键字:

产品体系怎么描述