《企业级应用软件架构开发过程与实践chapter2.pdf》由会员分享，可在线阅读，更多相关《企业级应用软件架构开发过程与实践chapter2.pdf（40页珍藏版）》请在金锄头文库上搜索。
1、 中国软件架构师网 中国软件架构师网 软件高端人才修炼系列 软件高端人才修炼系列 企业级应用软件架构开发过程与实践企业级应用软件架构开发过程与实践 第二章第二章 版本版本 0 5 胡协刚胡协刚 首席软件架构师首席软件架构师 szjinco www chinaarchitect org 中国软件架构师网 2006 Page 2 of 40 目录目录 第一章第一章 软件与软件的特性软件与软件的特性 从业务上下文出发的软件图景从业务上下文出发的软件图景 3 第二章第二章 软件工程基本原理软件工程基本原理 软件开发中的方法论软件开发中的方法论 4 第一节 问题解决规律与工程学方法 软件开发的方法 理
2、论框架基础 5 问题解决 5 解决复杂问题与方法论 7 工程问题与工程学方法 10 第二节 软件工程与软件过程 人类迄今为止最复杂的问题解决过程 14 软件工程 14 软件过程 16 软件过程的表述 18 软件过程的基本组成要素 19 软件过程科目 discipline 20 科目下的工作流 workflow 20 工作流明细 workflow details 21 软件生命期模型 22 以阶段为单位组合工作流 24 第三节 软件过程能力成熟度模型 CMMI 模型下的软件组织活动全景视图 27 软件过程的执行步骤 27 SW CMM CMMI 过程体系 31 CMMI 的过程成熟度等级 34
3、CMMI 的过程域 37 本章小节 39 中国软件架构师网 2006 Page 3 of 40 第一章 软件与软件的特性 从业务上下 文出发的软件图景 第一章 软件与软件的特性 从业务上下 文出发的软件图景 软件是人类有史以来创造的一种非常特别的制品 它具备与传统制品 完全不同的特性 由于软件最初的形态只是用于科学计算的简单程序 这使得人们 特 别是刚刚学习编程的初学者 往往倾向于将软件看作是一种相对独立的事 物 传统软件工程也是从软件需求开始来阐述软件的生命周期 并给人一 种错觉 即软件需求早就存在于用户那里 我们要做的只是去发现它们 需 求获取 这使得人们常常忽略一个简单的事实 软件是为了
4、支持客户 的业务 或解决领域问题 而被开发的 需求规格是被开发出来的 换句 话说是被设计出来的 其内在特性受其上下文的制约 甚至就是上下文 的一种直接反映 我们在研究软件的时候 不能脱离于它的上下文 例如软件的复杂性 根本上源至其问题域的复杂性 只有从业务 问题域 上下文入手 我们 才能真正看到软件的真实图景 本章试图从一个更为广泛的视角 来分析软件 还有软件的特性 而 软件及其架构的开发策略与方法的研究 则始于人们对软件自身特性所引 发的固有问题的一种解决努力 中国软件架构师网 2006 Page 4 of 40 第二章 软件工程基本原理 软件开发中 的方法论 第二章 软件工程基本原理 软件
5、开发中 的方法论 人们从事的大部分有意义活动 都可以归纳为一种问题解决的过程 软件开发也不例外 思维学家们做了大量的研究来帮助人们提高问题解决 的能力 认知学 方法论等都属于这方面的成果 软件被用来解决领域问题 它实际上包含了两个 问题解决 过程 一是 如何使用软件来解决业务问题 二是 如何开发出这个能解决业务 问题的软件交付 我们当然更为关注后者 当前软件的规模 复杂度已经 大到迫使人们必须采用团队模式来组织开发 而人类以往的成功经验是以 工程的方式来组织团队协作 另外 软件有其特殊的地方 因此我们需要 改造传统工程方式来适应软件的开发 这便是软件工程的由来 要将软件交付开发出来 不是单个的
6、方法或步骤所能办到的 这涉及 到一系列的活动 方法等 而有序的软件开发活动序列便是软件过程 本章试图从人类解决复杂问题的基本途径入手 一步步来分析软件开 发的基本方法 进而导出软件工程的基本框架 最后引入软件过程的体系 概念 中国软件架构师网 2006 Page 5 of 40 第一节 问题解决规律与工程学方法 软件开发的方法 理 论框架基础 澄清了软件的上下文与本质特性 理解了软件的各种质量属性 并将它们设定为 软件开发的目标 接下来 我们面临的挑战是如何去开发软件 软件被用来解决人们的业务或领域问题 开发软件的过程就是去获得解决业务问 题结果的过程 人类在问题解决规律研究方面已经有大量的现
7、成成果 传统的问题解 决步骤 实际上为软件开发 解决软件问题 提供了现成的 战略级的 理论方法框 架 现代的软件工程技术 其基础实际上就建立在这些问题解决规律之上 问题解决问题解决 我们先从最基本的问题解决步骤入手 接下来考察复杂问题如何解决 然后将关 注点转向工程类问题 并最终推导出如何解决软件问题的基本途径 问题解决是思维的一种形式 当个人或组织不知道如何从已知条件得到目标 期 望结果 的时候 解决问题 这一智力活动便开始了 对于普通的单一问题 我们可以将 解决问题 的过程简单地抽象为如下步骤 识别与澄清问题 收集相关信息 分析问题和评估已有信息 考虑各类解决方案选项与 结论 选择并实施最
8、佳解决方案 如问题没能被 解决 则再次尝 试 下一轮解决 周期 中国软件架构师网 2006 Page 6 of 40 图 2 1 问题解决流程示意图 识别与澄清问题 在解决问题之前必须先确定问题是什么 有时候问题并 非那么显而易见 而是充满了模糊与矛盾 因此还必须去伪存真 澄清问题 的实质所在 软件充满了不确定性 模糊与矛盾 而且人们对待软件的态度偏于主观 很 多时候 找出正确的软件问题并不像人们想象的那么容易 例如 曾经有客户需 要开发一套监控软件 用于监视其业务系统的运作状况 包括实时显示被监控系 统的 cpu 占用率等 让开发组苦恼的是 客户要求必须采用 B S 浏览器客户端 服务器 架
9、构 而在 B S 架构下实现较为复杂的图形化界面是代价非常高昂的 本案例中的客户显然并没有搞清楚他的真正问题是什么 这套监控软件并不会被 多人使用 因此不存在部署与升级的麻烦 因为安全的原因 客户也不期望能从 外部跨越 internet 网来使用本软件 这样 在此软件上采用 B S 架构将不会带来 任何明显的好处 相反却要付出更大的成本 B S 架构的优势在于近乎零成本的 部署与升级能力 以及使用了能穿透防火墙的 http 协议 收集相关信息 对问题相关的信息了解越多 就越有助于人们认识和解决 问题 一个有经验的软件工程师 在开始开发软件 包括定义需求 之前 会先去 了解相关的业务领域知识 并
10、尽力去寻找业界在此领域的通行做法和常用技术 通过收集相关信息 他甚至可能找到现成的架构方案 或者找到直接可用的开放 源码 分析问题和评估已有信息 问题本身有时并非那么简单明了 还需要进一 步进行分解 并分别被深入思考 收集到的信息 则需要归纳分类 评估其 准确度 相关性与可利用价值 最后 应当建立起这些信息与问题之间的关 联 方便人们从中找到解决的线索 软件非常复杂 其所要解决的业务及领域问题 通常涉及到客户 用户的多 种甚至是相互矛盾的要求与期望 软件架构师在选择架构方案之前 必须分析这 些支离破碎的要求和相关描述 并加以综合 最后整理出软件的各项架构敏感因 素 然后根据其自身及业界经验 找
11、出相应的构架级技术 并与前面的架构敏感 因素关联起来 考虑各类解决方案选项与结论 从问题与相关线索中得出结论和各类候选 的解决方案选项 然后分析与比较各自的优劣 包括成本 时间 利益 副 作用 风险与最终可能的结果等 最后得出一个最合适的选择 为了实现软件的诸如功能 可靠性 性能等各类质量属性 软件架构师从与 架构敏感因素相关联的构架级技术中找到备选的方案 并分析与比较各类技术的 优劣 以确定最适合的选项 并最终综合得到完整的架构方案 中国软件架构师网 2006 Page 7 of 40 选择并实施最佳解决方案 决定要采纳的方案 并加以实施 同时还要监 督实施的进展与实际效果 有必要的话 进一
12、步改进方案 再贯彻下去 软件架构方案被选定之后 开发组将按照架构方案中的模块划分进一步精化 设计 然后编码实施 从而最终贯彻这个架构方案 重试下一轮解决周期 所选择的方案 其实施有可能没有将问题解决 这 样就需要重新收集更多的信息 再次分析问题等 从而开始下一轮的问题解 决周期 这种循环将持续 直到问题被解决为止 一个软件在成功交付之前 必然经历大量的失败 重试的周期循环 例如 软件架构上的一个性能瓶颈问题 架构师设计相应的方案来应对 但往往第一次 尝试很可能失败 架构师必须继续设计新的方案 重新进行尝试 直到性能瓶颈 被消除为止 另外的典型示例 则是程序员解决代码中 bug 的过程 实际上
13、正 是因为软件的可塑性强 容易修改 才使得人们能够通过反复尝试的方式去解决 软件问题 上述问题解决的步骤 适于解决单一性质的问题 软件开发过程中将遇到一系列 性质各异的问题 我们需要多次重复这个步骤 去分别一一解决不同的问题 解决复杂问题与方法论解决复杂问题与方法论 软件被用来解决领域问题 但是正如前面所述 其面临的问题极其复杂 而且通 常都不是单一的问题 开发者需要分析客户 用户的多种要求与期望 并加以综合才 能整理出客户背后真实的目标与相关问题 即软件的需求 的结构 软件开发实际上将涉及两个 问题解决 过程 一是 如何使用软件来解决业务 问题 二是 如何开发出这个能解决业务问题的软件交付
14、后者之所以被专门关注 是因为常规的问题解决步骤对解决软件问题已经力不从心 人们需要寻求一种更有效 的解决途径 前段中所描述的问题解决步骤 存在一个隐含的假定前提 就是所有问题都能够 采用同样简单的方法 步骤来加以解决 对于那些普通 单一的问题而言 这个假定 是成立的 但对于软件开发这种复杂和多方面问题交织在一起的情况 假定就不再成 立了 实际上 软件具有不一致性与多样性 不同性质的软件 不相同的地方很多 所适应的开发方法也可能完全不同 例如 普通业务软件适用于迭代模型 而一些成 熟的电信设备控制软件则可能适用于瀑布模型 从理论上讲 我们可以组合上段描述 的问题解决步骤来解决更复杂的问题 包括软
15、件问题 但是如何去组合这些步骤 并 保证人们在遇到类似情形时 总是能正确地组合解决方法 成功地解决问题 这属于 方法论研究的范畴 方法论是与问题解决有关的一门思维科学 其通常的定义是 一个学科中所采用的 相关方法 规则与公理 人们只要遵照正确的方法论所指导的途径去解决现实问题 就有更大的机会获得成功 方法论的实质在于认识相关领域中的规律 而运用并遵循 中国软件架构师网 2006 Page 8 of 40 这些规律 就能确保方法自身的正确性 笛卡尔在其 方法论 中 对问题解决方法有段非常精彩的论述 他将研究问题 的方法分为四个步骤 永远不接受任何自己不清楚 存在疑点的真理 或事实 与问题相关的那
16、些 事实必须被亲自证实 而能够作为研究问题所依据的公理 定律 也必须被 亲自验证无疑 可以将要研究的复杂问题 尽量分解为多个比较简单的小问题 一个一个地 分开解决 将这些小问题从简单到复杂排列 先从容易解决的问题着手 将所有问题解决后 再综合起来检验 看是否完全 是否将问题彻底解决了 毫无疑问 笛卡尔已经提示我们应当如何去分解问题 并组合多个问题解决周期 每个问题的解决过程都是一个解决周期 来处理复杂问题 然而不是人人都精通方 法论 大多数人在第一次解决某个复杂问题时通常都会遇到失败 对于软件而言 要 同时解决功能 可用性 可靠性 性能 以及可维护性等质量问题 其对应的方法将 更为复杂 自然找到正确的方法也相当困难 实际上 没有任何一个人 能够在不参 考业界已有经验成果的基础上 独立设计出一套软件开发的正确方法 我们期望能够 利用他人或自己以往解决类似复杂 软件 问题的成功经验 于是我们将前段中的解 决步骤进行改造 变为如下模式 中国软件架构师网 2006 Page 9 of 40 图 2 2 先选择方法的问题解决流程示意图 在上述流程中 具体的问题解决步骤不再被事先确定 而是要根据问
