软件工程 | 核心概念

软件工程|核心概念

一、软件与软件危机

1. 软件的概念

1. 软件 = 程序 + 数据 + 文档 + （服务）

   程序 = 数据结构 + 算法

   软件是一种逻辑实体，具备知识性的产品集合；是物理世界的一种抽象化；是一种人脑智力的成果，开发成本昂贵但可复制

2. 软件的分类

1. 系统软件：操作系统，数据库管理系统，驱动程序
2. 应用软件：娱乐软件，个人PC软件
3. 工具软件：文档编辑软件
4. 可重用软件

3. 软件的特点

1. 是对物理世界的抽象化
2. 是开发人员的智力劳动成果
3. 软件具备强烈的个性化特征
4. 软件规模日益庞大，实现的业务逻辑与流程复杂

4. 软件产品的组成

1. 市场需求说明书
2. 客户需求说明书
3. 软件规格说明书
4. 技术设计文档
5. 测试文档
6. 在线帮助
7. 产品发布注释
8. 产品软件包

5. 软件危机的原因

1. 客观因素
   • 需求分析不足
   • 开发周期管理不善
   • 开发过程不规范
   • 质量控制标准规程滞后
   • 软件维护计划被忽视
2. 产业因素
   • 软件产业的作坊式管理
   • 软件企业规模的急剧膨胀

6. 软件危机的根源

1. 大量的需求与生产效率之间的矛盾
2. 软件系统的复杂性与软件开发方法之间的矛盾

7. 如何解决软件危机

1. 采用工程项目管理办法实施软件开发和组织管理
2. 采用成熟的软件开发技术和方法，使用适当的软件工具

二、软件开发与软件工程

1. 软件开发的基本过程

1. 软件计划
2. 软件需求分析
3. 概要设计
4. 详细设计
5. 编程实现
6. 软件测试
7. 运行维护

2. 软件开发的方法

1. 研究什么？软件开发方法研究如何在规定的时间、资金范围内开发出符合用户需求的高质量的软件产品
2. 是什么？软件开发方法是一种使用预先定义的技术集及符号来组织软件生产过程的方法
3. 方法：
   • 面向数据结构的开发方法
   • 面向对象的数据结构开发方法
   • 面向数据流的开发方法
   • 基于模型的方法

3. 软件工程要点

1. 软件工程将系统的、规范的、可度量的方法应用于软件的开发、运行以及维护的过程
2. 软件工程应采用适当的软件开发方法，语言，结构开发软件，使得软件产品标准化，开发人员专业化
3. 采用工程学的观点进行费用计算，制定合理的进度
4. 采用管理科学中的方法进行软件开发管理
5. 采用数学的方法建立软件开发模型与算法研究

4. 软件工程原则

1. 采用合适的软件开发模型
2. 采用合适的设计方法
3. 提供高质量的工程支持
4. 重视开发过程管理

5. 软件工程目标

1. 正确性
2. 可用性
3. 经济型

6. 软件生命周期

1. 可行性分析阶段
2. 需求分析阶段
3. 设计阶段
4. 实现阶段
5. 测试阶段
6. 运行与维护阶段

7. 软件生命周期常见模型

1. 瀑布模型

   将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活

   

   

   • 优点：

     1. 为项目提供了按阶段划分的检查点
     2. 可以在迭代模型中使用瀑布模型
     3. 当前一个阶段完成后，只需要关注后续阶段

   • 缺点

     1. 各阶段都需要输出一些相应的文件，增加了工作量

     2. 用户只有等到开发末期才能看到成果，增加了开发的风险

     3. 最突出的缺点：不适应用户需求的变化，早期的错误 可能要等到开发后期的测试阶段才能发现，带来严重后果

   • 适用环境

     ​ 比如A拥有一家跑车公司，可以给客户自定义生产跑车。有一天一土豪来到A的公司，跟A商谈了一个跑车项目，他们谈好了车型，材料，马力等等细节。之后，A带着团队做了6个月，做成了这架跑车，交给了土豪。可是土豪开了一天之后回来要求重做，原因是当讨论方案的时候，双方都忘记给跑车安尾灯了！但是给跑车安装尾灯，就要涉及到整个车尾的重新设计，就要把整辆车拆掉再重新组装！

     ​ 这个模型显然只适合已经成熟了的项目，团队接手项目之后如庖丁解牛般行云流水。当团队接手了创新项目之后，显然已经不再适合用瀑布模型。

2. V模型

   

   • V模型大体可以划分为以下几个不同的阶段步骤：客户需求分析、软件需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

   • V模型的缺点：V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

3. W模型

   • W模型：就是两个V模型 一个代表测试模型 一个代表开发模型

     

   • W模型 强调

     测试应该伴随整个生命周期，测试的对象不应该仅仅是程序，需求、设计等开发输出的文档也要进行测试

   • 优点：W模型有利于尽早地全面的发现问题。对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

   • 缺点：在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动各自也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型

4. 快速应用开发模型

   快速应用开发是一个增量型的软件开发过程模型，强调极短的开发周期

   

   • 缺点：
     1. 并非所有应用都适合采用RAD，如果一个应用不能被模块化，那么构造应用的构件就无法快速获取
     2. 由于时间约束，开发人员和客户必须在较短的时间内完成一系列的需求分析，沟通配合不当都会导致应用RAD模型的失败
     3. RAD适合于管理信息系统的开发，对于其他类型的应用系统，如技术风险较高、与外围系统的互操作性较高等，不太合适

5. 原型模型

   • 概念：

     ​ 原型模型是先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。主要是通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求。

     ​ 同时，原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应。相对瀑布模型而言，原型模型更符合人们开发软件的习惯，是目前较流行的一种实用软件生存期模型

   • 优点：

     1. 开发人员与用户在原型上达成一致后，减少了风险的发生，减少用户的培训时间，提高用户满意度

     2. 缩短开发周期

     3. 降低成本

   • 缺点：

     1. 大型系统难以进行直接的原型模拟
     2. 容易忽视一些文档工作，造成资源浪费、项目规划、管理困难

   • 适用场所：

     适用于那些不能预先确切定义需求的软件系统的开发

如何从一个需求落实到一个系统设计

参考

如何衡量两个不同设计的好坏

1. 可伸缩性

   当服务的负载增长时，系统能被扩展来满足需求，且不降低服务质量。简单的说，服务是可扩展的，并且扩展的成本是比较合理的。

2. 高可用

   尽管部分硬件和软件会发生故障，整个系统的服务必须是每天24小时每星期7天可用的。一般通过软件和硬件的冗余来实现。

3. 可管理

   整个系统可能在物理上很大，但应该容易管理。需要开发对应的管理工具。

4. 价格有效

   整个系统实现是经济的、易支付的。这点很多人可能会忽略，架构设计需要考虑ROI因素，如果一个架构很好，但成本高得惊人不一定是合适的架构。

如何在各种限制下（人员、时间、资源等）选择其中更合适的设计，以及提升该设计的可拓展性

参考

1. 百度百科—瀑布模型
2. 百度百科—V模型
3. 百度百科—W模型
4. CSDN—原型模型