在软件工程这门课中我们学到，一个软件的开发过程不是简单的一个选择编程语言编码实现的过程，而是一个要经过可行性研究分析、需求分析、形式化说明、总体设计、详细设计再到编码实现的过程，后期还需要对软件进行维护，整个软件的开发过程需要开发成员之间的密切而有效的合作。
这个学期，经同学的推荐，我读了一下《人月神话》这本书，一开始并不知道这是一本关于软件工程的书，毕竟这书名迷惑性太大，一般的人都会理解为是人跟月亮的神话，完全不会像软件工程的方向靠近。不过当你读了这本书之后会发现，整本书都是在以一种非常幽默的方式再给我们讲软件工程，每一章的标题都非常有趣，诸如“焦油坑”、“外科手术队伍”、“贵族专治”之类的标题给人一种耳目一新的感觉。在这里，我也推荐没有读过这本书的人去读一下。
《人月神话》这本书让我第一次接触到了“人月”这个概念，既人月是软件工程中工作量的计量单位，是项目所有参与者工作时长的累计，是最为方便计算成本的数据，是项目管理中常用的概念。这本书算是对软件工程项目开发过程中的一些定律上的指导吧，里面的很多观点让我对软件工程开发有了更好的认识。第一章“焦油坑”中它提出了这样一些看法：“我估计软件构件产品引起了3倍工作量，将软件构件整合成完整系统所需要的设计集成和测试又强加了3倍工作量。这些高成本的构件在根本上是相互独立的。创建事物的快乐,开发对其它人有用东西的乐趣将可以活动，相互齿合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力。不间断学习的乐趣工作在如此易于驾驭的介质上的乐趣--纯粹的思维活动，其存在移动和运转方式完全不同于实际物体。”这样的看法让我知道了软件开发的过程工作量是会不断增加的，编码开发的过程是一个非常享受的过程。当然，它还有很多非常有趣的观点。
诸如：①“人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的”，这应该是里面非常经典的一个观点，软件开发过程并不是一个简单的人月叠加过程，并不是增加人力，就一定可以减少开发过程的工作量，因为我们对自己的估计技术不确定，所以在管理和客户的压力下，常常缺乏坚持的勇气。向落后进度的项目中增加人手，只会使进度更加落后。向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务的重新分配本身和所造成的工作中断。培训新人员，额外的相互沟通；②“优秀的专业程序员的工作效率是较差的程序员的十倍。经验和实际表现之间没有相互联系。小型精干的队伍是最好的--尽可能的少。一拥而上的开发方法是高成本，速度缓慢，不充分的，开发出的产品无法进行概念上的集成”，对之作出的解释就是，一位首席程序员，类似于外科手术队伍的团队架构提供了一种方法--即能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底减少了沟通的工作量，虽然这句话有点打击普通程序员啊，但这也告诉我们要努力成为一个首席程序员哦，哈哈哈；③“为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。对于非常大型的项目，将设计方法体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法”；④“尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工”；⑤“程序开发呈程序规模的指数增长。全职程序员仅将50%的时间用于编程和调试。生产率是系统各个部分交互的函数，在1.5K千代码行/人年至10K代码行/人年的范围内变化。当使用恰当的高级语言时，程序编制的生产率可以提高5倍”；⑥“用户的实际需要和用户感觉会随着程序的构建，测试和使用而变化。软件产品易于掌握的特征和不可见性，导致了它的构建人员(特别容易)面临着永恒的需求变更。为变更计划软件产品的技术，特别是细致的模块接口文档--非常地广为人知，但并没有相同规模的实践。高级语言的使用，编译时操作，通过引用的声明整合和自文档技术能减少变更引起的错误”……还有好多很经典的观点，大家可以到图书馆找这本书自己看一下，从这些观点中，我们会发现“人月神话”这本书就像一本指导性的书，作者根据自己在软件工程开发长期摸索中得出了一些开发技巧，这些技巧就如同定律一般，按照这个做，开发过程会变得非常明晰，而违背它，开发工作就会变得非常繁琐。当年“软件危机”给了人们当头一棒，软件传统的软件开发暴露出非常多的诟病，缺乏更加科学的开发体系。“人月神话”软件开发带来一缕曙光。