项目原型设计
作业描述
| 课程 | 软件工程1916|W(福州大学) |
|---|---|
| 团队名称 | 修！咻咻！ |
| 作业要求 | 项目原型设计 |
| 团队目标 | 切实可行的计算机协会维修预约平台 |
| 开发工具 | Axue RP 8 |
| 原型下载 | 修！咻咻！维修平台原型设计 |
| PDF下载 | 修咻咻原型设计PDF |
团队信息
| 队员学号 | 队员姓名 | 个人博客地址 | 备注 |
| 221600126 | 刘忠燏 | http://www.cnblogs.com/Downstream-1998/ | |
| 221600207 | 黄权焕 | https://www.cnblogs.com/hyry/ | 队长 |
| 221600328 | 苏明辉 | https://www.cnblogs.com/ahuigg/ | |
| 221600330 | 吴可强 | https://www.cnblogs.com/masgak/ | |
| 221600331 | 向鹏 | https://www.cnblogs.com/xiang-peng/ |
团内分工
| 队员学号 | 队员姓名 | 分工 | 贡献度 |
| 221600126 | 刘忠燏 | 用户信息编辑页面原型的设计实现 | 19% |
| 221600207 | 黄权焕 | 文章发布、维修场次通知、登录注册页面原型的设计实现，整理博客内容 | 20% |
| 221600328 | 苏明辉 | 预约零件信息查看页面的设计实现、效能分析、PSP | 20% |
| 221600330 | 吴可强 | 预约人员信息查看页面的设计实现 | 19% |
| 221600331 | 向鹏 | 用户预约页面原型的设计实现，整理修改调和团队的原型设计 | 22% |
作业正文
问题回应
1. 如何确保用户需求得到满足？
实际上没有任何一家软件能说满足所有用户的所有需求。但是我们有建立用户反馈渠道（评价等），用户的不满之处我们将慎重考虑并加以改进，相信用户将在接下来的迭代版本中见到改进。
2. 是否提供预约前咨询功能
协会是有自己的公众号的，公众号的自动回复功能可以解决大部分常见问题，而部分特殊问题可以通过我们留在网页上的联系方式联系我们。目前平台需要先完善基础核心功能再完善进阶非刚需功能。
3. 计算机备件收费
备件信息会标明价格，在维修完成后由现场工作人员收取。这也是未来网站的一个盈利点，批发价和商品价总会有些差距。但是金额支付我们不会在线上完成，现场一手钱一手货更少经济纠纷（内存、显卡等物价波动大，可能只差一个月价格差了两三百，我们不准备做投机电商）。由于学号+手机号绑定，所有不担心恶意刷单。
4. 考虑维护队友的时间
我们将任务分为三种：未接取，已接取未处理，已处理。通过这三种方式让维修队队员根据自身时间与客户时间契合处来选择维修时间段，并可通过更改维修者的操作，达到多次多人处理，务必使客户满意。
5. 缺少维修人员等级评比
实际上这并不是我们用户的核心需要，也不是协会的核心需要。用户在维修时未必会因为一棵树放弃一片森林，协会内部谁是技术骨干也不需要在此处评比。但这的确是用户可能的需求。我们将在第三次迭代甚至第二次迭代中加入这个功能。借此重申：我们将投入精力优先完成核心需要，非核心功能模块请保持期待,等待我们迭代进度上线。
NABCD模型
N (需求 Need)
-
用户需求抽取
- 查看最近维修活动的信息
- 允许用户帮好友预约
- 预约信息的增删改查以及评价
- 一次完善信息后，预约时无需手动输入基础信息登记
- 了解义务维修队的维修范围，决定是返厂维修还是预约维修
- 决定是否预约上门服务
-
协会需求抽取
- 维修活动通知功能，能够推送活动举行的时间地点
- 文章信息推送功能，科普电脑小知识，推广协会
- 预约信息收集功能，导出预约人员信息
- 预约信息分析功能，得出预约零件以及对应的人员表
- 反馈调查功能，队员星级评价功能
A (做法 Approach)
我们将用户端和管理端进行了拆分，即管理页面单独为一个网站，进行数据的操作。
登录注册页面设计
登录注册预计是用户端和管理端分开使用，但样式不变。
用户需要以手机为账户注册，以确保预约联系方式真实可信，同时方便记忆。登录页面支持手机验证码登录或者账户密码登录。这个方面可能会复用网上现有的模块。登录之后用户在个人页面点击姓名等可切换账户登录。
--221600207 黄权焕
个人信息编辑页面
用户可在这里更新自己的相关信息（主要是姓名学号，电脑管理，以及对已提交的预约进行管理）
电脑的添加是考虑到大部分用户换电脑的频率不高，所预约的维修也基本是对自己的电脑，提前保存有利于减少输入。
添加电脑部分只需要两个信息：电脑品牌和型号（型号可选，品牌则是从下拉框中选取）
用户可以查看已提交的申请（默认只显示未完成的维修，已完成的维修可通过点击更多进行查看。每一条记录包含服务的时间与日期，电脑的型号与服务内容，和服务地点
对已经提交的申请，用户可以选择编辑预约的内容（主要是对状况的描述进行编辑，以及补充图片）
对于已经完成的申请，用户可以选择“后续服务”（针对问题没有完全解决的情况）
待议：
目前的信息主要是针对学生用户，如果以后开放给教师用户，怎么处理？
对于已被受理（但未完成的）的申请，用户是否可以进行取消或编辑
--221600126 刘忠燏
用户预约功能页面:
学生的维修预约功能分为两步，一为填写基本信息，若用户已登录的账户已完善自己的资料，就默认填写上去，并且提供修改(考虑到该账户可能是帮别人申请预约，目前不考虑安全性、欺骗性问题，到后期迭代再进行分析)；二是填写预约详情信息，提供2种预约方式，第一种线下维修活动预约，第二种上门维修预约。
线下活动预约提供计算机协会后续几次摆点义务维修的时间和地点让学生选择，上门维修预约提供计算机协会维修队的闲暇时间让学生选择。
学生选择设备从当前账户拥有的电脑中选取，可以选择协会目前提供的常用零件，描述其设备问题，可以提供图片，添加备注。
--221600331 向鹏
预约人员信息查看页面
预约人员界面是为了直接展示管理员看到的预约列表，该界面主要的功能是输入关键词（例如姓名）可以直接搜索有关预约消息，与导入功能（将excel表格的数据导入数据库，后续可以考虑直接做手动输入界面），与导出功能（将数据库数据导出至文件）。筛选功能可以筛选几个所选的条件，也就是直接从数据库中查找相应信息并展示在网页上，对于预约表的展示，本来是想直接做成一列列的表格信息，但考虑到这样信息全部展示出来界面会变得非常乱且不美观，所以制作成卡片形式，管理员还可以点击详细信息直接查看例如备注与图片等信息。
--221600330 吴可强
预约零件信息查看页面
预约零件主要是为管理员所提供的，供管理员采集所需零件的数据，首界面可以选择硬盘和内存相关的零件（目前计算机协会主要提供这两方面零件的维修），以表格的形式显示出来，另外，如需查看其他零件，可使用搜索功能，搜索页面提供相关搜索热词。
导入导出功能主要针对excel表格进行导入导出，导入或导出成功显示成功界面。
--221600328 苏明辉
维修场次通知页面
主要是简洁大方，界面清爽，让用户最直观感受维持场次信息，我们将其做为首页
由欢迎语和场次信息以及地点组成，场次可以由下拉框选择改变，默认为最新场次，地点信息也是根据下拉框的值进行动态显示。
--221600207 黄权焕
文章推送页面
最上方是搜索框，提供用户的文章搜索功能，暂只支持简单检索。
下方分为两个tab页：“文章推送”和“与我相关”。文章推送由标题、作者、发布时间组成，点击可查看详细文章。与我相关则是留给管理员与用户交互沟通使用，类似于淘宝的联系店家功能，预计在几次迭代后完善。
这个页面在第一次迭代中并不打算实现，原因是与维修公众号功能重复，是否开发待第二次迭代时与协会协商决定
--221600207 黄权焕
B (好处 Benefit)
作为软件工程的我们，有时电脑遇到问题也是解决乏力，更何况其他专业并不怎么了解计算机的同学呢？而电脑，往往是我们办公学习的优秀工具，所以一但出现问题，所有者一定心急如焚，而返厂维修时间成本太高，送店维修经济成本也不低。怎么办呢？如果有这个一个电脑维修平台，同学可以方便地去维修，甚至申请上门维修服务，这是多么方便的一件事啊！
服务同学，建设校园，正是我们团队的目标，也正是因此我们最终选择了“修！咻咻！”作为我们软件工程实践的项目
C (Competitors 竞争)
很多学会社团都存在一个问题：数据保存依旧还是在使用电子或纸质报表，而我们项目采用Web数据库服务（导入导出EXCEL也会具备）。就目前而言，针对学生社团的软件只有有限几个，且绝大部分不针对社团具体事务，更别说定制网站和定制小程序了。故竞争并不激烈。
但该软件项目也只能作为少盈利或者非盈利的存在，盈利方面会主要集中在推广费和广告费和计算机零件差价方面。即在文章推广页面植入软文和弹窗广告和提供零件维修。
D (Delivery 交付， Data 数据）
第一次迭代开发（3周）
- 完成用户的登录注册，完善基础信息（学号、姓名、住址）功能
- 完成首页的通知功能
- 完成用户基础预约功能（记录个人信息、电脑问题、所需零件、备注），记录维修类别（活动维修or上门维修）
- 完成对预约人员表的导入导出（可筛选）
- 完成对预约零件表的导入导出（可筛选）
第二次迭代开发（2周）
- 完善个人信息（设备信息）功能，支持预约信息的修改撤回评论等功能
- 增加预约任务状态位（未受理、已受理未完成、已完成），给用户直观感受预约业务进展
- 增加预约系统，问题拍照上传功能
- 完成发布活动通知地点的非数据库编写
第三次迭代开发（2周）
- 新增文章推送页面
- 新增管理员发布文章页面
- 新增修理队员星级认证统计服务
- 新增预约系统上门服务的空闲时间输入功能
- 完成协会各种需求
产品数据形式
数据形式为网站交付，采用MySQL数据库储存数据
我们已经购买域名和租借网站服务器，预计在本学期能交付一个可用网站
产品推广
借助计算机协会原有渠道宣传
联系协会挂靠学院帮忙宣传
QQ空间和微信公众号宣传
维修活动现场宣传
效能分析
前期通过讨论，大家对项目有了一致的了解与规划，设计原型时各成员分工绘画界面，因为时间比较赶，有一些额外的需求并没有画出来，基本功能基本实现，但由于是分工合作，对彼此界面的一些衔接可能存在瑕疵，画风也需要统一，应在画前约好一些方向和细节，方便后期整合。
PSP表格
| PSP2.1 | Pesonal SoftWare Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 40 |
| Estimate | 估计这个任务需要多少时间 | 10 | 10 |
| Development | 开发 | ||
| Analysis | 需求分析（包括学习新技术） | 120 | 130 |
| Design Spec | 生成设计文档 | 30 | 40 |
| Design Review | 设计复审 | 20 | 30 |
| Coding Standard | 代码规范（为目前的开发制定合适的规范） | 0 | 0 |
| Design | 具体设计 | 420 | 560 |
| Coding | 具体编码 | 0 | 0 |
| Code Review | 代码复审 | 0 | 0 |
| Test | 测试（自我测试，修改代码，提交修改） | 60 | 70 |
| Reporting | 报告 | 100 | 120 |
| Test Report | 测试报告 | 20 | 25 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem&Process Improvement Plan | 事后总结，并提出过程改进计划 | 30 | 30 |
| 合计 | 850 | 1065 |
总结
本次团队任务可以说是我们每个人都付出了相当的劳动，每个人都做出了精美的原型，显得界面丰富多彩，虽然确实存在每个人画风不一的问题，但详细给更多的时间我们可以解决这个问题。
这次原型设计其实一些对应的需求我们并不打算一次做完。例如预约信息地址的地图定位，我们更希望在第三次迭代去做。我们的目标依旧是十分明确的，为计算机协会提供预约管理的综合性平台，同学们为此提出了不少好点子，新需求，但我们团队很难在一学期内完成，只能逐步迭代，将核心做好，再扩展其余。
当然，微信小程序才是用户最需要的目标，所以在第三次迭代前，我们会先进行小程序移植，如果您有更多更好的建议，请及早提出，这样兴许可以在微信小程序上见到它的实现。
最后，感谢我的队员们，都是很棒很努力的人啊！道长且阻，与君同行，不失人间大乐也！鞠躬！
