202212-奋起上进组 实验五 团队作业2:软件项目案例分析
项目 | 内容 |
---|---|
班级博客 | 2019级卓越工程师班 |
作业要求 | 实验五 团队作业2:软件项目案例分析 |
团队名称 | 奋起上进组 |
课程学习目标 | (1)学习团队软件项目流程(TSP)、软件项目团队的角色分工,软件项目经理的职责; (2)掌握敏捷流程原则及相关概念; (3)软件案例分析 |
学习目标实现 | (1)团队成员之间通过线上交流协作学习,分享各自的学习体会,能够快速了解到自己未知的知识; (2)理解了软件团队的各种模式以及特点; |
团队博客链接 | 奋起上进组 |
任务1:阅读《现代软件工程—构建之法》
一、要求
-
阅读《现代软件工程—构建之法》第5、6章内容,理解并掌握软件项目团队的特点和模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点,理解并体会卡内基梅隆大学(CMU)软件工程学院总结的TSP原则。
-
阅读《现代软件工程—构建之法》第9章内容,了解软件项目团队设置项目经理的缘由、项目经理的职责。
二、《现代软件工程—构建之法》第5章
1、团队的特点:
(1) 团队有一致的集体目标,团队要一起完成这个目标。
(2) 团队成员有各自的分工,互相依赖合作,共同完成任务。
2、软件团队的模式:
Team | 模式 | 内容 | 特点 |
---|---|---|---|
Chaos Team | 一窝蜂模式 | 像小朋友踢球一样,球在哪里,人就一窝蜂跟在哪里 | 优点:欢乐而随意 缺点:这种团队模式很难存活,并不是一种好的团队模式 |
Cheif Programmer Team, Surgical Team | 主治医师模式 | 首席程序员负责处理主要模块的设计与编程,其他成员对其各个方面的辅助。 | 优点:其他人员可以为主力人员服务 缺点:这种团队模式可能出现一人出力其他人打酱油。 |
Super-star Model | 明星模式 | 主治医模式运用到极点,可以蜕变为明星模式。 | 优点:对主力个人的成长进步可能会有所帮助 缺点:团队模式强调的是团队的作用,而不是个人的独角戏,这种模式显然违背了团队模式的初衷,效率也很低 |
Community Model | 社区模式 | 成功的社区项目都有严格的代码复审和迁入的质量控制。 | 优点:“众人拾柴火焰高” 缺点:“只烤火,不拾柴”,“拾到的柴火质量太差” |
Amateur Theater Team | 业余剧团模式 | 在每一个项目中,不同的人拥有不同的角色,每个角色有自己不可或缺的责任。 | 优点:每个人都可以尝试不同角色,大家可以比较平等地讨论 缺点:在竞争性强烈、创造性要求高的团队,不会存在完美主义的民主气氛。 |
Skunk Work Team | 秘密团队 | 团队内部有极大的自由,较高的热情,没有外界的干扰。 | 优点:可以有效的提高效率 缺点:不可能成为普遍模式,只会针对个别项目。 |
SWAT | 特工团队 | 有一些有特殊技能的钻也人士组成,负责解决一些棘手而紧迫性的问题。 | 优点:高效率 缺点:对成员的知识面要求十分广,较为针对技术人员,不可能成为普遍模式 |
Orchestra | 交响乐模式 | 项目拥有齐全的部门管理,每个部门拥有较高的效率,同时严格听从总项目方负责人指示。 | 优点:各司其职,重在执行 缺点:局限性强 |
Jazz Band | 爵士乐模式 | 团队人员即兴发挥,没有详细的计划。 | 优点:领导给出一个主题,然后成员们百花齐放,各显本领,快收尾时再总结 缺点:人员不能太多 |
Feature Team | 功能团队模式 | 具备不同能力的人员平等协作,共同完成一个功能。 | 优点:效率高 缺点:每个小组必须与其他小组就编程规范达成一致 |
Bureaucratic Model | 官僚模式 | 拥有明确的等级划分。 | 优点:有助于技术的交替与互补 缺点:容易掺杂一些追名逐利,往往会使团队效率大打折扣 |
3、瀑布模型
瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点
(1) 传统瀑布模型:
-
传统瀑布模型开发软件的特点:
- 阶段期间具有顺序性和依赖性
- 推迟现实的观点
- 质量保证的观点
-
传统瀑布模型开发软件的缺点:
-
瀑布模型是由文档驱动的
-
传统瀑布模型:
(2) 改进瀑布模型:
- 增加回溯功能的瀑布模型
- 建立模拟模型,使其运行两遍
- 引入顾客,是项目更加的完善。
(3) 瀑布模型的变形:
-
生鱼片模型
该模型解决了各个步骤之间分离的缺点,但是无法确定一个阶段结束的时间。
-
子瀑布模型
该模型解决了不同子系统之间进度不一,计时迥异,需要区别对待的问题,但使其难度变大。
瀑布模型(Waterfall Model)及其变形的对比:
模型 | 特点 | 优缺点 |
---|---|---|
瀑布模型 | (1)阶段间具有循序性和依赖性 (2)区分软件的逻辑设计与物理设计 (3)质量保证观点 |
优点: (1)可强迫开发人员采用规范的方法 (2)严格规定了每个阶段必须提交文档 (3)要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证 缺点: (1)软件的实际情况必须等到软件开发后期客户才能看到 |
变形:生鱼片模型 | 各相邻模块像生鱼片那样部分重叠 | 优点: (1)解决了各步骤之间分离的缺点 缺点: (1)无法明确上一阶段何时结束 |
变形:子瀑布模型 | 大瀑布带着小瀑布 | 优点: (1)解决了不同子系统间进度不一,技术要求迥异,需要区别对待的问题 缺点: (1)要将各个子系统统一到最后的系统测试阶段难度较大 (2)软件的实际情况必须等到最后客户才能看到 |
卡内基梅隆大学(CMU)软件工程学院总结的TSP原则
TSP(Team Software Process)原则是由卡内基梅隆大学软件工程学院(Software Engineering Institute, Carnegie Mellon University)将优秀的团队模式和流程的共同点抽象总结而来。TSP原则概览可访问TSP Overview - SEI Digital Library或如下所示。
- 使用妥善定义的流程,流程中的每一步都是可以重复、可以衡量结果的。
- 团队的各个成员对团队的目标、角色、产品都有统一的理解。
- 尽量使用成熟的技术和做法。
- 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
- 制定切合实际的计划和承诺,团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
- 增加团队的自我管理能力。
- 专注于提高质量,争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。
4、开发流程:
(1) 软件开发流程概念
我们在开发、运营、维护的过程中有很多的技术、做法、习惯和思想。软件工程把这些相关的技术和过程统一到一个体系中,叫做“软件开发流程”。
(2) 软件开发流程的目的:
为了提高软件开发、运营和维护的效率,以及提高用户的满意度、软件的可靠性和可维护性。
(3) Rational Unified Process统一流程(RUP):
- 业务建模
- 需求
- 分析和设计
- 实现
- 测试
- 部署
- 配置和变更管理
- 项目管理
- 环境
- 初始阶段
- 细节阶段
- 构造阶段
- 交付阶段
(4) 渐进交付流程,MVP和MBP:
-
渐进交付流程:指当系统的主要需求和架构明确之后,软件团队今年入了一个不断演进的循环中,直到时间用完,钱花光,完成了计划的的代次数,或者客户认为满意。
-
MVP (Minimum Viable Product):最小可行产品,又称为Minimal Feature Set,最小功能集。MVP是指把产品最黑新的功能用最小的成本实现出来(或者描绘出来),然后快速深秋用户意见。
-
MBP (Maximal Beautful Product):最强最美产品,MBP是指抓住用户的需求,将产品最全、最美的形态展现出来。
(5) Team Software Process (TSP) 的原则:
三、《现代软件工程—构建之法》第6章
1、敏捷流程简介
(1) 开发原则:
- 尽早并持续的交付有价值的软件以满足顾客需求。
- 敏捷流程欢迎须取得变化,并利用这种变化来提高用户的竞争优势。
- 经常发布有用软件,发布间隔可以是几周到几个月,能短则短。
- 业务人员和开发人员在项目开发过程中应该每天共同工作。
- 已有进取心的人为核心,充分支持信任他们。
- 无论团队内外,面对面的交流始终是最有效的沟通方式。
- 可用软件是衡量项目进展目标的主要指标。
- 敏捷流程应能保持最持续的发展。领导、他团队和用户应该能够按照米钱的步调秩序合作下去。
- 只有不断关注技术和设计,才能够越来越敏捷。
- 保持简明——尽可能简化工作工作量技艺——极为重要。
- 只有能自我管理的团队才能够创造优秀的架构、需求和设计
- 时时总结如何提高团队效率,并付诸行动
(2) 开发步骤:
- 第一步:找出完成产品需要做的事——Product Backlog
- 第二步:决定当前冲刺(Sprint) 需要解决的事请——Sprint Backlog
- 第三步:冲刺
- 第四步:得到软件的一个增量版本,发布给用户。然后在此基础上又进一步计划增量的新功能和改进
(3) 敏捷团队:
- 团队要求:
1、自助管理:自己挑选任务;每次Sprint结束后,自我反思与总结,并对自己实施改进。
2、自我组织:每个人联合起来对项目负责,随时帮助同事,随时填补项目缺少的资源。
3、多功能型:每个人都对项目负责,自己搞定规格说明书,和别人沟通,同时自己测评。
三、《现代软件工程—构建之法》第9章
1、项目经理的由来:
软件团队中除了能携带按摩、测试代码和画图做设计的成员外,为了解市场与用户的需求、协调各部分资源,正确把握产品定位和方向,解决用户痛点,持续优化产品等而设立的一个角色。
2、PM的职责:
- 正确的协调团队的内部外部
- 调配各部门资源与时间
- 有效进行风险管理
- 保证一个项目顺利按计划结项
3、合格PM具备的能力:
- 观察、理解和快速学习能力
- 分析管理能力
- 一定的专业能力
- 自省能力
四、讨论截图
任务2:以团队协作学习方式,从B、C、D三个软件案例分析任务中选择一个课题来进行。
选择软件案例分析 任务C
任务C)现在学习资料很多,但是很多同学在学习新技术的时候还是很茫然,有没有更好的学习路径? 大家可以体验一下“CSDN技能树”,这个软件包含了很多IT技能的学习资料(文章、课程)和练习题,可以边学边练,解锁全部知识点后,还可以获得一枚勋章,活动链接:https://bbs.csdn.net/topics/605609934。
作为核心用户,CSDN技能树是否满足你们对类似软件产品的期待? 你们发现这些技能树有什么亮点?这个软件产品状态离预期还差哪些方面?
-
团队各位成员花几天时间至少使用 <被评测软件>5次, 成为<被评测软件>的持续使用者,记录每位成员使用的时间和时长。
姓名 使用次数 使用总时长(h) 曹永兴 7 3 张蓉星 6 2.5 李斌 6 2.5 尚洁 6 2.5 -
汇总<被评测软件> 解决了你们什么问题? <被评测软件>在数据量/界面/功能/准确度上各有什么优缺点? 用户体验方面有问题么?
(以C语言技能树为例)- 左侧为C语言学习目录
- 中间部分列出了每个部分的具体知识点,点击可进入学习,学习完成后知识框背景会变为绿色,方便用户下次学习时查看学习情况
- 右上部分可选择制定学习计划,制定计划后会显示预计计划完成时间、学习计划、学习进度条,学习进度使用可视化方法,可使用户更有动力执行学习计划。右下部分显示学习奖章的获取情况。
进入学习知识点页面,可查看相关参考资料、做练习题、交流讨论且可在右侧记录笔记。在右侧放置笔记栏,不必专门转跳换页面去做笔记,方便用户随时进行知识点记录,且笔记栏可左右拖动进行大小调节。完成一个知识点的学习后,左侧目录栏会在对应一栏显示一片叶子标记。
进入习题练习页面
当该习题已回答正确,再次查看该习题时会有提示
- 左侧为C语言学习目录
-
解决的问题:很多同学在学习新技术的时候比较茫然,该系统将各个知识点汇总,并将知识点以分类,方便用户按章节学习,界面简洁美观,也使用户有了更好的体验。
-
缺点:在点击左上角选择其他技能树时,显示的列表不能滚动,且列表部分超出了下边框。
-
将<被评测软件>推荐给你们周围需要这样的软件朋友或同学, 记录你对这位用户使用体验的采访,记录采访提要如下:
1) 介绍这位用户的背景和需求 (他们为何要用这个软件/网站, 有什么痛点,还有别的需求吗?)。用户 专业 使用背景 提出的不足 其他需求 本校大三学生 地理信息科学 有的时候学的东西较多语法会混乱,还有很多库,包的函数使用方法不清楚,就可以用来查找资料,也可以方便与网友交流学习 觉得还是比较方便的, 练习题做起来感觉不错,就是选择题占比过大,如果能讲一些实用的包和例子就更好了 网上爬取poi数据,用于地图制作 2) 请这位用户使用10 分钟 <被评测软件> 的基本功能 ,上传用户使用<被评测软件>的照片。
3) 概述用户使用<被评测软件>的过程, 评判这位用户的问题解决了么?
该用户主要需求是在写代码时能方便查找自己不熟悉的语法及库函数的使用,需要爬取poi数据,通过了解测评python技能树,发现在这个网站中,可以较轻松解决自己的问题。
4) 采访这位用户对产品有什么改进意见?
觉得用起来还是比较方便的, 练习题做起来感觉不错,就是选择题占比过大,如果能讲一些实用的包和例子就更好了,应该多引入新颖的编程题,帮助用户学习提升。
任务3:完成《实验五 团队作业2:软件项目案例分析》团队博文作业
一、项目计划表
任务内容 | 计划完成需要时间(min) | 实际完成需要时间(min) |
---|---|---|
计划 | 20 | 35 |
估计这个任务需要多少时间,并规划大致工作步骤 | 470 | 615 |
任务一 | 150 | 190 |
阅读《现代软件工程—构建之法》 | 120 | 150 |
小组讨论 | 30 | 40 |
任务二 | 260 | 325 |
小组测评“CSDN技能树” | 240 | 300 |
采访使用者 | 20 | 25 |
任务三 | 60 | 100 |
团队博客 | 60 | 100 |
团队感受和体会
- 本次作业学习了《构建之法》的第五、六、九章节,了解到了多种多样的团队模式,如一窝蜂模式、主治医师模式、明星模式等等,在上次的实验中我们已经组建了团队,本次学到的知识恰好帮助我们更合理的调整团队内部的运行模式;同时掌握了一些比较重要的软件开发流程,例如:瀑布模型及其各种变形、渐进交付流程、敏捷过程模型等;在第九章中理解了PM的多种分类以及职责,把之前课堂学习的东西和这次实验过程能够完美的结合到一起。
- 在本次实验的任务二中,我们组选择了C,通过对CSDN技能树的测评、体会,确实发现了一些使用过程中出现的问题,我们也俺要求把中国技能树推广给了身边的朋友,听取了他们的意见和反馈,结合展示的使用感受,总体感觉还是有很大的帮助,推荐使用。