| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 课程学习目标 | 学习团队软件项目流程、团队成员协作要求；掌握敏捷流程原则及相关概念。 |
| 本作业在哪些方面帮助我实现学习目标 | 通过进一步和结对同伴的学习，提升团队合作的能力和意识。 |
| 结对方学号-姓名 | 201771010108-韩腊梅 |
| 结对方本次博客作业链接 | https://www.cnblogs.com/hanlamei/p/12641088.html |
一.实验三得分100分以上作业中，选一案例进行评价
1.实验三优秀案例推荐：李婷华&王颖奇组
（1）该组项目仓库链接。
（2）评论截图如下。
2.体验案例项目源码，总结问题，体会案例博文
2.1 clone该组案例项目到本地进行测试。
2.2 阅读项目代码规范文档如下。
2.3 运行代码。
（1）设置提醒闹钟，但未提示该如何填写。
（2）登录初始界面。
（3）学生登陆。
（4）填报界面。
（5）二级负责人登录界面。
（6）负责人查看等功能。
（7）学校负责人登录。
（8）可视化查看。
（9）导出excal。
（10）闹钟提醒。
2.4 代码运行bug
(1)Bug1填报信息后报错，但提示填写成功。
(2)Bug2添加功能未做边界检查，不输入信息也能够添加空行。
(3)Bug3修改按钮没有设置的意义，双击表格即可修改。
对于该处Bug，该项目成员提出疑惑，再次进行测试，测试结果如下。
添加修改之前，下一步对选中行进行修改。
双击修改之后可以看到，界面表格中已经成功修改。
查看数据库，信息并未同时修改。
选中要修改的那一行，在修改框中输入要修改的内容，点击修改按钮。
刷新数据库，但数据仍未变化。
出于个人的能力问题，也可能是我的测试方式有错误（如果我的测试方法是错误的，我想大部分人测试时或者这个系统假如被推广运行时，大部分人都会产生跟我一样的测试问题，建议该团队能够在这里加上如何操作的提示性文字，或者写个文档），但这是我能想到的最普遍的修改操作了。在这里我有个问题，我们设计出的程序软件，难道要让每一个用户都读懂代码，理解思维逻辑之后才能够使用吗？
有这样的一句话我觉得非常受用“开发团队甚至要比用户更加清楚用户的需求”，用户是不懂什么逻辑符号的，如果所有的用户都能懂开发人员的痛苦，我相信这个世界将会变得更加美好。
(4)Bug4统计图未根据条件查询变化。注：此处为代码逻辑不严谨，而不是功能错误。在测试该部分功能时，由于我的个人问题，未站在该团队的角度去考虑需求，而是一昧的按照自己的想法去测试，导致过于注重追求功能上的完美，而忽略了代码逻辑。
(5)Bug5闹钟音乐并没有响，但控制台在到达设置时间后提示可以播放。
2.5 运行案例项目代码总结
经过为期一周的测试运行，我得出以下结论。该项目程序的功能较为完善，学生/教职工等人员可以进行疫情防控信息的填报，程序也提供了信息填报的定时提醒功能（但得手动操作）；各学院负责人或学校负责人可以登录后台查询本部门或学校成员的疫情防控信息填报情况。同时在GitHub中也提供了代码规范说明（但可能是时间不够的原因未提供数据库文件），代码也很好的遵循了自己制定的代码规范说明。博客文章对功能的介绍比较详细，也能够帮助我对项目的运行和理解。总的来说比较成功。
功能部分首先是登陆初始界面不够漂亮，其次闹钟提醒设置，该功能是设置在运行程序之后登陆之前的，填报人员如果都已经打开软件要填写了，这时候再设置闹钟的意义好像就emm。还有就是未设置导出按钮，导出excal弹窗只在点击填报情况统计图之后才弹出。
未实现功能为不能查询一段时间（某周某月）疫情。
3.总结本组实验三的问题与不足
通过对选取的案例项目学习和其他同学博文的浏览，我也再次发现了本项目组的以下缺点：
本组的博客作业内容较为充实，但还是存在一些问题，图片裁剪有些大小不一。而且在一些专业术语的表达方面就有些不专业。
在项目开发的过程中，本组采用web端页面填报操作和负责人对信息的查询操作，对功能的实现较为全面。但是在编写代码时未考虑到他人的读代码的能力，未注释足够且必要的文字性解释。而且在后期的修改当中未将多余的测试代码一并删除，更加给读代码的同学添加了障碍。而且在修改代码过程中的一些操作可能破坏了自己制定的编码规范却未来得及更正。更重要的是对用户的注册未添加足够的边界检限制查。导致重名用户可多次注册。
综上，本项目仍然存在有许多问题与不足，通过这次的项目开发学习和其他同学的测试意见。我对本项目中存在的一些漏洞与缺点有了更加清晰的认知，在以后逐渐修改本项目出现的漏洞，且在以后的项目开发中尽量避免再犯此类错误。和大家一起共同进步，一起提升。
二.协作学习：阅读《现代软件工程—构建之法》第5-6章内容
1.理解并掌握软件项目团队的特点。
软件团队的特点级本可总结为一下两点:
-
团队有一致的集体目标
-
团队成员各自又自己的分工,互相依赖合作,共同完成任务
2.了解软件团队的模式。
软件他团队主要有一下模式:
-
一窝蜂模式：最初的一窝蜂形式的软件团队模式，经过一段时间的演变将转变为其他模式；
-
主治医师模式：首席程序员负责主要模块的设计与编码，其他成员从不同角度提供支持；
-
明星模式：主治医师模式运用的极点，团队“明星”的能力掩盖了团队所有人的缺陷与优点；
-
社区模式：成员分布不受时间空间的限制，所有人根据喜好选择项目进行开发，一般不要求报酬；
-
业余剧团模式：没有固定的团队，且成员在不同的项目中没有固定的工作分配，所有成员由“中央指挥”指示；
-
秘密团队：秘密状态下进行，无外界干扰，团队肩负独特使命，内部成员自由度与热情较高；
-
特工团队：团队由专业人士组成，负责一些紧急问题的解决（如此次新冠疫情）；
-
交响乐团模式：较多大型软件公司采用，成员与领导者能力较强且有相似的项目开发经验，所有成员各司其职但统一受领导者指挥；
-
爵士乐模式：与交响乐团模式对立，较为松散，领导者完成框架，其他成员在此基础上创作，最后再由领导者收尾；
-
功能团队模式：没有固定的团队，由不同能力的成员进行组合，协作完成某一项目，项目完成后成员重新组织进行其它不同项目；
-
官僚模式：脱胎于大机构的组织架构，几人向小头目报告，小头目向大头目报告。容易形成恶性竞争。
3.理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点。
瀑布模型是一个经典的软件生命周期模型，也叫预测型生命周期、完全计划驱动型生命周期。在这个模型里，在项目生命周期的尽早时间，要确定项目范围及交付此范围所需的时间和成本。
在这个模型里，项目启动时，项目团队专注于定义产品和项目的总体范围，然后制定产品（及相关可交付成果）交付计划，接着通过各阶段来执行计划。应该仔细管理项目范围变更。如果有新增范围，则需要重新计划和正式确认。对于经常变化的项目而言，瀑布模型毫无价值。
以下情况优先选择这种生命周期：项目需求明确、充分了解拟交付的产品、有厚实的行业实践基础、或者整批一次性交付产品有利于干系人。例如开发一个软件项目时，如果采用这个模型的话，一般将软件开发分为可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段。
瀑布模型的局限性:
-
各步骤之间是分离的，但是软件生产过程中各个步骤不能这样严格分离出来；
-
回溯修改很困难甚至不可能，但是软件生产的过程需要时间回溯；
-
最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。
瀑布模型的适用范围：
-
如果产品的定义非常稳定，但是产品的正确性非常重要，需要每一步的验证；
-
产品模块之间的接口，输入和输出能很好地用形式化的方法定义和验证；
-
使用的技术非常成熟，团队成员都很熟悉这些技术。
-
负责各个部分的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流。
瀑布模型的变形主要有生鱼片模型、大瀑布带着小瀑布、子瀑布模型等，但每个模型均有其缺陷。
渐近交付的流程图如下:
敏捷流程的原则有以下12点:
-
尽早并持续地交付有价值的软件以满足顾客需求；
-
敏捷流程欢迎需求的变化， 并利用这种变化来提高用户的竞争优势；
-
经常发布可用的软件，发布间隔可以从几周到几个月，能短则短；
-
业务人员和开发人员在项目开发过程中应该每天共同工作；
-
以有进取心的人为项目核心，充分支持信任他们；
-
无论团队内外，面对面的交流始终是最有效的沟通方式；
-
可用的软件是衡量项目进展的主要指标；
-
敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去；
-
只有不断关注技术和设计，才能越来越敏捷；
-
保持简明---尽可能简化工作量的技艺---极为重要；
-
只有能自我管理的团队才能创造优秀的架构、需求和设计；
-
时时总结如何提高团队效率，并付诸行动。
4.理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则。
TSP原则主要有以下七点：
-
使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的；
-
团队的各个成员对团队的目标、角色、产品都有统一的理解；
-
尽量使用成熟的技术和做法；
-
尽量多地收集数据（也包括对团队不利的数据）,并用数据来帮助团队做出理性的决定；
-
制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定（而不是从上级而来）；
-
增加团队的自我管理能力；
-
专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作（而不是在后期匆忙修复问题）。
5.讨论截图展示
我和同伴采用的是自主学习总结之后互相提出疑惑和提问的方式讨论学习。
三.选取一院校团队项目测试分析
1.选取北京航空航天大学2019春季计算机学院软件工程的PureMan团队项目
1.1 团队项目作业发布账号链接。
1.2 团队项目github仓库链接。
1.3 选择该团队项目分析的理由
因为本课程的所有作业发布等都在博客园，我们不可能时时刻刻带着电脑在身边，所以移动端的博客园就显得尤为重要，而博客园手机版总是存在一些问题，该团队项目很好的解决了这一问题，而且项目质量也很高，并且已经上线使用。源代码仓库等也很齐全，方便我们下载测试。更重要的是本组成员未有过app开发的经历，所以选择该项目能促使我们惊进行一些相关知识的学习和理解。为以后的学习等打下一些基础。所以我们选择了这个团队的项目进行深入测试探究。
2.总结该团队成员分工合作情况
首先从这篇阶段项目展示可以得知该团队名称为PureMan6的团队总共有7个人,并且七个人分工各不相同，有两个PM和PM测试人员，四个开发员，有一个软件测试人员。四个开发人员在项目不同阶段分工也大不相同，大致如下图所示。在不同的阶段每个人都有不同的任务，并不是一个任务从头到尾进行下去，这样对团队成员的任务分配合理又高效，是一种非常不错的的团队开发模式。
3.评价项目的软件项目过程特点（TSP）
观察该团队的项目系列博客后，发现该项目的TSP主要包含以下几点：
-
并不是所有的团队成员都掌握了全部的开发知识和技术，都是在开发中学习，在学习中开发；
-
项目团队中的每个成员都非常明确本团队的开发目标，对自己的所扮演的角色都了然于心，而且对自己开发的产品都有哦这一致统一的理解。
-
项目团队前、中、后期都在不断地收集数据和用户反馈。
-
项目团队的每个成员都制定了较为细致的计划，然后按计划进行项目研发；
-
团队成员的自我管理能力很强，基本每个阶段都有例会；
-
项目的流程在博客中体现比较明确，而且在早期发现了很多问题，设计工作非常全面且细致。
4.该团队项目github仓库的源代码文件结构，是否包含代码规范文档？
团队项目github仓库的源代码文件结构如下图。
该团队GitHub上的源代码结构较差未有一些必要的开发说明和README文件，且没有项目的编码规范等文档。对于他人的二次开发有些不友好。可能是因为时间的问题，纵观所有的团队项目，都很少有包含文档较为全面的项目，我自始至终都认为，文档的撰写要比开发的质量更加重要。
5.下载团队项目代码，尝试部署并使用，描述使用体验，找出至少两个功能性bug
5.1 测试代码与使用体验
(1)从仓库中clone源码到本地测试。
(2)在安智市场app里面，搜索软件名称“CnblogAndroid”下载，测试机为安卓系统。下载完之后打开的登录界面优美，和网页端登录样式一致，如下图所示：
(3)并且登录之后会有一个验证环节，验证界面也很美观，如下图所示：
(4)此外软件功能齐全，看到自己发布的博客，还可以看到自己所在班级的其他同学的博客,如下图所示：
(5)并且还有很多附加功能，比如：日程提醒、收藏列表、浏览记录、设置以及对app的一个简单介绍，如下图所示：
(6)值得一提的是其可以设置黑暗模式，并且效果很棒，晚上使用黑暗模式，极大程度上减少了对眼睛的伤害。如下图：（虽然提示部分页面暂不支持黑暗模式，但能想到这个创意还是很棒的！）
5.２ bug的指出
(1)每隔较短时间就会提示“身份信息过期，请重新登录”，但是目前的身份信息并没有过期，我依然可以进行所有的操作
(2)博文作业中的表格线未显示，多次尝试亦如此
(3)部分博文页面布局不合适
(4)在“我的班级”页面点击“博文”，会出现一个筛选功能，选择“老师/助教”，但出现的依旧是班级同学的博客
6.评价该团队项目是否值得继续开发，并陈述理由
我们团队认为该团队项目值得继续开发。因为目前我们提交博文作业，查看博文作业要求都使用博客园的网页版，大多同学没有在手机浏览器中登录博客园的习惯，从而导致每次登录博客园都需要打开电脑，如果遇到刚好没有在家又需要查看博客园的情况，大多同学会选择等回家之后再查看，而这款app它可以满足我们在手机端查看博客以及评论等功能，并且界面也好很看。既然有用户需求，并且开发费用较小，所以该团队项目还是非常值得继续开发的。
四.记录完成《实验四 软件项目案例分析》各项任务实际花费的时间
| 任务 | 花费时间(h) |
|---|---|
| 任务一 | 2.5 |
| 任务二 | 5 |
| 任务三 | 10 |
| 任务四 | 2.5 |
五.请谈谈完成本次作业的感受和体会。（5分）
通过测试其他高校的软件工程团队项目与博客阅读学习，对我的感触很大.认识到了自己的很多不足之处,也发现了自己的一些独特之处。值得我学习的地方有很多,让我知道了什么叫做山外有山,楼外楼。比起大佬们,我并没有什么值得骄傲的成绩,在以后的学实习生活当中,确实应该将自己沉淀下来,虚心学习讨教。
本次学习相当于让我走了很多遍团队项目的流程,有很多开发经验和技术值得学习借鉴。这对我以后的团队项目当中有很重要的作用。