201771030103-陈正丽 实验四 软件项目案例分析
项目 | 内容 |
---|---|
课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
这个作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
我的课程学习目标 | 1.学习团队软件项目流程(TSP)、团队成员协作要求。2.掌握敏捷流程原则及相关概念。 |
这个作业在哪些方面帮助我实现学习目标 | 1.提高了阅读别人程序的能力 2.掌握团队项目开发的大致流程与相应的要求 3.编辑博客的相关技巧 |
结对方学号-姓名 | 201771030106-葛佳诚 |
结对方本次博客作业链接 | https://www.cnblogs.com/luor/p/12670178.html |
一.实验目的与要求
(1)学习团队软件项目流程(TSP)、团队成员协作要求。
(2)掌握敏捷流程原则及相关概念。
二.实验内容和步骤
任务1:在实验三得分100分以上作业中,任选一份作为案例,对案例项目成果进行评价,具体要求如下:
(1)对案例博文作业进行阅读并进行评论,评论要点包括:博文结构、博文内容、博文结构与PSP中“任务内容”列的关系,并将以上评论内容发布到案例作业的博客评论区。
(2)克隆案例项目源码到本地机器,阅读项目代码规范文档并运行代码,总结代码运行中存在的问题,体会案例博文是否有助于项目代码理解
。
- clone代码到本地
-
运行结果及存在的问题
-
用户登录页面
- 注册用户以及疫情信息上报成功
- 各二级部门疫情防控工作负责人注册登录后可使用高级查询功能进行多属性组合查询和可视化统计
发现存在的Bug
- 相同的用户名可以进行多次注册
案例博文在需求分析陈述、软件总体结构设计,软件功能描述部分做了详细的说明,并且在相关功能实现部分也做了详细的截图以及相应的说明,认真阅读以上部分,能理解该项目的大致核心和便于解答在测试部分遇到的疑问。在Github中也说明了相关使用的开发工具,便于其他人快速确认测试工具,综上所述,一篇优秀的博文有助于项目代码理解。
(3)总结本组实验三博客作业及代码设计存在问题与不足,列举代码中存在的bug,未实现的功能等等。
本组博客作业在内容方面考虑周全,设计合理,在截图模块大小合理,排版也很美观,在文本部分文字字体稍小,在每一小模块的设计中可以使用不同的背景颜色加以修饰,会使得博文更加完美。在项目系统中,没有实现用户防疫信息填报定时提醒功能。但是存在的这些问题大部分同学都存在,不过在一次一次的改进后,项目功能会越加完善。
任务2:与实验三结对伙伴协作学习:阅读《现代软件工程—构建之法》第5-6章内容,理解并掌握软件项目团队的特点、了解软件团队的模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点,理解并体会卡内基梅隆大学(CMU)软件工程学院总结的TSP原则;
- 1.软件团队的特点:
(1)团队有一致的集体目标,团队要一起完成这个目标。 (2)团队成员有各自的分工,互相依赖合作,共同完成任务。 |
- 2.软件团队模式
一窝蜂模式,主治医师模式,明星模式,社区模式,业余剧团模式,秘密团队,特工团队,交响乐团模式,爵士乐模式,功能团队模式,官僚模式。 |
- 3.软件开发流程:
3.1.写了再改模式(Code-and-Fix):不一定存在需求文档,直接编写代码,出现问题或需求变化时直接进行改动 3.2.瀑布模型(Waterfall Model)
(1)各步骤之间是分离的,但是软件生产过程中各个步骤不能这样严格分离出来。 (2)回溯修改很困难甚至不可能,但是软件生产的过程需要时间回溯。 (3)最终产品直到最后才出现,但是软件的客户,甚至软件工程师本人都需要尽早知道产品的原型并试用。
(1)如果产品的定义非常稳定,但是产品的正确性非常重要,需要每一步的验证。 (2)产品模块之间的接口,输入和输出能很好地用形式化的方法定义和验证。 (3)使用的技术非常成熟,团队成员都很熟悉这些技术。 (4)负责各个部分的子团队分属不同的机构,或在不同的地理位置,不可能做到频繁的交流。
(1)生鱼片模型:各相邻模块像生鱼片那样部分重叠。缺点:无法确定上一阶段是否结束、什么时候结束。 (2)大瀑布带着小瀑布:为了解决不同子系统之间进度不一,技术要求迥异,需要区别对待问题。缺点:难度较大。 |
- 3.3.统一流程(RUP)
重计划,重事先设计,重文档表达的各类模型(如:瀑布模型等)的集大成者。RUP将软件开发各个阶段整合统一在一个统一的框架内。
(1)业务建模:UML等语言 (2)需求 (3)分析和设计 (4)实现 (5)测试 (6)部署 (7)配置和变更管理 (8)项目管理 (9)环境
(1)初始阶段 (2)细化阶段 (3)构造阶段 (4)交付阶段 |
-
3.4.老板驱动的流程(Boss-Driven Process)
-
3.5.渐进交付的流程,MVP和MBP
渐进交付的流程:开发->发布->听取反馈->根据反馈做改进 MVP即最小可行产品,又称最小功能集。具体做法是把产品最核心的功能用最小的成本实现出来(或者描绘出来),然后快速征求用户意见。可以适用于新创立的企业在市场不确定的情况下来检验产品是否可行。 MVP的指导思想与渐进交付类似,但是它更强调更早获得用户反馈,为此可以在产品完成之前就发布,它也强调产品的核心价值(产品最区别于竞争产品的地方),为了突出核心功能,别的辅助功能可以不考虑或者用别的平台提供的服务来代替。 MBP即最强最美产品,对用户需求了然于心,或者产品团队比用户更了解用户的需求,把产品最全、最美的形态展现出来,一举征服用户。一般应用于时间比较充裕,客户要求标准比较严格,开发团队在此之前做了大规模的市场调研摸清用户需求。 |
- 4.TSP原则
(1)使用妥善定义的流程,流程中的每一步都是可以重复、可以衡量结果的。 (2)团队的各个成员对团队的目标、角色、产品都有统一的理解。 (3)尽量使用成熟的技术和做法。 (4)尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。 (5)制定切合实际的计划和承诺,团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。 (6)增加团队的自我管理能力。 (7)专注于提高质量,争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。 |
- 5.事后诸葛亮会议、Postmortem:
软件开发完成后进行的事后分析。对产品开发过程进行回顾并对其进行分析,总结不足之处,进而得出改进方案。 |
- 6.敏捷流程开发的原则:
(1)尽早并持续地交付有价值的软件以满足顾客需求。
(2)敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。 (3)经常发布可用的软件,发布间隔可以从几周到几个月,能短则短。 (4)业务人员和开发人员在项目开发过程中应该每天共同工作。 (5)以有进取心的人为项目核心,充分支持信任他们。 (6)无论团队内外,面对面的交流始终是最有效的沟通方式。 (7)可用的软件是衡量项目进展的主要指标。 (8)敏捷流程应 能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去。 (9)只有不断关注技术和设计,才能越来越敏捷。 (10)保持简明一尽可能简化工作量的技艺 一 极为重要。 (11)只有能自我管理的团队才能创造优秀的架构、需求和设计。 (12)时时总结如何提高团队效率,并付诸行动。 |
- 7.敏捷的步骤:
第一步:找出完成产品需要做的事情——Product Backlog 第二步:决定当前的冲刺(Sprint)需要解决的事情——Sprint Backlog 第三步:冲刺。期间团队通过每日例会(Scrum Meeting)进行面对面交流,所有人向同伴报告进度。Scrum Master根据项目情况,用简明的图表展现整个项目的进度(燃尽图Burn Down Chart、看板图Kanban) 第四步:得到软件的一个增量版本,发布给用户。然后在此基础上又进一步计划增量的新功能和改进。 |
- 8.敏捷的团队:
(1)自主管理:自己挑选任务、每次冲刺结束后总结经验并改进 (2)自我组织:每个人联合起来对项目负责 (3)多功能型:项目的测试、说明书等由每个人负责 |
- 9.敏捷流程的经验教训:
(1)敏捷宣言表明的是一些优先级, 不必当作圣旨或者教条来争论。 (2)Serum Master 不是一个官, 而是一个没有行政权力的沟通者,就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master,大多行不通。 (3)一些项目需要很多暗箱操作和政治角力才能搞定,Scrum会把这些矛盾都摆到明处。这有好处,也有风险。 (4)在复杂的项目里,要让一线团队成员做决定。 (5)创业公司的团队其实经常是运行在某种快节奏的敏捷的模式中(只不过大家太忙,没工夫论证自己到底有多么敏捷)。 (6)在Scrum 计划阶段的估计不是一个“合同”,领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint,这样即使不准的估计也不会有大的损害。 (7)不要和管理层谈“流程”,他们只关心“结果”。 (8)在大型团队、跨地区的团队,或者复杂项目中,Scrum 并没有非常完美的答案,Scrum的创始人也承认这一点。 |
- 讨论任务2截图:
- QQ聊天截图
-
在文本文件中互相交流学习情况
结对方学习成果
自己学习成果
任务3.在班级博客园,有很多高校的软件工程课程要求同学们完成团队项目,请与实验三结对伙伴协商,在以下三个班级中选择一个高质量的团队项目案例进行协作学习,要求追踪该团队项目发布所有博客作业,下载项目软件代码。
我们选择的是:2019春季计算机学院软件工程 (北京航空航天大学)
(一). 团队项目作业发布账号链接:https://www.cnblogs.com/LightOfFuture/
(二). 团队项目仓库GitHub链接:https://github.com/ThinMoon/ESchool
(三). 选择该团队项目进行分析的原因:
|
(四)项目团队成员分工合作情况
- 1.团队的角色,管理,合作
(1)团队的每个角色是如何确定的,是不是人尽其才?
(2)团队成员之间有互相帮助么?
(3)当出现项目管理、合作方面的问题时,团队成员如何解决问题?
|
- 2.团队成员分工
(五)项目的软件项目过程特点(TSP)
(1)团队的各个成员对团队的目标、角色、产品都有统一的理解。
(2)分工明确,团队成员的自我管理能力强。 (3)团队各个成员在每次学习中都会总结学习成果以及第二天的学习计划。 (4)团队成员掌握技术水平不一致,人尽其才,项目中的技术是使用成熟的技术; |
(六)该团队项目github仓库的源代码文件结构,是否包含代码规范文档?(TSP)
|
(七)下载团队项目代码,尝试部署项目运行环境并使用软件,描述最简单直观的使用体验,找出至少两个比较严重的功能性bug,在博客中展示截图(TSP)
- clone该团队项目到本地
用户注册界面如下: 错误图1 错误图2
![](https://img2020.cnblogs.com/blog/1946992/202004/1946992-202004102114181471422612861.jpg) 除了上述出现的问题外,还存在其他的Bug和可优化内容。 |
(八)评价该团队项目是否值得继续开发,并陈述理由
这个团队项目主要研发的是顺风车、校园兼职、代取快递,能满足当代大学生的实际需求,大部分学生因为懒惰或者特殊情况而需要代取包裹,家庭经济比较困难和需要锻炼自己能力的同学就非常需要校园兼职这个平台来寻找合适的工作,没有人不需要出门办事打车的,综合所有的因素,这个项目能满足当前市场的需求,因此这一项目值得进一步开发,如果能扩展更多的功能最好。 |
- 完成《实验四 软件项目案例分析》各项任务实际花费的时间
内容 | 计划花费时间(h) | 实际花费时间(h) |
---|---|---|
总计 | 32 | 48 |
任务1 | 10 | 18 |
任务2 | 5 | 6 |
任务3 | 15 | 20 |
任务4 | 2 | 4 |
四.总结
此次试验的目的是学习团队软件项目流程(TSP)、团队成员协作要求。并掌握敏捷流程原则及相关概念。通过阅读《现代软件工程—构建之法》第5-6章内容了解且掌握了相关的概念,理解并掌握了软件团队的特点以及在团队协作过程中应该注意的事项,浏览并其他同学\团队的博客并测试优秀案例,从中获益匪浅,同时也能清楚自己和同学之间的差距,在以后的学习中会更加注意对内容的理解。