胜利者的经验并不复杂,那就是寻找人生的关键点,并在关键时刻竭尽全力

首先要说明下一个可能的误区，并不是越高级的越复杂的模型就一定好，不是螺旋模型一定比瀑布模型一定好，与每个项目的需要的开发人员数目和进度安排一样，根据各个项目特性，都各不相同。每个项目都有自己的一个适合的生命周期模型，具体决定选择模型上有几个维度：需求是否清晰、客户的信息化能力、行业的特点、是否采用新的架构和技术、开发人员的经验（包括程序员和架构师）、管理方面的经验等。而且越是复杂的模型对架构师的要

一个简单的学习的开始。我感觉UML的最大作用，对于程序员来说在于沟通。UML是一种标准的建模语言，如果仅仅想要读懂这种语言，其实很简单，对于架构师来说，最大的最用在于对系统的分析和设计。为了使用这种语言需要一种方法——Rational Unified Process（RUP），也称为Unified Process（统一过程）。UML的两个主要构建是——结构图和行为图。结构图分为：类图、对象

有些地方没有理解，随便写了，估计写出来没什么条理。以问题的方式来组织下：一、一般系统的人员数目和分工？首先如果不是大型的系统，那么小的精干的队伍是合理的。曾经有的测量显示：一个效率较高的程序员可能是效率较低的程序员的生产率的10倍。如果一个200个人的项目，那么如果其中有20几个最能干的项目经理，那么可以开除其余的人，只让这20几个人组织项目。但是如果是大型的项目，要上千人共同完成，那么不

读书的一点点总结吧，关于软件开发管理方面的知识，虽然可能以后工作中用不到，但是至少理解自己的角色。这章主要问题就是：造成项目滞后的最主要原因是缺乏合理的进度安排。几个可能的原因有：一、对估算技术认识的缺乏，制定的时候基于一种假设——一切都将运作良好。造成这种问题的原因大多是因为思路的不完善性，假如文档写的天衣无缝，程序写的尽善尽美，估计会和理想预期的一样。二、采用的估算技术隐含