| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 这个作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 我的课程学习目标 | 学习并优秀案例 |
| 这个作业在哪些方面帮助我实现学习目标 | 学习优秀案例对系统设计以及框架有进一步的理解 |
| 结对方学号-姓名 | 201771010124-王海珍 |
| 结对方本次作业链接 | https://www.cnblogs.com/www-whz-1997/p/12675201.html |
1、实验目的与要求
（1）学习团队软件项目流程（TSP）、团队成员协作要求。
（2）掌握敏捷流程原则及相关概念。
2、实验内容和步骤
任务1：在实验三得分100分以上作业中，任选一份作为案例，对案例项目成果进行评价，具体要求如下：
（1）对案例博文作业进行阅读并进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系，并将以上评论内容发布到案例作业的博客评论区。
案例作业博客链接：https://www.cnblogs.com/hanlamei/p/12574378.html
案例作业项目仓库链接：https://github.com/YHwzt/Query-system-web
（2）克隆案例项目源码到本地机器，阅读项目代码规范文档并运行代码，总结代码运行中存在的问题，体会案例博文是否有助于项目代码理解。
#####（3）总结本组实验三博客作业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。 附加分要求：若测试发现案例代码存在bug，截图为证，一个bug得2分，本次作业附加分最高不超过10分； 符合（3）要求的总结，代码运行存在的问题截图为证（10分）。
a、二级防疫负责人在进行学号准确查询时可以查询到所有成员的信息，但是在姓名模糊查询和时间准确查询时却只能查询到本部门成员的信息
b、系统对用户输入的控制比较低，比如完全不进行输入也可以实现添加，时间统一为1900年1月1号。输入完全相同的信息也不会报错。
c、系统对闹钟的用户输入没有控制，不管输入什么，程序都正常运行。
任务2：与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；
软件项目团队的特点：
| 特点 | 如何理解 |
|---|---|
| 1、 具有明确且有挑战性的共同目标 | 一个具有明确的而且有挑战性目标的团队比目标不明确或不具有很大的挑战性目标的团队效率高得多，通常技术人员往往会因为完成了某个明确的任务，而且这个任务的完成具有挑战性的意义而感到自豪，反过来团队成员为了获取这种自豪的感觉而更加积极的工作从而带来团队开发的高效率，如作为系统设计人员很清楚的知道在什么时候要做到什么，什么时候开始做，什么时候必须完成，为了完成工作必须面临哪些挑战，怎么解决这些困难等为设计出一个高质量的软件项目提供了重要保证，而模模糊糊的去设计一个系统或模模糊糊的就去编写代码是非常危险的，而且会为此付出高昂代价，因此高效的软件开发团队具有挑战性的共同目标。 |
| 2、 团队具有很强的凝聚力 | 在一个高效的软件开发团队中，成员们凝聚为一个整体共同进行工作，他们是相互支持、互相交流、互相尊重的，而不是相互推卸责任、保守、相互指责的，在一些散乱的开发团队中往往存在这样的问题，一些程序员是比较保守的，明明知道另外的模块中需要用到一段与自己已经编写完成但有些难度的程序代码，他也不愿拿出来给其它程序员共享，不愿与系统设计人员交流，这样给项目的进度造成了些不可度量的因素。 |
| 3、 具有融洽的交流环境 | 在一个开发团队中，每个人行使自己的职责，如需求分析人员制定需求规格说明、系统设计人员做系统概要设计和详细设计、项目经理配置项目开发环境并且制定项目计划等，但每个人的工作不可能做到完美的，如系统概要设计的文档可能有个别地方词不达意，做详细设计的时候就可能会造成误解，项目经理制定计划时可能忽略了某种风险的存在而造成执行者过于紧张的压力等等情况都需要大家通过交流、反馈的手段然后协商解决的，因此高效的软件开发团队是具有融洽的交流环境的，而不是那种简单的命令执行式的。 |
| 4、 具有共同的工作规范和框架 | 高效软件开发团队具有规范性及共同框架的工作，对于项目管理具有规范的项目开发计划，对于分析设计具有规范和统一框架的文档及审评标准，对于代码具有程序规范条例，对于测试有规范且可推理的测试计划及测试报告等等。并且所有成员都明白自己的职责，知道必须完成什么计划？由谁来完成？什么时候开始？什么时候结束？按什么顺序？等，总之一个高效的开发团队无论是工作内容还是工作流程都具有不同程度的规范性和标准风格的框架。 |
| 5、 采用合理的开发过程 | 软件的开发不同于一般商品的研发和生产，开发过程中会面临着各种难以预测的风险，比如需求的变化、人员的异动、技术的瓶颈、同行的竞争等，高效的软件开发团队往往是采用了合理的开发过程去控制开发过程中的风险、提高软件的质量、降低开发费用，这样的团队会根据自身的必要程度决定要执行哪些工作？如配置管理、资源管理、版本控制、代码控制等，团队还合理的分划并定义开发过程的里程碑，决定每项活动内容的底线和审评标准，决定各项活动的先后关系或迭代的关系等。总之高效的软件开发团队的开发过程的原则是高效率、高质量、低成本。 |
软件团队的模式：
| 模式 | 理解 | 及其特点 |
|---|---|---|
| 1、一窝蜂模式 | 像小朋友踢球一样，球在哪里，人就一窝蜂跟在哪里 | 优点：欢乐而随意。缺点：这种团队模式很难存活，并不是一种好的团队模式 |
| 2、主治医师模式 | 像在手术台一样，有一个主刀医师，其他人负责协助主刀医师 | 优点：初衷很好，一个软件团队中，有首席程序员，负责主要模块的设计和编码，其他人尽可能从各个方面支持他的工做。缺点：在一些学校的软工课上，这种模式逐渐退化成“一个学生干活，其他学生打酱油” |
| 3、明星模式 | 主治医师模式运用到极点 | 优点：对“明星”个人的成长进步可能会有所帮助。缺点：团队模式强调的是团队的作用，而不是个人的独角戏，这种模式显然违背了团队模式的初衷，效率也很低 |
| 4、社区模式 | 由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬 | 优点：“众人拾柴火焰高”，成功案例：开发和维护Linux操作系统的社区，成功案例往往需要严格的代码复审和签入的质量控制。缺点：“只烤火，不拾柴”，“拾到的柴火质量太差” |
| 5、业余剧团模式 | 团队中各人扮演各人的角色 | 优点：在业余玩票、培训的环境中，每个人都可以尝试不同角色，大家可以比较平等地讨论。 缺点：在竞争性强烈、创造性要求高的团队，不会存在完美主义的民主气氛。 |
| 6、秘密团队 | 有一些软件项目在秘密状态下进行，别人不知道他们具体在做什么 | 优点：团队内部有极大的自由，较高的热情，没有外界的干扰。 缺点：不可能成为普遍模式，只会针对个别项目。 |
| 7、特工团队 | 软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题 | 优点：效率高。缺点：对成员的知识面要求十分广，较为针对技术人员，不可能成为普遍模式 |
| 8、交响乐团模式 | 各司其职，想交响乐队一样 | 优点：各司其职，重在执行。缺点：呆板 |
| 9、爵士乐模式 | 与交响乐模式存在相当多的对立 | 优点：领导给出一个主题，然后成员们百花齐放，各显本领，快收尾时再总结。缺点：人员不能太多 |
| 10、功能团队模式 | 具备不同能力的同事们平等协作公共完成一个功能 | 优点：效率高。 缺点：每个小组必须与其他小组就编程规范达成一致 |
| 11、官僚模式 | 脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次向上 | 优点：有助于技术的交替与互补。 缺点：容易掺杂一些追名逐利，往往会使团队效率大打折扣 |
模型特点：
| 模型 | 及其特点 |
|---|---|
| 瀑布模型特点： | (1)整个生命周期,有清洁定义的阶段. (2)前一个阶段完成后,下一个阶段才往下做. (3)任何阶段如果发生错误,立即回到前面发生错误得阶段,进行修正工做. (4)每一阶段完成后,皆会有严谨的文件产生. (5)使用者只有在调查,需求分析及测试三个阶段参与. |
| V模型 | （1）该模型中V 形左右两边连线说明各阶段的对应关系。（2）如果在验证和确认期间发现问题，应重新执行左边的步骤进行修正和改进相应的需求、设计和编码，然后去再次执行右边的测试，这样做使得迭代和重做的过程由隐藏变明确。（3）与瀑布模型关注对象是文档和制品相比，V 模型更加关注活动和正确性 |
| 敏捷流程等典型软件过程模型特点： | 也叫做鲑鱼模型，向前一阶段回溯，很难，特点：1）上一个阶段结束，下一个阶段才能开始；2） 每个阶段均有里程碑和提交物；3)上一阶段的输出是下一阶段的输入；(4)每个阶段均需要进行V&V；(5)侧重于文档与产出物。 |
| 渐进交付流程： | 特点:当系统的主要需求和框架明确后,团队进入一个不断演进的循环中。 |
理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则：
（1）流程中的每一步都是可以重复、可以衡量结果的。
（2）团队的各个成员对团队的目标、角色、产品都有统一的理解。
（3）尽量使用成熟的技术和做法。
（4）尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
（5）制定切合实际的计划和承诺，团队计划要由负责具体执行的角色来制定(而不是从上级而来)。
（6）增加团队的自我管理能力。
（7）专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。
博客作业中针对任务2的评分要点：提供两人讨论任务2学习内容的微信或QQ截图，要求截图美观。（10分）
任务3：在班级博客园，有很多高校的软件工程课程要求同学们完成团队项目，请与实验三结对伙伴协商，在以下三个班级中选择一个高质量的团队项目案例进行协作学习，要求追踪该团队项目发布所有博客作业，下载项目软件代码。
团队项目作业发布账号链接：https://www.cnblogs.com/16rg/p/10941589.html
团队项目仓库github链接：https://github.com/16rg/-
陈述你选择该团队项目进行分析的理由（5分）；
结合项目系列博客文档，总结项目团队成员的分工合作情况（4分）；
由此可以看出分工并不合理，又一个人单独负责文档编辑，把工作重心都交给了编码的同学，不合理，应该再分配一些任务，以减轻其他组员的负担。
结合项目系列博客文档，评价项目的软件项目过程特点（TSP):
软件开发是一个团队活动，而团队的有效性决定了产品的质量，TSP 的过程质量管理对于软件开发日渐重要。要建立和保持团
队的高效率工作，前期的 投入是必须的。从长期看，这种投入并没有增加成本，而是极大地降低成本，提高生产效率。软件开
发过程中积累下来的实际经验，对于团队今后的工作，具有很好的指导意义。
观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？（5分）；
下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展示截图（20分）；
在黑盒测试过程中，在对与软件工程进行测试时，我们发现以下错误及bug：
1.功能不正确或遗漏了功能：请假管理模块中，请假审核状态修改显示成功，但是状态并未改变。
2.性能错误及数据连接错误：老师请假审核通过后，学生看不到审核通过状态。
3.性能错误，学生自信修改权限。
评价该团队项目是否值得继续开发，并陈述理由？
基本会出现一些回归测试，应为做完一些模块后，总有一些问题出现，需要修改代码，但总体结构没变，怕影响到更大的问题 出现，回归测试较少，避免更多的错误出现。软件本版本完成后，有需要的话，进行二次版本修订，多次修改代码，回归测试必不可少。
出现回归测试有：
1.页面出现报错，发出异常处理界面。为了异常处理情况更加具有可视性，可操作性，增加编写404 error界面，出现错误，可直接退出或返回首页等。
2.模块功能异常，数据逻辑连接错误，在一个模块修改数据，另一模块无法及时变更等
记录完成《实验四 软件项目案例分析》各项任务实际花费的时间
| 实验任务 | 花费时间 |
|---|---|
| 任务一 | 3h |
| 任务二 | 1.5h |
| 任务三 | 5h |
| 任务四 | 2h |
请谈谈完成本次作业的感受和体会。
通过学习优秀案例，以及在完成各项人任务的过程中，感觉跟自己写的代码与别人的相比还是有很大的差别，没有注释，有些变量、函数其实是有些糊里糊涂的。检验别人的代码其实也是一个自我学习的过程，通过别人的代码、功能、界面对自己未来的项目开发也是有一些启示的，在一些功能实现的方面还是要注意的。对开发流程和步骤也有了相对清晰的认识，也认识到自己的能力问题，今后要更加努力。