GraphGists

软件开发过程模型

简介

有时,尽管我们恪守勤勉和流程,软件似乎仍然是偶然发生的。系统通过人员、技能和工具的某种组合渗入我们的生活。结果往往是一堆由许多作者编写的陌生且不清晰的组件,对整体缺乏了解。

广泛认知的好处

软件如果管理得当,会受益于对其创建和消费生态系统中“动态部分”的广泛认知。真实的人们与我们构建的系统交互,我们应该构建更好的模型来跟踪和描述这些系统。

碎片化的功能和孤立的团队

很多时候,致力于特定功能(如质量保证)的团队拥有可以直接管理与其工作职能相关的实体的应用程序和系统,但!…这些团队没有一个能将跨其他团队和工作职能的关注点联系起来的主控系统。通过适当的建模,Neo4j 可以解决这个问题。

连接关注点

通过跟踪系统的各个部分、它们如何连接和交互,以及谁关注这些连接,我们可以更好地理解我们所做更改的影响、关注并受这些更改影响的利益相关者,并且通过可视化,我们可以预测和沟通这些影响。

关于模型

zRAOaHp

在本模型中,采用以下类别对密切相关的标签进行分组

节点域

包含的标签

人类

:Audience, :Group, :Organization, :Person, :Role

流程

:CheckIn, :Defect, :Feature, :Iteration, :Release, :Requirement, :Task, :TestCase, :TestSuite, :UserProfile, :UserStory

技术

:AppLayer, :CodeProject, :CodeSolution, :Component, :CssFile, :Database, :DbFunction, :DbTable, :DbSchema, :DbView, :Environment, :File, :JsFile, :LocalizationKey, :Location, :MvcController, :MvcView, :Platform, :Permission, :Service, :Server

知识

:Audience, :Document, :Term, :Publication, :Skill

测试

:Defect, :Environment, :Feature, :Requirement, :TestCase, :TestSuite, :UserProfile, :UserStory

Web

:CssFile, :JsFile, :MvcController, :MvcView

设置

“人类”节点域 - 人员与群组

拥有一个构建软件的人类或组织环境的“地图”,可以帮助我们应对查找答案或完成更改系统所需请求的挑战。当我们需要告知利益相关者关于系统变化对其业务流程的影响时,它也有助于我们的沟通工作。

// Find Node Types in the "Human" Node Domain
MATCH (m) WHERE m:Person OR m:Group OR m:Role OR m:Organization
RETURN m;

“流程”节点域 - 跟踪工作

在本示例中,通过元数据包含在流程节点域中的标签用于查找此类节点的实例。

// Find node examples in the "Process" 'Node Domain'
MATCH (nt:NodeType)--(:NodeDomain { name: "Process" })
WITH COLLECT(nt.name) AS processNodeTypes
MATCH (m) WHERE LENGTH(FILTER(lbl IN labels(m) WHERE lbl IN processNodeTypes)) > 0
RETURN m LIMIT 50;

示例:查找连接的系统元素

在准备修改应用程序中共享代码资产时,将资产与其他系统部分之间的连接进行可视化会很有用。例如,考虑一个包含影响 Web 界面中多个视图的共享样式表的电子商务应用程序。Cypher 查询可以揭示对正在修改代码的多个依赖关系。

这是一个 Web 电子商务应用程序中共享 CSS 文件的示例。

// CSS to MVC View and MVC Controllers, if present
MATCH (css:CssFile)--(vw:MvcView)
OPTIONAL MATCH (vw)--(ctl:MvcController)
RETURN css, vw, ctl;

示例:对源代码提交进行建模

随着源代码的提交,追溯源代码更新对其影响的资产和功能很有帮助。在大多数系统中,源代码控制本身就是一个孤岛,无法提供将源代码更新追溯到应用程序内功能区域的抽象指定的功能。通过在图中对代码提交进行建模,您可以建立我们日常使用的工具通常不支持的连接。

// Developer checks in changes
MATCH (dev:Person { name: "Dev, Donna" })
MATCH (global_css:CssFile { name: "Global.css" })
MATCH (details_css:CssFile { name: "ProductDetails.css" })
MERGE (checkin:CheckIn { name: "Change set 2231" })
	ON CREATE SET checkin.description = "CSS fixes for product details"
MERGE (global_css)-[:INCLUDED_IN]->(checkin)
MERGE (details_css)-[:INCLUDED_IN]->(checkin)
MERGE (dev)-[:SUBMITTED { submitDate : "2015-06-13" }]->(checkin)
RETURN dev, global_css, details_css, checkin;

示例:一次提交影响了哪些功能?

通过在 Cypher 查询中使用几次“跳转”,可以确定对高级功能可能产生的影响,并且此信息可用于缩小需要关注的项目列表。

// What features did a checkin affect?
MATCH (checkin:CheckIn { name: "Change set 2231" })
MATCH (css_file)-[:INCLUDED_IN]->(checkin)
MATCH (css_file)--(vw:MvcView)
MATCH (vw)-[*1..3]-(feature:Feature)
RETURN DISTINCT checkin, css_file, vw, feature;

示例:QA需要运行哪些测试?

除了受影响的功能外,您还可以使用测试套件与功能的关联以及测试用例与测试套件的关联来构建给定代码提交所需执行的测试用例列表。

这还可以进一步扩展,根据与版本相关的代码(稍后描述)考虑版本所需的测试用例。

// Data: What tests does QA need to run?
MATCH (checkin:CheckIn { name: "Change set 2231"})
MATCH (css_file)-[:INCLUDED_IN]->(checkin)
MATCH (css_file)--(vw:MvcView)
MATCH (vw)-[*1..3]-(feature:Feature)
MATCH (t_case:TestCase)--(t_suite:TestSuite)-[*1..2]-(feature)
RETURN DISTINCT t_suite.name AS `Test Suite`, t_case.name AS `Test Case`;

示例:将提交与版本关联

通过将提交与版本关联,您可以对版本进行的更改进行全面分析,包括受影响的功能。

MATCH (checkin:CheckIn { name: "Change set 2231" })
MATCH (release { name: "Release v1.3" })
MERGE (checkin)-[:INCLUDED_IN]->(release)
RETURN checkin, release;

示例:此版本需要测试什么?

关于版本需要运行哪些测试用例的结论可以从模型中得出。

// Data: What needs tested for this release?
MATCH (rel:Release { name: "Release v1.3" })--(checkin:CheckIn)-[*1..4]-(feature:Feature)--(suite:TestSuite)--(testCase:TestCase)
RETURN DISTINCT rel.name AS `Release`, checkin.name AS `Check-In`, suite.name AS `Test Suite`, testCase.name AS `Test Case`;

示例:特定版本计划了什么?

除了预测版本的测试需求外,还可以对版本内容的进行高级概述建模。

// What's scheduled for Release v1.3?
MATCH (release_v1_3:Release { name : "Release v1.3" })
OPTIONAL MATCH (release_v1_3)<--(n)
RETURN release_v1_3, n;

示例:特定版本包含什么(来自提交的版本说明)

与版本关联的提交的原始视图可以允许编译版本说明,然后发布给利益相关者。

// Data: What's in release v1.3?
MATCH (rel_v1_3:Release { name: "Release v1.3" })
OPTIONAL MATCH (rel_v1_3)--(checkin:CheckIn)
RETURN rel_v1_3.name AS `Release`, checkin.name AS `Check-In`, COALESCE(checkin.description, "No description provided") AS `Description`;

示例:每个环境中存在哪些版本?

软件开发团队面临的一个挑战是按环境跟踪版本。如果您可供选择的环境数量有限,那么知道这一点就更加重要了。

第一部分:向UAT环境添加版本

// Add v1.3 to UAT
MATCH (rel_v1_3:Release { name: "Release v1.3" })
MATCH (uat:Environment { name: "UAT Environment"})
MERGE (rel_v1_3)-[r_1_3:DEPLOYED_IN]->(uat)
RETURN uat, rel_v1_3, r_1_3;

第二部分:按环境检查版本

// Releases in environments
MATCH (rel:Release)--(env:Environment)
RETURN rel, env;
// Data: Releases in environments
MATCH (rel:Release)-[i]-(env:Environment)
RETURN rel.name AS `Version`, TYPE(i) AS `is`, env.name AS `in Environment`;

试一试

自行执行一些查询,探索上面描述的模型。

结论

通过对软件开发过程的各个分散部分进行建模,可以在开发软件时更好地理解风险和影响,并将其可视化。这可以避免浪费时间和精力来解决模型可以揭示的意想不到的问题。


创建者:Jeffrey A. Miller - Twitter | 博客 | LinkedIn

© . All rights reserved.