- 系统开发过程整体介绍
- 系统开发过程步骤
- 选择开发路线和策略
- 自动化工具和技术
1.系统开发过程整体介绍
重点摘要：这一部分内容主要介绍开发过程整体的一些基本信息，这些信息对系统开发过程整体的了解有极大的帮助，至少它可以让你从某些细节和事务中跳出来，把握主要的内容。从能力成熟度模型上分析，我们一般可以得到一家公司的过程能力处于什么等级上，在这个等级上我们能获取什么样的信息，可以做哪一方面的改进。系统生命周期和系统开发方法会让你辨别当前系统在开发过程中使用的方法学是那种，同时也让你更加容易的知道现在项目的具体开发流程大概是什么样的，系统处于什么阶段。系统开发过程中的基本原理是指导的规则，违背这些规则会带来非常麻烦的问题，尽量遵守它们。整体介绍的内容是组织层面的流程、项目层面的方法指导、项目层面的规则指导。
1.1 能力成熟度模型
从书本中你可以找到很多开发要遵循一致过程的，为什么要这样呢？因为一致的过程可以让所有的参与者可以快速的了解这个工程的细节，尽管这种一致性的过程有时候会显得非常不合时宜，甚至是因为使用的人变得呆板，这个一致性的过程也扩大了参与者的范围，降低了参与者的门槛。为什么在中国的环境很少有贯彻使用这种一致性过程的人呢？商业上的竞争机会，系统拥有者的知识水平，还有系统使用者之间的竞争，系统承建者的成本等因素都在促使一致性过程被破坏。能够在这种环境下使用一致性过程的人一般需要对这个一致性过程有很高的理解力和调整能力。
Note:拥有知识或者是会某种知识不会让你很牛逼，但是你会运用它会让你很牛逼。
能力成熟度模型是帮助组织改善开发过程的，总共有五个等级。
第一级：初始级，无政府状态或者混乱状态。项目成败往往取决于项目团队的技能和经验，开发过程是不可重复也是不可预测的，常常有很多危机并超出预算，项目文档零散而且不一致。多存在于小公司以及没有开发制度规范的公司，包括存在外行直接指导内行模式开发过程的公司。
第二级：可重复级，组织已经建立了项目管理过程和实践，这些过程和实践可以跟踪项目费用、进度、功能。这一级重点是项目管理。组织采用的项目管理过程和实践是某个成功的存在，并且是生搬硬套，有时不合时宜。项目成败取决于项目团队的技能和经验。这一级为下一级标准化过程提供了素材并奠定了基础。
第三级：已定义级，组织购买或开发了一个标准的系统开发过程，并将其集成到组织的信息系统和服务部门中。由于所有项目都使用了标准化过程，所以项目产生一致并且高质量文档和交付成果。开发过程是稳定、可预测并且可重复。
第四级：已管理级，组织建立了可度量的质量和生产率目标。因为是基于标准化，开发过程的数据信息有效的保存到数据库中，这样可以通过数据统计分析，主动预测项目的问题，提前做好应对。
第五级：优化级，根据第四级数据的度量和分析，持续改进标准化过程和项目开发，最终形成组织最佳技术实践。
1.2 系统生命周期和系统开发方法
系统生命周期是自然存在的，有两个关键阶段的转换：1.当系统从开发阶段循环到运行和支持阶段时，必然会发生一次；2.在某个时刻，出现报废，系统从运行阶段循环到重新开发阶段。系统开发方法是一种方法学，它是构建和维护系统以及其他信息系统走过它们生命周期的标准过程。同能力成熟度模型的目标一致，系统开发方法确保：
1.提供一个一致且可再生的方法应用于所有项目；
2.降低了简捷和错误的风险；
3.为了各个项目生成完整且一致的文档；
4.由于所有人员都使用相同的过程，所以可以在项目之间灵活分配人员；
5.虽然开发团队和开发人员在不断变化，但是后来者可以方便地获得和理解以前的工作成果。
方法可以购买和自创。常见的方法学案例有结构化分析和设计、极限编程、动态系统开发方法等。
1.3 系统开发基本原理
这些原理是告诉我们，尽可能地去做到，这样可以提前规避掉很多的问题。预防胜过问题发生之后的补救。
原理1：让系统用户参与。系统用户包括系统使用着、系统设计人员、系统开发人员
原理2：使用一套问题解决步骤。遵循固定的解决步骤规避因为灵活跳跃步骤带来的风险，用稳定来替代灵活随意，越是规模大的系统，就越需要遵循固定步骤
原理3：确立开发阶段和开发活动。这些是为了明确时间段和每个时间段要解决的问题。
原理4：在开发过程中记录文档。足够的文档会保证项目工程不会因为人员流动带来困扰，但是过多的文档是不可取的。
原理5： 建立标准。只有比较一致的标准，项目才可以做到良好的集成。
原理6：管理过程和项目。使用标准化过程可以有效降低过程和项目中问题的产生。
原理7：将信息系统作为重要的投资看待。开发过程中对项目增加更多的功能如果不同步更新费用会在纸面上表现成本超支。信息系统是一种投资，以成本效益分析方法分析成本，而且要在项目的多个阶段中都要进行。如果一个项目成本效益不好，中途停止带来的短时间内损失会很大，但是不停止会带来更大的长时间损失，短时间内的损失总是小于长时间内的损失。
原理8：不必害怕取消和返工。在项目过程中要进行分阶段投入，每次投入之前都要分析项目的成本收益，决定是不是要中止、变更或者是缩减工作范围。实际工作中，大多数系统分析员、系统用户、系统所有者会忘掉成本收益的问题，所以在成本收益上陷入困境的项目非常多。特别是系统用户和系统所有者在中国这个环境下认为可以通过增加功能压低成本的时候，最终实质产品还是与成本有直接关联。
原理9：分而治之。将庞大的目标系统不断进行分解，分解到各种可以进行处理的子系统和组件是一项非常重要的基本要求。
原理10：设计系统时应考虑到增长和变化。
2.系统开发过程
这里将简单描述一个开发过程的样例，通过这个样例我们可以进一步去了解开发过程中细微之处。
2.1 项目确定
绝大多数的项目都是由系统所有者和系统用户启动的。大部分的项目动力来自于问题、机会和指示。 项目动力来源包括了解决问题、探索机会、实现指示。PIECES作为一个实用的问题分类框架，概括了项目动力来源的六个主要方面：
Performance：改进性能的需要
Information：改进信息和数据的需要
Economics：改进经济、控制成本或增加收益的需要
Control：改进控制或安全的需要
Efficiency：改进人与过程效率的需要
Service：改进客户、供应商、合作伙伴、雇员等服务的需要
计划内的项目多是来自于企业的信息战略规划和业务过程重构，计划外的项目多是来自于问题、机会和指示。并不是项目一旦提出就会进入计划和执行阶段，而是对多个项目进行抉择，看看那些对当前更有利。
2.2 FAST项目阶段
这里将会介绍一个比较通用的开发过程。
2.2.1 定义范围阶段
在这个阶段主要是定义项目的范围、目标、约束条件以及参与者、预算、进度。由于在项目刚开始的时候，很多信息并不是很明确，需要在项目进行过程中进一步更新和补充细节，所以在这个阶段的文档一般是非常粗略的。这个阶段的文档产物是作为衡量项目范围蔓延的基准。当前阶段的最重要的发布物是工作陈述。工作陈述是开发信息系统的合约或协议，它合并了问题陈述、范围陈述、进度和预算，提供给所有将参与该项目的各方。
2.2.2 问题分析阶段
这个阶段是研究现有系统的问题，关注系统用户，全面了解系统，针对最重要的问题来回答是不是要进行系统重构或者研发，是否本次的操作可以做到物超所值。如果是就进入下一个阶段。
2.2.3 需求分析阶段
需求分析阶段是开发过程阶段中最重要的阶段，它主要关注的是系统必须做什么的决策。需求需要做出需求陈述，同时也要确定优先级。这个阶段是开发过程中绝对不应该简化或省去的。需求直接关联着开发过程的目标，差之毫厘，失之千里。
2.2.4 逻辑设计阶段
逻辑设计阶段是将业务需求转换成系统模型。系统模型与具体实现技术无关，多使用系统模型图展示。图形是一种好于文字的沟通方式。
2.2.5 决策分析阶段
决策分析是对多种方案的决策，包括对一系列问题的决策。在技术可行性、运行可行性、经济可行性、进度可行性、风险可行性等各种方案作出决策，采用适当的方法缩减筛选范围，最终形成决策方案，进行实施。
2.2.6 物理设计和集成阶段
物理设计阶段是一种具体的特定的方案，它描述了方案的具体的物理过程，例如具体的人机交互方式，业务物理操作流程设计等等。物理设计存在两种极端，一种是设计产生物理系统模型和详细的规格说明，另外一种是构造不完整但可工作的应用或自系统并基于用户和其他设计人员的反馈细化原型。通常物理设计是这两种极端的组合，既有沿用原先体系系统的模式，又有独立于其他系统的个性特征。沿用原先系统的模式可以降低集成的难度，独立的个性特征是解决问题的主要方案。
2.2.7 构造和测试阶段
构造和测试阶段主要交付物是功能系统，主要是代码开发和测试的阶段。
2.2.8 安装和发布阶段
这个阶段主要是提供一个可正常运行的系统，保证旧系统向新系统的平稳转换。
2.2.9 运行和维护阶段
主要做系统支持，包括辅助支持、修正系统缺陷、恢复系统、调整系统适应新需求。
2.3跨生命周期活动
2.3.1调查研究，没有调查就没有发言权
2.3.2记录文档和演示汇报，这是有助于提升沟通效率
2.3.3可行性分析，有助于保证项目在开启时做出正确的决策
2.3.4项目管理和过程管理，这是在组织层面的保障，但是大多数公司没有
2.4顺序开发和迭代开发
顺序开发和迭代开发在介绍上都好理解，但是真正运用的好的公司没有多少，没有实践支撑的理论只是空中楼台。技能本身就是来指导应用场景的，没有几个场景支撑就彻底成了赵括。
3.选择开发路线和策略
开发路线和策略的选择要根据实际情况去选择，因势利导。下面介绍几种开发策略：
3.1 模型驱动开发策略
历史最悠久、最常用的分析和设计信息系统的方法是建模。模型是一种图形表示，表示了实际情况或最希望的情况。它会促进系统用户、分析人员、开发人员、构造人员之间的交流。前面提到的FAST模型就是一种。模型数据大概率可能是过时的，要注意维护。以下是三种最流行的模型驱动开发技术。
3.1.1 过程建模
起源于结构化分析和设计方法中，是一种可靠而且重要的技术，有点过时，但是因为业务重构的需要，它又向活跃舞台前进了几步。这种建模技术非常有助于消除存在于非技术性的系统所有者和用户与技术性的系统设计人员和构造人员之间的交流隔阂。
3.1.2 数据建模
使用最广的系统建模技术，重点在于捕捉业务数据需求的模型上，并把这些模型转换成数据库设计，极其强调知识构件和数据。
3.1.3 对象建模
对象建模是技术进步的产物，它消除了过程建模和数据建模之间的同步问题。面向对象建模是现在的主流。
3.2 快速应用开发策略
这个是采用原型开发的策略，隐藏在具体的背后是：当系统用户看到系统工作时，他们才知道想要的是什么。在RAD中，原型最后会进化成最终的信息系统。当然这个概念美好深深的吸引了系统拥有者，但是任何策略的实施都需要有足够技能的人才来支撑，特别是这种快速反馈、快速沟通。现实情况是使用这种策略的项目都是中小型项目，对人的要求格外的高，大部分企业完全不知道需要什么样的人然后只是吹概念，“我们至少是在名义上做到了敏捷开发”，此言常在。
3.3 商用应用软件包实现策略
商用软件包策略存在是因为企业经营策略而产生的。作为一家企业，我们只擅长我们的主营业务，至少it不是主业务。但是为了提高竞争优势，买一个比自己生产一个划算多了，至少这个策略是一个商业策略。多数情况下，我们要进行定制软件，选择合适的供应商，最好在软件不用之前供应商还能支持。虽然我们定制的软件和业务流程有点出入，至少整体上的效果是好的，剩下就是评估差异，寻求供应商继续改进。对软件拥有者来说，怎么清楚和正确的描述业务需求是很有难度的；对供应商，坚持不懈的持续改进是很有难度的，不见得名声好的就一定对，但是没有点真材实料的供应商肯定是不行的。
3.4 混合策略
根据FAST的开发路线，不同的阶段根据实际情况调整实现策略就是混合策略了。
3.5 系统维护
系统维护是对已经运行的系统进行维护。并不是所有已经建成的系统都会得到很好的维护，除非系统有足够的文档。需要维护的时间越长，对系统的文档化要求越高。这也会对系统维护的流程做出正式的规范。人员上的要求需要根据系统的文档化程度做出判断，文档化程度越高，人员要求越低，但是还是要高于一定年限的工作水平；文档化程度越低，人员要求越高，直到资深以上不封顶。系统的维护成本怎么估算就是一件值得推敲的事了。商用软件包的运维费用比自建系统的运维费用高是肯定的。
4. 自动化工具和技术
使用各种管理工具是现在这些公司的基本要求，但是当你面临只能使用纸和笔进行分析的时候，这毫不亚于石器时代与工业时代的对手做竞争，而美其名曰经费不够。使用工具和技术也是有一定要求的： 1.使用统一的工具，包括统一来源、统一版本、统一维护；2.工具的使用要足够的容易，最起码培训费用要低；3.满足开发人员和设计人员的要求，支持各种数据的统计分析；4.开发环境要统一；5.如果能支持过程管理和项目管理就更好了。在我经历的公司中，有实现全部这些要求的，也有的一条也不满足，差距在于产出的全面性上都有差距。