【IT168 技术文章】

　　如果眼光仅仅放在满足客户眼下的需求，当问题不断出现时再不断修补，头痛医头，脚痛医脚，甚至系统构架需要不断调整或重新设计，那么，很快就会陷入代码泥潭或坠入系统重复开发的无底深渊，当初项目完成时的成就感将被无止境的沮丧所代替。系统分析决定系统开发的成败，软件建模使系统开发走向成熟。

　　本章包括以下内容：

　　一：系统分析在网站项目管理中的地位

　　二：系统分析所要做的工作

　　三：系统分析的难点和技能要求：

　　四：软件建模使系统开发迈向成熟

　　五：总结

　　一：系统分析在网站项目管理中的地位

　　在进行了需求分析和业务流程分析并得到客户的认可之后，对项目进行系统分析是极其重要的。系统分析是能体现整个系统的灵魂的文档，将客户的需求从具体到抽象的一个过程，并制定编码人员可实施的规范和标准。

　　由于Web应用技术发展的历史相对与软件的历史短得多，在开发网络应用系统尤其是网站制作的系统设计中设计人员往往对系统分析重视的不够，特别是设计一些初期比较简单的或交互及功能较少的网站时，主要原因通常为：

　　? 客户初期的需求比较简单，忽略了客户潜在的巨大需求;

　　? 项目实施周期短，初期阶段采用最快的而不是最合理的实现手段;

　　? 经费有限，难以支付高质量的人力费用;

　　? Web编程技术手段多样，容易上手，设计人员参差不齐;

　　从现实中来看，网站项目的开发与管理和实施远不如软件工程规范，在编程语言、数据库、通信协议、应用服务器等相关环境都在不断快速发展和完善的情况下，的确很难期望每一个设计师都能网站项目进行系统的合理的分析，从而制定一套跨平台、健壮的、易扩展和升级的系统方案。

　　但是，这并不能成为系统分析员逃避或懈怠的借口，如果把一个系统比做一部汽车，系统分析的工作相当于设计发动机，也许很容易就想像的出用125cc的摩托车发动机去牵引10吨重载卡车会是一个什么样的后果。

　　在系统分析的过程中需要对需求分析进行进一步的深化和分析，通常客户及业务人员在需求分析和流程分析的过程中比较注重功能上的表现和定义，即使是做出正规的用户界面原型，对系统的需求也是不完整的，处于非技术人员的缘故，很难苛求能提出完整清晰专业的性能需求，但不意味着这需求不存在，而且这隐藏的需求对编码人员来说是极其重要的。

　　因此，客户的需求能否在系统中得到真正的体现和实施，系统分析是至关重要的。

　　二：系统分析所要做的工作：

　　把系统分析和详细设计阶段分开，针对不同项目的具体情况再决定采用什么方式进行开发。

　　那么在系统分析过程中重点要做的是：

　　? 对客户的需求分析进一步完善和补充，尤其是性能需求：让客户更加清楚这是一个什么样的系统，所要达到的功能和性能指标是什么，系统的扩展性和适应性如何，如何为客户今后的升级或维护提供最有效的方法。

　　? 系统运行所需要的的环境：系统能正常运行所需要的硬件、软件、网络环境;

　　? 系统的资源说明：系统所需要的各种成本。包括人员、时间、工作环境、一次性投入资金、持续性投入资金等所有资源。

　　? 系统可行性分析;

　　对于系统分析员比较苦恼的是大多客户在系统的要求上提不出独立的或成熟的意见，而将烫山芋交给了系统分析员的手上，为了避免在系统论证方面难以把握的失控和无从下手，设计几种不同类型的方案供客户选择不失为一个好的方法：

　　“比如通常至少应该考虑下述几类可能的方案：

　　1：低成本的解决方案

　　系统只能完成最必要的工作，不能多做一点额外的工作。

　　2：中等成本的解决方案

　　这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证明是很有价值的。

　　3：高成本的"十全十美"的系统

　　这样的系统具有用户可能希望有的所有功能和特点。系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上，推荐一个较好的系统(非常好的方案)，并且制定实现所推荐的系统的详细计划。如果用户接受分析员推荐的系统，则可以着手完成本阶段的另一项主要工作。”(引用《如何写系统分析书》一文)

　　经过系统分析的阶段，我们就比较容易和客户在系统如何部署、采用的数据库类型、设计模型和分析模型等方面达成一致的认识，如果能顺利地将客户的需求业务逻辑分析转化为程序逻辑，把原先用户可视化的界面原型和业务流程图映射成编码人员理解的模型和规范时，那么恭喜你，项目已经成功了一半。