前言
考试题型及占比情况：
单选 |
15道题 |
每题2分 |
共30分 |
填空 |
20个空 |
每空1分 |
共20分 |
简答题 |
6道题 |
每题5分 |
共30分 |
综合题 |
2道题 |
每题10分 |
共20分 |
为啥要学这门课？
这门课程的名字由两个词语组成的，软件与工程；字面意思就是把软件开发的工作使用工程的方法进行管理与执行。
软件工程是一种工程师部门使用定义良好的科学原理，方法和程序开发软件产品。软件工程的结果是一个高效，可靠的软件产品。
软件项目管理的范围比软件工程过程更广，因为它涉及到沟通，交付前和交付后的支持等。
目的是让学员基本了解软件产品，软件设计和开发过程，软件项目管理等。在本课程结束后，可以充分理解软件工程的概念。
这门课也是让你从码农蜕变成为项目经理/产品经理甚至更高管理广为的关键。
相比其他专业课来讲；这门课程更加看重“修道”；而其他的什么C++/Java/数据结构...只是“修术”。
本系列的文章在写的时候参考了大佬的文章；内容已经很详细了：
https://blog.csdn.net/weixin_46287713/article/details/124250241
本人在部分章节部分内容做了一些修改；欢迎大家访问原创作者的文章；本文可以作为辅助。
软件工程这门课程；简单的部分其实就是常识，不用深讲，字面意思大家都能理解；难得部分又很抽象，因此本人在总结课程内容的时候也是一度想放弃；幸好有前人的文章可以参考。
但鉴于本人实在是能力有限导致不像其他课程本着自己的意识作为指导，辅以教材和网上资料完成所有内容；本课程大段引用原教程和网上的资料；我只是做了一些汇总，希望能对大家有一些些帮助。
第一章：绪论
1.1 软件工程概念的提出与发展
1.软件工程的概念
软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科。
2.“软件危机”现象
20世纪60年代以来，随着计算机的广泛使用，软件生产率、软件质量远远满足不了社会发展的需求，成为社会、经济发展的制约因素，人们通常把这一现象称为“软件危机”
可以总结为(两低一高；影响社会经济发展)：
- 速度（低）: 软件的发展水平远远滞后于硬件的发展水平，生产率低下，软件制造仍然是一种人工 集约生产方式
- 质量（低）: 软件的质量低下，不能满足用户的需求、适应性差
- 成本（高）: 软件开发成本居高不下
3.软件工程的发展
- 20世纪60~80年代 ：瀑布模型、过程化语言（C语言）、支持工具
- 20世纪80年代~今 ：软件复用技术、软件生产管理、面向对象语言（C++）、CASE
- 近几年 软件复用技术：构件技术、平台技术、需求工程技术、领域分析技术、应用集成技术等。
1.2. 软件开发的本质
本质：不同抽象层术语之间映射，以及不同抽象层处理逻辑之间的映射。 1、软件的概念 计算机软件一般是指计算机系统中的程序及其文档。其中，程序是计算机任务的对象和处理规则的描述；文档是为了理解程序所需的阐述性资料。 2.模型概念 简单地说，模型就是待建模系统的任意抽象，其中包括所有的基本能力、特性或其他一些方面，而没有任何冗余的细节。 进一步说，模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述，通常包含对该系统的描述、对系统内各模型元素以及它们之间关系的语义描述。 3.求解问题的基本途径 为了求解其中的非结构化和半结构化问题，其基本途径是问题建模，问题建模是指运用所掌握的知识，通过抽象，给出该问题的一个结构。 常用的建模手段包括：结构化方法、面向对象方法以及诸多向数据结构方法等。 4.模型的分类 在软件开发中，软件系统模型大体可分为两类：概念模型和软件模型。概念模型是创建在需求层上的，它描述了系统是什么；软件模型是创建在抽象层上的，它描述了实现概念模型的软件解决方案。软件模型可进一步分为设计模型、实现模型和部署模型。
总结
第二章 软件需求与软件需求规约
2.1 需求与需求获取
1.需求定义及其基本特性
一个需求是有关一个“要予构造”的陈述，描述了待开发产品/系统（或项）功能上的能力、性能参数或其他性质。 对于单一一个需求，必须具有五个基本特性： （1）必要的，该需求是用户说要求的； （2）无歧义的，该需求只能用一种方式解释； （3）可测的，该需求是可以进行测试的；（从属于可测量性） （4）可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段； （5）可测量的，该需求是可测量的。 2.功能需求和非功能需求 功能需求规约了系统或系统构件必须执行的功能。 非功能需求：分为性能需求、外部借口需求、设计约束和质量属性需求。 3.需求发现技术 初始发现需求的常用技术，如下所示
名称 |
适用情况 |
成功条件 |
存在风险 |
自悟Introspection |
需求人员不能直接与用户进行交流，自悟就可能是一种切实可行的、比较有吸引力的方法 |
需求人员必须是具有比最终用户还要多的应用领域和过程方面的知识，并具有丰富的想象力 |
无法验证发现的需求是否满足用户的要求，无法验证发现的需求是不是正确的 |
交谈Individual Interview |
客户支持需求人员与最终用户进行有关系统需求的交流 |
依赖于：（1）需求人员是否具有“正确提出问题”的能力；（2）回答人员是否具有“揭示需求本意”的能力 |
在交谈期间所获得的需求可能不断增长，或是以前没有认识到合理需求的一种表现，或是“完美蠕行”病症的体现，可能导致超出项目成本和进度的限制 |
观察Observation |
用户允许需求人员进入用户工作场所，并进行观察，可与有关人员就有关问题进行交流 |
需求人员具有洞察事物本质的能力 |
（1）客户可能抵触这一观察（2）客户可能认为开发者在签约之前，就已经熟悉他们的业务 |
小组会Group Session |
各方组织在管理层面上重视需求工作，并有能力提供人力资源 |
会议组织得当，包括责权分明，参与会议人员具有良好的需求发现能力，并允许发表不同的观点，以便很快的标识需求，揭示需求中存在的问题，并与客户达成共识。 |
如果会议组织不到位，或收到某些客观环境限制，就有可能过多地召开这样的会议，并产生一些互相矛盾的需求。 |
提炼Extraction |
提炼方法是针对已经有了部分需求文档的情况。依据产品的本来情况，可能有很多文档需要重审，以确定其中是否包含相关联的信息 |
已存在项目背景文档以及一些紧密相关的需求文档，并且需求人员具有很好的想象力和需求标识能力，包括熟悉相关的技术标准和法律 |
与自悟方法一样，无法验证发现的需求是否正确。 |
2.2 需求规约
1.需求规约定义及其基本特性
需求规约是一个软件项/产品/系统所有需求陈述的正式文档，它表达了一个软件产品/系统的概念模型、 需求规约一般要满足四个基本特性
（1）重要性和稳定性程度：按需求的重要性和稳定性，对需求进行分级，例如：基本需求、可选需求、期望需求
（2）可修改的：在不过多地影响其他需求的前提下，可以容易地修改一个单一需求。
（3）完整的：没有遗漏的需求。
（4）一致的：不存在互斥的需求。
2.需求规约的表达
在实际工程中，需求规约的表达主要存在三种不同的风格。
（1）非形式化的需求规约。
（2）半形式化的需求规约。
（3）形式化的需求规约。
3.需求规约在软件开发中的作用
（1）需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。
（2）对于项目的其余大多数工作，需求规约是一个管理控制点。
（3）对于产品/系统的设计，需求规约是一个正式的、受控的起始点。
（4）需求规约是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产生另外两个文档——初始测试计划和用户系统操作描述。
本人能力有限，文中内容难免有纰漏，真诚欢迎大家斧正~
喜欢本文的朋友请三连哦！！！
另外本文也参考了网络上其他优秀博主的观点和实例，这里虽不能一一列举但内心属实感谢无私分享知识的每一位原创作者。