软件工程——个人总结
1.团队名称和项目名称
- 风启团队
- 寝室分配管理系统
2.学习和使用的新平台
- APIcloud手机APP开发平台很大的帮助了我们完成项目。
3.学习和使用的新工具
- mockplus原型设计工具,设计自己项目的原型,对自己项目有一个初步的印象。
- Enterprise Architect画类图,用例图等,明白自己项目的功能。
4.学习和使用的新语言
- css语言(因为主要任务是前端界面要用到html及css语言)
5.学习和掌握的新方法
- MarkDown排版方法
- 简单前端界面设计
6.完成的代码量
- 前端界面大概400多行
7.经验总结
- 完成一个项目开发需要很多东西不光是学习我们从未接触的知识还要学习团队协作能力。
- 完成一部分任务要及时总结,有错误要及时改正。要养成勤总结的习惯。
- 老师教过的知识在项目中用到的很少,说明对学的知识没有很好的掌握。
8.对学弟学妹的建议和告知
- 学习本课程会接触很多新东西,不要害怕难、学不会,尽力去学。
- 认真对待每次老师布置的作业,提升自己的编程能力。
- 在做项目这一块要尽早制定计划,小组成员团结协作。
9.对自己团队的分析
我们团队经历过萌芽阶段、磨合阶段、规范阶段、创造阶段。
- 萌芽阶段:只是匆忙组了队,还没有了解彼此的能力,初步建立了项目。
- 磨合阶段:在对项目进行规划时,队员产生了分歧,最后通过上网了解相关信息及查阅书籍达成共识。
- 规范阶段:通过聆听、讨论,成员互相之间更加了解,认识到并欣赏各自的能力和经验。
- 创造阶段:队员做自己的任务,团队的注意力集中到如何完成项目上。
10.补充
-
1.生鱼片模型中什么时候上一个阶段会结束呢?如何简化大瀑布带着小瀑布这种变型使这种问题能解决更多问题吗?
- 我看了《构建之法》,有这个问题,书中讲述了瀑布模型以及瀑布模型的变型,有生鱼片模型,大瀑布带着小瀑布。生鱼片模型描述各相邻模块像生鱼片那样部分重叠,大瀑布带着小瀑布是为解决子系统之间进度不一,技术要求迥异的模型。 但是我还是些问题不太懂,就像书中提到的困扰,生鱼片模型中什么时候上一个阶段会结束呢?如何简化大瀑布带着小瀑布这种变型使这种问题能解决更多问题吗?(第五章团队和流程P96)
- 回答:在生鱼片模型中每一个步骤是分离的,有些步骤可能一同进行也可能一同完成。这说明这种模型有局限。在大瀑布带着小瀑布模型中,我们看到每个环节我们可以简化这个模型例如在编码调试和子系统测试这里,我们可以分类,把功能类似的一起测试,减少了多次测试的麻烦。 -
2.我们应如何选择适合我们团队的敏捷流程?
- 敏捷流程很多方法论,例如FDD,SCRUM,XP这些方法论都是人们自己总结出来的,但它不是万能的,它有自己的适用范围,它也可以为我们指引方向,那么我们应如何选择适合我们团队的敏捷流程?书中也提出了这个问题让我们思考,看了这些问题我发现我们团队需要考虑的问题很多的,只有尽可能做到全面我们的项目才能更好的完成。(第六章敏捷流程P121)
- 回答:敏捷流程是总结出来的方法,它并不是万能的,它对于我们做项目有参考功能,我们也能根据这些方法完善我们的功能。 -
3.我们团队如何找到适合自己的需求分析方法?选谁来当PM(项目经理)?
- 书上说PM(项目经理)可以通过需求分析找到需求,第八章也找到很多需求分析的做法,我还是有困惑,我的困惑是我们团队如何找到适合自己的需求分析方法?选谁来当PM(项目经理)?(第九章项目经理P186)
- 回答:由于我们的项目是手机APP,我们就需要找到典型用户询问他们对我们项目的需求,我们根据她们的需求增添项目功能。至于PM就像书中提到的像乐队中的指挥一样,她懂得如何让队员最大的实现自身价值,她善于发现队员的优点和缺点,她也具有引导的能力。 -
4.使用UML建模有什么局限?
- 在理论课上我们讲了UML建模,主要学习了用例图,顺序图,类图,这三种不同的用例图有自己都有的优点,我还有疑问,我的疑问是使用UML建模有什么局限?如何更全面的建模?搜索了相关网页发现UML建模标准化的同时也让工程管理多了很多工作,要专门花精力来维护这么一套东西,是很花人力物力的。那么在这个基础上我们如何改进这些局限呢?
- 回答:UML建模只是对项目的初步规划,如果项目后期有变动或者没有达到最初的期望,那么建模的用处也不大。可以根据尽可能根据自己的能力,建立适合自己团队的模型。 -
5.如何有效的测试软件?在测试阶段怎样衡量构建的质量?
- 书中说到测试团队拿到一个构建之后,就会按照测试计划,测试各自负责的模块和功能,这个过程可能出现10个或100个以上的bug,我还是有疑问,我的疑问是就像书中的提问,如何有效的测试软件?在测试阶段怎样衡量构建的质量?(第十三章软件测试P260)
- 回答:选择适合自己项目的测试软件,比如我们组做的是APP就要通过不同的手机进行测试,通过对APP进行压力测试及兼容性测试等观察结果来衡量构建的质量。 -
6.通过四个象限对一个产品进行划分,有什么局限?
- 在书中讲如何通过四个象限对一个产品的功能进行分类,第一象限是杀手产品,第二象限是外围功能,第三象限是辅助需求,第四象限是必要需求。针对这四个象限也有不同的处理的方式,但是我还有困惑,我的困惑是需求分析中通过四个象限对一个产品进行划分,有什么局限?(第八章需求分析P344)
- 回答:通过四个象限对一个产品进行划分,可以让团队对自己的项目有明确的想法,也可以决定怎么处理不同类型的功能。但是这些划分只是给自己项目的功能进行排序, -
7.团队如何能让所有人都明确驱动和责任?
- 在书中练习与讨论里我看到了一个问题我也有相同的疑问,我的疑问是团队如何能让所有人都明确驱动和责任?在《梦断代码》读后感中说到,有理论认为,传统的软件公司用工资,职位,绩效考核等让一群经过面试和培训的人在严格定义的流程下一起工作(大教堂/Cathedral模式)。其实,用开源,社区,共享的模式会更好,但是作者举例反对了这个观点并说明了“义务”劳动并没有起到好的效果,这是关于驱动的问题。而责任与驱动是密切相关的,如果一个项目被拖延,迟迟不能完成,员工陆续离开公司,他们都没有承担自己的责任。我认为一个团队要让所有人明确驱动和责任就要沟通,内部外部都要沟通,而且要让队友明白自己的任务,并为自己的任务努力,制定规矩,以及奖惩制度,让自己的项目如期完成。团队应如何制度规矩?(第十七章人,绩效和职业道德P379)
- 回答:我认为团队可以每周进行会议总结,每个队员汇报自己的完成任务的情况。组长对项目及每个队员的任务进一步分析并制定规则,让组员意识到自己的驱动与责任。
11.个人发挥
在这次团队合作做项目中,我学到了很多,也很开心,意识到团队协作的重要性。