| 项目 | 内容 |
| 课程班级博客 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 作业要求 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 课程学习目标 | 通过分析优秀的作业案例，掌握自己的不足之处。通过合作学习，理解合作的重要性 |
| 这个作业在哪些方面帮助我实现学习目标 | 体验软件项目开发中的两人合作，练习结对编程，掌握Github协作开发程序的操作方法。 |
| 结对方学号-姓名 | 201771010126-王燕 |
| 结对方本次博客链接 | <https://www.cnblogs.com/wy201771010126/p/12677569.html> |
实验内容和步骤：
任务一：实验三优秀案例推荐：王之泰&韩腊梅组
案例作业博客链接：https://www.cnblogs.com/hanlamei/p/12574378.html
案例作业项目仓库链接：https://github.com/YHwzt/Query-system-web
（1）对案例博文作业进行阅读并进行评论评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系，并将以上评论内容发布到案例作业的博客评论区。
（2）克隆案例项目源码到本地机器，阅读项目代码规范文档并运行代码，总结代码运行中存在的问题，体会案例博文是否有助于项目代码理解。
将案例方的代码克隆至本地进行运行
然后进行代码运行，截图如下
上面是登录界面
进行信息的添加
进行采集信息的统计
信息的展示
以上案例实现的功能：
1，可采集全校各类师生员工疫情信息；
2，各二级部门疫情防控工作负责人可查看本部门人员疫情汇总，并提供高级查询功能进行多属性组合查询和可视化统计功能；
3，学校防控办指定负责人登录《西北师范大学疫情防控信息统计》子系统，可浏览所有人员填报汇总数据清单，利用【高级查询】可进行数据组合筛选，系统以图形化方式展示各学院已填报和未填报学生统计情况和关键疫情数据统计情况，可【导出】查询列表的EXCEL文件；
4，附加功能：定时填报提醒
此案例的功能实现全面，完全按照老师的要求，实现了所有的功能，另外还实现 了附加功能，相比较 来说 算是做得很完美的，所以相比来说，我认为此案例是很值得我来参考学习一下的。
（3）总结本组实验三博客作业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。
我认为此案例很完美没有多少不足，但是也有一些不完美的地方，比如，仓库中的代码在clone之后没有出现问题但是在导入eclipse的时候有一些问题，导不进去，最后在请教同学和查询相关资料之后直接在 idea打开才行，着让很多参考者有了很大 的问题，因为打不开，会认为自己的eclipse配置有问题，或者代码有问题。
代码规范基本没有问题，功能实现也比较全面。
任务2：与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；
1，软件项目团队的特点
（1）团队应该拥有共同的目标；
（2）团队应该合理分工协作；
（3）高度的凝聚力是是团结的保证；
（4）团队成员相互信息；
（5）有效的沟通；
2，软件团队的模式：软件团队有很多不同的模式。
（1），以下是几种模式以及他们的优缺点：
1.一窝蜂模式：像小朋友踢球一样，球在哪里，人就一窝蜂跟在哪里
优点：欢乐而随意
缺点：这种团队模式很难存活，并不是一种好的团队模式
2.主治医师模式：像在手术台一样，有一个主刀医师，其他人负责协助主刀医师
优点：初衷很好，一个软件团队中，有首席程序员，负责主要模块的设计和编码，其他人尽可能从各个方面支持他的工作
缺点：在一些学校的软工课上，这种模式逐渐退化成“一个学生干活，其他学生打酱油”
3.明星模式：主治医师模式运用到极点
优点：对“明星”个人的成长进步可能会有所帮助
缺点：团队模式强调的是团队的作用，而不是个人的独角戏，这种模式显然违背了团队模式的初衷，效率也很低
4.社区模式：由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬
优点：“众人拾柴火焰高”，成功案例：开发和维护Linux操作系统的社区，成功案例往往需要严格的代码复审和签入的质量控制
缺点：“只烤火，不拾柴”，“拾到的柴火质量太差”
5.业余剧团模式：团队中各人扮演各人的角色
优点：在业余玩票、培训的环境中，每个人都可以尝试不同角色，大家可以比较平等地讨论
缺点：在竞争性强烈、创造性要求高的团队，不会存在完美主义的民主气氛。
6.秘密团队：有一些软件项目在秘密状态下进行，别人不知道他们具体在做什么
优点：团队内部有极大的自由，较高的热情，没有外界的干扰。
缺点：不可能成为普遍模式，只会针对个别项目。
7.特工团队：软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题
优点：效率高
缺点：对成员的知识面要求十分广，较为针对技术人员，不可能成为普遍模式
8.交响乐团模式：各司其职，想交响乐队一样
优点：各司其职，重在执行
缺点：呆板
9.爵士乐模式：与交响乐模式存在相当多的对立
优点：领导给出一个主题，然后成员们百花齐放，各显本领，快收尾时再总结
缺点：人员不能太多
10.功能团队模式：具备不同能力的同事们平等协作公共完成一个功能
优点：效率高
缺点：每个小组必须与其他小组就编程规范达成一致
11.官僚模式：脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次向上
优点：有助于技术的交替与互补
缺点：容易掺杂一些追名逐利，往往会使团队效率大打折扣
（2），和小组成员讨论团对模式
3，典型软件过程模型特点
所谓软件过程模型就是一种开发策略，这种策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。对一个软件的开发无论其大小，我们都需要选择一个合适的软件过程模型，这种选择基于项目和应用的性质、采用的方法、需要的控制，以及要交付的产品的特点。一个错误模型的选择，将迷失我们的开发方向。
| 模型名称 | 技术特点 | 适用范围 |
| 瀑布模型 | 简单，分阶段，阶段间存在因果关系，各个阶段完成后都有评审，允许反馈，不支持，用户参与，要求预先确定需求 | 需求易于完善定义且不易变更的软件系统 |
| 快速原型模型 | 型 不要求需求预先完备定义，支持用户参与，支持需求的渐进式完善和确认，能够适应用户需求的变化 | 需求复杂、难以确定、动态变化的软件系统 |
| 增量模型 | 软件产品是被增量式地一块块开发的，允许开发活动并行和重叠 | 技术风险较大、用户需求较为稳定的软件系统 |
| 迭代模型 | 不要求一次性地开发出完整的软件系统，将软件开发视为一个逐步获取用广需求、完善软件产品的过程 | 需求难以确定、不断变更的软件系统 |
| 螺旋模型 | 结合瀑布模型、快速原型模型和迭代模型的思想，并引进了风险分析活动 | 需求难以获取和确定、软件开发风险较大的软件系统 |
| RUP | 可改造、扩展和剪裁：可以对它进行设计、开发、维护和发布；强调迭代开发 | 复杂和需求难以获取和确定的软件系统；软件开发项目组拥有丰富的软件开发和管理经验 |
瀑布模型
瀑布模型（经典生命周期）提出了软件开发的系统化的、顺序的方法。其流 程从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供一 个完整的软件并提供持续的技术支持。
优点：
1. 强调开发的阶段性，各阶段具有顺序性和依赖性
2. 强调早期调研和需求分析，推迟编码实现的观点
3. 提供了一个摸板，这个摸板使得分析、设计、编码、测试和支持的方法可以 在该摸板下有一个共同的指导
缺点：
1. 文档驱动，用户无法及时了解产品的情况
2. 依赖早期调研和需求分析，很难适应在许多项目开始阶段必然存在的不确定 性。
3. 流程单一，必须要完成前一阶段的任务，才能进行下一阶段，开发过程中的 成功经验无法用于本产品。
4. 测试在后期引入，对于系统存在的重大缺陷，如果在可执行程序评审之前没 有被发现，将可能造成重大损失。
5. 组织庞大，人员闲置。
增量过程模型
增量过程模型包括增量模型、RAD 模型。
（一）增量模型 增量过程模型以迭代的方式运用瀑布模型，把软件产品作为一系列的增量构件来设计、编码、集成和测试。
每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量往往是核心功能。
优点：
1.能在较短的时间内向用户提交可完成部分工作的产品。
2.逐步增加产品功能可以使用户有充裕的时间学习和适应新产品，从而减少一个 全新的软件可能给客户组织带来的冲击。
3. 规避技术风险
4. 可并行开发构件，加快开发的进度
缺点：
1. 没有考虑软件的整体质量和长期的可维护性。
2. 大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工 具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。
3. 由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计
RAD模型
RAD 模型是一种侧重于短暂的开发周期的增量软件过程模型，它是瀑布模 型的“高速”变体，通过基于构建的构建方法实现快速开发。
开发团队能够在非常短的时间内创造出“全功能系统”
优点：
1．开发速度快，质量有保证。
2．对信息系统特别有效。
缺点：
1. 对于大型的可伸缩的项目，RAD 需要大量的人力资源来创建多个相对的独立 的 RAD 团队
2. 如果开发者和用户没有为短时间内急速完成整个系统做好准备，RAD 项目将会失败。
3. 如果一个系统不能合理的模块化，RAD 构件建立会有很多问题。
4. 如果系统需求是高性能，并且需要通过调整构件接口的方式来提高性能，不 能采用 RAD 模型
5. 技术风险很高的情况下
演化过程模型
演化过程模型包括原型开发，螺旋模型，协同开发模型。
（一）原型开发 从需求收集开始，开发者和客户在一起定义软件的总体目标，标识已知的需求并且规划出需要进一步定义的区域。
然后是“快速设计”，它集中于软件中那些 对客户可见的部分的表示，这将导致原型的创建，并由客户评估并进一步精化待 开发软件的需求。
逐步调整原型使其满足客户的需求，这个过程是迭代的。其流 程从听取客户意见开始、随后是建造/修改原型、客户测试运行原型、然后回头 往复循环直到客户对原型满意为止。
由于这种模型可以让客户快速的感受到实际 的系统（虽然这个系统不带有任何质量的保证），所以客户和开发者都比较喜欢 这种过程模型（对于那些仅仅用来演示软件功能的公司而言或从来不考虑软件质
量和不害怕长期维护的公司而言）。
优点：
1、能让人（开发者或客户）很快见到产品，有成就感。
2、能渐进地启发客户提出新的要求或任务。
缺点：
1、 没有考虑软件的整体质量和长期的可维护性。
2、 大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。
3、 由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计。
螺旋模型
螺旋模型是一种演进式软件过程模型，结合了原型的迭代性质和瀑布模型的系统性和可控性的特点，具有快速开发越来越完善软件版本的潜力。
开发步骤：沿螺线自内向外，每旋转一圈便开发出更为完善的一个新的软件版本。
例如，在第一圈，确定了初步的目标、方案和限制条件以后，转入右上象限，对风险进行识别和分析。
如果风险分析表明，需求有不确定性，那么在右下 的工程象限内，所建的原型会帮助开发人员和客户，考虑其它开发模型，并对需求做进一步修正。客户对工程成果做出评价之后，给出修正建议。
在此基础上需 再次计划，并进行风险分析。在每一圈螺线上，风险分析的终点做出是否继续下 去的判断。
假如风险过大，开发者和用户无法承受，项目有可能终止。多数情况 下沿螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统。
优点：
1. 强调风险
2. 强调阶段质量
3. 提供纠错的机会
缺点：
1. 每个阶段都要提出被选方案，进行风险分析，研发周期长，效率低
2. 必须要转业的风险分析人员的参与
统一过程模型
统一过程模型是一种“用例驱动、以体系结构为核心、迭代及增量”的软件 过程框架，由 UML 方法和工具支持。它是一种增量模型，定义了五个阶段：
a、起始阶段，包括用户沟通和计划活动，强调定义和细化用例
b、 细化阶段，包括用户沟通和建模活动，重点是创建分析和设计模型。
c、构件阶段，细化模型设计，并将设计模型转化为软件构件实现
d、 转化阶段，将软件从开发人员传递给最终用户，并由用户完成 beta 测试和验 收测试
e、生产阶段，持续地监控软件的运行，并提供技术支持。
优点：
1. 任何功能开发后就进入测试过程，及早进行验证
2. 早期风险识别，采取预防措施
缺点：
1. 需求必须在开始之前完全弄清楚，否怎有可能在架构上出现错误
2. 必须有严格的过程管理，以免使过程退化为原始的试→错→改模式
3．如果不加控制的让用户过早接触没有测试完全，版本不稳定的产品可能对用 户和开发团队都带来负面的影响
4、理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则
（1）使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。
（2）团队的各个成员对团队的目标、角色、产品都有统一的理解。
（3）尽量使用成熟的技术和做法。
（4）尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
（5）制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
（6）增加团队的自我管理能力。
任务3：请与实验三结对伙伴协商，在以下三个班级中选择一个高质量的团队项目案例进行协作学习，要求追踪该团队项目发布所有博客作业，下载项目软件代码。
1. 2016级计算机科学与工程学院软件工程 (西北师范大学)
用过讨论决定选择西北师范大学的的进行学习，选择的原因主要是，相比较来说，第一是自己学校的，学习水平差距不是很大，容易理解，相比较其他两个学校的自己学校的更能理解。
结合项目系列博客文档，总结项目团队成员的分工合作情况（4分）；
这个分工看似合理，但是每个人参与的环节不一样，有的同学除了文档部分其他部分，没有参与，而有些同学除了编码部分为参与文档部分，者相对来说也是一种重心偏移的现象。
结合项目系列博客文档，评价项目的软件项目过程特点（TSP):
TSP把人员分成小组领导者、开发经理、计划经理、质量／生产经理，以及技术支持经理(注意这点和RUP的雷同）,要求各个人员严格记录在软件开发过程中的每一步，比如程序的Bug率，使用的时间等等。
观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？
clone该团队的代码查看，发现包含代码规范文档。
下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展示截图
以上是代码运行的结果截图。我们讨论运行发现的bug有：
（1）.在功能展示部分：请假管理模块中，请假审核状态修改显示成功，但是并没有发生改变，可能是功能不完整或者不健全的原因。
（2）.在数据连接部分：当看到老师通过请假审核后，学生却无法看到请假已经通过的状态。
（3）.性能部分：学生可以自行修改权限，没有将 老师的权限展示出来，也没有完善学生的权限。
评价该团队项目是否值得继续开发，并陈述理由？
项目值得继续开发，但是此项目的完成度较低，在功能，数据连接，性能等部分都有或多或少的问题，建议先完善问题，再进一步做好更进一步的开发工作，学生考勤管理系统，加一些签到打卡的功能。
以上是我和伙伴儿一起添加修改的管理系统，以此做个对照。
记录完成《实验四 软件项目案例分析》各项任务实际花费的时间
| 实验任务 | 花费时间 |
|---|---|
| 任务一 | 3h |
| 任务二 | 2h |
| 任务三 | 5.5h |
| 任务四 | 1h |
5，请谈谈完成本次作业的感受和体会。
本次作业主要学习其他的优秀作业为主，而学习优秀作业的同时也是对自己的能力的一种提升和进步，看了优秀作业的代码和博文结构内容等等，觉得自己还是有很多需要学习的地方，自己的代码也不够完整，而且也没有优秀案例的规范，如此这些都是需要在后期加强的地方，所以此次优秀案例分析也让我了解到了自己的欠缺，需要在什么地方下功夫。