201771030113-李志龙 实验四 软件项目案例分析

项目	内容
课程班级博客链接	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
作业要求链接	https://www.cnblogs.com/nwnu-daizh/p/12369881.html
课程学习目标	学习团队软件项目流程、团队成员协作要求；掌握敏捷流程原则及相关概念。
本作业在哪些方面帮助我实现学习目标	通过进一步和结对同伴的学习，提升团队合作的能力和意识。
结对方学号-姓名	201771030114-马强
结对方本次博客作业链接	https://www.cnblogs.com/AlexCrizs/p/12676098.html

实验三得分100分以上作业中，选一案例进行评价

• 实验三优秀案例推荐：张芹&李佩杉组

  • 该组项目仓库链接
  • 该组博客作业链接-张芹
  • 该组博客作业链接-李佩杉

• 评论截图
  

• 体验项目源码，总结问题，体会案例博文。

  • 复制对方案例源码到本机。
    

  • 运行登录
    

  

  • 二级部门查询
    
    
  • 成功导出表
    
  • 生成统计柱状图
    

• 对所选案例的分析及其不足的补充

  • 通过本次实验的案例，对其代码的测试和运行。发现其中的不足之处有，不能够很好的对其中的人员信息进行有效的管理，即不能很好的增加和删除。还有就是对生成的统计表没有做到清晰的存储路径。导致在试行的时候很难找到导出的表。

协作学习：阅读《现代软件工程—构建之法》第5-6章内容

• 理解并掌握软件项目团队的特点
  • 团队有一致的集体目标，团队要一起完成这个目标。
  • 团队成员有各自的分工，互相依赖合作，共同完成任务。
• 软件团队的模式
  • 主治医师模式：首席程序员负责主要模块的设计与编码，其他成员从不同角度提供支持；
  • 一窝蜂模式：最初的十分随意的软件团队模式，经过一段时间的演变将转变为后续的其他模式；
  • 社区模式：成员分布不受时间空间的限制，所有人根据喜好选择项目进行开发，一般不要求报酬；
  • 明星模式：主治医师模式运用的极点，团队“明星”的能力掩盖了团队所有人的缺陷与优点；
  • 业余剧团模式：没有固定的团队，且成员在不同的项目中没有固定的工作分配，所有成员由“中央指挥”指示；
  • 秘密团队：秘密状态下进行，无外界干扰，团队肩负独特使命，内部成员自由度与热情较高；
  • 特工团队：团队由专业人士组成，负责一些紧急问题的解决；
  • 交响乐团模式：较多大型软件公司采用，成员与领导者能力较强且有相似的项目开发经验，所有成员各司其职但统一受领导者指挥；
  • 爵士乐模式：与交响乐团模式对立，较为松散，领导者完成框架，其他成员在此基础上创作，最后再由领导者收尾；
  • 功能团队模式：没有固定的团队，由不同能力的成员进行组合，协作完成某一项目，项目完成后成员重新组织进行其它不同项目；
  • 官僚模式：脱胎于大机构的组织架构，几人向小头目报告，小头目向大头目报告。容易形成恶性竞争。
• 理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点。
  • 　瀑布模型是一个经典的软件生命周期模型，也叫预测型生命周期、完全计划驱动型生命周期。在这个模型里，在项目生命周期的尽早时间，要确定项目范围及交付此范围所需的时间和成本。
  • 在这个模型里，项目启动时，项目团队专注于定义产品和项目的总体范围，然后制定产品（及相关可交付成果）交付计划，接着通过各阶段来执行计划。应该仔细管理项目范围变更。如果有新增范围，则需要重新计划和正式确认。对于经常变化的项目而言，瀑布模型毫无价值。
• 渐进交付流程
  • 渐进交付流程由史蒂夫·迈克康奈尔与1996年总结，较接近于迭代式开发流程。其主要指当系统的主要需求和架构明确后，软件团队将进入如图所示的循环中，该循环将一直进行直至项目的资金不足、项目时间不够或产品能使用户满意为止。
    
• 敏捷流程所遵循的开发原则
  • 尽早并持续地交付有价值的软件以满足顾客需求；、
  • 敏捷流程欢迎需求的变化， 并利用这种变化来提高用户的竞争优势；
  • 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短；
  • 业务人员和开发人员在项目开发过程中应该每天共同工作；
  • 以有进取心的人为项目核心，充分支持信任他们；
  • 无论团队内外，面对面的交流始终是最有效的沟通方式；
  • 可用的软件是衡量项目进展的主要指标；
  • 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去；
  • 只有不断关注技术和设计，才能越来越敏捷；
  • 保持简明————尽可能简化工作量的技艺————极为重要；
  • 只有能自我管理的团队才能创造优秀的架构、需求和设计；
  • 时时总结如何提高团队效率，并付诸行动。
• TSP原则
  • 使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的；
  • 团队的各个成员对团队的目标、角色、产品都有统一的理解；
  • 尽量使用成熟的技术和做法；
  • 尽量多地收集数据（也包括对团队不利的数据）,并用数据来帮助团队做出理性的决定；
  • 制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定（而不是从上级而来）；
  • 增加团队的自我管理能力；
  • 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作（而不是在后期匆忙修复问题）。
• 讨论截图
  
  
  

选取一院校团队项目测试分析

• 选取北京航空航天大学2019春季计算机学院软件工程的PureMan团队项目

  • 所选项目博客链接
  • 所选项目GitHub仓库链接

• 选取该团队项目的理由

  • 主要是由于该项目的实施在移动端，并且是一款APP，想通过此次项目来熟悉一下移动端的开发，并且可以很好的学习一下团队项目是如何开发的。

• 该团队成员分工合作情况

  • 以我的看法是该团队主要是采用交响乐模式来进行开发的，开发人员主要负责实现客户端的功能，界面。刚开始的分工是大家各自负责自己的所要实现的功能，然后在例会上交流遇到的障碍或者取得进度，确定把功能加入哪里，保证大家的统一，同时也有两位开发人员定期统一所有的界面和美化。测试人员负责完成客户端的兼容性测试、压力测试，各个功能的集成测试。项目经理负责完成各种文档，组织开会，安排任务推进项目，与相关人员沟通，做调研，推广。

• 评价该项目的软件项目过程特点

  • 该团队的项目开发的过程，在我看来主要是采用了交响乐模式来进行开发的。每个成员都有自己所扮演的角色，并且很好的做到了统一，这部分的实现还是主要靠了项目经理的统筹，而且在开发的过程中实时调整，使得项目的进展很是顺利。

• 该项目仓库文件中包含规范文档，如下图所示
  

• 部署并使用，并找出其中的bug
  
  以上是我在移动端部署所使用的效果图，其中发现了问题，在移动端的界面中，背景没有，显得界面很是单一。还有就是我的手机上直接不能显示黑夜模式，跟其在博客中所说的不符。

• 评价该团队项目是否值得继续开发

  • 我觉得此项目非常值得继续开发，说咱们眼前的事，在本课程的学习中对博客使用非常广泛，该项目的实施非常便利我们的使用，再往长远说，开发者的家园，即博客园。如果往其中加入更多的功能，可以非常方便开发者的使用体验。

《实验四 软件项目案例分析》各项任务实际花费的时间

任务	花费时间（h）
任务一	5.0
任务二	3.0
任务三	10.5
任务四	2.0

总结

通过本次实验的学习，即学习了上次实验中的不足之处，又学习了团队开发的流程。对我的帮助非常大，尤其是在学习任务三的时候，我的感触非常大，让我清楚的明白了自己与其他人的差距。又通过学习教材的知识，很清楚的掌握了团队开发的模式和流程，对我以后的所要开发的项目帮助很大。