在进行系统分析时要注意的结合是

1. 在新系统开发之前必须先进行什么分析

需求分析奠定了软件工程和项目管理的基础。我们在建造软件系统这座大厦的时候，如果需求分析的基础不够坚实和牢固，那么往往会导致软件系统问题百出，甚至被马上丢弃。在建造软件系统的过程中，如果我们经常习惯地沿用一些不规范的方法，其后果便是产生一条鸿沟──开发者开发的与用户所想得到的软件存在着巨大的“期望差异”。 因此“需求”这个名词的定义不仅仅是从用户角度对系统外部行为的描述，以及从开发人员角度对系统内部特性的描述，其关键的一点是“需求”必须文档化。

需求的类型
软件需求包括三个不同的层次──业务需求、用户需求和功能需求。 除此之外，每个系统还有各种非功能需求。
业务需求（BusinessRequirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。 用户需求（UserRequirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
功能需求（Functional Requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavioral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。
非功能需求（Non-functional Requirement） 定义了软件产品为满足用户业务需求而必须具有的除功能需求以外的特性。包括系统的完整性（联机帮助、 数据管理、用户管理、软件发布管理、在线升级等）、性能、可靠性、可维护性、可扩充性、对技术和业务的适应性等。
需求分析的任务
1 解决的问题
1) 齐全、准确地找出目标系统全部的功能、性能、限制； 2) 找出全部的输入流、输出流； 3) 找出所有的加工；
4) 产生完整的分层的DFD、数据字典、加工的描述； 5) 补充的意见。
2 综合要求
确定对系统的综合要求，系统功能要求，系统性能要求，运行要求，将来可能提出的要求。
3 任务
图1为需求分析任务图，需求分析阶段要完成的具体明确的最终任务就是形成一份经开发方和用户认可或达成共识的软件需求分析文档（需求规格说明书、修改后的项目开发计划、初步的用户手册、确认测试计划、数据要求说明书）。这个文档能清晰准确地说明系统将要开发什么，能够规定出详细的技术需求，包括所有面向用户、面向机器和其它软件系统的接口。可以说需求文档在开发过程中一直起指导作用。
为了更好地完成软件开发第一阶段的需求分析任务，提高质量，需求管理是必不可少的。
需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更，主要体现在跟踪和控制需求变更管理。需求管理是开发工作有效进行的保证，是一种很高层次的系统行为，涉及整个开发过程和产品本身。
需求分析的方法
需求分析方法由对软件问题的信息域和功能域的系统分析过程及其表示方法组成，大多数的需求分析方法是由信息驱动的。信息域具有三种属性： 信息流、信息内容和信息结构。
常用的需求分析方法有：面向数据流的结构化分析方法（SA），面向数据结构的Jackson方法（JSD），面向数据结构的结构化数据系统开发方法（DSSD），面向对象的分析方法（OOA）等。选择那种方法要根据哪些资源在什么时间对开发人员有效，不能盲目套用。这里着重阐述面向数据流的结构化分析方法（SA）。
面向数据流的结构化分析方法
面向数据流的结构化分析方法（Structured Analysis，简称SA），是面向数据流进行需求分析的方法，是需求分析使用最多的方法之一。 SA也是一种建模活动，该方法使用简单易读符号，根据软件内部数据传递、变换的关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。适用于数据处理类型软件的需求分析，这一方法除了简单，容易掌握之外，还能和设计阶段的结构化设计（SD）衔接，从而取得良好的设计结果。
自顶向下逐层分解的分析策略
SA方法的基本手段：“分解”和“抽象”。这是系统开发技术中控制复杂性的两种手段。它先将系统“抽象”成一个模型，此模型是有输入和输出并有系统名称的盒子，然后打开这个盒子，对它进行逐层分解，直到能被理解，可以实现为止。因此分析的策略是自顶向下，逐层加细，由抽象到具体的过程。如图2。
结构化分析方法使用工具
SA方法利用图形等半形式化的描述方式表达需求，简明易懂，用它们形成需求规格说明书中的主要部分。描述工具是
1) 数据流图：描述系统由哪几部分组成，各部分之间有什么联系等等。 2) 数据字典：定义了数据流图中每一个图形元素。
3) 描述加工逻辑的结构化语言、判定表、判定树：详细描述数据流图中不能被再分解的每一个加工。
由于分析中的主要依据是数据传递及数据变换所形成的数据流，所以结构化分析一般采用的方法是使用数据流图的分析方法，最终结果是产生需求规格说明书，该文档包括一套数据流图，对数据流图中的成分进行定义的一本数据字典及对加工逻辑的描述。
结构化分析步骤
用结构化分析方法进行系统需求分析的具体步骤是： 1) 了解当前系统的工作流程，获得当前系统的物理模型。通过对当前系统的详细调查，了解当前系统的工作过程，同时收集资料、文件、数据、报表等，将看到的、听到的、收集到的信息和情况用图形描述出来。也就是用一个模型来反映自己对当前系统的理解，如画系统流程图。
2) 抽象出当前系统的逻辑模型。物理模型反映了系统“怎么做”的具体实现，去掉物理模型中非本质的因素，抽取出本质的因素，构造出当前系统的逻辑模型，反映了当前系统“做什么”的功能。
3) 建立目标系统的逻辑模型。分析、比较目标系统与当前系统逻辑上的差别，明确目标系统到底要“做什么”，从而从当前系统的逻辑模型导出目标系统的逻辑模型。
4) 作进一步补充和优化。为了对目标系统做完整的描述，还需要对得到的逻辑模型做一些补充。
说明目标系统的人机界面。
说明至今尚未详细考虑的细节（包括出错处理、系统的启动与结束、系统的输入/输出和系统性能方面的需求等）。
其他（系统特有的其他必须满足的性能和限制，也需要用适当的形式做出书面记录。 分析阶段结束时，系统分析员必须和用户再次认真地审查系统文件，争取在系统开始设计之前，尽可能地发现其中存在的一些错误并及时纠正，直至用户确认这个模型表达了他们的要求后，系统文件（软件需求规格说明书等）才作为用户和软件开发人员之间的“合同”而最后得到确定。
结构化分析方法的优缺点
1) 优点： 结构化分析方法是软件需求分析中公认的、有成效的、技术成熟的、使用广泛的一种方法，它较适合于开发数据处理类型软件的需求分析，该方法利用图形等半形式化工具表达需求，简明易读，也易于使用，为后一阶段的设计、测试、评价提供了有利条件。 2) 缺点：① 传统的SA方法主要用于数据处理方面的问题，主要工具DFD体现了系统“做什么”的功能，但它仅是一个静态模型，没有反映处理的顺序，即控制流程。因此，不适合描述实时控制系统。② 上世纪60年代末出现的数据库技术，使许多大型数据处理系统中的数据都组织成数据库的形式，SA方法使用DFD在分析与描述“数据要求”方面是有局限的，DFD应与数据库技术中的实体联系图(ER图)结合起来(如同IDEF0功能模型与IDEF1信息模型相结合一样)。ER图能增加对数据存储的细节以及数据与数据之间，数据与处理过程之间关系的理解，还解决了在DD中所包含的数据内容表示问题，这样才能较完整的描述用户对系统的需求。③ 对于一些频繁的人机交互的软件系统，如飞机订票、银行管理等系统，用户最关系的是如何使用它，输入命令、操作方式、系统响应方式、输出格式等都是用户需求的重要方面，DFD不适合描述人机界面系统的需求，SA方法往往对这一部分用自然语言作补充。④ 描述软件需求的精确性有待提高。 5 需求的变更
在开发项目过程中，用户随时会提出一些新的需求，要求开发方解决，这些需求的提出，有时在开发阶段中有时在开发阶段后。这种在需求分析的两个相邻子阶段中，或者在迭代周期的需求分析中，后一段或周期的需求分析结果与前一次不一致，我们把这种不一致称为需求变更。产生需求变更的原因主要有以下几个方面：1) 在需求分析阶段，开发方与用户的沟通不够。在需求分析阶段，开发方与用户没有很好的交流，开发方就根据用户提供的大概信息，自己推导出用户的需求。通过这种需求分析得出的需求往往会和用户的实际需求相差甚远，导致用户提出更改需求。2) 项目的实施周期过长。随着时间的推移，用户对整个系统的了解也越来越深入。他们会对模块的界面、功能和性能方面提出更高更多的要求。3) 技术更新过快。由于技术的快速更新， 企业可能引进一些新的设备， 而这些设备可能就会与我们的目标系统有直接的关系， 由于这一变化可能发生在解决用户原先问题之前或者之中，那么开发方不得不加入这一新的需求。[3]
为了尽可能地避免发生需求变更，以及保证需求分析的高稳定性，可以采用以下方法：1) 分工明确，系统分析员和程序员各有不同的职责。系统分析员处在用户和程序员之间，沟通用户和开发人员的认识和见解。系统分析员一方面要协助用户对所开发的软件提出需求，另一方面还要和程序员充分交换意见，探讨其合理性和实现的可能性。如图3所示，系统分析员在需求分析阶段起着重要的作用。
2) 开发方与用户进行协作和交流。在用户提出需求变更时系统分析员应该认真听取用户的要求并加以整理和分析。分析需求变更的原因并提出可行的替代方案；同时向用户说明这些需求变更会对整个项目的开发带来的不良后果。3) 合同约束。由于需求变更可能会对整个项目产生影响，所以，开发方和用户在签定项目合同时，可以对需求变更增加一些相关的合同条款。4) 建立需求文档并进行版本控制。需求分析的最终成果是一份客户和开发方对所开发的产品达成共识的系统文档。有了这份文档， 即使开发方人员的角色有所变动，也不会对需求分析的前期工作有所影响。对每次的需求变更都用一个新的版本来标识。5) 需求评审和设立需求基线。为了让开发方详细了解用户的需求，让不同人员从不同的角度对需求进行验证，作为需求的提出者（用户方），在需求评审过程中，往往能提出许多有价值的意见，同时，也是对需求进行最后确认的机会，可以有效减少需求变更的发生。需求在通过正式评审和批准之后，应该确定需求基线，进一步的需求变更将在此基线的基础上，依照项目定义的变更过程进行。设置需求基线可以将变更引起的麻烦减至最小。

软件架构（software
architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系
统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向
对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。
软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。
在“软件构架简介”中，David Garlan 和 Mary Shaw
认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结
构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。
但构架不仅是结构；IEEE Working Group
on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注
重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
在Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管
理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑
和流程。
一般而言，软件系统的架构（Architecture）有两个要素：
它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。
所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和
联结器完成某一项需求。
建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
对于较大的通常应用应该使用框架，可能节省不少时间.。能使你很轻松的开发出一款软件来。
（软件开发一般比较会关注设计模式而不是架构设计）

2. 系统分析要回答系统应该怎么做的问题,这是对的吗

是错误的,

参见专属>http://ke..com/view/170100.htm

3. 企业在进行管理信息系统实施过程中的要点有哪些

管理信息系统是一个以人为主导，利用计算机硬件、软件、网络通信设备以及其他办公设备，进行信息的收集、传输、加工、储存、更新、拓展和维护的系统。管理信息由信息的采集、信息的传递、信息的储存、信息的加工、信息的维护和信息的使用六个方面组成。
完善的管理信息系统具有以下四个标准：确定的信息需求、信息的可采集与可加工、可以通过程序为管理人员提供信息、可以对信息进行管理。管理信息系统主要有以下几个功能：
1、数据处理功能；
2、计划功能；
3、控制功能；
4、预测功能；
5、 辅助决策功能
而企业进行管理信息系统，对企业有以下作用：
1、管理信息是企业重要的资源

对企业来说，人、物资、能源、资金、信息是5大重要资源。人、物资、能源、资金这些都是可见的有形资源，而信息是一种无形的资源。信息资源决定了如何更有效地利用物资资源。信息资源是人类与自然的斗争中得出的知识结晶，掌握了信息资源，就可以更好地利用有形资源，使有形资源发挥更好的效益。
2、 管理信息是企业决策的基础
决策是通过对客观情况、对客观外部情况、对企业外部情况、对企业内部情况的了解才能做出正确的判断和决策。所以，决策和信息有着非常密切的联系。过去一些凭经验或者拍脑袋的那种决策经常会造成决策的失误，越来越明确信息是决策性基础。
3、 管理信息是企业实施管理控制的依据
在管理控制中，以信息来控制整个的生产过程、服务过程的运作，也靠信息的反馈来不断地修正已有的计划，依靠信息来实施管理控制。有很多事情不能很好地控制，其根源是没有很好地掌握全面的信息。
4、管理信息是企业联系组织内外的纽带
企业跟外界的联系，企业内部各职能部门之间的联系也是通过信息互相沟通的。因此要沟通各部门的联系，使整个企业能够协调地工作就要依靠信息。所以，它是组织内外沟通的一个纽带，没有信息就不可能很好地沟通内外的联系和步调一致地协同工作。
企业在进行管理信息系统实施过程中的要点包括：
1、规划阶段
系统规划阶段的任务是：在对原系统进行初步调查的基础上提出开发新系统的要求，根据需要和可能，给出新系统的总体方案，并对这些方案进行可行性分析，产生系统开发计划和可行性研究报告两份文档。

2、分析阶段
系统分析阶段，也被成为逻辑设计阶段。这个阶段的任务是根据系统开发计划所确定的范围，对现行系统进行详细调查，描述现行系统的业务流程，指出现行系统的局限性和不足之处，确定新系统的基本目标和逻辑模型。
系统分析阶段的工作成果体现在“系统分析说明书”中，这是系统建设的必备文件。它是提交给用户的文档，也是下一阶段的工作依据，因此，系统分析说明书要通俗易懂，用户通过它可以了解新系统的功能，判断是否所需的系统。系统分析说明书一旦评审通过，就是系统设计的依据，也是系统最终验收的依据。

3、设计阶段
系统分析阶段回答了新系统“做什么”的问题，而系统设计阶段的任务就是回答“怎么做”的问题，即根据系统分析说明书中规定的功能要求，考虑实际条件，具体设计实现逻辑模型的技术方案，也即设计新系统的物理模型。所以这个阶段又称为物理设计阶段。它又分为总体设计和详细设计两个阶段，产生的技术文档是“系统设计说明书”。

4、实施阶段
系统实施阶段的任务包括计算机等硬件设备的购置、安装和调试，应用程序的编制和调试，人员培训，数据文件转换，系统调试与转换等。系统实施是按实施计划分阶段完成的，每个阶段应写出“实施进度报告”。系统测试之后写出“系统测试报告”。

5、维护与评价
系统投入运行后，需要经常进行维护，记录系统运行情况，根据一定的程序对系统进行必要的修改，评价系统的工作质量和经济效益。

4. 系统分析的任务是什么 如何进行系统分析

任务是：在充分认识原信息系统的基础上，通过问题识别、可行性分析、详细调查、系统化分析，最终完成新系统的逻辑方案设计，或称逻辑模型设计。逻辑方案不同于物理方案，前者解决“做什么”的问题，是系统分析的任务；后者解决“怎么做”的问题，是系统设计的任务。 没有系统分析的内容，只有系统化分析的主要内容。可能不太一样，系统化分析是系统分析的一个步骤呢。 如果硬要讲内容,也许就是问题识别、可行性分析、详细调查、系统化分析、逻辑模型设计吧 系统分析方法是指把要解决的问题作为一个系统，对系统要素进行综合分析，找出解决问题的可行方案的咨询方法。兰德公司认为，系统分析是一种研究方略，它能在不确定的情况下，确定问题的本质和起因，明确咨询目标，找出各种可行方案，并通过一定标准对这些方案进行比较，帮助决策者在复杂的问题和环境中作出科学抉择。 系统分析方法来源于系统科学。系统科学是20世纪40年代以后迅速发展起来的一个横跨各个学科的新的科学部门，它从系统的着眼点或角度去考察和研究整个客观世界，为人类认识和改造世界提供了科学的理论和方法。它的产生和发展标标志着人类的科学思维由主要以“实物为中心”逐渐过渡到以“系统为中心”，是科学思维的一个划时代突破。 系统分析是咨询研究的最基本的方法，我们可以把一个复杂的咨询项目看成为系统工程，通过系统目标分析、系统要素分析、系统环境分析、系统资源分析和系统管理分析，可以准确地诊断问题，深刻地揭示问题起因，有效地提出解决方案和满足客户的需求。 系统分析的主要任务是将在系统详细调查中所得到的文档资料集中到一起，对组织内部整体管理状况和信息处理过程进行分析。它侧重于从业务全过程的角度进行分析。分析的主要内容是：业务和数据的流程是否通畅,是否合理；数据、业务过程和实现管理功能之间的关系；老系统管理模式改革和新系统管理方法的实现是否具有可行性等等。系统分析的目的是将用户的需求及其解决方法确定下来，这些需要确定的结果包括：开发者关于现有组织管理状况的了解；用户对信息系统功能的需求;数据和业务流程;管理功能和管理数据指标体系;新系统拟改动和新增的管理模型等等。系统分析所确定的内容是今后系统设计、系统实现的基础。

5. 企业在什么情况下要进行系统的工作分析，明确岗位职责

企业在组织架构发生变化、岗位部门名称发生变化、部门的隶属关系发生变化、主要职能变内动、企业容刚刚成立的时候要进行系统的工作分析，明确岗位职责。

工作分析以便确定每一项工作的6w1h：用谁做（Who）、做什么（what）、何时做（When）、在哪里做（Where）、如何做（How）、为什么做（Why）、为谁做（Whom）。分析的结果或直接成果成为岗位说明书。

(5)在进行系统分析时要注意的结合是扩展阅读：

工作分析类型

1、岗位导向型是指从岗位工作任务调查入手进行的工作分析活动。（以岗位为核心，韦伯官僚层次理论）

2、人员导向型是指从人员工作行为调查入手进行的工作分析活动。（以员工为核心，前提条件人岗匹配，员工绩效良好）

3、过程导向型从产品或服务的生产环节调查入手进行的工作分析活动。（以生产过程为核心，流程的科学性）

6. 如果要做系统分析员要学习什么知识

基本功
好的系统分析员都是从优秀的程序员中产生的，坚实的编程功底、丰富的经验是今后做系统分析的基础。
其实在大学的时候我们就应该夯打基础，现在工作之才深深的感到，所以读研期间就恶补基础的东西。
没有对系统本身进行过透彻剖析过，很难领会到其中一些难以言述的精华。但并不等于好的程序员就能够成为好的系统分析员。
合理的知识结构。语言能力、文字表达能力、技术的全面性等是对系统分析员的基本要求。比如说c/s和3 层开发，如果仅仅对Netscape公司的产品熟悉还不够，还需要了解比如微软等产品，并且要了解他们中产生历史，发展思路，技术优劣，以应付各种穷追猛打的提问。但更重要的是，这是你为应用定制技术要求的前提。

思想
全局观念是系统分析员必须具备的观念。如果系统分析员设计时太注重细节，往往会陷入在某个问题上纠缠不清的泥潭，系统分析员要有面向用户的思想。系统分析员应当有能力将自己扮演成用户，来了解要交付的项目看起来想什么样式，感觉想什么，从而了解用户的想法并挑选出合理部份去开发。从这个意义上说，系统分析员才能获得有意义的见解去引导他的开发组成员。系统分析员头脑中要对项目结局有一个清楚的认识，并保证项目不偏离方向。系统分析员要有根植于技术，高于技术思考问题的思想。纯粹的程序员通常对最终结果考虑的不是很多，当一种新的技术在市场上出现时，他们对能否按时交付的考虑就比较少，而强烈希望他们的计划能够建立在新的技术之上。因此，系统分析员的想法和行动要像一个用户，又要能够站在技术的高度，成为真正的用户、程序员之间的代言人。

任务难度的预测能力
系统分析员要具备快速的任务难度预测能力以及具备快速确定开发小组人员构成和任务划分的能力。昆虫自然会长出翅膀，而思想却需要长期的浸润。要做到这点，需要大量的思考、学习。设计远比编程重要。当今软件业的发展，各种开发工具的出现，编程已经不是什么问题，程序员的工作某种程度上讲是将别人现成的东西拼凑堆砌起来。系统分析员要清楚的认识到，现在大多数程序员没有学会怎么去整体的了解一个系统，有些甚至不了解编程（这不是说他们不会写代码）。可视化的开发工具加五花八门的控件，程序员可以偷点懒了，基于技术，跳出框架。基于现有技术结合用户需求思考问题，设计时跳出框架。

关键
获得信任。系统分析员最重要的素质是获得信任，这是成为优秀系统分析员的关键。成熟最为关键。成熟可以为整个项目组提供正确的支持,能够理解技术怎样才能解决用户的需求。

准备工作
统一的各种文档模式，这其中包括今后软件变量、字段命名规则。我推荐用 Java 制定的规则做基础，通过改造成为适合自身实用的标准。统一的文档管理。统一的分析软件。比如说rose（UML太规范，国内的软件管理水平根本用不上，只不过尽量应用，你自己对系统分析的理解有好处）方法是思想的放映.
我在拙作"在中国没有人懂计算机"里发了点牢骚，听说挨了部分人（习惯性的）骂。其实，bbs本来就是发泄的地方，在这里从来就罕有有内容的文章。
自从"维纳斯"登陆深圳后，大家更着眼于从宏观看中国的IT业了。中国IT这棵小树，说实在的，长到今天实在是不容易。一些人提出了"反对微软霸权"的口号，不少人呼唤中国"硅谷"的出现。微软的成功不是技术的成功，更多的是商业运作的成功。中国IT这棵树能长多高，取决于他所植根于的土壤。而现在的事实是，这片土壤实在是太贫瘠了！如果按我们现在的思路和搞法，是长不成大树，更别指望能结出像“微软”、“硅谷”这样丰硕的果实。如果说，我们的软件技术落后美国十年，我们的硬件制造技术则落后美国二十年，我们的管理水平落后美国至少三十年。而最终决定发展速率的恰恰是我们的死穴---低劣的管理水平。低劣的管理水平的形成的原因有着深厚的背景和多方面的原因。

系统分析工作是解决一个问题的工作,目标是将一个对计算机应用系统的需求转化成实际的物理实现,其中复杂就复杂在实际的面太多。在系统分析过程之中注意问以下的问题,可能会所进行的系统分析设计工作有帮助。
(1)您所完成的系统目的是什么?注意不是功能要求,而是目的.也就是为什么要建设、为什么要现在建设。在考虑系统目的时，我更多的侧重于系统的最终目标考虑，因为一个系统不可能一下子完美，为系统留些余地。
(2)您所完成的系统有哪些方面参与，各方面的初衷是什么？那些人可能在系统建设中起重要作用，他们会采取什么样的态度？你对他们有多少影响力？中国IT行业的失败之一就是人"太年轻"，一定要有领导的支持，否则完蛋。不要认为自己对他们会有多少影响力，即便有，也要尽可能的认为是决策者再影响他们。在中国，一个技术员，你算老几？说到这里我很悲哀。哪些人在系统中起重要作用并弄清楚他们的态度，这点十分关键。
(3)您的系统是否有一个明确的评价标准？最好从参与的各方面都进行考虑。不知道这样说对不对，在系统建设之前，对你的程序员、对你的领导要有至少不同的两种评价。
(4)你的系统设计思想是什么？是否能够得到各方面的认可。如果高明，对领导、对程序员都采用引导，得到认可的最好办法，就是让他们认可他们自己的想法。
(5)你对参与系统设计开发的人员了解吗？他们的特长在哪里，是否愿意与你合作，为什么？你对他们有足够的影响力吗？软件发展到一定的程度，不是编程，不是数学，而是管理。
(6)你的系统开发计划是否完善？你的计划表有明确的阶段吗？任何一阶段都应该怎样完成？如何对这一阶段完成的情况进行评价？
(7)你对所采用的系统开发方法以及工具是否熟悉？你的夥伴是否熟悉？事实上，不是每种好的工具都要使用，也并不一定都要他们熟练掌握。提醒诸位一句，当你将方案做得可以不依赖某个程序员，你在程序员面前就无信任可言，因为从此程序员将受到更大的生存压力。我坚决不在公司使用rose。
(8)你所完成的系统是否有原型？计算机的或者物理的。
以上的几个问题都是在系统分析以及系统规划时涉及到的，供各位参考。

7. 在系统分析阶段，做系统详细调查前为什么要先对用户进行培训求解，

因为系统分析的难点之一就是用户与设计者的沟通，用户了解原系统的使用，系统设计者则关心实现系统。培训一方面让用户理解设计者关心的事，一方面理解设计者调查的方式和手段

8. 在进行系统分析时,应特别注意抓住管理系统的几个主要特性

在进行系统分析时，应特别注意抓住管理系统的三个主要特性。

9. 在进行系统聚类分析时，不同的类间距离计算方法有何区别

聚类分析有两种主要计算方法，分别是凝聚层次聚类（Agglomerative hierarchical method）和K均值聚类（K-Means）。
一、层次聚类
层次聚类又称为系统聚类，首先要定义样本之间的距离关系，距离较近的归为一类，较远的则属于不同的类。可用于定义“距离”的统计量包括了欧氏距离 (euclidean)、马氏距离(manhattan)、 两项距离(binary)、明氏距离(minkowski)。还包括相关系数和夹角余弦。
层次聚类首先将每个样本单独作为一类，然后将不同类之间距离最近的进行合并，合并后重新计算类间距离。这个过程一直持续到将所有样本归为一类为止。在计算类间距离时则有六种不同的方法，分别是最短距离法、最长距离法、类平均法、重心法、中间距离法、离差平方和法。
下面我们用iris数据集来进行聚类分析，在R语言中所用到的函数为hclust。首先提取iris数据中的4个数值变量，然后计算其欧氏距离矩阵。然后将矩阵绘制热图，从图中可以看到颜色越深表示样本间距离越近，大致上可以区分出三到四个区块，其样本之间比较接近。
data=iris[,-5]
dist.e=dist(data,method='euclidean')
heatmap(as.matrix(dist.e),labRow = F, labCol = F)
X
然后使用hclust函数建立聚类模型，结果存在model1变量中，其中ward参数是将类间距离计算方法设置为离差平方和法。使用plot(model1)可以绘制出聚类树图。如果我们希望将类别设为3类，可以使用cutree函数提取每个样本所属的类别。
model1=hclust(dist.e,method='ward')
result=cutree(model1,k=3) 为了显示聚类的效果，我们可以结合多维标度和聚类的结果。先将数据用MDS进行降维，然后以不同的的形状表示原本的分类，用不同的颜色来表示聚类的结果。可以看到setose品种聚类很成功，但有一些virginica品种的花被错误和virginica品种聚类到一起。

10. 9如何进行系统分析

系统分析阶段的任务很多，本课程设计仅要求大家完成几个重要环节的工 版作，主要有绘制系统功能结构权图和业务流程图等。该阶段结束后要提交系统需求 分析说明说。具体内容如下： 需求分析说明书 1 、系统功能结构图（ HIPO 图） （在该功能结构图中选一个子系统进行逐层分解） 2 、系统功能说明 （对以上选中的子系统进行功能描述） 3 、现有系统的业务流程图及说明 （对以上选中的子系统绘制手工系统或旧的计算机系统的业务流程图并进行简 单的功能说明） 4 、新系统的业务流程图及说明 （对以上选中的子系统绘制计算机系统下的业务流程图（重组后的）并进行简单的功能说明）