2018软工实践第八次做业

目录

• 团队信息
• 分工选择
  • 课上分工
  • 课下分工
  • ToDolist
  • alpha版本要作的事情
  • 燃尽图
• UML
  • 用例图
  • 状态图
  • 活动图
  • 类图
  • 部署图
  • 实例图
  • 对象图
  • 时序图
  • 包图
  • 通讯图
• 贡献分评定
  • 课上贡献分
  • 课下贡献分
• 工具选择
  • StarUML
  • Process on
• 使用工具感觉
  • StarUML
• PSP表格
• 换队感觉

团队信息

队名 404 Note Found

队长：胡绪佩

临时队长：周政演

团队会议纪要连接

学号	姓名	博客连接
031602543	周政演	http://www.javashuo.com/article/p-kiosznsv-gh.html
031602510	葛家灿	http://www.javashuo.com/article/p-exmqjzvh-gk.html
031602513	黄鸿杰	http://www.javashuo.com/article/p-weahklwn-gm.html
031602627	刘恺琳	http://www.javashuo.com/article/p-xnrlsola-go.html
031602113	何宇恒	http://www.javashuo.com/article/p-gyatofhg-gp.html
031602444	庄卉	http://www.javashuo.com/article/p-ydcgmnng-ge.html
031602525	刘一好	http://www.javashuo.com/article/p-gbeichju-ev.html
081600410	胡青元	http://www.javashuo.com/article/p-cozmifac-eh.html
031602114	胡绪佩	http://www.javashuo.com/article/p-kstprbhu-dz.html
031602511	何家伟	http://www.javashuo.com/article/p-oynqqnns-dt.html
031602539	翟丹丹	http://www.cnblogs.com/breakbreak/p/9822763.html

分工选择

课上分工

课下分工

ToDolist

alpha版本要作的事情

迭代原则，由核心功能到辅助功能

燃尽图

UML

用例图

描述的部分：

• 描述了咱们软件必须完成的任务，定义了必须完成的软件功能；
• 基本呈现用户与用例之间的具体关系；
• 基本表达系统的基本功能；
• 基本表达系统的具体行为。

面临的问题：

• 如何具体对用例进行分类，使得用例更加具体；
• 如何对用户与不一样用例之间的关系详细分析。

解决的问题：

• 初步获取用户的需求；
• 指导测试；
• 在整个过程当中对其余工做流起到指导做用。

状态图

【part1】
描述的部分：

• 描述了用户登陆及未登陆使用的状态。

面临的问题：

• 面临用户帐号管理及云备份的问题。

解决的问题：

• 解决了用户使用云备份功能的问题。
• 解决了用户注册登陆流程的问题。
• 解决了用户找回密码的问题。

附图：

【part2】
描述的部分：

• 描述了用户新建自定义备忘的状态。

面临的问题：

• 面临用户添加自定义备忘条目选填信息较多的问题。

解决的问题：

• 用户只需添加标题即可新建备忘，选填信息个性化添加。

附图：

【part3】
描述的部分：

• 描述了备忘信息的状态。

面临的问题：

• 备忘录的备忘录事项状态较多，如何分类、组织的的问题。

解决的问题：

• 用户可清晰了解备忘录事项的各类状态。

附图：

【part4】
描述的部分：

• 描述了全部备忘展现的状态。

面临的问题：

• 备忘信息分类方式不一样及备忘信息展现形式比较多对于用户较复杂。

解决的问题：

• 方便用户切换查看备忘信息的分类方式，如按时间顺序与事务类型。
• 方便用户选择备忘信息展现的形式。

附图：

活动图

描述的部分

• 备忘录生成过程。
• 个性化壁纸设计。
• 用户自定义备忘录设置。

面临的问题

• 面临帐户管理问题。
• 用户自定义设计问题。如何使用户得到喜好的简洁实用的备忘录壁纸。

解决的问题

• 提供用户行为分析功能，对用户娱乐，游戏方面进行时间监控。
• 提供智能分析功能，智能读取快递信息和订单信息，将有效信息转化成备忘录。
• 提供智能提醒功能，在备忘录自定义提醒时间以前进行短信提醒，并提供天气提醒附加功能。
• 提供壁纸生成功能，用户自定义壁纸样式，字体颜色及字号，完成个性化特点壁纸设计。

附图

类图

描述的部分：

• 描述了咱们软件必须完成的类、接口以及它们之间的静态结构和关系；
• 类的部分：用户、备忘录、备忘录分类夹、桌面控件、锁屏壁纸、图片、音频、备忘详情、智能分析、快递信息、订单信息、天气信息；
• 关系部分：关联、聚合、泛化；

面临的问题：

• 绘制类图软件的选择和该软件在类图绘制上的使用方法；
• 类的定义（如属性和方法）和个数比较不明确；
• 各类类之间的关系比较模糊；

解决的问题：

• 1肯定使用StarUML进行类图绘制并搜索相关博客教程学习使用StarUML绘制类图；
• 2 与其余负责后端任务的组员讨论交流沟通，肯定主要的类的属性、方法和个数；
• 3与组内负责前端、原型设计和其余UML图绘制的组员反复沟通；

附图：

部署图

描述的部分：

• 描述服务器内部构建
• 描述软件物理构架示意图
• 描述软件与硬件组件之间的物理关系以及处理节点

面临的问题：

• 咱们没法提供24小时开机的主机，只能进行租借与托管

解决的问题：

• 解决了开发者对于物理构架的宏观理解
• 提供了科学可实现的物理框架构建

附图：

实例图

描述的部分：

• 描述用户和软件之间、软件各个部分之间的联系
• 描述软件的逻辑结构
• 描述实体与其属性的联系，是用来描述现实世界的概念模型。

面临的问题：

• 1.具体实际功能要与后端商议，进行必定修改

解决的问题：

• 1.明确了各个部分的具体功能
• 2.具体解决了数据库的设计

附图：

对象图

描述的部分：

• 软件运行中的静态时刻，描述对象之间关联的实例；
• 描述某一个应用情景；

面临的问题：

• 具体的应用情景需求；
• 数据流图的设计；
• 抽象语义的可视化描述；

解决的问题：

• 能够直观表示出系统在某一个时刻（情景）一组类的实体之间的关系；
• 经过查看某个时刻不一样类之间的关系，思考概括数据流图；
• 对系统的设计视图建模时，可使用一组类图完整地描述抽象的语义以及它们之间的关系；

附图：

时序图

云备份

描述的部分

• 这里描述了系统的云备份部分

面临的问题

• 要面临云搭建的，以及访问的问题

解决的问题

• 设计帮助后端成员理解这一过程

附图

登录系统：

描述的部分

• 这里描述了用户登录系统时遇到的状况

面临的问题

• 面临与数据库链接访问和与现有信息匹配的问题
  解决的问题
• 帮助编码人员分析登录时遇到的状况

附图

备忘录管理：

描述的部分

• 这里描述了用户对备忘录进行操做时遇到的状况

面临的问题

• 面临对备忘录的内容进行增删改的问题

解决的问题

• 帮助编码人员分析录入备忘录时遇到的状况

附图

备忘录类别：

描述的部分

• 这里描述了用户对备忘录类别进行操做时遇到的状况

面临的问题

• 面临对备忘录的类别进行增删改的问题

解决的问题

• 帮助编码人员分析修改备忘录类别时遇到的状况

附图

壁纸系统：

描述的部分

• 这里描述了用户设定时遇到的状况

面临的问题

• 面临如何使用备忘录生成壁纸的问题

解决的问题

• 帮助编码人员分析如何生成壁纸的状况

附图

智能分析：

描述的部分

• 这里描述了备忘录软件进行智能分析时遇到的状况

面临的问题

• 面临如何对用户行为进行分析和根据短信进行识别的问题

解决的问题

• 帮助编码人员分析进行智能分析时遇到的状况

附图

包图

描述的部分：

• 基本表达系统的基本功能
• 描述了软件大体须要实现的功能

面临的问题：

• 如何对于相关的类进行整合使之成为更加简练的包
• 对于相关包之间的关系如何显示比较好

解决的问题：

• 大体了解整个软件的使用过程
• 对于繁杂的类实现至关于文件夹的功能，看起来更加简洁
• 实现了uml的附加功能之一

附图

通讯图

【part1】
描述的部分

• 描述的是用户登录注册流程。

面临的问题

• 面临用户帐号管理以及云备份的问题。

解决的问题

• 解决用户注册登陆的问题
• 解决了用户使用云备份的问题
• 解决用户找回密码的问题。

附图

【part2】

描述的部分

• 描述的备忘录的生成以及删除的问题。

面临的问题

• 面临备忘录自动生成和用户自行建立的问题。

解决的问题

• 解决用户自动撰写备忘录的问题，解决根据手机短信生成备忘录提醒的问题，解决备忘录云备份的问题。

附图

【part3】

描述的部分

• 这里是根据用户手机上其余APP的使用频率自动生成分析图表的部分

面临的问题

• 应用使用频率的获取问题
• 生成分析图表的问题
• 生成消息提醒的问题。

解决的问题

• 自动获取应用使用频率
• 自动生成分析图表
• 自动发送消息提醒。

附图

贡献分评定

分工参考：

团队内部一致交流后，大体分为如下三个模块：任务工做量、任务完成效率、反馈度。贡献分评定不该当仅仅局限于工做量，而应该综合考虑全部对团队发展的因素。具体理由分析：

• 任务工做量：如构建之法中所说，在软件行业中，如何衡量工做量这自己就是一个大问题。可是工做量却并不能由于其难以衡量便不予以考虑，咱们会采起团队重复讨论投票形式比较精确、公平的决定工做量占比。好比：在还未开始时进行投票哪一个模块的难度最大，工做量最多，这样不够全局天然也会存在误差，所以咱们还会在实现过程当中中途继续进行讨论对初始工做量、难度的投票结果进行必定程度的更改使之更为精确。尽可能避免出现：“明明有效的只有十行代码，却由于其中加了许多的冗余代码甚至是空行使其代码量看上去较多”这类误判状况。所以咱们相信在咱们团队中评定出的较为合理的工做量做为贡献分占比的重要参考数据可使团队更良好的发展，相互良性竞争。

• 任务完成效率：团队并不是一我的，而是许多个成员之间的总体，多个模块功能组成的集合，相互之间的影响是很大的，产品的进度极可能会受其中某一个模块而停滞不前。好比产品发布时出现先后端有一个模块还有一半未完成的现象那对整个项目的影响也很是大。所以任务完成效率也是一个重要衡量贡献分占比的数据。

• 反馈度：团队想要良好的发展，就应当每个成员都尽可能保持较高的热情和动力，这样团队才会持久的具备活力和潜力。所以将反馈做为一项重要参考数据决定贡献分，防止出现由于个别成员懈怠致使整个团队缺少活力，项目完成天然也受到影响。

考虑到本次工做的临时性，既要考虑到贡献分评定的公平性，又要考虑要计算的快速性，故采用如下方式

• 临时贡献分评定 ：我的任务量 45%+完成度45%+反馈状况10%
• 要求：组里总共11我的，分数加起来为100分
• 每一个人结束前，对临时队内的每一个人进行评定，汇总给PM，PM对每一个人的给分进行平均，得出最后贡献分

课上贡献分

课下贡献分

工具选择

根据助教学姐推荐，以及转进同窗的使用习惯，本次做业共使用了两种工具：StarUML，ProcessOn。

StarUML

• 制做工具：staruml2.8
• 选择理由：staruml功能完整、易上手；
• 本小组组内试用过ProcessOn和visio，前者缺乏部分构图件，后者使用感受通常。

Process on

• 制做工具 Process on
• 选择理由：
  • 支持流程图、思惟导图、原型图、UML、网络拓扑图等；
  • 支持图形界面操做，容易上手，方便实用；
  • 随时将做品分享给队友，达成团队之间的共享，可以更好的协同合做，互相促进；资源丰富，图库资源强大；

使用工具感觉

本次做业使用了一种工具：StarUML

StarUML

• 这是一个很好的UML设计工具

经过这个工具很好的实现了个人时序图的部分，日常的软件一是没法建立生命线这一重要控件，二是没法针对各类实际状况作出应对，例如循环，条件等都没法进行设计。这款软件完美地解决了这些问题，而且还能针对时序图生成代码，很好地契合了咱们的需求。

PSP表格

PSP8.1	header 2	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	35	30
· Estimate	·估计这个任务须要多少时间	15	5
Development	开发	0	0
· Analysis	需求分析（包括学习新技术）	60	60
· Design Spec	· 生成设计文档	60	120
· Design Review	· 设计复审	30	30
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	180	240
· Coding	· 具体编码	0	0
· Code Review	· 代码复审	0	0
· Test	·测试（自我测试，修改代码，提交修改）	0	0
Reporting	报告	245	300
· Test Repor	· 测试报告	0	0
· Size Measurement	· 计算工做量	0	0
· Postmortem & Process Improvement Plan	· 过后总结, 并提出过程改进计划	60	60
合计		685	845

换队感觉

• 换走了pm以及其余两位同窗，因为此次的任务比较简单，因此没有太大区别
• 因为本次个人部分没有和换来的同窗有交集，因此没有更多的感觉，看他们的完成状况仍是很优秀的！