为什么软件工程的本质是管理复杂性
软件工程是软件的形成过程，除了概念本身，涉及到了工具和人。主要是how，如何形成软件，如果使用技术，人又如何。软件工程的本质是复杂性
对软件工程而言，不可避免的东西是(需求）变化；而软件是的本质是概念和概念之间的关系，这个本质类似什么，类似于中子会影响原子裂变。
所以，这导致了软件的复杂性爆炸。
这也是为什么《人月神话》作者在论述到这个本质和变化的时候说：“如果这是事实，那么终究没有银弹”。
这里且不去论证他这个论断是否正确，但是的确反应了人月神话描述的软件工程面临的诸多难题
1，软件很容易陷入泥沼
2，陷入泥沼很难纠正调控
……
复杂性有三类
1，问题域本身的复杂性
2，采用的技术方案引入的额外复杂性
3，涉及到的人和组织再引入的额外复杂性
理解了这三个复杂性，就理解了为什么软件容易陷入泥沼，因为不能控制变化发生，就不能控制复杂性爆炸；
需求变化是变化，会引发复杂性爆炸
不能尽然计划可以视为一种计划外的变化
技术变化也是变化
组织变化也是变化
这些都会极大引发复杂度变化
软件工程 必须要解决这三个复杂性
成功的有效率的软件工程，需要引入技术熵和组织熵的概念
熵是能量中不能做功的能量
技术熵和组织熵是技术和组织在解决问题中，额外多花费的能量。
很明显，这两者越少越好。
所以，软件工程必须管理复杂性
1，技术熵越少越好
2，组织熵越少越好
3，良好的领域抽象，是真正的关键
4，如何去控制变化，隔离变化，适应变化
传统的软件工程理论是无法解决这个问题的，我们先来看一下传统的软件工程理论是个什么东西
1，将软件按照时间阶段分为几个步骤（需求，设计，开发，测试，维护），这个划分是确保了完备性的
2，将每个步骤分配给一个或者几个角色，确保了这个划分是可执行，可管理，可组织的
3，微观上控制每一个步骤和节点的时间，风险，降低整体复杂性；提升可管理性
4，引入UML和工作协作方法（敏捷，瀑布……）来实现各个步骤之间的衔接和角色之间的衔接，确保整个理论是内洽的
这个理论，是一个管理性的理论，但没有解决任何软件工程的本质问题，只是确保了可管理性。
严格按照这个理论做的话，大概率可以提升软件的成功率的，但是效率和灵活性就难以保证了——这也是微软这种传统类型的软件公司和FG这种类型的软件公司的差异
至于正确的方式，回头慢慢聊
https://my.oschina.net/u/3364724/blog/2098256?from=timeline&isappinstalled=0