今天读的是前五个话题。
第一个概念，就是关于软件行业中的度量单位问题——人月。在阅读这本书之前，我一直以为人月神话就是指的是人们想要造出一个月亮一样大的工程，然后作者会对这个进行一通分析。结果读完之后才知道，所谓人月，是指工作量。或者说，我们时常认为的进度。事实上，这一方式很不合理，这个等到后面再讲。
之后就是关于软件估算的问题。往往这都是一个死循环。没有事先做好规划，想要缩短工期，就仓促的开展项目，就会导致后期的测试以及修改大幅度增加，从而事与愿违。尤其是在看了一些软件方面的书之后，感觉这个真的是一个难逃的死结。不过作者好像提到了一种比较新的方法。作为一个学生，不知道到底好不好用，但是从理论上来看，确实是挺好的。
关于人月的问题，作者的观点与大部分需求分析书上所说相同，进度并不会随着人数的增加而变快。可以列举几个情况（当然也是理念上的）：
1.任务不可能分解，所以每个进程所花时间不会因为人数的增加而减少，所以增加人数无效
2..任务可以分解，将任务进行再一次分解，以及对人员的培训，再加上意见的分歧，往往导致时间成本超过了原来人数少的时候。
所以作者提出了一种模型，叫做外科医生式（有点武侠的感觉）。首先就是有一个设计者，他的主要功能与权限最大，设计以及形成统一的概念，其他的部分都各自有专门的人负责。之后如果人数进一步加大，那么只需要协调不同的设计者之间的关系就好。
这其中设计师或者说是架构师，所做的就是设计和总体的结构，并没有完全剥夺作为实现人员的创作的快感（当然，我个人认为不是这样，因为架构师往往还能获取一种帮助他人，看到自己的设想为人所用的快感。而实现人员。。。。大概是替公司赚钱的荣誉感）。
最后一个挺有意思的部分就是作者的引用的一个模型，也就是体现结构，设计实现，还有就是物理实现。设计人员最先启动，设计实现人员在有了系统雏形时，就可以开始准备所需要的工具。之后就是物理实现上的算法准备。