实验四 软件项目案例分析
| 项目 | 内容 |
| 课程班级博客 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 作业要求 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 课程学习目标 | 学习团队软件项目流程（TSP）、团队成员协作要求并掌握敏捷流程原则及相关概念。 |
| 这个作业在哪些方面帮助我实现学习目标 | 体验软件项目开发中的两人合作，练习结对编程，掌握Github协作开发程序的操作方法。 |
| 结对方学号-姓名 | 201771010135-杨蓉庆 |
| 结对方本次博客链接 | https://www.cnblogs.com/YRQY/p/12618697.html |
实验内容和步骤：
任务一：实验三优秀案例推荐：王之泰&韩腊梅组
案例作业博客链接：https://www.cnblogs.com/hanlamei/p/12574378.html
案例作业项目仓库链接：https://github.com/YHwzt/Query-system-web
（1）对案例博文作业进行阅读并进行评论评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系，并将以上评论内容发布到案例作业的博客评论区。
（2）克隆案例项目源码到本地机器，阅读项目代码规范文档并运行代码，总结代码运行中存在的问题，体会案例博文是否有助于项目代码理解。
1.系统运行截图如下
- 登录界面：
- 注册界面：
- 信息填写提交
- 高级查询
- 信息录入
- 信息填写提交
- 可视化统计功能
- 信息导出
2.软件功能总结
- 基本功能
- 系统可采集学生疫情有效信息；
- 学生在前端提交信息到管理员端；
- 各学院指定负责人登录系统，可查看学生填报的所有汇总数据
- 负责人可根据学生的姓名，学院，地址查找相关信息
- 负责人可直接添加学生的信息
- 负责人也可将填写有误的学生信息进行修改及删除
- 扩展功能
- 每日十点之后停止填报
- 负责人通过【导出】可获取疫情数据的EXCEL文件
- 负责人可通过图形化方式查看各学院已填报和未填报学生统计情况和关键疫情数据统计情况
- 填报提醒功能通过邮件的方式每天在九点半定时向学生及教职工发送疫情填报提醒
（3）总结本组实验三博客作业及代码设计存在问题与不足，列举代码中存在的bug，未实现的功能等等。
我的eclipse运行出错，改为idea运行时，由于环境配置不同导致出错，数据库连接也出现了问题，最后通过搜索并请教同学解决了问题，成功运行出了结果。
该程序代码也存在一些格式上的小问题，如下图：
任务二：与实验三结对伙伴协作学习：阅读《现代软件工程—构建之法》第5-6章内容，理解并掌握以下内容
软件项目团队的特点
（1）团队有一致的集体目标，团队成员要一起完成目标，一个团队的成员不一定要一起工作。
（2）团队成员有各自的分工，互相依赖合作，共同完成任务。
软件团队的模式：软件团队有各种模式，适用于不同的人员和需求，主要有以下几种
- 蜂窝模式：是一种欢乐而随意的形式。
- 主治医师模式：各司其职，为主治医师服务。
- 明星模式：主治医师模式的极点。
- 社区模式：每个人参与自己感兴趣的方向。
- 业余剧团模式:每个团队在不同的项目会挑选不同的角色。
- 秘密团队：每个人在秘密条件下进行。
- 特工团队：有特殊技能的专业人士。
- 交响乐团模式：交响乐团的演奏模式。
- 爵士乐模式：与交响乐队模式对立。
- 功能团队模式：具备不同能力的人平等协作。
- 官僚模式：小头目-->中头目-->大头目。
经过我们的讨论，我们认为对于我们学生现如今而言，比较好的还是交响乐团模式以及功能团队模式。交响乐团门类齐全，各司其职，演奏都靠谱，同时看指挥；当某个软件领域处于稳定成长阶段的时候，众多大型软件公司的开发团队就会采取这种模式，例如微软公司的office软件。而功能团队模式是指具备不同能力的同事们平等协作，共同完成一个功能，在这个功能完成以后，这些人又重新组织，和别的角色一起去完成下一个功能，他们之间没有管理和被管理的关系。很多软件公司的团队最后都演变成功能团队，大型软件公司里的不少团队也采用这种模式，但功能团队也有一个弊端，即没有决策者，适当的交流是好的，但一旦交流，就难免会出现分歧，众口难调的话，就需要一位决策者了，决策者做的决定不可能迁就每一个小组，但至少可以让利益最大化。。
我希望之后实践时，我们的团队模式可以是二者的结合形式，通过磨合，能够协同作战。团队可以公开的讨论流程和工作的方式，协商制定计划；PM可以得到广泛尊重，有能力的成员也分担一定的领导职责；大家各司其职，平等协作，最后汇总各部分，完成任务。
明确目标，合理分工，共同协作
典型软件过程模型特点
一、瀑布模型（Waterfall Model）
瀑布模型（经典生命模型）提出了软件开发的系统化的、顺序的方法。其流程从用户需求规格说明开始，通过策划、建模、构建和部署过程，最终提供一个完整的软件并提供持续的技术支持。
- 模型特点：
- 必须等前一阶段的工作完成之后，才能开始后一段的工作；
- 每一阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
- 前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能得到正确的结果。
- 每个阶段结束前都要对所完成的文档进行评审，以便及早发现问题，改正错误。事实上越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出的代价也越高。因此，及时审查，是保证软件质量，降低软件成本的重要措施。
理解：瀑布模型作为最早出现，应用最广泛的软件过程模型，适用于需求确定，无大的需求变更，工作能够采用线性的方式完成的软件。此模型强调了开发的阶段性，各阶段具有顺序性和依赖性，并且提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。但其局限性在于要求项目严格按规程推进，必须等到所有开发工作全部完成以后才能获得可以交付的软件产品。不能对软件系统进行快速创建，对于一些急于交付的软件系统的开发很不方便。而且对于分析初期需求模糊的项目，瀑布模型也并不适合。
二、增量模型（Incremental Model）
增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它对软件过程的考虑是：在整体上按照瀑布模型的流程实施项目开发，以方便对项目的管理；但在软件的实际开发中，则将软件系统按功能分解为许多增减构件，并以构件为单位逐个地创建与交付，直到全部增量构件创建完成，并都被集成到系统之中交付用户使用。
- 模型特点：
- 当使用增量模型时，第一个增量往往是核心的产品；
- 客户对每个增量的使用和评估都作为下一个增量发布的新特性和功能；
- 该模型采用随着日程时间的进展而交错的线性雪猎，每一个线性序列产生软件的一个可发布的“增量”。
理解：增量模型适用于项目在既定的商业要求期限之前不可能找到足够的开发人员的情况。优点是开发由增量表示的小系统所承担的风险不大，但局限性是如果没有对用户的变更要求进行规划，那么产生的出事增量可能会造成后来增量的不稳定。
三、快速原型（Rapid Prototype）模型
软件开发过程中，开发初期很难得到一个完整的、准确的需求规格说明，开发者往往对要解决的应用问题模糊不清，以至于形成的需求规格说明常常是不完整的、不准确的，有时甚至是有歧义的。此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变更。为了适应这种需求的不确定性和变化，于是出现了快速原型（Rapid Prototype）开发方法。
- 模型特点：
- 快速原型是用来获取用户需求的，或是用来试探设计是否有效的。一旦需求或设计确定下来了，原型就将被抛弃。因此，快速原型要求快速构件、容易修改，以节约原型创建的成本、加快开发速度；
- 快速原型是暂时适用使用的，因此并不要求完整。它往往针对某个局部问题建立专门原型，如界面原型、工作流原型等；
- 快速原型不能贯穿软件的整个生命周期，它需要和其他的过程模型相结合才能产生作用。例如，在瀑布模型中应用快速原型，以解决瀑布模型在需求分析时期存在的不足。
理解:快速原型方法比较适用于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法比较好。而且 减少了开发风险，避免了因为需求不确定而在开发过程中浪费了大量的资源。但快速原型模型没有考虑到软件的整体和长期的可维护性。
四、渐进交付流程
渐进交付流程是史蒂夫.迈克康奈尔在1996年总结的，但是它其实已经很接近现在大家谈论较多的迭代式开发流程。当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的循环中
[ 开发 → 发布 → 听取反馈 → 根据反馈做改进 ]
通过资料的搜集，我发现渐进交付流程已经接近现在大家所说的开发流程。当系统的主需求和架构明确之后，软件团队进入了一个不断演进的循环中。但渐进交付流程最大的弊端在于产品团队得到用户的反馈太晚了。为了让用户更早地给产品团队反馈，把“尽早”推到极致，从2009年开始，MVP方法达到广泛应用。
MVP一Minimum Viable Product：最小可行产品,又称为Minimal Feature Set,最小功能集。
具体的做法是:把产品最核心的功能用最小的成本实现出来(或者描绘出来)，然后快速征求用户意见。MVP的指导思想和渐进交付相似，但是它更强调更早获得用户反馈，为此可以在产品完成之前就发布，它也强调产品的核心价值(产品最区别于竞争产品的地方)，为了突出核心功能，别的辅助功能可以不考虑或者用别的平台提供的服务来代替。
MBP一Maximal BeautifulProduct :最强最美产品，对用户的需求了然于心，产品团队比用户更了解用户的需求，把产品最全、最美的形态展现出来，一举征服用户。
五、敏捷流程
敏捷流程图如下所示
第一步:找出完成产品需要做的事情一Product Backlog。
Backlog翻译成“积压的工作”、“待解决的问题”、“产品订单”，都可以。产品负责人领导大家对于这个Backlog中的条目进行分析、细化、理清相互关系、估计工作量等工作。每一项工作的时间估计单位为“天”。
第二步:决定当前的冲刺( Sprint )需要解决的事情一Sprint Backlog。
以小时为单位，如果一个任务的估计时间太长(如超过16个小时)，那么它就应该被进一步分解。订单上的任务是团队成员根据自己的情况来认领。如果团队成员能主导任务的估计和分配，他们的能动性会得到较大的发挥。
第三步:冲刺。
冲刺期间，团队通过每日例会(ScrumMeeting)来进行面对面的交流，每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。同时团队要启动每日构建，让大家每天都能看到一个逐渐完善的版本。
六、理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则
- 使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的。
- 团队的各个成员对团队的目标、角色、产品都有统一的理解。
- 尽量使用成熟的技术和做法。
- 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
- 制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
- 增加团队的自我管理能力。
- 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。
这些原则虽然抽象，但是每个团队在做Postmortem的时候（Postmortem是指软件项目结束以后，对产品的回顾以及读开发过程的分析），可以对照检查,看看自已的团队在刚刚过去的软件生命周期中到底提高了多少。
通过阅读，我个人认为这几个原则中最重要的是增加团队的自我管理能力，在平常的软件工程项目设计中，一定要首先制定好合理的进度计划，再去逐步做好。从逆向的思维方式来整理科学的管理方法对整个软甲工程项目的推进至关重要。
任务三：与实验三结对伙伴协商，在三个班级中选择一个高质量的团队项目案例进行协作学习，要求追踪该团队项目发布所有博客作业，下载项目软件代码。
1.团队项目作业发布账号链接：https://www.cnblogs.com/PureMan6/p/10739662.html#4
2.团队项目仓库github链接：https://github.com/swearitagain/EduCnblogs2.0
3.陈述你选择该团队项目进行分析的理由：
开始在考虑三个团队项目选择的问题上，和结对伙伴最终通过讨论选择了北京航空航天大学的班级博客客户端项目设计，选择这个项目主要有两个原因，第一是我们通过浏览项目博客及相关内容，可以看到这个项目的完整度和复杂度都很高，深入学习的空间很大。第二点是这个项目的创新性很高，我们恰巧在学习软件工程这门课的时候都是通过博客园来进行学习交流，如果可以在手机端方便地查看班级博客的相关内容，会使得平常使用起来更加便捷，此项目满足了实用性的特点。
4.结合项目系列博客文档，总结项目团队成员的分工合作情况
项目团队成员有六位成员构成，其中三位担任开发人员，一位是开发/PM 另外两位分别是测试人员和项目经理，分工较为合理，从博文中的成员贡献和特殊加减分的部分可以看出整个设计过程的记录非常完整，在之后的项目设计中会试着去学习运用。
5.结合项目系列博客文档，评价项目的软件项目过程特点（TSP）
首先可以看到团队的各个成员对团队的目标、角色、产品都有统一的理解，团队成员的整体能力都较高，后期还通过用户反馈情况和对机型、环境（机型，版本，分辨率）的测试来改进完善功能。团队的自我管理能力较好。而且专注于提高质量，反复的测试能够在软件生命周期的早期发现问题，可以有效地提高质量设计工作全面而细致(而不是在后期匆忙修复问题)。
6.观察该团队项目github仓库的源代码文件结构，是否包含代码规范文档？
该团队项目github仓库中未包含代码规范文档
7.下载团队项目代码，尝试部署项目运行环境并使用软件，描述最简单直观的使用体验，找出至少两个比较严重的功能性bug，在博客中展示截图；
- 部分功能截图如图所示
系统功能bug
①博客作业的提交列表不显示
②提交的博文内容查看时Markdown的渲染和博客园的背景不显示
8.评价该团队项目是否值得继续开发，并陈述理由？
我认为该团队项目非常值得开发，就我个人对博客园的体验来说，每次交作业都不知道截止时间是什么，但在手机端登录博客园查看时很不方便，也没必要每次都打开电脑查看，这样一个手机端的应用不仅有提醒功能，还对班级博客园的相关部分都着重显示出来，用户体验极好，方便且实用，从软件的应用性来看非常值得开发。其次就是此项目的具体设计，基本功能实现和页面设计都较为完善，其中存在的小问题以及页面的美观也可以通过后期的用户体验逐步完善改进。
各项任务实际花费的时间
| 任务内容 | 计划共完成需要的时间（min） | 实际完成需要的时间 |
| 任务一 | 180 | 200 |
| 任务二 | 120 | 120 |
| 任务三 | 180 | 240 |
小结感受
这次实验的目的是学习团队软件项目流程（TSP）、团队成员协作要求及敏捷流程原则及相关概念。通过阅读《现代软件工程—构建之法》第5-6章内容以及网上资料的搜集，对基本概念有了全面的了解，此外，此次实验很重要的部分是优秀案例的学习，一个是同班同学的案例，由于之前的作业中也做过同样的案例，理解起来较为容易，也能够把我们的项目和他们的项目做个比较，学习他们的设计中的优点，对以后的学习很有帮助。第二个优秀案例的学习是北京航空航天大学的团队项目案例，这是一个较为完整的团队项目，不仅做出了实用度较高，质量较好的项目，而且从整体的设计过程中可以看出团队成员的整体水平和协作能力都较高，我深刻地体会到了自己能力的欠缺，希望之后可以通过自己的努力慢慢进步。