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团队项目

  • 选取该团队项目的理由

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

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

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

  • 部署并使用,并找出其中的bug

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

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

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

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

任务 花费时间(h)
任务一 5.0
任务二 3.0
任务三 10.5
任务四 2.0

总结

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

posted @ 2020-04-11 01:39  17李志龙  阅读(159)  评论(1编辑  收藏  举报