1.No Silver Bullet - Essence and Accidents of Software Engineering
这句话是说在软件开发的过程中并不存在一种有效的方法。他强调由于软件的复杂性本质，而使真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。所有软件创作都包括了本质性工作和附属性工作。前者是去创造出一种由抽像的软件实体所组成的复杂概念结构，后者则是用编程语言来表现这些抽象的实体，并在某些空间和速度的限制之下，将程序对应至机器语言。现在，若跟本质性的工作相比，软件工程人员所做的事，还有多少算是花在附属性的工作上呢？除非附属性工作要耗费的心力超过全部工作的9/10，否则就算是将所有的附属性工作降至零，也无法将整个开发工作的轻松程度提升一个数量级。本文还将困难分为下列几类：
•复杂性（complexity）：软件要解决的问题，通常牵扯到计算步骤，这是一种人为、抽象化的智能活动，多半是复杂的。
•隐匿性（invisibility）：尚未完成的软件是看不见的，即使利用图标说明，也常无法充分呈现其结构，使得人们在沟通上面临极大的困难。
•配合性（conformity）：在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难。
•易变性（changeability）：软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所汇集而成，而这些因素皆会快速变化。
多种困难造成软件开发中的没有银弹的情况。就比如说我们软件开发过程之中遇到了许许多多的问题，其中的一个就是我们无法把应用的界面设计的很美观。由于我们团队都是计算机学院的学生，大家艺术造诣极为有限，实在是没有什么妙招来解决这个问题，所以我们只有靠自己不断地去网站上面搜查资料，不断学习前人界面美化的经验来一点一点改进我们的界面了，虽然效果还是很有限。
2.big ball of mud
大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。无法使得系统内的信息得到更好的控制和共享，使得信息失去了应有的价值。大泥球般的系统的整体结构没有得到很好的界定，也就使得大泥球越发的复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。
那么大泥球产生的原因是什么，首先，程序员在编写程序或是系统时遇到问题后的解决方法，往往不是合适的或者最优的解法，而是方便修改的，变动最小的，这就为以后的系统架构的混乱甚至整个系统的奔溃埋下了隐患。其次，用户的需求或者编程的要求是在不断地变化的，任何一个已有的系统都随之会产生重大的变化，使得系统越来越复杂化，维护也越来越昂贵，另外编写人员的变动等等因素都会导致系统的退化，一步步变为大泥球。
所以，可以将其产生的原因归结为：一次性代码，碎片式增长，缺少前期设计，应对需求和架构变化过晚，程序员的经验，技巧，眼界的限制。
那么如何避免自己的程序中出现大泥球的情况呢？首先，程序员或者设计师为了在预算中并按时交付高质量的软件，就需要关注软件的特性和功能，然后集中在架构和性能，使得软件设计初步就避免产生小的问题或者方向的偏差。其次，程序员在编写软件时要及时的解决出现的小问题或者原型概念等等，这样不会使得问题堆积导致后期的无法修改。另外，应当及时处理用户需求的变化，由于需求往往会随着时间的推移而变化，所以应当逐步的解决，并且鼓励和积极面对变化而不是掩盖问题。另外，要保持一直工作的状态，不断地维护需求和系统。但不应当进行一次彻底的检查，这样很可能会破坏系统。当然，软件系统也是在变化的，但是不同的部分会以不同的速度变化，所以应当使得它们的变化率一致。最坏的结果就是代码已经下降到了无法修复甚至理解的地步，那么就扔掉，重新开始。
3. Cathedral and the Bazaar
在《Cathedral and the Bazaar》中，有两种模式的开发方式：
大教堂模式（The Cathedral model）︰原始码在本模式是公开的，但在软件的每个版本一个专属的团队所掌控。GNU Emacs及GCC就是这样的例子。
市集模式（The Bazaar model）︰原始码在本模式也是公开的，不过却是放在因特网上供人查看和开发。Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发就是这一过程的创始，并引用fetchmail的开发为例。
就我个人来说更为青睐市集模式，因为市集模式为我们提供了更为广阔的表现舞台，我们可以充分了解源代码，并且针对原始版本提出自己的一系列独特的改进办法，最终形成许多版本，演化成百家争鸣的情况，这样必将衍生出众多优秀的软件。
4. Managing the development of large software systems: concepts and techniques
此即是瀑布模型，1970年WinSTon Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； （3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
5. Agile Method – by Martin Fowler
敏捷方法是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。就我们团队而言，我们在软件开发的过程之中应用到了这种方法，我们将软件拆分为几大模块，每个模块分配人员来开发，几个同学一起面对面交流，组成紧凑而高效的软件开发团队，是对敏捷开发的实际应用。
6.本次软件开发到目前为止的感想
就我们这次团队项目而言，能说的的确不少。首先就是从我们确定选题之后毫无头绪，大家一起去查阅了好多的资料，然后勉强对整个项目有了基本想法，哪里该怎么实现，哪里该怎么设计之类的。再到后来对项目的分割，将项目分给为几个大的部分，每一组同学负责实现这些代码完成统一的接口，然后每个小组的同学之间互相讨论，注重实践，一步一个脚印的将项目做到现在。可以说已经有了许多的进步，万事开头难，现在回想起来项目刚开始时的无助仍然是记忆犹新。总之我们的项目也算是踏上了正轨，接下来的任务就是大家要和自己同组的小伙伴好好地商量，按照指定的接口实现自己的接口，最后大家同意调试，相信成功就在不远的前方等着我们。