第 一 章 软件工程简介

“上帝是无所不在的，软件呢？”

1.1         什么是软件

通俗地讲，软件是指能够运行在硬件上的程序及其文档。这里的硬件是具有计算能力的设备，包括计算机、手机等很多类型。本书中主要介绍的是计算机及其软件。

软件并不是一个设备的形式出现的，它是运行在设备里面的程序。套用一个流行的词，就是“灵魂附体”，灵魂就是这个软件，体就是硬件。只有被灵魂附了体，这个体才能活过来。硬件只有安装了相应的软件，也才能发挥作用。

（场景：小P孩：哥哥，软件是什么？

               小张：这个…，就是电脑上跑的东东，你打的游戏，上的网站，和MM聊天用的东东…

               小P孩：那我的游戏机里的东东算不算？

               小张：en…，算。

               小P孩：那我的电子手表里的东东算不算？

               小张：en…，en….算。

               小P孩：那我的电子熊里的东东算不算？

               小张：en…，en….，算吧。

               小P孩：那我的…？

               小张（暴走，汗……）

）

1.2         什么是软件工程

软件工程就是用工程化的方法来开发软件。按照权威的定义（IEEE）：软件工程是：（1）将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；（2）在（1）中所述方法的研究。[1]

笔者认为软件工程是指导软件开发的方法，包括软件开发分为哪些过程，每个过程要做哪些事情，怎样去做，如何判定是否做好等一系列方法。

（场景1：小张：老师，什么是软件工程？

                老师：这个都不知道吗!?，去查书上怎么说得！

                小张（俯首帖耳状）：恩，恩。。。

 ）

1.3         软件开发模型

从实践的角度，可以将软件开发大致分为需求获取及分析阶段、设计阶段、编码阶段、测试阶段、部署阶段。每个软件都要经历这些阶段，只是不同的软件经历的方式、时间、次数有所区别。做软件时不光是要熟悉相应的语言、工具、技术，从项目管理者和设计者的角度，还有软件开发过程需要确定。历史上有很多软件开发的过程模型，比如，最传统的瀑布模型、原型方法模型、演化过程模型等等。

（场景：

小张（思考状）：过程模型是什么？能否这么理解：软件工程的开发要有明确的阶段和计划，那么做一个系统时就必须要考虑清楚该如何去做这个项目，如何调研需求、如何安排阶段、如何做出计划。

）

瀑布模型也称为线形模型，它将软件开发过程分为四个步骤：分析、设计、编码和测试。这是一个很经典且应用最广泛的模型。它对软件开发的描述很直观，也是广大IT人员最容易接受的。但是它的主要问题是对于需求必须在开始阶段就能有一个清晰的描述，并且对于其中的问题往往要到使用时才能发现，这两点都是难以接受的。所以项目在开发完成后往往有较大的变化，导致项目延期和成本的增加。

       吸取了瀑布模型的经验和教训，原型方法模型就是要解决软件需求和最终实现的偏差问题。从项目开始后，软件开发人员就和客户一起做需求调研，并根据需求先实现原型系统（可以很简单），属于“抛弃型”系统，用户使用中提出对此原型系统的意见，形成新的需求并修改或重新开发原型系统。以上的过程重复迭代，直到形成最终的实际运行系统。但问题是原型系统往往没有精心设计，在效率和性能等方面存在问题，最终的实际运行系统如果建立在对原型系统的修改上，会导致软件质量欠缺。

       演化过程模型是指无法一次到位地开发出最终系统，而是先开发出第一个版本，满足核心的需求，其余的需求在后续的版本中予以完善。例如增量模型、螺旋模型等。演化过程模型与原型模型都是迭代式的模型，在近些年来取得了越来越多地应用。详细的介绍可以参考软件工程书籍，比如《软件工程，实践者的研究方法》。

       在实际工作中，笔者认为这些模型并无绝对的优劣问题，关键是要能够适合所开发的项目。总的来说，需求是所有软件项目的根本，一切的工作都是围绕着需求来的。所谓的原型方法、演化模型等解决的都是需求能够被清晰定义的问题。

1.4         关于需求分类

       需求可以被分为两类：一是用户结合自己的业务工作提出的需求，属于业务驱动型需求（I型需求），二是技术人员根据自己对市场的理解提出的功能，属于技术驱动型需求（II型需求）。这两类需求的提出者、角度、立场各不相同，处理方式也不想同。举例来讲，做一个企业信息管理系统时，调研企业的工作流程，用户的业务操作、业务流程，审批流程，公文、报表格式等，都是业务驱动型需求。此时软件系统的目的是将传统的管理流程和工作流程予以信息化。

n         关于业务驱动型需求：

（场景１：甲方领导：小张，把我们企业办公信息化了！

              　小张：好的，我们马上开始需求调研。得和贵企业的员工了解他们的日常工作，．．．

　）

       技术驱动型需求是指研发人员灵机一动，想出的虽然不是哪个用户提出的需求，而是创造性提出的想法，能够吸引用户来用。

n         技术驱动型需求

（场景2：某大牛：Oh！伙计们，我有一个想法。我要做一个系统，能够让大家在家里就能看到地球的卫星地图）

              众人：Ahh!!!太牛了！！！

）

1.5         到底用什么开发过程模型

说到这里，笔者给出一种自己使用过的开发过程，因为根本的问题是需求。所以，需求是否被清晰定义成为软件项目的关键问题。

（1）通常来讲，乙方到甲方进行需求调研，需求调研结果形成《需求说明书》，甲乙双方评审通过后作为后续工作的基础。

（2）根据书面的《需求说明书》，快速开发原型演示界面，能够反映需求说明书中的业务流程，基本操作要求，关键数据内容。演示系统可以只是些界面的跳转，主要的目的是给用户直观的系统概念，并确认需求。甲乙双方对演示系统进行评估，并根据需要来修改《需求说明书》。通过演示系统加需求说明书的方式来便于双方明确和确认需求。需求调研基本结束。

（3）根据上述《需求说明书》来设计。包括概要设计与详细设计。概要设计的目的是设计系统框架，技术选型等。详细设计则是要确定系统的接口格式、函数的具体实现流程等等，指导软件开发。

（4）软件开发。开发的过程需要有相应的过程控制机制，代码质量控制机制。

（5）测试。可以分为单元测试、集成测试和系统测试。主要的差别就是测试的代码规模。

（6）部署，就是集成工作，把所开发的软件和第三方软件进行安装部署，形成运行系统。