软件工程实践结对编程作业（需求分析与原型设计）

这个作业属于哪个课程	软件工程2020秋学期
这个作业要求在哪里	结对编程作业（需求分析与原型设计）
这个作业的目标	学习软件需求分析及原型设计，掌握相关工具，熟悉 GitHub 协作
学号	031802112, 031802113

目录

• 结对成员
• NABCD 模型分析
  • Need（需求）
  • Approach（做法）
  • Benefit（好处）
  • Competitors（竞争）
  • Delivery（推广）
• 原型图
  • 注册及登录页
  • 首页
  • 消息列表、聊天界面、通知列表
  • 动态发布
  • 查找
  • 实验室简介
  • 个人简介
  • 我
  • 权限管理
• PSP 表格
• 结对过程概述
• GitHub 协作练习
• 总结
  • 031802112 黄泷
  • 031802113 黄明浩
• 附录

结对成员

031802112 黄泷 博客地址

031802113 黄明浩 博客地址

NABCD 模型分析

Need（需求）

学长学姐去哪儿——了解实验室或社团历史上的那些学长学姐们的去向和现状

了解实验室学长们去向的现状：

除了实验室群里长期潜水或偶尔冒泡的学长、导师口中的零星去向、临近的学长，似乎就无法了解了。好久以前的没见过的学长们，去了哪里。这不仅仅是是否选择这个实验室的依据之一，还是今后找工作的内推的重要支柱。可惜现状就不是很明确和了解，知晓的渠道也很有限。

学长们其实也很想了解学弟们现在在做什么研究，有没有什么擅长的技能，比如会某个研究方向或数学建模技能的，也很希望能帮忙协助内推，比如这位学长，就只能给我发消息，也无法有效传递。

另外，建一个实验室群，也不是很方便，因为在群里，你也不好意思经常问：学长们，你们在哪啊。

甚至，等你工作了，和你同一个公司或一个组的同事，可能就是实验室同门，你们都相见不相识，多遗憾。

需求简单总结如下：

• 毕业学生

  • 希望了解实验室与导师的近况
  • 希望让学弟学妹知晓公司的内推情况，给予学术和生活上的建议、帮助

• 在读学生

  • 希望在未来的学习和工作中得到学长学姐老师的建议、帮助
  • 为选择未来导师、实验室提供一些参考资料
  • 了解实验室毕业后学长学姐的工作方向

• 导师

  • 了解毕业学生的去向以及现状
  • 了解有意向加入实验室的学生，包括特长、技能等
  • 能够更好更便捷地管理实验室

Approach（做法）

经过对客户需求的分析，我们认为，相比普通的微信、QQ 群聊或私聊，客户需求的特点在于方便、快捷、准确地获取特定的信息（如学弟学妹的技能、学长学姐的去向，都是相对固定的信息门类），且要尽量减少不必要的打扰以避免尴尬。因此我们最初曾想过避开社交的环节，做一个信息管理与查询的应用。

但我们很快发现，交流是绝对不可避免的，人不是机器，减少打扰不应该被曲解为不考虑沟通交流。正如不管简历做得再漂亮，面试都是必不可少的。而且只制作信息查询功能的话，功能过于单薄和片面，用户平时很难有动力打开我们的应用。而我们需求的信息是有时效性的。如果用户几个月甚至一两年才打开一次软件，很难想象他们会及时维护和更新相关的信息。所以我们还是选择了做一款泛社交的应用。具体形式方面，结合当下人们的使用习惯，我们选择了移动端。同时考虑到小程序虽轻便、简洁，但其依托于微信、QQ，社交关系还是要建立在平台自身的好友上，其他限制也比较多，因此我们认为开发独立 app 比较合适。

我们最终确定，设计一款兼顾数据信息分享和社交沟通的校园分享型 app，其中的信息主要包括上述需求中用户希望获取的信息。

针对各项客户需求的解决方案：

• 了解实验室毕业学生、在读学生、导师的近况
  • 认证为实验室成员后，可以在实验室主页或通讯录中找到所有已加入的实验室当届及往届成员的个人资料进行浏览。
  • 实验室主页也会实时更新实验室及成员的科研、竞赛动态等。
  • 在对方权限设置允许的情况下，可以通过 app 内私聊或其他通信方式进行沟通。
• 内推相关事项
  • 已毕业学长学姐可以在实验室主页或通讯录中找到学弟学妹的个人资料进行浏览。
  • 如果看过资料后认为合适，可以直接向学弟学妹发起私聊（同样需考虑对方权限设置，默认允许）。
  • 如果想公开发布内推名额，可以在发布动态时选择“内推招聘”标签，并选择权限（实验室成员或同专业学生）。目标会在首页看到相关信息，并可一键发出申请。
  • 当然，也可以选择直接在实验室群聊中发布相关信息。
• 低年级学生了解实验室
  • 直接点击界面下方“实验室”按钮即可看到本专业实验室列表。
  • 点击其中一个实验室即可看到实验室研究方向、科研成果、地址、成员等基本信息，并可一键咨询负责人。
• 身份认证、权限、隐私管理相关
  • 关于注册用户认证，比较理想的做法是对接学校教务处网站或统一身份认证平台，使用学号、密码认证。
  • 但上述接口可能不容易取得，有密码泄露的风向，且毕业生不好认证。因此若无法进行上述认证，我们要求用户在注册时填写真实姓名和学号。通常情况下并不进行验证，但若注册时学号出现重号，我们会要求上传学生证照片并由系统管理员人工审核。
  • 加入实验室则需要实验室导师或得到授权的学生管理员进行审核，或直接由他们邀请也可。
  • 个人资料中各项目以及发送动态可见性都可以在权限设置中逐一调整（动态可以逐条选择，总设置与单条动态设置冲突时以较严格的为准）。为了方便，也设有默认值。

Benefit（好处）

• 该 app 主要面向大学生，主要是解决在校学生与毕业学生之间沟通难的问题，能够实现学生与学生之间的准确定位，并且针对性较强，能够快速地认识同专业的学生并快速地建立交流。在现有市场的 app 中，较少产品能够针对性地解决这一问题。
• 该 app 具有根据不同用户推送不同信息的功能，针对性地给用户提供其潜在需要的信息（例如在校学生推送企业内推信息、学习计划、各种考试资料等，毕业学生则推送同级学生、母校趣事等）。虽然市面上的APP都有针对性地推送，但我们的产品可以更加纯粹地服务于用户，推送信息的有效性和可利用性更好。而不是恰饭式推送！同时该推送功能用户可以自己调整推送信息的方向。
• 该 app 同时具备实验室展示和聊天功能，该功能有利于实验室的纳新宣传以及实验室内部的网络通信，可以让导师更好地管理实验室。同时让在校学生更好地、更多方面地考虑未来实验室和导师的选择。
• 用户可以根据自己的意愿来设置信息展示分享的权限，不是一刀切、一锅煮式，而是对于每一类、每一条信息，用户都可以设置其权限。该功能有利于保障用户信息的隐私性和相对封闭性。

Competitors（竞争）

我们的优势：

• 清晰呈现学生、导师、实验室的有关信息，方便快捷，减少不必要的打扰，契合客户需求。
• 实现基础需求，适度拓展功能，提供完善而不臃肿的用户体验。
• 相较微信、QQ，圈定了社交的范围，专注校内实名社交，辅以清晰的权限管理，兼顾隐私性、安全性与便捷性，同时减少其他信息的干扰。
• 相较网课类软件，更希望师生基于自发需求而非课程强制来选择使用，因此事务属性相对较弱，更能鼓励师生在平台上自发分享。

我们的劣势：

• 相较专业团队，我们的开发精力和经验都非常有限，功能完成度和稳定度可能都比较低。
• 通用的社交 app 已经非常成熟，用户基数大，我们很难仅凭几个亮点功能留住用户。
• 界面设计和交互设计比较一般，不够吸引人。
• 由于精力、能力和政策限制（社交类 app 需要相关许可证方可上架），我们只能做 Android 版本，不能服务所有目标客户。

Delivery（推广）

• 向认识的老师与同学及熟悉的实验室推荐试用。
• 在微信朋友圈、QQ 空间、群聊、微博等转发推广。
• 通过扫楼、发放传单等方式线下推广。
• 社交类产品还是要靠用户实际体验说话，因此我们鼓励产品最终用户宣传推广。

原型图

我们采用了 墨刀 MockingBot 作为原型设计的工具。

原型体验链接：https://modao.cc/app/6ae3d3f2eb6d54a6460a13976a9c13ac53744996?simulator_type=device&sticky

（功能尚不完整，且目前全为静态页面）

注册及登录页

• 登录框内可输入学号或手机号，也可使用微信或 QQ 关联登录。
• 注册时需选择身份，并填写必要的实名信息。之后 app 页面会因为用户身份而有所不同。

首页

• 首页上方醒目位置显示重要通知，包括内推消息、实验室通知、待办任务、好友申请等，左右滑动可以显示最近几条重要通知，点击可以进入通知列表。
• 中间部分按四大专题分门别类设置社区入口，专业生活两不误，更有针对性。
• 下方按用户个人设置以瀑布流形式进行综合性推送，可以供用户在闲暇时间浏览。

消息列表、聊天界面、通知列表

• 消息列表页与一般聊天软件相仿，但通知、签到、通讯录、实验室群默认置顶。通知与首页入口指向相同，因为是重要信息，交互上做了一点冗余。
• 聊天界面里点右上角即可查看个人消息。
• 通知列表中可以进行简单处理，点击消息查看详情，按右上角“管理”按钮可以删除。

动态发布

• 界面上和大多数社交软件都差不多。
• 标签默认有四个项目：内推招聘、技术交流、校园 Q&A、生活分享。
• 关于“提醒”功能，内推招聘可以作为重要消息批量推送到全实验室学生或特定年级同专业学生，在对方首页及通知列表上显示。技术交流与校园 Q&A 也可以批量推送，但只会在对方 @我列表中显示。生活分享只能逐个 @。这样能尽量减少对用户的打扰，同时也不漏掉重要信息。
• 权限设置比较灵活，但有默认值：内推招聘为本实验室可见，技术交流为本专业可见，其他默认为全校可见。

查找

• 查找可以将找实验室和分开。
• 查找页默认列出了本专业的实验室和用户，有特殊需求的学生可以通过界面上方筛选功能查看其他学院信息（确实在现实中有碰到其他专业学生来数计的实验室）。
• “研究方向”筛选栏列出了本专业常见的研究方向，便于快速筛选。如果不全可以使用上方搜索框。
• 搜索框除了研究方向、实验室名称，还可以搜索导师姓名、成员姓名、成员去向、竞赛名称等各类信息。

实验室简介

• 实验室简介页展示了实验室的研究方向、科研竞赛成果、地址、成员等重要信息，便于学生了解。点击各成员头像可以看到他们的信息（信息多少视权限设置而定）。
• 如果觉得有兴趣，可以在页面底部一键咨询负责人。
• 在现实中完成加入实验室手续后，可以点击申请加入等待审核，或通过扫二维码等方式让导师及学生管理员邀请加入。审核时必须提供实名信息，保证安全。（我们 app 只是交流分享平台，不能替代现实中的手续）

个人简介

• 从找人界面、实验室中成员列表，以及聊天中个人信息按钮都可以进入。
• 界面项目根据用户身份稍有不同。
• 上方列出关键信息，中部放置添加好友等常用操作和最新动态，下方列出联系方式和教育、工作经历等（同样遵循权限设置）。

我

• 该页集成了个人信息修改、权限设置、推送设置等设置板块。
• 一般的动态回复之类较不重要的提醒可以从该页进入查看。

权限管理

• 为了确保隐私性和安全性，隐私设置项比较详细和精确。
• 为避免过于繁琐，我们设置了“一键设置”按钮，用于将所有项目统一设置，再更改个别项目。
• 一般情况下可以不用特别设置，默认值可以满足大部分需求。

PSP 表格

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

结对过程概述

我们俩是舍友，都选了这门课，就自然结对了。我们在任务布置头两天先初步分析了需求，并利用零散时间学习原型设计工具的使用，中间也不断对需求进行部分修改。大概到上周日我们完成了界面框架，之后就是微调交互和完善博客。

GitHub 协作练习

我们先后尝试了两人操作同一仓库以及一方 fork 再 Pull Request 的协作方式。

总结

031802112 黄泷

在看构建之法时第一次听说结对编程这个概念，经过本次的结对作业，加深了我对“结对”的了解。同样经过结对过程，我对本书中讲述的原型分析有了更深刻的理解。从一开始的独立思考到相互讨论用户需求、沟通软件定位、确定软件功能，再到交换设计原型图，最后队友之间的默契配合，这一系列结对过程，让我慢慢感觉到了软工作业的快乐。？emmmm 虽然中途也有设计的分歧，但是往往二者结合体才是最好的。个人认为以下几点是软件原型设计时的重要注意点：

• 在着手实践前，对于市场的调查十分重要以及 NABCD 的撰写，千万别问我为什么！因为一边画原型一边完善 NABCD 非常的痛苦，同时这对后期软件的用户满意度和竞争力起着至关重要的作用，你的软件生命力是否顽强取决于你是否考虑用户的需求和软件本身的独特之处。

• 前期对于用户的需求理解定位非常重要，千万不要自我意淫，抛开用户需求来做，记住你不是甲方爸爸，先把用户需求满足了再搞花里胡哨的。

• 在结对讨论的过程中，逐渐明白书本中主持人为什么要打断了，因为有时候讨论着讨论着，就偏离了讨论的主题，变成不断扩展软件功能、开发用户需求的茶话会。所以在讨论会议召开前要明确讨论的主题，而新想法被提出时可以保留至下一次会议。

• 对于原型开发工具的使用，建议先玩开发工具半个小时，不然一边开发一边找功能挺麻烦的，个人感觉墨刀也不是很好用（可是我的菜，蒙蔽了我的双眼 QAQ）。

总的来说，本次组队学习了很多从来没接触的操作，对于软件开发中原型设计方面有了初体验。当真正的原型图运行时，简直了，成就感爆棚好吧！

031802113 黄明浩

这个……楼上都说了这么多了，我就少说点吧。首先还是要感谢队友，太给力了！结对非常愉快，碰撞出了许多奇妙的思想。相比单打独干，视野一下子开阔了。而且每当我懒癌发作时，他都默默地画了好几张图了……虽然偶有分歧，但基本上都能虚心听取对方意见，实现我们认为较好的效果。这是关于结对。

关于需求分析，我觉得我们应该算是考虑了挺多的，但是最终的结论是否合适，说实话我还是不太有信心。我们也确实怀疑过是否有些“误入歧途”，即过度专注于我们想到的拓展需求，而原本的重点反而不突出了。

关于原型设计，我们俩没玩过原型设计工具，再考虑到钢铁直男的审美……能做成这样还是比较满意的了。当初设想是把所有功能的界面都画一遍，但实际上根本来不及，有一些功能没有图片描述比较遗憾。再想到下次作业编码实现……是只要实现一部分对吧？对吧？希望简单点啊！

附录

以下内容本来想放在 NABCD 模型分析中，但写完后感觉不太契合且太冗长，本想删去，但毕竟体现了我们的思考，于是以这样的方式保留。

我们的 app 应该算是实名制、基于熟人关系的社交平台，印象中目前国内应该没有比较大众化的类似服务（没什么人用钉钉来社交吧……）。外网倒是有 Facebook，以及专门的职场社交网站 LinkedIn，国内曾经的人人网可能也比较符合这一定义。为何这样风靡多国的服务在目前的中国却无人问津？人人网的最终失败是否意味着这一模式在中国走不通？

这个问题我们恐怕难以给出一个很好的答案。但就结论来说，我们并不认同这一观点。这类网站没有在中国最终获得成功，应该说与其自身商业策略、发展时机，甚至政策因素都有很大的关系，并不等于说中国用户完全没有相关需求，只是需求可能转为以另一种相对别扭的方式实现了而已。比如十多年前说白领都用 MSN，现在 MSN 停止服务了，但职场社交的需求仍然在，只不过转化到微信上罢了。

但微信毕竟不是为职场定制的，于是就有了钉钉，有了企业微信。应该说，现在的互联网服务已经相对发达，不管对于大公司还是个人开发者，大部分的通用需求已经被实现，很难再做出什么颠覆性的服务来。要想找到出路，除去给予用户“优惠券”“补贴”之外，一种常见的做法就是做“微创新”，在现有服务基础上，找到一两个用户迫切需要的“痛点”功能加以改进，也有突围的一线可能。像我们这样需求相对特殊化、精细化的 app 也是如此。当然，成熟应用的先发优势——用户黏度是难以撼动的，尤其是社交应用，毕竟其核心还是活跃用户量。即使初期推广采用金钱激励，一旦停止，用户恐怕还是会跑掉大半。真要做成功，还是非常困难的。

接下来分析一下目前国内已有的相关产品。在福州大学师生常用的应用中，有部分功能重合或形成竞争关系的包括微信、QQ 等聊天社交类软件，以及今日校园、云班课、学习通等网课或校园事务类软件。我校贴吧好像不太活跃，暂且不计入。

对于 QQ 和微信这两款同为腾讯出品的聊天软件，孰优孰劣在网上已有诸多讨论，相关的知乎问题下有几千个回答。较为普遍的观点是，微信较为简洁，但基础功能有匪夷所思的欠缺，常有让人感觉不方便的时候。QQ 功能齐全，但花里胡哨的无关功能和增值服务太多，让人感觉不够正式且重点不突出。这可以说是两种不同的设计理念。

而之所以把今日校园和网课类软件列入竞争对手，是因为他们的使用逻辑也是构筑在学校及师生关系上的，而且它们也都有一颗做社交的心——这些软件很多都会按课程或者班级建个群，多半还会有兴趣圈子之类的功能。但就我们的现实经验，几乎没有师生会使用相关功能。究其原因，我们认为一方面是这些软件过于强调任务属性，在多数学生印象中就是每天打开签个到然后关掉，与社交不搭边。另一方面对社交的范围把握得不够准确。课程群相较微信、QQ 群没有明显的优势，而兴趣圈子这样的应用理论上辐射全国，把范围铺得太大，这样若用户少没有资源，用户多了往往垃圾信息泛滥。个人比较欣赏今日校园的校内圈板块，刚开通时确实有不少有趣的动态，但自从很多专业拿它来做学习打卡之后，基本上没人再用了，其实也还是上面说的任务属性过浓的问题。

而我们的 app 要想有人用，就应当在上面所说的问题中找到平衡，在满足客户需求的前提下，依托实验室、年段、学校的社交圈为基础做部分功能拓展。要让用户愿意尝试，就要把基本需求做清楚、方便。而要留住用户，还是要扩展一些“兴奋需求”。