软件开发过程新领悟

最近做项目对于产品开发过程控制有了新认识，先暂记如下，以后再研究。

需求分析与设计是按主题划分的

基本上一个研发类项目可按如下主题划分：

1.业务与问题主题 分析需求和问题、得出产品构想。
2 解决方案主题 需求分析后设计解决方案(产品架构 核心产品功能设计)。
3.产品功能主题 需求分析后产品功能设计。(覆盖所有功能点)
4.程序设计主题 需求分析后程序设计（详细数据结构、过程设计（时序图））。
5.功能实现主题 根据设计编码。

各个主题都有需求分析过程，但是这里的需求分析是特指当前主题下的需求分析。比如程序设计时的需求分析，是指要实现的界面内容及交互动作是什么。

这些不同的主题内容，会在软件的开发过程中出现。


------------------------------------------------------------------
关于时序图：
从自动路由得来的经验，复杂的程序的第一版顺序图落实到代码上会有很多的漏洞，随着代码的编写需要修改很多次，因此在功能开发时的设计文档，不应包含
详细的顺序图，顺序图应该是存储在工具中的，这样方便随时修改，因为在写代码时变动的可能性太大了。

这个理解是有问题的。如果在开发前，时序图是可以详细明确的，应该放在文档中。对于不同复杂度的程序时序图在未开发前，能明确的程度是不同的。比如swing的调用过程，就比较好明确。没有理由，明明可以画的很详细，却故意画的很简化。

无论怎么画时序图，在开发前，都是想把要开发的内容理清楚，并记录。只是需要寻找一种最佳形式。如果人的思考能力，可以不借助于任何工具，那就可以完全不同时序图了。

开发前时序图是用来发现需要的类和描述详细或概要的主要过程(取决于问题的难度)。不需要将全部过程的顺序图画出来，也不应该用图来限制代码的变化，因为在实现时也许会想到更好的办法或发现之前的想法是错的。详细死板的使用顺序图，现在无用，将来也无用。关键的顺序图写在设计文档中即可，不需要再用uml工具画出来其它过程的图，因为没必要。通过一个顺序图做为敲门砖，可以想通一组相关的过程，那些类似的过程，是没必要再表达为时序图的。

在开发后，文档中的顺序图，能起到读代码的入口，是一个非常不错的定位。这个是要在开发后和软件保持一致的。

通过以上方法，即可以保持设计文档的简捷有效，又因为单个功能需要维护的时序图较少，这就使设计文档和软件保持一致成为可能。

这个思想的总原则是相信人的思考能力，并不需要依赖穷举类型的设计文档，相似的过程是可以举一反三的。

以下也是一个基本事实：
写代码时也是需要进行设计的，有时非常简单可能就是某种技术的直接应用，也可能是非常复杂的，涉及复杂的算法和并发处理，这些内容的实现可能要经过多次的试错才行，这导致详细的设计文档很难准确。因此，必须还是要靠开发人员才能得到最后的实现方法。因此，没必要在设计文档中定义一切，准备的描述关键内容，其它的内容由开发人员补充即可。
--------------------------------------------------------------

象需求、设计、架构这样的词汇，都有自已的内含。但在不同的主题范围内，指代内容又不同。因此有其泛指和特指。
---------------------------------------------------------------