《软件工程》笔记1

先写一段废话好了。作为一只又懒又菜的...zhu，果然在第一篇写完以后，继续放任自由了4个半月，终于想起来要干点什么，写些什么了。

为什么会从《软件工程》开始呢？虽然求职的时候随大流一股脑儿地扎进了码农的巨坑，但说起来自己对软件这个行业并没有很系统，更不要说深入的了解了，就目前的认知，也仅停留在“开发就是写几行代码”的阶段，这就导致一个很尴尬的问题，跟同样从事软件相关行业，做测试或开发的小伙伴在一起的时候，每次想要和他们更深入地探讨问题时，竟然满脑子迷茫却不知如何表达&并不是很明白他们在说什么而且他们好像也不知道我在说什么...为了能制定出更加明确的职业规划，然后更高效、更欢快地抱大腿，痛定思痛的我决定先系统地了解一下整个行业或者说生产流程。

---

chapter 1 软件工程与软件过程

通过翻看前三章，我觉得作为（测试）菜鸟，先了解一些概念就好。

（1）软件并不仅仅是程序，而是程序、数据及相关文档的完整集合；

其中，数据是指计算机上运行数据时所必需的数据

相关文档则联想到系统测试中，不仅仅要测功能，对功能清单，研制规范都要进行测试，如果需求中描述不正确、不全面、缺少相关指标数据，都是文档类bug

（2）软件工程：指导计算机软件开发和维护的工程科学（这是一门专业！）；

软件工程主要通过回答两个问题来解决软件危机：

①如何开发软件，满足日益增长的需求

②如何维护数量不断膨胀的已有软件

（3）软件生命周期

①问题定义：确定解决什么问题

输出：系统分析员提出关于问题性质、工程目标和工程规模的书面报告，并需要得到客户的确认。

②可行性研究：用最小的代价在最短的时间内确定①中确定的问题是否能解决；

包括经济、技术、社会因素（如法律）等方面的可行性。

③需求分析：与客户沟通，对目标系统提出完整、准确、具体要求（并不涉及怎样实现系统）；

④概要设计：怎样设计系统？提出几种可能方案，确定解决策略及目标系统中应包含的程序（只是概要，不涉及具体实现方法）；

⑤详细设计：怎样具体实现这个系统，确定实现模块功能所需算法、数据结构；

⑥编码、单元测试

单元测试就是对单个模块进行测试，一般由开发自己测

⑦综合测试：集成测试，验收测试

自己的一些理解如下

集成测试：软件设计角度，关心功能是否实现

验收测试（即系统测试？）：发布前的最后一道测试，是站在用户角度，关心需求有没有实现

另外还有交付测试，不是很理解它所处的位置？

⑧软件维护

---

软件产品开发模式

（1）瀑布型：按照上述8个步骤线性完成，一下子完成所有需求，提交用户；

（2）快速原型：做好，提交用户，用户提出意见，修改，再提交用户，以此循环直到用户完全认可；

（3）增量模型：完成一个需求，提交用户，再增加第二个需求，提交用户...；

（4）螺旋模型：可看做在每个阶段之前都增加了风险分析的快速原型模型；

（5）喷泉模型：迭代

迭代开发允许在每次迭代过程中需求发生变化，这种开发方法通过一系列需求细化来加深对问题的理解，因此能更容易地容纳需求变更。

（6）Rational统一过程

（7）敏捷开发：人人都在搞敏捷，不展开了

（8）能力成熟度模型

---

chapter 2 传统方法学

一、结构化分析：用于完成用户需求分析工作。

这里为了叙述简洁，把软件生命周期中的前三项（问题确定、可行性分析、需求分析）合并到需求分析中。因此，需求分析是指发现、求精、建模、规格说明和复审的过程。需求分析第一步是了解用户所处情况，发现用户面临问题。接下来应该通过与用户交流、对用户基本需求反复细化，以得出对目标系统的完整、准确和具体的需求。

（1）详尽了解并正确理解用户需求：访谈；

面向团队的需求收集法：“简易的应用规格说明技术”；

快速建立软件原型是最准确、最有效和最强大的需求分析技术，必须有适当的软件工具支持快速原型技术；

（2）为了更好地理解问题，常采用建立模型方法。通常建立数据模型、功能模型和行为模型。

这里提到了几种图形化技术

①实体——关系图：一般用来建立数据模型

②数据流图：描绘信息流和数据从输入移动到输出的过程中所经受的变换，建立目标系统的功能模型

③状态转换图：通过描绘系统的状态及引起系统状态转换的事件，表示系统的行为，从而提供了行为建模的机制

④数据字典：描述在数据模型、功能模型和行为模型中出现的数据对象和控制信息的特性，给出这些对象的精确定义。

（3）写出“软件需求规格说明”，认真评审后得到用户认可，这也是这阶段最终成果；

---

看理论类的书籍难免枯燥，出于了解的心态，只是贴了一堆概念在这里，目的是为了以后需要查找某个似曾相识的名词时能快速明白，不用到浩瀚厚重的工具书中去摸索。

对，说白了就是懒...