CMMI3精髓培训(中级2)

open-wyp

贡献于2011-09-24

字数:0 关键词: 培训

CMMI 精髓培训-中级2 彭国明 http://www.mansuo.com 上海漫索计算机科技有限公司 Page 2 目录 1. 需求开发 2. 需求管理 3. 软件设计 4. 软件实现 5. 产品交付 6. 小结 Page 3 1.需求开发 1.1.1 需求的基本概念 ‹ 宽泛地讲,需求来源于用户的一些“需要”,这些“需要”被分析、确认后形成完整的文档,该文档 详细地说明了产品“必须或应当”做什么。 ‹ 所以如果只有一些零碎的对话、资料或邮件,你就以为自己已经掌握了需求,那是自欺欺人。 1.1.2 需求的重要性 ‹ Frederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性: – 开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的 需求,包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错,将会给系 统带来极大的损害,并且以后对它修改也极为困难。 ‹ 需求是产品的根源,需求工作的优劣对产品影响最大。就像一条河流,如果源头被污染了,那么 整条河流也就被污染了。 ‹ 国内软件业的痼疾:人们并不清楚究竟该做什么,但却一直忙碌不停地开发。 1.1 什么是需求 Page 4 1.2. 了解客户、最终用户、间接用户 1.2.1 基本概念 ‹ “用户”(user)是一种泛称,它可细分为“客户”(customer)、“最终用户”(the end user)和“间接用户”(或 称为关系人)。 ‹ 掏钱买软件的用户称为客户,而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同 一个人。 1.2.2 客户是掏钱买软件的人,所以他是“上帝” ‹ 某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时,精辟地阐述了客户的地位: – 如果顾客先点鸡,那么就先有鸡;如果顾客先点蛋,那么就先有蛋。 ‹ “现代营销学之父”菲利普•科特勒所著的《市场营销导论》是这样描述客户的: – 客户永远是本公司的座上客。客户并不依赖我们,而我们却依赖客户。客户不是我们工作 的障碍,而是我们工作的目标。我们并不因为服务于他而对他有恩,他却因为给予我们服 务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户 的争辩中获胜。客户是把他的欲望带给我们的人,因此我们的工作就是满足这些欲望,从 而使客户和我们共同获益。 ‹ 与客户打交道的主要目的是:一是获取需求,二是签合同。不要把钱仍到水里。 Page 5 1.2. 了解客户、最终用户、间接用户 1.2.3 即使最终用户不是上帝,也算是“上帝”的“亲戚”,同样怠慢不得。 ‹ 如果项目规模比较大,那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需 求,请最终用户试验软件,对最终用户进行培训等等。 ‹ 公司新员工上产品培训课,有位小领导匆匆赶来作指示:“隔壁班正在给电信局的员工们进行培训 ,他们都是上帝派来的,大家要注意形象。由于休息室空间有限,请大家自觉让位。午休时他们 可以躺着睡,我们只能坐在位置上打个盹儿…….。” 1.2.4 重视“间接用户”,千万别“大意失荆州” ‹ 间接用户既不掏钱买该软件产品,也不使用该软件,但是它可能对软件产品有很大的影响。 ‹ 例如,财务软件开发商在把“财务软件”卖给客户之前,这个“财务软件”必须得到国家财政部的批 准。否则即使该软件的功能是完美的,但却被政府认为是非法的。所以国家财政部就是所有财务 软件的间接用户,它不仅不付钱给财务软件开发商,反而要收取鉴定费、手续费等。 ‹ 同理,市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准,否则软件开发商被 逮住后戴上“非法经营”的帽子就惨了。 Page 6 Analyze and Validate Requirements 分析和验证需求 Develop Customer Requirements 开发客户需求 Customer Requirements 客户需求 Validated Requirements 验证需求 Product, Product-Component, and Interface Requirements 产品、产品组件、接口需求 Develop Product Requirements 开发产品需求 1.3 需求开发过程域结构图 RD: Requirements Development Page 7 Develop the Customer Requirements 转换成客户 需求 Customer Requirements Develop Customer Requirements 开发客户需求 Elicit Needs 诱导需求 1.3.1 开发客户需求 Page 8 Establish Product & Product- Component Requirements 确定产品和产品 组件需求 Product, Product-Component, and Interface Requirements Develop Product Requirements 开发产品需求 Allocate Product- Component Requirements 分配产品 组件需求 Identify Interface Requirements 确定接口 需求 Customer Requirements 1.3.2 开发产品需求 Page 9 Establish Operational Concepts & Scenarios 建立操作概念 和场景 Establish a Definition of Required Functionality 评审功能 需求 Analyze Requirements to Achieve Balance 平衡需求 Analyze Requirements 分析需求 Product, Product-Component, and Interface Requirements Validated Requirements Analyze and Validate Requirements 分析和确认需求 Validate Requirements with Comprehensive Methods 确认需求 1.3.3 分析和确认需求 Page 10 Requirements Obtain an Understanding of Requirements 获得可理解 需求 Obtain Commitment to Requirements 获得对需求的 承诺 Traceability Matrix or Requirements Tracking System Maintain Bidirectional Traceability of Requirements 维护需求的双 向可溯性 Identify Inconsistencies Between Project Work and Reqmts 识别需求和工产 品不一致性 Manage Requirements管理需求 Manage Requirements Changes 管理需求 的变更 1.3.2 需求管理过程域结构图 REQM: Requirements Management Page 11 1.4. 需求工程基本概念 1.4.1 什么是需求工程 ‹ 把所有与需求直接相关的活动通称为需求工程。 ‹ 需求工程中的活动可分为两大类,一类属于需求开发,另一类属于需求管理。 ‹ 需求工程的结构图 Page 12 1.4. 需求工程基本概念 1.4.2 需求开发过程域 ‹ 需求开发的目的是产生和分析用户需求、产品需求和产品组件需求。 ‹ 需求调查的目的是通过各种途径获取用户的需求信息(原始材料),产生《用户需求说明书》。 ‹ 需求分析的目的是对各种需求信息进行分析,消除错误,刻画细节等。常见的需求分析方法有“问 答分析法”和“建模分析法”两类。 ‹ 需求定义的目的是根据需求调查和需求分析的结果,进一步定义准确无误的产品需求,产生《需 求规格说明书》。系统设计人员将依据《需求规格说明书》开展系统设计工作。 1.4.3 需求管理过程域 ‹ 需求管理的目的是在客户与开发方之间建立对需求的共同理解,维护需求与其它工作成果的一致 性,并控制需求的变更。 ‹ 需求确认是指开发方和客户共同对需求文档进行确认,确认方法有评审、签字、原型等,使需求 文档具有商业合同效果。 ‹ 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系,建立与维护“需求跟踪矩阵”, 确保产品依据需求文档进行开发。 ‹ 需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更,防止需求变 更失去控制而导致项目发生混乱。 Page 13 1.4. 需求工程基本概念 1.4.4 需求工程的一些感悟 ‹ 不论是合同项目还是自主研发的产品,都必须开展需求开发和需求管理活动。 ‹ 开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种,只有后两种才 有可能开发出成功的产品。 – “被动型”是指开发者被动地对待需求工程中的各项活动,能少干则少干,能偷懒则偷懒。 他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更,导致产品 迷失方向,不是半途而废就是陷入半死不活的状态。 – “主动型”是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己 的职责,会想尽一切办法克服需求开发和需求管理过程中的困难,而不是找借口推卸责任 。俗话说“良好的开端是成功的一半”,“主动型”需求工程是开发成功产品的必备条件。 – “领先型”是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求,导致用 户跟着新产品跑而不是新产品围着用户转,这叫引导消费。需求工程做到这个份上,才能 使产品立于不败之地,长盛不衰。 Page 14 1.5. 需求开发的主要困难与对策 1.5.1 知识技能问题 ‹ 应用域的知识是无边无际的,任何人都不可能是“万事通”。俗话说“隔行如隔山”,需求分析员可 能是某一领域的专家,但当他接手陌生的业务时,他可能是个“无知”者。一个企业要谋求发展, 不能总在做老的业务。人一生中会有许多充满挫折的“第一次”,不可以逃避。 ‹ 当需求分析员缺乏应用域知识时,他该怎么办? – 首先他要有勇气做事,否则连实践的机会都没有。 – 其次他应当赶紧补习应用域知识,不论是通过自学还是培训的方式,否则他很难与用户交 流。如果可能的话,开发方最好请既懂软件又懂应用域知识的行家来帮忙。 1.5.2 态度问题 ‹ 相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时,他们会发牢骚,找出一 堆用户的毛病。很多开发人员错误地以为: – 需求是用户的事情,不是我们的事情。我们为用户开发软件,难道用户不该告诉我们应当 开发什么吗?如果用户说不清楚需求,或者经常变更需求,这类问题是用户产生的,应当 由他们自己负责。 ‹ 用户说不清楚需求或者需求发生变更,这些都是常见的问题,并不是绝症,是人们可以设法解决 的。可悲的是开发人员把这些问题当成了借口,不愿主动攻克问题,导致需求问题扩散到整个软 件开发过程,产生太多的后患。 ‹ 软件企业的领导应当给具有错误观念的开发人员们洗脑:需求分析员的天职就是在有限的时间内 获取准确而细致的用户需求,如果做不到就是失职,不要找借口。 Page 15 1.5. 需求开发的主要困难与对策 1.5.3 合作关系 ‹ 如果需求分析员不能与用户建立良好的合作关系,那么他们在需求开发过程中会很疲惫。 ‹ 倘若用户不能很好地配合需求分析员,那并不表示他是个坏蛋。因为用户有他自己的想法: – 我回答了你们的问题,讲了该讲的。我们付钱给你们,难道还要我伺候你们不成?我还要 干自己的事情,别打扰我了。你们自己想办法把活干好吧 ……。 ‹ 对于一些竞标项目,在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品,他不 会投入很多精力来协助你搞需求开发。 ‹ 需求分析员不是销售人员,他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色 的需求分析员不仅要有过硬的专业知识,还要具备较强的交流、沟通能力。 ‹ 开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目,我们不能完 全期望双方能够自发地建立起良好地合作关系,这样风险太大。 ‹ 开发方和用户方在开展需求开发之前,双方协商并撰写“用户在需求工程中的权利与义务”,即以 协议的方式确定合作关系。“好话”和“丑话”都说在前头,这样能减少今后的摩擦。如果条件允许 的话,开发方最好为用户举办关于需求工程的培训,这样的培训将使用户明白需求的重要性以及 忽视需求的危害性,从而促使他们积极友善地参加需求工程中的各项活动。 Page 16 1.5. 需求开发的主要困难与对策 1.5.4 用户说不清楚需求 ‹ 用户说不清楚需求是普遍现象,这是让开发人员头痛的大问题。 ‹ 有些用户真的不知道需求是什么,或者对需求只有朦胧的感觉,他当然说不清楚需求。 – 例如开发方的营销人员水平比较高,他能够在用户不清楚自己要什么的情况下引导用户“消 费”。 – 例如前些年全国各地的很多政府机构大搞网络建设。这些机构的领导和办公人员大多数不 清楚网络干什么用,就让开发人员替他们设想需求吧,反正是花公家的钱。 ‹ 有些用户虽然心里明白想要什么,但却说不清楚需求。 – 比如说买鞋子。我们非常了解自已的脚,但很难用语言说清楚脚的大小和形状。通常拿鞋 子去试,试穿时感觉到舒服才会买鞋。 ‹ 需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作,否则会连累整个开发 团队的。 ‹ 无论是什么原因导致用户说不清楚需求,需求分析员必须设法搞清楚用户真正的需求,这是需求 分析员的职责,也是职业的挑战。 Page 17 1.5. 需求开发的主要困难与对策 1.5.5 双方误解需求 ‹ 人们在交流的时候,经常会发生“问非所求,答非所问”的事情。 ‹ 有时用户会把开发人员的建议或答复给想歪了: – 有一个软件开发人员滔滔不绝地向用户讲解在“信息高速公路上做广告”的种种好处,用户 听得津津有味。最后,心动的用户对软件开发人员说:“好得很,就让我们马上行动起来吧 。请您决定广告牌的尺寸和放在哪条高速公路上,我立即派人去做。” ‹ 而用户表达的需求,不同的开发人员可能有不同的理解。如果需求分析员误解了需求,那会导致 后续的不少开发人员将错就错、白干活。就像作文写跑题了,写得再好也白搭。这类错误连高智 商的外星人都不能避免: – 有个外星人间谍潜伏到地球刺探情报,它给上司写了一份报告:“主宰地球的是车。它们喝 汽油,靠四个轮子滚动前进。嗓门极大,在夜里双眼能射出强光。……有趣的是,车里住 着一种叫作‘人’的寄生虫,这些寄生虫完全控制了车。” ‹ 不论是复杂的项目还是简单的项目,需求分析员和用户都有可能误解需求。所以需求确认工作( 属于需求管理)必不可少。 Page 18 1.5. 需求开发的主要困难与对策 1.5.6 开发人员写不好需求文档 ‹ 需求调查工作不充分,获取的需求信息太少或者太乱,以至于写不成需求文档。 – 古时候,一书生在考试前补习“写文章”,成天愁眉苦脸…… – 所以要想写出好的需求文档,前提条件是把需求调查工作做好。 ‹ 开发人员写作能力比较差,虽然在调查过程中已经获得了不少需求信息,却写不出好的需求文档 来。 – 可以毫不夸张地说,国内90%以上的软件开发人员,他们的写作能力远不及开发能力。 – 提高开发人员写作能力的根本办法就是让他们多练习写文档,熟能生巧。 – 另外,企业应当提供合适的文档模板以及比较好的示例文档,尽可能地降低写作难度。 Page 19 1.6. 如何开展需求调查 1.6.1 准备调查 ‹ 首先,需求分析员应当起草需求调查问题表,将调查重点锁定在该问题表内,否则调查工作将变 得漫无边际。 – 问题表可以有多份,随着调查的深入,问题表将不断地被细化。 – 根据经验,用户通常没有耐心回答复杂的论述题,所以问题表应当以“选择题”和“是非题”为主。 – 制定问题表最简便的方法就是从《用户需求说明书》的模板中提取需求问题。 ‹ 其次,需求分析员应当确定需求调查的方式,例如: – 与用户交谈,向用户提问题。向用户群体发调查问卷。 – 参观用户的工作流程,观察用户的操作。 – 与同行、专家交谈,听取他们的意见。 – 分析已经存在的同类软件产品,提取需求。 – 从行业标准、规则中提取需求。 – 从Internet上搜查相关资料。 ‹ 最后,需求分析员与被调查者建立联系,确定调查的时间、地点、人员等,撰写需求调查计划。 要特别留意的是不要漏掉典型的用户。 Page 20 1.6. 如何开展需求调查 1.6.2 执行调查 ‹ 准备工作完毕后,需求分析员按照计划执行调查。在调查过程中随时记录(或存储) 需求信息 。 ‹ 需求分析员与用户面谈时应当注意以下事项: – 如果与用户约好了时间,切勿迟到或早退。要注意礼节,尽可能获得用户的好感,并为下 次打扰他们埋下伏笔。(船员穿衣服的故事) – 需求分析员应事先了解用户的身份、背景,以便随机应变。IT人士不可貌相,有些大企业 的领导其外表很土气,象农民。如果你路上碰到他,以为是个勤杂工,说:“喂,老师傅, 来帮我拎东西。”也许这笔生意就泡汤了。 – 需求调查不象侦探推理那样从蛛丝马迹着手,应该先了解宏观问题,再了解细节问题。 – 如果双方气氛融洽,可以采用灵活的访谈形式,轻易不要打断用户的谈话。当双方对某些 问题的交流合乎逻辑地结束后,即可继续讨论问题表中的其它问题。 – 尽可能避免为用户添麻烦,但也不能怕给用户添麻烦而降低需求调查的力度。 – 避免片面地听取某些用户的需求而忽视其它用户的需求。 Page 21 1.6. 如何开展需求调查 1.6.3 《用户需求说明书》与《需求规格说明书》的主要区别与联系 ‹ 前者主要采用自然语言(和应用域术语)来表达用户需求,其内容相对于后者而言比较粗略,不 够详细。 ‹ 后者是前者的细化,更多地采用计算机语言和图形符号来刻画需求,需求是软件系统设计的直接 依据。 ‹ 两者之间可能并不存在一一影射关系,因为软件开发商会根据产品发展战略、企业当前状况适当 地调整产品需求,例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《需求 规格说明书》来开发当前产品。 1.6.4 撰写《用户需求说明书》 Page 22 1.7. 如何进行需求分析 1.7.1 基本概念 ‹ 为了得到用户的金钱,企业不得不鼓吹:用户就是上帝,用户永远是正确的。 ‹ 谁都知道这不是真的。事实上,很多时候用户说不清楚需求、会说错需求或者提出一些无法实现 的需求。 ‹ 需求分析是指在需求开发过程中,对所获取的需求信息进行分析,及时排除错误和弥补不足,确 保需求文档正确地反映用户的真实意图。 ‹ 需求分析是需求开发过程中最费脑子的工作。分析方法大体有两类:“问答分析法”和“建模分析法 ”。后者技术性比较强,写出来有学术味,故大多数软件工程书籍都有论述。前者就是一些常识而 已,虽然写不成文章,但是简单易用(保你一学就会),很有实用价值。 ‹ “问答分析法”比较适合于用户需求调查阶段 ‹ “建模分析法”比较适合于产品需求定义阶段。 Page 23 1.7. 如何进行需求分析 1.7.2 问答分析方法 ‹ 问答分析方法很简单:刨根究底地问,如果问题都被解答了,那么需求也就分析清楚 了。一个人可以“自问自答”地分析需求,几个人分析需求则称为“研讨”。 ‹ 问答分析最重要的问题是:“是什么”和“为什么”。 – 每个需求都应当用陈述句说明“是什么”,如果“是什么”的内涵不够清晰,则应补充说明“不 是什么”。 – 如果“是什么”和“不是什么”并不是“理所当然”的,那么应当解释“为什么”,以便加深读者 的理解。 – 追究“是什么”和“为什么”的目的是获得正确、清楚的需求。 ‹ 其它常见的问题有: – 需求存在二义性吗? – 需求文档的上下文有矛盾吗? – 需求完备吗? – 需求是必要的吗? – 需求可实现吗? – 需求可验证吗? – 需求的优先级确定了吗? Page 24 1.7. 如何进行需求分析 1.7.3 建模分析法 ‹ 人们都有这样地感受:有些时候用语言描述某个问题特别费劲,而采用图形则使人一目了然,所 谓“一图低千言”就是这个道理。 ‹ 在需求开发过程中,对于某些类型的信息,用图形表示要比文本表示更加有效。所以将图形与文 本结合起来描述需求是很自然的方法。 ‹ 需求建模就是指用图形符号来表示、刻画需求。 ‹ 建模分析方法主要有两大类:“结构化分析法”和“面向对象分析法”。 ‹ 恰当地使用图形符号: – 现代建模工具如Rose有非常丰富的图形符号和文字标注,能很好地表达模型的细节。要注 意的是:在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化,将使开发人 员更难掌握,而且使图形文档更加杂乱。 – 世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描述。 在需求文档中,文字描述是第一重要的,建模主要是起分析、解释作用。建议将模型存放 在需求文档的附录中,便于正文引用。 Page 25 1.7. 如何进行需求分析 1.7.4 作出决策 ‹ 当需求从四面八方收集来后,需求的冲突在所难免。对于那些难以达成共识的需求而言,经常会 发生“公说公有理,婆说婆有理”的现象。那么需求分析员究竟应该听谁的呢? – 如果一群人对需求有争议,并不是谁声音最响就听谁的。根据生活经验,最保险的办法是 :先听官儿大的或者威望高的,如果大家的职位和威望都差不多,那么采用“少数服从大多 数”的原则。 – 如果一个产品可以卖给几类客户,但是各类客户都要求产品按照他们的喜好来开发。此时 对需求的决策应当以商业利益为导向, 即哪一类客户出钱最多就先满足他们的需求,以后 再做那些获利相对较少的需求。 – 当开发者想象中的产品与客户所提的需求有冲突时,一般应当尊重客户的观点。但是不要 陷入“客户总是对的”陷阱里,需求分析员应当纠正明显不合理的客户需求。如果产品很复 杂,双方都不太明白需求,此时最好请开发人员快速构造软件的原型,双方看着软件原型 再分析需求。 Page 26 1.8. 如何定义系统需求 1.8.1 规程 ‹ 第一步:细化并分析用户需求 – 需求分析员首先对《用户需求说明书》进行细化,对比较复杂的用户需求进行建模分析, 以帮助软件开发人员更好地理解需求。例如采用Rational 的Rose工具进行需求的建模分析 ,建模分析产生的文档可以作为《需求规格说明书》的附件。补充说明:建模分析的技术 难度比较高,需求分析员应当根据自身水平进行取舍。 ‹ 第二步:撰写需求规格说明书 – 需求分析员按照指定的文档模板撰写《需求规格说明书》。如果待开发的产品分为软件和 硬件两部分的话,则应当撰写《软件需求规格说明书》和《硬件需求规格说明书》。 ‹ 第三步:进行需求确认 – 项目经理邀请同行专家和用户(包括客户和最终用户)一起评审《需求规格说明书》,尽 最大努力使《需求规格说明书》能够正确无误地反映用户的真实意愿。 – 需求评审之后,开发方和客户方的责任人对《需求规格说明书》作书面承诺。 1.8.2 编写《需求规格说明书》 Page 27 2. 需求管理 2.1 需求确认(评审和承诺) ‹ 需求确认是指开发方和客户方共同对《需求规格说明书》进行评审,双方对需求达成共识后作出 承诺。需求确认包含两个重要工作:“需求评审”和“需求承诺”。 2.2 需求评审面临的困难 ‹ 需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味,也比较费脑子。刚开始评审时,大家都 比较认真,越到后头越马虎。 ‹ 需求评审涉及的人员可能比较多,有些时候让这么多人聚在一起花费比较长的时间开会并不容易 (例如有些人可能出差在外,有些人可能事务缠身)。没有必要把所有事情挤在一块做,需求开 发是循序渐进的过程,需求评审也可以分段进行。这样每次评审的时间比较短,参加评审的人员 也少一些,组织会议就比较容易。 ‹ 开评审会议时经常会“跑题”,导致评审效率很低。有时话匣子一打开后关不上,大家越扯越远, 结果评审会议变成了聊天会议。主持人应当控制话题,避免大家讨论与主题无关的东西。 ‹ 开评审会议时经常会发生争议。适当的争议有利于澄清问题,比什么东西都一致赞成要好。然而 当争议变为争吵时就坏事了,争吵不仅对评审工作没有好处,而且会无意中伤害同事们的感情。 ‹ 人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是 好办法。我们应当养成良好的习惯:不要一棍子打死异己的观点,尝试着让自己站在他人的立场 思考问题,这样你会找到比较满意的答案。 Page 28 2. 需求管理:确认、跟踪、变更控制 2.3 需求承诺 ‹ 需求承诺是指开发方和客户方的责任人对通过了正式技术评审的《需求规格说明书》作出承诺, 该承诺具有商业合同的效果。 ‹ 需求承诺的“八股文”如下: – 本《需求规格说明书》建立在双方对需求的共同理解基础之上,我同意后 续 的 开 发 工 作 根 据 该 《需求规格说明书》开展。如果需求发生变化,我们将按照“变更控制规程”执行。我 明白需求的变更将导致双方重新协商成本、资源和进度等。 – 甲方签字 乙方签字 ‹ 人们在作出承诺之前务必要认真阅读文档,一定要明白签字意味着什么。 Page 29 2. 需求管理:确认、跟踪、变更控制 2.4 需求跟踪 ‹ 需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性,确保所有的工作成果符 合用户需求。 ‹ 需求跟踪有两种方式: – 正向跟踪。检查《需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点 。 – 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《需求规格说明书》中 找到出处。 ‹ 正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式,都要建立与维护需求跟踪矩阵 (即表格)。需求跟踪矩阵保存了需求与后继工作成果的对应关系。 Page 30 2. 需求管理:确认、跟踪、变更控制 2.5 需求变更控制 ‹ 需求发生变更的起因主要有: – 随着项目的进展,人们(包括开发方和客户方)对需求的了解越来越深入。原先的需求文 档可能存在这样那样的错误或不足,因此要变更需求。 – 市场发生了变化,原先的需求文档可能跟不上当前的市场需求,因此要变更需求。 ‹ 提出需求变更的动机是好的,目的是希望产品更加符合用户的需求。对项目开发小组而言,变更 需求意味着要调整资源、重新分配任务、修改前期工作成果等,开发小组要为此付出较重的代价 。如果每次需求变更请求都被采纳的话,这个项目也许永远不能按时完成。 ‹ 需求变更控制的目的: 如果需求变更带来的好处大于坏处,那么允许变更,但必须按照已定义的 变更规程执行,以免变更失去控制。 如果需求变更带来的坏处大于好处,那么拒绝变更。 ‹ 需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方 是不敢得罪客户的,但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先 建立“游戏规则”: ‹ 如果事先没有“游戏规则”的话,开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新 版本时修改需求。 Page 31 3. 软件设计 3.1 基本概念 ‹ 设计师与程序员的地位。软件设计的技术难度要比编程、测试的高。所以程序员、测试员称为“员 ”,而设计师尊称为“师”。 ‹ 设计的好坏在根本上决定了软件的优劣。我们可以断言“差的系统设计必定产生差的软件系统”, 但是不能保证“好的系统设计必定产生好的软件系统”。因为在设计之前有需求开发工作,在设计 之后还有编程、测试和维护工作,无论哪个环节出了差错,都会把好事搞砸了。 – 据说上帝把所有的女士都设计成天使,可是天使们在下凡的时候,有些人双脚先着地,有 些人脸先着地。上帝的这一疏忽让很多女士伤透了心。所以我们在开发软件时,一定要吸 取这个教训。 ‹ 软件设计之源是软件需求,包括“功能性需求”与“非功能性需求”。设计的目标就是使所设计的系 统能够被开发方顺利地实现,并且恰如其分地满足用户的需求,使开发方和用户的利益极大化。 开发人员千万不能偏离需求,为了追求技术的先进性而开展系统设计工作。 ‹ 依据“分而治之”的思想,我们把系统设计过程划分为两个阶段:高层设计阶段和详细设计阶段。 高层设计阶段的重点是系统结构设计。详细设计阶段的重点是用户界面设计、数据库设计、模块 设计、数据结构与算法设计等。 ‹ 著名3D游戏软件Quake设计师Michael Abrash 的总结:“所有真正杰出的设计一旦被设计好,看起 来都是那么的简单和显而易见。但是在获得杰出设计的过程中,需要付出令人难以置信的努力。” Page 32 3. 软件设计 3.1.1 技术解决(TS)结构图-设计1 Alternative Designs and Evaluation Criteria Developed Product Select Product- Component Solutions Develop the Design 设计 Implement the Product Design Design Detail & Documentation Requirements Development TS: Technical Solution Page 33 Design the Product or Product- Component 设计产品或 产品构件 Develop the Design设计 Establish a Tech Data Package 创建技术 数据包 Tech Data Package Design Interfaces Using Criteria 设计接口 Design Documentation Specification Control Documents Perform Make, Buy, or Reuse Analyses 执行制造、 购买或重用分析 Product Architecture Product Component Designs Selection Criteria Make/Buy Analysis RD PI 3. 软件设计 3.1.2 技术解决(TS)结构图-设计2 Page 34 3. 软件设计 系统设计过程示意图 3.1.3 系统设计过程示意图 Page 35 3. 软件设计 3.1.4 软件系统与人体的比喻 ‹ 体系结构如同人的骨架。如果某个家伙的骨架是猴子,那么无论怎样喂养和美容,这家伙始终都 是猴子,不会成为人。人的身材大小取决于骨架大小,天生小个子的人基本上不可能成为威猛的 大汉,后天再努力(例如锻炼和吃喝)也白搭。由此可见,体系结构乃是系统设计的重中之重。 ‹ 用户界面如同人的外表,最容易让人一见钟情或一见恶心。象人类追求心灵美和外表美那样,软 件系统也追求(内在的)功能强大和(外表的)界面友好。我们在设计软件时不要沉迷于技术, 而要多多思考什么样的界面才能让用户更加喜欢。 ‹ 数据库是存储和处理数据用的。人体的数据库是大脑,知识相当于数据,全存在大脑里。如果脑 子里存储的知识很多,那么这个人就显得博学。如果脑子处理知识的速度很高,那么这个人就显 得聪明。数据库设计的主要挑战是“高速处理大容量的数据”。 ‹ 模块如同人的器官。每个器官都具有特定的功能,器官们依附在骨架上。模块是软件系统的部件 ,它们安插在体系结构上(否则运行起来掉光光了)。在设计模块时要重视功能独立性,还要追 求“高内聚、低耦合” 。 ‹ 数据结构与算法如同人的神经和肌肉,它分布在全身,让器官具有生命并能发挥功能。人之所以 能够全身运动,那是无数的神经和肌肉在起作用。如果局部的神经和肌肉失效了,那么会导致对 应的器官残废。如果全局的神经和肌肉失效了,那么人就瘫痪了。同理,数据结构与算法也有全 局和局部之分,都要慎重设计。 Page 36 3. 软件设计 3.1.5 漫谈设计模式 ‹ 20世纪90年代,面向对象(Object-Oriented)方法与技术在国内软件业界十分火爆,人们热衷于 谈论“对象”并引以为荣。十多年来,人们发表、出版了无数的文章和书籍。现在,该写的似乎都 写完了,没有新花样玩了,真是一片无聊。设计模式(Design Pattern)及时问世,面向对象爱好 者们终于有了新的追求。 ‹ 1995年,Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides(戏称“四人帮”)出版了Design Patterns: Elements of Reusable Object-Oriented Software,该书的中译本已于2000年出版 . ‹ “四人帮”这本书的主要贡献是:确立了设计模式 这 个 术 语 , 创 导 了 一 种 新 的 面 向 对 象 设 计 思 潮。 该书出版后,全世界参与设计模式研究的人数呈爆炸性地增长。该书的负面效应是:这本书 深奥 无比,读者被分成两类 , 即“看得懂设计模式的”和“看不懂设计模式的”,后者居多。很多人刚 入 门时就被吓住了,知难而退。 ‹ 何为“模式”和“设计模式”?模式描述了在我们周围不断重复发生的问题,以及该 问 题 的 解 决 方 案 的核心,这样你就能一次又一次地使用该解决方案而不必重复劳动。 ‹ 模式就是一种公式化的表现,究竟公式化是不是好事?(蔡学庸精辟的解释) ‹ 尽管软件技术发展非常快,但是仍然有非常多的设计模式可以让我们套用,包括体系结构模式、 数据结构模式、接口模式等。 ‹ 小结:设计模式的应用价值在于它能帮助人们简便地复用以前成功的设计方案。设计模式不是凭 空产生的,只有对应用域问题及其解决方案进行抽象和分析,发现本质,并按照一定的格式记录 下来,才能成为可以被人们复用的设计模式。 Page 37 3. 软件设计 3.2 体系结构设计原则 ‹ 中国科学院的杨叔子院子如是言: – 文学中有科学,音乐中有数学,漫画中有现代数学 的 拓 扑 学 。 漫 画 家 可 以“几笔”就把一 个 人画出来,不管怎么美化或丑化,就是活像。为什 么 ? 因 为 那“几笔”不是别的,而是拓扑 学中的特征不变量,这是事物最本质的东西。 – 体系结构是指软件系统的基本和主体的形态,也就是软件系统中“最本质”的东西。一个软 件系统的体系结构设计得好不好,可以用“合适性、结构稳定性、可扩展性、可复用性”这 些特征量来评估。 ‹ 合适性:即体系结构是否适合于软件的“功能性需求”和“非功能性需求”。 ‹ 结构稳定性:高水平的设计师应当能够分析需求文档,判断出哪些需求是稳定不变的,哪些需 求是可能变动的。于是根据那些稳定不变的需求设计体系结构,而根据那些可变的需求设计软件 的“可扩展性”。 ‹ 可扩展性:可扩展性是指软件扩展新功能的容易程度。可扩展性越好,表示软件适应“变化”的 能力越强。 ‹ 可复用性 :可复用性是设计出来的,而不是偶然碰到的。要使体系结构具有良好的可复用性, 设计师应当分析应用域的共性问题,然后设计出一种通用的体系结构模式,这样的体系结构才可 以被复用。 Page 38 3.2.1 体系结构设计流程 ‹ 体系结构设计流程:6个步骤 3. 软件设计 Page 39 3.2.2 层次结构介绍 ‹ 层次结构是最常见的体系结构模式,它体现了“分而治之”的思想:当我们没法一口气解决复杂的 原始问题时,就把该问题切割成许多个小的相对简单的问题,然后逐个解决。水平方向切割产生 的层称为Layer,而竖直方向切割产生的层称为Tier。 ‹ 层次结构在人类社会里随处可见。有个村长曾得意地向老婆吹牛:“全中国只有四个人比我的官儿 大,乡长、县长、省长和国务院总理”。政府的行政结构应当划分为多个Layer和Tier。如果Layer 和Tier的数目太少了,那么各级政府的领导人会非常劳累。反之如果Layer和Tier的数目太多了 ,那么导致政府机构太臃肿,办公效率极低。 ‹ 古代中国文人的学历大体分为两层:秀才和举人。这种划分太粗了(即Layer数目太少),对发 展教育是很不利的。很多老百姓读不起几年书,拿不到秀才毕业证书的人就被归类为文盲,不幸 成为社会下层人物。虽然社会上的秀才人数也不少,但是从秀才到举人的跨度太大、门槛太高, 很多秀才考举人考了一辈子也考不上。 – 典型的例子是《儒林外史》里的范进,范进在青年时期就成为秀才,可惜他考举人考了几 十年!等他碰巧考上举人的时候,已经是个老头了,只给朝廷增加负担而没有贡献。后人 吸取了经验教训,于是逐步建立了现代的学历层次结构,将学历划分为5个层次:小学、中 学、学士、硕士、博士。这样人们读书的选择面广了,工作面也广了。 ‹ “层次结构”是应用最为广泛的体系结构模式。其最大的优点是具有良好的可扩展性,人们在扩充 或修改功能时,基本不会破坏原有结构的稳定性。但是万事有利必有弊,层次结构的系统的主要 缺点是:管理多个Layer和Tier比较麻烦,运行效率可能比较低。所以,一个具备良好层次结构 的系统,其Layer和Tier的数目要恰如其分。 3. 软件设计 Page 40 3.3 用户界面设计 3.3.1 什么是好的用户界面 ‹ 通俗地讲,用户界面“好不好”主要看它是否“容易使用”和“美观”。 ‹ 易用性是指用户使用软件的容易程度。现代人的生活节奏快,干啥事都想图个方便。谁都不乐意 掏钱买很难用的东西,所以把易用性作为用户界面的重要属性对待无可非议。 ‹ 除了要求软件易用之外,人们还希望用户界面美观。电影《食神》里的一段精彩故事情节可以帮 助我们理解界面美观的重要性。 ‹ 美观的界面能消除用户由感觉引起的乏味、紧张和疲劳(情绪低落),大大提高用户的工作效率 ,从而进一步为发挥用户技能和为用户完成任务作出贡献。人们对美的向往和追求是与生俱有的 。显然没有开发人员愿意丑化自己的软件,也没有用户嗜好丑陋的界面。软件开发者要设计美, 用户要享受美,所以界面的美是开发者与用户的共同需求。 ‹ 全世界无数人使用Microsoft公司的操作系统DOS, Windows 3.1, Windows 9x, Windows 2000和 Windows XP,这些操作系统的确是越来越好用了,并且越来越漂亮了。界面的“易用性”和“美”充 分体现了人机交互作用中人的特性与意图,越来越多的用户将通过具有吸引力而令人愉快的人机 界面与计算机打交道。 3. 软件设计 Page 41 3.3.2 开发人员的能力缺陷 ‹ 尽管国内有很多技术出色、聪明过人的软件开发人员,但是他们未必开发得出“易用”的和“美观” 的软件。主要原因有: – 国内绝大多数大学的计算机学科教育存在缺陷:没有开设人机工程学、美学、心理学这些 必修课。由于学生们接受的教育几乎全是科学与技术,他们根本不知道怎样才能设计出易 用、美观的用户界面,很多人甚至想都没有想过。当他们毕业后真正参与软件产品开发时 ,只好凭着个人的经验与感觉设计软件的用户界面,这样产生的界面往往得不到大众用户 的认可。 – 开发人员在设计用户界面方面不仅存在先天的教育缺陷,更加糟糕的是还常常犯“错位”的 毛病,即他以为只要自己感觉用户界面漂亮、使用起来方便,那么用户也一定会满意。俗 话说“王婆卖瓜,自卖自夸”。当开发人员向用户展示软件时,常会得意地讲:“这个软件非 常好用,我操作给你看,……是很好用吧!蛮漂亮的吧!” ‹ 软件是否易用、是否美观要让用户来评价。如果用户对界面很不满意,开发人员不要有逆反心里“ 到哪里找来的笨蛋!”。其实不是用户笨,是自己开发的软件太笨了。当用户真的感到软件很好用 时,一股温暖的感觉油然而生,于是就用“界面友好”来表扬这个软件。 3. 软件设计 Page 42 3.3.3 用户界面设计原则(11个) ‹ 用于提高易用性的界面设计原则有8个: – 用户界面适合于软件的功能 – 容易理解 – 风格一致 – 及时反馈信息 – 出错处理 – 适应各种用户 – 国际化 – 个性化 – 最短路径,最少操作 (操作的最高效率) ‹ 用于提高美观程度的设计原则有: – 合理的布局 – 和谐的色彩 3. 软件设计 Page 43 3.3.4 用户界面设计流程 3. 软件设计 Page 44 3.4.1 概念 ‹ 首先要搞清楚容易混淆的两个概念:“数据库系统”和“应用软件的数据库”。 – 数据库系统是指数据库厂商提供的数据库服务器,目前著名的大型数据库系统有Oracle、 DB2、Informix、Sybase,中型数据库系统如Microsoft SQL Server。 – 而应用软件的数据库则是指开发者在数据库系统中创建的库,用于存储应用软件的数据。 一般地,人们可以从上下文判断“数据库”究竟是指哪一个? ‹ 简而言之,数据库是存储和处理数据用的。数据库设计的主要工作是: – (1)设计数据库的表(数据就存在表里面),表的结构就是数据的存储结构。 – (2)对这些表中的数据进行操作,常见操作如查询、插入、修改、删除等。 ‹ 数据库设计的难易程度取决于两个要素:“数据关系的复杂程度”和“数据量的大小”。如果应用软 件只涉及几张简单的表,并且数据量特别小,那么设计这样的数据库就非常容易(例如设计一个 班级的学生成绩单数据库)。但是你绝对不能盲目乐观:以为所有的数据库设计都是那么简单。 – 从前有个财主姓万,他请了一个秀才教儿子写字。 … – 软件开发人员学习数据库设计的特点是:入门很容易,但是成为高手非常难。大家千万不 要学万公子写字噢。 3.4 数据库设计 3. 软件设计 Page 45 3.4.2 数据库设计流程 ‹ 数据库设计一般要经历“逻辑设计—>物理设计->安全性设计->性能优化”等步骤,通常要迭代进 行。 3. 软件设计 Page 46 3.5.1 何为“模块”与“模块化” ‹ 对于软件而言,我们习惯从功能角度描述模块。所以模块泛指软件系统的功能部件。在软件的体 系结构设计完成之际,我们就已经确定了所有模块的功能,并且把模块们安放在体系结构的恰当 位置上。 ‹ 每个模块都具有特定的、明确的功能(否则不能成为模块)。人们在设计模块时应当尽量使模块 的功能独立,因为功能独立的模块可以降低开发、测试、维护的代价。但是功能独立并不意味着 模块是绝对孤立的。所有的模块应当能够被集成为一个系统,所以模块之间必定要交流信息、相 互配合。 ‹ 比如手和脚是两个“功能独立”的模块。没有脚时,手照样能干活。没有手时,脚仍可以走路。但 如果想让人跑得快,那么迈左脚时一定要伸右臂甩左臂,迈右脚时则要伸左臂甩右臂。所以在设 计模块时不仅要考虑“这个模块应当有什么样的功能”,还要考虑“这个模块应该怎样与其它模块 交流信息”。 ‹ “模块化”(Modularization)是指:将系统分解为一系列功能模块,然后逐一实现 这 些 模 块 , 最 后把所有的模块集成为原来的系统。这样做的好处是能够大大降低系统的开发难度。 ‹ 是否将系统分解得非常细、得到的功能模块越多越好呢?不是的。虽然这样做可以使实现模块的 代价更低,但是把功能模块集成为原来系统的代价却增大了很多,得不偿失,所以一个系统的模 块数量不能过多也不能过少。那么多少算是恰如其分呢?不知道,要靠设计师的判断。 3.5 模块设计 3. 软件设计 Page 47 3.5.2 模块设计原则 ‹ 信息隐藏 – 在一节不和谐的课堂里,老师叹气道:“要是坐在后排聊天的同学能象中间打牌的同学那么 安静,就不会影响到前排睡觉的同学。” – 这个故事告诉我们,如果不想让坏事传播开来,就应该把坏事隐藏起来,家丑不可外扬就 是这个道理。为了尽量避免某个模块的行为干扰同一系统中的其它模块,在设计模块时就 要注意信息隐藏。应该让模块仅仅公开必须要让外界知道的东西,而隐藏其它一切内容。 – 接口设计是模块设计的核心工作之一,体现了信息隐藏这一原则。接口是模块的外部特征 ,应当公开;而数据结构、算法、实现体等则是模块的内部特征,应当隐藏。 ‹ 高内聚 – 内聚(Cohesion)是一个模块内部各成分之间相关联程度的度量。文献[Pressman99, p249] 归纳了7种内聚类型,绘制了模块的“内聚谱系”,内聚程度从低到高大致划分为低端 、中段和高端。模块设计者没有必要确定内聚的精确级别,重要的是尽量争取高内聚,避 免低内聚。 ‹ 低耦合 – 耦合(Coupling)是模块之间依赖程度的度量。内聚和耦合是密切相关的,与其它模块存 在强耦合的模块通常意味着弱内聚,而强内聚的模块通常意味着与其它模块之间存在弱耦 合。 – 模块设计应当争取“高内聚、低耦合”,而避免“低内聚、高耦合”。 3. 软件设计 Page 48 3.5.3 模块设计流程 ‹ 模块设计的核心工作是“接口设计”和“数据结构与算法设计”。前者是模块的外部特征,应当公开 ,而后者是模块的内部特征,应当隐藏。 ‹ 模块设计属于系统设计的详细设计阶段,那么模块设计应当详细到什么程度? – 由于现代的软件开发工具越来越先进,模块的详细设计和编程可以很好地融合一起,而且 效率相当高,有些开发工具甚至具有代码自动生成的功能。所以模块设计究竟要详细到什 么地步,应当视问题复杂性以及所采用的开发工具而定。 – 一般地,只要确定了每个模块的主要接口、数据结构与算法,能够清楚地指导模块编程即 可。总之,不必花太多时间用于设计模块的细节。 3. 软件设计 Page 49 3.6.1观点 ‹ 学会设计数据结构与算法,可以让我们编写出高效率的程序。也许有人要问,在计算机速度日新 月异的今天,为什么还需要高效率的程序?因为我们的雄心与能力是一起增长的,技术进步最快 也快不过人们欲望的增长。计算速度和存储容量上的革新仅仅提供了处理更复杂问题的有效工具 ,所以高效率的程序永远不会过时。 ‹ 设计高效率的程序是基于良好的数据结构与算法,而不是基于编程小技巧。因此,大学里计算机 科学(或工程)系都把“数据结构与算法设计”作为本科生的必修课程。 3.6 数据结构与算法设计 3. 软件设计 Page 50 3.6.2 设计理念 ‹ 每一种数据结构与算法都有其时间、空间的开销和收益。当面临一个新的设计问题时,设计者要 彻底地掌握怎样权衡时空开销和算法有效性的方法。这就需要懂得算法分析的原理,而且还需要 了解所使用的物理介质的特性(例如数据存储在磁盘上与存储在内存中,就有不同的考虑)。 ‹ 与开销和收益有关的是时间——空间的权衡。通常可以用更大的时间开销来换取空间的收益,反 之亦然。时间——空间的权衡普遍地存在于软件开发的各个阶段中。 ‹ 程序员应该充分地了解一些常用的数据结构与算法,避免不必要的重复设计工作。 ‹ 数据结构与算法为应用服务。我们必须先了解应用的需求,再寻找或设计与实际应用相匹配的数 据结构。 3.6.3 一般流程 ‹ 数据结构与算法有全局和局部之分,先设计全局的,后设计局部的(通常在模块设计时进行)。 ‹ 根据问题的特征,先查找已经存在的数据结构与算法,挑选最合适的(并不一定是最先进的)。 如果不存在现成的,那么自己设计。 ‹ 设计并且编写代码之后要进行测试,如果不满足性能要求,那么要进一步优化数据结构和算法。 3. 软件设计 Page 51 4. 软件实现 4.1 概念 ‹ 软件实现(Software Implementation)不等同于纯粹的编程,它是“编程、内部测试、代码审查 、调试改错、优化”的综合表述。软件实现是人员最多、时间最长、工作量最大的开发阶段。 ‹ 对于现代软件开发而言,超级程序员不再是法宝了。正是因为软件实现阶段“人多、活儿多、问题 更多”,天生就有混乱倾向,因此必须制定软件实现的规范,让所有人员都按照规范执行,才可能 顺利地完成任务。 Alternative Designs and Evaluation Criteria Developed Product Select Product- Component Solutions 选择构件解决方案 Develop the Design 设计 Implement the Product Design 实现 Design Detail & Documentation Requirements Development Page 52 Parts Fabricated Software Coded Data Documented Processes Documented Facilities Constructed Implement the Design 实现设计 Implement the Product Design 实现产品设计 Develop Product Support Documentation 建立产品支 持文档 End-User Training Materials User’s Manual Operator’s Manual Maintenance Manual Online Help 4.1.1 技术解决(TS)结构图 4. 软件实现 Page 53 4. 软件实现 4.1.2 流程图 Page 54 4.2.1 准备什么 ‹ 开发小组制定计划(包括编程计划、代码审查计划、测试计划等),项目经理审批该计划。 ‹ 开发小组确定编程、代码审查、内部测试等规范。如果机构已经存在相应的规范,则采用之。如 果机构不存在相应的规范,则由开发小组制定。 ‹ 开发小组构建编程与测试环境,例如安装软件开发工具(包括可复用库)、配置管理工具、软件 测试工具和缺陷跟踪工具等等。如果是异地开发和测试,那么要构建Internet环境。 ‹ 如果开发组长认为开发小组需要接受编程、测试、代码审查等方面的培训,那么由开发组长安排 相应的培训。 4.2.2 制定计划 ‹ 软件实现阶段的一些计划中,编程计划最重要,是主线,代码审查计划和测试计划可以根据编程 计划推演出来。这些计划可以合并成一个《软件实现计划》,当然也可以分开写。 ‹ 编程计划应当根据产品的功能特征和开发人员的技能来制定。 – 假设一个系统由N个模块组成,每个模块又分前台和后台两部分。有些人可能擅长开发前 台程序,有些人可能擅长开发后台程序,还有些人对前台和后台程序的熟练程度差不多。 开发组长要充分了解组员的技能优缺点,让他们扬长避短,而不是平均分配任务。 4.2 软件实现的准备工作 4. 软件实现 Page 55 4.2.3 制定编程规范 ‹ 如果没有统一的编程规范,放任程序员按照自己的风格编程的话,那么代码风格将五花八门,可 能潜伏许多Bug,即使没有Bug也让别人难以理解。 ‹ 编程规范的主要用途是统一编程风格、提高代码质量,是给已经懂得编程的人用的,所以不要把 编程规范写成入门教科书。 – Internet上有许多公开的C++、Java编程规范,人们根据企业的需求适当裁剪就可以了,不 必彻头彻尾地自己撰写。 ‹ 一般地,编程规范应当覆盖以下主题: – 文件版式、命名规则、 – 基本语句、函数设计、 – 内存管理、错误处理 等等 ‹ 通常每个主题都有若干的规则、建议和示例,其中“规则”是必须要遵守的,“建议”不是强制的但 是推荐采用的,“示例”用来解释“规则”和“建议”。 ‹ 公司制定编程规范后,应当马上组织程序员们学习,促使大家按照该规范编写应用程序,逐步形 成统一的风格。千万不可让编程规范成为一种摆设。 4. 软件实现 Page 56 4.2.4 技术预研 ‹ 在软件开发过程中,技术问题可能会层出不穷。如果一点技术障碍都没有遇到,要么是开发人员 的技术水平实在太高了,要么是项目的技术含量实在太低了,这类情况比较少见。 ‹ 一般说来,在遭遇到了技术障碍之后才匆忙地去攻克问题,其代价通常比较高。因为其他人的工 作可能会被阻塞,已经投入的不少资源将被闲置。 – 最糟糕的是,如果此技术障碍无法攻克,不得已要改变技术方案、重新设计系统的话,那 么不仅浪费了人力、财力、时间,处理不好还会使开发队伍陷入混乱状态。 ‹ 技术预研是指对项目将采用的关键技术提前学习和研究,以便尽可能早地发现并解决开发过程中 将会遇到的技术障碍。 ‹ 技术预研不同于真正地开发产品,投入人员与时间相对比较少,主要步骤如下: – 项目经理或技术负责人识别项目中的技术难题,指定技术人员攻克该问题。 – 技术攻关人员制定简要的计划,设定技术预研的内容和目标,预计应递交的工作成果,制 定进度表。 – 按照计划进行技术攻关。在任务结束时,技术攻关人员撰写《技术攻关报告》,并向相关 人员介绍工作成果。 4. 软件实现 Page 57 4.3.1 尽可能采用成熟可靠的技术 ‹ 人们开发软件是为了满足客户的需求,而不是自己闹着玩或者追求技术挑战。为了提高质量、提 高开发效率并且降低成本,我们应当尽可能采用成熟可靠的技术来开发软件。 ‹ 软件复用体现了这种思想,正被越来越多的企业倡导。据统计,世上已有一千多亿行程序,无数 功能被重写了成千上万次,真是浪费啊!面向对象学者呼吁“请不要再发明相同的车轮子了”。 ‹ 不要急于从零开始编程,应当先调查是否有现成的程序库可以使用(可能要花钱去买也可能是免 费的)?除非是没有现成的程序或者现成的程序不符合应用要求,我们再自己编写程序,这样省 时省力,何乐而不为呢? ‹ 在编程的时候尽量少用技巧。 – 技巧的优点在于能另辟蹊径地解决一些问题,缺点是技巧并不为人熟知。 – 若在程序中使用太多的技巧,可能会留下错误隐患,别人也难以理解。 – 一个局部的优点对整个系统而言是微小的,而一个错误则可能对整个系统是致命的。 – 因此建议用自然的方式编程,不要滥用技巧。 4.3 对编程的建议 4. 软件实现 Page 58 4.3.2 对所有代码进行单步跟踪调试 ‹ 大多数程序员有这样的习惯,如果程序通过了编译和连接,他就认为程序基本上没有问题了,就 交给别人测试,等到别人发现Bug后自己才去调试改错。 ‹ Steve Maguire在其著作《Writing Clean Code》中极力提倡程序员应当养成“对代码进行单步跟踪调 试”的习惯。 – 即当程序员编写完成一个和几个相关程序之后,不必等别人测试,自己马上对代码进行单 步跟踪调试。 – 单步跟踪调试能够发现数据溢出、内存泄漏、野指针等仅靠黑盒测试难以察觉的Bug,无 疑大大地提高了程序的质量和开发、测试效率。 ‹ 但遗憾的是,大多数程序员觉得“单步跟踪调试”太花费时间,不值得这样做。 – 理由是:程序中正确的代码远比错误的代码多,单步跟踪调试简直就是大海捞针,还不如 等别人发现Bug后再改错来得方便。 ‹ 假设我们设计和编写200行C++代码要花费一天时间(8小时),那么对这200行代码进行单步跟踪 调试大约会花费10分钟。这10分钟的单步跟踪调试不会让我们很劳累,它带来的好处是: – (1)减少了后继的测试和改错代价(远远不止10分钟的工作量); – (2)让你对自己的程序更有信心,不再为未知的Bug提心吊胆,日子过得更加快乐。 ‹ 所以程序员朋友们,不要拒绝单步跟踪调试了。 4. 软件实现 Page 59 4.3.3 及时写编程日记 ‹ 随时随地记录你在工作中遇到的问题,以及你产生的灵感。不要等到将来再靠回忆来写总结,那 时候你可能想不起来了,岂非浪费了一笔“财富”? ‹ 程序员每天应该写一份简短的工作日记,花几分钟就行了。 – 很多程序员觉得他们的光荣任务就是开发软件,写工作日记很费时间很烦人。 – 整个团队都写工作日记不仅对个人有好处,而且有利于项目的管理。如果这些工作日记保 存在数据库里,那么管理者会对各人的工作进展一目了然。 – 如果大家还没有写工作日记的习惯,项目经理就强迫大家写,用不了几天就习惯了。 4.3.4 对代码进行配置管理 ‹ 曾经有一个很好的配置管理工具在我面前,我没有理睬,直到版本混乱的时候才后悔莫及,工作 中最大的痛苦莫过于此,如果上天再给我一次机会的话,我向对它说三个字:我要你。如果非得 加一个期限的话,我希望是一辈子。 ——配置管理忏悔录 ‹ 人们每天将产生许多代码,而且会不断地修改代码。如果不使用配置管理工具对源代码进行版本 管理的话,人们在同一个文件上修改程序,保存之后,那么新的程序覆盖了老的程序。如果发现 新程序是错误的,而老程序却是对的,可是老程序被新程序覆盖了,再也无法恢复。怎么办呢? 只好重新写老程序再覆盖新程序,这种做法是很落后的。程序员不对源代码进行版本管理那是自 寻烦恼。 4. 软件实现 Page 60 4.3.5 正常作息 ‹ 编程和调试有这样的特点,干活要一鼓作气完成,不要中途停下来做其它事情之后再接着编程调 试,否则思路丢失,重新捡起来很费劲。所以程序员经常在夜里干活,这样效率比较高。 – 据说真正的程序员不会在上午9:00到下午5:00之间工作,如果你看到他在上午9:00工作, 这表明他从昨晚一直干到现在。 ‹ 只要你是程序员,总是有写不完的程序,抓不尽的Bug,就让我们以平常心对待程序和Bug,过正 常人的生活吧。 4. 软件实现 Page 61 4.4.1 内部测试 ‹ 一般地,软件实现阶段的单元测试和集成测试都在开发小组内部开展,因为这样效率最高并且节 约人力资源。 – 对于严格系统,开发人员编写完成某个程序之后,先进行单步跟踪调试,然后请同伴进行 代码审查和内部测试。 – 对于非严格系统,那么代码审查和内部测试的力度可以适当减弱一些。 – 如果发现缺陷,则记录在缺陷跟踪工具中,开发者应当及时修正程序,消除缺陷。 4.4.2 代码审查 ‹ 代码审查通常在开发人员之间开展,用眼睛检查代码是否符合编程规范。为什么有了软件测试, 还要代码审查呢? ‹ 因为代码审查有一些独到的优点,可以弥补软件测试的不足: – (1)软件测试不能发现代码风格不统一的问题,而代码审查则很容易做到; – (2)有经验的人可以一目十行地审查代码,很快就能抓住一些Bug(主要是常见的Bug)。 ‹ 开发小组在执行代码审查之前要制定“代码审查表”,从编程规范中提取最重要的规则。 ‹ 为了提高代码审查效率,检查者不必给每一个检查项填写结论,凡是正确的就跳过去,仅仅记录 缺陷就行了。 4.4内部测试与代码审查 4. 软件实现 Page 62 4.5.1 主动 ‹ 改错是个大悲大喜的过程,一天之内可以让人在悲伤的低谷和喜悦的颠峰之间跌荡起伏。 ‹ 软件中的错误通常只有开发者自己才能找出并改掉。如果因畏惧而拖延,会让你终日心情不定, 食无味,睡不香。所以长痛不如短痛,要集中精力对付错误 4.5.2 对症下药 ‹ 改错的第一步是找出错误的根源,如同医生治病,必须先找出病因才能“对症下药”。改错过程很 像侦破案件,我们必须从结果出发,逆向思考。一旦找到了根源,我们就知道如何改正了。 ‹ 根据软件错误的症状推断出根源并不是件容易的事,因为: – 症状和根源可能相隔很远 – 症状可能在另一个错误被纠正后暂时性消失 – 症状可能并不是由某个程序错误直接引发的,如误差累积。 – 症状可能时隐时现,如内存泄漏。 – 很难重新产生完全一样的输入条件,难以恢复“错误的现场”。 – 症状可能分布在许多不同的任务中,难以跟踪。 ‹ 人们把寻找错误根源的过程称为调试(debugging)。 4.5 调试改错的方法 4. 软件实现 Page 63 4.5.3 “神奇”的硬件调试改错方法 ‹ 据说硬件调试改错继承了中医的“望闻听切”诊断方法: – (1)望,即用眼睛查看哪些地方是否有破损。 – (2)闻,即用鼻子闻哪些地方是否有烧焦的味道。 – (3)听,即用耳朵听哪些地方是否有异常的噪声。 – (4)切,即用手触摸哪些地方是否异常发烫。 ‹ 据有经验的电器修理工说,“望闻听切”这4招能解决大部分问题。 4.5.4 软件调试 ‹ 软件调试的基本方法是“粗分细找”。 – 对于隐藏得很深的Bug,我们应该运用归纳、推理、“二分”等方法先“快速、粗略”地确定错 误根源的范围,然后再用调试工具仔细地跟踪此范围的源代码。 – 如果没有调试工具,那么只好用“土办法”:在程序中插入打印语句如printf(…),观看屏 幕的输出。 ‹ 有些时候,世界上最好的调试工具恐怕是那些有经验的人。我们经常会长时间地追踪某个Bug, 苦恼万分。恰好有高手路过,被他一语“道破天机”,顿时沮丧的阴云就被驱散。(故事…) ‹ 通常软件改错要比硬件改错的代价低得多,因为后者经常抛弃原来的东西。(故事…) 4. 软件实现 Page 64 4.5.5 修改代码错误的注意事项 ‹ 找到错误的代码时,不要急于修改,先思考一下:修改此代码会不会引发其它问题?如果没有问 题,可以放心修改。如果有问题,那么可能要改动程序结构,而不止一行代码。 ‹ 有些时候,软件中可能潜伏同一类型的许多错误(例如由不良的编程习惯引起的)。好不容易逮 住一个,应当乘胜追击,全部歼灭。 ‹ 在改错之后一定要马上进行回归测试,以免引入新的错误。改了一个程序错误固然是喜事,但要 防止乐极生悲。 – 更加严格的要求是:不论原先程序是否绝对正确,只要对此程序作过改动(哪怕是微不足 道的),都要进行回归测试。 ‹ 上述事情做完后,应当好好反思:我为什么会犯这样的错误?怎么能够防止下次不犯相似的错误 ?最好能写下心得体会,与他人共享经验教训。 4. 软件实现 Page 65 4.6.1 优化 ‹ 软件的优化是指优化软件的各个质量属性,如提高运行速度,提高对内存资源的利用率,使用户 界面更加友好等等。 ‹ 想做好优化工作,首先要让开发人员都有正确的认识:优化工作不是可有可无的事情,而是 必须 要做的事情。当优化工作成为一种责任时,开发人员才会不断改进软件中的数据结构、算法和程 序,从而提高软件质量。 ‹ 优化工作的复杂之处是很多目标之间存在千丝万缕的关系,可谓数不清理还乱。当不能够使所有 的目标都得到优化时,就需要“折衷”。 ‹ “折衷”是指协调各个质量属性,实现整体质量的最优。 – 软件折衷的重要原则是不能使某一方损失关键的功能,更不可以像“舍鱼而取熊掌”那样抛 弃一方。 – 人都有惰性,如果允许滥用折衷的话,那么一旦碰到困难,人们就会用拆东墙补西墙的方 式去折衷,不再下苦功去做有意义的优化。 – 折衷原则:在保证其他质量属性不差的前提下,使某些重要质量属性变得更好。 4.6完善性工作 4. 软件实现 Page 66 4.6.2 写文档 ‹ 程序员们愿意为编程而熬夜,但我几乎没有见过哪个程序员为写文档而通宵达旦。编程工作结束 后,程序员至少要撰写一些重要的文档。 ‹ 补写或修改需求和设计文档。随着开发的深入,人们必定会修改许多细节,因此要修改以前的文 档。不少开发小组因进度压力大,以前压根就没有时间写需求、设计文档,编程结束后亡羊补牢 总比不补要好。 ‹ 总结编程、测试、改错的经验教训,可以写出不少专题报告,积累知识财富。如果平时有写工作 日记的习惯的话,那么大家可以从工作日记中提取经验教训(这是写工作日记的好处),否则只 好靠回忆了。 ‹ 项目经理要有优化软件、写文档的强烈意识,然后监督组员们执行,才能把完善性工作做好。 4. 软件实现 Page 67 Prepare for Product Integration 产品集成准备 Ensure Interface Compatibility 确保接口兼容 Assemblies Sub-assemblies产品组件组装 Assemble Product Components and Deliver the Product 产品组装和交付 Technical Solution DAR 5. 产品交付 5.1产品集成(PI)结构图 PI: Product Integration Page 68 - Integration Sequence 集成序列 - Integration Procedures and Criteria 集成规程和准则 - Integration Environment 集成环境 Prepare for Product Integration 产品集成准备 DAR Technical Solution Determine Integration Sequence 建立集成规程 Establish Product Integration Procedures and Criteria 建立和维护 组件的集成序列 Establish the Product Integration Environment 建立产品集成环境 5.1.1产品集成准备 5. 产品交付 Page 69 Ensure Interface Compatibility 确保接口兼容 Technical Solution Review Interface Descriptions for Completeness 审查接口描述 的完备性 Manage Interfaces 管理接口 - Integration Sequence - Integration Procedures and Criteria - Integration Environment 5.1.2确保接口兼容 5. 产品交付 Page 70 Assemble Product Components and Deliver the Product 产品组装和交付 Technical Solution Confirm Readiness of Product Components for Integration 确认将集成组件 的条件具备 Assemble Product Components 组装产品组件 Evaluate Assembled Product Components 核查组装的 产品组件 Package and Deliver the Product or Product Component 产品打包和交付 - Integration Sequence - Integration Procedures and Criteria - Integration Environment 5.1.3产品组装和交付 5. 产品交付 Page 71 5.1.4 产品集成(PI)与其他过程域关系 ‹需求开发(RD):识别接口需求 《需求规格说明书》明确定义接口的需求。 ‹技术解决(TS):定义接口、需要的集成开发环境 《概要设计说明书》和《详细设计说明书》定义接口、以及系统运行的环境。 ‹验证(VAL):验证接口、集成环境以及迭代集成 《产品集成计划》可以合并为《测试计划》中,对于每阶段测试如单元测试、集成测试、系统测试 来都需要分别集成(环境中迭代集成),以确保接口兼容。 确认(VER):产品组件和集成产品进行确认 在客户现场或模拟客户运行环境,进行集成,并做确认测试。 ‹风险管理(RSKM):识别接口兼容性和产品组件集成的风险和利用原型缓解风险 考虑产品集成中可能存在的接口(如涉及到软硬件接口)兼容性的风险,采用原型或试验来缓解风 险。 ‹决策分析和解决方案(DAR):评估产品组装顺序的决策以及自制还是外购集成环境 系统集成环境决定了产品集成次序,通过DAR的分析技术进行决策。 ‹配置管理(CM):接口变更控制及其信息发布 由配置管理变更的流程统一控制集成接口的变更,版本(每次版本发布为一次集成)的发布,产品 交付前进行配置审计。 ‹供应商管理(SAM): 集成环境中的外购产品或组件的信息 经决策分析确定了集成环境(租凭还是购买),进行相应的采购 5. 产品交付 Page 72 5.2.1 产品试运行 目的:规范软件试运行过程,收集系统试运行的反馈信息,及时解决系统问题,确保系统正常运 行。 角色与职责:项目经理编写《软件试运行》,并监督执行。组织安排相关人员解决试运行发现的 问题。技术支持人员按照试运行及验收计划的要求进行现场安装部署、培训等工作。记录 试运行及验收过程中发现的问题,汇总提交给项目经理,并协助相关人员解决。 启动准则:《系统用户操作手册》、《系统安装维护手册》等用户支持性文档已完成。系统测试 已完成。 输入:《系统测试报告》、《需求规格说明书》 主要步骤: [Step1] 项目经理编写《软件试运行计划》 [Step2] 技术支持人员按《软件试运行计划》进行现场安装部署 (硬件环境、操作系统、 数据库、软件产品安装 ),系统初始化操作。试运行问题处理。 [Step3] 编写《系统安装报告》交客户确认 [Step4] 进行系统操作培训 输出:《软件试运行计划》、《系统安装报告》 结束准则:客户在《系统安装报告》上签字确认。 度量:试运行计划与实际对比;试运行发现问题的个数。 5.2产品试运行与验收 5. 产品交付 Page 73 5.2.2 系统验收 目的:完成系统验收,收款。 角色与职责:项目经理编写《软件验收计划》,并监督执行。按照合同及相关协议的要求,提交 完整和正确的软件产品给客户,与客户方代表、商务人员一同完成系统验收工作。 启动准则:《系统安装报告》经客户确认。 输入:《用户需求说明书》、合同(或协议)、《系统安装报告》 主要步骤: [Step1] 项目经理编写《软件验收计划》 [Step2] 成立验收小组 [Step3] 进行验收测试 [Step4] 完成《验收报告》 输出:《软件验收计划》、《验收报告》 结束准则:客户在《验收报告》上签字确认。 度量:验收计划与实际对比;验收发现的问题的个数。 5. 产品交付 Page 74 5.3 产品确认 5.3.1 确认的目的 z “确认”的目的在于证明,产品或产品构件当被置于其预定环境中时,适 合于其预定用途。 z “确认”过程要证明所建造的产品将在其预定环境中发挥其预定作用。各 项确认活动的做法与验证类似(例如,测试、分析、仿真、客户签字等等 )。 z “验证”的目的在于保证工作产品满足其规定的要求 。 “验证”过程包括按 照需求(包括顾客需求、产品需求和产品构件需求)对产品和中间产品进行 验证 。 z "确认"是要证明所提供的(或将要提供的)产品适合其预计的用途,而" 验证"则是要查明工作产品是否恰当地反映了规定的要求。换句话说,验证要 保证"做得正确",而确认则要保证"做的东西正确"。 5.3.2验证与确认的区别 5. 产品交付 Page 75 5.3.3 确认(VAL)的结构图 - Conformance一致性 - Deficiencies缺陷 Prepare for Validation 准备确认 Validate Product or Product Components 确认产品或产品构件 Requirements Development 需求开发 VAL: Validation 5. 产品交付 Page 76 Select Products for Validation 选择确认的 工作产品 CL3 Establish Validation Procedures and Criteria 建立确认规程 和规则 Prepare for Validation 准备确认 CL2 Establish the Validation Environment 创建确认环境 - Validation Environment and Criteria - Validation Procedures and Criteria - List of Products and Product- Components Selected for Validation 5.3.3.1 准备确认 5. 产品交付 Page 77 Perform Validation 执行确认 Validate Product or Product Components 确认产品或产品构件 Validation Reports Validation Results Cross Reference Matrix As-Run Procedures Log Operational Demonstrations Analyze Validation Results 分析确认结果 Validation Deficiency Reports Validation Issues Procedure Change Request 5.3.3.2 确认产品或产品构件 5. 产品交付 Page 78 工程类过程域 RD PI Val CustomerTS Ver REQM Requirements需求 Customer needs客户需求 Product and product component requirements产品和产品构件需求 Product components, work products, verification and validation reports 产品组件、中间产品以及验证和确认报告 Product components 产品组件 Alternative solutions 供选择方案 Require- ments Product 注: REQM:需求管理 RD:需求开发 TS:技术解决 PI:产品集成 VER:验证 VAL:确认 6. 小结

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 15 金币 [ 分享文档获得金币 ] 1 人已下载

下载文档

相关文档