zoukankan      html  css  js  c++  java
  • 201771010130-王志成 实验四 软件项目案例分析

    项目 内容
    这个作业属于哪个课程 https://www.cnblogs.com/nwnu-daizh/
    这个作业的要求在哪里 https://www.cnblogs.com/nwnu-daizh/p/12616341.html
    作业学习目标 (1)学习团队软件项目流程(TSP)、团队成员协作要求。(2)掌握敏捷流程原则及相关概念 。
    这个作业在哪些方面帮助我实现学习目标 (1)对团队项目协作开发流程的实践(2)相关知识的学习
    结对方学号和姓名 201771010110 孔维滢
    结对方本次博客作业链接 https://www.cnblogs.com/Weiron/

    实验内容及步骤:

    任务1:实验三优秀案例推荐:汪慧和&杨野组
    https://www.cnblogs.com/http-www-whh0601-cnblogs-com/p/12553743.html
    https://www.cnblogs.com/2017xinghui/p/12554158.html

    (1)对案例博文作业进行阅读并进行评论,评论要点包括:博文结构、博文内容、博文结构与PSP中“任务内容”列的关系,并将以上评论内容发布到案例作业的博客评论区。

    (2)克隆案例项目源码到本地机器,阅读项目代码规范文档并运行代码,总结代码运行中存在的问题,体会案例博文是否有助于项目代码理解。













    软件功能总结:

    -该软件很好的实现了疫情信息填报系统的基本功能,而且在用柱状图统计信息的方面做得很完美,很直观的展现出了数据的统计信息

    (3)总结本组实验三博客作业及代码设计存在问题与不足,列举代码中存在的bug,未实现的功能等等。

    相对于优秀案例,我们组在柱状图方面所展现的数据有点单一
    并没有实现定时提醒功能

    任务2:与实验三结对伙伴协作学习:阅读《现代软件工程—构建之法》第5-6章内容,理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点,理解并体会卡内基梅隆大学(CMU)软件工程学院总结的TSP原则;

    1.软件项目团队特点:

    1、 具有明确且有挑战性的共同目标
    一个具有明确的而且有挑战性目标的团队比目标不明确或不具有很大的挑战性目标的团队效率高得多,通常技术人员往往会因为完成了某个明确的任务,而且这个任务的完成具有挑战性的意义而感到自豪,反过来团队成员为了获取这种自豪的感觉而更加积极的工作从而带来团队开发的高效率,如作为系统设计人员很清楚的知道在什么时候要做到什么,什么时候开始做,什么时候必须完成,为了完成工作必须面临哪些挑战,怎么解决这些困难等为设计出一个高质量的软件项目提供了重要保证,而模模糊糊的去设计一个系统或模模糊糊的就去编写代码是非常危险的,而且会为此付出高昂代价,因此高效的软件开发团队具有挑战性的共同目标。
    2、 团队具有很强的凝聚力
    在一个高效的软件开发团队中,成员们凝聚为一个整体共同进行工作,他们是相互支持、互相交流、互相尊重的,而不是相互推卸责任、保守、相互指责的,在一些散乱的开发团队中往往存在这样的问题,一些程序员是比较保守的,明明知道另外的模块中需要用到一段与自己已经编写完成但有些难度的程序代码,他也不愿拿出来给其它程序员共享,不愿与系统设计人员交流,这样给项目的进度造成了些不可度量的因素。
    3、 具有融洽的交流环境
    在一个开发团队中,每个人行使自己的职责,如需求分析人员制定需求规格说明、系统设计人员做系统概要设计和详细设计、项目经理配置项目开发环境并且制定项目计划等,但每个人的工作不可能做到完美的,如系统概要设计的文档可能有个别地方词不达意,做详细设计的时候就可能会造成误解,项目经理制定计划时可能忽略了某种风险的存在而造成执行者过于紧张的压力等等情况都需要大家通过交流、反馈的手段然后协商解决的,因此高效的软件开发团队是具有融洽的交流环境的,而不是那种简单的命令执行式的。
    4、 具有共同的工作规范和框架
    高效软件开发团队具有规范性及共同框架的工作,对于项目管理具有规范的项目开发计划,对于分析设计具有规范和统一框架的文档及审评标准,对于代码具有程序规范条例,对于测试有规范且可推理的测试计划及测试报告等等。并且所有成员都明白自己的职责,知道必须完成什么计划?由谁来完成?什么时候开始?什么时候结束?按什么顺序?等,总之一个高效的开发团队无论是工作内容还是工作流程都具有不同程度的规范性和标准风格的框架。
    5、 采用合理的开发过程
    软件的开发不同于一般商品的研发和生产,开发过程中会面临着各种难以预测的风险,比如需求的变化、人员的异动、技术的瓶颈、同行的竞争等,高效的软件开发团队往往是采用了合理的开发过程去控制开发过程中的风险、提高软件的质量、降低开发费用,这样的团队会根据自身的必要程度决定要执行哪些工作?如配置管理、资源管理、版本控制、代码控制等,团队还合理的分划并定义开发过程的里程碑,决定每项活动内容的底线和审评标准,决定各项活动的先后关系或迭代的关系等。总之高效的软件开发团队的开发过程的原则是高效率、高质量、低成本。

    2.软件团队的模式:

      1.一窝蜂模式:像小朋友踢球一样,球在哪里,人就一窝蜂跟在哪里
      优点:欢乐而随意
      缺点:这种团队模式很难存活,并不是一种好的团队模式
      2.主治医师模式:像在手术台一样,有一个主刀医师,其他人负责协助主刀医师
      优点:初衷很好,一个软件团队中,有首席程序员,负责主要模块的设计和编码,其他人尽可能从各个方面支持他的工
      缺点:在一些学校的软工课上,这种模式逐渐退化成“一个学生干活,其他学生打酱油”
      3.明星模式:主治医师模式运用到极点
      优点:对“明星”个人的成长进步可能会有所帮助
      缺点:团队模式强调的是团队的作用,而不是个人的独角戏,这种模式显然违背了团队模式的初衷,效率也很低
      4.社区模式:由很多志愿者参与,每个人参与自己感兴趣的项目,贡献力量,大部分人不拿报酬
      优点:“众人拾柴火焰高”,成功案例:开发和维护Linux操作系统的社区,成功案例往往需要严格的代码复审和签入的质量控制
      缺点:“只烤火,不拾柴”,“拾到的柴火质量太差”
      5.业余剧团模式:团队中各人扮演各人的角色
      优点:在业余玩票、培训的环境中,每个人都可以尝试不同角色,大家可以比较平等地讨论
      缺点:在竞争性强烈、创造性要求高的团队,不会存在完美主义的民主气氛。
      6.秘密团队:有一些软件项目在秘密状态下进行,别人不知道他们具体在做什么
      优点:团队内部有极大的自由,较高的热情,没有外界的干扰。
      缺点:不可能成为普遍模式,只会针对个别项目。
      7.特工团队:软件团队由一些有特殊技能的专业人士组成,负责解决一些棘手而有紧迫性的问题
      优点:效率高
      缺点:对成员的知识面要求十分广,较为针对技术人员,不可能成为普遍模式
      8.交响乐团模式:各司其职,想交响乐队一样
      优点:各司其职,重在执行
      缺点:呆板
      9.爵士乐模式:与交响乐模式存在相当多的对立
      优点:领导给出一个主题,然后成员们百花齐放,各显本领,快收尾时再总结
      缺点:人员不能太多
      10.功能团队模式:具备不同能力的同事们平等协作公共完成一个功能
      优点:效率高
      缺点:每个小组必须与其他小组就编程规范达成一致
      11.官僚模式:脱胎于大机构的组织架构,几个人报告给一个小头目,几个小头目报告给中头目,依次向上
      优点:有助于技术的交替与互补
      缺点:容易掺杂一些追名逐利,往往会使团队效率大打折扣
    

    瀑布模型及变形:

    瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

    瀑布模型的优点:

    1)为项目提供了按阶段划分的检查瀑布模型查点。
    2)当前一阶段完成后,只需要去关注后续阶段。
    3)可在迭代模型中应用瀑布模型。
    4)它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
    

    瀑布模型的缺点:

    1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
    2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
    3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
    4)瀑布模型的突出缺点是不适应用户需求的变化。
    5)早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。
    

    温斯顿指出,要让产品成功,最好把这个模型走两遍,先有一个模拟版本(Simulation of FinalProduct),在此基础上收集反馈,改进各个步骤,并交付一个最终的版本

    渐进交付流程:

    史蒂夫·迈克康奈尔(Steve McConnell)在1996年总结的,但是它其实已经很接近现在大家谈论较多的迭代式开发流程。当系统的主要需求和架构明确之后,软件团队进入了一个不断演进的evolution循环中。[开发→发布→听取反馈→根据反馈做改进]

    敏捷流程:

    优点:

    1)敏捷开发的高适应性,以人为本的特性。
    2)更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。
    

    缺点:

    1)由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。
    

    理解卡内基梅隆大学(CMU)软件工程学院总结的TSP原则:

    TSP建立的基本原则如下:

    (1) 在遵循定义好的过程并得到快速反馈时,学习是最重要的;
    (2) 高效团队的协同工作存在- -些基本的共性,如具体又一致的目标、良好的工作支撑环境和强有力的指导等;
    (3)在面临软件开发的实际问题时,讨论、分析并最终得到了有效的解决方案的同时,软件开发人员获益匪浅。

    TSP描述了下列内容:

    (1)如何规划和管理-.个软件开发团队;
    (2)如何制定团队工作所需要的策略;
    (3)如何定义和确定团队中每个角色的职责;
    (4)如何为团队中每个成员分配不同的角色;
    (5)团队机器不同角色在整个开发过程的不同阶段应该做些什么,如何更好地

    发挥作用:

    (1)如何协调团队成员之间的任务,并跟踪报告团队整日的任务进度;
    (2)采用哪些方法提高团队的协作能力。

    任务3:在班级博客园,有很多高校的软件工程课程要求同学们完成团队项目,请与实验三结对伙伴协商,在以下三个班级中选择一个高质量的团队项目案例进行协作学习,要求追踪该团队项目发布所有博客作业,下载项目软件代码。

    1.团队项目作业发布账号链接https://www.cnblogs.com/PureMan6/p/10739662.html

    2.团队项目仓库github链接https://github.com/swearitagain/EduCnblogs2.0

    3.陈述你选择该团队项目进行分析的理由:

    首先对于他们团队做出的App感觉很新奇,用手机软件查看和管理自己的博客园很有用。
    在博客中看出他们的程序完成度很高,值得深入研究。

    4.结合项目系列博客文档,总结项目团队成员的分工合作情况

    成员&身份 具体任务
    PM:邵旭哲、吴昊 1.完成所有的博客撰写
    2.管理Github项目和issues
    3.编写问卷,收集并整理用户需求和反馈
    4.规划项目下一步实现的功能
    5.组织每日例会,了解监督任务进度
    6.了解和沟通Alpha版本的发布渠道并进行发布
    开发:吴昊 1.学习代码编写
    2.实现功能“成员列表”的迁移
    3.编写团队贡献分分配规则,scrum meeting汇总并提交
    4.构建devote相关的框架
    5.处理"ClassFunction"页面存在的bug
    6.编写投票功能:查看班级投票、查看参与成员
    开发:胡俊崧 1.学习react-native框架,熟悉项目结构
    2.重构"我的班级"界面UI,使其交互更人性化
    3.增加对作业的操作中学生、老师、助教的区分
    4.增加作业分类展示功能
    5.增加删除作业功能
    6.增加修改作业功能
    7.编写博客分享功能
    8.编写记录用户使用情况的部分用以改进Alpha版本
    开发:陈治齐 1.重构'我的班级'页面显示博文的代码
    2.编写班级选择功能和界面
    3.完成班级博文列表筛选功能的重构
    4.编写消息通知功能
    5.修复查看班级博文显示不正确的错误
    6.编写投票功能:获取投票内容、获取投票
    7.统计统一全局列表样式
    开发:蒋锋 1.增加查看班级公告列表功能、修复相关问题
    2.增加发布公告功能、修复相关问题
    3.增加编辑公告功能
    4.增加公告的操作中不同身份的区分
    5.增加删除公告功能
    6.增加收藏博文的功能
    7.研究打包发布app
    测试:吴枫 1.学习测试,复现上一版本未修改的bug
    2.测试用户的登录与登出,测试作业相关功能
    3.测试班级博客的功能,与成员功能
    4.汇总新功能,根据功能制作测试分支树
    5.写自动化脚本,联合测试作业的所有功能
    6.编写单元测试,获得代码覆盖率

    总结:每个人的分工明确,任务分配均匀,是很好的团队项目的分工。

    5.结合项目系列博客文档,评价项目的软件项目过程特点(TSP)

    在团队中每个人都有自己明确的职责
    团队的分工也很合理
    每个人在每个阶段的任务都有相应的任务
    对于每个阶段的任务汇报都有明确的时间

    6.观察该团队项目github仓库的源代码文件结构,是否包含代码规范文档?

    包含代码规范文档

    7.下载团队项目代码,尝试部署项目运行环境并使用软件,描述最简单直观的使用体验,找出至少两个比较严重的功能性bug,在博客中展示截图

    没有在Git中没有找到相应的JAVA文件导致程序没有运行出来。


    在登录界面点击忘记密码等没有返回功能,看似有返回按钮,但点击并没有用,可能由于开发者忘记此处功能。



    再打开作业栏中的内容时,需要点击链接进行跳转

    8.评价该团队项目是否值得继续开发,并陈述理由?

    对于这个项目我觉得很有必要继续开发,可以将博客内容展示为适合屏幕的大小,再添加一些手机独有的特色功能,那么这款软件将会给很多人带来便利,让人随时随地管理自己博客,学习知识。

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

    项目 内容
    实验1 60min
    实验2 40min
    实验3 90min

    请谈谈完成本次作业的感受和体会。

    通过本次作业,我学习团队软件项目流程(TSP)、团队成员协作要求,同时通过学习其他团队的程序代码,使我也学习了很多新的知识。也掌握了软件开发中的不同的开发流程如:瀑布模型,渐进交付和敏捷流程。在今后的学习中我也会将这些知识融入到实际操作中,加深对其的理解。

  • 相关阅读:
    GmSSL 与 OpenSSL 共存的安装方法
    爬虫之ssh证书警告错误
    逆向so文件调试工具IDA基础知识点
    frida- registernatives获取so层动态注册函数
    绑定方法与非绑定方法, 反射
    Elk stack安装部署
    类的继承和组合
    安装部署kafka和zookeeper集群(三节点)
    ELK stack 生产问题
    Elasticsearch删除数据操作,你必须知道的一些坑
  • 原文地址:https://www.cnblogs.com/847118824wang/p/12675836.html
Copyright © 2011-2022 走看看