zoukankan      html  css  js  c++  java
  • UX结合需求实例化进行设计开发

    技  术  文  件

                技术文件名称:实例化+UX需求分析实践:场景监控需求实例化

                技术文件编号:

                版        本:V1.0

               

    共 32 页

    (包括封面)

                                 拟  制    廖开蒙、刀锋团队          

                                 审  核                     

                                 会  签                     

                                                            

                                                            

                                                            

                                 标准化                     

                                 批  准                     

    产品市场体系无线研究院

    修改记录

    文件编号

    版本号

    拟制人/

    修改人

    拟制/修改日期

    更改理由

    主要更改内容

    (写要点即可)

    V1.0

    廖开蒙

    2016-04-01

    新建

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    注1:每次更改归档文件(指归档到事业部或公司档案室的文件)时,需填写此表。

    注2:文件第一次归档时,“更改理由”、“主要更改内容”栏写“无”。

     


     

    (包括封面) 1

    1.      引言... 7

    1.1             编写目的... 7

    1.2             预期的读者和阅读建议... 7

    1.3             文档约定... 7

    2       用户需求分析... 8

    2.1             原始需求描述... 8

    2.2             需求背景... 8

    2.2.1         客户问题... 8

    2.2.2         客户收益... 8

    2.2.3         客户规划... 8

    2.3             系统组网... 9

    2.4             用户需求实例化... 9

    2.4.1         定系统... 9

    2.4.2         找用户... 10

    2.4.3         问目的——监控人员... 11

    2.4.3.1               用户画像... 11

    2.4.3.2               体验地图... 11

    2.4.4         问目的——运维人员... 12

    2.4.4.1               用户画像... 12

    2.4.4.2               体验地图... 12

    2.4.5         用户目的... 13

    2.4.6         需求场景实例... 15

    2.4.6.1               场景一:维护场景指标... 15

    2.4.6.2               场景二:维护场景... 16

    2.4.6.3               场景三:维护场景监控... 18

    2.4.6.4               场景四:实时监控场景网络... 21

    2.4.6.5               场景五:实时监控控制... 22

    2.4.6.6               场景六:切换实时监控数据... 23

    2.4.6.7               场景七:切换数据视图... 24

    2.4.6.8               场景八:场景指标数据分析... 26

    2.4.6.9               场景九:场景监控报告... 27

    2.4.7         设功能... 27

    2.4.8         功能交互分析... 28

    2.4.8.1               本次功能之间的交互分析... 28

    2.4.8.2               与以往功能之间的交互分析... 28

    2.4.9         质量属性分析... 28

    3       解决方案分析... 29

    3.1             方案考虑... 29

    3.2             风险考虑... 30

    3.3             界面原型... 30

    4       外部接口说明... 31

    5       关联需求汇总... 31

    6       会议讨论记录... 31

     

    1.     引言

    1.1    编写目的

    1.2    预期的读者和阅读建议

    预期的读者和阅读建议参见表1.1。

    表1.1

    读者分类

    阅读重点

    备注

    总工、产品研发经理、项目经理

    全文,并据此编制/修订项目(软件)开发计划等。

    产品需求与方案设计工程师

    需求分析的完整性、无二义性,为产品需求和方案设计作准备。

    产品管理部方案人员

    需求的必要性、优先级,从用户的角度看分析的正确和完整性。

    1.3    文档约定

    本文使用了如下的文档约定:

    1)  表头文字使用了20%灰度背景;

    2)  插图一律使用MS Visio 中文版绘制,并一律“嵌入”于需求描述正文中,而非“浮于文字上方”。;

    3)  用同号、同体但加粗的文字来强调需要读者重视的内容。

    4)  本文档<>中内容均为注释,正式文档中需要删除。

    5)  关于文档中的编号缩写,A表示Actor用户;T表示目的Target;S表示Senario场景;US表示User Story用户故事;E表示Epic史诗故事。

    6)  文档中故事和史诗的优先级,仅分了1-10,其中10为最高优先级,1为最低优先级。对应到项目的实际优先级请参考1-10分布情况。或直接在此文中使用真实优先级表达方式。

    2         用户需求分析

    2.1    原始需求描述

    系统提供自定义场景监控功能,根据基站分布特点将其划归某一场景,实现该场景实时监控功能。

    用户需要对热点区域进行重点监控,可以实时了解全网某个关注场景无线网络的状况。场景可能是高速沿线、地铁沿线、校园、机场、会场等等,场景涉及的网元可能是一个区域的,也可能是不同区域的,可能分属不同EMS管理。

    2.2   需求背景

    2.2.1    客户问题

    现有的EMS和区域监控系统功能无法满足场景监控的需求。

    实时告警监控、历史性能数据实时查询不是基于全网的监控,只能监控本EMS管理的网元;告警、性能数据查询位于不同界面,无法做到一个页面同时展示所有监控指标,易用性不高,界面展示效果不好。

    现有监控系统的区域监控是对区域内所有网元进行监控,无法对归属一个区域部分网元或归属不同区域的网元构成的场景进行重点监控;所有区域的监控指标都相同,无法定制各个区域监控指标;所有区域的性能监控指标粒度都是固定的,如果想对某个网元进行更高实时性的监控,无法满足。区域监控对客户的各种个性化需求无法满足。

    2.2.2    客户收益

    期望提供灵活的、重点突出、实时的、简单易用的场景监控功能,能够:

    1. 用户根据需要选择基站创建自定义监控场景,譬如“机场”“地铁”“校园”等场景,其中场景中包含地站点数不要求限制。
    2. 支持场景管理,用户能够新增修改和删除场景,自定义场景数目要求不小于50个。
    3. 可以对各个场景自定义指标。用户主要关注点为基站是否中断、小区是否异常、话务和流量指标是否恶化。
    4. 场景监控任务要求可控制,用户可以启动、暂停和停止场景监控。
    5. 场景监控时采用丰富图表方式呈现基站指标数据,要求监控数据实时刷新。
    6. 场景监控要求支持趋势分析功能,提供今天VS昨天VS一周前VS二周前对比。

    7、 异常指标采用颜色渲染,重点突出在页面上,便于用户查看基站异常信息。

    通过上述功能,提供便捷的监控功能,提升运维体验,并且在故障定位时,能够提升故障定位的效率。

    2.2.3    客户规划

    规划在2016年年中提供商用。

    2.3   系统组网

    本需求涉及的组网情况如下图所示:

     

    图1 系统组网图

    2.4   用户需求实例化

    需求分析过程中将实例化和UX结合起来。从头至尾贯穿了UX设计方法,体现出UX在需求分析中感知用户、提升体验的重大作用。本次需求分析中UX主要体现在如下几方面:

    1、通过使用[用户画像]+ [体验地图]找出用户工作场景的兴奋点、痛点,完成用户目的输出。

    2、进行场景的挖掘分析,通过场景实例化,完成用例、页面元素、交互、线框图的输出整理。

    3、根据页面元素、线框图及交互画出原型图,完成功能设定。

    2.4.1    定系统

    场景监控需求要考虑的典型组网图见3.3章节。此处增加外部操作用户。

    此需求需要从EMS采集告警性能资源数据,故EMS需要参与分析。RNC/BSC/ENODEB等网元只是提供告警/性能数据,不参与到场景监控的交互中,故不参与分析。确定的系统为红线内的范围。

    如下图所示:

     

    图2 带外部用户的系统架构图

    2.4.2    找用户

    以图2红色圈内的部分作为SYS,场景监控的时序图如下图所示:

     

    图3 场景监控时序图

    初选用户:

    l  根据流程法,初选直接Actor有监控人员、运维人员、网元(此处将RNC/BSC/eNodeB/CN合一考虑)。

    l  结合干系人法,主要考虑设备商售后、代维人员两个初选用户。

    对初选用户进一步分析,最终用户可归为监控人员与运维人员,用户表如下所示:

    表3.2用户表

    Actor

    用户编号

    是否用户

    用户类别

    说明

    监控人员

    A1

    直接使用者

    此需求主要满足监控人员对场景进行监控的日常要求。

    运维人员

    A2

    直接使用者

    此需求满足运维人员分析场景数据的要求

    网元

    A3

     

    此需求不需要网元参与交互,不是本需求的用户

    设备商售后

    A4

    直接使用者

    当网络状况出现问题,此需求满足设备商售后查看场景数据的要求,设备商售后角色与运维人员一致。

    代维人员

    A5

    直接使用者

    当网络状况出现问题,此需求满足代维人员查看场景数据的要求,代维人员角色与运维人员一致。

            

    2.4.3    问目的——监控人员

    基于找到的最终用户,针对场景监控需求,进行用户画像分析及工作场景体验地图,找出用户目的。

    2.4.3.1  用户画像

    监控人员定位为女性,因为通过几次在局方沟通需求过程中发现,陕西联通、深圳联通运维部网管中心的监控大厅从主管到职员,女性占了很大比例。其用户画像如下所示:

    表3.3监控人员用户画像

     

    性别

    女性

    年龄

    25岁左右

    学历

    本科

    身份

    运营商职员

    工作经验:工作经验4~5年左右,监控岗位从事两年以上

    性格特点:细心,怕繁琐,喜欢简洁、美观的事物

    工作场景

    定制监控内容,查看监控指标数据,及时发现问题

    频度

    实时,非常频繁

    2.4.3.2  体验地图

    依据需求及用户画像分析对监控人员进行体验地图分析,挖掘用户体验的低点、高点中存在的痛点、机会,据此找出用户目的。

    表3.4监控人员体验地图

    事务

    定制监控内容

    监控指标数据

    1、选择监控所需指标

    2、选择监控网元

    1、启动监控

    2、查看监控指标数据

    3、及时发现超限指标

    感受

    定制监控内容是工作的开端,需要一系列步骤才能开始监控,这时用户的情绪是较低落的

    监控指标数据是监控员的主要工作,可以正式开始工作,这时用户处于情绪良好的阶段

     

    痛点

    1、  指标太多,指标选择麻烦

    2、  网元数量规模庞大,网元选择麻烦

    3、  需要监控的场景很多

    4、  每种场景在不同时间、不同场合监控的指标会发生变化,监控内容不固定

    1、  监控指标数据展示不直观,无法一目了然

    2、  场景中某个网元指标恶化无法及时发现

    3、  操作麻烦,需要不时切换页面

    4、  查看其他实时监控任务麻烦

    5、  监控过程不可控

    机会

    1、  建立场景指标集

    2、  提供多种过滤方式,便于筛选网元

    3、  提供场景管理功能

    4、  提供监控任务管理功能

    1、  可以一目了然的查看指标数据

    2、  突出指标恶化的网元,及时发现问题

    3、  监控页面提供数据切换,以减少操作和页面切换

    4、  提供监控任务切换

    5、  可以控制监控过程

    2.4.4    问目的——运维人员

    2.4.4.1  用户画像

    运维人员定位为男性,处理故障需要下现场的人员譬如局方、设备商、代维公司 基本上都是男性。

    表3.5运维人员用户画像

     

    性别

    男性

    年龄

    30岁左右

    学历

    本科

    身份

    运营商职员

    工作经验:工作经验5~8年左右,运维岗位从事三年以上

    性格特点:严谨,喜欢追根究底

    工作场景

    查看指标数据,了解故障详细信息,定位分析问题,输出报告

    频度

    出现问题时需要使用监控系统排查问题

    2.4.4.2  体验地图

    作为运维人员,由于其工作职责与监控人员的差异,其对需求的痛点及感受会存在不同。

    表3.6运维人员体验地图

    事务

    观测监控指标

    分析定位问题

    输出报告

    1、选择场景监控任务

    2、观察监控指标数据

    1、选择告警/性能指标

    2、分析指标数据信息/趋势变化

    3、定位故障

    1、生成表格图片

    2、输出数据分析结果

    感受

    开始工作,心情平静

    存在比较严重的问题,不知道问题出在哪里,比较迷茫,情绪不高

    任务完成,心情愉悦

     

    痛点

    1、场景太多,监控任务太多,定位场景监控比较麻烦

    1、无法从图表看到具体详细数据,数据不够丰富,导致无法定位问题

    1、报告不符合要求

    2、报告不是自己想要的

    机会

    快速定位到关心的监控场景(区别于监控人员监控目的,满足快速定位排查问题目的)

    1、查看图表具体详细数据

    2、查看指标对象数据

    3、提供趋势对比分析等分析手段

    1、  提供图文并茂 、结论突出 、结构清晰的报告

    2.4.5    用户目的

    基于找到的最终用户,通过用户画像、体验地图分析,并进一步深入挖掘,汇总后情况如下:

     

    表3.7 监控人员用户目的

    用户

    目的编号

    深度挖掘

    广度挖掘

    WANT

    NEED

    WIN

    监控人员

    A1T1

    可以一目了然的查看指标数据

    提供良好的指标数据可视化展示界面,方便了解场景网络的概况(趋利)

    业务目的

    A1T2

    重点突出指标恶化的网元

    避免在场景指标没有超限情况下,网元指标恶化没有及时发现(避害)

    将指标恶化站点在监控页面自动标示出来,以告警声音警示用户(避害)

    A1T3

    监控页面提供数据过切换,以减少操作和页面切换

    提供根据制式、时间等条件进行监控数据过滤和对比分析,便于一页展示,避免繁琐操作和页面切换(避害)

    A1T4

    监控任务切换

    便于快捷查看其他监控任务数据(趋利)

    记录最近浏览任务,方便切换到最近浏览任务(趋利)

    A1T5

    提供多种过滤方式,便于筛选网元

    避免无法及时查找到网元,更快捷(避害)

    已经选择的网元不出现在待选择列表中(避害)

    管理目的

    A1T6

    建立场景指标集

    避免直接从大范围指标内选择,更方便(避害)

    提供默认的场景指标集(避害)

    A1T7

    管理场景

    可以快速定位场景,方便场景增删改查,提高效率(趋利)

    批量创建、修改场景(趋利)

    A1T8

    管理场景监控任务

    每个场景可以对应多个监控任务,可以灵活定制每个监控任务的监控指标,满足不同场合的需求(趋利)

    创建监控任务时任务名默认显示场景名,勾选默认的监控指标(趋利)

    A1T9

    可以控制监控过程

    根据需求,控制监控的过程,增加监控的灵活性(趋利)

    维护目的

    表3.8 运维人员用户目的

    用户

    目的编号

    深度挖掘

    广度挖掘

    WANT

    NEED

    WIN

    运维人员

    A2T1

    快速定位到关心的场景监控

    便于快速定位场景,加快问题排查(趋利)

    业务目的

    A2T2

    查看图表具体详细数据

    查看场景指标具体信息,便于分析(趋利)

    A2T3

    查看性能指标对象数据

    用于分析的数据越细,越有助于定位问题(趋利)

    A2T4

    提供趋势对比分析等分析手段

    趋势对比分析手段有助于分析定位问题(趋利)

    A2T5

    提供图文并茂 、结论突出 、结构清晰的报告

    便于汇报总结(趋利)

    管理目的

    维护目的

    2.4.6    需求场景实例

    2.4.6.1  场景一:维护场景指标

    此场景对应的用户和其目的详情:

    表3.9

    用户

    目的编号

    深度挖掘

    WANT

    NEED

    WIN

    监控人员

    A1T6

    建立场景指标集

    避免直接从大范围指标内选择,更方便(避害)

    提供默认的场景指标集(避害)

          

           场景监控主要监测场景的重点指标,同时区域监控的指标数最多为10个,考虑场景监控的指标数不大于区域监控指标数,经过与规划沟通定为9个。

    这个场景考虑用流程图方式建模。

    Step1:流程图建模

     

    图4 场景一建模

    Step2:给测试条件填充数据输出AC

    根据模型,需要填充的数据包括:已有场景指标数、操作、操作结果。

    表3.10

    编号

    GIVEN

    WHEN

    THEN

    已有场景指标数

    操作

    任务状态

    S1-010

    0

    增加1个指标

    无关

    列表呈现1个指标

    S1-020

    0

    删除指标

    无关

    删除操作无效

    S1-030

    9

    增加1个指标

    无关

    增加操作无效

    S1-040

    9

    删除一个指标

    该指标没有存在于运行、暂停状态的监控任务

    列表呈现8个指标

    S1-050

    9

    删除一个指标

    该指标存在于运行、暂停状态的监控任务

    删除失败

    S1-060

    5

    查询显示

    列表呈现5个指标

    Step4:补充模型之外的用例

    无。

    2.4.6.2  场景二:维护场景

    此场景对应的用户目的详情:

    表3.11

    用户

    目的编号

    深度挖掘

    WANT

    NEED

    WIN

    监控人员

    A1T7

    管理场景

    可以快速定位场景,方便场景增删改查(趋利)

    批量创建、修改场景

    A1T5

    提供多种过滤方式,便于筛选网元

    避免无法及时查找到网元,更快捷(避害)

    已经选择的网元不出现在待选择列表中

     

    通过讨论和挖掘确定如下:

    1、场景的主要属性包括场景名称、网元列表(网元个数不受限制),场景不包含指标(在监控任务阶段设置指标)。场景名称需要限定长度(64位,避免在页面显示超长)、非法字符范围(除字母、数字、下划线、减号、左右括号以外的字符)。场景数量不受限制。

    2、涉及场景的主要操作:过滤查询场景、创建场景、修改场景、删除场景、过滤选择网元、添加网元、删除网元。

    3、为了快速定位场景,支持在场景名称、网元标示中匹配搜索字符。

    4、为了避免操作失误,应该只允许单个场景的删除操作。

    5、通过导入方式批量创建、修改,必然需要导出场景信息.

    6、为了快速添加网元,避免返工,已经添加的网元不出现在待选择网元列表。

    7、为了快速过滤查询网元,支持按归属EMS、及网元属性(名称、制式、归属RNC、区域)过滤查找。通过选择EMS过滤出该EMS下的网元,并可以通过网元属性匹配搜索字符进行二次过滤。

    Step1:流程图建模

     

    图5 创建场景建模

           上图是创建场景的流程图,修改场景的流程与创建场景类似,不在列出。      

    过滤选择网元需要根据网元属性进行过滤查找,只与执行的输入有关,直接实例化输入输出。

    Step2:给测试条件填充数据输出AC

    创建、修改场景的输入是操作类型、场景数量、场景名称、网元,输出是创建结果

    表3.12创建/修改场景

    编号

    WHEN

    THEN

    操作

    场景个数

    场景名称

    网元个数

    S2-010

    创建

    1

    咸阳机场

    0

    失败

    S2-020

    创建

    1

    咸阳机场

    >0

    成功

    S2-030

    创建

    1

    咸阳机场

    >0

    失败

    S2-040

    修改

    1

    咸阳机场+57个1

    >0

    失败

    S2-050

    修改

    1

    咸阳机场!@#

    >0

    失败

    S2-060

    导入批量创建

    10

    一个场景的场景名称包含异常字符;

    一个场景的场景名称超长

    一个场景没有设定网元,其他场景设定10个网元

    7个场景创建成功,3个场景创建失败

    S2-070

    导入批量修改

    7

    1个场景没有设定网元,6个场景设定网元5个

    1个场景修改失败,6个场景修改成功

     

    表3.13 网元过滤

    编号

    GIVEN

    WHEN

    THEN

    网元个数

    归属EMS

    搜索字符

    S2-80

    EMS1下网元个数0

    选择EMS1

    显示0个网元

    S2-90

    EMS1下网元个数10个,属性中包含字符”UM”的网元2个

    选择EMS1

    UM

    显示2个网元

    S2-100

    全网下网元个数100个,属性中包含字符” 延安”的网元0个

    选择全网

    延安

    显示0个网元

     

    Step3:补充模型之外的用例

    场景过滤查询、场景删除、导入、导出,只与执行的预置条件及输入有关,直接实例化输入输出。

    表3.14场景查询过滤

    编号

    GIVEN

    WHEN

    THEN

    场景个数

    搜索字符

    S2-110

    0

    非空

    显示场景数为0

    S2-120

    5

    显示场景数为5

    S2-130

    10

    一个场景的场景名称包含搜索字符

    显示场景数为1

    S2-140

    10

    2个场景的网元标示包含搜索字符

    显示场景数为2

     

    表3.15场景导出

    编号

    GIVEN

    WHEN

    THEN

    查询过滤场景个数

    操作

    S2-150

    0

    导出

    导出场景数为0

    S2-160

    5

    导出

    显示场景数为5

     

    表3.16场景删除

    编号

    GIVEN

    WHEN

    THEN

    场景个数

    客户端个数

    操作

    监控任务状态

    S2-170

    0

    1

    删除

    无关

    没有可删除的记录

    S2-180

    5

    1

    删除一个场景

    监控任务都停止

    删除成功,列表显示4个场景

    S2-190

    5

    2

    删除一个被其他客户端已经删除的场景

    无关

    删除失败,列表显示4个场景

    S2-200

    5

    1

    删除一个场景

    有一个运行状态监控任务

    删除失败,列表显示5个场景

    S2-210

    5

    1

    删除一个场景

    有一个暂停状态监控任务

    删除失败,列表显示5个场景

    2.4.6.3  场景三:维护场景监控

    此场景对应的用户目的详情:

    表3.17

    用户

    目的编号

    深度挖掘

    WANT

    NEED

    WIN

    监控人员

    A1T8

    管理场景监控任务

    每个场景可以对应多个监控任务,可以灵活定制每个监控任务的监控指标,满足不同场合的需求

    创建监控任务时任务名默认显示场景名;自动勾选默认的监控指标

    维护人员

    A2T1

    快速定位到关心的场景监控

    便于快速定位场景,加快问题排查(趋利)

    为了满足灵活性要求,场景不设定指标,创建监控任务的时候从场景指标集中挑选指标。一个场景可以创建多个监控任务。

    1、监控任务主要属性包括场景、监控任务名、监控指标、状态、开始时间、停止时间,场景监控任务具有较强的实时性,不需要给其附加周期性、定时、定点等时间属性。

    2、监控任务名称需要限定长度(64位,避免在页面显示超长)、非法字符范围(除字母、数字、下划线、减号、左右括号以外的字符)。

    3、监控任务状态包含运行、停止、暂停。

    4、监控任务主要操作包括增加、修改、删除、查询。

    5、创建监控任务时任务名默认显示场景名。

    6、自动勾选默认的监控指标。

    7、过滤查询时支持按场景、状态、指标进行过滤,对监控任务名、开始时间、停止时间等属性进行匹配搜索过滤。

    Step1:流程图建模

     

    图6 创建场景监控任务

           修改场景监控的流程与创建场景监控类似,不在列出。

    Step2:给测试条件填充数据输出AC。

    表3.18

    编号

    WHEN

    THEN

    操作

    场景

    监控任务名称

    指标个数

    S3-010

    创建

    咸阳机场-掉话率

    >0

    失败

    S3-020

    创建

    咸阳机场

    0

    失败

    S3-030

    创建

    咸阳机场

    咸阳机场-掉话率

    0

    失败

    S3-040

    创建

    咸阳机场

    咸阳机场-掉话率

    >0

    成功

    S3-050

    修改

    咸阳机场

    咸阳机场咸阳机场+57个1

    >0

    失败

    S3-060

    修改

    咸阳机场

    咸阳机场!@#

    >0

    失败

    S3-070

    修改

    咸阳机场

    咸阳机场-掉话率(重名)

    >0

    失败

    S3-080

    修改

    咸阳机场

    咸阳机场-告警监控

    0

    失败

    S3-090

    修改

    咸阳机场

    咸阳机场-告警监控

    >0

    成功

     

    Step3:补充模型之外的用例

    监控任务过滤查询、监控任务删除,只与执行的预置条件及输入有关,直接实例化输入输出。

    表3.19监控任务删除

    编号

    GIVEN

    WHEN

    THEN

    监控任务个数

    客户端个数

    操作

    S3-100

    0

    1

    删除

    没有可删除的记录

    S3-110

    5

    1

    删除一个监控

    删除成功,列表显示4个监控任务

    S3-120

    5

    2

    删除一个被其他客户端已经删除的监控任务

    删除失败,列表显示4个场景

    表3.20监控任务查询过滤

    编号

    GIVEN

    WHEN

    THEN

    监控任务个数

    搜索字符

    状态

    场景

    指标

    S3-130

    0

    非空

    新建

    校园

    掉话率

    显示场景数为0

    S3-140

    5

    显示场景数为5

    S3-150

    5,只有一个校园场景下停止状态包含掉话率的教学区监控任务

    教学区

    停止

    校园

    掉话率

    显示场景数为1

    S3-160

    10,没有包含基站退服数运行状态的监控任务

    2016

    运行

    小寨

    基站退服数

    显示场景数为0

    2.4.6.4  场景四:实时监控场景网络

    此场景对应的用户目的详情:

    表3.21

    用户

    目的编号

    深度挖掘

    WANT

    NEED

    WIN

    监控人员

    A1T1

    可以一目了然的查看指标数据

    提供良好的指标数据可视化展示界面,方便了解场景网络的概况

    A1T2

    重点突出指标恶化的网元

    避免在场景指标没有超限情况下,网元指标恶化没有及时发现(避害)

    将指标恶化站点在监控页面自动标示出来,以告警声音警示用户

    维护人员

    A2T4

    提供趋势对比分析等分析手段

    趋势对比分析手段有助于分析定位问题(趋利)

     

    该场景需要达成如下:

    1|、通过良好的图形化、可视化方式展示场景的网络状况,做到一目了然;

    2、通过突出问题网元,及时发现场景问题;

    3、通过颜色渲染和告警声音,提醒用户。

    指标恶化的含义有两种:

    1、  指标数据超过阀值

    2、  指标数据波动幅度较大

    此过程只是数据展示,相对没有流程,需要考虑指标数据变化、场景网元发生变化、任务指标发生变化对数据展示的影响,因此不需要建模,直接生成用例:

     

     

    表3.22

    编号

    GIVEN

    WHEN

    THEN

    指标个数

    网元个数

    指标数据

    场景变更

    任务变更

    S4-010

    9

    5

    没有站点指标恶化

    以合理布局展示9个指标2/3/4G趋势数据,展示5个站点位置

    S4-020

    8

    50

    10个站点出现指标大幅波动

    增加10个站点

    以合理布局展示8个指标2/3/4G趋势数据,展示60个站点位置,10个站点标红。

    S4-030

    7

    100

    30个站点出现指标超过阀值

    减少10个站点

    以合理布局展示7个指标2/3/4G趋势数据,展示90个站点位置,30个站点标红。

    S4-040

    6

    500

    50个站点指标波动幅度大,50个站点指标超过阀值

    增加一个指标

    以合理布局展示7个指标2/3/4G趋势数据,展示100个站点位置,30个站点标红。

    S4-050

    5

    1000

    500个站点指标超过阀值

    减少一个指标

    以合理布局展示6个指标2/3/4G趋势数据,展示1000个站点位置,500个站点标红。

    S4-060

    4

    50

    10个站点指标超过阀值

    以合理布局展示4个指标2/3/4G趋势数据,展示50个站点位置,10个站点标红。

    S4-070

    3

    50

    10个站点指标超过阀值

    以合理布局展示3个指标2/3/4G趋势数据,展示50个站点位置,10个站点标红。

    S4-080

    2

    50

    10个站点指标超过阀值

    以合理布局展示2个指标2/3/4G趋势数据,展示50个站点位置,10个站点标红。

    S4-090

    1

    1

    没有站点指标恶化

    以合理布局展示1个指标2/3/4G趋势数据,展示1个站点位置。

    2.4.6.5  场景五:实时监控控制

    此场景对应的用户目的详情:

    表3.23

    用户

    目的编号

    深度挖掘

    WANT

    NEED

    WIN

    监控人员

    A1T9

    可以控制监控过程

    根据需求,控制监控的过程,增加监控的灵活性(趋利)

    监控任务存在3种状态:运行、暂停、停止。

    1、  运行状态表明任务正在实时监控,采集指标数据刷新监控页面

    2、  暂停状态表明用户不想刷新监控页面,但是不停止指标数据采集,便于后续数据分析。

    3、  停止状态表明监控任务停止监控,不采集指标数据

    依据如下状态转换图建模,输出实例

                                图7 任务状态转换图

    此场景主要考察操作对任务状态转换的影响,因此也直接生成用例:

    表3.24

    编号

    GIVEN

    WHEN

    THEN

    任务状态

    S5-010

    运行

    暂停任务

    成功

    S5-020

    运行

    停止任务

    成功

    S5-030

    运行

    删除任务

    失败

    S5-040

    运行

    运行任务

    无效操作

    S5-050

    暂停

    启动任务

    成功

    S5-060

    暂停

    停止任务

    成功

    S5-070

    暂停

    删除任务

    失败

    S5-080

    暂停

    暂停任务

    无效操作

    S5-090

    停止

    暂停任务

    失败

    S5-100

    停止

    运行任务

    成功

    S5-110

    停止

    删除任务

    成功

    S5-120

    停止

    停止任务

    无效操作

    2.4.6.6  场景六:切换实时监控数据

    此场景对应的用户目的详情:

    表3.25

    用户

    目的编号

    深度挖掘

    WANT

    NEED

    WIN

    监控人员

    A1T3

    监控页面提供数据过切换,以减少操作和页面切换

    提供根据制式、时间等条件进行监控数据过滤和对比分析,便于一页展示,避免繁琐操作和页面切换(避害)

    A1T4

    监控任务切换

    便于快捷查看监控任务数据(趋利)

    记录最近浏览任务,方便切换到最近浏览任务

    监控人员

    A2T1

    快速定位到关心的场景监控

    便于快速定位场景,加快问题排查(趋利)

     

    A2T4

    提供趋势对比分析等分析手段

    趋势对比分析手段有助于分析定位问题(趋利)

    此场景满足用户一页展示数据,减少切换和操作,提高效率的需求。提供两个方面的数据切换:

    1、  当前监控页面的数据展示满足了监控需求,当需要进一步分析数据,进行数据筛选,就需要在监控页面提供操作,支持这些需求。如下所示:

    A)     监控页面同时展示了多种制式的数据,提供制式选择,将监控页面数据切换成单制式数据监控,满足专注单制式监控的需求;

    B)     想查看某个指标的昨天、前一周、前两周数据,与当前数据进行比对分析,提供这种时间选择,满足数据比对分析的需求。

    C)     界面网元提供网元指标数据展示

    2、由于存在多个监控任务,为了方便查看其他监控任务,需要能快速的切换到监控任务。

             A)在场景监控维护中,查询出相应监控任务,查看该任务实时监控

             B) 在实时监控页面,提供按场景查找监控任务,选择任务切换

             C)记录最近浏览监控任务,选择最近浏览监控任务进行切换

    监控数据切换通过选择条件影响监控页面数据展示,相对没有流程,直接输出用例。

    Step1:给测试条件填充数据输出AC。

    表3.26

    编号

    Given

    When

    THEN

    当前监控任务

    场景

    监控任务

    制式

    时间

    网元

    S6-010

    小寨

    校园

    监控任务下拉框出现校园对应监控任务,监控页面数据无变化

    S6-020

    小寨

    校园

    校园-掉话率

    显示校园-掉话率实时监控

    S6-030

    校园-掉话率

    小寨

    显示小寨实时监控

    S6-040

    小寨

    UMTS

    显示小寨 UMTS实时监控

    S6-050

    小寨

    GSM

    显示小寨 GSM实时监控

    S6-060

    小寨

    LTEFDD

    显示小寨 LTEFDD实时监控

    S6-070

    小寨

    掉话率昨天数据

    显示掉话率昨天指标趋势

    S6-0840

    小寨

    掉话率前一周数据

    显示掉话率前一周指标趋势

    S6-090

    小寨

    掉话率前两周数据

    显示掉话率前两周指标趋势

    S6-100

    小寨

    选择一个网元

    显示该网元的监控指标数据

    Step3:补充模型之外的用例

    无。

    2.4.6.7  场景七:切换数据视图

    此场景对应的用户目的详情:

    表3.27

    用户

    目的编号

    深度挖掘

    WANT

    NEED

    WIN

    维护人员

    A2T2

    查看图表具体详细数据

    查看场景指标具体信息,便于分析(趋利)

    A2T4

    提供趋势对比分析等分析手段

    趋势对比分析手段有助于分析定位问题(趋利)

    数据视图相对图形监控页面,弥补了监控页面无法查看指标数据详细信息的缺憾,譬如告警指标对应的告警信息、网元的性能指标信息。

    数据视图切换提供两种切换方式:

    1 选择指标切换,显示指标的详细信息

    2 选择网元,显示网元的指标详细信息

    Step1:流程建模

    图8 数据视图切换

    Step2:给测试条件填充数据输出AC。

    表3.28

    编号

    GIVEN

    When

    THEN

    监控

    网元

    性能指标

    告警指标

    S7-010

    咸阳机场

    基站

    无关

    无关

    显示基站的各个监控指标的当天趋势变化

    S7-020

    咸阳机场

    无关

    掉话率

    无关

    显示场景的掉话率当天趋势,场景网元当天的粒度指标数据

    S7-030

    咸阳机场

    无关

    话务量

    无关

    显示场景的话务量当天趋势,场景网元当天的粒度指标数据

    S7-040

    咸阳机场

    无关

    无关

    严重告警数

    显示严重告警数当天趋势变化,显示场景的按时间排序的严重告警信息,包括流水号、网元名称、归属RNC、发生时间、制式、详细信息等

    Step3:补充模型之外的用例

    数据查询出来后,能够导出来进行分析、备份、通知维护人员,必然有一定价值。

    表3.29场景导出

    编号

    GIVEN

    WHEN

    THEN

    指标类型

    操作

    记录数

    S7-050

    告警指标

    导出

    >0

    导出告警记录>0

    S7-060

    性能指标

    导出

    >0

    导出性能指标数据>0

    S7-070

    告警指标

    导出

    0

    导出告警记录0

    S7-080

    性能指标

    导出

    0

    导出性能指标数据0

    2.4.6.8  场景八:场景指标数据分析

    此场景对应的用户目的详情:

    表3.30

    用户

    目的编号

    深度挖掘

    WANT

    NEED

    WIN

    维护人员

    A2T3

    查看性能指标对象数据

    用于分析的数据越细,越有助于定位问题(趋利)

    A2T4

    提供趋势对比分析等分析手段

    有效的分析手段有助于分析定位问题(趋利)

    数据分析依赖于分析手段及数据,分析手段包括趋势对比分析,TOPN等等,有助于发现定位问题。不过用于分析的数据层次不同,分析的精细程度也就不一样。

    使用场景层次的指标数据进行趋势分析,只能发现大面上的严重问题,无法发现细节问题,对定位帮助不大。

    使用更底层次譬如站点或小区层次的指标数据进行趋势分析、TOPN,对定位问题会有较大帮助。

    通过场景、监控任务、性能指标、制式等条件查询出指标数据,根据判决门限列出具体的指标差的对象,对这些对象进行分析,对定位问题必然有很大帮助。

    根据各种条件组合查询数据,相对没有流程,依赖后续的分析方法,直接输出用例。

    Step1:给测试条件填充数据输出AC。

    表3.31

    编号

    When

    THEN

    场景

    监控任务

    性能指标

    制式

    对象

    操作

    S8-010

    校园

    校园—1

    掉话率

    GSM

    小区1

    趋势对比

    显示小区1的当前与历史趋势对比.

    S8-020

    校园

    校园—1

    掉话率

    GSM

    不选择

    趋势对比

    显示校园的掉话率当前与历史趋势对比。

    S8-030

    校园

    校园—1

    掉话率

    UMTS

    不选择

    TOPN

    校园场景掉话率TOPN小区排序

    S8-040

    校园

    校园—1

    UMTS

    TOPN

    无数据显示

    S8-050

    校园

    校园—1

    掉话率

    小区1

    趋势对比

    无数据显示.

    S8-060

    校园

    LTEFDD

    趋势对比

    无数据显示.

    S8-070

    GSM

    趋势对比

    无数据显示.

    Step3:补充模型之外的用例

    无。

    2.4.6.9  场景九:场景监控报告

    此场景对应的用户目的详情:

    表3.32

    用户

    目的编号

    深度挖掘

    WANT

    NEED

    WIN

    维护人员

    A2T5

    提供图文并茂 、结论突出 、结构清晰的报告

    便于汇报总结(趋利)

     

    场景监控除了提供实时监控、数据分析,能够输出报告进行监控总结,对于给上级领导汇报有较大帮助。

    报告采用html格式,按场景指标分段列出,每段列出指标的趋势图、问题对象及指标数据。

    表3.33

    编号

    When

    THEN

    监控任务

    性能指标个数

    S8-010

    校园—掉话率

    9

    报告中包含9个指标的趋势图和问题对象

    S8-020

    校园—掉话率

    1

    报告中包含1个指标的趋势图和问题对象

     

    2.4.7    线框图

    如下是场景分析过程中画出的线框图

     

    场景及监控管理线框图

     

     

    实时监控线框图

    2.4.8    界面原型

    界面原型经过了团队、产品规划、局方讨论评审,界面原型参见附件: ,在浏览器打开目录中index.html

     

    图9 场景管理界面

     

    图10 场景监控管理界面

     

                                                     图11 监控视图界面

     

    图12 数据视图界面

    2.4.9    设功能

    经过以上的分析,设置为6个主要功能点。

    表3.34

    编号

    简称

    AS

    FOR

    DO

    优先级

    F1

    场景指标管理

    监控人员

    为实时监控提供备选指标集,方便启动监控

    增减告警指标、性能指标,维护场景指标集

    9

    F2

    场景管理

    维护人员

    为实时监控提供监控网元

    维护场景的网元列表,并对场景进行增删改查

    9

    F3

    场景监控管理

    维护人员

    为实时监控提供监控指标

    维护监控指标列表,并对监控任务进行增删改查

    9

    F4

    场景实时监控

    维护人员

    了解场景网络概况及重点问题

    通过图形化、可视化的方式展示数据

    9

    F5

    场景指标数据分析

    维护人员

    方便维护人员定位问题

    提供趋势对比分析等分析手段

    8

    F6

    场景监控报告

    维护人员

    方便总结及汇报

    展示指标数据并给出分析结论

    6

     

     

     

     

     

     

    2.4.10   功能交互分析

    2.4.10.1          本次功能之间的交互分析

    查看各子功能间的交互:

     

    表3.35

    功能

    场景指标管理

    场景管理

    场景监控管理

    场景实时监控

    场景指标数据分析

    场景监控报告

    场景指标管理

    N/A

    无关

    已交互

    已交互

    无关

    无关

    场景管理

     

    N/A

    已交互

    已交互

    已交互

    无关

    场景监控管理

     

     

    N/A

    已交互

    已交互

    已交互

    场景实时监控

     

     

     

    N/A

    已交互

    已交互

    数据视图分析

     

     

     

    N/A

    已交互

    场景监控报告

     

     

     

    N/A

    2.4.10.2          与以往功能之间的交互分析

    老的功能包括区域监控、TOPO监控,与这两个功能没有交互。

    2.4.11   质量属性分析

    主要考虑如下质量属性:

    表3.26

    功能

    可靠性

    安全性

    性能

    扩展性

    可维护性

    可测试性

    场景指标管理

    非常态化业务功能,不涉及

    管理功能,需设置权限

    场景指标数<=9

    已考虑

    已考虑

    已考虑

    场景管理

    同上

    管理功能,需设置权限

    场景个数不受限制

    已考虑

    已考虑

    已考虑

    场景监控管理

    同上

    管理功能,需设置权限

    监控任务太多,对系统会有较大影响,非停止状态监控任务<=100

    已考虑

    已考虑

    已考虑

    场景实时监控

    常态化业务,长时间监控运行半年以上不中断、不出现内存泄露、CPU冲高

    需设置权限,不同地市的只能看到自己地市的场景监控

    数据更新延时<5s

    已考虑

    已考虑

    已考虑

    数据视图分析

    不出现内存泄露、CPU冲高

    需设置权限,授权用户才能查看场景的数据

    数据分析结果显示<5s

    已考虑

    已考虑

    已考虑

    场景报告

    不出现内存泄露、CPU冲高

    需设置权限,授权用户才能查看场景的报告

    输出场景监控报告时间<10秒

    已考虑

    已考虑

    已考虑

    综上,没有发现新的AC。

    3         解决方案分析

    3.1   方案考虑

    1、  在监控项设置界面参照区域监控项设置,增加场景监控项设置,控件、操作与区域监控项设置一样。

    2、  实时监控中根据基站经纬度展示基站,国内局采用矢量图标出基站。国外可以采用开源地图,需要评估使用谷歌地图是否侵权。

    3、  通过EMS代理发送mml命令查询网元计数器数据,在CSP算出网元指标数据,据此发现场景监控的问题网元。

    4、  CSP只存储场景告警、性能指标数据。网元的性能指标数据不存储,都通过MML命令查询获取。降低对系统配置、负荷压力。

    3.2   风险考虑

    1、  在监控任务较多的情况,采集数据量比较大,系统负荷比较大,同时需要评估频繁查询EMS告警、性能数据对EMS的影响。

    2、  场景报告格式还需要与用户沟通。

    3、  实时监控中根据基站经纬度展示基站,需要研究评估是否能实现。

    4、  场景监控需求比较大,开发时间比较长,不知道是否能满足印尼6、7月份节点要求。

     

    4         外部接口说明

     

    <待进一步细化>

    5         关联需求汇总

    6         会议讨论记录

    场景监控需求实例化过程中,按照需求实例化流程,其间融合UX设计方法,体现了产品级敏捷的思想,取得较好的效果。团队成员全程参与,同时邀请规划黄淑清参与了实例化讨论,大家对需求的理解和讨论充分全面,对后期需求开发有极大帮助。

    在完成原型图后,与西安办事处同事、陕西联通监控大厅监控人员进行了演示和讨论,他们做为最终用户提出了很好的意见,特别对监控视图可视化展示给出了很好的建议。

    讨论白板照片SVN路径:https://10.67.18.31:8443/svn/ZXM-GUT_Doc/运维领域/需求文档/刀锋/场景监控/白板照片

  • 相关阅读:
    HTML: 表单标签、CSS语法、CSS选择器、CSS属性
    HTML:快速入门、表格标签
    JDBC连接池&JDBCTemplate
    JDBC
    MYSQL多表查询&事务
    使用CompletionService批处理任务(线程池阻塞线程)
    java运行字符串代码
    Linux常用命令大全(非常全!!!)
    SpringBoot防止重复请求,重复表单提交超级简单的注解实现
    在Spring-boot中,为@Value注解添加从数据库读取properties支持
  • 原文地址:https://www.cnblogs.com/onetwo/p/5447122.html
Copyright © 2011-2022 走看看