首先想要说一句，感觉这个软件工程课的阅读作业好多啊，回想起上一学期上的面向对象的课程，着实没有读什么东西。
就书上以及博客上面讲解的内容，结合我的理解，软件工程这门课其主要的核心是关于软件构造过程的一种方法论。关于其中的一些方法，我在这里就不做过多的介绍，主要谈一谈自己的感想。
计算机软件的发展，最开始就是几个人的玩具，这些是属于少部分人的事情的，随着时间的发展，软件在我们的日常生活中所占的比重越来越大，渐渐地，对软件的需求也不断的提升。最终形成了软件工程，在这个阶段，我们锁面临的复杂度也是极大地提升。于是，就需要一种必要的方法将大家组织联系在一起。
从这些读的内容中，了解了很多关于软件开发过程中的要求以及方法。比如开发的模式，测试，项目计划等等方面的知识。了解的东西很多，然是同时，也让我陷入了一些迷茫。读的时候有一种感觉，就是在想，对于一个标准的软件开发流程，有这么多的要求，我自己做的过程中到底达到了多少。
书中印象最深刻的一句话就是：代码首先是为了人而写的，不是为了机器。
当然，我把看到的几句话作为自身总结：
1） 不是高手不要假装高手
2） 乐于承认错误
3） 敢于面对程序中的错误
4） 不要把很简单的原理扯得很复杂
我们每个人的能力各不相同，每个人感兴趣、专研的方向也各不相同，为了让我们能够更好的参与团队协作，我们更应该积极参加相应的讨论，让组内成员明白自身的优缺点，并有选择地进行功能的实现，尽可能让本身简单的东西，做出来之后也是特别简单。还有就是软件工程需要我们具有其思想，并不是每一个功能都需要我们自己使用代码实现，我们完全可以选择性地用一些已经有了的开源软件进行相应的开发，这样不仅开发时间大大减少，甚至在性能上都会有比自己开发的要好。所以我们在开发的时候逐渐明白开发代码时选择的重要性。
当然这次阅读作业重点不在于此，而在于解决并处理各种问题。
不能有银弹
软加工程是现在很多地方采取的一种提出很长时间但又是在不断前进的事物。我们应该用发展的眼光来看待软件工程。而银弹是软件工程中常见的问题。为了解决这个问题，不少人提出了自己的看法。但作者却有自己的想法。他提出了一个相互牵制关联的概念结构，是软件实体必不可少的部分，它包括：数据集合、数据条目之间的关系、算法、功能调用等等。
我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。当然，我们还是会犯一些语法错误，但是和绝大多数系统中的概念错误相比，它们是微不足道的。如果这是事实，那么软件开发总是非常困难的，天生就没有银弹。
我们团队一开始对任务有了较好的分配，而且最后的实现也遵照了部分最初的要求。但是逐步开发才明白这个事物并没有想的那么简单，我们是在不断摸索中前进，在不断跨越障碍中前进。虽然对于面向对象编程一直都有着很高的期望值，可我们现在虽说也是写过一定数量的面向对象程序，却依旧没有真正掌握其精髓。我们没能够很好的完成各项指标，但是我们在初步时刻完成了自身要求。我们不能期望着银弹横空出世为我们干掉所有的障碍，在自己的能力范围内尽可能多地学习程序设计手段或许才是完成工程的不二法门。
所以就目前来讲，我们所做的项目只能按部就班，按照目前软件工程的既定步骤，逐步地完成。除了认真学习所学知识，团结协作，没有什么捷径可用。
你的项目有一个大泥球么? 有什么解决办法？
所谓大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，多种指导方法一起出现，然而实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。我想每个同学在拿到学长的代码之后，会对学长的代码进行批评，认为学长的代码的出现了大堆的”泥球“。但是现在我们才明白这项工作的难度，我们的代码中很多就出现了泥团的问题。但是由于时间问题等等，我们没有对其中进行改正，所以我们完全没有资格批评学长。
其实，我们的软件，直到现在可能还有一些问题，但是这些问题无伤大雅，所以我们可能没有对其中的一些进行改正。很多时候就是这样，我们完全没有办法对一些事情进行更新完善，我们可能完全没有能力对事情进行分类。。。。。。
只要我们不断对过程进行完善，我们才能更为完美地实现我们的需求。
CatB – Cathedral and the Bazaar
我认为作者写这篇文章，是鉴于当时的自由软件开发的现状。这就回到了我们一开始的状况了，我们很多时候就是在选择开源软件的过程中不断提升速度，完善我们工程的。
我们既然有了PM，有了QA，有了EX，我们当然可以对软件的优劣有了较为深刻的认识。我们的项目现在是在不断分配需求，然后实现任务的过程中前进的。但是这是有问题的。没有对任务有的明确要求，没有对代码有认真测试，没有对真正的用户进行体验，我们完全没能够有效实现要求。
Managing the development of large software systems: concepts and techniques
瀑布模型采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。而对于我们这种较小规模的软件开发项目，瀑布模型并无裨益。
软件工程的方法论到底有多少用处?
软件工程的方法伦很多，有敏捷编程，敏捷编程中又分很多方法论：如极限编程等。但大体上软件工程的方法论一般就是一些普通要求。软件开发速度更快，软件速度更快，软件开发更加弱耦合，软件可以拆分成若干相互独立的部分等。只有我们不断追着这些要求，我们才能完成得更加好。
总而言之，软件工程中有很多问题，我们完全没法把这些问题解决得尽善尽美。所以我们要在有限的时间里，不断更新完善这些知识，并且在这些情况中择出我们需要的功能。当然，我们还需要团队协作，以提升我们的能力，同时提升我们自身的能力。