1 引言

近年来, 互联网的普及、社交网络的发展以及开源软件的兴起使得在线协作的研究与应用成为人们关注的热点. 从广泛使用的Linux操作系统, 到市场占有率第一的Android手机操作系统, 再到当前社会热点大数据所使用的Hadoop、Spark等分布式计算平台, 这些都是为现代化生活做出巨大贡献的开源软件, 也都采用了分布式协作的方式进行开发.

开源软件的开发过程中, 普遍使用分布式版本控制系统进行协作, 如Git, SVN, CVS等. 其中, Git以其极其优秀的分支创建、操作以及删除的能力, 成为目前使用最为广泛的版本控制系统.

在Git的基础上, 2008年4月, 现今全球最大的社交编程及代码托管平台GitHub正式上线. GitHub除了基本的Git代码仓库托管和基于Web的管理界面外, 还提供了文档管理、问题追踪与订阅、在线讨论组等功能, 为专业的开发人员提供了一片高效交流的乐土, 开启了人人都可以做开源项目的新时代. 但是, GitHub主要面向开发及测试人员等专业用户, 相对比较小众; 同时, 对普通用户而言, 使用门槛和学习成本都比较高.

近年来, 随着移动互联网和智能终端的发展, 直接面向最终用户的应用软件越来越多, 传统的软件工程方法已经不能完全适应这一转变, 如何更有效、更准确地把握最终用户的需求, 对企业来说具有重要的意义.

本文提出了一种基于成熟度的开源软件项目立项评估模型, 包含项目需求评估及项目组评估两个主要的阶段, 通过成熟度机制对项目立项的进程进行评估与控制, 帮助最终用户、开发人员、项目管理人员等多方参与到项目的立项评估过程中, 促进相互交流, 确保最终用户能够充分参与到开源软件项目的需求分析过程中.

第二节将介绍相关的研究工作;第三节将详细介绍基于成熟度的软件项目立项评估模型及评估流程;第四节通过一个例子完整展示软件项目的立项评估过程; 最后对全文内容进行总结并提出未来可能的研究方向.

2 相关研究 2.1 众包

“众包”(crowdsourcing)一词是美国杂志《连线》的记者杰夫·豪(Jeff Howe)在2006年5月提出的, 从提出至今得到了工业界和学术界的广泛关注. 他对“众包”的定义是: “一个公司或机构把过去由员工执行的工作任务, 以自由自愿的形式外包给非特定的(而且通常是大型的)大众网络的做法. 众包的任务通常由个人来承担, 但如果涉及到需要多人协作完成的任务, 也有可能以依靠开源的个体生产的形式出现”^[1].

Google提供的reCAPTCHA服务是使用最广泛的验证码服务, 也是最典型的众包项目. reCAPTCHA提供了最基本的验证码服务, 同时, 还利用大量用户的人工识别结果, 来帮助对扫描版的图书做数字化, 还能帮助改善地图的准确度, 为更深层次的AI提供海量的宝贵数据.

“众包”所呈现的参与式文化和所体现的集体智慧加速了创意的产生, 但是同时也伴随着巨大的潜在风险^[2,3], 在享受众包带来的创新资源的同时, 还需规避众包带来的风险.

2.2 Scrum敏捷开发过程模型

Scrum方法是目前全球最流行与最有效的敏捷项目管理理念与方法之一, 是一种快速增量交付软件产品的模型, 在构建产品过程中创建产品的内部团队并与其他用户高度协作^[4]. Scrum方法能够很好的应对快速变化的需求, 强调面对面式的紧密协作与沟通, 频繁的交付新版本.

2.3 软件成熟度

成熟度旨在确定被评估对象的成熟程度, 是对与评估对象有关的概念、状态、以及能力等进行的检查活动^[5]. 项目成熟度的衡量是为用户的选择做参考, 为开发者提供项目质量的评估, 促进软件开发的同时对项目有推广作用^[6].

3 基于成熟度的开源软件立项评估方法

在众包更加广泛应用的现在, 用户群体开始变大, 不再仅仅局限于开发人员, 普通用户也可以是提出自己需求、展示市场痛点的策划人. 这些用户没有足够的开发能力, 也无法通过软件工程的相关工具、图表来给其他用户展示想法, 只能通过自然语言来表达. 本文所构思的平台就是将最终用户、开发人员、项目经理多方参与到项目的立项评估过程中, 让没有开发能力的用户也能参与项目的执行, 以此来拓展用户群体.

3.1 项目成熟度评估

理想的项目成熟度计算是通过系统智能地抓取项目相关信息进行智能地判断给分的, 这里只从项目最主要的三个因素考虑: 项目需求, 项目人员分工, 关注度. 以下的成熟度计算将以这三个因素作为评判依据分成三个阶段的评定, 每个阶段设置一个合适的条件来控制跳转至下一阶段.

3.1.1 项目需求成熟度

项目需求是一个项目最开始就要讨论分析的重要因素, 而需求分析对软件项目后续阶段的工作具有直接的指导性作用, 需求分析执行的程度会直接关系到项目开发的成败^[7]. 成熟度最主要的衡量因素也就是项目需求成熟度.

项目需求成熟度有如下定义:

定义1. 项目需求成熟度.

项目需求成熟度被定义为如下的公式:

$requirement={\sum\nolimits_{r \in R} {m(r)} }/{\left| R \right|}$

其中, R定义为项目组提出的需求集合, 函数m(r)计算某一个需求项r的成熟度, 定义为:

$m(r) = \left\{ \begin{array}{l}\frac{{{v_s}}}{{{v_s} + {v_a}}} \times 100, {\text{若}}{v_s} + {v_a} \ge 1000,{\text{若}}{v_s} + {v_a}<100\end{array} \right.$

v_s为需求项r获得的赞成票数, v_a为需求项r获得的反对票数.

项目需求成熟度的计算流程

(1) 项目组成员进行讨论, 详细列举并修改项目的各项需求;

(2) 用户对每一项未确定的需求投上赞成或者反对的一票;

(3) 计算项目需求成熟度;

(4) 若项目需求成熟度大于等于 80 则可以进入下一个阶段, 否则返回步骤 (1).

需求成熟度计算流程图如图1所示.

3.1.2 项目组成熟度

项目组成熟度是指项目组人员的能力与担任职务的契合程度. 一个专业的用户只有在扮演了他所擅长的角色之后才能最大化地发挥他的能力. 而项目人员分配是否合理, 会直接影响到项目的运作效率^[8].

为了量化项目组参与人员的质量, 设立带等级标签制度, 将用户所擅长的技能设定为带有等级的标签, 用户在平台上参与的活动获取积分, 根据积分提升等级(等级上限为5). 在项目分工时标签可作为评分依据, 通过标签与职务的适配情况来判断是否分配合理. 若在CSDN、Linkedin、GitHub等较为出名的网站上有较高的知名度, 平台可以直接赋予其一定的积分和高等级标签.

定义2. 项目组成熟度.

项目组成熟度被定义为如下的公式:

$labor = {\sum\nolimits_{r \in R} {g(r)} }/{\left| G \right|}$

其中, G定义为项目组分组集合, 函数g(r)计算某一个分组r的成熟度, 定义为:

$g(r) = \left\{ \begin{array}{l}h(r) \times 100,{\text{ 若}}h(r) < 1\\100,{\text{ 若}}h(r) \ge 1\end{array} \right.$

$h(r) ={(\frac{{{p_l}}}{{{s_l}}} + \sum {\frac{{{p_m}}}{{{s_m}}})} }/{x(r)}$

其中, p_l、p_m为分组r的组长和组员的标签等级, s_l、s_m为标准的组长和组员的标签等级(默认为5、3), 函数x(r)为分组r的标准人数, 表1列出默认的值.

项目组成熟度的计算

(1) 综合项目成员人数与项目内容复杂程度对项目组成员进行分工;

(2) 计算项目组成熟度;

(3) 若项目组成熟度大于等于 80 则可以进入下一阶段, 否则返回步骤 (1).

项目组成熟度计算流程图如图2所示.

3.1.3 项目关注度

项目关注度是指一个项目应该引起用户对其关注的程度. 其值越高, 表明该项目内容足够丰富、创意足够新颖, 更容易引起用户的高度关注. 因此项目关注度也应该作为成熟度的评定依据之一.

关注度的计算需要用到信息检索与信息分析的技术, 最基本的信息就是关注量与浏览量, 以下计算不做过于复杂的计算, 主要使用这两个信息做简单计算来表示关注度.

定义3. 项目关注度.

项目关注度被定义为如下的公式:

$concern = \frac{l}{r} \times 100$

其中, l为项目的关注数, r为项目的被浏览数.

项目关注度的计算

(1) 从数据库获取项目的关注量与浏览量;

(2) 计算项目关注度;

(3) 若关注度大于等于 80 则可以进入下一阶段, 否则返回步骤 (1).

3.1.4 计算总成熟度

由以上三个阶段得出成熟度的三个主要因素, 由以下公式计算得出最终的总成熟度:

$\begin{align} Maturity = &requirement \times 50\% + labor \times 30\% \hfill \\ & + concern \times 20\% \hfill \\ \end{align} $

得出总成熟度后, 项目正式开始进入编码阶段, 平台与GitHub对接.

3.2 立项评估流程

当有一个策划者有灵感的时候, 就可以直接在平台上提出此想法, 然后系统会由标题抓取关键词, 并首先自动向策划者推荐类似的项目. 如果策划者觉得系统推荐的创意项目符合自己的预想, 那么可以自行关闭想法; 如若觉得并不符合自己的需求, 可以再添加更加具体的描述, 然后发布此想法. 平台用户一起讨论可行性以及再进一步的润色想法. 如果经过讨论发现此想法实现难度极大甚至无法实现, 策划者可以自行关闭想法; 如果经过润色补充后, 想法逐渐成为一个充实、可执行的项目, 那么策划者可以广招贤士, 组建项目团队, 开始项目的实现.

开始实现项目后, 就必然要进入上文中成熟度评估的流程. 一系列的计算过后, 得出项目的成熟度, 可作为项目质量的凭证. 随后进入开发阶段.

进入正式开发阶段后, 平台对接GitHub以便开发协作. 开发团队应该选择一种软件开发模型, 平台推荐使用Scrum敏捷开发过程模型, 并为此提供了充分的作业空间. 接下来平台对开发过程不做干涉直到开发完成, 结束.

完整的执行流程如图3所示.

4 实例分析 4.1 实例一

现有用户如表2所示.

黄琦在平台上提出一个想法“设计一个可以即时分享想法的平台”, 吸引众多用户进行讨论, 组成讨论组.

王毅提出“不只是要分享想法, 还要做到可以讨论完善想法, 并将想法实现”, 98%的用户表示同意. 张珊认为“可以从即时记录入手, 写一个有较强功能的记事本”, 66%的用户表示同意, 其他用户认为“记事本产品太多, 没必要”.

经过讨论完善后, 多数用户认为可以实现, 于是组成项目组, 有王毅、李尔、张珊、刘肆、陈武、杨柳志愿加入项目组, 王毅被推举为组长, 黄琦作为用户组参与其中.

进入成熟度机制的三个阶段:

(1) 进入需求分析阶段, 项目组与用户组进行讨论, 列出以下需求.

随后过了一周, 有233个用户参与了投票, 每项需求获得的赞成投票数分别为: 1)215, 2)198, 3)204, 4)208, 5)168. 经过计算后得出需求成熟度为85.2, 大于80, 进入下一阶段.

(2) 进入成员分工阶段, 组内讨论后成员分工如表3所示.

经过计算后得出项目组成熟度为80.6, 大于80, 进入下一阶段.

(3) 进入关注度分析阶段, 由系统给出的项目的浏览量为568, 关注量为474, 进行关注度分析算法计算后得出的关注度为83.5.

根据三个阶段获取的三个数据, 计算得出总成熟度:

$Maturity = 85.2 \times 50\% + 80.6 \times 30\% + 83.5 \times 20\% = 83.48$

项目正式成立, 进入编码阶段, 平台对接GitHub, 项目组以Scrum敏捷开发的理念来执行项目开发.

4.2 实例二

现有用户如表4所示.

朱伟提出一个想法“设计一个可以用摄像头拍摄并扫描物体, 然后构建一个类似的3D立体模型的软件”, 吸引众多用户进行讨论, 组成讨论组.

赵刚提出“这种技术已经有了, 有个叫3D扫描仪的机器就可以实现, 如果要用手机摄像头来实现的话, 索尼出的Xperia XZ1实现了这种技术, 可以扫描人脸和3D建模. 如果要自己实现的话, 需要有这方面的专家, 否则难度非常大.”, 98%的用户表示同意.

经过讨论后, 多数用户认为难度过高难以实现, 而且没有专业人员参与, 于是想法作废.

5 结论与展望

本文针对传统的开源软件开发模式在获取用户需求方面存在的问题, 提出了基于项目成熟度评估的开源软件立项评估模型, 从需求成熟度、项目组成熟度、关注度三个角度对项目进行项目成熟度评估, 并通过实例分析模拟了立项评估模型的执行过程. 在未来的工作中, 将尝试在大规模分布式环境下进行实际运行测试, 从而进一步对本文所提出的模型进行细节优化和参数调整.