页数：162页文件大小：926.8 KB来源： 软件工程ppt课件
本课件为软件工程课程第1章概论，从计算机软件的概念与软件危机的表现、成因讲起，界定软件工程的目标、过程与原则，展开软件生存周期活动，并介绍ISO/IEC 12207生存周期过程、CMM与CMMI的阶段式与连续式表示法。
软件工程第1章概论
序言
序言（2）
课程成绩计算
参考书
内容摘要
内容摘要
计算机软件
软件的发展
软件危机许多软件项目不能满足客户的要求许多软件项目超出预算和时间安排
软件危机的表现
软件危机的原因
克服软件危机的途径
软件的特点
其它特点：
软件的分类
软件语言software language软件语言是用于书写计算机软件的语言。它主要包括：需求定义语言功能性语言设计性语言实现性语言（即程序设计语言）文档语言
需求定义语言requirements definition language需求定义语言用来书写软件需求定义。软件需求定义是软件功能需求和非功能需求的定义性描述。软件功能需求刻画软件“做什么”，软件非功能需求刻画诸如功能性限制、设计限制、环境描述、数据与通信规程及项目管理等典型的需求定义语言有PSL语言（ProblemStatement Language问题陈述语言）
功能性语言functional language功能性语言用来书写软件功能规约（functional specification）软件功能规约是软件功能的严格而完整的陈述。通常它只刻画软件系统“做什么”的外部功能，而不涉及系统“如何做”的内部算法。典型的功能性语言有广谱语言、Z语言。
设计性语言design language设计性语言用来书写软件设计规约（designspecification）软件设计规约是软件设计的严格而完整的陈述。一方面，它是软件功能规约的算法性细化，刻画软件“如何做”的内部算法，另一方面，它是软件实现的依据。典型的设计性语言有PDL语言（ProgramDesign Language）
实现性语言实现性语言用来书写计算机程序实现性语言也称编程语言或程序设计语言（programming language）程序设计语言可按语言的级别、对使用者的要求、应用范围、使用方式、成分性质等多种角度进行分类
也可称：命令式语言和申述式语言命令式语言（imperative language）即过程式语言。申述式语言（declarative language）是着重描述要处理什么，而非描述如何处理的语言。申述式语言程序是关于问题解的约束陈述，这些约束迫使含于实现中的算法处理机制生成一个解或一组解。如函数式语言、逻辑式语言。
函数式语言(functional programminglanguage)中函数是构造程序的基本成分，它提供一些设施用于构造更为复杂的函数。程序人员根据提出的问题去定义求解函数（即主程序），其中可能包含一些辅助函数。如Lisp语言。逻辑式语言(logic programming language)的基本运算单位是谓词。谓词定义了变元间的逻辑关系。例如，Prolog语言的基本形式是Horn子句，其程序围绕着某一主题的事实、规则和询问三类语句组成。这三类语句分别用来陈述事实、定义规则和提出问题。
文档语言documentation language
内容摘要
软件工程定义1968年NATO(北大西洋公约组织)会议上首次提出
软件工程的框架
软件生存周期（software life cycle）
内容摘要
软件过程
ISO12207软件生存周期过程
基本（primary）过程供各当事方在软件生存周期期间使用。包括：
支持（supporting）过程用于支持其他过程，它有助于软件项目的成功和质量提高。包括：
组织（organizational）过程用于软件组织建立和实现构成相关生存周期的基础结构和人事制度，并不断改进这种结构和过程。包括：
ISO/IEC 12207为软件生存周期过程建立了一个公共框架，它提供了一组标准的过程、活动和任务。对于一个软件项目，可根据其具体情况对标准的过程、活动和任务进行剪裁，即删除不适用的过程、活动和任务。ISO/IEC 12207标准的附录A中的剪裁（tailoring）过程规定了在针对该标准进行剪裁时所需要的基本活动（包括：明确项目环境；请求输入；选择过程、活动和任务；把剪裁决定和理由写成文档），剪裁过程的输出是：剪裁决定和理由记录。附录B就剪裁要点提供简要说明，并列出一些关键要素，可以根据这些要素作出剪裁决定。
能力成熟度模型CMMCMM（Capability Maturity Model）即能力成熟度模型，是美国卡耐基梅隆大学软件工程研究所（SEI）在美国国防部资助下于二十世纪八十年代末建立的，用于评价软件机构的软件过程能力成熟度的模型。此模型在建立和发展之初，主要目的在于提供一种评价软件承接方能力的方法，为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到后来，又同时被软件组织用于改进其软件过程。
软件组织的成熟与不成熟1.不成熟的软件组织
.成熟的软件组织
软件过程成熟度等级CMM提供了一个成熟度等级框架：1级-初始级、2级-可重复级、3级-已定义级、4级-已管理级和5级-优化级。1.初始（initial）级：软件过程的特点是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力。2.可重复（repeatable）级：建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功。
.已定义（defined）级：己将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。4.已管理（managed）级：收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。5.优化（optimizing）级：整个组织关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生。过程的量化反馈和先进的新思想、新技术促使过程不断改进。
.优化级4.已管理级3.已定义级2.可重复级1.初始级标准、一致的过程有纪律的过程可预测的过程持续改进的过程软件过程成熟度的5个等级
成熟度等级关键过程域共同特性关键实践包含划分为包含过程能力表明目标实现实施或制度化解决活动或基础设施描述CMM结构能力成熟度模型的结构
能力成熟度模型的结构
2)执行能力：执行能力描述了项目或机构完整地实现软件过程所必须有的先决条件。典型内容包括资源、机构结构和培训。3)执行活动：执行活动描述了执行一个关键过程域所必需的活动、任务和规程。典型内容包括制定计划和规程、执行和跟踪以及必要时采取纠正措施。
4)测量和分析：测量和分析描述了为确定与过程有关的状态所需的基本测量实践。这些测量可用来控制和改进过程。典型内容包括可能采用的测量实例。5)验证实现：验证实现描述了为确保执行的活动与已建立的过程一致所采取的步骤。典型内容包括管理部门和软件质量保证组实施的评审和审核。
在执行活动这个共同特性中的实践描述了建立一个过程能力所必须完成的活动。所有其他实践共同形成了一个使机构能将执行活动中描述的实践进行规范化的基础。各关键过程域的详细描述，参见《能力成熟度模型（CMM）：软件过程改进指南》，卡耐基梅隆大学软件工程研究所编著，刘孟仁等译，电子工业出版社出版。
缺陷预防技术更新管理过程更改管理优化级定量过程管理软件质量管理已管理级机构过程焦点机构过程定义培训大纲综合软件管理软件产品工程组间协调同行评审已定义级需求管理软件项目计划软件项目跟踪和监督软件分包合同管理软件质量保证软件配置管理可重复级初始级能力成熟度级别中的关键过程域
关键过程域实例机构过程焦点第3级的关键过程域：已定义级机构过程焦点的目的是，为能改进机构整体软件过程能力的软件过程活动建立机构的职责。机构过程焦点包括，建立和维护机构的软件过程和项目软件过程（之间）的默契关系，并协调有关评估、开发、维护和改进这些过程的活动。机构提供长期的约定和资源，以协调现在和将来的软件项目的软件过程的开发和维护。该项工作由某个小组实施，例如软件工程过程组。它负责机构的软件过程活动，特别是负责开发和维护机构标准软件过程和相关过程资源（如在机构过程定义关键过程域中说明的），并协调软件项目的过程活动。
目标目标1：机构内部软件过程的制定和改进活动协调一致。目标2：相对于过程标准，所使用的软件过程的优势和薄弱环节标识清楚。目标3：机构级的过程开发和改进活动有计划。
执行约定约定1：机构遵循书面的管理策略，协调整个机构范围内的软件过程开发和改进活动。该策略一般规定:1.建立一个小组，负责机构级的软件过程活动，使这些活动与各项目协调一致。2.定期评估项目所使用的软件过程，以确定其优势和薄弱环节。
.对机构标准软件过程进行合理地剪裁，以得到项目使用的软件过程。关于机构标准软件过程，参见综合软件管理关键过程域的活动1。
约定2：上级管理部门倡导和支持机构的软件过程开发和改进活动。上级管理部门：1.向机构成员和负责人说明有关软件过程活动的约定。2.制定资金、人员配备和其他资源的长期计划和约定。3.制定管理和执行有关软件过程开发和改进活动的策略。
约定3：上级管理部门监督机构的软件过程开发和改进活动。l.确保机构标准软件过程满足企业目标和策略。2.提出关于软件过程开发和改进活动优先次序的建议。3.参与制定软件过程开发和改进计划。a.上级管理部门与更高层人员和负责人共同协调软件过程需求及问题b.上级管理部门与该机构负责人进行协调，以获得负责人和机构成员的支持和参与
执行能力能力1：有一个负责机构的软件过程活动的小组。一个小组是一些部门、负责人和人员的组合，负责一组任务和活动。小组的规模可以不同，既可以是单个兼职的人，也可以是多个来自不同部门的兼职人员，也可以由几个专职人员组成。组成小组时考虑的因素包括：分派的任务和活动、项目规模、机构结构和机构文化。某些小组，如软件质量保证组，集中关注项目活动;而其他一些小组，例如软件工程过程组，集中关注机构范围内的活动。
.条件可能时，小组成员以专职工作的软件专业人员为核心，并尽可能有其他的兼职人员支持。该小组最一般的例子是软件工程过程（SEPG）。2.小组成员中有软件工程及软件相关科目的代表。软件工程及软件相关科目的实例有：
能力2：为实施机构的软件过程活动提供了充足的资源和资金。1.委派在特定领域具有特长的人员支持该小组。特定领域的实例有：
能力3：负责机构软件过程活动的小组成员接受过实施这些活动所需的培训。培训的实例有：
能力4：软件工程组和其他软件相关小组的成员接受过机构软件过程活动及其在这些活动中的任务方面的定向培训。参见培训大纲关键过程域
执行活动活动1：定期评估软件过程，并根据评估结果制定行动计划。评估一般每隔一年、一年半至三年进行一次。评估可针对机构中所使用的所有软件过程，也可通过对过程和项目进行抽样评估。评估机构软件过程能力的方法实例之一是SEI软件过程评估方法。行动计划标识：
活动2：机构制定和维护它的软件过程开发和改进活动的计划。该计划：1.以软件过程评估后的行动计划和其他的机构过程改进倡议为基础。2.确定要实施的活动及实施这些活动的进度。3.确定负责这些活动的小组和个人。4.确定所需的资源，包括人员配备和工具。5.初始发布和有大改动时通过同行评审。参见同行评审关键过程域。6.机构的软件负责人和上级负责人评审认可。
活动3：在机构级协调关于机构和项目的软件过程的开发和改进活动。涉及的软件过程有：1.机构标准软件过程。关于机构标准过程，参见机构过程定义关键过程域的活动1和活动2。2.项目定义的软件过程。关于项目定义的软件过程。参见综合软件管理关键过程域的活动1和活动2。
活动4：在机构级协调有关软件过程数据库的使用。机构的软件过程数据库用来收集机构和项目的软件过程以及生成的软件产品的信息。关于机构的软件过程数据库，参见机构过程定义关键过程域的活动5。
活动5：监控和评价机构中限制使用的新过程、方法和工具。合适时，推广到机构的其他部分。活动6：在机构内协调机构和项目的软件过程的培训。1.制定有关机构和项目软件过程的专题培训计划。2.合适时，培训由负责机构软件过程活动的小组（如软件工程过程组）或培训小组准备和实施。参见培训大纲关键过程域。
活动7：向与实施软件过程有关的小组通报机构和项目中软件过程开发和改进活动的情况。通报方式的实例有：
测量和分析测量1：测量机构的软件过程开发和改进活动的状态测量的实例有：
验证实现验证1：上级管理部门定期评审软件过程开发和改进活动。上级管理部门实施定期评审的主要目的是适当地、及时地掌握软件过程活动。在满足机构需求的前提下，只要有适当的机制来报告异常情况，评审的时间间隔就尽可能长些。1.对照计划，评审有关开发和改进软件过程活动的进展和状态。2.讨论低层不能解决的冲突和问题。3.指定和评审行动措施，并跟踪到关闭。4.编写评审的总结报告，并分发给相关的小组和个人。
能力成熟度模型集成CMMICapability Maturity Model Integration
相应的国际标准：ISO/IEC12207（软件生存周期过程）、ISO/IEC15288（系统生存周期过程）、ISO/IEC15504（软件过程评估）
阶段式模型
阶段式模型的成熟度等级结构过程域2过程域n成熟度等级过程域1执行的能力执行的承诺定向实现验证实现特定目标共性目标特定实践共性实践公共特征
连续式模型
能力等级特征示意图CL0未完成的CL1已执行的CL2已管理的CL3已定义的CL4定量管理的CL5优化的过程域RSKMIPMSAMPMCPPITQPM
内容摘要
软件过程模型
软件过程模型
瀑布模型系统工程需求分析与规约设计与规约编码与单元测试集成测试系统测试运行与维护
增量模型项目日历时间软件功能性和特征12345第2次增量发布增量212345第n次增量发布增量n12345第1次增量发布增量1┇5部署（发布，反馈）4构造（编码，测试）3建模（分析，设计）2计划1交流
部署交付和反馈构建原型交流快速设计方式建模快速计划原型模型
喷泉模型
领域分析构件可变性分析构建可复用构件领域模型领域基准体系结构图可复用构件库分析体系结构设计获取构件构件特化和修改评价构件组装和测试开发未找到构件的部分应用系统工程应用系统领域工程
形式方法模型
净室过程模型系统工程需求收集代码审查盒结构规约形式化设计正确性验证代码生成统计使用测试认证测试计划增量1需求收集代码审查盒结构规约形式化设计正确性验证代码生成统计使用测试认证测试计划需求收集代码审查盒结构规约形式化设计正确性验证代码生成统计使用测试认证测试计划增量2增量3
内容摘要
敏捷软件开发
Agile方法的价值观
（5）以积极向上的员工为中心建立项目组，给予他们所需的环境和支持，对他们的工作予以充分的信任（6）项目组内效率最高、最有效的信息传递方式是面对面的交流（7）测量项目进展的首要依据是可运行的软件（8）敏捷过程提倡可持续的开发，项目发起者、开发者和用户应能长期保持恒定的速度
（9）应时刻关注技术上的精益求精和好的设计，以增强敏捷性（10）简单化是必不可少的，这是尽可能减少不必要工作的艺术（11）最好的构架、需求和设计出自于自我组织的团队（12）团队要定期反思怎样才能更有效，并据此调整自己的行为
Agile方法的适用范围Martin Fowler认为：新方法不是到处可适用的适合采用Agile方法的情况：
Agile的典型方法
XP方法
XP方法的4个价值观
XP方法的12个核心实践1.完整的团队（Whole Team）所有的小组成员应在同一个工作地点工作成员中必须有一个现场用户（On-siteUser）由他提出需求，确定开发优先级通常还设一个“教练”（Coach）角色教练指导XP方法的实施，以及与外部的沟通和协调2.计划对策（Planning Game）包括两类：发布计划和迭代（Iteration）计划
.系统比喻（Metaphor）系统比喻是待开发软件的一个每个成员都熟悉的形象化比喻，相当于一个粗略的软件体系结构4.小发布（Small release）经常、不断地发布可运行的、具有商业价值的小软件版本，供现场用户评估或最终使用5.测试（testing）XP方法提倡测试优先，即先写测试后编代码（testing then coding）6.简单设计（Simple Design）设计只考虑当前定义的功能而不考虑以后需求的变化该设计是完成目前功能所需的最简洁的设计
.结对编程（Pair Programming）一个程序员编程的同时，另一个程序员负责检查程序的正确性和可读性结对的伙伴可以动态调整8.设计改进（Design Improvement）在不影响程序的外部可见行为的情况下，按高内聚低耦合的原则对程序结构进行改进，保持代码简洁、无冗余9.持续集成（Continuous Integration）每完成一个模块的开发（包括该模块的单元测试）后，立即将其组装到系统中，并进行集成测试，完成该集成测试后才能进行下一次集成
.代码全体共有（Collective codeOwnership）团队中的任何人可以在任何时候修改系统任何位置上的任何代码团队的成员都可以参加模型的开发，又有系统比喻、结对编程、编码标准、持续集成等实践，这些都为代码全体共有提供了支持11.编码标准（Coding Standard）XP方法强调制订一个统一的编码标准，包括命名、注释、格式等编程风格12.可持续步调（Sustainable Pace）每周40小时工作制
XP方法的开发过程最新版本发布计划用户认可用户故事(userstories)下一迭代Bugs新用户故事测试用例迭代开发体系结构骨架(spike)系统比喻制订交付计划验收测试小发布需求不确定的估计确定的估计难点骨架探索阶段计划阶段迭代与发布阶段产品化阶段维护阶段
探索阶段
计划阶段
迭代到发布阶段
产品化阶段
可能要写的文档：
维护阶段
内容摘要
在软件工程活动中，软件工程师和管理人员按照软件工程的方法和原则，借助于计算机及其软件工具的帮助，开发、维护、管理软件产品的过程称为计算机辅助软件工程计算机辅助软件工程（CASE）Computer Aided Software Engineering
维护过程：版本控制工具，文档分析工具，逆向工程（reverse engineering）工具，再工程（reengineering）工具管理过程：项目管理工具，配置管理工具，软件评价工具应用类工具
下载地址：{{downurl}}
{{{a}}}
{{#b}}{{{b}}}
{{/b}} {{/title}} {{#nolog}}登陆注册
{{/nolog}} {{#djsx}}点我刷新
{{/djsx}} {{#gocz}} {{/gocz}} {{#ffqr}} {{/ffqr}}