系统规划主要记录从项目提出、选择到确立的过程。包括系统项目的提出与可行性分析，系统方案的制定、评价和改进，新旧系统的分析和比较，以及现有软件、硬件和数据资源的有效利用等问题。

一、项目的提出与选择

根据项目的动机确定系统的范围及方案选择。

1、系统的立项目标和动机

项目立项的动机包括

1
2
3
4

进行基础研究并获取技术：大学、企业、研究所等科研类
进行应用研发并获得产品：产品研发，卖产品获利
提供技术服务：卖服务获利
信息技术产品的使用者：买软件或者产品使用

2、项目选择和确定

项目选择的目的可能有两种。
1是软件开发公司在诸多产品方向中选择格式的方向研究和开发。
2是客户从诸多的产品中购买适合自己的产品或方案。

（1）选择有核心价值的产品/项目或开发方向

关键在于确定什么样的系统项目是有价值的。价值通常与核心业务有关系，立项单位所在的行业或上下游位置不同，价值判断也不同。

（2）评估项目风险、收益和代价

1、对于开发产品进行销售
主要评估产品期望收益和开发投入的时间、资金、人力等资源。项目的风险主要是技术难度、技术能力、经济能力、开发进度、法律风险、政策风险。
2、对于购买产品或技术服务
需要评估项目实施后的变更情况，组织机构和人员职责的影响，现有流程和人员能否满足要去，规章制度是否满足要求等。

（3）评估项目的多种实施方式

（4）平衡地选择合适的方案

1、新技术与就技术

1
2

新技术意味着风险、学习和导入期。
旧技术享受不了新技术的好处。

2、快速开发平台

1
2

基于某平台的产品会让用户绑定在该平台上，减少未来自主选择性。
不基于某平台可能会延长项目开发时间，从而导致更多开销。

3、系统扩展性

1
2

不考虑系统扩展性很可能在业务变更时受阻。
过多考虑系统扩展性会花费大量时间进行设计。在IT发展迅速的今天，很有可能在有升级的时候，原来的技术体系已被淘汰。

4、抛弃明显存在问题的“差”项目，选择基本立场“合适”的项目，而不是尽可能的“好”。

1
2
3
4
5
6

要求质量是客户认为产品应该具备的功能或性能，实现越多客户越满意。
假想质量是客户想当然认为产品应具备的功能或性能，客户不能正确描述自己想当然要得到的这些功能或性能需求。
兴奋质量是客户要求范围外的功能或性能，通常是开发者很愿意增加的技术特性，实现这些客户会更高兴，但是不识闲也不影响其购买。

系统设计师常犯的错误是用自己对技术产生的兴奋质量，替换客户最基本的要求质量或假想质量。
企业经营者场贩的错误可能是对客户提出的合理要求质量视而不见，或者不加区分的把未经评估的假想质量指派给开发团队。

2、项目提出和选择的结果

项目提出和选择的结果最终会以“产品/项目建议书”的方式体现。典型的应用场景是：

1
2

在投标项目中，建议书通常是乙方提交给甲方竞标方案的一部分。
在企业确立要开发某产品后，对该产品进行多角度评估，最终项目立项人向上级提交建议书进行决策。

产品/项目建议书包括以下几部分：

1
2
3
4
5
6
7
8
9
10
11
12
13

用户单位、项目或产品的立项背景、需求来源和目标性的介绍；
用户的内外部环境、组织机构、现有的IT设施情况等；
用户的业务模型和业务规划；
预期要建设的技术系统在用户业务中的位置和作用；
信息化后的用户业务模型、软件应用方式、相关的部署环境、运行规划、管理规范等；
为实现信息化业务模型，技术系统的产品需求鼎业（功能、性能、约束）和部署方式等；
产品或项目的技术框架；
项目的要点、技术难点、主要实施障碍等。
项目或产品的可行性研究结果；
项目可选择的试试方式、组织方式、沟通和协调机制等；
项目的资源范围和规划，人、财、物、时间等；
项目的成本、收益分析；
......

其他项目建议书可能包含的内容或已单独文档列举的内容包括：

1
2
3
4
5
6
7
8

项目风险及影响评估
项目进度计划
项目质量计划
项目过渡期资金的获得方式、财务计划
产品或项目的商务模式、盈利模式论述
同类产品或公司的市场调查结果，以及竞争性比较
企业成功案例、资质等
商务条款或供应商、客户合同。

项目建议书标志着项目立项和选择阶段性工作的完成，一旦项目建议书被批准通过，项目可进入正式的开发准备和实施阶段。

主要完成的工作是解析“系统如何实现”的问题。
主要包括一下几个方面。

1、确定软件架构

1、分析模型的结构。
2、对应于系统目标的最基本。最重要的实现要素。
3、特性和要点的解释。

2、确定实现的各种关键性要素

1、关键的用例、主要的控制类、功能和服务的首要组织方式
2、对象的组织模式
3、常用和最关键的实现算法模型。
4.选定开发工具和开发环境

3、归结目标到最适合的计算体系

1、表示层：用户的界面部分
2、事务逻辑层：负责处理表示层的应用请求，完成商务逻辑的计算任务并肩结果返回用户。
3、数据服务层：为应用提供数据来源。

可行性研究的范围包括技术、经济、执行、环境等方面。虽然可行性研究不能给出详细的计划和方向，但是可以以最小的成本识别出错误构思的系统，从而避免更大的损失。

一、可行性研究的内容

可行性研究包括经济可行性、技术可行性、法律可行性、执行可行性、方案的选择等5个方面。

经济可行性

评估项目的开发成本及项目成功后可能获得的经济收益。

技术可行性

评估对于假想的软件系统需要实现的功能和性能，以及技术能力约束。可通过“提问-回答”的方式进行论证。
投资不足、时间不足、技术难度过大、没有足够的技术积累、没有熟练的员工、没有足够的合作公司、晚报资源不足等都是技术可行性的约束。

法律可行性

评估可能有系统开发引起的侵权或法律责任。
可能包括过年政策和法律的限制，合同的订立和条款，职责、侵权情况的设定，违约、争议的解决等。

执行可行性

评估与其的软件系统在真实的环境中能够被应用的程度和实施过程中的障碍。

方案的选择

评估系统或者产品开发的可选方法，可以采用折中的方法，反复比较各个方案的成本和效益，选择可行的方案。

二、成本效益分析

对项目开发目标的成本及可度量的项目现金收入和无形收益进行一次转化的评估。

项目可能涉及的成本

基础建设支出
一次性支出
运行维护费用

项目可能涉及的利益

一次性收益
非一次性收益
不可定量的收益

效益分析的若干指标和进一步的分析

收益/投资比
投资回收周期
敏感性分析

三、可行性分析报告

国标 GB 8567-1988 中定义了可行性分析报告的格式和内容。

1
2
3
4
5
6
7
8
9

项目背景：包括问题描述、实现环境和限制条件
管理概要和建议：包括重要的研究成果、说明、建议和影响
候选方案：包括候选系统的配置和最终方案的选择标准
系统描述：包括系统工作范围的简要说明和被分配系统元素的可行性
经济可行性：包括经费概算和与其的经济效益
技术可行性：包括技术实力、已有工作基础和设备条件
法律可行性：包括系统开发可能导致的侵权，违法和责任等
用户使用可行性：包括用户单位的行政管理，工作制度和使用人员的素质
其他与项目有关的问题：例如其他方案接收和未来可能的变化

遗留系统的特点：

1
2
3
4

系统虽然能完成很多重要的业务工作，但是已经不能外圈满足要求。
系统在性能上已经落后，或者采用的技术已经过时。
通常是大型的系统，已经融入业务工作中，维护工作十分困难。
系统没有使用现代系统工程方法进行管理和开发，基本没有文档，很难理解。

对于遗留系统，可以根据系统的技术条件、商业价值及维护和运行系统的组织特征不同，采取继续维护、重构或替代、或联合使用几种策略。

一、遗留系统的评价方法

1、启动评价
评价是为了对遗留系统足够的理解。评价前需要了解以下问题：

1
2
3
4
5
6
7
8

对企业来说，遗留系统是否至关重要
企业的商业目标是什么
演化需求是什么
所期望的系统寿命多长
系统的使用期限多久
系统的技术状态如何
企业是否愿意改变
企业是否有能力承受演化

2、商业价值评价
判断遗留系统对企业的重要性。可以包括概要和详细两个级别，概要评价包括：

1
2
3

咨询
评价问卷
进行评价

详细评价包括应用系统不符合业务规范的风险分析，该分析十分费时，最好由业务分析师来完成。
3、外部环境评价
外部环境评价系统的外部技术环境，是硬件、支撑软件和其他基础设施的统一体。

1
2
3
4
5
6
7
8

硬件
    系统一些常见特征有供应商、维护费用、市销率、年龄、功能、性能等。
    具体评价方法是对每一个部件或整个系统的每个特征打分（1-4），求总分。
支撑软件
    支撑软件可包括操作系统、数据库、事务处理程序、编译器、网络软件、应用软件等。
    评价方式同硬件。
企业基础设施
    需要考虑企业和使用者的类型、开发组织的技术成熟度、企业的培训过程、系统支持人员的技术水平、企业是否愿意改变。

4、应用软件评价

1
2
3

系统级，整个系统看作不可分的原子。
部件级，关注系统的每个子系统，考虑子系统的特征，包括复杂性、数据、文档、外部依赖型、合法性、维护记录、大小、安全性等。
评价方式同硬件。

5、分析评价结果
加权平均值。

二、遗留系统的演化策略

1、淘汰策略
第3象限低水平、低价值区，淘汰，全面开发新的系统替代遗留系统。
一般在业务发生根本变化，或维护人员、维护资料全部丢失了。经过评价，重新开发比改造旧系统更划算。
2、继承策略
第4象限低水平、高价值区，遗留，在开发系统时需要完全兼容遗留系统的功能模型和数据模型，新老系统同时运行，逐渐切换到新系统。
3、改造策略
第1象限高水平、高价值区，改造，这种系统通常建成时间段。其他功能不变，增加新功能。
4、集成策略
第2象限高水平、低价值区，集成，这种系统可能只完成某部门或子公司的业务，从整体看，他们基于不同的平台，不同的数据模型，无法互联互通，数据还不一致，属于较严重的问题。

1970年 Boehm定义的软件生命周期模型

《GB 8566-1988计算机软件开发规范》定义的软件生命周期模型

《GB/T 8566-1995 信息技术-软件生存期过程》定义的软件生命周期模型

1999年 《统一软件开发过程》

包括4个阶段和5种工作流

五种工作流

UP是一个统一的软件开发过程，可以用于各种类型的项目。UP是基于构件的，使用统一建模语言（UML）。

1
2
3
4

特点：
用例驱动
以基本架构为中心
迭代和增量

初始阶段：

1
2
3
4

明确项目规模。了解核心需求及约束，以确定验收标准。
计划和准备商业理由。评估风险管理、人员配备、项目计划、成本、进度、收益率折中的备选方案。
综合考虑备选架构。评估设计和自制、外购、复用方面的折中，从而估算成本、进度和资源。
准备项目的环境，评估项目和组织，选择工具，决定流程中要改进的部分。

细化阶段

1
2
3
4
5

快速确定架构。
进一步明确需求，充分了解对推动架构和计划决策的最关键的用例。
创建详细的迭代计划，并建立基线。
优化开发流程，确定构建和自动化工具。
优化架构，并选择构件。自制、外购或者复用。

构建阶段

1
2
3

资源管理、控制和流程优化。
完成构件开发，并根据已定义的评估标准进行测试。
根据验收标准对产品进行评估。

交付阶段

1
2
3
4
5
6
7

执行部署计划
完成用户手册
确认测试
打包发布
获得用户反馈
基于反馈调整产品
最终版上线

瀑布模型

瀑布模型严格遵守软件生命周期各阶段的固定顺序，上一阶段完成后才能进入下一阶段，整个模型就像一个飞流直下的瀑布。

1
2
3
4
5
6
7
8
9

优点：
可强迫开发人员采用规范的方法
严格规定了各阶段必须提交的文档
要求每个阶段结束后，都要进行严格评审

缺点：
过于理想化
缺乏灵活性
无法再开发过程中逐步明确用户无法表达准确的需求

瀑布V模型

瀑布V模型是瀑布模型的一种变体。在开发过程中任一阶段都可能引入缺陷，最后的测试只能在交付前发现更多的缺陷。瀑布V模型强调了测试。

1
2
3
4
5
6

优点：
瀑布V模型不但保证了瀑布模型的阶段式文档驱动的特点，更强调了软件产品的验证工作

缺点：
需求分析集中在项目开始，而一旦需求不准确，存在偏差，之后的设计、实现、验证会放大偏差。
瀑布模型后期维护工作相当繁重，而这些维护工作大都是修正需求阶段引入的缺陷，这个问题是瀑布模型难以克服的。

快速原型模型

快速原型是指在计算机上快速建立可以运行的程序或者界面。让用户能尽快了解系统的概貌，一旦用户确认了原型，就可以快速按照原型开发出满足用户真实需求的软件产品。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

特点：
引入了迭代的概念
强调用户参与
在用户需求分析、系统功能描述、系统实现方法等方面允许有较大的灵活性，可以逐步完善。
可以用来评价几种不同的设计方案
可以用来建立系统的某个部分
不排斥传统生命周期的有效的方法和工具，与传统方法互为补充。

动态定义需求，适用于需求不明确的项目。

不适合使用原型法的情况：
缺乏使用的原型开发工具
用户不参与、不积极配合开发过程
用户的数据资源缺乏组织和管理
用户的软件资源缺乏组织和管理

演化模型

演化模型也是一种原型化的开发方法。

1
2
3

快速原型模型中，原型的用途是获取用户的真实需求，一旦需求确定了，原型就被抛弃，是一种“抛弃式”的原型化方法。
演化模型中，则是从初始模型逐步演化为最终软件产品的渐进过程，是一种“渐进式”的原型化方法。
一个演化模型可以看做若干次瀑布模型的迭代。

增量模型

增量模型是第三种原型化开发方法，它既不是“抛弃式”的，也不是“渐进式”的，而是“递增式”的。

1
2
3
4
5
6
7

在系统的技术架构成熟、风险较低的时候，可以采用增量的方式进行系统开发，
这样可以提前进行集成测试和系统测试，缩短初始版本的发布周期，提高用户对系统的可见度，降低系统的风险。
第一版本往往是系统的核心功能，可以满足用户最基本的需求。之后增量版本的功能逐步丰富、完善。

注意：
每一个版本都是一个完整的、可用的版本
版本间的增量要均匀

螺旋模型

螺旋模型结合了瀑布模型和演化模型的有点，不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。
螺旋模型在“瀑布模型”的每一个开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制。它把软件项目分解成一个个小项目，每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型特别适用于庞大而复杂、具有高风险的系统。

1
2
3
4
5
6

优点：
螺旋模型支持需求的动态变化，为用户的关键决策提供了方便，有助于需求准确性；为项目管理决策调整提供了便利，从而降低软件开发风险。

缺点：
需要具有相当丰富的风险评估经验和专业知识，如果未能及时标识风险，势必会造成重大损失。
过多的迭代次数会增加开发成本，延迟提交时间。

构件组装模型

利用软构件进行搭积木的方式开发。

1
2
3
4
5
6
7
8
9
10

优点：
让系统扩展更容易
构件更容易被重用，降低软件开发成本
构件粒度较小，开发任务更灵活，可用若干小组并行开发。

缺点：
需要经验丰富的架构师，设计不好的构件难以实现构件的优点，降低构件组装模型的重用度。
在考虑重用度的时候，往往会在其他方面让步，比如性能。
使用构件的时候，要求开发人员熟练掌握构件，增加了开发人员的学习成本。
第三方构件的质量难以掌握，且会最终影响软件的质量。

进阶方法包括极限编程、自适应开发、水晶方法、特征驱动开发等，他们都认为传统的软件工程方法文档量太“重”了，成为“重量级”方法，而敏捷方法则是“轻量级”方法。

一、极限编程

极限编程由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联，并通过行为贯穿于整个生命周期。

四大价值观

沟通

如果小组成员之间无法做到持续的、无间断的交流，那么协作就无从谈起。

简单

“够用即好”，尽量地简单化。

反馈

向团队内部、客户、管理层反馈，通过持续、明确的反馈来暴露软件状态的问题。

勇气

每时每刻都在变化，需要有勇气来面对快速开发，甚至重新开发。
在四大价值观之下，隐藏着一种更深刻的东西，那就是尊重。因为这一切都建立在团队成员之间相互关心、相互理解的基础之上。

五大原则

快速反馈
简单性假设
逐步修改
提倡更改
优质工作

12个最佳实践

计划游戏

先快速指定一份概要的计划，随着细节不断清晰，在逐步完善计划。

小型发布

持续集成，小步快走

隐喻

简单设计

简单不是忽略设计，而是认为设计不应该在编码前一次性完成。

测试先行

重构

要有重构的勇气，目的是降低变化引起的风险、使得代码优化更加容易。

结对编程

降低了沟通成本，提高了工作质量。

集体代码所有制

每个人都拥有全部代码，也都需要对全部代码负责。

持续集成

每周工作40小时

现场客户

将客户请到现场，时刻保证“客户负责业务决策，开发团队负责技术决策”。

编码标准

确保代码清晰，便于交流指导。

二、特征驱动开发FDD

FDD也是一个迭代的开发模型，弱化了过程在软件开发的地位。FDD强调软件开发不可缺少的三个要素：人、过程、技术。

FDD角色

项目经理

是开发的组织者，同时对外沟通

首席架构设计师

系统架构设计

开发经理

负责团队日常开发，解决开发中的技术问题和资源冲突。

主程序员

带领小组完成特征的详细设计和构建工作，要求有一定工作经验病能带动小组工作。

程序员

开发

领域专家

对业务领域精通的人，一般是客户、系统分析员等。

FDD核心过程

开发整体对象模型

业务建模，强调系统的完整地面向对象建模。

构造特征列表

特征是一个小的、对客户有价值的功能，特征包括动作、结果、目标，颗粒度最好在两周之内。

计划特征开发

项目经理根据特征列表、特征之间的关系安排开发任务。

特征设计

主程序员带领小组进行详细设计，为构建做准备。

特征构建

特征设计和构建合起来就是实现阶段，这两个阶段反复迭代，直到开发完成。

FDD主张个体所有对系统开发更有帮助。

三、Scrum

1
2
3
4
5

特点：
Scrum是一个增量的、迭代的开发过程。
整个开发过程由多个短的迭代周期（Sprint）组成，每个周期建议2-4周。
由Backlog管理产品需求，Backlog是按商业价值排序的需求列表，每个需求通常是一个故事。
总是优先开发最客户最有价值的需求。

（1）五个活动

产品待办事项列表梳理

Sprint计划会议

固定时长：推荐时长是每周对应两小时或者更少。
一、需要完成那些工作：由开发团队根据当前产品增量的状态、团队过去的工作情况、团队生产力及代办事项优先级决定。
二、如何完成工作：工作拆分成小的单元，每个单元不超过一天。

每日Scrum会议

团队内部沟通
固定时长，不超过15分钟
我完成了什么，我要做什么，我的阻碍

Sprint评审会议

固定时长：推荐时长是每周对应一个小时。
会议邀请其他相关干系人参加。
会议内容：演示产品增量、新想法，调整产品待办事项列表。

Sprint回顾会议

固定时长：推荐时长是每周对应一个小时。
回顾团队在流程人际关系及工具方面做得情况，识别出好的，不好的，找出潜在改进事项。

（2）五大价值观

承诺

愿意对目标作出承诺

专注

把心思和能力用到承诺的工作上

开放

项目中的一切开放给每个人看

尊重

每个人都有他独特的背景和经验

勇气

有勇气做出承诺，履行承诺，接受别人的尊重

四、水晶方法Crystal

水晶方法Crystal家族包括Crystal Clear、Crystal Yellow、Crystal Orange、Crystal Red。
最常用的是Crystal Clear——透明水晶方法。
透明水晶方法七大体系特征

1
2
3
4
5
6
7

经常交付
反思改进
渗透式交流
个人安全
焦点
与专家用户建立方便的联系
配有自动测试、配置管理和经常集成功能的技术环境

五、其他敏捷方法

开放式源码：

1
2

开发人员地域分布广
查错排障高度并行，任何人都可以将补丁发给维护人

山东省大数据工程专业职称考试-大数据分析应用-中级大纲如下：

恭喜我过了！祝你们也能过~

一、大数据法律法规、政策文件及相关标准
二、计算机基础知识
三、信息化基础知识
四、大数据安全
五、数据库系统
六、数据仓库
七、大数据技术与应用
八、大数据分析模型
九、数据科学

中间件-Redis
中间件-ZooKeeper
Web-浏览器