A
amsea
Unregistered / Unconfirmed
GUEST, unregistred user!
主题:如何写系统分析书
内容:
想请大家一起来谈谈在软件工程中我们所做的第一步：系统分析。
在之前见到吕布由 NEASE转发过来的一个文章，深觉国人的计算机系统能力还需要提高，而更多的代码人 在找一个对系统更好的开发体系和方式，在代码联盟之前的一些贴子中也有i.q他们提 出的这样的问题，所以我想就这样的事来与大家共同探讨，这样这个 CCU.Programming.Engineering才有更深的意义，希望我们中国的代码人能吸取更多更 好的理论和实际的经验，有附合我们实际情况的系统分析、开发方法、步骤以及文档。
系统分析，我个人认为这里应该出来系统的灵魂性的文档。这样的文档应写什么样 的内容，表达什么样的意思是我想在这里与大家谈的问题。 我觉得应该说出以下内容（视项目而定）：
1、系统需求说明 说明系统是一个什么样的系统，用市场上现有的系统来类比，用客望（或是我们自己） 需要一个什么样的系统进行说明，力求完整。并对系统的发展可扩充性进行描述（现在 没有哪个系统是一次OK的）。说明与现有的系统有什么相同什么不同，说明未来系统的 发展方面以及可移值性等能预见的事情。
2、系统资源说明 对系统所需要的软件、硬件资源进行说明。描述系统所需要的所有的TCO成本。包括人 员、时间、设备、系统、一次性投入资金、持续性投入资金这样的所有资源。
3、系统可行性分析 对系统的实施中的资源进行分析，说明投入的合理性和必然性，对其中的所有不可预见 性的投入进行合理的量化说明，来说明系统的实施的可行性。 以上为我所想到的系统应出现的前三样文档，不知大家有什么想法，请赐教。
作为开发前期的工作，好象也就这么些。但我觉得不够。还应该包括：总体设计和详细设计 总体设计 这个阶段必须回答的关键问题是：“概括地说，应该如何解决这个问题？”
首先，应该考虑几种可能的解决方案。列如，目标系统的一些主要功能是用 计算机自动完成还是用人工完成；如果使用计算机，那么是使用批处理方式还是 人机交互方式；信息存储使用传统的文件系统还是数据库……。通常至少应该考虑 下述几类可能的方案：
低成本的解决方案。
系统只能完成最必要的工作，不能多做一点额处的工 作。
中等成本的解决方案。
这样的系统不仅能够很好地完成预定的任务，使用 起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没 有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的 能力在实践中将证明是很有价值的。
高成本的“十全十美”的系统。
这样的系统具有用户可能希望有的所有功 能和特点。 系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种 方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上，推荐一个较好 的系统（最佳方案），并且制定实现所推荐的系统的详细计划。如果用户接受分 析员推荐的系统，则可以着手完成本阶段的另一项主要工作。
上面的工作确定了解决问题的策略以及目标系统需要哪些程序，但是，怎样设 计这些程序呢？结构设计的一条基本原理就是程序应该模块化，也就是一个大程 序应该由许多规模适中的模块按合理的层次结构组织而成。总体设计阶段的第二 项主要任务就是设计软件的结构，也就是确定程序由哪些模块组成以及模块间的 关系。通常用层次图或结构图描绘软件的结构。
详细设计 总体设计阶段以比较抽象概括的方式提出了解决问题的办法。
详细设计阶段 的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这 个系统呢？” 这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规 格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该 包含必要的细节，程序员可以根据它们写出实际的程序代码。 通常用ＨＩＰＯ图（层次图加输入／处理／输出图）或ＰＤＬ语言（过程设计语言 ）描述详细设计的结果。 我想这样的文档系统的思路是 一个慢慢积累的过程，如JJX同志所说，我们现在有太多的形式上的东东，它并不是一 个程序员真正需要的系统分析／设计书，对于系统的设计到实施到最后的代码以及验收 有太多的改动和变化，我们正在一个极不规范的系统中生存，所以我们不可能有太多的 选择，只能抄抄应付了事。所以与大家一起探讨一个真正适合我们的文档模式，这个模 式或是说模板能为我们的代码工作减少负担，带来更多的动能 我认为就目前的开发思路，应用环境和编程方法来说，传统的需求分析-系统分析 -概要设计-详细设计-。。。已越来越不行乐。
1。现在的应用和以前大不一样。现在的应用是一种庞大的集成，包括跨平台， 网络，数据库等等，而且新技术的出现越来越快，任何人都无法精通甚至是掌握 全部技术。 简单例子：现在有windows,unix,linux等平台，有sql server,oracle,sybase等 数据库，有C++,vb,delphi等工具，谁能全部精通呢？如果不能，那么如何确定是 windows+sql server+delphi好还是unix+oracle+C++合适？
2。客户没有需求 我做过银行，电信等大客户，也做过各种小客户。他们无一另外的说“我要做一个 OA系统”，“我要做一个企业网”，“我要做一个。。。”。可他们无法确定要 实现什么，因为：很少有用户是真正由于业务的需求而做项目的；而且他们也不清 楚能够实现什么(因为他们不懂notes,不懂企业网)。
3。需求与环境的变化 由于在项目开发前客户没有实质性的需求，加上软件开发人员不熟悉客户的业务， 就导致在开发过程中需求的不断变化，严重时将导致分析与设计作废。
4。对象化的工具和过程化的程序 现在的开发工具已经很对象化了，而我们开发的程序却很过程化。也就是说你虽然 努力的模块化，层次化，可只要运行环境有所变化，你还要不断地修改，再修改辕 马。 实际中是这样说明我们确实需要把实际中的做法修改一下。
一个项目如果做到了80%的时候才真正明确则个系统是什么样子的话，我认为是设计者 的失败。 我认为在设计阶段不但应该做好传统做法的各种文档和论证，而且，应该做一些具体 的设计 工作了。比如，系统的整体运行设计及系统各功能模块的具体设计。而且这些设计应当都 有详细 的设计说明书。当这些说明书完成后，应当能做到，随便找个程序员他都能只通过看某功 能模块的 设计说明书就能够开始代码的开发而不用再重新思考该怎样去做了，程序员在这里就真的 只是一个 设计者的实现工具。 当然，也象某些兄弟说的那样，现在的系统都越来越繁杂越来越庞大越来越向集成性 质靠拢， 似乎是没有多少人能掌握具体用什么做效果是否如何如何，但关键就是这里。莫非真的没 有人能 做到这点吗？非也！只不过是目前的显示情况是，设计人员的水平偏低，有些公司的设计 人员根本 就没有多少的开发经验，他又怎能了解太多的系统呢。系统设计在目前看来似乎是个拿钱 多干活 少的工作，但这是不正常的现象。培养一个程序员根本不用花多大的力气，一个人只要不 太笨不太 蠢，给他一个机会，相信就能掌握某门技术或方法。但要掌握若干种方法，就不是能够通 过速成 解决的了。 问题也在于此。目前似乎所有的系统设计人员都能够设计所有的东西。其实不然。很 多人都有 知识的局限性，这就决定他只能对某些方向的东西做出决策和设计。客户固然不知道他要 做什么， 但我们应该知道。如果在前期能够多接触用户多深入实际，把设计人员当成客户工作中的 一员， 他就能够真正了解到客户的需求，当然也就能够为他做出合适的设计。
至于说到各种系统之间的好坏对比，我想，任何东西都没有绝对，有的只是某些方面 的权衡。 比如性能或空间的权衡或者价格和性能的权衡，或者就是功能侧重上的权衡等等等如此而 已。计算机 里的东西没有哪一样的存在不是包含了这种权衡在内的。虽然从商务上似乎总想说服用户 什么东西好 什么东西不好，其实从技术上讲无所谓好和不好，有的只是区别及该区别所针对的问题而 已。这就 象有人总在争论linux和window到底谁好一样。或许从“技术”上讲，linux比window好， 但这其实 并不公正，因为漂亮的GUI界面和友好的人际交互同样应该是“技术”中应该考虑到的一部 分。把所有 的东西结合起来一看就知道没有绝对的好。所以，不见得非要在用户决定之前由系统设计 的人员 事先来为各种方案做个排队，只需要了解用户的需求，然后从大方向上决定一个方向再做 具体设计 就可以了。 继续我的发言。
在这里我只从过去的实践角度举例来说，至于理论方面实在 没时间深入。 首先，认同两个说法：
1。项目(或说工程)有三个主要方面：功能，时间，成本。
2。系统分析的任务：将用户的业务逻辑转化为程序逻辑，计算时间和成本。
好，让我们来做一个概要设计：
1。功能：简单的信息发布系统。
2。系统分析员根据项目的时间和成本，在充分权衡各种方案的利弊的基础 上提出SQL SERVER+CORBA+DELPHI的方案。 。。。 用户很满意，OK，
开始详细设计：
1。为方便用户的安装使用三层结构。
2。客户端包含信息分布和查询两个模块。
2。使用各种图或语言描述各种函数，过程，模块，层次。 。。。 一切顺利，开始编码。 。。。 编码完成，用户试用，这时用户提出：在客户端要能实时跟踪信息的变化， 而你却发现DELPHI的CORBA不支持回调！转用其它方按时间上不可能，补救 措施也不灵(比如使用timer，但客户的网络环境不允许多个用户的频繁刷 新)，怎么办？ 现在来分析一下问题出在哪里：
1。有人会说系统分析员不真正了解客户的需求，可这不可能(项目时间的限 制)也不现实(不可能让分析员到每个岗位都去操作一下)。
2。有人会说系统分析员的知识和经验不足，可现实却是分析员认为应该的 客户觉得没必要，而客户觉得必须的分析员有不可理解。这是不同的工作造 成的，俗话说隔行如隔山。
3。有人会说系统分析员的水平不够，可问题绝大部分是出在细节而不是大方 向上，掌握全部细节可能吗？ 这里就是一个长期困扰我的问题：细节(而不是方向)往往成为成功与失败的 关键(注意，这里的成功是包含了时间和成本的)，而细节是不可能全部发现 与分析清楚的。如何在这种不完整的需求上构造完整的系统呢？或是根本不 可能呢？ 你说的问题确实存在。而这种问题我就遇到过多次──当然都是别人做的设 计。 但我认为这个过程中不足的地方就是：把东西做死了，没有切实地为用户着 想。 很多人在做设计时，可能考虑的最多的是实现上的方便，而不是系统的扩展及 更新。需知道，用户的需求是在不断变化的，如果总是在设计前就“善意”地替用 户假设，是难以预料后事的结局的。所以我想，在设计阶段就因该把可能出现的问 题都摆到桌面上讨论，包括其特点及效果和后果，而不是自以为是地好心地替用户 “假设”。 其实一个系统设计的优劣，其系统的扩展性能是一个很重要的指标，一个单纯 就事论事地针对某件事情而做出的“专用”系统是没有任何远见的。
内容:
想请大家一起来谈谈在软件工程中我们所做的第一步：系统分析。
在之前见到吕布由 NEASE转发过来的一个文章，深觉国人的计算机系统能力还需要提高，而更多的代码人 在找一个对系统更好的开发体系和方式，在代码联盟之前的一些贴子中也有i.q他们提 出的这样的问题，所以我想就这样的事来与大家共同探讨，这样这个 CCU.Programming.Engineering才有更深的意义，希望我们中国的代码人能吸取更多更 好的理论和实际的经验，有附合我们实际情况的系统分析、开发方法、步骤以及文档。
系统分析，我个人认为这里应该出来系统的灵魂性的文档。这样的文档应写什么样 的内容，表达什么样的意思是我想在这里与大家谈的问题。 我觉得应该说出以下内容（视项目而定）：
1、系统需求说明 说明系统是一个什么样的系统，用市场上现有的系统来类比，用客望（或是我们自己） 需要一个什么样的系统进行说明，力求完整。并对系统的发展可扩充性进行描述（现在 没有哪个系统是一次OK的）。说明与现有的系统有什么相同什么不同，说明未来系统的 发展方面以及可移值性等能预见的事情。
2、系统资源说明 对系统所需要的软件、硬件资源进行说明。描述系统所需要的所有的TCO成本。包括人 员、时间、设备、系统、一次性投入资金、持续性投入资金这样的所有资源。
3、系统可行性分析 对系统的实施中的资源进行分析，说明投入的合理性和必然性，对其中的所有不可预见 性的投入进行合理的量化说明，来说明系统的实施的可行性。 以上为我所想到的系统应出现的前三样文档，不知大家有什么想法，请赐教。
作为开发前期的工作，好象也就这么些。但我觉得不够。还应该包括：总体设计和详细设计 总体设计 这个阶段必须回答的关键问题是：“概括地说，应该如何解决这个问题？”
首先，应该考虑几种可能的解决方案。列如，目标系统的一些主要功能是用 计算机自动完成还是用人工完成；如果使用计算机，那么是使用批处理方式还是 人机交互方式；信息存储使用传统的文件系统还是数据库……。通常至少应该考虑 下述几类可能的方案：
低成本的解决方案。
系统只能完成最必要的工作，不能多做一点额处的工 作。
中等成本的解决方案。
这样的系统不仅能够很好地完成预定的任务，使用 起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没 有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的 能力在实践中将证明是很有价值的。
高成本的“十全十美”的系统。
这样的系统具有用户可能希望有的所有功 能和特点。 系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种 方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上，推荐一个较好 的系统（最佳方案），并且制定实现所推荐的系统的详细计划。如果用户接受分 析员推荐的系统，则可以着手完成本阶段的另一项主要工作。
上面的工作确定了解决问题的策略以及目标系统需要哪些程序，但是，怎样设 计这些程序呢？结构设计的一条基本原理就是程序应该模块化，也就是一个大程 序应该由许多规模适中的模块按合理的层次结构组织而成。总体设计阶段的第二 项主要任务就是设计软件的结构，也就是确定程序由哪些模块组成以及模块间的 关系。通常用层次图或结构图描绘软件的结构。
详细设计 总体设计阶段以比较抽象概括的方式提出了解决问题的办法。
详细设计阶段 的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这 个系统呢？” 这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规 格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该 包含必要的细节，程序员可以根据它们写出实际的程序代码。 通常用ＨＩＰＯ图（层次图加输入／处理／输出图）或ＰＤＬ语言（过程设计语言 ）描述详细设计的结果。 我想这样的文档系统的思路是 一个慢慢积累的过程，如JJX同志所说，我们现在有太多的形式上的东东，它并不是一 个程序员真正需要的系统分析／设计书，对于系统的设计到实施到最后的代码以及验收 有太多的改动和变化，我们正在一个极不规范的系统中生存，所以我们不可能有太多的 选择，只能抄抄应付了事。所以与大家一起探讨一个真正适合我们的文档模式，这个模 式或是说模板能为我们的代码工作减少负担，带来更多的动能
我认为就目前的开发思路，应用环境和编程方法来说，传统的需求分析-系统分析 -概要设计-详细设计-。。。已越来越不行乐。 1。现在的应用和以前大不一样。现在的应用是一种庞大的集成，包括跨平台， 网络，数据库等等，而且新技术的出现越来越快，任何人都无法精通甚至是掌握 全部技术。 简单例子：现在有windows,unix,linux等平台，有sql server,oracle,sybase等 数据库，有C++,vb,delphi等工具，谁能全部精通呢？如果不能，那么如何确定是 windows+sql server+delphi好还是unix+oracle+C++合适？
2。客户没有需求 我做过银行，电信等大客户，也做过各种小客户。他们无一另外的说“我要做一个 OA系统”，“我要做一个企业网”，“我要做一个。。。”。可他们无法确定要 实现什么，因为：很少有用户是真正由于业务的需求而做项目的；而且他们也不清 楚能够实现什么(因为他们不懂notes,不懂企业网)。
3。需求与环境的变化 由于在项目开发前客户没有实质性的需求，加上软件开发人员不熟悉客户的业务， 就导致在开发过程中需求的不断变化，严重时将导致分析与设计作废。
4。对象化的工具和过程化的程序 现在的开发工具已经很对象化了，而我们开发的程序却很过程化。也就是说你虽然 努力的模块化，层次化，可只要运行环境有所变化，你还要不断地修改，再修改辕 马。 实际中是这样说明我们确实需要把实际中的做法修改一下。
一个项目如果做到了80%的时候才真正明确则个系统是什么样子的话，我认为是设计者 的失败。 我认为在设计阶段不但应该做好传统做法的各种文档和论证，而且，应该做一些具体 的设计 工作了。比如，系统的整体运行设计及系统各功能模块的具体设计。而且这些设计应当都 有详细 的设计说明书。当这些说明书完成后，应当能做到，随便找个程序员他都能只通过看某功 能模块的 设计说明书就能够开始代码的开发而不用再重新思考该怎样去做了，程序员在这里就真的 只是一个 设计者的实现工具。 当然，也象某些兄弟说的那样，现在的系统都越来越繁杂越来越庞大越来越向集成性 质靠拢， 似乎是没有多少人能掌握具体用什么做效果是否如何如何，但关键就是这里。莫非真的没 有人能 做到这点吗？非也！只不过是目前的显示情况是，设计人员的水平偏低，有些公司的设计 人员根本 就没有多少的开发经验，他又怎能了解太多的系统呢。系统设计在目前看来似乎是个拿钱 多干活 少的工作，但这是不正常的现象。培养一个程序员根本不用花多大的力气，一个人只要不 太笨不太 蠢，给他一个机会，相信就能掌握某门技术或方法。但要掌握若干种方法，就不是能够通 过速成 解决的了。 问题也在于此。目前似乎所有的系统设计人员都能够设计所有的东西。其实不然。很 多人都有 知识的局限性，这就决定他只能对某些方向的东西做出决策和设计。客户固然不知道他要 做什么， 但我们应该知道。如果在前期能够多接触用户多深入实际，把设计人员当成客户工作中的 一员， 他就能够真正了解到客户的需求，当然也就能够为他做出合适的设计。
至于说到各种系统之间的好坏对比，我想，任何东西都没有绝对，有的只是某些方面 的权衡。 比如性能或空间的权衡或者价格和性能的权衡，或者就是功能侧重上的权衡等等等如此而 已。计算机 里的东西没有哪一样的存在不是包含了这种权衡在内的。虽然从商务上似乎总想说服用户 什么东西好 什么东西不好，其实从技术上讲无所谓好和不好，有的只是区别及该区别所针对的问题而 已。这就 象有人总在争论linux和window到底谁好一样。或许从“技术”上讲，linux比window好， 但这其实 并不公正，因为漂亮的GUI界面和友好的人际交互同样应该是“技术”中应该考虑到的一部 分。把所有 的东西结合起来一看就知道没有绝对的好。所以，不见得非要在用户决定之前由系统设计 的人员 事先来为各种方案做个排队，只需要了解用户的需求，然后从大方向上决定一个方向再做 具体设计 就可以了。 继续我的发言。
在这里我只从过去的实践角度举例来说，至于理论方面实在 没时间深入。 首先，认同两个说法：
1。项目(或说工程)有三个主要方面：功能，时间，成本。
2。系统分析的任务：将用户的业务逻辑转化为程序逻辑，计算时间和成本。
好，让我们来做一个概要设计：
1。功能：简单的信息发布系统。
2。系统分析员根据项目的时间和成本，在充分权衡各种方案的利弊的基础 上提出SQL SERVER+CORBA+DELPHI的方案。 。。。 用户很满意，OK，
开始详细设计：
1。为方便用户的安装使用三层结构。
2。客户端包含信息分布和查询两个模块。
2。使用各种图或语言描述各种函数，过程，模块，层次。 。。。 一切顺利，开始编码。 。。。 编码完成，用户试用，这时用户提出：在客户端要能实时跟踪信息的变化， 而你却发现DELPHI的CORBA不支持回调！转用其它方按时间上不可能，补救 措施也不灵(比如使用timer，但客户的网络环境不允许多个用户的频繁刷 新)，怎么办？ 现在来分析一下问题出在哪里：
1。有人会说系统分析员不真正了解客户的需求，可这不可能(项目时间的限 制)也不现实(不可能让分析员到每个岗位都去操作一下)。
2。有人会说系统分析员的知识和经验不足，可现实却是分析员认为应该的 客户觉得没必要，而客户觉得必须的分析员有不可理解。这是不同的工作造 成的，俗话说隔行如隔山。
3。有人会说系统分析员的水平不够，可问题绝大部分是出在细节而不是大方 向上，掌握全部细节可能吗？ 这里就是一个长期困扰我的问题：细节(而不是方向)往往成为成功与失败的 关键(注意，这里的成功是包含了时间和成本的)，而细节是不可能全部发现 与分析清楚的。如何在这种不完整的需求上构造完整的系统呢？或是根本不 可能呢？ 你说的问题确实存在。而这种问题我就遇到过多次──当然都是别人做的设 计。 但我认为这个过程中不足的地方就是：把东西做死了，没有切实地为用户着 想。 很多人在做设计时，可能考虑的最多的是实现上的方便，而不是系统的扩展及 更新。需知道，用户的需求是在不断变化的，如果总是在设计前就“善意”地替用 户假设，是难以预料后事的结局的。所以我想，在设计阶段就因该把可能出现的问 题都摆到桌面上讨论，包括其特点及效果和后果，而不是自以为是地好心地替用户 “假设”。 其实一个系统设计的优劣，其系统的扩展性能是一个很重要的指标，一个单纯 就事论事地针对某件事情而做出的“专用”系统是没有任何远见的。
