2020软件工程第三次作业（结对合作）

2020软件工程第三次作业（结对合作）

目录

• 2020软件工程第三次作业（结对合作）
  • PSP表格
  • 合作过程
  • 客户需求与解决方案
    • N（Need）
    • A（Approach）
      • 一般流程：
      • V1.0：标签分类、好友社区方式
        • 流程图：
        • 具体介绍：
        • 考虑过但抛弃的想法：
        • 用例图：
        • 原型图：
        • 方案自我评估：
      • V2.0：离线存储信息、在线查询下载信息的方式
        • 流程图：
        • 具体介绍：
        • 用例图：
        • 原型图：
        • 方案自我评估：
    • B（Benefit）
    • C（Competitors）
    • D（Delivery）
  • 总结
  • 小组成员：

• 这个作业属于哪个课程	https://edu.cnblogs.com/campus/fzu/SE2020
  这个作业要求在哪里	https://edu.cnblogs.com/campus/fzu/SE2020/homework/11224
  这个作业的目标	学习根据需求完成软件初步设计并提出具体方案的方法
  学号	031802127 031802106

PSP表格

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

合作过程

本次作业由我和陈泽宇同学合作完成，我们线下进行讨论了几回，第一次在玫瑰园食堂进行，这是当时的情景：

之后几次都是在课上或者是路上，以及线上。在第一次商量时仔细分析了题目需求后，依据NABCD模型的建立，我们在进行了一轮头脑风暴之后，提出了几套拟进行方案，在结合现实情况排除了一些不切实际的方案后，基本敲定了往做一款类交友微信小程序的方向进行本次作业，商讨了软件大概的功能方向和大体页面布局之后，开始着手安排原型模型的设计分工，我们使用Axure创作原型，两人各自负责部分页面的设计，之后在模型设计上面又花了一些功夫进行修修改改，并对NABCD模型的内容进行相关的改动。

前后给出两个版本解决方案，经过权衡有了后面V2.0最终解决方案。

期间文件的交流均在GitHub上进行：

Github仓库：https://github.com/rebuilder945/project

客户需求与解决方案

附:客户现实困扰

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

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

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

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

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

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

针对本次作业如上客户需求，我们使用NABCD模式进行竞争性需求分析并给出解决方案

N（Need）

由于信息渠道有限，学长学姐与我们之间要取得相互交流的机会存在困难（学长学姐出社会后和校内联系较少，导致我们缺乏渠道与之交流；有些学长学姐长期潜水，离开学校时也是悄悄地不带走一片云彩，如同人间蒸发，让我们十分难以自行寻找其联系方式；我们出了社会，离开学校，与学弟学妹的交集也减少，不好了解他们情况；即使是在身边的朋友同事，如果没有交心谈起过去，也并不会知道到底是不是同门出身，所以这些都需要互联网软件进行辅助，增大相互了解的概率），把特定团体内的往届学长学姐与我们沟通起来，让我们能够了解他们的去向，他们也能够知晓我们在学校的情况。并使得双方能够进行联系。

A（Approach）

根据需求分析，我们认为实现的一般流程如下：

一般流程：

信息库的建立有赖于推广，查询信息、获得信息的方式是我们要考虑的主体内容。

经过讨论，给出前后两个版本解决方案：

V1.0：标签分类、好友社区方式

流程图：

具体介绍：

• 注册账号与建立个人信息：使用微信登录，填写信息，每个用户可以给自己打上信息标签（自己在哪里，哪个学校，会什么，在什么社团，实验室，在哪里工作，毕业院校是哪等等）

• 分类进入圈子：根据用户填写的信息，推荐分类如相应的圈子（社团、实验室）

• 查询用户以及联系：用户之间可以通过搜索，选择标签，查看圈子等方式，或者由系统推送相同标签的用户，让用户能够看到自己所感兴趣的其他用户，可选择向对方发送一条验证消息（由系统发送，对方登录，即可见，知道是谁发送的），只有通过验证才可以查看对方资料，通过资料中的第三方联系方式来联系对方。（考虑到成本以及必要性，只能够采取第三方软件来联系对方，毕竟腾讯爸爸等大公司的软件功能齐全方便好用，并不是我们可以替代的，我们只是提供用户之间相互认识的平台）

• 我们在考虑用户隐私以及安全性、隐私性过程中，认为在注册时可采用以下三种注册方式：

  • 校园范围内推广扫码（无须验证身份）
  • 已有用户分享邀请（无须验证身份）
  • 校友直接注册（须要验证身份）

  还应建立用户投诉机制，以防止无关人员污染环境

  在用户查看资料时设置验证消息来保护隐私

考虑过但抛弃的想法：

• 是否需要添加推送定位周边用户的功能？

​ 考虑的理由：在工作后可以发现周围潜在的校友，增加交流机会

​ 抛弃的理由：定位权限并非都愿意开启，发现周边校友的可能性不大；并非必要需求

用例图：

原型图：

使用工具：Axure

（仅画出了主体部分，细节略）

主页面查看各种圈子：

查看一个圈子：

查看感兴趣用户资料：

发送关注：

消息页面：

设置页面：

方案自我评估：

​ 实用性：实际上不是很高。满足需求所须要的功能是单一的，界面与用户信息的设计占用太多开发成本，对于这样单一的一个功能而言机制的设定与维护太过复杂;

​ 有效性：中等，相较于建立q群联系，这种方式使得我们在了解学长学姐的情况下进行联系，消除了一部分联系的陌生与尴尬，使得交流更为自然与顺畅；功能有较好的拓展性，可以添加更多功能以提供更便捷的服务

​ 安全性、隐私性、封闭性：验证消息以及注册方式改进的加入，使得三者得以保障;

总的来说，这是一种最自然而然、容易想到的实现方式，也能较好地满足客户需求。但是，我们在后续的讨论过程中，越来越感觉到这种方式的不足：对于这样一个简单的需求而言，用户或许在查询到有用信息后便不再使用此程序，因此用户使用频率并不高，况且用户范围局限于学校，用户基数不大，用户可能一次查询后，很长一段时间不会再使用，在这样的情况下，用户界面、社区建立、用户信息维护等方面的工作实在显得冗余复杂。

因此我们给出最终方案：

V2.0：离线存储信息、在线查询下载信息的方式

流程图：

具体介绍：

• 用户提供个人信息进行身份验证：须设置简单而有效的问题，来验证用户非无关人员查询。此时可用学号姓名进行验证，考虑到校外学长学姐们可能时隔多年，社团组织的信息描述也可以是一种验证方式。用户在此时需要提供联系方式，以及社团、实验室相关信息。若验证通过，则仅保存联系方式以及所选标签等基本查询信息，不保存真实姓名学号等验证信息（仅凭我们存储下来的信息无法确定该用户身份），从而将保存的用户信息最简化、有效化。一方面保证用户隐私性、安全性、封闭性，一方面简化用户的操作，方便用户的需求实现。
• 输入查询范围：身份验证成功后，用户选择要查询的社团、实验室，选择要查询的是学长学姐还是学弟学妹
• 下载所需文档：后台数据库按查询要求，整理出所查询的信息输出为一个文件，提供用户下载，里面集合了满足条件用户的资料（联系方式、年级、所在社团实验室、研究方向等，不包括真实姓名以及学号）
• 必要的隐私保护方案要在一开始告知用户。
• 问题：用户信息需要有第一批的建立者，这些人的第一次查询或许还没有信息可以提供，会出现查询无果。这与V1.0是差不多的，只不过查询无果容易带给用户不好的体验，这时需要设置提示，提示第一批用户可过段时间再来查询。而信息库的建立速度同V1.0一样，需要靠推广来促进。

用例图：

原型图：

进入系统首先提醒需要提供身份验证信息：

提供验证信息以及个人查询信息：（验证信息不局限于姓名学号，具体略）

验证成功则输入查询信息，并下载生成的文档：（查询项可更细化，具体略）

方案自我评估：

我们本来认为第一版本已经较为完善，但在一次讨论过程中，经过不断自我否定与评估，暴露出不能忽略的问题。

这一版方案被我们定为最终版，是从用户角度出发，基于对用户使用频率以及需求单一性的考虑。

在实用性以及有效性上，或许功能不如第一版方案丰富完善，界面不如第一版精致，但在用户使用频率不高的情况下，实现用户最核心的需求是最为重要的。在安全性与隐私性上也做了保障，由于不必将每个用户以界面形式展示出来，而是提供给查询者下载信息的途径，信息的封闭性则较第一版有了更好的保证。后期的维护工作也大大降低。

B（Benefit）

1.提供了一条新渠道，可以让同一群体内的历届学生之间能够加强联系，整合资源，提供交流互助的平台。增强福大学子在社会上的凝聚力。
2.功能方便有用，让用户之间能够更加轻松的相互认识到对方。
3.用户使用的是小程序，迁移成本低，体积小，依附在微信这个日常使用的社交软件上，使用方便。

C（Competitors）

优势：
1.软件的功能是为精确定位用户而设计的，从实用性的角度来说没有问题。

2.计划开发的是小程序，依附在微信这个社交软件，更加的便捷，体积小，功能明确，开发方便，传播也相对轻松些（只是相对）。用户使用时无需任何迁移成本。

3.在同行的竞争中，优势在于，我们对于丰富多样功能的实现是否有必要的问题考虑较深入，对问题考虑较全面，先后提出两个版本，且最终版本能在开发成本限制较高的情况下满足不同需求。

劣势：
1.鉴于已知对手就有同堂课的一百多号人，想法雷同，功能雷同的情况难以避免，竞争还是相对激烈的。

2.技术相对不成熟。

3.最终版在功能上、界面上毕竟不如其他那么丰富精美。

D（Delivery）

由身边加入的第一批用户进行推广，推广的渠道可以是线上qq空间，微信朋友圈，发布贴吧帖子，线下商家或校园活动合作以及地推贴海报等等。关于用户参与推广的驱动力，我们考虑可添加功能：“推广送礼包”或“不推广则限制功能”或“推广获得抽奖机会” 的方式（第三种或为最有效）。

总结

在考虑最终版本的时候，我们也犹豫过，推翻之前的成果是否合适，但过程究竟是比结果重要的，于是我们尽力将真实的讨论过程呈现出来。

在本次作业中仍存在很多不足之处，原型的设计太过简陋，没有深入学习Axure的使用，没有设计交互；相关理论知识也很浅薄。

总体上这次结对合作进行的较愉快，我们之间分工明确，沟通顺畅，合作顺利。尤其在遇到困难时，互帮互助，一起攻克的感觉比一个人埋头苦干好太多。

期待下一次编程合作。

小组成员：

学号	姓名
031802127	吴达渝
031802106	陈泽宇