GIS开发及应用

2.3 定义需求
1、 系统功能要求 应该划分出系统必须完成的所有功能。
2、 系统性能要求 例如，联机系统的响应时间（即对于从终端输入的一个“事务”，系 统在多长时间之内可以做出响应），系统需要的存储容量以及后援存 储，重新启动和安全性等方面的考虑都属于性能要还应。
3、 运行要求 这类要求集中表现为对系统运行时所处环境的要求。例如支持系统运 行的系统软件是什么，采用哪种数据库管理系统，需要什么样的外存 储器和数据通信接口等。
8. 技术力量与支持 9. 软硬件价格与性能 10. 数据源状况 11. 应用前景 12. 效益评估 13. 可运行性评价
立项申请一般要附可行性研究报告
1． 可行性研究的目的和任务
1）可行性研究的目的： 用最小的代价在尽可能短的时间内确定问题是否能
够解决。可行性研究的目的不是解决问题，而是确定 问题是否值得解决。 2）可行性研究的任务： 确认问题定义→导出系统的逻辑模型→探索几种系统 实现的方案→研究每种方案的可行性
4、成本/效益分析
直接效益 服务（内容、质量） 节省开支 提高工作效率
间接效益 科学决策 快速决策
5、成本估计
1） 用户成本估计 2） 系统开发成本估计（任务分解技术）
首先把软件开发工程分解为若干个相对独立的任务， 估计每个任务的成本时，通常先估计完成该任务需要 用的人力（以人月为单位），再乘以每人每月的平均 工资而得出每个任务的成本。
4.2 输入输出设计
数据输入的格式、类型、形式、校验等 数据输出的内容、形式（报表、专题图）
4.3 数据库设计
1．属性数据库 表、查询、索引、视图、报表（第三范式）
一般说来，可行性研究的成本只是预期工程总成本的 5%-10%。
2、可行性研究包含的内容：
1) 技术可行性： 分析使用现有的技术能否实现系统，能否解决系统的技术难点，系 统对技术人员有什么要求，硬件能否适应系统要求，系统开发是否 与现行系统有运行矛盾。
2) 开发的风险： 在现有条件限制范围内，能否设计出系统，实现必须的功能，达到 要求的性能。 资源： 开发人员的水平，硬件、软件、数据。 技术：相关技术的发展能否支持系统 。
这个阶段的任务仍然不是具体地解决问题，而是准 确地确定“为了解决这个问题，目标系统必须做什 么”，主要是确定目标系统必须具备哪些功能。
系统分析员在需求分析阶段必须和用户密切配 合，充分交流信息，以得出经过用户确认的系统 逻辑模型。通常用数据流图、数据字典和简要的 算法表示系统的逻辑模型。
在需求分析阶段系统分析员将仔细研究这些功 能并进一步将它们具体化。在这个阶段结束时交 出的文档中应该包括详细的数据流图。数据字典 和一组简明的算法描述。
3．系统维护设计 说明为了系统维护的方便而在程序内部设计中作出的安排，包括在程序 中专门安排用于系统的检查与维护的检测点和专用模块。
四、详细设计
4.1 详细设计的内容
1）模块设计 2）代码设计 3）数据库设计 4）数据获取方案设计 5）界面设计 6）输入输出设计 7）程序模块设计 8）安全性设计 9）实施方案设计
3、可行性研究的步骤
1）审查系统的规模和目标 2）研究目前正在使用的系统
研究原有系统的功能。 研究原有系统存在的缺点。 分析原系统的文档资料和使用手册。 描绘原系统的高层系统流程图。
（注意：了解原有系统能做什么，而不是了解它怎样 做。）
3）导出新系统的高层逻辑模型
从原有系统物理模型，导出新系统的逻辑模型。 画出系统流程图和数据流图。定义系统中使用 的数据，一般用数据字典表示。
4）做出可行性分析
进行成本效益分析，技术可行性分析，社会可 行性分析，论证可开发的理由。
成本/效益分析的目的：从经济的角度分析
开发一个特定的新系统是否合算，来帮助使用 部门正确作出是否投资这项开发工程的决定。
5）找出可实施方案
画出推荐系统目标逻辑模型
6）写可行性报告。（阶段性成果）
可行性报告提纲参见软件设计文档国家标准——可行性研究报
3．数据结构与程序的关系 说明各个数据结构与访问这些数据结构的形式。
3.5 编码设计
编码设计的原则： 唯一性 合理性 可扩充性 简单性 实用性 规范性 系统性
3.6 界面设计
美观 整洁 简单 易用
3.7 系统出错处理设计
1．出错信息 用一览表的方式说明每种可能的出错或故障情况出现时，系统输出信息 的形式、含意及处理方法。
2．外部接口 说明本系统同外界的所有接口的安排包括软件 与硬件之间的接口、本系统与各支持软件之间 的接口关系。
3．内部接口 说明本系统之内的各个系统元素之间的接口的 安排。
3.3运行设计
1．运行模块组合 说明对系统施加不同的外界运行控制时所引起的 各种不同的运行模块组合，说明每种运行所历 经的内部模块和支持软件。
10. 是否考虑过软件需求的其它方案; 11. 是否考虑过将来可能会提出的软件需求; 12. 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认
2.6 需求分析报告
需求分析的最终结果是形成需求分析报告 这里要说明是： 很多情况下需求分析报告也叫系统（软件）规 格说明书，它一般作为项目合同的附件，是合 同成立的基础，也是项目验收的依据，具有一 定的法律效力，因此在书写是一定要慎重。表 达必须准确、清晰，不能含糊不清，为以后带 来不必要的麻烦。
三、总体设计
3.1 总体设计的内容
1. 确定系统的目标与属性 2. 进行各子系统或模块的划分与功能描述 3. 模块或子系统间的接口设计 4. 软硬件配置设计 5. 网络设计 6. 输入输出与数据存贮要求 7. 开发策略规定 8. 成本与收益分析
3.2 接口设计
1．用户接口 说明将向用户提供的命令和它们的语法结构， 以及软件的回答信息。
2．运行控制 说明每一种外界运行控制的方式方法和操作步骤
3．运行时间 说明每种运行模块组合将占用各种资源的时间
3.4 系统数据结构设计
1．逻辑结构设计要点 给出本系统内所使用的每个数据结构的名称、标识符 以及它们之中每个数据wenku.baidu.com、记录、的标识、定义、长 度及它们之间的层次的或表格的相互关系。
2．物理结构设计要点 给出本系统内所使用的每个数据结构中的每个数据项 的存储要求，访问方法、存取单位、存取的物理关系 （索引、设备、存储区域）、设计考虑和保密条件。
2.3 软件需求规格说明
规格说明必须包括系统运行环境 规格说明必须是一个认识模型 规格说明必须是可操作的 规格说明必须容许不完备性并允许扩充 规格说明必须局部化和松散耦合
2.4开发原型系统
开发原型系统通常有两个主要目的： 检验关键设计方案的正确性 系统是否真正满足用户的需要。
建立原型系统原因： 1） 由于人类认识能力的局取胜，不能预先指定所有要求； 2） 在用户和系统分析员之间存在固有的认识鸿沟； 3） 用户需要一个“活的”系统模型，以便获得实践经验； 4） 在开发过程中重复和反复是必要的和不可避免的； 5） 目前有快速建立原型系统的工具可供选用。（UML）
2．补救措施 说明故障出现后可能采取的变通措施，包括： 1）后备技术说明准备采用的后备技术，当原始系统数据万一丢失时启 用的副本的建立和启动的技术，例如周期性地把磁盘信息记录到磁带上 去就是对于磁盘媒体的一种后备技术； 2）降效技术说明准备采用的后备技术，使用另一个效率稍低的系统或 方法来求得所需结果的某些部分，例如一个自动系统的降效技术可以是 手工操作和数据的人工记录； 3）恢复及再启动技术说明将使用的恢复再启动技术，使软件从故障点 恢复执行或使软件从头开始重新运行的方法。
GIS应用开发
参考教材
地理信息系统软件工程的原理与方法（毕硕本，王桥等） 科学出版社，2003.7，52 元 软件工程的书，随便哪个版本。 用MapX开发地理信息系统（齐锐），清华大学出版社， 2003.11，28元 Visual C++开发GIS系统，陈建春，电子工业出版社， 72元 地理信息系统设计与实现（吴信才） 设备设施管理地理信息系统，张书亮、闾国年 等编著， 科学出版社，2006.6，36 元（推荐定购） 地理信息系统（GIS）开发工程案例精选，王占全，赵 斯思等 ，人民邮电出版社 ，2005.10 ，78元
4、 将来可能提出的要求 应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来 很可能会提出来的要求。
功能需求、性能需求、环境需求、可靠性需求、安全保密要求、 用户界面需求、资源使用需求、成本消耗需求、开发进度需求 是主要考虑因素。
2.4 分析系统的数据要求
复杂的数据由许多基本的数据元素组成，数据结构 表示数据元素之间的逻辑关系。利用数据字典可以 全面准确地定义数据，但是数据字典的缺点是不够 形象直观。为了提高可理解性，常常利用图形、表 等辅助工具描绘数据结构。 GIS应用项目，对图形数据的要求较高，定义需求 时一定弄清楚用户能提供什么样的数据，还需要那 些数据，如何获取和加工。
告（GB8567——88），基本内容包括：引言、可行性研究的
前提
、对现有系统的分析、所建议的系统、可选择的其
他系统方案、投资及效益分析、社会因素方面的可行性、结论
等。
7）文档提交审查
将可行性研究写成文档，请用户和使用部门审查，以决定是否
接受推荐的方案。
可行性分析的结果是形成可行性研究报告，最终形成 的可行性研究报告提纲如下表所示：
GIS应用工程设计的基本内容
一、可行性分析 二、需求分析 三、总体设计 四、详细设计 五、系统开发与实施（编码） 六、系统测试 七、系统运行、维护与评价
一、可行性分析
1. 立项原因 2. 立项基础 3. 国内外研究现状 4. 工程轮廓与目标 5. 需求调查（宏观的） 6. 投资环境 7. 投资周期
可行性研究阶段产生的文档，特别是数据流图， 是需求分析的出发点。数据流图中已经划分出系 统必须完成的许多基本功能，
2.2、需求分析过程
1) 结构化分析方法（简称SA方法） 就是面向数据流自顶向下逐步求精进行需求分析的 方法。通过可行性研究已经得出了目标系统的高层 数据流图，需求分析的目的之一就是把数据流和数 据存储定义到元素级。
2.5 需求分析评审 （特别重要）
1. 系统定义的目标是否与用户的要求一致; 2. 系统需求分析阶段提供的文档资料是否齐全; 3. 文档中的所有描述是否完整、清晰、准确反映用户要求; 4. 与所有其它系统成分的重要接口是否都已经描述;
5. 被开发项目的数据流与数据结构是否足够，确定; 6. 所有图表是否清楚，在不补充说明时能否理解; 7. 主要功能是否已包括在规定的软件范围之内，是否都已充分说明; 8. 设计的约束条件或限制条件是否符合实际; 9. 开发的技术风险是什么;
3） 经济可行性：（成本 / 效益分析） 估算系统的经济效益能否超过它的开发成本。开发成本包括人员、 软硬支持所需费用。包括：经费概算，预期的经济效益，公司经营 策略，市场前景等。
4） 操作可行性： 系统的操作方式在这个用户组织内是否行得通。（用户单位的行政 管理，工作制度，使用人员的素质。 ）
5) 社会可行性： 分析开发系统是否符合当前法律和社会生产管理经营体制要求，有 无涉及到版权纠纷等，包括：违法、侵权、合同、责任、版权等。
最常用的办法是按开发阶段划分任务。如果软件系统 很复杂，由若干个子系统组成，则可以把每个子系统 再按开发阶段进一步划分成更小的任务。
典型环境下各个开发阶段需要使用的人力的百分比大 致如表所示。
二、需求分析
2.1.需求分析的任务
基本任务是准确地回答“系统必须做什么？”这个 问题。主要包括：
1。深入描述软件的功能和性能 2。确定系统设计的约束和与其它系统元素的接口细节 3。定义系统的其它有效性需求
2)定义需求 3)用户审查 4)细化数据流图 5)开发系统原型 6)书写需求分析报告 7)需求分析报告审查（用户和项目组）
数据流图(DFD,Data Flow Diagram)
数据流程图是用符号化方法进行系统分析的工具， 用于描述数据流动、数据存储、数据处理的逻辑关 系。
数据字典
数据字典是描述各类数据的集合和标准规范，通常 由数据元素、数据结构、数据流、数据存储和处理 过程组成。