软件工程_第一次阅读做业

项目	内容
课程	软件工程（罗杰）
做业要求	第一次阅读做业
个人课程目标	了解软工开发流程，编程实践
此做业帮助	阅读《构建之法》，对软工有基础认识

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.服务器压力较大