软件工程
软件工程
Chapter1 Introduction
软件工程学科产生的背景：
软件危机：
从结果来看，软件危机体现在：
- 软件质量差、可靠性难以保证
- 成本难以控制
- 开发进度难以把握
- 可维护性较差
从原因来看，软件危机由以下两点导致：
- 不断增长的系统复杂性
- 未有效采用软件工程方法进行开发
Frequently asked questions about software engineering
| Question | Answer |
|---|---|
| What is software? | Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market. |
| What are the attributes of good software? | Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable. |
| What is software engineering? | Software engineering is an engineering discipline that is concerned with all aspects of software production. |
| What are the fundamental software engineering activities? | Software specification(规范), software development, software validation(验证) and software evolution(演进). |
| What is the difference between software engineering and computer science? | Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. |
| What is the difference between software engineering and system engineering? | System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process. |
| What are the key challenges facing software engineering? | Coping with increasing diversity, demands for reduced delivery times and developing trustworthy software. |
| What are the costs of software engineering? | Roughly 60% of software costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs. |
| What are the best software engineering techniques and methods? | While all software projects have to be professionally managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can’t, therefore, say that one method is better than another. |
好的软件的基本属性
- 可接受性(满足用户的需求，用户能用，好用)
- 可依赖性和信息安全性
- 效率高
- 可维护性
软件过程——四项基本活动
- 软件规格说明（like 需求分析
- 软件开发
- 软件确认（like 验收
- 软件演化（like 维护
Chapter2 软件过程
2.1软件过程模型
瀑布模型：
如果每阶段做的事是正确的，就能保证最终结果的正确
系统需求<=>软件需求<=>需求分析<=>设计<=>编码<=>测试<=>运行
瀑布模型的优点：
虽然瀑布模型是一个比较 “老”的。甚至过时的开发模型，但其优点为：
在决定系统怎样做之前，存在一个需求阶段。鼓励对系统“做什么” 进行规约（即设计之前的规约）。
在建造构件之前。存在一个设计阶段，鼓励规划系统结构（即编码之前的设计）。
在每一阶段结束时进行复审，允许获取方和用户的参与。
前一步工作产品可作为下一步被认可的。文档化的基线。允许基线和配置早期接受控制。
瀑布模型的缺点：
瀑布模型下，客户和开发者可能会过早地冻结了需求，这样的话后续就不能发生进一步的变化(除非返工)
客户必须能够完整、正确和清晰地表达他们的需求：开发人员一开始就必须理解需求。
缺乏灵活性。一旦软件需求存在偏差，就会导致开发出的软件产品不能满足用户的实际要求(需要返工)。
在一个项目的早期阶段，过分地强调了基线和里程碑处的文档,可能要花费更多的时间，用于建立一些用处不大的文档。
直到项目结束之前，都不能演示系统的能力,增加了项目的风险。
增量模型：
该模型有一个假设：假设需求可以分段，成为一系列增量产品，每一增量可以分别地开发。
系统开发体现为一系列的版本(增量)，每个版本在前一版本的基础上增加一些功能。
增量模型的优点：
作为瀑布模型的第一个变体，具有瀑布模型的所有优点。
此外，它还有以下优点：
更容易获得用户的反馈
第一个可交付版本所需要的成本和时间是很少的：
开发由增量表示的小系统所承担的风险是不大的：
由于很快发布了第一个版本，因此可以减少用户需求的变更：
允许增量投资，即在项目开始时，可以仅对一个或两个增量投资。
注：如果采用增量投资方式，那么客户就可以对一些增量进行招标。
然后，开发人员按提出的截止期限进行增量开发，这样客户就可以用多个契约来管理组织的资源和成本。
增量模型的缺点：
如果增量模型不适于某些项目，或使用有误，则有以下缺点：
如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；
如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发(返工)，重新发布：
管理发生的成本、进度和配置的复杂性，可能会超出一些组织的能力。
过程不可见：管理者需要定期交付成果来衡量进度。如果系统开发迅速，则生成反映系统每个版本的文档并不具有成本效益。
集成和配置：
该方法依赖于可复用的构件或系统。
演化模型：
（针对一开始不能明确需求的情况：
是一种有弹性的过程模式，由一些小的开发步组成，每一步都历经需求分析、设计、实现和验证
喷泉模型：
特征：迭代、无缝
chapter1 软件工程概论
1.1 软件的定义及特点
1.2 软件工程的起源和概念
1.3 软件开发的本质和基本手段
1.4 软件工程框架
chapter2 软件过程
2.1软件生存周期过程的概念
2.2软件生存周期过程的分类
2.3软件生存周期模型的概念
2.4常见的软件生存周期模型
瀑布模型：
如果每阶段做的事是正确的，就能保证最终结果的正确
系统需求<=>软件需求<=>需求分析<=>设计<=>编码<=>测试<=>运行
瀑布模型的优点：
虽然瀑布模型是一个比较 “老”的。甚至过时的开发模型，但其优点为：
在决定系统怎样做之前，存在一个需求阶段。鼓励对系统“做什么” 进行规约（即设计之前的规约）。
在建造构件之前。存在一个设计阶段，鼓励规划系统结构（即编码之前的设计）。
在每一阶段结束时进行复审，允许获取方和用户的参与。
前一步工作产品可作为下一步被认可的。文档化的基线。允许基线和配置早期接受控制。
瀑布模型的缺点：
客户必须能够完整、正确和清晰地表达他们的需求：开发人员一开始就必须理解需求。
缺乏灵活性。一旦软件需求存在偏差，就会导致开发出的软件产品不能满足用户的实际要求。
在一个项目的早期阶段，过分地强调了基线和里程碑处的文档,可能要花费更多的时间，用于建立一些用处不大的文档。
直到项目结束之前，都不能演示系统的能力,增加了项目的风险。
增量模型：
该模型有一个假设：假设需求可以分段，成为一系列增量产品，每一增量可以分别地开发。
增量模型的优点：
作为瀑布模型的第一个变体，具有瀑布模型的所有优点。
此外，它还有以下优点：
第一个可交付版本所需要的成本和时间是很少的：
开发由增量表示的小系统所承担的风险是不大的：
由于很快发布了第一个版本，因此可以减少用户需求的变更：
允许增量投资，即在项目开始时，可以仅对一个或两个增量投资。
注：如果采用增量投资方式，那么客户就可以对一些增量进行招标。
然后，开发人员按提出的截止期限进行增量开发，这样客户就可以用多个契约来管理组织的资源和成本。
增量模型的缺点：
如果增量模型不适于某些项目，或使用有误，则有以下缺点：
如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；
如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布：
管理发生的成本、进度和配置的复杂性，可能会超出一些组织的能力。
演化模型：
（针对一开始不能明确需求的情况：
是一种有弹性的过程模式，由一些小的开发步组成，每一步都历经需求分析、设计、实现和验证
喷泉模型：
特征：迭代、无缝
chapter3 软件需求与软件需求规约
3.1需求的作用
软件开发的工作基础
3.2需求的定义
描述了待开发产品/系统功能上的能力、性能参数或其他性质
需求的基本性质：
- 必要性 是要求的
- 无歧义性 是否只能用一种方式来解释
- 可测的 (测试) 能否进行测试，对一定的输入，会有相同的输出
- 可跟踪的 从一个开发阶段到另一个阶段能否进行跟踪
- 可测量的 能否测量
3.3需求的分类
功能需求：
关于该功能输入的所有假定，或为了验证该功能输入有关检测的假定。
功能内的任一次序，这一次序是与外部有关的。
对异常条件的响应，包括所有内外部所产生的错误。
需求的时序或优先程度。
功能之间的互斥规则。
系统内部状态的假定。
为了该功能的执行，所需要的输入和输出次序。
用于转换或内部计算所需要的公式。
性能需求：
规约了一个系统或系统构建必须具有的性能特性(速度、准确率、并发等要求)
外部接口需求：
外部接口需求 (External interface requirement) 规约了系统或系统构件必须与之交互的硬件、软件或数据库元素。它也可能规约其格式、时间或其他因素。
系统接口 (Systeminterfaces)：描述一个应用如何与系统的其他应用进行交互。
用户接口 (User interfaces)：规约了软件产品和用户之间接口的逻辑特性。即规约对给用户所显示的数据，对用户所要求的数据以及用户如何控制该用户接口。
硬件接口 (Hardware interfaces)：如果软件系统必须与硬件设备进行交互，那么就应说明所要求的支持和协议类型。
软件接口 (Software interfaces)：允许与其它软件产品进行交互，如，数据管理系统、操作系统或数学软件包。
通讯接口 (Communications interfaces)：规约待开发系统与通讯设施（如，局域网）之间的交互。如果通讯需求包含了系统必须使用的网络类型 (TCP/IP. WindowsNT. Novell)，那么有关类型的信息就应包含在SRS中。
设计约束需求：
设计约束限制了系统或系统构件的设计方案。就约束的本身而言。对其进行权衡或调整是相当困难的，甚至是不可能的。它们必须予以满足。这一性质是与其它需求的最主要差别。为了满足功能、性能和其它需求，许多设计约束将对软件项目规划、所需要的附加成本和工作产生直接影响。例如：
- 系统必须用C++或其他面向对象语方编写。系统用户接口需要菜单……
质量属性：
规约了软件产品必须具有的性质是否达到质量方面一个所期望的水平
例如：
可靠性 软件系统在指定环境中没有失败而正常运行的概率。
存活性 当系统的某一部分系统不能运行时，该软件维续运行或支持关键功能的可能性。
可维护性 发現和改正一个软件故障或对特定的花明进行修改所要求的平均工作。
用户友好性 学习和使用一个软件系统的容易程度。
安全性 在一个预定的时间内，使软件系统安全的可能性。
可移植性 软件系统运行的平台类型。
3.4需求发现
需求是怎么来的？
自悟(Introspection)
需求人员把自己作为系统的最终用户，审视该系统并提出问題：“如果是我使用这一系统，则我需要…”
适用条件：
需求工程师不能直接与用户进行交流，自悟似乎是一种比较有吸引力的方法，可能确实是必须的。
成功条件：
若使自悟是成功的，需求人员必须具有比最终用户还要多的应用领域和过程方面的知识，并具有良好的想象能力。
交谈(Individual interviews)
为了确定系统应该提供的功能，需求人员通过提出问题，用户回答，直接询问用户想要的是一个什么样的系统。
成功条件：
交谈通常是一种比自悟更好的技术。这种途径成功与否依赖于：
一一需求人员是否具有“正确提出问题的的能力，
一一回答人员是否具有“揭示需求本意”的能力。
在在的风险：在交谈期间需求可能不断增长，或是以前没有认识到的合理需求的一种表现，说是“完美蠕行”(Creepingelegance)病症的体现，以至于很难予以控制，可能导致超出项目成本和进度的限制。
应对措施：
项目管理人员和客户管理人员应该定期地对交谈过程的结果进行复車。其中具有挑战的问题是：
判断：
一一什么时候对这一增长划界：
一一什么时候将这一增长通知客户。
观察(Observation)
通过观察用户执行其现行的任务和过程，或通过观察他们如何操作与所期望的新系统有关的现有系统，了解系统运行的环境，特别是了解要建的新系统与现存系统、过程以及工作方法之间必须进行的交互。尽管了解的这些信息可以通过交谈获取，但“第一手材料”一般总是能够比较好的符合现实的。
存在的风险：
一一客户可能抵触这一观察。其原因是他们认为开发者打扰了他们的正常业务。
一一客户还可能认为开发者在签约之前，就已经熟悉了他们的业务。
小组会(Group session)
举行客户和开发人员的联席会议，与客户组织的一些代表共同开发需求。其中：
一通常是由开发组织的一个代表作为首席需求工程师或软件工程项目经理，主持这一会议。但还可以采用其它形式，这依赖于其应用领城和主持人的能力。主持人的作用主要是掌握会议的进程。
一必须仔细地选择该小组的成员，不仅要考虑他们对现存的和未来运行环境的理解程度，还要考虑他们的人品。
提炼(Extraction)
复审技术文档（例如，有关需要的陈达，功能和性能目标的陈述，系统规约接口标准，硬件设计文档以及ConOps文档），并提出相关的信息。
适用条件：
提炼方法是针对己经有了部分需求文档的情况。依据产品的本来情况，可能有很多文档需要复审，以确定其中是否包含相关联的信息。在有的情况，也可能只有少数文档需要复审。
在许多项目中，在任何交谈、观察、小组会或自悟之前，应该对该项目的背景文档进行复审，还应对系统规约进行复审，同时了解相关的标准和政策。
总结：
- 在任意特定的环境中，每项技术都有其自己的优点和不足。在实施上述任何一项技术时，都可以辅以其他
方法，例如原型构造，在举行小组会时可以使用原型，方便人员之间的交流。
依据需求工程人员的技能和产品、合同的实际情况，往往需要“组合”地使用这些技术来开发初始需求。
执行需求发现这项活动的人，其技能水平将对这项活动的成功具有重大的影响。
大型复杂项目和一些有能力的组织，在开发需求文档时，往往使用系统化的需求获取、分析技术和工具。
一些方法提供了 系统化、自动化的功能，并可逐一验证单一需求所具有的五个性质，验证需求规约是否具
有四个性质。
3.5需求规约(SRS)
概念:
一个需求规约是一个软件项/产品/系统所有需求陈述的正式文档，是一个软件产品/ 系统的概念模型。
基本性质:
一般来说，SRS应必须具有以下4个性质：
重要性和稳定性程度 (Banlked for importaance and stability).例如：基本需求、可送的需求和期望的需求。
可修改的 (Modifiable)：在不过多地影响其它需求的前提下，可以容易地修改一个单一需求.
完整的(Couplete)：没有被遗漏的需求.
一致的 (Consistent)：不存在互斥的需求.
格式:
引言……总体描述……特定需求……
3.6需求规约的作用
第一，是最重要的，作为软件开发组织和用户之间一份事实上的技术合同书；是产品功能及其环境的体现。
第二，对于项目的其余大多数工作，它是一个管理控制点。
第三，对于产品的设计，它是一个正式的、受控的起始点。
第四，是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产生另外两个文档——初始
测试计划和用户系统操作描述。
3.7项目的需求及需求规约
项目需求是客户和开发者之间有关技术合同-产品/系统需求的理解，应记录在工作陈述SOW中或其他某一项目文档（例如，项目管理计划）中。
即需求规约(SRS)应只关注产品需求，即：
产品/系统需求一“交付给客户的产品是什么”
项目的需求(SOW)应关注项目工作与管理，即：
项目需求-“开发组要做的是什么”
chapter4 结构化分析方法
结构化分析：
需求分析的目标
对需求陈述进行分析，解决其中的歧义、不一致等问题以系统化的形式表达用户的需求，即给出问题的形式化或半形式化的描述(称为系统的概念模型，或系统的需求规约或需求规格说明)。作为开发人员和客户间技术契约的基础，并作为而后开发活动的一个基本输入。
2实现软件需求分析的目标对方法学的需求
- **提供一组术语(符号)**，指导需求抽象中需要关注的主要方面，并用于表达分析中所使用的信息。这些术语形成一个特定的抽象层，即需求层。
- 依据这些术语所形成的“空间”，给出表达模型的工具,支持表达系统功能形态。
- 给出过程指导，以支持系统化地使用相关信息建造系统模型。
基本术语：
模型表达工具
数据流图：
数据字典：定义数据流和数据存储
加工小说明：
- 结构化自然语言
- 判定表
- 判定树
结构化方法：
结构化分析方法：
结构化设计方法
结构化程序设计方法
chapter5
chapter6
chapter7
chapter8 软件测试
chapter9 软件项目管理
Chapter10 软件开发工具与环境
wechat
alipay
