学号1：211606367 姓名：林恩 学号2：211606445 姓名：肖志豪
作业链接：https://edu.cnblogs.com/campus/fzzcxy/2016SE/homework/2180
原型模型设计工具： 墨刀
原型模型链接：https://modao.cc/workspace/apps/pCD69854C3C1538919846204
一、预估与实际
| Planning |
计划 |
30 |
30 |
| ? Estimate |
? 估计这个任务需要多少时间 |
30 |
30 |
| Development |
开发 |
790 |
750 |
| ? Analysis |
? 需求分析 (包括学习新技术) |
170 |
150 |
| ? Design Spec |
? 生成设计文档 |
50 |
70 |
| ? Design Review |
? 设计复审 |
20 |
30 |
| ? Coding Standard |
? 代码规范 (为目前的开发制定合适的规范) |
30 |
20 |
| ? Design |
? 具体设计 |
185 |
185 |
| ? Coding |
? 具体编码 |
185 |
185 |
| ? Code Review |
? 代码复审 |
30 |
30 |
| ? Test |
? 测试（自我测试，修改代码，提交修改） |
120 |
120 |
| Reporting |
报告 |
60 |
50 |
| ? Test Repor |
? 测试报告 |
30 |
30 |
| ? Size Measurement |
? 计算工作量 |
10 |
10 |
| ? Postmortem & Process Improvement Plan |
? 事后总结, 并提出过程改进计划 |
10 |
20 |
|
合计 |
880 |
830 |
二、需求分析
需要了解
- 《构建之法》，第八章-需求分析 与 第十章-典型用户和场景
- 原型模型如何设计
- 功能规格说明书如何书写
三、设计
1. 设计思路
显示解决用户问题的过程
- 题目重复
- 在每次生成式子最终时判断式子是否是已经存在的，如果存在，则放弃这道题，选择重新生成；如果不存在，则继续生成这道题。
- 数量不可定制或无限制
- 非法输入参数
- 输入非法参数，与正则表达式进行匹配，不匹配则重新输入参数；匹配则继续下一步。
- 乘除法、括号、数制范围、数值范围
- 用字符串数组存放乘除号，括号则是手动添加，数制范围默认为整型，数值范围则根据年级进行重新限制。
2. 实现方案 写出具体实现的步骤
分为六个步骤：
定义相关概念，如缩写、专有名词等
竞争性需求分析的框架
N（Need，需求）
- 要充分了解用户的痛苦，他们对已有软件、服务不满意的地方。
A（Approach，做法）
B（Benefit，好处）
- 你的新的软件具体有哪些好处，能让用户离开现有产品，使用你的产品呢？
C（Competitors，竞争）
- 做竞争性需求分析的目的之一，就是要看清楚我方优势在哪里，我方劣势在哪里。
D（Delivery，推广）
- 如何把产品交到千万个用户手中呢？
- 如何使应用快速推广至用户手中，快速扩大使用群体？
功能的定位和优先级
从各个角度将需求量化（需求实现的最后期限，实现需求大致所需的时间和资源成本，各个不同需求的优先级，需求带来的收益，等等）
功能分析的四个象限
- 杀手功能（Core）/ 外围功能（Context）
- 必要需求（Mission Critical）/ 辅助需求（Enabling）
功能分析的四个象限
规格说明书（Specification），简称Spec
软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当作一个黑盒子）。
- 定义好相关的概念。
- 规范好一些假设（Assumptions）。
- 避免一些误解，界定一些边界条件。
- 描述主流的用户/软件交互步骤。
- 一些好的功能还会有副作用。我们要把这些副作用明明白白地写出来。
- 服务质量的说明。软件团队要说清楚服务质量是什么等级，意味着什么，不然就会人云亦云，以谬传谬。
软件技术说明书（Technical Spec），又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当作一个透明的箱子）。
定义典型用户
典型用户可以分为两类（软件系统中有受欢迎的和不受欢迎的典型用户）：
- 受欢迎的典型用户——指那些按设计者的期望使用系统的用户，如“网站的购物者”；
- 不受欢迎的典型用户——指那些有不正当目的的用户，如在一个房地产业主论坛中滥发房屋中介广告的用户——这些用户也许在别的系统中（如房屋中介论坛）是受欢迎的。
典型用户包含以下内容：
- 名字（越自然越好）
- 年龄（不同年龄和收入的用户有不同的需求）
- 收入
- 代表的用户在市场上的比例和重要性（比例大不等同于重要性高，如付费的用户比例较少，但是影响大，所以更重要）
- 使用这个软件的典型场景
- 使用本软件/服务的环境（在办公室/家里/沙发/床上/公共汽车/地铁……）
- 生活/工作情况
- 知识层次和能力（教育程度，对电脑、互联网的熟悉程度）
- 用户的动机、目的和困难（困难 = 需要解决的问题）
- 用户的偏好
注意：我们的软件不是为所有人服务的。
给出界面原型设计
主要页面
登录页面
退出登录页面
注册页面
注册完成页面
功能页面
生成四则运算
生成期中期末的试卷
描述主流的用户/软件交互步骤
主流用户进入登录页面进行注册操作，然后登录进行功能选择，可以选择是生成期中期末试卷功能或是生成四则运算功能，生成后可按照提示获取生成，然后退出网站即可。
系统功能描述及验收验证标准
具体功能
- 网站至少在五点到晚十二点能访问
- 能生成期中期末的试卷
- 对于题目：
- 题目避免重复
- 可定制数量
- 可以控制一下参数
- 乘除法、括号、数制范围、数值范围、……
验收验证标准
- 在5:00~24:00能够登录，其它时间无法登录
- 正常生成期中期末的试卷
- 对生成的题目进行自动化测试
写出产品可能的副作用
- 不够完善，功能上仍有残缺，需要补缺
- 在超过一定人数访问时，可能会无法及时响应
- 不同的人在生成题目时，可能会生成有重复部分的题目
四、总结
spec的目标是什么，不包括什么？
- 从用户的角度描述软件产品的功能, 输入，输出，界面, 功能的边界问题, 功能的效率问题(对用户而言), 国际化, 本地化异常情况, 等;
- 不涉及软件内部的实现细节
spec的用户和典型场景是什么？
- 用户：学生、老师、程序员
- 典型场景：老师布置作业让学生上网站各自下载对应作业，然后学生上学校网站获取题目并完成；程序员不断完善后台。
spec用到了哪些术语，它们的定义是什么？
- 软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当作一个黑盒子）。
- 软件技术说明书（Technical Spec），又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当作一个透明的箱子）。
用户是如何使用软件的功能的？
- 进入登录页面点击注册，进行注册操作
- 完成注册，回到登录页面，进行登录
- 登录成功，进行所需功能的选取
- 选定功能后，转至相对应功能页面
- 进行各自功能操作，完成操作后，获取相对应所需
各种边界条件是什么，软件功能应该怎样随之变化？（用户数量的变化，输入内容的上限下限，不同国家地区文化语言硬件……）
- 一年级只会有加减运算，运算结果在100以内进行
- 二年级只有乘除运算，运算结果在100以内
- 三年级有加减乘除运算，并且加入括号进行混合运算，运算结果在1000以内
- 用户只能输入年级在1~3以内，数量1~100以内才能正确运行程序
- 不同国家，则会改变成相对应的语句
功能有什么副作用，对于其他功能有什么显性或隐性的依赖关系？
- 生成题目过程中需要调用所输入参数，需要用户一定有参数输入，方能运行
- 如果输入的是0，则只会生成空的文档，不进行题目生成
什么叫“好”，什么叫“这个功能测试完了，可以交付了”？
- 能够顺利运行，并且没有太高延迟，保证所有人都能顺利执行操作，简易明白。才是“好”
- 当所有功能都能顺利运行，并且没有异常抛出，就叫“这个功能测试完了，可以交付了”
软件发布出去之后，有哪些和项目目标相关的数据可以收集，怎么在实现阶段就能把数据收集的工作准备好？
- 用户在进行参数的输入时输入了哪些数据导致功能无法顺利运行，应当进行和项目目标相关的数据收集
- 用户正常操作，出现异常或无法继续执行，应当进行和项目目标相关的数据收集
- 当出现异常时，调用try{}catch{}捕获异常，并存储下来，进行和项目目标相关的数据收集
结对照片
结对照片
功能规格说明书
原文：https://www.cnblogs.com/mumuyinxin/p/9755596.html
