第四次团队作业——系统设计
我说的都队
031402304 陈燊 031402342 许玲玲 031402337 胡心颖 031402203 陈齐民 031402209 黄伟炜 031402233 郑扬涛 031402341 王婷婷
一、完善《需求规格说明书》
《需求规格说明书》修改版Git链接
文档初稿查缺补漏
-
文档里未提现可上传Excel文件的版本限制。（原型里有提现，但相应界面未加入1.0版本里）。
-
在压力特性要求里未考虑可同时在线的最大人数。
-
原型里缺少设置导师是否为实验班的界面。
-
数据库设计未和Android的进行商讨，不少字段和Andoird组的产生冲突。
-
用户特点部分存在些许冗余，重复描述。
-
原型部分界面较为粗糙，样式不统一。
-
文档目录结构较为杂乱。
-
国标要求的部分要点没有提现。
针对《需求规格说明书》1.0版本存在的不足之处，进行了如下修正
添加
- 版本历史
- 第二部分 需求分配 小节
- 第三部分 外部接口需求 小节
- 第三部分 性能需求小节 添加 压力特性要求（即对600人同时在线的处理方案)
- 第三部分 软件系统属性
删除
- 原2.3.2.3用户场景 part six 对两种分配算法的简介
- 原4.1.2功能描述（概要）
- 原4.5数据管理能力要求
- 原4.6其它专门要求
- 原第三部分 原型界面
调整
=> 代表调整到
- 原1.3 预期读者和阅读建议 => 1.1 目的 部分
- 原第三部分 界面原型 => 3.1.1 用户界面 小节
- 原4.4 输入输出要求 => 3.1.3 软件接口 和 3.1.4 通信接口 小节
- 原4.6 故障处理要求 => 3.6 软件系统属性 小节
- 原4.2.3 灵活性 => 3.6 软件系统属性 小节
- 替换原型界面的图片
- 重新撰写3.3.1节精度部分
二、编码规范
编码规范文档链接
关于编码规范，我们有话要说
031402304 陈燊
1、对于每一名程序猿，在刚踏入C语言的世界，蹩手蹩脚得输出Hello world时，便已经开始接触到了编码规范。缩进、命名原则、花括号位置等等，这些规范肯定都曾让每个程序猿头疼好久。在自己大一刚接触C语言的时候，并没有考虑过编码规范的问题，但是随着代码写得越来越多，才逐渐深感一份规范得体的代码的重要性。每当别人叫我去帮忙看哪些排版乱七八糟的代码时，无疑是一种地狱般的体验，于是从那时开始，自己便逐渐注意到编码规范的问题，并在自己日常编程中，尽量提升自己的代码规范性和可读性。
2、自己之前也做过几个Android项目，或多或少对项目开发的编程开发有一定的接触和了解。虽说我们团队所负责的是PHP端的项目，但是编程世界万变不离其宗，大致的编码规范都是相同的。而我们小组也有几名组员接触过PHP和前端的编码，因此在开会讨论编码规范时，整体的过程还是比较顺畅的。不过介于我们所制定的编码规范内容太多，便把编码规范文档上传到github上，以免博客内容太长。
031402342 许玲玲
由于一直都没注意过编码规范这个问题，都是自己看得懂就好的原则，通过这次作业了解了编码规范，发现自己以前都是乱来，这样在团队里面根本是不行的，只有代码规范了之后才能使得整个团队更好的进行编码。开始学习规范编程，从现在开始做起。
031402337 胡心颖
以前写代码都不管编码规范的，什么大写小写驼峰下划线，开心叫什么就叫什么，只要不error不wrong就都可以接受。代码注释更是从来不写，毕竟一个人做，虽然时间久了自己也有点看不懂。这次要规定编码规范，百度了一下，第一反应是：这文档好长。毕竟这次是一群人写一个项目，各种规范还是要做好，万一编程的时候沟通出了差错，轻则几个BUG，重则GG。
031402203 陈齐民
1、每个程序猿都有自己敲代码的风格，而且彼此之前的风格大相径庭，如果多人合作完成一个项目的话，彼此之间做好编码规范和代码风格的确定是非常重要的，因为如果不做规范统一，绝大多数的时间会花在理解代码结构上，而不是代码的逻辑功能；在编写PHP编码规范的时候，我发现自己的编码风格不是特别的规范，在每个接口前我会注释该接口所需参数是什么，何种数据类型，调用方式是什么，返回数据的类型是什么，但是在方法中我很少或者基本不会添加代码注视，这样队友在看我的接口代码的时候，就可能需要花时间去理解逻辑，而且一些细节方面我也会不注意，比如｛ 和 ｝另起一行与否，函数方法变量命名要清晰易懂等等，所以我觉得编写编码规范是很重要的，而且对这门语言也会有更加深入的了解。
2、尤其是PHP，不仅仅是语言本身的编码规范，还包括了给其他开发者阅读的接口说明规范，采用标准的接口说明是很重要的，因为接口是提供给其他开发者使用的，如果不清晰不准确，很容易造成数据的错误，这样就失去了接口本身应该提供便利的特性了。
3、所以，代码的编码规范和风格是我们共同讨论出来的，因此我们每个人对这个编码规范是比较熟悉的，在编程的过程中我也希望自己和队友都能够遵循编码规范，提高开发效率。
031402209 黄伟炜
当你是一个孤胆极客时，不遵守编程规范似乎不是一件大事。因为所有的代码只要你能看懂，可以编译通过，能在机器跑起来就行。但是，如果是一个团队。这样的方式，就不可行了。在一个团队，同一份代码，经手的人可能就有好几个。每个人如果都按照自己喜好来编写，将会有不同的缩进、不同注释、不同命名方法。对接手的人来说这是很棘手的，他需要去适应不同人的不同风格。光是看懂代码，都需要不少的时间。但是，有了编程规范，大家只要共同遵守一份规约，就能很愉快的合作写代码了。而不用去适应不同人的不同风格，节省时间成本。
031402233 郑扬涛
对于编码规范，其实早有耳闻，但是平常自己写代码的时候却不是很在意。而且自己在写acm题目的时候，一般会喜欢“压行”，比如说同类型变量全部定义在一行，大括号不换行，使用逗号表达式等等。但是现在我们是作为一个团队，写出来的代码不仅仅只有自己一个人看，代码也不是为了AC而生，遵守编码规范将给团队交流带来极大的便利。网上有各式各样的编码规范，该如何编写属于自己团队的编码规范呢？于是我们团队就开了会讨论此问题，最后整理了一份大纲。我相信如果每个人都能够遵守编码规范的话，那么后期的开发效率将大大提高。
031402341 王婷婷
以前做php项目时都是一个人完成所有编码，所以对于编码、命名基本都是我行我素，想怎么来怎么来，现在由于多人合作，编码规范自然是要考虑的。不做不知道，一做吓一跳，自己之前的代码规范性简直为0啊，估计除了自己也没谁看得懂了。组员们一起讨论了许久，最终编码规范总算是确立出来了。通过这次的编码规范作业，相信以后我的代码应该越来越规范!
三、数据库设计
用PowerDesigner进行数据库的设计
ER图
四、体系结构与界面设计
MVC角度看体系结构
- MVC结构由Model(模型)、View(视图)、Controller(控制器)组成。
MVC将人机交互从核心功能分离出来，模型对于用户来说是透明的，用户只需要观察视图，用户和模型的交互通过控制其提供的安全方法。 - 模型（Model） 包含核心功能和数据和后台的业务逻辑，在模型这一层封装了访问数据的函数，例如查询导师、学生信息，负责人导入新的学生和导师等。这一层对于用户来说是透明的，用户看不到后台对数据库的操作。
- 视图（View） 负责向用户显示信息，不同的角色可以看见的视图不同。用户在视图上与系统进行交互，一些用户的行为（例如填报志愿、选择学生、调整结果等）会触发模型的功能，从而向模型传递数据或者得到模型更新后的数据。
- 控制器（Controller） 与视图一一对应，每个视图都有一个相关的控制器，控制器组件接受事件，并将事件翻译成堆模型或者视图的请求。如果控制器的行为依赖于模型的状态，那么控制器也需要向模型登记请求变更通知。
例如，导师在视图中点击显示学生信息按钮，控制器接到此事件后，调用模型的查询方法，获得数据库对应的信息，再显示到视图中去。导师查看完学生信息后，点击接受某个学生，控制器从视图中读取到此事件，将相关数据传入模型中，模型进行对应的增加操作。
用户角度看体系结构
从用户角度出发，可将体系结构分为 学生、普通导师、系负责人、院负责人四大模块。
以下是四大模块详细描述：
| 模块 | 描述 |
|---|---|
| 学生 | 填报志愿 修改个人信息 查看导师信息 查看志愿结果 |
| 普通导师 | 修改个人信息 设置学生数 选择学生 查看学生信息 |
| 系负责人 | 批量导入学生、导师 手动添加学生、导师 修改学生、导师信息 设置默认志愿数 设置流程期限 选择分配方式 导出分配结果 |
| 院负责人 | 修改分配结果 导出分配结果 设置系负责人 |
体系结构运行流程
- 院负责人首先添加、修改系负责人
- 相关系负责人设置该系导师填报选题起止时间、志愿填报起止时间
- 该系导师在系负责人所设置的报选题时间内填报选题
- 该系学生在系负责人所设置的填报志愿时间内填报志愿导师
- 该系导师在志愿互选时间内选择合适的学生
- 志愿互选时间截止后，该系负责人有权修改、导出分配结果
- 院负责人可再次对系负责人所提交的结果再次修改
- 院负责人课导出并公布分配结果
导师互选系统采用ThinkPHP5框架
ThinkPHP5框架目录
主要应用目录
- database.php 数据库配置文件
用于配置数据库相关信息，例如：数据库类型、服务器地址、数据库名、用户名等。 - Config.php 公共应用配置目录
包含应用设置、模块设置、URL设置、模块设置、异常以及错误设置、日志设置、缓存设置等 - common.php 应用公共函数文件
放置一些较为常用的公共函数，比如弹窗报错等。 - index/controller 控制器目录
包含导师互选系统index模块所需所有控制器 - index/model 模型目录
包含导师互选系统index模块所需所有模型 - index/view 视图目录
包含导师互选系统index模块所需所有视图
界面设计
五、任务分工及比例
| 姓名 | 任务 | 分工比例 |
|---|---|---|
| 陈燊 | 项目管理；把控任务进度；博客撰写 | 14.2 |
| 许玲玲 | 界面设计；原型完善 | 14.3 |
| 胡心颖 | 体系结构设计 | 14.0 |
| 王婷婷 | 体系结构设计 | 14.2 |
| 陈齐民 | 数据库设计；ER图的制作；验证验收标准的改进 | 14.5 |
| 黄伟炜 | 编码规范的整理以及撰写 | 14.0 |
| 郑扬涛 | 改进完善《需求规格说明书》 | 14.8 |
六、燃尽图
七、总结
031402304 陈燊
1、在之前访谈学长时，学长们一直告诫我，作为项目管理者，最重要的责任是把控全局，协调分工，尽量不参与编程。而在本次作业中，我也尝试着去改变自己以往在团队里的角色，尽可能得把任务平均分配给每个组员，并让每个组员负责自己较为擅长的部分，以求取得1+1>>2的效果。此外，为了让项目管理更为清晰便捷，我把每个组员的分工、任务实时更新在github的issues上面，改变了以往QQ繁杂的文件传送，让任务成果的显示更为直观。而通过close/open的次数统计以及燃尽图的生成，让我对整体任务的完成进度有着一个清晰的了解。尝到了issues给项目管理带来的甜果，我才明白了之前的作业里，栋哥为何一而再再而三得强调对git以及issues的使用了。
2、当然，有甜也必有苦。以前总是以程序猿的角色自居，开着PM的玩笑，而如今角色互换，等到自己真正开始做一些类似PM的工作时，才深感PM的不易。我觉得我们团队是一支战斗力挺强的队伍，队员们各有所长，对待项目都有着自己独特而理智的见解。而如何把这一根根强劲的钢丝凝合成一把无坚不摧的利刃，便是PM的职责所在。硬件设施有了，而整个团体系统的上限，则取决于PM对任务成果的把控力度。在本次作业过程中，对于每个组员所完成的成果，我都尽可能一字不落得去审核把关，并提出自己一些建设性的意见。当然，意见的提出总是避免不了意见的冲突，但是有冲突，才会逼迫大家去思考，这才是一个团队前进的最大动力。
3、在一个团队里面，沟通很是重要，特别作为一个PM，更是要把自己的想法一字不漏、毫无歧义得传达给队员们。在本次作业中，我自认为对于沟通这一块，自己做得并不是很好，对于部分任务的意见，没有清晰了当得传达给队友们，导致了任务进度的拖拉。不过在下次作业中，我会努力去改正自己的不足之处，尽量让团队里彼此之间的思想都透明起来。
4、最后，作为这个团队的组长，我会尽一切努力把这个团队给带好，理解每一名组员的想法，也非常非常希望，组员们能够理解组长，共同造就“产品经理程序猿和谐一家”的美好局面！谢谢！
031402342 许玲玲
这次作业我的主要任务是原型的完善，对于原型设计上面，我和PM有很大的分歧，我认为原型的主要目的是揭示和测试系统的功能与实用性；是通过内容喝结构展示，以及粗略布局，能够像用户说明如何与产品进行交互，应该展示的产品逻辑功能。我花更多的时间在交互上面，PM要求原型的美化，这与我的想法大相径庭。让我重新认识了强迫症患者。在下周的编码实现中，不得不打起精神才能满足PM的要求。
031402337 胡心颖
就很气啊。一模一样的图表黑白的说很粗糙，换个背景色就有感觉。Excuseme?刚开始做体系结构设计的时候一脸蒙逼，以前做项目套过MVC的思想，但是不知道那是体系结构。后面突然想起栋哥上课说过，然后开始照着编。虽然知道什么是体系结构，但是不知道怎么表达，我觉得那张图表足够表达了，但是组长半夜叫我们改。然后就又磨蹭了好几个小时，把图表做的不那么“粗糙”，又把图表内容翻译了一下，强行加了文字。虽然整个过程比较折腾，但是跟负责原型的那位同学比就比较知足了。下次开会要去贵一点的店让组长请客。
031402341 王婷婷
本次的系统结构主要是由我和另一组员共同完成，感想颇多啊。刚开始动笔的时候我两几乎是懵逼的，愣了许久，依旧憋不出半个字，认真翻阅课本，以及参考网络资料后，仍是不知从何下笔。无奈之下只能请教栋帅，在栋帅的教导下，似懂非懂地噼里啪啦写了一些。心里想着算是写完了，于是便草草交差了。然，在要求严格的组长大大的严格检查下，当然是得重做啦。看得出组长非常认真地看了我们的作业，也看得出来组长应该是 **处女座** 的吧(好挑剔啊)。挑剔是真的很挑剔，但是大多是很有道理的。于是我和队友又重新讨论、查阅资料、查看需求规格书、翻阅课本，花了将近一下午总算完成了(希望不要在退回来😭)。除此以外，感触颇深的就是原形设计了，上次作业是原型的粗糙版本，这次要求做精致的原型，然后真的是好艰辛啊（虽然说并没有画原型），在组长的严要求下，字体大小不行、文本框没对齐不行... ... 原型一改再改，感觉玲玲身体都掏空了。。。。。。就这两个进行得不大顺利吧，软件规格书、编码规范什么的好像还蛮顺利。
031402203 陈齐民
1、感觉这周组长的分工很合理，每个人都有自己的比较擅长的任务分工，我分配到的任务是 `编写PHP编码规范和代码风格` `修改验收验证标准` `用powerDesigner进行数据库设计和设计E-R图`，终于开始自己比较得心应手的任务了，感觉充满干劲，而且感觉任务压力不会特别大，不像前两周压力那么大。
2、在编写PHP编码规范的时候，发现了自己编码有很多不规范的地方，比如在接口代码部分很少或者甚至没有代码注释，`{` 和 `}` 是否另起一行等等许多细节的问题，这些细节的问题看似对编码没有什么影响，但是在团队合作中，编码过程是有队友一起共同完成的，这些细节对于彼此阅读代码就起到至关重要的作用，所以PHP的编码规范和风格可以帮助我们统一代码风格，做到彼此的代码整合后也能够清晰整洁、阅读性强，提高接口的开发效率
3、其次是数据库的设计，在用 `powerDesigner` 进行数据库设计的时候，因为共用报课系统的数据库，所以需要考虑到很多的问题，在设计 `E-R 图` 的时候会思考到许多功能逻辑方面的点，如何实现比较方便且效率高、有没有漏了什么字段等等，但是有一个比较大的问题，比如报课系统他们原先的表没有主键的设置，而我们需要和他们的表进行表关联的时候就非常头疼，修改了许多遍，但是也有好处，就是对系统的功能逻辑变得更加清晰
4、下周就进入编码冲刺阶段了，但是对于学长报课系统的代码还不是特别的熟悉，下周还有电工实习，希望自己能够合理安排好时间，完成组长分配的任务，和队友一起在规定时间前把Alpha版本开发出来！
031402209 黄伟炜
本周任务包括，修改完善需求规格说明书、确定编码规范、数据库设计、系统结构设计和界面设计，每一项都对项目的进展有举足轻重的影响。有了上次的魔鬼一周的经历，感受到了队友们的强大。这周的心情就是心安安。这次在团队分工中，我负责的部分是编码规范。在平时自己写的小项目中，也有很注意变量的命名，尽量做到见其名知其义，增强可读性。但是，只是知其然。通过这次的作业，我了解到一份编程规范不仅能够增强代码可读性，提高团队协作效率，还能避免一些编程上易犯但隐蔽的错误。还有，能和强大的队友们一起协作，这种感觉真是棒棒哒！
031402233 郑扬涛
这周我的任务主要是修改完善上周提交的需求规格说明书，基本上是对照《GB-T 9385-2008 计算机软件需求规格说明规范》这份国标来修改的。仔细对照国标，发现之前的文档还有许多不完善的地方，存在目录结构不规范，信息冗余等情况，改文档的过程相比写代码是枯燥乏味的，但是如果没有一份详尽的需求规格说明书提供给开发人员的话，那么将会造成后期诸多不必要的麻烦。同时，这周还阅读了《构建之法》第四章中有关编码规范的内容，读后发现有良好的编码规范对于一个团队来说是一件多么重要的事。因此我们开会确定了编码规范，团队编码规范的形成也将对后续开发过程产生有利的帮助。最后，不得不感叹下团队的力量，虽然每周都有高强度的任务要完成，但是大家经常相互交流合作，我相信再难的任务都能啃下来！加油！
