CN115033221A - 基于风险演变网的软件产品责任管理系统及方法 - Google Patents
基于风险演变网的软件产品责任管理系统及方法 Download PDFInfo
- Publication number
- CN115033221A CN115033221A CN202210638026.3A CN202210638026A CN115033221A CN 115033221 A CN115033221 A CN 115033221A CN 202210638026 A CN202210638026 A CN 202210638026A CN 115033221 A CN115033221 A CN 115033221A
- Authority
- CN
- China
- Prior art keywords
- risk
- responsibility
- software
- evolution
- coding
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/31—Programming languages or programming paradigms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0635—Risk analysis of enterprise or organisation activities
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Human Resources & Organizations (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Physics & Mathematics (AREA)
- Economics (AREA)
- General Engineering & Computer Science (AREA)
- Entrepreneurship & Innovation (AREA)
- Software Systems (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Operations Research (AREA)
- Development Economics (AREA)
- Marketing (AREA)
- Game Theory and Decision Science (AREA)
- Computing Systems (AREA)
- Educational Administration (AREA)
- Computer Hardware Design (AREA)
- Stored Programmes (AREA)
Abstract
本发明公开基于风险演变网的软件产品责任管理系统及方法,其中涉及的责任管理系统,包括:风险输入模块,用于构建与软件设计相对应的风险演变模型;风险检测模块,用于对软件产品进行编码,并基于风险演变模型对编码过程进行检测,以使风险驱动编码的优化,得到编码相对应的履责结果;风险责任评估模块,用于对编码结果以及履责结果进行风险驱动调试,根据调试结果判断风险检测是否合格,得到最终评估结果。本发明将软件研运建模成一个风险演变网,软件研运过程就是减少目标风险的过程,形成参与人员的风险责任,通过风险管控成熟度逐步实现:软件性能可控、软件质量及成本可控、软件客户满意度可控、软件市场领引可控、尽责式AIOps。
Description
技术领域
本发明涉及软件产品开发管理技术领域,尤其涉及基于风险演变网的软件产品责任管理系统及方法。
背景技术
软件产品开发越来越重要,每个设计、开发人员、软件供应商、运维需要对自己设计的产品框架或代码或业务数据负责任,责任范围包括:用户价值实现风险、设计风险、代码质量、性能质量、安全漏洞、知识产权侵权、敏感数据、程序技术缺陷、运维的用户业务价值增长等,即一旦出了严重的产品价值偏差问题,就需要对相应的人员问责、追责。
当然任何好的、高效的管理都不是以问责、追责为目的的,需要将这些产品价值偏差问题提前找出来,对开发人员进行失责前提醒,目前虽有通过工具检查、或审查人员审查、或测试人员测试,但由于这些人员对上述问题及相应责任便捷的认知不尽相同。所以如何确保每一位开发人员都能有效地尽责,成为了软件产品开发中的大难题。
确保风险管控才能尽责,软件产品开发主要有闭源、开源或组合三种方式,开源方式更好地利用了不同组织或个人的智慧,具有很强的竞争力,发展越来越主流化,但开源面临的风险也更多,从管理风险和技术风险两方面来看:
1)主要的管理风险有:产品价值实现风险、敏感数据泄密风险、知识产权风险(版权侵权;专利侵权;商标侵权;许可证冲突)、软件质量风险、运维成本高的风险(因为不考虑运维,技术迭代快、运维成本高)、统筹管理风险、安全漏洞风险和开源技术垄断风险。
2)主要的技术风险有:资源泄漏、空指针引用、内存损坏、错误处理问题、控制流问题、变量未初始化、跨站脚本攻击、调用多余参数出错、不安全的数据处理、未捕获异常等风险。
因为开源的编程人员,很有可能来自全球各地,有些是属于不同的组织,有些是个人,对以上各种风险的认知标准不同导致认知、理解深度不同,且人员易调整、多变,管理流程难以真正确保责任主体明确、责任边界清晰,另外还缺乏良好的商业模式(或良好的绩效考核机制),这些都严重影响软件产品的尽责管理机制,构不成一个良好的软件产品(或平台)的生态,难以持续发展。
当前软件开发管理采用的是软件成熟度模型(CMM),其主要是用于评估软件组织的开发过程是否规范,这只是管理风险的重要一部分,再则CMM需要大量的资源和复杂的规范化机制,CMM最高认证组织也无法确保开发的产品具有市场领引能力或高价值,成本高且在开源管理上基本难以胜任应用,另外也不是以人的主观能动性为目的,通过人力方式来解决各种风险,所以竞争力有限。另外需求还会经常变动,即用户会逐步理清自己的真实需求,比如互联网开发、或基于客户全程结合的快速开发。
为了避免以上缺点,软件开发中还采用敏捷软件开发管理,但这个开发管理对人的要求很高,一旦中后期就会出现对需求理解不统一的风险,导致对沟通的要求也特别高,规模小、项目快速应付、软件快速迭代。同时还会有一些数字化团队,其业务不够稳定、应急性强,导致传统管理下人员成长性比较差。具体的可以参考图1,包括后面的DevOps将运维结合到开发中,也包括人工智能的研发、运维智能化。
当前软件开发机制主要采用面向对象的构建方法(UML)、图示、原型法来进行软件产品的设计,以及后续编程语言的编程、测试等。这些机制很难确保风险有效管控、责任有效到位。所以需要基于完全的Cyberspace(信息时空),构建一种新的风险管控成熟度的责任管理体系。
针对上述技术问题,本发明提供基于风险演变网的软件产品责任管理系统及方法。
发明内容
本发明的目的是针对现有技术的缺陷,提供了基于风险演变网的软件产品责任管理系统及方法。
为了实现以上目的,本发明采用以下技术方案:
基于风险演变网的软件产品责任管理系统,包括:
风险输入模块,用于构建与软件设计相对应的风险演变模型;
风险检测模块,用于对软件产品进行编码,并基于风险演变模型对编码过程进行检测,以使风险驱动编码的优化,得到编码相对应的履责结果;
风险责任评估模块,用于对编码结果以及履责结果进行风险驱动调试,根据调试结果判断风险检测是否合格,得到最终评估结果。
进一步的,所述风险输入模块中风险演变模型包括软件需求风险、产品设计风险、UI设计风险、架构设计风险、与设计人员相关的责任清单、与设计人员相关的风险责任。
进一步的,所述风险输入模块中风险演变模型,表示为:
其中,R表示风险演变模型的集合;S表示风险空间维度;T表示风险时间维度;L(x)表示损失可能函数或不确定可能函数;C(y)表示损失判断函数或不确定性差距函数;f(L(x),C(y))表示风险模型的函数;TS表示风险R的迁移集合;FS表示工作流。
进一步的,所述风险演变模型中还包括代码风险检测模型,表示为:
R·<Rmax={ri·<rimax,r∈R}
其中,R·表示迁移后的风险;Rmax表示可接受的代码风险;rmax表示软件开发中最大可接受的代码风险。
进一步的,所述风险输入模块中还包括风险管理模块,用于对风险演变模型进行管理并调整,得到调整后的风险演变模型。
进一步的,所述风险检测模块具体为:基于责任清单对软件产品进行编码,基于风险演变模型对编码不同流程的关键节点进行风险输入提醒,并对风险提醒处理后完成后进行风险检测。
进一步的,还包括风险责任验证转交模块,用于基于评估结果将风险进行移交,构建移交的责任风险工作流。
相应的,还提供基于风险演变网的软件产品责任管理方法,包括:
S1.构建与软件设计相对应的风险演变模型;
S2.对软件产品进行编码,并基于风险演变模型对编码过程进行检测,以使风险驱动编码的优化,得到编码相对应的履责结果;
S3.对编码结果以及履责结果进行风险驱动调试,根据调试结果判断风险检测是否合格,得到最终评估结果。
进一步的,所述步骤S1中风险演变模型,表示为:
其中,R表示风险演变模型的集合;S表示风险空间维度;T表示风险时间维度;L(x)表示损失可能函数或不确定可能函数;C(y)表示损失判断函数或不确定性差距函数;f(L(x),C(y))表示风险模型的函数;TS表示风险R的迁移集合;FS表示工作流。
进一步的,所述风险演变模型中还包括代码风险检测模型,表示为:
R·<Rmax={ri·<rimax,r∈R}
其中,R·表示迁移后的风险;Rmax表示可接受的代码风险;rmax表示软件开发中最大可接受的代码风险。
与现有技术相比,本发明将软件研运建模成一个风险演变网,软件研运过程就是减少目标风险的过程,形成参与人员的风险责任,通过风险管控成熟度逐步实现:软件性能可控、软件质量及成本可控、软件客户满意度可控、软件市场领引可控、尽责式AIOps。
附图说明
图1是背景技术提供的软件开发管理示意图;
图2是实施例一提供的基于风险演变网的软件产品责任管理系统结构图;
图3是实施例二提供的软件设计典型工作流风险变迁管理示意图;
图4是实施例二提供的基于风险-责任的软件开发管理示意图;
图5是实施例二提供的风险时空的信息时空履责过程示意图;
图6是实施例三提供的敏捷开发工作流示意图;
图7是实施例四提供的责任(风险)工作流示意图。
具体实施方式
以下通过特定的具体实例说明本发明的实施方式,本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用,本说明书中的各项细节也可以基于不同观点与应用,在没有背离本发明的精神下进行各种修饰或改变。需说明的是,在不冲突的情况下,以下实施例及实施例中的特征可以相互组合。
本发明的目的是针对现有技术的缺陷,提供基于风险演变网的软件产品责任管理系统及方法。
实施例一
本实施例提供基于风险演变网的软件产品责任管理系统,如图2所示,包括:
风险输入模块11,用于构建与软件设计相对应的风险演变模型;
风险检测模块12,用于对软件产品进行编码,并基于风险演变模型对编码过程进行检测,以使风险驱动编码的优化,得到编码相对应的履责结果;
风险责任评估模块13,用于对编码结果以及履责结果进行风险驱动调试,根据调试结果判断风险检测是否合格,得到最终评估结果。
风险输入模块11,构建与软件设计相对应的风险演变模型。
软件设计为对软件进行开发,需要通过编写代码等方式实现软件的生成;在软件开发中会涉及到用户需求的分析、根据用户的需求进行产品设计、根据产品设计的内容进行平面涉及、UI设计以及交互分析等、等设计图纸呈现后相关工作人员会进行产品的代码架构搭建、架构搭建完成后实现代码的补充等等,在对上述每个节点进行是现实均会涉及到风险,因此需要涉及一种风险演变模型进行实时把控。
本实施例的风险演变模型会融合软件需求风险、产品设计风险、UI设计风险、架构设计风险、与设计人员相关的责任清单、与设计人员相关的风险责任等等。
建立相应的风险库,从静态进行演进,理顺软件的设计阶段、编码阶段、调测阶段的风险演变机理,在设计阶段即梳理好不同阶段的风险及风险演变情况(即形成风险演变网),同时将风险以责任方式分配给该阶段的人员,人员在操作的关键节点需要进行风险快速检测,然后再逐一履责,再评估,实现软件以业务视角为基础,产品视角、技术视角相结合的目标有效管控。
在进行风险库建立时,将顾客、供应商(承包商)、开源开发人员均加进来,尤其是平台开发机制,可以符合更好的商业模式。
本实施例将建立的风险库中的风险进行分级管理,1级属于风险不全阶段;2级属于风险全面阶段;3级属于风险的有效管控阶段;4级属于目标达标阶段;5级属于目标优化阶段。
风险演变(RTNet)模型,表示为:
其中,R表示风险演变模型的集合;S表示风险空间维度;T表示风险时间维度;L(x)表示损失可能函数或不确定可能函数;C(y)表示损失判断函数或不确定性差距函数;f(L(x),C(y))表示风险模型的函数,统一接口模块的量化标准;TS表示风险R的迁移集合,迁移前的风险设为·R,迁移后的风险设为R·,则R·是产品建模语言或程序代码对·R的风险驱动关系,也可以是主观设计对R的驱动关系,其中单一迁移如图7的一个节点到另一个节点,如图7中的wt1;FS表示工作流,工作流中与一个人员或一群人相对应,同时和工作流的流向对应,如图7所示;x表示软件对风险的检测、人员的培训教育、风险日常管控确保,必要时通过采集并流程规范的软件模块降低损失可能;y表示软件产品市场竞争力、软件产品用户价值、产品质量、产品性价比。
风险演变模型中还包括代码风险检测模型,表示为:
R·<Rmax={ri·<rimax,r∈R}
其中,R·表示迁移后的风险;Rmax表示可接受的代码风险;rmax表示软件开发中最大可接受的代码风险;即在软件开发中要求关键的风险必须小于rmax,或者严格地可以要求所有的风险必须小于rmax。
风险检测模型还可以进行优化,可以从中识别相应工作流节点责任人的解决风险的能力,如果解决不过关,则责任人就是风险源。识别过程可以是自动分析,也可以是关键节点专家评审机制。
代码程序目前的时间:静态、运行时二种,要评估代码的风险值演变是大了还是小了,要理清代码的映射关系。静态风险分析:代码风险;动态风险分析:代码风险。
在本实施例中,还包括风险管理模块,用于对风险演变模型进行管理并调整,得到调整后的风险演变模型。
风险管理,也是风险叠加管理,通过风险机理来实现有效变更。软件升级也是一样,即先功能单一,后功能可定制或多样化,或可符合对用户的有效定制。
在风险检测模块12中,对软件产品进行编码,并基于风险演变模型对编码过程进行检测,以使风险驱动编码的优化,得到编码相对应的履责结果。
用户根据预先搭建的责任清单对软件产品进行需求分析、产品设计、图形设计、架构设计、代码编写等等,在制作软件的每个节点中均会有相对应的风险存在,因此,用户在编码时涉及到的每个节点,风险演变模型会针对不同关键节点输入风险提醒,即若在编码中某一个环节出现了问题(即存在风险),系统会自动提示出错等信息,以便用户及时修改,当用户改正后模型还会继续对改正后的风险进行检测,以使风险及时解决,进而保证软件产品的正确性。
本实施例在不同阶段每个风险都有风险演变机制,以及相应的人员的责任清单,每一个工作流节点,如图3所示,有三个节点:wai、waj和wak,每一个节点负责人有相应的责任清单,在工作流节点转移,如wtj-k中wtj的负责人需要通过风险值的评估即履责条件,只有履责条件满足规则方可完成节点的转移(量化履责、量化尽责过程),可以实现技术风险零责任监管的机制,当然管理风险还是需要责任监管的。
在风险责任评估模块13中,对编码结果以及履责结果进行风险驱动调试,根据调试结果判断风险检测是否合格,得到最终评估结果。
评估即对履责结果进行调试或测试,除了要测试编码的结果是否成功,还要测试编码过程中遇到的风险是否控制住了;其中编码结果包括需求是否合理,产品设计是否合适、图形设计是否符合要求、架构搭建是否成功、代码编写后生成的程序是否运动顺畅、是否存在Bug等等。
根据上述判断可以得到风险检测是否成功,若没有,则继续对风险进行管控;若成功,则进行后续工作,如通过后的移交、移交的个人责任芯建立,这样形成了风险驱动的工作流。
本实施例还包括风险责任验证转交模块,用于基于评估结果将风险进行移交,构建移交的责任风险工作流。
责任风险工作流如图7所示。
本实施例将软件研运建模成一个风险演变网,软件研运过程就是减少目标风险的过程,形成参与人员的风险责任,通过风险管控成熟度逐步实现:软件性能可控、软件质量及成本可控、软件客户满意度可控、软件市场领引可控、尽责式AIOps。
相应的,还提供基于风险演变网的软件产品责任管理方法,包括:
S1.构建与软件设计相对应的风险演变模型;
S2.对软件产品进行编码,并基于风险演变模型对编码过程进行检测,以使风险驱动编码的优化,得到编码相对应的履责结果;
S3.对编码结果以及履责结果进行风险驱动调试,根据调试结果判断风险检测是否合格,得到最终评估结果。
进一步的,所述步骤S1中风险演变模型,表示为:
其中,R表示风险演变模型的集合;S表示风险空间维度;T表示风险时间维度;L(x)表示损失可能函数或不确定可能函数;C(y)表示损失判断函数或不确定性差距函数;f(L(x),C(y))表示风险模型的函数;TS表示风险R的迁移集合;FS表示工作流;x表示软件对风险的检测、人员的培训教育、风险日常管控确保,必要时通过采集并流程规范的软件模块降低损失可能;y表示软件产品市场竞争力、软件产品用户价值、产品质量、产品性价比。
进一步的,所述风险演变模型中还包括代码风险检测模型,表示为:
R·<Rmax={ri·<rimax,r∈R}
其中,R·表示迁移后的风险;Rmax表示可接受的代码风险;rmax表示软件开发中最大可接受的代码风险。
实施例二
本实施例提供的基于风险演变网的软件产品责任管理系统与实施例一的不同之处在于:
本实施例以会责产品的开发为例进行说明。
会责:是指责联网上的一个手机APP工具,主要功能是开会责任进行目标体系的PDCA(P计划,D执行,C检查,A反馈)闭环管理,即年度目标、月度目标在年会、月会和周会上的体现,到底有哪些风险,这些风险应该怎么通过责任落实的角度来指派任务,责任落实的提醒和跟踪,可以将会议上的语音和自动识别的文字作为履责检查的依据,同时力求开会将任务以量化明责/知责的形式理透,以便于后期的有效履责,确保目标的成果。
产品如图4所示,分成三个阶段:设计、编码和调测。设计为风险驱动的设计,风险驱动的编码,风险驱动的调测,当然这些风险和责任是可以映射到人的。
设计阶段:参与方包括用户(研发部)、产品经理、技术经理,需要用户需求、设计优化、变更管理,做为一个创新产品,会责的用户需求无法直接全面细化,新产品需要经过技术论证和原型试用提升,这里就会有“需求不到位”的风险;需要产品经理抓住几个主要功能,先细化,所以会有“架构不充分”、”用户UI不友好”、“运维成本高”的风险;由于用户本身就是自身企业的新产品研发,如何推广也需要有个过程,所以也会存在“商业模式不到位”的风险。风险驱动到人,即需要落实相应的责任任务到人,分别是研发部负责、产品经理和技术经理,由于产品重要,所以由总经理或副总经理进行监管。
软件开发时的流程图如图4所示,在不同的流程关键节点中,有相应的风险输入提醒(相应岗位人员考核也需要通过,以便知晓风险点的参数、演变规律、管控机制,可以借助风险可视化工具)、完成后风险检测、风险检测通过后的移交、移交的个人责任芯建立,这样形成了风险驱动的工作流。
具体的风险演变过程,如表1所示。
表1
表1中后台/逻辑设计师在编码阶段涉及到的编码风险有:
5.1变量和方法名的命名不规范、可读性差;
5.2代码没有或很少注释;
5.3路由设计不遵循restful风格;
5.4方法内的行数过大、臃肿;
5.5业务代码未与控制代码分离;
5.6传递进来的参数未进行校验就插入数据库;
5.7大量书写mysql原生语句,产生复杂度较高的查询语句,可读性较差;5.8插入数据时,未处理mysql注入攻击;
5.9有关联关系的,未在model层定义其关联关系;
5.10if...else...没有穷尽;
5.11变量是否为空未做判断;
5.12调用第三方接口未捕获异常;
5.13引用不安全的第三方包;
5.14环境变量未存储在可配置文件中;
5.15业务的关键环节的关键参数未写入日志;
5.16接口调用频率未做限制;
5.17mysql表的设计不符合数据库设计三原则;
5.18未正确创建数据库表的索引,导致查询速度慢;
5.19mysql表未使用外键约束,导致其余表查询数据不存在而报错;
5.20下达督办任务报错;
5.21需要失责提醒的地方未进行提醒。
编码阶段涉及到的管理风险:
6.1团队之间未就需求和功能达成一致意见;
6.2功能更新未及时同步到团队每一位成员;
6.3未书写接口文档;
6.4书写接口文档但参数注释不完整;
6.5团队之间未使用协作工具,导致沟通还效率低下。
编码阶段、调试阶段涉及到的调试风险有:
7.1未进行单元测试;
7.2单元测试没有覆盖所有代码路径;
7.3业务测试整个流程无法跑通;
7.4git push之前未对要提交的代码进行git diff进行review;
7.5分支合并之前未对这两个分支进行git pull导致合并冲突。
编码阶段:有编码履责、风险驱动优化、代码责任三个过程,可以形成图4的工作流。
编码履责:编码人员组织,编码人员理解需求、格式规范(包括编程命名规范、编程代码格式)统一,质量管控要求(代码质量、注释质量、可重用性等)。
风险驱动优化:代码测试、仿真测试、风险管控。
代码责任:履责评分、重构审查、可信入库。
如图5所示,风险时空的信息时空(cyberspace)履责过程,软件这一块需要编制相关的软件来检测,所以不需要如物理时空中的工程管控、防护、教育培训、管理措施、应急机制,而是完全在信息时空中进行的快速量化履责过程,即开源在开发环节中对pullrequest、issue进行检查或增量检查,如图3所示,影响的源代码状态进行相应的风险责任审计。
建立以下模型:产品设计数学模型(包括质量风险数学模型、管理风险数学模型)、编程语言数学模型(包括代码风险数学模型)。并实现这二个模型之间的关联,以及风险的传递、风险检测和检测结果的责任落实。
编程语言:面向对象(模型)、面向过程(算法或信息流处理)及混合应用(面向对象中的面向过程,以及面向过程中的对象处理);处理动态信息(指针、引用)、静态信息(变量、数组);算法库:矢量、矩阵、各种数学函数库;处理模型及模型间关系:继承规则、抽象类;人为设计规定、或漏洞补充规则(虚函数、虚基类等)
1)各种测试原理:(单元测试、全路径测试有没问题:不同类型变量的边界测试、算法结果是否可行测试、算法是否正确折测试;);(压力测试:数据量、性能问题)
2)各种技术风险的原理:资源泄漏(检查回收动态资源是否到位,从new相关的到delete);空指针引用(空指针的检查及使用:包括判断、引用及delete);内存损坏(大内存new、内存赋值等);控制流问题(流的应用);变量未初始化(易);跨站脚本攻击(从HTTP/S、TCP、UDP协议中检查域名或IP,进一步判断可能的攻击);调用多余参数出错(有没有默认参数的有效情况,否则编译也通不过的);不安全的数据处理;未捕获异常…
软件产品设计:软件的模型(建模的覆盖面:涉及的组织人员、设施、环境是否齐全)、软件的模型交互功能(产品输入到输出,功能是否满足条件)、模型中的各种数据集、相关数据的采集或自动生成效果、安全性等。
变更设计包括很多外在风险,如下表2。
软件产品设计时还需要考虑:
1)软件模型、源代码的对应关系(包括硬件):目前是通过代码解释、注释来实现,需要用例的逐级展开来理顺。
a)用例图(actor,动作)
b)类包
c)顺序图
d)激活图(流程图)
e)部件图
f)布局图
g)分配图
2)数据集
a)有些算法需要的数据
b)基础信息,需要提供(组织、人员等)
c)解决问题的数据,与上面的流程图结合,要达到效果,需要对用例图进行效果的评估
3)用户功能需求:解决问题的到位程度,用户使用的便利程度
对量化履责进行风险管控,要将后续的风险前移,也要根据人员素质进行合理配置。
对顶层目标进行风险驱动的分解,通过搭建风险工作流,来配置给各级人员,人员对风险管控的考核是需要理解风险演变机理、对风险敏感性、对风险的辨识量化等,即人员的素质既有自身的要求,也有风险演变的可视化驱动,甚至还可以识别后续的大风险,并前置成当前小风险管控的机制。
对于以上额外优化,都应该有一个激励的内容,即可以对担责进行量化激励,以及对用户理解的深入,既有助于培养人,也有助于团队商业竞争力提升,即有更良性的商业模式机制。
这样可以有RMM(风险管控成熟度模型)的分级深入,以培养人、价值提升(竞争力提升)、性价比控制等的机理。
从UML图到编程树的结合
视图方向一条线,要把目前的四个视图打通。这四个视图是:用例视图(包,actor,用例,对象,消息和关系);逻辑视图(包、类、状态和关系);组件视图(包、组件和依附关系);拓扑视图(节点和关系)。
表2
软件代码提交前检测,同时生成责任芯,以代表责任到位情况,
负责任程度的检测,履责过程的快速跟进:各种工具的编制及配合。
责任芯签名(以证明这一段文字是自己提交的)。
实施例三
本实施例提供的基于风险演变网的软件产品责任管理系统与实施例二的不同之处在于:
本实施例以一种敏捷开发为例进行说明,目标管理分成多次快速迭代,而不是实施例二中的一次性完成。如图6为例,每一次迭代开发都是风险工作流。
1)PO和开发团队对产品业务目标形成共识,构建目标风险分级管控流程;
2)PO建立和维护产品需求列表(需求会不断新增和改变),并进行优先级排序,风险分级细化;
3)PO每轮迭代前,Review需求列表,并筛选高优先级需求进入本轮迭代开发,形成风险工程流;
4)开发团队细化本轮迭代需求,并按照需求的优先级,依次在本轮迭代完成,每一步风险可控;
5)开发团队每日站立会议、特性开发、持续集成,使开发风险可控,进度风险可控;
6)PO对每轮迭代(2-4周)交付的可工作软件进行现场验收和风险管控能力反馈,理出重点风险,形成下一轮迭代时的管控机制;
7)回到第3步,开始下一轮迭代;
形成敏捷开发的风险驱动式开发流程。
在风险演变时,也对产品总监或高层中的风险论域进行阶段性分块,按敏捷开发的重点对风险论域进行处理,有些风险集可以先搁置,可以后一步实现,比如敏捷开发更多倾向于市场营销。
实施例四
本实施例提供的基于风险演变网的软件产品责任管理系统与实施例二的不同之处在于:
本实施例以责任(风险)工作流模型为例进行说明,细化了过程中的工作流的风险演变和风险在不同时空中的关注度,实现风险演变管理的工作流机制,如图7所示。
1.工作流WG(有向无环图),工作流上的节点wa,工作流上的转移wt责任清单项,责任清单的风险管控点(分级评估)。
责任节点(RPs,WA,AW,RPe),其中RP是人员责任,RPs、RPe分别是初始责任情况和结束责任情况,可以有个验证和条件,即下一步人员是否可以承担这个,WA是是某一个工作流节点,
2.责任组织,基本数学模型有:组织模型,责任目标模型,多目标风险模型,人员责任模型,人员责任素质评估模型。
复杂数学模型有:责任目标分解模型,风险管控模型,目标价值归类模型,目标以责定利模型。
人员责任:RP=<Pi|p1,…pn,pi∈(p1,...,pn)>,其中n=1时,称为单人责任。
组织责任体:<pj,RP>。
3.工作流责任演变进程,a1<RPa1>,<Rsa1><Rsa2>,wt1需要评估Rs有哪些风险是变大了,哪些风险是新增的,则可以形成问责依据。
责任工作流即风险工作流。
4.风险软件快速检测:对软件编程可以这样来看,风险自洽。
5.风险会审(会责):提出可能的风险,变更风险,风险商议节点。
6.让工作流中的风险越来越可控。
实施例五
本实施例提供的基于风险演变网的软件产品责任管理系统与实施例二的不同之处在于:
应用于DevOps,即除设计、开发、调测之外,还增加了软件产品的部署、产品运营、再升级、业务保障监控等环节。
部署有:生产部署、部署报告、上线切换等;运营有:运营监控、配置、业务保障、升级回退、下线等。也包括各种DevOps的以下工具链的风险快速检测和集成风险设计。
·代码管理:SCM GitHub、GitLab、SubVersion、TFS
·构建工具:Ant、Gradle、Maven
·自动部署:Capistrano、CodeDeploy
·持续集成:CI Bamboo、Hudson、Jenkins
·配置管理:Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail
·容器:Docker、LXC、第三方厂商如AWS
·编排:Kubernetes、Core、Apache Mesos、DC/OS
·服务注册与发现:Zookeeper、etcd、Consul
·脚本语言:Python、Ruby、Shell
·日志管理:ELK、Logentries
·系统监控:Datadog、Graphite、Icinga、Nagios
·性能监控:AppDynamics、New Relic、Splunk
·压力测试:JMeter、Blaze Meter、loader.io
·预警:PagerDuty、pingdom、厂商自带如AWS SNS
·HTTP加速器:Varnish
·消息总线:ActiveMQ、SQS
·应用服务器:Tomcat、JBoss
·Web服务器:Apache、Nginx、IIS
·数据库:MySQL、Oracle、PostgreSQL等关系型数据库;cassandra、mongoDB、redis等NoSQL数据库
·项目管理:PM Jira、Redmine、禅道、Asana、Taiga、Trello、Basecamp、PivotalTracker
也以风险工作流方式,将运维人员也纳入风险管理中。
实施例六
本实施例提供的基于风险演变网的软件产品责任管理系统与实施例二的不同之处在于:
应用于安全生产和数字化转型,重点在于架构和管理层级的区别。
如表3,从文化层、战略层(管理一级要素)、目标层(管理二级要素,因为内容比较多,所以这里略过),任务层(多个技术层)。
表3
实施例七
人工智能研运体系(MLOps/AIOps)
本实施例提供的基于风险演变网的软件产品责任管理系统与实施例五的不同之处在于:
增加对机器学习或深度学习的研发、运维来进行风险工作流管理,包括商业目标评估、业务KPI评估、机器学习问题框定、机器学习模型训练、收集并治理算法所需数据、预处理数据、设计业务目标模型、迭代训练模型并进行业务目标优化、部署、监控等的风险集,以及风险的工作流。
还可以实现对机器学习的算法库进行风险管理。
包括对机器学习全流程自动化的风险驱动,包括数据预处理、特征工程、模型超参数优化、模型选择和模型部署的风险工作流管控。
以及对数据驱动的AI的风险管理,包括数据过载与KPI、目标之间的风险管理工作流。
实施例八
本实施例提供的基于风险演变网的软件产品责任管理系统与实施例六的不同之处在于:
引入尽责学习机制,来建立学习的业务目标风险函数、认知风险函数以及复杂业务的未知风险或模糊风险的建模,实现不同岗位的尽责,以及尽责学习代替人的尽责风险深度识别及风险工作流管理。
从尽责学习代替人的角度来判断代替人的担责风险如何管控上实现相应的通用型AI的风险可接受,以及通过对尽责的责任清单进行风险深度评估,以及定制责任清单的风险、责任清单量化履责的风险工作流管控。
本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代,但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。
Claims (10)
1.基于风险演变网的软件产品责任管理系统,其特征在于,包括:
风险输入模块,用于构建与软件设计相对应的风险演变模型;
风险检测模块,用于对软件产品进行编码,并基于风险演变模型对编码过程进行检测,以使风险驱动编码的优化,得到编码相对应的履责结果;
风险责任评估模块,用于对编码结果以及履责结果进行风险驱动调试,根据调试结果判断风险检测是否合格,得到最终评估结果。
2.根据权利要求1所述的基于风险演变网的软件产品责任管理系统,其特征在于,所述风险输入模块中风险演变模型包括软件需求风险、产品设计风险、UI设计风险、架构设计风险、与设计人员相关的责任清单、与设计人员相关的风险责任。
4.根据权利要求3所述的基于风险演变网的软件产品责任管理系统,其特征在于,所述风险演变模型中还包括代码风险检测模型,表示为:
R·<Rmax={ri·<rimax,r∈R}
其中,R·表示迁移后的风险;Rmax表示可接受的代码风险;rmax表示软件开发中最大可接受的代码风险。
5.根据权利要求1所述的基于风险演变网的软件产品责任管理系统,其特征在于,所述风险输入模块中还包括风险管理模块,用于对风险演变模型进行管理并调整,得到调整后的风险演变模型。
6.根据权利要求2所述的基于风险演变网的软件产品责任管理系统,其特征在于,所述风险检测模块具体为:基于责任清单对软件产品进行编码,基于风险演变模型对编码不同流程的关键节点进行风险输入提醒,并对风险提醒处理后完成后进行风险检测。
7.根据权利要求1所述的基于风险演变网的软件产品责任管理系统,其特征在于,还包括风险责任验证转交模块,用于基于评估结果将风险进行移交,构建移交的责任风险工作流。
8.基于风险演变网的软件产品责任管理方法,其特征在于,包括:
S1.构建与软件设计相对应的风险演变模型;
S2.对软件产品进行编码,并基于风险演变模型对编码过程进行检测,以使风险驱动编码的优化,得到编码相对应的履责结果;
S3.对编码结果以及履责结果进行风险驱动调试,根据调试结果判断风险检测是否合格,得到最终评估结果。
10.根据权利要求8所述的基于风险演变网的软件产品责任管理方法,其特征在于,所述风险演变模型中还包括代码风险检测模型,表示为:
R·<Rmax={ri·<rimax,r∈R}
其中,R·表示迁移后的风险;Rmax表示可接受的代码风险;rmax表示软件开发中最大可接受的代码风险。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210638026.3A CN115033221A (zh) | 2022-06-07 | 2022-06-07 | 基于风险演变网的软件产品责任管理系统及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210638026.3A CN115033221A (zh) | 2022-06-07 | 2022-06-07 | 基于风险演变网的软件产品责任管理系统及方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115033221A true CN115033221A (zh) | 2022-09-09 |
Family
ID=83122310
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210638026.3A Pending CN115033221A (zh) | 2022-06-07 | 2022-06-07 | 基于风险演变网的软件产品责任管理系统及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115033221A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116204236A (zh) * | 2023-04-27 | 2023-06-02 | 深圳艾为电气技术有限公司 | 基于模板的ptc驱动器配置方法及装置 |
CN117252569A (zh) * | 2023-11-01 | 2023-12-19 | 厦门奇力夸拉网络科技有限公司 | 基于大语言模型的ai日程管理系统 |
-
2022
- 2022-06-07 CN CN202210638026.3A patent/CN115033221A/zh active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116204236A (zh) * | 2023-04-27 | 2023-06-02 | 深圳艾为电气技术有限公司 | 基于模板的ptc驱动器配置方法及装置 |
CN116204236B (zh) * | 2023-04-27 | 2023-09-29 | 深圳艾为电气技术有限公司 | 基于模板的ptc驱动器配置方法及装置 |
CN117252569A (zh) * | 2023-11-01 | 2023-12-19 | 厦门奇力夸拉网络科技有限公司 | 基于大语言模型的ai日程管理系统 |
CN117252569B (zh) * | 2023-11-01 | 2024-08-16 | 厦门奇力夸拉网络科技有限公司 | 基于大语言模型的ai日程管理系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2019113308A1 (en) | Active adaptation of networked compute devices using vetted reusable software components | |
CN115033221A (zh) | 基于风险演变网的软件产品责任管理系统及方法 | |
US8027859B2 (en) | Analysis of a model of a complex system, based on two models of the system, wherein the two models represent the system with different degrees of detail | |
MacCormack et al. | The impact of component modularity on design evolution: Evidence from the software industry | |
De Leenheer et al. | Ontology evolution: State of the art and future directions | |
WO2022237284A1 (zh) | 一种工程化预测分析的方法 | |
Trad | The business transformation framework and enterprise architecture framework for managers in business innovation: An applied holistic mathematical model | |
Afzal et al. | Intelligent software product line configurations: A literature review | |
Nazir et al. | Architecting ML-enabled systems: Challenges, best practices, and design decisions | |
Alvarez‐Rodríguez et al. | Challenges and opportunities in the integration of the Systems Engineering process and the AI/ML model lifecycle | |
Altan et al. | Digital twins in lean construction: a neutrosophic AHP–BOCR analysis approach | |
Gudas | Causal modelling in enterprise architecture frameworks | |
Jafarinezhad et al. | Development of situational requirements engineering processes: A process factory approach | |
Agostinho et al. | Explainability as the key ingredient for AI adoption in Industry 5.0 settings | |
Smaizys et al. | Business Rules based agile ERP systems development | |
Sharifi et al. | Towards improved certification of complex fintech systems–a requirements-based approach | |
Feltus et al. | Towards a multidimensional ontology model for DIH-based organisations | |
Zayakin et al. | Design patterns for a knowledge-driven analytical platform | |
Bi et al. | The Privacy Pillar--A Conceptual Framework for Foundation Model-based Systems | |
Stanev et al. | Why the standard methods, 5GL, common platforms and reusable components are the four pillars of the new computational paradigm Programming without programmers | |
Bouheroum et al. | A Formal Integrated Approach for Cyber Physical Systems | |
Liu et al. | The management of simulation validation | |
George et al. | Fixing state change inconsistency with self regulating particle swarm optimization | |
Kunigami et al. | Amalgamating agent and gaming simulation to understand social-technical systems | |
Tignor et al. | Object Oriented Design Patterns and System Dynamics Components |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |