繁星 实验六 团队作业3：团队项目需求调研与原型开发
繁星 实验六 团队作业3：团队项目需求调研与原型开发
| 课程班级博客链接 | |
| 这个作业链接连接 | |
| 团队名称 | |
| 团队成员分工描述 | 刘春丽：调查问卷数据分析，博客撰写，项目申请表撰写 李涛：需求分析，原型开发，项目申请表撰写 陈玉英:原型开发，项目申请表撰写 |
| 团队的课程学习目标 | （1）运用各种调研手段调研真实用户并对调研成果进行了整理分析，完成了对软件项目的需求调研 （2）学习并应用NABCD法对实验软件项目可行性进行了分析 （3）学习使用了墨刀原型设计开发工具 （4）掌握软件原型开发技术 |
| 这个作业在哪些方面帮助团队实现学习目标 | （1） 选择优秀项目，学习借鉴，提升自身实力。 （2）创建团队，了解团队成员。 |
| 团队博客链接 | |
| 团队项目Github从库地址链接 |
任务一：团队协作学习《现代软件工程—构建之法》第8章需求分析，团队组长主持企业微信会议，采用NABCD法，从五个视角对实验软件项目可行性进行团队合议
1、团队组长主持企业微信会议，采用NABCD法，从五个视角对实验软件项目可行性进行团队合议（截图）：
2、团队协作学习《现代软件工程——构建之法》第八章：
- 软件需求（人们为了解决现实社会和生活中的各种问题，要求助于软件）
获取需求的步骤：- 获取和引导需求：软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出真实的需求。
- 分析和定义需求：对从各个方面获取的需求进行规整定义。
- 验证需求：跟利益相关者沟通，通过分析报告，技术原型，用户调查或演示等形式验证软件团队对需求的认知。
- 在软件产品的生命周期中管理需求：需求变化，技术发展，团队实力提高，需要不断对需求进行审核并做出相应的调整。
- 软件产品的利益相关者
很多人和机构都是某个软件的利益相关者，软件团队在分析软件需求时需要考虑：用户，顾客，市场分析者，监管机构，系统/应用集成商，软件团队，软件工程师。 - 获取用户需求——用户调研
- 秋千图
- 常用的用户调研方法：焦点小组，深入面谈，卡片分类，用户调查问卷，用户日志研究，人类学调查，眼动跟踪研究，快速原型调研，A/B测试。
- 竞争性需求分析的框架
- NABCD模型：
- N(Need,需求）
假设用户的需求已经被不同程度地满足了；
找到不消费用户，了解他们不使用的原因 - A(Approach,做法)
使用独特的招数，来解决用户的痛苦 - B(Benefit,好处)
可以给用户带来的体验以及产品升级 - C(Competitors,竞争)
掌握先发优势 - D(Delivery，推广)
让用户了解我们的产品，例如做广告，做公关活动，鼓励有影响力的用户或市场认识介绍这个产品，做出高质量的功能让用户口口相传等。
- N(Need,需求）
- NABCD模型：
- 功能的定位和优先级
- 杀手功能
- 外围功能
- 必要需求
- 辅助需求
- 计划和估计
- 估计项目各类工作所需的时间
- 分而治之
3、 团队利用NABCD的讨论如下：
- NABCD法：
- N（Need，需求）
开发背景: 背包问题（Knapsack Problem，KP）是NP Complete问题，也是一个经典的组合优化问题，有着广泛而重要的应用背景。{０-1}背包问题（{0-1 }Knapsack Problem，{0-1}KP）是最基本的KP问题形式，它的一般描述为：从若干具有价值系数与重量系数的物品（或项）中，选择若干个装入一个具有载重限制的背包，如何选择才能使装入物品的重量系数之和在不超过背包载重前提下价值系数之和达到最大？- 需求分析：是一款由注册用户共享的背包问题知识社区系统。
- 功能需求：系统具有资源上传、检索、资源审核与管理、背包问题主题知识论坛；资源类型至少包括：典型算法源代码、开源数据集、背包问题相关文献资源；系统设置管理员，用于系统用户管理、资源有效性审核。
- A（Approach，做法）
软件支持：数据库、Mysql、python、Java、墨刀；
技术支持：开发人员是计算机专业学生，拥有浓厚的专业知识支持，掌握基本软件编程； - B（Benefit，好处）
开发成本低；
系统是一个容易操作、体验的系统，里面内容丰富、所包含的知识体系完整、功能完整；
开发人员把内容融合在一个系统，提高了开发人员的编程应用技术，用户体验感较好。 - C（Competitors，竞争）
背包问题一直是一个热门问题，在编程方面的开发基本已经成熟，但是我们的背包问题知识社区系统对于用户来说是一个全新的系统，里面内容丰富、知识结构完整、体验过程新鲜。 - D（Delivery，推广）
我们可以主动与相关企业联系，向其细致地介绍本系统，说明本系统的优秀之处以及相关的不足。也可以和当地学校联系，推广自己的系统。还有一些类似的实体开发集团，我们可以主动和他们联系，试着将现在的系统与网络联系起来。
任务二：：依据任务1讨论情况，实施团队项目软件用户调研活动，并依据调研结果填写《学生“创新能力提升计划”项目申请表》，要求如下：
1、调研真实用户
 |
 |
 |
 |
|---|
2、问卷调查结果分析
调查问卷
2.1 问题一：您的性别？
- 分析：此次调查问卷中有52.73%的调研用户是人群女生，有47.27%的调研用户人群是男生，男女生填写比例相对均匀。
2.2 问题二：您的学历？ - 分析：调查结果显示，有90.91%是本科学历，有3.64%是硕士学历，还有5.45%是其它学历。（我们此次问卷面向的是所有人群）
2.3 问题三：您对背包问题的了解程度 - 分析：有10.91%的用户表示非常了解，这些用户大概率是对算法非常熟悉的。有9.09%的用户表示比较了解，说明这些人群也是比较了解算法。有23.64%的用户表示基本了解，那么这类用户是属于接触过算法，但并未系统地学习过。有56.36%的用户表示不了解，那就说明他们的专业基本与算法无关。
2.4 问题四：您了解背包问题时，会选用以下哪种方式？ - 分析：有40%的用户选用向老师和同学请教，说明这些用户还是比较喜欢传统的方式去了解问题。有50.91%的用户选用查阅相关书籍资料，说明这些用户比较喜欢自学来获取知识。有50.91%的用户选择听网课（在B站、中国大学mooc等），说明这些用户结合了网络进行自学从而获取知识。有61.82%的用户选择使用网络交流平台（贴吧、博客、QQ交流群等），说明这些用户紧跟时代的脚步，明白利用网络资源，向其他和自己同专业的人进行直接的交流来获取知识解决学习问题。最后有30.91%的用户选择通过其他方式获取知识，这部分用户具体选用什么方式我们也就不得而知了。
2.5 问题五： 如果有一个背包问题知识社区系统，您会在学习过程中选用它吗？ - 分析：有45.45%的用户选择会，有29.09%的用户选择不会，以及25.45%的用户表示要再想想。从这些数据中可以看出我们很有必要去开发一个背包问题的知识社区系统，去帮助多数用户进行学习背包问题的相关知识。
2.6 问题六：对背包问题知识社区系统，您最希望实现哪个功能？ - 分析：有40%的用户希望实现查找背包问题相关资料的功能，有34.55%的用户希望实现用户之间交流学习成果的功能，有10.91%的用户希望实现用户可以实时反馈意见的功能，还有14.55%的用户选择其他，说明这些用户些有自己的想法，值得我们再去探究一番。
2.7 问题七：作为用户，您最希望背包问题知识社区系统实现什么功能？
3、依据调研结果填写《学生“创新能力提升计划”项目申请表》
任务三完成情况
1、以团队成员姓名命名的墨刀安装界面截图
2、墨刀原型设计工具简介
- 目前市面上主要流行的有五款原型设计工具，分别是Axure、Balsamiq Mockups、墨刀、Justinmind和iClap。自然是包括了推荐使用的Axure与墨刀两款工具。简单上网了解之后发现大家都比较推荐墨刀。因为墨刀其实是主打团队协作工作来展现特性，且它的使用十分得方便、易上手，对于初学者包括项目后续的接手人员十分得友好，同时通过主界面、主界面以下的子界面等有效地分清楚层次。
2.1 墨刀的简介
- 墨刀是一款在线原型设计与协同工具，借助墨刀，产品经理、设计师、开发、销售、运营及创业者等用户群体，能够搭建为产品原型，演示项目效果。墨刀同时也是协作平台，项目成员可以协作编辑、审阅 [1] ，不管是产品想法展示，还是向客户收集产品反馈，向投资人进行Demo展示，或是在团队内部协作沟通、项目管理。
关于墨刀了解更多
2.2 墨刀的发展历史
- 2017年6月，墨刀推出3.0版本，主打团队协同方向，从3.0开始，墨刀不再是一个只给产品经理用的，用来画产品原型的工具，而是变成了一个覆盖整个产品的设计和开发流程，帮助整个产品团队最大限度的发挥协同效应的团队协同工具。
- 2017年6月12日，高保真产品原型制作及团队协同工具公司墨刀宣布推出最新3.0版本，此次发布会墨刀主打团队协同方向，未来重点打造高效团队协作工具，加速团队内部效率和流程。同期墨刀宣布与石墨文档、吆喝科技、轻芒、联创工厂等多家上下游企业达成合作，未来打通整个产品设计流程。
- 2018年1月推出Sketch插件2.0版本，Sketch设计稿可以导入墨刀，进行交互设计，自动获取标注信息，推进开发进程；
- 2019年1月，墨刀启动To B 战略上线企业版，提供诸如企业项目及成员管理、基本数据统计等功能。
2.3 墨刀的优点
- 操作简单
- 简单拖拽和设置，即可将想法、创意变成产品原型。
- 演示方便
- 真机设备边框、沉浸感全屏、离线模式等多种演示模式，项目演示效果逼真。
- 具备团队协作
- 与同事共同编辑原型，效率提升；一键分享发送给别人，分享便捷；还可在原型上打点、评论，收集反馈意见，高效协作。
- 交互简单
- 简单拖拽就可实现页面跳转，还可通过交互面板实现复杂交互，多种手势和转场效果，可以实现一个媲美真实产品体验的原型。
- 自动标注及切图
- 将 Sketch 设计稿墨刀插件上传至墨刀，将项目链接分享给开发人员，无需登录可直接获取到每个元素宽高、间距、字体颜色等信息，支持一键下载多倍率切图。
- 有丰富的素材库
- 内置丰富的行业素材库，也可创建自己的素材库、共享团队组件库，高频素材直接复用。
3、团队协作学习墨刀的会议截图或照片
4、团队协作学习《现代软件工程—构建之法》第10章典型用户和场景
构建之法第十章——典型用户（Persona）和场景（Scenario）学习笔记
1 典型用户和典型场景
1.1 定义典型用户
- 要定义典型用户，我们首先要定义用户的角色：
- 受欢迎的典型用户：指哪些按设计者的期望使用系统的用户；
- 不受欢迎的典型用户：指哪些有不正当目的的用户。
- 典型用户的模板可以包括以下内容：
- （1）名字（越自然越好）
- （2）年龄和收入（不同年记和收入的用户有不同的需求）
- （3）代表的用户在市场上的比例和重要性（比例大不等同于重要性高，如付费的用户比例较少，但影响大，所以更重要）
- （4）使用这个软件的典型场景
- （5）使用本软件/服务的环境（在办公室/家里/沙发/床上/公共汽车/地铁……）
- （6）生活/工作情况
- （7）知识层次和能力（教育程度，对电脑、互联网的熟悉程度）
- （8）用户的动机、目的和困难（困难=需要解决的问题）
- （9）用户的偏好
1.2 从典型用户到场景 - 有了典型用户之后，我们还得决定每一个典型用户的目标：他/她使用系统想要达到什么目的（如购物、卖产品、滥发广告等）。
1.3 从场景到任务 - 有了场景，下面就由架构设计师和各个模块的负责人一起，沿着子系统/模块的所属关系把场景划分开。（如UI层+逻辑层+数据库）
1.4 场景/故事/Story的模板
（1）.背景- 典型用户
- 用户的需求/迫切需要解决的问题
- 假设
（2）.场景
（3）.其他资料
（4）.用例（Use Case） - 用例的基本元素：
- 标题：描述这个用例要达到的目标；
- 角色（Actor）：和软件系统交互有关的角色，例如用户、其他实体、甚至
- 时间（在描述一些和时间相关的场景时哟用）；
- 主要成功场景（Main Success Scenario）：一系列步骤描述角色是怎样和系统交互，从而达到目标的；
- 步骤（Step）：描述每一步的交互；
- 扩展场景（Extension）：描述一些扩展的交互，例如一些意外情况。
1.5规格说明书
- 规格说明书（Specification）简称Spec，分为以下两种：
- 软件功能说明书（Functional Spec）：主要用来说明软件的外部功能和用户的交互情况（把软件当做一个黑盒子）;
- 软件技术说明书（Technical Spec）：又叫设计文档（Design），主要用来说明软件内部的设计规范（把软件当做一个透明的箱子）。
1.6 功能驱动的设计（Feature Driven Design，FDD）
- FDD由下面几个步骤构成：
第一步：构造总体模型（Develop an Overall Model）
第二步：构造功能列表（Build a Feature List）
第三步：制定开发计划（Plan by Feature）
第四步：功能设计阶段（Design by Feature）
第五步：实现具体功能（Build by Feature）
任务四：利用墨刀设计实验项目软件原型
1、用户登录页面/管理员登录页面
- 登录页面——>修改密码——>激活失败——>激活成功
 |
 |
|---|---|
 |
 |
2、 进入主页
|
3、 进入资源
|
4、 上传文件
|
5、 打开文件
|
6、进入课程
|
7、进入社区
|
8、 进入论坛页面
|
9、创建文章
|
10、文章详情
|
11、个人中心
|
任务五：上传至GitHub
1、 各项任务完成所花费的时间
| 任务类型 | 实际花费时间（） |
|---|---|
| 任务一 | 100 |
| 任务二 | 230 |
| 任务三 | 120 |
| 任务四 | 600 |
| 任务五 | 270 |
2、实验总结
此次项目，需要下载安装墨刀原型设计工具，在此过程中，我们学会了使用墨刀进行软件的原型设计；掌握了软件原型开发技术，意识到软件原型设计对于整个软件开发的重要性；了解了以原型系统为基础的软件项目需求获取的技巧与方法；团队通过有效的沟通和合理的任务分配，互相学习，互相交流，提高了团队的合作意识，学到了以前没有了解到的很多知识，这些知识方法为在帮助我们小组完成这次实验内容的同时也为我们之后的软件项目开发积累了经验。每当我们的设计出现遇到瓶颈时，和团队成员们的讨论总是会再次激发灵感。通过此次任务，我门再次的感受到了团队协作的重要性:将一个大任务分解成几个小任务，再由不同成员分工合作，最终整合——效率至上，现在我们小组默契度也越来越高。
