想和大家一起来谈谈在软件工程中我们所做的第一步:系统分析。希望我们中国的代码人能吸取更多更好的理论和实际的经验,有符合我们实际情况的系统分析、开发方法、步骤以及文档。系统分析,我个人认为它应该是能体现系统的灵魂性的文档。该文档应有什么内容,表达什么意思是我想在这里与大家探讨的问题。我觉得在系统分析书中应该有以下内容(视项目而定)
1、 系统需求说明 说明系统是一个什么样的系统,用市场上现有的系统来类比,用客户(或是我们自己)需要一个什么样的系统进行说明,力求完整。并对系统的发展可扩充性进行描述(现在没有哪个系统是一次OK的)。说明与现有的系统有什么相同什么不同,说明未来系统的发展方面以及可移值性等能预见的事情。
2、 系统资源说明 对系统所需要的软件、硬件资源进行说明。描述系统所需要的所有的TCO成本。包括人员、时间、设备、系统、一次性投入资金、持续性投入资金这样的所有资源。
3、 系统可行性分析 对系统的实施中的资源进行分析,说明投入的合理性和必然性,对其中的所有不可预见性的投入进行合理的量化说明,来说明系统的实施的可行性。
以上为我所想到的系统分析说明书中应出现的前三种文档,不知大家有什么想法,请赐教。
作为开发前期的工作,还应该包括:总体设计和详细设计。
总体设计这个阶段必须回答的关键问题:概括地说,应该如何解决这个问题?
首先,应该考虑几种可能的解决方案。例如,目标系统的一些主要功能是用计算机自动完成还是用人工完成;如果使用计算机,那么是使用批处理方式还是人机交互方式;信息存储使用传统的文件系统还是数据库……
通常至少应该考虑下述几类可能的方案:
低成本的解决方案
系统只能完成最必要的工作,不能多做一点额外的工作。
中等成本的解决方案
这样的系统不仅能够很好地完成预定的任务,使用起来很方便,而且可能还具有用户没有具体指定的某些 功能和特点。虽然用户没有提出这些具体要求,但是系统分析员根据自己的知识和经验断定,这些附加的能力 在实践中将证明是很有价值的。
高成本的"十全十美"的系统
这样的系统具有用户可能希望有的所有功能和特点。系统分析员应该使用系统流程图或其他工具描述每种 可能的系统,估计每种方案的成本和效益,还应该在充分权衡各种方案的利弊的基础上,推荐一个较好的系统 (最佳方案),并且制定实现所推荐的系统的详细计划。如果用户接受分析员推荐的系统,则可以着手完成本阶段的另一项主要工作。
上面的工作确定了解决问题的策略以及目标系统需要哪些程序,但是怎样设计这些程序呢?
结构设计的一条基本原理就是程序应该模块化,也就是一个大程序应该由许多规模适中的模块按合理的层次结构组织而成。总体设计阶段的第二项主要任务就是设计软件的结构,也就是确定程序由哪些模块组成以及模块间的关系。通常用层次图或结构图描绘软件的结构。
详细设计总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化,也就是回答下面这个关键问题:"应该怎样具体地实现这个系统呢?"这个阶段的任务还不是编写程序,而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图,它们应该包含必要的细节,程序员可以根据它们写出实际的程序代码。通常用 HIPO 图(层次图加输入/处理/输出图)或PDL语言(过程设计语言)描述详细设计的结果。
我想这样的文档系统的思路是一个慢慢积累的过程,如JJX同志所说,我们现在有太多的形式上的东东,它并不是一个程序员真正需要的系统分析/设计书,对于系统的设计到实施到最后的代码以及验收有太多的改动和变化,我们正在一个极不规范的系统中生存,所以我们不可能有太多的选择,只能抄抄应付了事。所以与大家一起探讨一个真正适合我们的文档模式,这个模式或是说模板能为我们的代码工作减少负担,带来更多的动能,就目前的开发思路,应用环境和编程方法来说,传统的需求分析-系统分析-概要设计-详细设计-……已越来越不行了,因为: