201771030106-葛佳诚 实验四 软件项目案例分析
| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 我的课程学习目标 | 1.学习团队软件项目流程（TSP）与团队成员协作要求； 2.掌握敏捷流程原则及相关概念。 |
| 作业对我实现学习目标的帮助 | 1.掌握团队项目开发的大致流程与相应的要求； 2.了解了敏捷开发流程的基本原则。 |
| 结对方学号-姓名 | 201771030103-陈正丽 |
| 结对方本次博客作业链接 | https://www.cnblogs.com/chenzhengli-/p/12669822.html |
任务一. 在实验三得分100分以上作业中，任选一份作为案例，对案例项目成果进行评价
（一）. 案例作业博客链接
https://www.cnblogs.com/hackerZT-7/p/12544280.html
（二）. 案例作业项目仓库链接
https://github.com/YHwzt/Query-system-web
（三）. 案例作业博客评论
博客评论见下图1.3.1
图1.3.1 博客评论
（四）. 案例作业系统运行截图、软件功能总结
首先下载项目源代码至本地，之后导入IDEA并配置相应的环境如图1.4.1。
图1.4.1 IDEA
之后配置数据库文件如图1.4.2。
图1.4.2 数据库配置
在数据库、项目环境等配置完成后开始运行如下，首先是用户登录页面：
图1.4.3 用户登录
进行用户的注册如下图1.4.4，可见用户注册成功。
图1.4.4 用户注册
在登录了注册的用户后，即可开始进行疫情信息的上报，详见图1.4.5与图1.4.6，可见信息录入成功。
图1.4.5 用户信息录入
图1.4.6 信息录入完成
使用上述方式注册管理员账户并登录系统见图1.4.7，管理员可通过多种方式查询成员录入的信息。
图1.4.7 管理员界面
此外，在系统的使用过程中，我也发现了一些问题与不足，除却注释等文字性内容较少外，在这里列举两个实际运行中存在的情况。
1. 系统在进行用户的注册时，相同的用户名可以进行多次的注册且均能注册成功，这一点见图1.4.8，虽然系统在用户登录时选择的是第一个注册的用户，之后注册的密码不同的用户无法正常登录（图1.4.9），但是这些重复用户在数据库中仍然存在。
图1.4.8 重复用户注册
图1.4.9 重复用户登录
2. 虽然有可能是我的电脑上的环境问题，项目在进行个别页面跳转或有一些违规数据输入时会产生白页错误如图3.4.10，需要手动进行页面的重定向。
图1.4.10 白页异常
经过基本的使用发现，该系统的功能较为完善，学生、教师等普通用户可以疫情防控信息的填报，系统也提供了信息填报的定时提醒功能；各学院负责人或学校负责人可以登录后台查询本部门或学校成员的疫情防控信息填报情况。同时，项目在GitHub中也提供了数据库与代码规范说明，项目的博客也能较好的帮助项目的运行与理解。总的来说的确是一次成功的结对编程项目。
（五）. 本组作业总结，系统问题分析
通过对其他结对小组项目的学习，我们也总结了一些在我们的项目中存在的不足：
1. 在博客作业中，我们的博客排版存在问题，图片都显得过大。此外，一些具体的细节功能在说明的措辞方面有点问题；
2. 在项目系统中，我们采用的方式为用户信息录入为网页录入，而管理员信息查询在本地应用中进行，这种方式可能会显得有些杂乱且由于两部分分隔开来，使得部分功能的实现会较为复杂。此外，在我们的项目系统中并没有提供用户防疫信息填报的定时提醒等功能。之后是数据库方面的问题，由于数据库中的数据过多，使得在进行首次的数据查询时会有1-2秒的停顿。最后，从页面的布局等方面来说，我们的项目仍然有提高的空间。
总之，我们的项目中仍然存在有许多问题与不足，通过这次的学习，我们对我们项目中存在的一些缺陷与问题有了更加清晰的认识，这都是我们在之后的学习中需要改进的。最后，希望我们在之后的实验项目中能够吸取经验教训，做得更好。
任务二. 与实验三结对伙伴协作学习《现代软件工程—构建之法》第5-6章内容
我们此次学习主要方式为：个人首先阅读书籍进行学习，由一人进行学习内容的总结，之后将总结的内容发送给结对伙伴，结对伙伴根据自己的学习成果，对同伴的总结内容进行添加修改，之后两人进行交流。
（一）. 学习成果展示
此次学习中总结出的部分重点内容如下：
1. 软件项目团队的特点
（1）. 团队有一致的集体目标，团队要一起完成这个目标。
（2）. 团队成员有各自的分工，互相依赖合作，共同完成任务。
2. 软件团队的模式
目前软件团队的模式主要有以下几种，目前我们在实际的团队项目开发中使用的最多的应该是主治医师模式与业余剧团模式：
（1）. 一窝蜂模式：最初的十分随意的软件团队模式，经过一段时间的演变将转变为后续的其他模式；
（2）. 主治医师模式：首席程序员负责主要模块的设计与编码，其他成员从不同角度提供支持；
（3）. 明星模式：主治医师模式运用的极点，团队“明星”的能力掩盖了团队所有人的缺陷与优点；
（4）. 社区模式：成员分布不受时间空间的限制，所有人根据喜好选择项目进行开发，一般不要求报酬；
（5）. 业余剧团模式：没有固定的团队，且成员在不同的项目中没有固定的工作分配，所有成员由“中央指挥”指示；
（6）. 秘密团队：秘密状态下进行，无外界干扰，团队肩负独特使命，内部成员自由度与热情较高；
（7）. 特工团队：团队由专业人士组成，负责一些紧急问题的解决（如此次新冠疫情）；
（8）. 交响乐团模式：较多大型软件公司采用，成员与领导者能力较强且有相似的项目开发经验，所有成员各司其职但统一受领导者指挥；
（9）. 爵士乐模式：与交响乐团模式对立，较为松散，领导者完成框架，其他成员在此基础上创作，最后再由领导者收尾；
（10）. 功能团队模式：没有固定的团队，由不同能力的成员进行组合，协作完成某一项目，项目完成后成员重新组织进行其它不同项目；
（11）. 官僚模式：脱胎于大机构的组织架构，几人向小头目报告，小头目向大头目报告。容易形成恶性竞争。
3. 瀑布模型及其变形
瀑布模型产品遵循 [分析→设计→实现（制造）→销售→维护] 这一流程，其描述了单项的、不可逆的生产过程。由于严格的瀑布模型存在诸多缺陷，因此温斯顿提出了对瀑布模型的改进如图2.1.1，其中他提出了相邻步骤间的回溯与模型的再运行以收集反馈进行产品改进，他也强调了文档的重要性。
图2.1.1 改进的瀑布模型
瀑布模型的局限性如下：
（1）. 各步骤之间是分离的，但是软件生产过程中各个步骤不能这样严格分离出来；
（2）. 回溯修改很困难甚至不可能，但是软件生产的过程需要时间回溯；
（3）. 最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。
瀑布模型主要适用于以下情况：
（1）. 如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证；
（2）. 产品模块之间的接口，输入和输出能很好地用形式化的方法定义和验证；
（3）. 使用的技术非常成熟，团队成员都很熟悉这些技术。
（4）. 负责各个部分的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。
瀑布模型的变形主要有生鱼片模型、大瀑布带着小瀑布、子瀑布模型等，但每个模型均有其缺陷。
4. 渐进交付流程
渐进交付流程由史蒂夫·迈克康奈尔与1996年总结，较接近于迭代式开发流程。其主要指当系统的主要需求和架构明确后，软件团队将进入如图2.1.2所示的循环中，该循环将一直进行直至项目的资金不足、项目时间不够或产品能使用户满意为止。
图2.1.2 渐进交付流程循环
5. 敏捷流程
在软件工程中“敏捷流程”是指一系列价值观与方法论的集合，其与现有的做法对比如图2.1.3。
图2.1.3 对比图
敏捷流程遵循以下开发原则：
（1）. 尽早并持续地交付有价值的软件以满足顾客需求；
（2）. 敏捷流程欢迎需求的变化， 并利用这种变化来提高用户的竞争优势；
（3）. 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短；
（4）. 业务人员和开发人员在项目开发过程中应该每天共同工作；
（5）. 以有进取心的人为项目核心，充分支持信任他们；
（6）. 无论团队内外，面对面的交流始终是最有效的沟通方式；
（7）. 可用的软件是衡量项目进展的主要指标；
（8）. 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去；
（9）. 只有不断关注技术和设计，才能越来越敏捷；
（10）. 保持简明————尽可能简化工作量的技艺————极为重要；
（11）. 只有能自我管理的团队才能创造优秀的架构、需求和设计；
（12）. 时时总结如何提高团队效率，并付诸行动。
图2.1.4 Scrum
敏捷流程下有诸多的方法论，其中Scrum这一方法论的流程如上图2.1.4，其主要分为以下四步：
（1）. 找出完成产品需要做的事情——Product Backlog；
（2）. 决定当前的冲刺（Sprint）需要解决的事情——Sprint Backlog；
（3）. 冲刺。期间团队通过每日例会（Scrum Meeting）进行面对面交流，所有人向同伴报告进度。Scrum Master根据项目情况，用简明的图表展现整个项目的进度（燃尽图Burn Down Chart、看板图Kanban）；
（4）. 得到软件的一个增量版本，发布给用户。然后在此基础上又进一步计划增量的新功能和改进；
6. TSP原则
TSP原则主要有以下七点：
（1）. 使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的；
（2）. 团队的各个成员对团队的目标、角色、产品都有统一的理解；
（3）. 尽量使用成熟的技术和做法；
（4）. 尽量多地收集数据（也包括对团队不利的数据）,并用数据来帮助团队做出理性的决定；
（5）. 制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定（而不是从上级而来）；
（6）. 增加团队的自我管理能力；
（7）. 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作（而不是在后期匆忙修复问题）。
（二）. 学习过程展示
此次学习中结对双方总结的部分文档如下图所示：
图2.2.1 内容总结 1
图2.2.2 内容总结 2
此次学习中结对双方的部分主要交流内容如下图所示：
图2.2.3 学习交流 1
图2.2.4 学习交流 2
（三）. 学习总结
通过这次学习，我们对软件开发团队的组成要求与基本的团队软件开发流程都有了一定的理解，清楚了现在常见的一些团队合作方式与软件开发流程，同时我们也知道了一个合格的、好的开发团队需要具有的一些基本要求等等。总的来说，这次阅读学习为我们之后的团队软件开发提供了一定的理论基础，相信我们在之后的实验中能够做好我们的工作，完成我们的团队项目。
任务三. 从博客园的三个班级中选择一个高质量的团队项目案例进行协作学习
（一）. 团队项目作业发布账号链接
https://www.cnblogs.com/LightOfFuture/
（二）. 团队项目仓库GitHub链接
https://github.com/ThinMoon/ESchool
（三）. 选择该团队项目进行分析的原因
1. 由于我们平常与学校内的人员接触较多，因此想选择外校学院的团队项目进行学习；
2. 由于在外校的团队项目中，移动应用程序开发较多，而我们对移动应用开发不够熟悉，因此选择了其他的团队项目；
3. 经过大致浏览，所有的团队项目中，这一个团队的项目我们较为感兴趣，比较贴近我们的校园生活。
（四）. 项目团队成员的分工合作情况
该项目团队共有10人，团队分工情况在前期文档编写阶段与后期编码测试阶段不同。具体分工合作情况如下：
1. 在前期文档编写阶段，分组情况多是每个人各自负责一部分文档编写，没有因为某一项内容工作量大而多分配人员。其中，一人负责原型设计与文档编写，一人负责上台报告与PPT的撰写，两人负责文档完善工作，两人负责原型完善工作，其余四人分别负责评分样式表、功能完善、GitHub配置与博客的撰写。
图3.4.1 团队分工
2. 如图3.4.1，在后期编码测试阶段，分组情况多是几个人合作实现某一项功能，只有工作量较小的工作由个人完成。其中，一人由于能力相对较强，负责校园兼职模块的编写，另外一人负责后期文档编辑，其余八个人两两分组，分别进行前端界面编写、后端界面编写、校园顺风车模块编写与校园代取代取模块。
（五）. 项目的软件项目过程特点
从项目博客来看，该项目的过程特点主要有以下几点：
1. 项目团队中的所有成员都有详细的分工安排，成员对其项目目标与各自工作内容都有较为明确的认识；
2. 尽管团队成员中有部分人对一些技术掌握不够，但是通过学习，项目中使用的技术如Maven、SSM、bootstrap等均是现在的成熟的技术；
3. 项目有团队内部负责具体执行的的成员制定了较为实际的计划，然后根据计划开展项目；
4. 项目团队分工明确，团队成员自我管理能力较强；
5. 虽然项目的流程在博客中体现的不够明确、项目相关数据收集不够全面使得有部分功能不够完善，但是团队在此次开发的最后进行了此次项目开发经验的总结。
（六）. 团队项目GitHub仓库源代码文件结构分析
该团队项目GitHub页面如下图3.6.1所示。
图3.6.1 GitHub
该团队项目GitHub上的源代码结构较乱，虽然有测试用例报告与README文件，但是没有项目的编码规范等文档。除此之外，该项目使用的数据库文件并没有上传至GitHub，且没有安装文档。
总的来说，该团队的GitHub仓库结构较乱，许多文档文件都没有上传至GitHub，这也是我们在浏览各个团队的项目的过程中发现的许多项目团队都存在的问题，这一点在我们以后的项目开发中需要着重注意的。
（七）. 团队项目软件部署与测试运行
在团队的GitHub仓库中下载代码至本地，再导入至IDEA中，项目的导入情况如图3.7.1，由于项目所用的环境与我的电脑上的环境不同（JDK版本、Tomcat版本与MySQL版本等），因此也进行了JDK、Tomcat的重新配置与jar包的导入。
图3.7.1 IDEA
由于项目没有提供相应的数据库文件，为保证项目正常运行，我们根据该团队在博客中如图3.7.2的数据库设计图与代码中的数据库查询语句等创建了对应的数据库文件如图3.7.3。
图3.7.2 数据库设计图
图3.7.3 数据库详细设计
在完成数据库创建并修改相应连接代码之后，运行服务器，项目主页如图3.7.4。
图3.7.4 网页首页
图3.7.5 用户登录
在一段时间的使用之后，发现这个项目存在有不少的问题，详细情况如下：
图3.7.6 用户注册
图3.7.7 Bug1.1
图3.7.8 Bug1.2
如图3.7.6，在用户的注册流程中，将基本信息填写完成的情况下点击注册将生产如图3.7.7的错误，身份证号码一栏的数据没有传输至后台，在检查了项目代码之后发现在网页中如图3.7.8的错误，身份证号码一项的name被省略了，这里不知道是从一开始就有错误还是该团队在后期修改的过程中无意间进行了改动，在修改了该属性后，程序注册流程得以正常进行。
在上述的错误说明中，可以发现这里直接表示点击注册，而不是根据手机号获取验证码，这是因为获取验证码这一功能无法使用且没有被使用，也就是说无论有没有验证码，手机号是否正确，用户均可完成注册。
图3.7.9 Bug2.1
图3.7.10 Bug2.2
图3.7.11 Bug2.3
在用户注册过程中，还存在有一个问题，同一个手机号码可以注册无限个账号，无论用户名、密码相同还是不同，用户均可注册。详细情况如图3.7.9，在数据库中可以看到这里已经通过上述方式注册了两个完全一样的账号，而如图3.6.6再次注册一个密码不同的账号后，数据库中仍然添加了数据如图3.7.10，之后进行登录将直接报出错误如图3.7.11。
在上述测试过程中，还存在一个问题，在该项目中，没有进行异常错误的拦截与处理，所有的错误异常会直接暴露出来，在一个正式的软件项目中这一点绝不应该出现。
图3.7.12 Bug3.1
图3.7.13 Bug3.2
在正常登录用户后，用户的个人页面如图3.7.12与图3.7.13，可见用户的信息并没有同步显示在前端网页中，用户信息修改与密码修改按钮相应的方法并没有实装，在我的订单中仅仅是通过html代码显示了几个不存在的订单。
图3.7.14 Bug4.1
图3.7.15 Bug4.2
图3.7.16 Bug4.3
在订单发布中，填写如图3.7.14信息并提交可见提交结果如图3.7.15，提交成功后返回上一页面，结果如图3.7.16，数据提交成功，但是填写当天实际的日期是4月9日，这里选择日期为4月8日进行订单的发布，此时订单发布成功显然不够合理。
除了上述各种问题以外，仍然有其他Bug与可优化内容存在，如首页的图片显示、整体页面的美化、用户登录与订单发布成功的结果界面与其他的订单填写中存在的Bug等，此处不再说明。
（八）. 团队项目前景
对于这个团队项目，虽然目前存在许多问题，但是它的选题较好，比较符合当前大学生的实际需要，因此这一项目比较值得进一步的开发，当然如果进行进一步开发，其功能也需要扩展。
（九）. 总结
通过阅读学习其他学校团队的软件工程团队项目成果与博客，我熟悉了团队项目开发的基本流程，对团队成员之间的分工协作形式等有了更加深刻的了解，这为我们之后将展开的团队项目提供了许多经验，同时我们也从中了解到了一些基本的错误与不足，这都是我们在项目开发中需要注意的。最后，希望我们之后的团队项目能够顺利进行。
任务四. 任务时间记录与总结
（一）. 各项实验任务的时间记录如下
| 任务内容 | 实际完成需要的时间（h） |
|---|---|
| 任务一 | 6 |
| 任务二 | 2 |
| 任务三 | 4.5 |
| 任务四 | 3 |
（二）. 实验总结
在此次实验中，我们从实验三优秀案例分析、《构建之法》的阅读学习与其他班级团队项目案例学习三个方面展开进行，从对上一次实验的分析与经验总结到软件开发团队相关知识的掌握再到实际的团队软件项目分析，可以说我们这次实验都是在为之后的团队项目进行准备。任务一中我们总结了其他队伍的作业的优点与我们自己的作业中出现的不足之处，可以说提醒了许多我们在之后的团队编程中需要注意的事项；任务二中我们学习了基本的团队开发模型与流程，为之后的团队开发提供一定的理论基础；任务三中则是对实际的团队项目进行分析与总结，找出他们的优点与不足，学习他们的优点，并避免与他们犯类似的错误。具体的其他方面由于每个任务的简单总结与感受在上面都有说明，这里不再赘述。
总之，在这次实验中，我们从不同方面学习到了很多在之后的团队开发中需要用到的知识，希望通过这次的学习，我们能在之后的团队开发中取得较好的成果。
