2018年软工第一次结对作业

引子

愈是敏感，愈是胆怯，愈会企盼暴风雨降临得更加猛烈 ——《人间失格》

本次作业
结对同学博客
PDF

• 结对构建之法学习小记

https://www.cnblogs.com/031602523liu/p/9683382.html
https://www.cnblogs.com/031602523liu/p/9683388.html
https://www.cnblogs.com/tomvii/p/9683381.html
https://www.cnblogs.com/tomvii/p/9683385.html

NABCDM模型——完善化用户需求

• 通读《构建之法》第八章以后，我们在感叹 “NABCD” 模型的同时，也对需求的合理化产生了一些思考——需求文档的确立中不需要考虑软件的维护问题吗?仅仅依靠创新的做法、优秀的推广可以说服客户吗？
• 来对比一下以下的两段话...

  • 我们的产品——论文检索平台是为了解决小樱等高校大学生的痛苦，他们需要<Need>——有效的论文检索工具来检索、总结，但是现有的产品并没有很好地解决这些需求。我们有独特的办法<Approach>——结合论文检索与热点词频统计为一体的检索平台、OCR识别翻译论文原文来解决需求，它能给用户带来好处<Benefit>,远远超过竞争对手<Competitor>。同时，我们有高效率的<Delivery>方法,能很快让目标用户知道我们的产品，并进一步传播。

  • 我们的产品——论文检索平台是为了解决小樱等高校大学生的痛苦，他们需要<Need>——有效的论文检索工具来检索、总结，但是现有的产品并没有很好地解决这些需求。我们有独特的办法<Approach>——结合论文检索与热点词频统计为一体的检索平台、OCR识别翻译论文原文来解决需求，它能给用户带来好处<Benefit>,远远超过竞争对手<Competitor>。同时，我们有高效率的<Delivery>方法,能很快让目标用户知道我们的产品，并进一步传播。最后，我们有完善的维护<Maintainence>与更新机制，随着客户需求的变更以及市场驱动的导向，能够逐步改进和完善我们的软件

    修改自《构建之法》 Page-171

• 可以很明显看出这两句话的差异，按部就班地分析需求毫无疑问是一件好事情，但是有条理地说服客户往往会决定软件开发的走向。任何一个好的软件都是存在时效性的，就当前来看或许某某软件满足了客户的诸多需求，随着市场的变动、竞争的不确定性以及用户需求的日益增长，这样一个功能齐全的软件也很难持续性地给用户带来良好的体验。
• 以一个曾经霸占了整个中国互联网下载市场的软件——快车为例，过去，快车迟迟没有推出 P2P 技术亦或是其他技术更新，而当时迅雷快速地启动了 P2P 技术进一步霸占了市场。
• 难道最开始的 “快车” 不具备 “NABCD” 的任何一项特质吗？这个软件很大程度上没落的原因就是 “维护” 问题，定期、合理的维护带给一个软件的收益丝毫不比 “NABCD” 中任何一个特质差。这也是我们提出对这个模型进行改善的原因。

Need——需求

• 小樱是一名大三的学生，急需一个论文检索工具来完成检索到的论文的分析和总结。具体的需求可以细化为以下几个部分：
• 基本需求
  • 通过对论文列表的增删改获取指定论文的具体信息，包括标题、摘要、原文链接。
  • 检索的同时获取论文作者主页、及源代码(如开源)。
  • 再通过对获取的信息进行结构化处理——筛选论文属性及形成热词图谱。
  • 最后进行数据统计呈现热度走势对比。
• 附加需求
  • 提供论文分享的社交平台，考虑到客户的个人背景——沉迷吃鸡游戏，可以通过论文中的社交平台，在与其他论文读者的交流中获取更多论文相关信息，还能以此为基础实现论文推荐功能。
  • 最后，提供了OCR翻译功能，直接扫描PDF给出论文翻译。(示例如下所示)

Approach——做法

• 基本需求的做法

  • 我们设计的系统主要应用于Web端，分设管理员与用户账号来实现管理论文检索工具，这里提供了如下几个方案来应对上述需求。
  • 首先，在用户登录界面之后，可进行添加检索条件来进行具体的论文指定，经过本软件检索后得到的论文也可通过下拉按钮功能展现论文的具体信息。
  • 检索中获取的作者主页及源代码也可通过论文具体信息中的延伸资料来实现拓展，以体现原作者的著作权。
  • 关于信息的结构化处理可以采用生成图表的方式来达到数据可视化的效果，也可就图表进一步对可视化信息做出筛选进而充分利用结构化数据。而相对于最后的数据总统计，具体实现方式可以采用类似于hashmap的方式以极快的速度完成统计图以及热度走势图的生成。

• 附加需求的做法

  • 论文分享的社交平台可以结合类似朋友圈、动态的形式来分享阅读的论文，提供一个论文读者间的交流平台，也能借此平台达到论文推荐、技术交流的功能。
  • 由于大部分检索工具很少提供给用户一个交流平台，使得用户无法将论文中收获的知识和基于论文改进的idea及时分享与发布，只能选择类似择日整理通过其他平台类似于博客的形式分享自己的所得。所以本软件添加了这个看似多余的功能其实也是为了提供一个实时分享的途径。

• 计划实现的流程图如下图所示
  

Benefit——好处

• 固有好处
  • 由于采用精简但有效的实用模块构成论文检索的筛选条件部分，使得本软件在实现检索的过程中不会获取到过多的无用信息，提供结果的同时也可根据用户需求附加论文作者相关的延伸阅读，并且提供历史记录的功能——供用户参照历史阅读。
  • 同时根据已经获取的论文列表形成热词词频——以扇形图和直方图形式给出,将可视化数据直观展现给用户，并且提供可视化词云的方式。
• 扩充功能
  • 单一的论文检索工具很难吸引用户使用，我们为此添加了社交平台以供技术交流，当然为此我们需要考虑到用户的迁移成本，现有的很多平台例如博客园都已经提供了很完善的技术交流平台，所以这项功能个人认为显得有些 “鸡肋” 。
  • 但是最终还是采用这个功能是考虑到了及时性的原因，本软件也可以在检索、阅读论文的同时，及时写下、分享自己对论文的理解，以这一种——论文阅读与分享心得捆绑一体的形式也是我认为这个软件所提供十分有益客户的一点。
  • 由于存在部分论文都是以外文形式展现，若是直接把文字翻译，还需对照论文上的思维图对照观看，这样不仅效率低下而且存在易错性，所以本软件提供OCR+翻译功能。(具体如下图所示)
    
    实现上可能有些复杂，若要求实现会可以考虑CRNN实现端到端OCR+爬虫百度翻译

Competitors——竞争

• 考虑到竞争市场，我想先谈谈 “先发优势” 和 “后发优势”
  • “先发优势”——先进入市场的产品会使得用户形成在先发软件上的习惯，同时需要额外考量迁移成本。
  • “后发优势”——后进入市场的产品可以在先进入市场的产品上做出改进，更好地满足用户需求。
• 举个简单的例子，以博客发表的先后来当做先后进入市场的产品，先发的产品当中也有很多具有很优秀的功能，也具有“把握”住用户的能力——迁移成本，当然像本篇博客这样构思时间偏长，后发表的也不一定就存在劣势。
• 优势和劣势均是属于相对的，后发软件也可以综合先发软件的缺陷并且提供创新思路，所以软件在考量这两种优势的同时不能一概而论以为先发软件就一定占据绝对优势。我们这篇在deadline发表的博客也能提供不一样的阅读体验
• 假想竞争对手
  • ① 以其他同样完成结对作业的同学为假想竞争对手，由于我们的软件提供了维护的功能——M，个人认为一个维护有保障的软件产品在面对客户需求上完全不输于其它看似功能性完备的产品。我们的软件产品可以通过有效、规范的维护更新制度完成良好的产品输出，并且能持续性给用户带来更佳的体验。
  • ② 若是不巧，相较于同样于同样也为客户提供维护功能的团队，则进一步转入各自软件的功能上的竞争，这里我们可以回头看一下小樱同学的需求——希望借用软件完成论文检索与分析，希望能在毕业前完成一篇站在时代前沿的优秀论文，我们的客户小樱并不是只想获得论文统计、了解哪个领域热门、哪个学校论文发的多。我们需要考量到用户的最终需求。
  • 既然小樱希望能够发表一篇优秀论文，那么小樱也必须需求大量的论文阅读以提升自己，说到这里就体现出来本软件附加的核心功能——OCR+翻译功能，借用此功能可以为用户提供极佳的阅读体验，以这种独特的功能来满足用户需求。

Delivery——推广

我们将推广思路分为三个阶段——初期、中期、上升期

• 推广的初期在学校内的几大实验室宣传，针对于类似于小樱且主要研究方向为计算机视觉领域的福大学子，根据他们的反馈信息，对软件进行进一步的迭代更新。完善功能。接下来推广到大学城内其他几所高校，进行下一步的更新和迭代。
• 进入到中期，积累了一定的用户量和功能完善，我们计划在论文检索平台中加入其他领域的顶会论文收集功能，相当于对论文库的扩充，可以借用原先的客户流量来完成进一步推广。
• 有了以上的基础，则进入软件的上升期，增加一些互动功能比如：优质论文分享，作者经验分享，论文批改等等功能。大家可以互相促进，甚至会结识志同道合的伙伴一起合作一篇论文，共同走向顶会的巅峰！借用这类高质量的功能让用户口口相传，可以在客户分析内容的同时结尾带上本软件产品的宣传标语。

Maintainence——维护

原有的 “NABCD” 模型已经足够让人惊艳需求分析的条理性，也一定是经过多次推敲后得出的模型，私以为按部就班地分析需求的固然有为实现功能绘出蓝图的目的考量，但也是在一定程度为了以一种更好、更简明的方式展现出项目的特点。提出一个创新的点子相当于蓝图的构思，但是如何说服他人采纳你这个点子则又等同于蓝图的绘制。构思固然是扬帆起航的美好冀望，但是再美好的远航冀望也需要航行的方向——绘制蓝图 。
基于现有的 “NABCD” 模型，我们可以很好地说服他人采纳我们的idea，但是可否考虑到每个人均以这种方式来进行需求分析呢？是否可以在原有的需求分析上做出些许改进达到更好的效果呢？

• 为此，我们在提供一套完整的从需求考量到推广产品的完善体系的同时，也想要给客户提供一个不断 “涌入新鲜血液”——不断更新迭代的平台，而不是一成不变的单色格调般的平台。
• 作为软件生命周期的最后一个阶段——维护在重要性上丝毫不比开发差，在提供描述软件项目特点时，用户也更愿意接受一个有固定、规范的更新维护流程的软件产品，也能更完善整个需求分析过程，并且可以借此形成需求分析文档，同时提供一个过程性的实现、维护流程供技术人员参考。
• 这里还行延伸一些自己对于维护的体会——私以为维护不单单只是完成bug修复、软件产品升级改进等事务，更是向用户表现软工团队对既成品软件的重视，通过一次次的维护也能建立起团队与用户间的信息反馈机制，提升客户对软件的忠诚度。

原型实现

• 登录界面
  (用户划分为普通用户与管理员)

• 论文检索界面
  (提供待筛选条件的论文检索)

• 热词分析图谱
  (热词数据可视化) 可借由个人作业1实现

• 个人中心
  (提供历史记录统计及检索)

• 用户管理界面
  (个人信息编辑以及密码修改，并且可发布个人动态信息)

• 高校热点界面
  (统计各高校近十年论文发表数目，并分析该校强势研究领域)

• OCR翻译界面
  (实现OCR扫描PDF+翻译功能，提供优质论文阅读环境)

结对过程

• 作为合作多年的难兄难弟，经历了无数次的大风大浪，经过不断的磨合，终于软工实践又给了我们俩这一次难得的机会。

• 这是我们讨论的草稿。团队急需美工外援

设计说明

• 我们的软件主打检索、分享与实时OCR翻译，实现一个三位一体的用户检索平台
• 以下为我们软件的思维导图
  

遇到的困难及解决方法

困难描述	尝试解决	是否解决	有何收获
原型工具的选择	尝试Axure Rp、Prototype Composer、墨刀	是	分析了上述三个软件的优劣，Axure Rp界面设计复杂度太高，以及学习时间成本比过低； Prototype Composer提供了完整的集成环境，可轻松进行设计，但是设计界面过于简陋，用户亲和度过低； 最终采用墨刀，短小精悍的国产工具集成了复杂的功能以及支持富文本功能的文字处理。
对NABCD模型的困惑	根据需求分析与现实应用间的差异性，扩充既有模型。	是	解决问题不一定要按部就班地照标准模型进行，可以在既有模型的概念基础上，添加自身的思考与体会，打造出更适合团队实际应用的模型
钢铁直男的审美	尝试邀请美工“大触”	否	直男毁一生，美工“大触”都不屑跟我们合作

PSP表格

psp3.1	personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	20
Estimate	估计这个任务需要多少时间	20	30
Development	原型开发	120	150
Analysis	需求分析（包括学习新技术）	60	40
Design Spec	生成设计文档	15	25
Design Review	设计复审	20	10
Coding Standrd	代码规范（为目前的开发制定合适的规范）	0	0
Design	具体设计	30	25
Coding	具体编辑	0	0
Code Review	代码复审	0	0
Test	测试（自我测试，修改代码，提交修改）	30	30
Reporting	报告	210	300
Test Repor	测试报告	10	5
Size Measurement	计算工作量	30	20
Postmortem&Process Improvement Plan	事后总结，并提出过程改进计划	20	15
-	合计	595	670

结对学习进度条

• 以下耗时均以两人总和时间为计。

第N周	新增代码（行）	累计代码（行）	本周学习耗时(小时)	累计学习耗时（小时）	重要成长
1	300	300	18	18	原型设计，爬虫关于python的urllib库及request库学习
2	0	300	8	26	钢铁直男们的审美进步“一点点”

作业感想

共同感想：

• 本次作业跟队友探讨了“NABCD”的优劣，并且在此基础上，结合了生活实际的应用，总结出了“NABCDM”模型。在本次作业中。
• 私以为作业给出的范例只是起到引导作用，关键在于引发我们的思考。对于循规蹈矩的完成既定规范内容显然不是我的队友和我想要做的。
• 作为这次结对作业的一个起始符，希望今后能跟我的钢铁直男队友可以天长地久。

2018.09.20