摘要：
没有银弹这篇文章讲述了束缚软件工程的几个重要问题：1、复杂性：软件增加新的内容，其复杂度的增加是非线性的，整体复杂性的增加可能比线性增加要大得多。随着软件功能的增加，显然可靠性是会下降的，接着还会面临一系列的难题。2、软件整合：人不是上帝，不可能像上帝创造世界那样完成所有的工作，软件是由不同的人写出来的，所以软件的整合成了一个很大的问题。3、可变性：因为软件是给客户做的，一旦客户要求变化，那么软件就要跟着变化，所以，开发的软件是随时可变的。就像们的第一次编程作业，因为之前的题目定义不明确，我们中途修改过题目，这就像是用户的需求在变。4、不可见性：软件不像建筑那样是可见的，也没有空间性，虽然数据 阅读全文
摘要：
大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。这使得系统内的信息无法得到更好的控制和共享，使得信息失去了应有的价值。大泥球复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。产生： 首先，程序员在编写程序或是系统时遇到问题后的解决方法，往往不是合适的或者最优的解法，而是方便修改的，变动最小的，这就为以后的系统架构的混乱甚至整个系统的奔溃埋下了隐患。其次，用户的需求或者编程的要求是在不断地变化的，任何一个已有的系统都随之会产生重大的变化，使得系统越来越复杂化，维护也越来越昂贵，另外编写人员的变动等等因素都会. 阅读全文
摘要：
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。我感觉我们的团队项目中就用到了较多的瀑布型，但不全是，有些时候我们会遇到工作中的某些模块比较难处理，那么我们可能会暂时放一放，做下一个阶段的任务，有了头绪之后再回过头来做一遍。但是我们的开发过程是按顺序先走一遍的，类似于瀑布模型。 瀑布型的各个阶段：1、定义期 （1）问题的定义 （2）可行性分析 （3）需求分析2、开发期（1）系统设计（2）详细设计（3）编程调试（... 阅读全文
摘要：
在读了这篇文章过后，对我的原来的各种理解完全是种“颠覆”。过去我所了解到的Linux/Unix是开源的极好的系统.因为他的开源，所以其中的BUG很容易被人发现，因为他的开源，他们安全性是有所保证的。再同时他是一个精细的，简练的系统。但是，这里却说集市开发毁掉了Unix，表示说需要有人对版本负责，难道这是Linux成功的原因？因为对文章中说的一系列背景丝毫不了解，我也不能提出反驳的理由，所以，这个需要有人对版本负责，这个是一个新的声音。对我来说是个新的认识。原文链接：http://www.ituring.com.cn/article/9363 阅读全文
摘要：
在阅读了《The Cathedral and the Bazaar》的介绍后，大教堂和集市的软件发展模式： 大教堂的模型：在大教堂模式中，每一个版本的源代码都是可以被用到的，但是在不同版本间的已经开发好的代码被限制在一个专有的软件开发团队中。 集市的模式：在集市模式中，代码的开发是通过互联网以大众的视角来开发的。我们团队用的开发模式是集市模式，代码是放在TFS上供大家一同开发的，而不是一个版本一个版本的开发。如果不断的限定版本号，每个版本都有一个团队来负责，这是我们不需要的，我们要做的只有一个版本，接着在上面不断的修改完善。原文链接：http://en.wikipedia.org/wiki.. 阅读全文
摘要：
敏捷开发听上去就很能理解其特点，感觉上是一种不同于平常的软件开发方法。下面是具体的敏捷开发特点：敏捷型方法是“适应性”而非“预见性”。工程方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划， 然后依计划进行开发。这类方法在一般情况下工作良好，但（需求、环境等） 有变化时就不太灵了。因此它们本质上是拒绝变化的。而敏捷型方法则欢迎 变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适 应变化。敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。工程型方法的目标是定义一个过程，不管是谁用都工作。而敏捷型方法 则 阅读全文