搜索
•CH01软件和软件工程•1.软件的特点：软件是设计开发的，而不是传统意义上生产制造的；软件不会磨损，但是会退化；多数软件仍是根据实际顾客需求定制的；在软件设计中，大规模的复用才刚刚开始。•2.IEEE对软件工程的定义：将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件；上述方法的研究。•3.软件工程层次图：工具-方法-过程-质量关注点•4.通用软件工程过程框架包括5个活动：沟通；策划；建模；构建；部署。•5.软件神话：它实际上是误导了管理者和从业人员对软件开发的态度，从而引发了严重的问题。•管理神话：•神话：我们已经有了一本写满软件开发标准和规程的宝典。它无所不包，囊括了我们可能问到的任何问题。•现实：这本宝典也许的确已经存在，但不能保证它已在实际中采用、反映了软件工程的现状、可以适应不同应用环境、在缩短交付时间的同时还关注保证产品的质量等等。•神话：如果我们未能按时完成计划，我们可以通过增加程序员人数而赶上进度。•现实：新人加入一个软件项目后，原有开发人员必须牺牲本来的开发时间对新人进行培训，减少了应用于高效开发的时间。•神话：如果我将一个软件外包给另一家公司，则我可以完全放手不管。•现实：如果开发团队不了解如何在内部管理和控制软件项目，那在外包项目中都会遇到困难。•客户神话：•神话：有了对项目目标的大概了解，便足以开始编写程序，可以在之后的项目开发过程中逐步充实细节。•现实：虽然通常难以得到综合全面且稳定不变的需求描述，但对项目目标模糊不清的描述将为项目实施带来灾难，只有客户和开发人员之间保持持续有效的沟通才能得到清晰的需求描述。•神话：虽然项目需求不断变更，但是因为软件是弹性的，因此可以很容易地适应变更。•现实：软件需求的变更引入时机不同，变更造成的影响也不同，如提出的较早，则费用影响较小，但随着时间的推移，变更的代价也迅速增加，因为资源已经分配，设计框架已经建立，此时变更可能会引起剧变，需要添加额外的资源或修改主要设计架构。•从业者神话：•神话：当我们完成程序并将其交付使用之后，我们的任务就完成了。•现实：软件首次交付顾客使用之后花费的工作更多。•神话：对于一个成功的软件项目，可执行程序是惟一可交付的成果。•现实：软件配置包括很多内容，可执行程序只是其中之一。各种工作产品（如模型、文档、计划）是成功实施软件工程的基础，为软件技术支持提供了指导。•神话：软件工程将导致我们产生大量无用文档，并因此降低工作效率。•现实：软件工程并非以创建文档为目的，而是为了保证软件产品的开发质量。•CH02过程模型•1.瀑布模型•①经过的活动：沟通：项目启动、需求获取。策划：项目估算、进度计划、项目跟踪。建模：分析、设计。构建：编码、测试。部署：交付、支持、反馈。•②优缺点：它提供了一个模板，使得分析、设计、编码、测试与维护工作可以在该模板的指导下有序地展开，避免了软件开发、维护过程中的随意状态。对于需求确定、变更相对较少的项目，线性顺序模型仍然是一种可以考虑采取的过程模型。采用这种模型，曾经成功地进行过许多大型软件工程的开发。•③存在问题：（为什么瀑布模型有时候会失效？）实际项目很少严格遵守该顺序。客户通常难以清楚描述所有需求。只有到项目接近尾声时，才有可执行程序。•3.增量模型：•①经过的活动：•第一个增量模型往往是核心部分的产品，它实现了软件的基本需求，但很多已经明晰或者尚不明晰的补充特性还没有发布。每个增量的开发可用瀑布或快速原型模型。和原型模型不一样的是，增量模型虽然也具有“迭代”特征，但是每一个增量都发布一个可操作的产品，不妨称之为“产品扩充迭代”。它的早期产品是最终产品的可拆卸版本，每一个版本都能够提供给用户实际使用。•②优缺点：•优点：能在较短时间内向用户提交可完成部分工作的产品。用户有较充裕的时间学习和适应新产品。易于保证核心功能正确。可以基于早期版本来获取需求。项目完全失败的风险小。可以为那些创新的功能开拓市场。规避了资源缺乏的风险。•缺点：把用户需求转化为功能递增的不同版本可能比较难。以确定所有版本共需的公用模块。•③存在问题：•如果你的客户要求你在一个不可能完成的时间提交产品，向他建议只提交一个或几个增量，此后再提交软件的其他增量。•增量和原型的比较：任何增量的处理流程均可结合原型实现；增量模型与原型相同，本质上都是迭代的；增量模型强调每个增量都是可操作的；早期的增量是整体的一部分，而原型最终要被抛弃。•4.原型开发：•①经过的活动：•沟通→快速策划→建模快速设计→构建原型→部署交付及反馈(组成一个圆圈)•②优缺点：•优点：用户能够感受到实际系统；开发者能很快建造出一些东西。•③存在问题：开发者没有考虑整体软件质量和长期的可维护性；开发者往往在实现过程中采用折中的手段。客户提出了一些基本功能，但未详细定义输入、处理和输出需求；开发人员可能对开发运行环境、算法效率、操作系统的兼容性和人机交互等情况不确定。这些情况下，采用原型开发。对于要求把一个粗糙的原型系统变为工作产品的压力，建议尽量抵制。这样做的结果往往是产品质量受到损害。•5.螺旋模型•①经过的活动：（五个关键词形成一个螺旋）•沟通。策划：项目估算、制定进度计划、风险分析；建模：分析、设计。构建：编码、测试。部署：交付、反馈。•②优缺点：随着过程进展演化，开发者和客户能够更好地理解和对待每个演化级别上的风险，适合于大型系统及软件的开发。使用原型实现作为降低风险的机制，并在开发的任意阶段均可使用原型实现。更真实的反映了现实世界。如应用得当，能在风险变成问题之前降低它。模型的成功依赖于风险评估的专门技术。是一个较新的模型，功效的确定尚需若干年时间。③存在问题：很难说服客户演进的方法是可控的。依赖大量的风险评估专家保证成功，如果风险没被发现，会发生问题。•6.协同开发模型：定义一系列事件，触发软件工作活动、动作或者任务的状态转换。更适合于client/server应用。定义一个过程网络活动代替一个事件的序列。•7.各种模型的比较：•8.统一过程（UP——UnifiedProcess）：•①宗旨：用例驱动，以架构为核心，迭代并且增量。•②统一过程的阶段：起始阶段包括客户沟通和策划活动。细化阶段包括沟通和通用过程模型的建模活动。构建阶段与通用软件过程中的构建活动相同。转换阶段包括通用构建活动的后期阶段以及通用部署（交付和反馈）活动的第一部分。生产阶段与通用过程的部署活动一致。5个过程并非顺序进行，而是阶段性并发进行。•例题：以下情况下应该采用什么过程模型？•（1）客户不太清楚待开发的系统需要提供什么服务。答：原型•（2）开发团队了解待开发软件的相关领域知识，尽管此系统庞大，但其较已经开发的系统差异并不大。答：瀑布•（3）软件的功能是把读入的浮点数开平方，所得到的结果应该精确到小数点后4位。答：瀑布•（4）开发一个已发布软件的新版本，公司规定了严格的完成期限，并对外公布。答：增量•（5）汽车防锁死刹车控制系统。答：螺旋•（6）大学记账系统，准备替换一个已存在的系统。答：瀑布•（7）一个位于火车站的交互式火车车次查询系统。答：原型•CH03敏捷开发•1.敏捷的概念：它是一种软件开发方法论，可以应对客户快速变更的需求。它强调以人为核心，采用迭代的方式，循序渐进的开发软件。特别适用于web应用开发。•2.敏捷原则：•通过尽早、持续交付有价值的软件来使客户满意。即使在开发后期，也欢迎需求变更。经常交付可工作软件。业务人员和开发人员必须在一起。围绕受激励的个人构建项目。最有效的信息传递方法是面对面交谈。•3.敏捷的特点：工作软件是进度的首要度量标准。提倡可持续的开发速度。不断关注优秀的技能和设计。简单是必要的。好的架构、需求和设计出于自组织团队。定期反省，并相应调整自己的行为。允许项目团队调整并合理安排任务；理解敏捷开发方法的易变性并制定计划；精简并维持最基本的工作产品；强调增量交付策略；快速向用户提供适应产品和运行环境的可运行软件。•4.极限编程XP（eXtremeProgramming）•为实施XP的全部工作定义了五个有重要意义的要素：沟通、简明、反馈、鼓励和尊重。•①策划：•建立一系列描述待开发软件必要特征与功能的“故事”•评估每一个故事（即优先级），并给出以开发周数为度量单位的成本•客户和XP团队共同决定如何把故事分组并置于将要开发的下一个发行版本中（下一个软件增量）•形成关于一个发布版本的基本承诺•在第一个版本发布之后，XP团队计算项目的速度。•对待开发的故事排序方法：所有选定故事在几周内尽快实现；具有最高权值的故事移到进度表前面先实现；高风险故事将首先实现。•项目速度：第一个发行版本中实现的客户故事个数。用于后续发行版本的发布日期和进度安排，•调整软件发型内容和最终交付日期。•②设计•严格遵循KIS(Keepitsimple)原则•鼓励使用CRC卡，CRC（类-责任-协作者）卡确定和组织与当前软件增量相关的面向对象的类。•在某个故事设计中遇到困难时，立即建立这部分设计的可执行原型，实现并评估设计原型（被称为Spike解决方案)•鼓励“重构”，重构是以不改变代码外部行为（如函数的输入输出）而改进内部结构（如函数实现方法）的方式来修改软件系统的过程。重构实质就是在编码完成之后改进代码设计。•③编码•在编码之前，确定检测本次发布的所有故事的单元测试•鼓励结对编程，这提供了实时解决问题和实时保证质量的机制。•连续集成策略，有助于避免兼容性和接口问题。•④测试•每天进行测试•“验收测试”由客户确定，根据本次软件发布中所实现的用户故事而确定。•5.工业极限编程IXP是XP的一种有机进化。更大的包容性、扩大用户角色、升级技术实践。•6.其他敏捷过程模型：自适应软件开发（ASD）。Scrum。精益开发（LeanDevelopment）。动态系统开发方法（DSDM）。特征驱动开发FDD。水晶开发（CristalClear）。•CH04/05/06需求工程•1.需求工程过程（RE——RequirementEngineering）通过执行7个活动来实现：起始、导出、精化、协商、规格说明、确认、管理。起始阶段的工作：确认共同利益者（直接或间接地从正在开发的系统中获益的人）、识别多种观点、协同合作、Q&A会议P68.•2.CRC（类-责任-协作者）建模，提供了一个简单方法，用于识别和组织与系统或产品需求相关的类。CRC模型实际上是表示类的标准索引卡片的集合。•3.创建分析模型时应该遵循的经验原则：•①模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些。•②需求模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。•③关于基础结构和其他非功能的模型应推延到设计阶段再考虑。•④最小化整个系统内的联系。•⑤确认需求模型为所有利益相关者都带来价值。•⑥尽可能保持模型简洁。•4.给类分配职责时建议一下5个指导原则：•①只能系统应分布在所有类中以求最佳地满足问题的需求。•②每个职责的说明应尽可能具有普遍性。•③信息和与之相关的行为应放在同一类中。•④某个事物的信息应局限于一个雷中而不要分布在多个类中。•⑤适合时，职责应由相关类共享。•5.数据流图DFG——DataFlowDiagram•CH07设计概念•0.抽象：①过程抽象是指具有明确和有限功能的指令序列；②数据抽象是描述数据对象的冠名数据集合。•部署级设计元素指明软件功能和子系统将如何在支持软件的物理计算环境内分布。•1.模块化：将系统划分为相对独立但又有所关联的多个部分。•①按照设计原则将系统划分为若干个较小的模块：相互独立但又相互关联。实际上是系统分解和抽象的过程。•②模块是相对独立的程序体•是数据说明、可执行语句等程序对象的集合。单独命名的，并且可以通过名字来访问例如：类、过程、函数、子程序、宏等。•③模块化就是把程序划分成独立命名且可直接访问的模块，各个模块完成一个子功能，这些模块集成起来构成一个整体，完成指定功能。•④对于一个给定的系统，合适的模