软件工程学习笔记（全）

文章目录

• • 1.软件的概念
  • • 软件的特点：
    • 请用你所见、所闻、所经历的事例来描述软件危机的现象或表现。
    • 软件工程定义
    • 软件工程与计算机科学有什么不同/li>
    • 软件的生命周期
    • 软件生命周期方法学
    • 软件工程的基本原理
    • 软件的伦理道德
  • 2. 软件的过程
  • • 软件过程活动
    • 软件过程模型的概念
    • RUP的基本策略与特点
    • 敏捷开发
    • 极限编程（XP Extreme Programming， Kent Beck 2000）
    • • 结对编程
    • 测试团队和开发团队是否应该处在一个团队中，应该是怎样一种管理结构/li>
  • 3. 软件需求
  • • 可行性研究
    • 需求工程概述
    • 需求规约与建模（Requirements specification）
    • 需求的获取
    • 需求分析
    • 需求验证与确认
    • 讨论快速原型与需求评审
    • 需求管理
  • 4. 面向对象范型
  • • 讨论面向对象范型
    • UML（Unified Modeling Language 统一建模语言）
    • 讨论用例图（case diagram）
    • 一个类可能有多于一个状态图/li>
  • 5. 软件生命周期
  • • 你认为哪种软件生命周期模型最好什么/li>
  • 6. 软件测试
  • • 软件测试原则
    • 测试的基本概念
    • 软件测试的步骤
  • 7. 软件维护
  • • 软件维护的目的和任务
    • • 改正性维护
      • 适应性维护
      • 完善性维护
      • 预防性维护
    • 影响软件可维护性的因素
    • 软件维护的过程
    • 你愿意一直做维护工作吗
  • 8. 软件项目管理
  • • 软件项目管理的任务与内容
    • 成本估计

1.软件的概念

软件的特点：

1. 软件是抽象的，是一种逻辑实体而不是一种物理实体。
2. 软件是不会因为使用而损坏的。
3. 软件是可以被拷贝的。（portable）
4. 软件是复杂的。
5. 软件是昂贵的。

请用你所见、所闻、所经历的事例来描述软件危机的现象或表现。

1. 对软件开发成本和进度的估计常常很不准确。
2. 用户对已完成的软件不满意的现象时有发生。
3. 软件产品的质量往往是靠不住的。
4. 软件常常是不可维护的。
5. 软件通常没有适当的文档资料。
6. 软件成本在计算机系统总成本中所占比例逐年上升。
7. 软件开发生产率提高的速度远跟不上日益增长的软件需求

软件工程定义

1. 软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发和维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
2. 软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。

软件工程与计算机科学有什么不同/h3>

1、计算机科学与技术：涉及大数据技术导论、数据采集与处理实践（Python）、Web前/后端开发、统计与数据分析、机器学习、高级数据库系统、数据可视化、云计算技术、人工智能、自然语言处理、媒体大数据案例分析、 络空间安全、计算机 络、数据结构、软件工程、操作系统等方面

2、软件工程：涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。

二、软硬件不同

1、计算机科学与技术：既有软件技术，也包括硬件技术。

2、软件工程：偏向软件技术。

三、就业领域不同

1、计算机科学与技术：主要就业领域是从事 络工程领域的设计、维护等工作和软件信息技术领域的技术开发、教学、科研及管理等工作。

2、软件工程：主要就业领域是软件信息技术领域的技术开发工作和金融领域的经济管理工作。

软件的生命周期

一个软件从定义，使用，开发，维护，直到最终被废弃为止的整个过程。

软件生命周期方法学

基本思想：从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。
前阶段任务的完成是后阶段工作开始的前提与基础，后阶段任务是前阶段的具体与细化。
优点：各阶段任务相对独立，便于分工协作，降低开发工作的难度，便于科学组织与管理；保证了产品的质量，提高了可维护性。

软件工程的基本原理

1. 用分阶段的生命周期计划严格管理

这一条是吸取前人的教训而提出来的。统计表明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。 Boehm 认为，在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。

2. 坚持进行阶段评审

统计结果显示： 大部分错误是在编码之前造成的，大约占63%; <2> 错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级。 因此，软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误。

3. 实行严格的产品控制

开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们，需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制，又叫基准配置管理。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。

4. 采纳现代程序设计技术

从六、七时年代的结构化软件开发技术，到最近的面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大似气力。采用先进的技术即可以提高软件开发的效率，又可以减少软件维护的成本。

5. 结果应能清楚地审查

软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。

6. 开发小组的人员应少而精

开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多； 当开发小组为N人时，可能的通讯信道为N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。

7. 承认不断改进软件工程实践的必要性

遵从上述六条基本原理，就能够较好地实现软件的工程化生产。但是，它们只是对现有的经验的总结和归纳，并不能保证赶上技术不断前进发展的步伐。因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题 告统计。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。

软件的伦理道德

3. 产品：软件工程师要保证其产品即相关组件达到尽可能高的行为标准。
4. 判断力：软件工程师要具备公正独立的职业判断力。
5. 管理：软件工程管理者和领导者应当维护并提倡合乎道德的软件的管理方法。
7. 同事：软件工程师要公平的对待和协助每一位同事。
8. 个人：软件工程师应当毕生学习专业知识，倡导合乎职业道德的职业方式。

2. 软件的过程

软件过程活动

软件过程模型的概念

软件过程模型（software process model）是软件开发全部过程，活动和任务的结构框架，它能直观表达软件开发全过程，明确规定要完成的主要活动，任务和开发策略。

优点：

1. 软件逐次交付，每次增量交付过程中获取的经验，有利于后面的改进，客户也有机会对建立好的模型作出反应。
2. 用户可以更好的获得收益。
3. 核心功能先被开发，降低了项目失败的可能性。
4. 风险分布到几个更小的增量中，而不是集中于一个大型开发中。

缺点：

1. 系统体系结构非常重要，需要良好的可扩展性架构设计，这是增量开发成功的基础。

---

3. 原型模型（Prototype Model）

原型模型是一个软件系统的初期版本，用于展示概念，验证设计方案，发现存在的问题和寻找可能的解决方法。


1. 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。
2. 减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险。
3. 在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。

缺点

1. 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
2. 过多的迭代次数会增加开发成本，延迟提交时间。

RUP的基本策略与特点

极限编程（XP Extreme Programming， Kent Beck 2000）

极限编程是目前最为流行的敏捷开发方法。该方法推行最佳工程实践，如迭代式开发，结对编程，测试驱动开发等，致力于积极响应用户需求变化，并能高效率的开发出高质量软件。。

XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观 是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

具体可以点击这里–>极限编程

结对编程

1. 两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。且角色一直互换。
2. 项目开发中会不断的更换合作伙伴。

优点：

1. 编码，设计和测试至少被另外一个人检查过，代码，设计和测试的质量提高。
2. 增强了彼此之间的沟通。

测试团队和开发团队是否应该处在一个团队中，应该是怎样一种管理结构/h3>

不应该，软件的成功不仅需要开发人员的设计和实现。而且还需要测试人员去做测试找出bug，避免在用户使用时出现较多错误，影响用户体验度。在一个团队中，大家均是为了完成这个软件，难免会有漏洞，只有独立开，专以找出软件的漏洞为职责，才能更好地修复软件。

3. 软件需求

软件需求是待开发系统特征的描述，即提供的服务及运行时满足的约束条件。

可行性研究

可行性研究的主要任务是”了解客户的要求及现实环境，从技术，经济和 会因素等三方面研究并论证本软件项目的可行性，编写可行性研究 告，制定初步项目的开发计划。“

• ：对待开发的项目的功能，性能和限制条件进行分析，确认现有的资源（硬件，软件，技术人员水平，已有的工作基础）条件下，项目能否实现。
• ：对待开发的项目的开发成本与预期收益进行评估，确定该项目是否值得去投资开发。考虑的问题主要是成本和效益的估算。
• ：待开发项目是否存在着违反法律的（合同，责任，侵权）的潜在因素以及待开发的项目在用户组织内是否行的通，现有的管理体制，人员素质和操作方式是否可行。

讨论用例图（case diagram）

用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

一个类可能有多于一个状态图/h3>

状态图用来描述一个特定的对象所有可能的状态,以及由于各种事件的发生而引起的状态之间的转移和变化。

并不是所有的类都需要画状态图，有明确意义的状态，在不同状态下行为有所不同的类才需要画状态图。

5. 软件生命周期

你认为哪种软件生命周期模型最好什么/h3>

要根据情况而决定，不同情况使用不同的模型。目前有瀑布模型、快速原型模型、增量模型、螺旋模型

1. ，也称软件生存周期模型。
   优点： （1）在软件工程中占有重要地位，它提供了软件开发的基本框架，这比依靠“个人技艺”开发软件好得多。 （2）有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。
   缺点： （1）阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2）由于开发模型是线性的用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； （3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重后果。 适用： （1）在开发时间内需求没有或很少变化； （2）分析设计人员应对应用领域很熟悉； （3）低风险项目（对目标、环境很熟悉）； （4）用户使用环境很稳定；用户除提出需求以外，很少参与开发工作。
2. 优点： （1）可以得到比较良好的需求定义，容易适应需求的变化； （2）有利于开发与培训的同步； （3）开发费用低、开发周期短且对用户更友好。
   缺点： （1）客户与开发者对原型理解不同； （2） 准确的原型设计比较困难； （3） 不利于开发人员的创新。 适用： （1）对所开发的领域比较熟悉而且有快速的原型开发工具； （2）项目招投标时，可以以原型模型作为软件的开发模型； （3）进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的。
3. 优点： （1）采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源； （2）如果核心产品很受欢迎，则可增加人力实现下一个增量； （3）可先发布部分功能给客户，对客户起到镇静剂的作用。
   缺点： （1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构； （2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。 适用： （1）进行已有产品升级或新版本开发，增量模型是非常适合的； （2）对完成期限严格要求的产品，可以使用增量模型； （3）对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。
4. 优点： （1）设计上的灵活性,可以在项目的各个阶段进行变更； （2）以小的分段来构建大型系统,使成本计算变得简单容易； （3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性； （4） 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
   缺点： （1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失； （2）过多的迭代次数会增加开发成本，延迟提交时间。 适用： 只适合于大规模的软件项目

6. 软件测试

软件测试是保证软件质量，提高软件可靠性的关键。

狭义的软件测试定义：为发现软件缺陷而执行程序或系统的过程

广义的软件测试定义：人工或自动地运行或测定某系统的过程，目的在于检验它是否满足规定的需求或弄清预期结果和实际结果间的差别

为什么要做软件测试/p>

• 发现软件缺陷
  • 功能错
  • 功能遗漏
  • 超出需求部分（画蛇添足）
  • 性能不符合要求
• 软件质量高低：是否符合用户习惯、符合用户需求

测试的任务

• 找出
• 定位
• 修改
• 修改后要做回归测试，对已修改的部分进行再次的测试，避免引入新的错误

软件测试原则

软件测试的原则

• 所有的测试都应追溯到用户的需求

• 尽早地和不断地进行软件测试（缺陷具有放大的特点，测试成本随阶段深入而上升）

• 8-2原则

  • 测试中发现的错误80%很可能起源于程序中的20%
  • 提前测试可发现80%，系统测试找出剩余bug的80%（总体的16%），最后的4%可能只有用户大范围长时间使用后才暴露出来
  • 80%的工程用在20%的需求上（即关键需求）

• 软件缺陷的寄生虫性：找到的缺陷越多说明软件遗留的缺陷越多

• 避免自己测试自己的程序

• 回归测试：避免引入新的错误

测试的基本概念

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

白盒测试：已知产品的内部工作过程，可以进行测试证明每种内部操作是否符合设计规格要求，所有内部成分是否经过检查。

黑盒测试和白盒测试区别

软件测试的步骤

适应性维护

你愿意一直做维护工作吗

软件维护是非常重要且有必要的，软件维护是软件生存周期的最后一个阶段，就是要针对用户使用软件产品过程提出的问题而对软件产品进行相应的修改或演化，从而修正错误，改善性能或其他特征，以及使软件适应变化的环境。

软件维护工作的目标是不断地、持续地改进、扩充、完善软件系统，以提高系统运行效率，并尽量延长系统的使用寿命，为用户创造更大的价值。

我不愿意做维护工作。维护工作是一项漫长，艰巨且需要程序员有优秀的专业能力的工作，具体的困难性表现如下：

1. 理解别人写的程序困难，困难程度随软件配置成分减少而迅速增加

2. 要维护的软件往往没有合适的文档或资料不全

3. 绝大多数软件设计时没有考虑将来的修改

4. 软件维护不是一项吸引人的工作

5. 软件人员经常流动，维护不能依靠原开发人员

6. 追踪软件的建立过程非常困难，或根本做不到

8. 软件项目管理

软件项目管理的任务与内容

项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性努力。

项目管理是一系列伴随着项目的进行而进行的，目的是为了确保项目能够达到预期结果的管理行为。

成本估计

软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价，不包括原材料和能源的估计，主要是人的劳动的消耗。