软件工程入门指南
软件工程入门指南
软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。
软件工程的目标
软件工程的目标是：在给定成本、进度的前提下，开发出具有适用性、有效性、可修改性、可靠性、可理解性、可维护性、可重用性、可移植性、可追踪性、可互操作性和满足用户需求的软件产品。
- 适用性 - 软件在不同的系统约束条件下，使用户需求得到满足的难易程度。
- 有效性 - 软件系统能最有效的利用计算机的时间和空间资源。各种软件无不把系统的时/空开销作为衡量软件质量的一项重要技术指标。很多场合，在追求时间有效性和空间有效性时会发生矛盾，这时不得不牺牲时间有效性换取空间有效性或牺牲空间有效性换取时间有效性。时/空折衷是经常采用的技巧。
- 可修改性 - 允许对系统进行修改而不增加原系统的复杂性。它支持软件的调试和维护，是一个难以达到的目标。
- 可靠性 - 能防止因概念、设计和结构等方面的不完善造成的软件系统失效，具有挽回因操作不当造成软件系统失效的能力。
- 可理解性 - 系统具有清晰的结构，能直接反映问题的需求。可理解性有助于控制系统软件复杂性，并支持软件的维护、移植或重用。
- 可维护性 - 软件交付使用后，能够对它进行修改，以改正潜伏的错误，改进性能和其它属性，使软件产品适应环境的变化等。软件维护费用在软件开发费用中占有很大的比重。可维护性是软件工程中一项十分重要的目标。
- 可重用性 - 把概念或功能相对独立的一个或一组相关模块定义为一个软部件。可组装在系统的任何位置，降低工作量。
- 可移植性 - 软件从一个计算机系统或环境搬到另一个计算机系统或环境的难易程度。
- 可追踪性 - 根据软件需求对软件设计、程序进行正向追踪，或根据软件设计、程序对软件需求的逆向追踪的能力。
- 可互操作性 - 多个软件元素相互通信并协同完成任务的能力。
软件工程的原理
软件工程的七条基本原理：
- 用分阶段的生存周期计划进行严格的管理。
- 坚持进行阶段评审。
- 实行严格的产品控制。
- 采用现代程序设计技术。
- 软件工程结果应能清楚地审查。
- 开发小组的人员应该少而精。
- 承认不断改进软件工程实践的必要性。
软件工程的方法
著名的重量级开发方法：
- ISO9000 - ISO 9000 系列标准是国际标准化组织设立的标准，与品质管理系统有关。
- 能力成熟度模型（CMM） - CMM 涵盖一个成熟的软件发展组织所应具备的重要功能与项目，它描述了软件发展的演进过程，从毫无章法、不成熟的软件开发阶段到成熟软件开发阶段的过程。
- 统一软件开发过程（RUP） - RUP 是一种软件工程方法，为迭代式软件开发流程。
著名的轻量级开发方法：
- 敏捷开发（Agile Development） - 是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
- 极限编程（XP） - 极限编程是敏捷软件开发中最有成效的方法学之一。极限编程技术以沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）和尊重（Respect）为价值标准。
软件需求
软件需求包括三个不同的层次：业务需求、用户需求和功能需求。
**业务需求（Business requirement）**表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（ vision and scope ）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（ project charter 或 market requirement ）文档。
**用户需求（user requirement）**描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
**功能需求（functional requirement）**规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（ behavioral requirement ），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。
**系统需求（system requirement）**用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
软件需求说明书（ SRS ）
软件需求说明书（ SRS ）完整地描述了软件系统的预期特性。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。
除了功能需求外， SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。
- **质量属性（quality attribute）**对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。
- **约束（constraint）**限制了开发人员设计和构建系统时的选择范围。
软件生命周期
软件生命周期（Software Life Cycle,SLC）是软件的产生直到报废或停止使用的生命周期。
- 问题定义 - 要求系统分析员与用户进行交流，弄清“用户需要计算机解决什么问题”然后提出关于“系统目标与范围的说明”，提交用户审查和确认。
- 可行性研究 - 一方面在于把待开发的系统的目标以明确的语言描述出来；另一方面从经济、技术、法律等多方面进行可行性分析。
- 需求分析 - 弄清用户对软件系统的全部需求，编写需求规格说明书和初步的用户手册，提交评审。
- 开发阶段
- 概要设计
- 详细设计
- 编码实现
- 软件测试 - 测试的过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。
- 维护
软件生命周期模型
瀑布模型
瀑布模型（Waterfall Model）强调系统开发应有完整的周期，且必须完整的经历周期的每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等。
瀑布模型思想
瀑布模型核心思想是按工序将问题拆分，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型特点
优点：
- 为项目提供了按阶段划分的检查点。
- 当前一阶段完成后，您只需要去关注后续阶段。
- 可在迭代模型中应用瀑布模型。
- 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
缺点：
- 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
- 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
- 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
- 瀑布模型的突出缺点是不适应用户需求的变化。
适用场景：
是否使用这一模型主要取决于是否能理解客户的需求以及在项目的进程中这些需求的变化程度。对于需求经常变化的项目，不要适用瀑布模型。
螺旋模型
螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型思想
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
- 制定计划 - 确定软件目标，选定实施方案，弄清项目开发的限制条件；
- 风险分析 - 分析评估所选方案，考虑如何识别和消除风险；
- 实施工程 - 实施软件开发和验证；
- 客户评估 - 评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。
螺旋模型特点
优点：
- 设计上的灵活性,可以在项目的各个阶段进行变更。
- 以小的分段来构建大型系统,使成本计算变得简单容易。
- 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
- 随着项目推进,客户始终掌握项目的最新信息, 从而他或她能够和管理层有效地交互。
- 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点：
很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
适用场景：
对于新项目，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更。
软件工程术语
- 里程碑（Milestone） - 在制定项目进度计划时，在进度时间表上设立一些重要的时间检查点，这样一来，就可以在项目执行过程中利用这些重要的时间检查点来对项目的进程进行检查和控制。这些重要的时间检查点被称作项目的里程碑。
- 人月 - 软件开发的工作量单位。如 200 人月，10 个人开发，那算来就是花 20 个月就可完工。
- 基线 - 基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。