BugPhobia启程篇章:需求分析与功能定位

0x01 :引言

If you weeped for the missing sunset,

you would miss all the shining stars

我看着大巴缓缓的驶过街角,我躲在那些树后,内心安静的做着告别

相遇在一场雨里

告别在另一场雨里

多好

0x02 :项目的基本定位概述

There are no trails of the wings in the sky,

while the birds has flied away.

 


网站基本定位


面向CS/EE领域的垂直搜索引擎


网站创新形式


首先,按照《构建之法》中创新类型的划分,在创新的类型上,我们的产品是改良型的创新,而非颠覆性的创新


用户基本定位


计算机及相关专业学生,其中以大学生群体为最主要的用户群


用户的知识层次


用户具备基本的编程基础,并具备使用通用搜索引擎(百度、谷歌等)的能力


网站的基本功能


网站能够采集专业化社区中的问答数据、高质量课程资源、专业技术文档中的内容,为使用者提供一体化的、精准的、高质量的搜索内容

同时,用户能够通过网站直接参与到上游社区的讨论中

0x03 :需求调研问卷的反馈

To the world,you maybe a person.

But to a person,you maybe the world.

 


调查问卷设计背景


随着信息技术的需求扩展和蓬勃发展,计算机及相关专业的学习资源(Mooc)平台、通用搜索引擎提供的平台(百度知道、谷歌学术)等已逐步成为学习和工作中不可或缺的一部分。因此,为进一步了解计算机及相关专业的学生、爱好者、及就业人员对专业方向的垂直搜索引擎的需求,软件开发团队BugPhobia,将针对这一领域的用户的基本需求进行调研,并据此进行产品本身的需求分析和开发


调查问卷具体链接


http://www.sojump.com/jq/5964543.aspx


调查问卷发放渠道


通过朋友圈及交流群展开传播,优先覆盖各学校的计算机专业的学生、本科生


调查问卷反馈结果


截至2015年10月20日14时,调查问卷有效填写人次达到140

0x0304 :调查问卷的用户概况

根据调查问卷的反馈结果,截至2015年10月20日14时,调查问卷有效填写量达到140人次,而其中78.57%的填写用户属于计算机及相关专业的学生、职场人才群体,同时也收集了非计算机相关专业群体的部分问卷,在后续的数据处理中将依据不同权重参考调研数据。因此,在用户需求的调研反馈中,首先将调查问卷的有效填写的群体的基本信息以图表的形式展示出来,为后续针对网站定位的用户群体的搜索习惯分析做出一定的铺垫


年龄、学历分布


根据有效调查问卷的反馈,此次调研群体集中于18~21岁,达到114人次,占据总用户调查群体的83.82%;而在基本的学历分布中,学历位于大学本科生(含在读)阶段的有128人,占据总用户调查群体的94.12%,年龄和学历百分比基本符合预期,调查问卷具备有效性

     

图1:调研群体年龄分布饼形图                                            图2:调研群体学历分布饼形图


身份分布


根据反馈,此次调研群体中,计算机及相关专业学生达到106人,占据总调研人群的77.94%;而计算机爱好者、职场人才则将作为参考数据的进行统计。

而根据产品的基本用户定位,此网站的用户定位集中于“计算机及相关专业学生”,调研群体的年龄、学历、身份百分比均超过75%,此调查问卷的结果能够在一定程度上反映真实的用户需求

图3:调研群体身份分布饼形图


学习计算机类技术的目的分布


根据反馈,此次调研群体中,以“参加计算机等级考试”“掌握常用工具使用方法”等为学习技术目的的仅占据11.77%,因此,在第一轮迭代(Alaph阶段),将优先以参与领域研究、软硬件开发用户的需求进行开发,而其他人群将以低权值纳入需求分析中的考虑部分,在“必需需求/辅助需求”部分,将进一步对此进行说明

图4:调研群体学习计算机类技术目的分布饼形图


计算机应用能力分布


根据反馈,此次调研群体中,计算机应用能力基本呈现均衡分布,按照调查问卷所划分的能力层次“仅能编写简单程序”“掌握语言并期望了解数据结构、算法”“简单开发工作”等均占据总调查群体的30%左右。因此,在后续的交叉分析中,即便是处理整体的数据,也能很好地保障“经常搜索哪类信息”的调查结果更具备普遍性

图5:调研群体计算机应用能力分布饼形图


用户经常搜索问题类分布


根据反馈,此次的调研群体中,用户搜索的信息和问题基本呈现集中分布、均衡分布。针对集中分布,在所调研的7类选项中,5类选项在调查中所占据的百分比都超过半数;针对均衡分布,7类选项中的5类选项,在调查中极差仅为16.18%,因此可以做出基本的推断,所提供的搜索引擎针对不同类型的问题筛选,均应做出一定的考虑,而不是在迭代过程中舍弃大部分类型的问题

图6:调研群体用户经常搜索问题类分布饼形图

0x0308 :用户基本搜索渠道统计


标准库函数用法

搜索渠道


百度(百度知道、搜索)


80.68%

 

Google(谷歌学术、搜索)


23.86%


维基百科


15.91%


应用程序API、系统调用

搜索渠道


百度(百度知道、搜索)


71.21%

 

Google(谷歌学术、搜索)


56.06%


StackOverflow


33.33%


编译的错误信息

搜索渠道


百度(百度知道、搜索)


80%

 

Google(谷歌学术、搜索)


41.33%


StackOverflow


18.67%


开源社区代码

搜索渠道


Github等代码托管平台


65.96%

 

Google(谷歌学术、搜索)


42.55%


百度(百度知道、搜索)


42.55%


课程学习中的试题

或专有名词

搜索渠道


百度(百度知道、搜索)


86.96%

 

Google(谷歌学术、搜索)


43.48%


维基百科


28.99%


工具或插件的使用说明

搜索渠道


百度(百度知道、搜索)


84.72%

 

Google(谷歌学术、搜索)


51.39%


维基百科


23.61%

0x030c :用户需求交叉分析

根据基础的调查问卷数据,不妨进行自变量-因变量模型的的相关交叉分析,以“计算机应用能力”为自变量,“经常搜索的信息或问题”为因变量,根据用户的计算机应用能力将用户进行不同层次的划分从不同层次的用户角度分析各自的搜索习惯,从而在需求分析和架构阶段,权衡WBS树的优先权重和开发顺序。


交叉分析

自变量:计算机应用能力

因变量:经常搜索的信息或问题


根据经典柱形图的数据反馈,在柱形图,从左至右的自变量因素按计算机的应用能力的递增顺序排列。因此,在交叉分析中我们清晰观察到用户在随着计算机应用能力增长的同时,其搜索内容的比例变化。由于第四类人群的数据量仅为2.19%,其数据样本本身不具备普遍性,暂且忽略。在前三类人群中

ü  “编译的错误信息”、“标准库函数的用法”基本呈现平稳变化趋势。随着用户学习过程的深入,需要接触不同类型的语言,而基础的语法和初期的编译问题自然占据较大模块。因此,在此部分的检索过程中,将尽可能选取经验化的例子、文档中的部分说明反馈于用户

ü  “应用程序API、系统调用”“开源代码”基本呈现递增变化趋势。随着用户计算机能力的提高,在逐步接触应用程序开发或领域研究时,必须参考部分结构优秀的代码,并逐步查询外包的API手册。因此,在此部分检索过程中,将尽可能针对专业性较强的用户,反馈的结果也将更为专业性

ü  “工具或插件的使用说明”基本呈现动态变化趋势。在初期未接触工具插件时,用户会需要查询相关说明,而后期接触大量工具和插件后同样要查询相关说明,因此呈现不稳定的波动状态。因此,权衡实现,在此部分的检索过程中,将尽可能针对多层次用户,优先将使用心得这类回答反馈,而非手册说明

图7:计算机应用能力-经常搜索问题的自变量-因变量交叉分析条形图

0x04 NABC分析

I leave uncultivated today,

was precisely yestoday perishes tomorrow

which the person of the body implored.

0x0404 :需求( Need )

首先从《构建之法》中对创新界定一张入手分析这一问题,在创新的类型上,垂直搜索引擎属于改良型的创新,而非颠覆性的创新,因此,在具体的需求分析中,我们将重点围绕计算机及相关专业的学生群体展开必要的讨论。

面向CS/EE领域的垂直搜索引擎主要针对计算机及相关专业的学生群体,因此首先结合调查问卷的统计结果阐释这一群体的信息搜索习惯。计算机及相关专业的学生群体,在学习和积累的进程中,必然会经历由初步接触语言的语法规则、数据结构和算法的阶段到熟练运用语言,并逐步参与到软硬件开发或领域研究的渐变过程。而根据此前交叉分析结果(0x0308),不同层次的学生群体对不同问题的需求不尽相同同时其使用的主要搜索渠道也不尽相同

因此,根据调查问卷的统计结果和学生的整体反馈做出如下的搜索习惯表格


学生群体层次


搜索内容


搜索渠道


刚接触语言的学生群体


基础库函数、专业名词等基础知识

其搜索方向主要包含基本的语法和常用术语


百度、谷歌等通用搜索平台,期望获得经验化的内容,而不是干巴巴的技术文档摘要


期望了解数据结构、算法等专业知识


基础库函数、开源社区代码

其搜索方向主要包含新接触的语言的基本的规则(如从Java转换到C#),优秀的代码片段


百度、谷歌等通用搜索平台仍在使用,但往往不会获取到预期结果

CSDN、Github等专业性强的社区,但内容参差不齐,而且部分社区屏蔽了百度的爬虫,导致通用搜索引擎完全无法显示其中内容


熟练运用语言,参与开发或研究


应用程序API、开源社区代码

其搜索方向主要包含软件开发过程中必需的API(最简单的如python的Numpy包),优秀的开源代码


百度、谷歌等通用搜索平台仍在使用,但获取内容往往局限于个人经验,无法保证正确性

Github、MSDN、StackOverflow等文档平台或专业问答平台更适合找到理想的结果

因此,根据调查问卷的反馈结果,针对不同类型的问题,百度和谷歌这类通用搜索引擎的使用率大部分超过70%,在所调查的用户群体中,占据极高的市场份额,但实际调研的结果却与庞大的市场份额有所出入

ü  (搜索的高质量)在计算机专业的领域搜索中,用户往往会优先选择“CSDN、MSDN”等平台提供的博客或文档知识,或各文库提供的课后习题答案、课程相关的其他课件,而通用搜索引擎却往往在其中掺杂很多的劣质回答,导致用户在搜索的过程中需要浪费大量时间做出不必要的筛选,如“百度知道”这种非专业平台提供的回答,简短的回答往往并不能真正解决问题,且平台上往往充斥着与问题无关的吐槽;同时,部分对博客园进行爬虫的“子网站”也会重复出现在搜索栏中,导致重复的内容集中在同一页中,使得通用搜索引擎的结果往往不尽人意。

ü  (信息的一体化)计算机行业是强调“终生学习”的领域,必然会在不同领域存在不同能力水平的用户,如上表所展示。而面向大众的通用搜索引擎却往往不能获得用户所需的切实内容。是选择专业的文档、或是基础简单的样例,取决于用户本身,不同的信息·渠道也面向不同用户提供了不同层次的回答,但单一的平台往往很难兼顾不同层次的用户。但这一过程中,换用不同的信息渠道会浪费大量时间,很可能导致事倍功半

ü  (用户的精准性)计算机行业是各知识交杂的行业,因此,部分搜索内容是具备标签化的(TAG)特征。而通用搜索引擎对计算机专业方面的标签管理混乱关键词关联不具备很强的逻辑性

因此,根据现有的用户调研,我们能够清晰地观察到搜索引擎和需求之间的落差,而在此用户需求上,面向CS/EE领域的垂直搜索引擎应运而生

0x0408 :做法( Approach )

网站本身的定位,是面向CS/EE领域的垂直搜索引擎。因此网站所注重的创新做法集中于“一体化”、“精准性”、“高质量”的三个主要关键词,因此从总体的架构角度,网站将具备采集专业化社区中的问答数据、收集高质量课程资源、关注专业技术文档的内容的功能,从而为用户提供一体化、精准的、高质量的搜索内容


搜索的高质量


从搜索的角度,优先搜索机制将保障问题和搜索结果高匹配度。简而言之,垂直搜索引擎将高质量的内容聚合,并针对某一类型的问题根据调查的反馈结果优先选择更为专业的搜索渠道,方便用户直接系统地浏览、搜索、编辑、评论,

同时,网站将支持用户继续通过提问、追问和回答来完善这些内容,保证优秀的用户体验

最后,通过“检测输入的模糊匹配”“检索内容的半自动化识别”“常见问题的文档支持”等方面,进一步打造高质量的垂直搜索引擎


信息的一体化


在一定程度上,信息的一体化和搜索的高质量密切相关,但信息一体化更展示的高质量数据的多样性。信息一体化更强调不同层次的数据一同展示,如在函数搜索的过程中同时展示函数的官方文档和民间给出的简单样例

因此,搜索引擎将高质量的内容聚合,并进行简单的层次上的分类,有层次地展示所获取的一体化的信息


用户的精准性


从用户群体的角度,计算机专业领域更适合基于Tag的搜索和数据分类。因此,在搜索数据上关联相关的Tag,将保证搜索的精准性。而对用户而言,基于Tag的问答平台,也将使得具备相同知识背景的人可以在特定的领域中分享知识,达到互利共赢的目的。当然,在这一层次上,我们也需要设置不同的权限,保证高质量提问和回答的用户能够具备更高的权限,使得付出与回报成正比

0x040c :好处( Benefit )

首先明确目前市场现实情况,随着信息时代与互联网的迅速发展,现有用户对产品的依赖度逐步呈现多元化发展,现有用户迁移成本相对较低,用户对产品的单一依赖度有所降低,而更多抱有“不管黑猫白猫,能捉到老鼠就是好猫”的心态,因此,由这一市场现状入手,本身存在着巨大的好处与发展空间。

        相比于通用搜索引擎,用户能够依据Tag的搜索机制更快捷地搜索到满意的答案节省在不同网站过滤无用信息的时间

        相比于通用搜索引擎,通过模糊匹配、半自动化识别等方式使得搜索结果更能适应不同层次的用户,且根据问题类型自动选择专业信息渠道,也使得搜索结果更为准确

简而言之,对于某一库函数F(X, Y, Z)的用法,能同时反馈官方文档的内容和讲义、网站给出的简单样例;同时,对于特定类型的错误,如编译报错信息,能选择更为专业的平台返回搜索结果

        精简、整洁的页面也将使得用户不会受到杂乱界面的困扰

        具备一定社交功能的问答平台,可将使得用户能够找到“相似标签”或是兴趣相合的伙伴。

图8:垂直搜索引擎的简单草稿(设计师绘制简单雏形)

0x0410 :竞争( Competitors )

从竞争的角度,首先不妨选取通用搜索引擎Google、垂直搜索引擎Codase、问答平台百度知道来解析面向CS/EE领域的垂直搜索引擎在竞争过程的核心竞争力


平台类型


通用搜索引擎


垂直搜索引擎


问答平台


平台代表


Google


Codase


百度知道


 

平台受众


Internet时代下对于互联网资源有需求的全体网民。


对主流语言的源码有需求或感兴趣的计算机及相关方向的学习者或从业人员。


对某一特定领域的相关问题不了解,希望得到简明扼要答案的网民。


 

 

 

 


l  信息整合导航,形式多样。内形式方面表现为视频、音频、图片、文字等。

l  资源内容丰富。网络上大量的资源都可以通过Google找到相关的内容。

l  查询效率高。极短的时间内查到数以万计的相关的网站和页面。


l  相关内容深度好。垂直搜索引擎诞生的意义所在,提供专业的相关的搜索。

l  内容之间的相关性强。内容的关联性强,属于同一或相近的学科体系。

l  查询准确率高。相关内容集成度大,知识密度大,容易迅速定位问题答案,极大提高查询的准确度。


l  针对性强。用户就某一特定问题进行提问,问题的准确描述容易获得。

l  互动性强。用户间交互与人机交互相比能给用户更好的体验,更容易实现问答之间的平衡。

l  群众基数大。百度中文搜索积累的数据资源吸引大量的网民使用这一平台,庞大的群众基础又提供了丰富的数据资源,形成良性循环。


 

 

 


l  资源冗余度大。网站页面的条目重复给出相同的查询结果的链接。

l  内容关联性弱。网页条目从根本上来讲还只是简单的罗列,没有内在逻辑。

l  查询准确度低。在纷繁的页面中查找想要的资源,即便是PageRank算法也难保证不费一番周折。


l  稳定性差,由于是国外的网站,国内的相关人员享受不到其优势。

l  交互性不足,用户还是需要自己主动查询和筛选,对用户的甄别能力要求高。

l  资源仅针对C++、java等主流语言提供查询,相关行业的其他领域知识涉及甚少。


l  平台的准入门槛低。回答的内容更多的是无关的吐槽,和问题本身关联性不大。

l  回答效率低下。不是每一个问题都能获得及时的回答,回答的问题有时也不能保证质量,甚至有误导。

因此,总体概述基本的竞争情况,Google、Codase、百度知道均在一定程度上支持了计算机及相关专业的信息检索,但由于用户定位层次的不同,导致搜索引擎本身难以保证EECS相关的内容和问答质量;同时,具备相同目标群体的垂直搜索引擎Codase由于资源的集约,导致网站本身交互性较差,且经常由于模糊搜索支持较差,导致大量的函数方法无法被有效检测。


l  Google搜索引擎利用其强大的资源优势保证了相关内容的覆盖率,却在准确率上不尽如人意。

l  Codase目标群体和资源相对集约,却难免交互性不足和资源局限的尴尬。

l  百度知道有强大的用户基础和良好的交互,却难以对问答的质量做出保证。

综合以上的分析,我们的产品应该具有的是准确的查询定位,高质量的专业资源,丰富的专业内容,齐全的专业门类,高效的用户交互平台,成熟的用户激励机制,完善的准入考察机制

综合以上的分析,我们的产品应该具有的是准确的查询定位,高质量的专业资源,丰富的专业内容,齐全的专业门类,高效的用户交互平台,成熟的用户激励机制,完善的准入考察机制。

因此,论述产品的核心竞争力,集中在数据的管理形式和明确的用户定位。标签(Tag)方式关联的数据,其本身又包含多种类型的信息,能够高质量地展示搜索数据;同时,明确定位于计算机及相关专业学生也将最大程度保证搜索的精确性。

0x05SWOT分析

I am a slow walker,

but I never walk backwards.


优势

(Strengths)


劣势

(Weaknesses)


ü  在技术优势上,垂直搜索引擎支持模糊匹配和半自动化识别等搜索技术,用户体验更为优质

ü  垂直搜索引擎全面基于Tag的多类型数据分类,一体化的设计也将保证搜索结果优中择优,反馈的查询结果更为精确而全面,能有效针对不同层次的用户

ü  架构上包含完整的安全维护措施和反垃圾机制,能够有效减轻无效的访问压力

ü  开发团队本身又是用户的一部分,类似“人类学调查”机制,开发团队本身更能深入用户本身的不同需求

ü  初步设计页面整洁大方,用户搜索时不会受到冗杂信息的干扰


ü  数据本身依赖其他组的工作进度,而在进度上需要密切同伙伴组沟通接口、数据来源、数据分类等细节

ü  敏捷开发时间较短,需要时刻保证高效率的开发进度

ü  缺乏充裕的资金支持


机遇

(Opportunities)


威胁

(Threats)


ü  与同类搜索引擎相比,具备更为优秀的功能和高质量的搜索结果

ü  类似“人类学调查”的机制,作为大学生的视角更能切合学生用户群体的使用需求

ü  软件开发过程中,学校及学院将提供硬件上的支持

ü  互联网本身的特点导致用户迁移成本大大降低,且用户也更为依赖网络检索功能


ü  同类搜索引擎的不断整合,可能导致其他搜索引擎快速构架出类似网站形成基本的竞争关系

ü  用户的等级分配权限制度可能降低新用户的积极性

0x0504 SWOT矩阵分析

此部分的矩阵分析正在架构中,而SWOT在竞争分析中也注重SO、WO、ST、WT策略的设置和不同阶段的不同竞争方式。

0x06:功能定位和优先级草稿

If you have a friend who knows your heart,

Distance cannot keep you two apart.

这里暂且将产品经理初步架构的功能定位和优先级规划罗列出来,其中【】中包含的字符*越多,代表其需要实现的优先级越高,而关于杀手功能、外围功能的界定,暂时依据星级评判标准,而具体的规划,还需要在此后的讨论中进一步明确和完善


垂直搜索引擎的建设


基于Tag以及类型的数据分类【***】

对用户检索输入进行模糊匹配【***】

用户检索内容类型的半自动化识别【***】

针对问答数据、课程资源、常用专业官方文档中函数的检索分别建立支持【***】


基本的用户管理模块


注册、登陆、注销等基本管理模块【***】


问答平台的构建


问答数据的展示【***】

用户对问答的评论或跟帖与原社区进行关联【*】


优秀课程资源


将其他组获取的数据资源进行展示【***】

+ 课程的来源,视频链接

+ 课程讲义

+ 参考资料

支持用户留下自己的学习笔记和心得(注意隐私权限)【**】

设立讨论区进行交流【*】


用户资源的共享


用户能够自主上传或撰写课件、笔记心得等内容【**】


丰富用户功能


完善激励模式(用户积分系统、高积分鼓励措施、与优质网站的积分转换)【*】

增设好友、同学、师生、兴趣组【*】

增加与社交网络的关联手段,为系统的生存发展推广做考虑【*】

推荐系统及偏好分析【*】

0x07WBS基础构建

I wrote a sign called "Dead End" in front of myself,

but love crossed it with a smile and said ,

"I can enter anywhere"

 

0x08:附录与后记

1 universe, 9 planets,

204 countries,809 islands, 7 seas,

and i had the privilege to meet you.

写到后记,莫名思路滞塞,不知从哪里记述这短暂一周时间的讨论,若单纯凭着吃货的执着去记录这短暂一周的工作,深夜热腾的馄饨铺、新主楼露天的水果披萨、必胜客中冷热交加的柚子蜂蜜柠檬茶,或是莫名从大洋彼岸发来的调查问卷反馈数据;感觉能始终凭借这样的依托和动力继续前行,内心,大抵,也会不自觉地充满夏意。就用《你好,旧时光》中自己时常写在明信片或是信的底部的一句话,谨以此寄予BugPhobia般的团聚吧:一如既往,万事胜意

你好,BugPhobia,安好~

时间: 2024-10-05 04:45:12

BugPhobia启程篇章:需求分析与功能定位的相关文章

BugPhobia开发篇章:Alaph阶段Scurm Meeting

0x01 :目录与摘要 If you weeped for the missing sunset, you would miss all the shining stars 索引 提纲 整理与更新记录节点 起始记录时间 终止记录时间 0x01 目录与摘要 初次整理于2015/10/23 2015/10/23 12:00 A.M. -- 0x02 Alaph阶段第一次Scrum Meeting 初次整理于2015/10/24 2015/10/23 12:00 A.M. 2015/10/24 12:

BugPhobia进阶篇章:功能规格说明书

0x01 :特别鸣谢 首先特别鸣谢<构建之法>中并没有给出固定化格式的功能规格说明书的样例,因此在此次的说明书中将尽可能用生动形象的例子展示软件交互阐释 因此受到它本身的启发,此次团队功能规格说明书尽量用活生生的例子讲述用户和软件交互的场景,并且力求语言的简洁和直白 最后,再次鸣谢bugphobia团队本身的创造力,最终没有局限在模板中,而是能在讨论中共同挖掘出非常欢酷的想法 0x02 :前置条件阐释 0x0200 :定义 <摘要>依据康德理性批判“澄清前提,划清界限”的指导思想,

BugPhobia准备篇章:团队Beta阶段准备工作分析

0x00:序言 To the searching tags, you may well fall in love withhttp://xueba.nlsde.buaa.edu.cn/ 再见,无忧时光~ 0x01 :Beta阶段会议记录(2015/10/24) 特别说明:Beta准备阶段的会议(2015/10/24~2015/12/07之间的全部会议全部不计入Scrum Meeting,实为准备阶段的集体讨论) 会议记录Github传送门:Beta阶段会议记录过渡阶段)(20151024).md

BugPhobia休息篇章:Beta阶段第IX次Scrum Meeting前奏

特别说明:此次Scrum Meeting不计入正式的Scrum Meeting,因此此次工作仅为第IX次Scrum Meeting的前奏,而笔者也首次采用休息篇章作为子命题   0x01 :Scrum Meeting基本摘要 Beta阶段第九次Scrum Meeting前奏 敏捷开发起始时间 2015/12/23 00:00 A.M. 敏捷开发终止时间 2015/12/26 23:00 P.M. 会议基本内容摘要 ü  近期,由于12月23日至12月26日各专业课程均进入了收尾工作而导致软件工程

四则运算需求分析和功能实现--杨宇杰

四则运算需求分析和功能实现 一.基本要求 1.编写小学四则运算测试系统,要求完成两位数以内(包括两位数)的加,减,乘,除四则运算.下述所有四则运算表达式均需随机生成.使用参数能够控制生成题目的数量. (例如:12+6+7=?3*4*6=?) 2.能根据用户的输入来选择运算种类(例如:加法运算.减法运算....),让程序能接受用户输入答案,并判定对错. 最后给出总共 对/错 的数量.程序一次运行生成的题目不能重复,即任何两道题目不能通过有限次交换+和×左右的算术表达式变换为同一道题目.例如,23

软件工程启程篇章:C#和四则运算生成与运算

0x01 :序言 I leave uncultivated today, was precisely yestoday perishes tomorrow which the person of the body implored “看不清楚的时光印痕,像是泛黄的底片,明明还记得那个故事,却忘了故事里的风月”,不知如今因为生成规则.词法排序或效率而争执地面红耳赤的少年们,多少岁月走过重新翻阅看着七零八落的注释和代码段,是否只得慨叹岁月这把最锋利的杀猪刀,然而,即便最终能停留在代码段的注释行不过寥

BugPhobia开发篇章:Beta阶段第I次Scrum Meeting

0x01 :Scrum Meeting基本摘要 Beta阶段第一次Scrum Meeting 敏捷开发起始时间 2015/12/10 00:00 A.M. 敏捷开发终止时间 2015/12/12 23:00 P.M. 会议基本内容摘要 ü  Beta阶段第一次Scrum Meeting主要总结准备阶段的工作安排,同时就此前由于编译课设目标代码生成而拖延的进度任务进行了基本的审核和说明,在沟通方面解决了和PowerTeam之间的协商问题,决定采取Solr框架提供的搜索机制,并针对部分需求进行了更改

BugPhobia开发篇章:Beta阶段第VII次Scrum Meeting

0x01 :Scrum Meeting基本摘要 Beta阶段第七次Scrum Meeting 敏捷开发起始时间 2015/12/19 00:00 A.M. 敏捷开发终止时间 2015/12/21 23:00 P.M. 会议基本内容摘要 ü  考虑到周六的英语六级考试和周日的CCF认证考试,因此第七次Scrum Meeting期间各开发组的成员可以依据具体情况进行停工或正常开发,而在此期间项目经理将不进行进度的监督或干涉,因此此次Scrum Meeting重点在于整理项目缓工期的工作进度,并重新调

BugPhobia开发篇章:Beta阶段第IV次Scrum Meeting

0x01 :Scrum Meeting基本摘要 Beta阶段第四次Scrum Meeting 敏捷开发起始时间 2015/12/16 00:00 A.M. 敏捷开发终止时间 2015/12/16 23:00 P.M. 会议基本内容摘要 ü  在前端方面,ReactJS开发正式进入转折期,此次讨论的过程中各任务基本处于阻塞状态,主要原因在于ReactJS对javascript本身做出了大量布局和实现效率的限制,同时jQuery的document字段也被严格限制,因此整体的开发进度相对较慢,此次Sc