软件工程_第一次阅读作业
项目 | 内容 |
---|---|
课程 | 软件工程(罗杰) |
作业要求 | 第一次阅读作业 |
我的课程目标 | 了解软工开发流程,编程实践 |
此作业帮助 | 阅读《构建之法》,对软工有基础认识 |
1.阅读教材后的问题
第4章 结对编程
总之,如果运用得到,结对编程可以取得更高的投入产出比(Return of Investment)。
- **Q1 **
此处的投入产出比仿佛是一个缺乏定义的概念。结对编程的核心想法大概是一人领航一人实际操作,并通过频繁交流迫使双方共同努力提高自身水平,这种工作模式在参与者水平均较高且相当的情况下一定程度上自然能减少错误、有一定督促效果,但考虑到磨合成本,以及现实中参与者往往存在水平、技能的差异,能否真的达到比两人高效协同工作收益更高,我持怀疑态度。
第6章 敏捷流程
教材中对敏捷开发团队成员提出了较高的要求:
1.以有进取心的人为项目核心,充分支持信任他们。
2.自助管理、自我组织、多功能型。
对于团队成员质量的保证,我有以下两个问题:
-
**Q2 **
这样的团队成员要求不说极高,但也算很高了。那么,为了持续保证成员质量,是否需要以某种形式进行团队成员出入的管理?以何种标准合适呢? -
**Q3 **
敏捷开发以充分信任为前提,但人和团队往往是有惰性的。即便是每日例会平行比较工作量,如果所有人在安逸的条件下都有一定的惰性,那就失去了比较的价值。如此而来,是否应当引入外界筛选压力从而督促团队提高效率呢?外界压力和信任是否存在一定冲突?
对于敏捷流程,我有以下问题:
- **Q4 **
敏捷开发以个人冲刺为工作行为单元,任务多零散。这样的模式对于有复杂依赖关系的软件系统,是否会导致在工作对接上导致效率降低呢?
第16章 IT行业的创新
两三个专注于某一领域的匠人,用非大规模制造技术打造出来的东西还有价值么?IT历史告诉我们,有很多成功的产品都是从小作坊开始的。
- **Q5 **
历史中的成功和当下成功的条件是很不同的。如今,软件行业的质量要求、用户需求都比以往多得多(用户容忍度低),在这种情况下,小作坊形式的产物会不会更容易面临因资源不足的问题难以达到当今环境的质量标准线,从而难以成功?
2.“软件” 和 “软件工程” 最初出现的场景
- 软件
Alan Turing于1935年在其论文“Computable numbers with an application to the Entscheidungsproblem (decision problem)”中提出。 - 软件工程
Margaret Hamilton于1968年在阿波罗计划期间提出。
3.目前流行的源程序版本管理软件和项目管理软件用户数量与优缺点比较
用户数量 (维基百科)
Name | Users | Projects |
---|---|---|
Github | 31,000,000 | 100,000,000 |
GitLab | 100,000 | 546,000 |
Bitbucket | 5000,000 | Unknown |
SourceForge | 3,700,000 | 500,000 |
Launchpad | 4,000,000 | 41,000 |
优缺点比较:
-
Git
- 优点:
1.适合分布式开发,强调个体
2.用户项目多,利于交流
3.很好的版本管理功能支持
4.公共服务期压力和数据量不会太大
5.可以离线工作 - 缺点:
1.概念较多,学习成本相对较高
2.权限管理较复杂
- 优点:
-
Bugzilla:
- 优点:
1.检索功能强大
2.Bug跟踪处理
3.强大的后端数据库支持
4.免费开源
5.有汉化版本 - 缺点:
1.安装需要Mysql数据库配置,修改配置文件也较繁琐
2.汉化乱码
- 优点:
-
Mercurial:
- 优点:
1.服务器部署较容易
2.命令兼容SVN
3.多数命令有双字母缩写,命令行工作效率较高 - 缺点:
分支管理不灵活,相对于Git进行branch管理很不方便
- 优点:
-
SVN:
- 优点:
1.集中式服务器,更能保证安全性,易于管理
2.使用相对简单 - 缺点:
1.若中心服务器出现问题,所有人的工作都会暂停,且恢复较麻烦
2.必须联网才能提交、还原、对比
3.服务器压力较大
- 优点: