一、设计模式的概念

设计模式解决的是一类问题。
工厂模式就是为了解决类创建的问题，
适配器模式则是为了解决类接口不匹配的问题。

(1)学习这些模式是一个方面，另一方面更要了解模式中的思想。
(2)设计模式虽然可以使设计变得更精妙，但滥用设计模式会适得其反。

二、设计模式的组成

在描述一个设计模式时，至少需要包含四个方面:
模式名称(Pattern name)、
问题(Problem)、
解决方案(Solution)、
效果(Consequence)。

三、GoF设计模式

(补充)简单工厂

1、写一个工厂类，使用静态方法，根据传参来new不同的产品对象
2、客户端调用这个工厂类的静态方法，就可以获取想要的产品

(1)Factory Method 模式。工厂模式

Factory Method 模式提供了一种延迟创建类的方法，使用 这个方法可以在运行期由子类决定创建哪一个类的实例。
1、写一个抽象工厂类，每个工厂实现类负责将new不同种类的产品。
2、客户端new不同的工厂实现类就可以获得不同的产品。

(2)Abstract Factory 模式。抽象工厂模式

Abstract Factory 又称为抽象工厂模式，该模式主要为解决 复杂系统中对象创建的问题。抽象工厂模式提供了一个一致的对象创建接口来创建一系列具 有相似基类或相似接口的对象。
1、写一个抽象工厂类，然后每个工厂实现类负责new一组不同的种类的产品。
2、客户端new需要某一组的产品，只需要new一个工厂即可。

(3)Builder 模式。建造者模式

Builder 模式与 Abstract Factory 模式非常类似，但 Builder 模式是逐步地构造出一个复杂对象，并在最后返回对象的实例。Builder 模式可以把复杂对象的创建与表示分离，使得同样的创建过程可以创建不同的表示。
1、Builder：给出一个抽象接口，以规范产品对象的各个组成成分的建造。这个接口规定要实现复杂对象的哪些部分的创建，并不涉及具体的对象部件的创建。
2、ConcreteBuilder：实现Builder接口，针对不同的商业逻辑，具体化复杂对象的各部分的创建。在建造过程完成后，提供产品的实例。
3、Director：调用具体建造者来创建复杂对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建，是一个具体的类。
4、Product：要创建的复杂对象类。

1
2
3
4
5
6
7
8
9

public class Director {
    
    public Product constructProduct(ConcreteBuilder concreteBuilder){
        concreteBuilder.buildBasic();
        concreteBuilder.buildWalls();
        concreteBuilder.roofed();
        return concreteBuilder.buildProduct();
    }
}

(4)Prototype 模式。原型模式

Prototype 模式可以根据原型实例制定创建的对象的种类，并通过深复制这个原型来创建新的对象。Prototype 模式有着同 Abstract Factory 模式和 Builder 模式相同的效果，不过当需要实例化的类是在运行期才被指定的而且要避免创建一个与产品 曾是平行的工厂类层次时，可以使用 Prototype 模式。使用 Prototype 模式可以在运行时 增加或减少原型，比 Abstract Factory 和 Builder 模式更加灵活。

1
2

Prototype pro = new Prototype();
Prototype pro1 = (Prototype)pro.clone();

(5)Singleton 模式。单例模式

Singleton 模式也是一种很有代表性的模式。使用 Singleton 模式 可以保证一个类仅有一个实例，从而可以提供一个单一的全局访问点。

饿汉式

在定义类的静态私有变量同时进行实例化。

1
2
3
4
5
6
7

public class Singleton {  
    private static Singleton instance = new Singleton();  
    private Singleton (){}  
    public static Singleton getInstance() {  
        return instance;  
    }  
}

好处：线程安全；获取实例速度快
缺点：类加载即初始化实例，内存浪费

懒汉式

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Singleton {
    private volatile static Singleton singleton;
    private Singleton (){}
    public static Singleton getSingleton() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

优点：线程安全，进行双重检查，保证只在实例未初始化前进行同步，效率高
缺点：实例非空判断，耗费一定资源

静态内部类

1
2
3
4
5
6
7
8
9

public class Singleton {
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
    private Singleton (){}
    public static final Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

这种方式利用了classloder的机制来保证初始化instance时只有一个线程，但singleton类被装载了，instance不一定被初始化。因为SingletonHolder类没有被主动使用，只有显示通过调用getInstance方法时，才会显示装载SingletonHolder类，从而实例化instance。如果实例化instance很消耗资源，我们想让他延迟加载，此外，我们不希望在Singleton类加载时就实例化，因为不能确保Singleton类还可能在其他的地方被主动使用从而被加载。这个时候，这种方式相比饿汉式就显得更合理。

枚举

1
2
3
4
5

public enum Singleton {  
    INSTANCE;  
    public void whateverMethod() {  
    }  
}

优点：写法简单，天然线程安全，可防止反射生成实例，是Effective Java作者Josh Bloch提倡的方式。

(6)Adapter 模式。适配者模式

Adapter 模式可以解决系统间接口不相容的问题。通过 Adapter 可以把类的接口转化为客户程序所希望的接口，从而提高复用性。
实现原来的接口，方法体却是另一个对象的实现。

接口适配

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

interface Mp4{
    void playMp4();
}
interface Avi{
    void playAvi();
}
class VideoPlayer implements Mp4{
    @Override
    public void playMp4() {
        System.out.println("播放Mp4格式的视频文件.");
    }
}
class FormatFactory extends VideoPlayer  implements Avi{    
    @Override
    public void playAvi() {
        //转换成MP4格式的视频
        playMp4();
    }
}
public static void main(String[] args) {        
    Mp4 mp4=new VideoPlayer();
    mp4.playMp4();
    Avi avi=new FormatFactory();
    avi.playAvi();
}

类适配

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class FormatFactory2 implements Rvmb{
    private Mp4 mp4;
    public FormatFactory2(Mp4 mp4) {
        this.mp4=mp4;
    }
    @Override
    public void playRvmb() {
        mp4.playMp4();
    }
}
public static void main(String[] args) {
    Rvmb rvmb=new FormatFactory2(new VideoPlayer());
    rvmb.playRvmb();
}

(7)Bridge 模式。桥接模式

Bridge 模式把类的抽象部分同实现部分相分离，这样类的抽象和实现都可以独立地变化。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

interface Pen{
    void write();
}
class RedPen implements Pen{
    @Override
    public void write() {}
}
abstract class  Paper{
    protected  Pen pen;
    void setPen(Pen pen){
        this.pen=pen;
    }   
    abstract void writing();
}
class ExaminationPaper extends Paper{
    @Override
    void writing() {}
}
public static void main(String[] args) {
    Paper paper=new ExaminationPaper();
    paper.setPen(new RedPen());
    paper.writing();
}

(8)Composite 模式。复合模式

Composite 模式提供了一种以树形结构组合对象的方法，使用Composite 可以使单个对象和组合后的对象具有一致性以提高软件的复用性。

(9)Decorator 模式。装饰模式

Decorator 模式可以动态地为对象的某一个方法增加更多的功能。在很多时候，使用 Decorator 模式可以不必继承出新的子类从而维护简洁的类继承结构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public interface Beverage{} // 饮料接口
public class CoffeeBean implements Beverage{} // 具体被装饰的对象类
public class Decorator implements Beverage{} // 装饰类
public class Milk extends Decorator{ // 具体装饰类，给咖啡加入牛奶
	private String description = "加了牛奶！";
	private Beverage beverage = null;
	public Milk(Beverage beverage){
		this.beverage = beverage;
	}
	public String getDescription(){
		return beverage.getDescription()+"\n"+description;
	}
}
public static void main(String[] args) {
    Beverage beverage = new CoffeeBean();
    beverage = new Milk(beverage); // 给咖啡加了牛奶
    System.out.println(beverage.getDescription());
}

(10)Facade 模式。外观模式，门面模式

Facade 模式为一组类提供了一致的访问接口。使用 Facade 可以 封装内部具有不同接口的类，使其对外提供统一的访问方式。Facade 模式在 J2EE 系统开 发中发展为 Session Facade 模式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class FacadePattern {
    public static void main(String[] args) {
        Facade f = new Facade();
        f.method();
    }
}
class Facade { //外观角色
    private SubSystem01 obj1 = new SubSystem01();
    private SubSystem02 obj2 = new SubSystem02();
    private SubSystem03 obj3 = new SubSystem03();
    public void method() {
        obj1.method1();
        obj2.method2();
        obj3.method3();
    }
}

(11)Flyweight 模式。享元模式，共享元素

Flyweight 模式可以共享大量的细粒度对象，从而节省创建对象 所需要分配的空间，不过在时间上的开销会变大。

1
2
3
4
5
6
7
8

public Flyweight factory(int state){
    if(map.containsKey(state)){
        return (Flyweight)map.get(state);
    }else{
        map.put(state, new ConcreteFlyweight(state));
        return (Flyweight)map.get(state);
    }
}

(12)Proxy 模式。代理模式

Proxy 模式为对象提供了一种访问代理对象，通过对象 Proxy 可以控制客户程序的访问。例如:访问权限的控制、访问地址的控制、访问方式的控制等， 甚至可以通过 Proxy 将开销较大的访问化整为零，提高访问效率。

1
2
3
4

Customer customer=new Customer();
customer.setCash(120000);
BuyCarProxy buyCarProxy=new BuyCarProxy(customer);
buyCarProxy.buyCar();

(13)Interpreter 模式。解释器模式

定义了一个解释器，来解释遵循给定语言和文法的句子。
只需要向计算机输入一个句子或文件，就能按照预定的文法规则来对句子或文件进行解释。
例如输入“1+2+3-4+1”时，将输出计算结果为3。

(14)Template Method 模式。模板方法模式

定义一个操作的模板，其中的一些步骤会在子类中实现，以适应不同的情况。
在父类中定义处理流程的框架，在子类中实现具体的处理方式。

(15)Chain of Responsibility 模式。责任链模式

Chain of Responsibility 模式把可以响应请求的对象 组织成一条链，并在这条对象链上传递请求，从而保证多个对象都有机会处理请求而且可以 避免请求方和相应方的耦合。

一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个：一个是承担责任，二是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又把责任向下传的情况。

在一个纯的责任链模式里面，一个请求必须被某一个处理者对象所接收；在一个不纯的责任链模式里面，一个请求可以最终不被任何接收端对象所接收。纯的责任链模式的例子是不容易找到的，一般看到的例子均是不纯的责任链模式的实现。

(16)Command 模式。命令模式

将请求封装为对象，从而增强请求的能力，如参数化、排队、 记录日志等。

Command有时也被称为事件（event）。它与“事件驱动编程”中的“事件”是一样的意思。当发生点击鼠标、按下键盘按键等事件时，我们可以先将这些事件作成实例，然后按照发生顺序放入队列中。接着，再依次去处理它们。在GUI（graphical user interface）编程中，经常需要与“事件”打交道。即为在有多个命令，并且这些命令有一定的逻辑顺序，且可能需要保存的这些命令的数据，那么可以使用Command设计模式。

(17)Iterator 模式。迭代器模式

Iterator 模式提供了顺序访问一个对象集合中的各元素的方法， 使用 Iterator 可以避免暴露集合中对象的耦合关系。

(18)Mediator 模式。仲裁者模式、中介者模式

Mediator 模式可以减少系统中对象间的耦合性。Mediator 模式 使用中介对象封装其他的对象，从而使这些被封装的对象间的关系就成了松散耦合。

例如：QQ聊天

(19)Memento 模式。备忘录模式

Memento 模式提供了一种捕获对象状态的方法，且不会破坏对 象的封装。并且可以在对象外部保存对象的状态，并在需要的时候恢复对象状态。

1
2
3
4
5
6
7
8

public static void main(String[] args) {
    List<Memento> savedTimes = new ArrayList<>();
    Life life = new Life();
    life.set("3000 A.D.");
    savedTimes.add(life.saveToMemento());
    life.set("4000 A.D.");
    life.restoreFromMemento(savedTimes.get(0));
}

(20)Observer 模式。观察者模式

Observer 模式提供了将对象的状态广播到一组观察者的方式， 从而可以让每个观察者随时可以得到对象更新的通知。

(21)State 模式。状态模式

State 模式允许一个对象在其内部状态改变的时候改变它的行为。

1
2
3
4
5
6
7
8
9
10
11
12
13

public void setState(State state) {
    System.out.println("订单信息已更新！");
    this.state = state;
    this.state.handle();
}
public static  void  main(String [] args) {
    Context context = new Context();
    context.setState(new Booked());
    context.setState(new Payed());
    context.setState(new Sended());
    context.setState(new InWay());
    context.setState(new Recieved());
}

(22)Strategy 模式。策略模式

使用 Strategy 模式可以让对象中算法的变化独立于客户。

1
2
3
4
5

状态模式和策略模式的不同点：
策略模式中，类的功能是根据当前条件主动更改；
状态模式中，类的功能是被动由当前状态更改；
策略模式中每个行为或算法之间没有关联；
状态模式中的状态之间有关联，并且状态本身控制着状态转移；

(23)Visitor 模式。访问者模式

表示对某对象结构中各元素的操作，使用 Visitor 模式可以在不改
变各元素类的前提下定义作用于这些元素的新操作。

双重分发

四、其他设计模式

(1)Intercepting Filter 模式。拦截过滤器模式

在 J2EE 的 BPS(Basic Programming System，基本编程系 统)应用框架下，在真正响应客户端请求前经常需要进行一些预处理，如客户身份验证、客 户 Session 的合法性验证、字符集转码、客户请求记录等。

(2)Session Facade 模式。

在 J2EE 开发领域，人们把Session Bean 和 Facade 模式结合起来， 封装业务逻辑的接口，形成了 Session Facade 模式。

五、设计模式与软件架构

软件架构更倾向于从整体和全局上描述软件的组成。
设计模式更侧重于类与类、对象与对象之间的关系。
设计模式和软件架构是面向不同层次问题的解决方案。

六、设计模式分类

设计模式分为三类，分别为创建型、结构型和行为型。

一般的项目管理可以分为范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理 9 个知识领域。

对于软件的开发管理来讲，软件范围管理、软件进度管理、软件成本管理、软件配置管理(属于整体管理)、软件质量管理、软件风险管理、开发人员管理(属于人力资源管理)7 个方面的管理尤为重要

一、项目范围管理

目的是控制项目的全部活动都在需求范围内，以确保项目资源的高效利用。

它主要包括项目启动、范围计划编制、范围定义、范围核实和范围变更控制 5 个部分的内容。

当范围定义不明确时，不可避免的变更会使最终 项目成本大大超出预算，因为这些不可避免的变更会破坏项目节奏，导致返工、增加项目历 时、降低生产率和工作人员的士气。

二、项目成本管理

软件项目的成本不仅包括开发成本，也包括开发之前立项阶段及软件在运行中的费用。此外，操作者的培训费用和项目所使用的各种硬件设施费用也都是整个项目成本的一部分，这些成本都需要很好地计划和控制。

项目成本管理包括资源计划编制、成本估算、成本预算、成本控制 4 个主要部分内容。

三、项目时间管理

时间管理包括确保项目按时完成所需的各个过程。

它包括活动定义、活动排序、活动历时估算、进度计划编制、进度控制 5 个部分内容。

需求变更

进行需求变更控制的主要依据是项目计划、变更请求和反映项目执行状况的绩效报告。

为保证项目变更的规范性和项目的有效实施，通常软件开发机构会采取如下措施。

(1)项目启动阶段的变更预防。

基准文件定义的范围越详细、清晰，用户跟项目经理的分歧就越少。
如果需求做得好，文档清晰且有客户签字，那么后期客户提出的变更超出了合同范围，就需要另外处理。

(2)项目实施阶段的需求变更。

“需求变更是必然的、可控的、有益的”

需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为 必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一条:需求变，软件开 发的投入也要变。

需求的变更要经过出资者的认可，使需求的变更有成本的概念。这样项目实施涉及各方就能 够慎重地对待需求的变更。

小的需求变更也要经过正规的需求管理流程。在实践中，人们往往不愿意为小的需求变更去 执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才使需 求逐渐变为不可控，最终导致项目的失败。

需求跟踪

(1)确定需求变更控制过程。

制定一个选择、分析和决策需求变更的标准过程，所有的需求变更都需遵循此过程。

(2)进行需求变更影响分析。

评估每项需求变更，以确定它对项目计划安排和其他需求的影响，明确与变更相关的任务，并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。

(3)建立需求基准版本和需求控制版本文档。

确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。

(4)维护需求变更的历史记录。

将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。

(5)跟踪每项需求的状态。

可以把每一项需求的状态属性(如已推荐的，已通过的，已实施的，或已验证的)保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。

随着软件规模和复杂性的增大，许多大型开发项目往往都会延迟和超出预算，软件开发 不得不直面越来越多的问题，表现为开发的环境日益复杂，代码共享日益困难，需跨越的平 台增多;软件的重用性需要提高;软件的维护越来越困难。

软件配置管理(Software Configuration Management，SCM)，其主要作用是通过结构化的、有序化的、产品 化的管理软件工程的方法来维护产品的历史，鉴别和定位产品独有的版本，并在产品的开发 和发布阶段控制变化;通过有序管理和减少重复性工作，配置管理保证了生产的质量和效率; 它涵盖了软件生命周期的所有领域并影响所有数据和过程。

一、软件配置管理的概念

SCM 是指在软件系统中确定和定义构件(源代码、可执行程序、文档等)，在整个生命周期中控制发布和变更，记录和报告构件的状态 和变更请求，并定义完整的、正确的系统构件的过程。

在 IEEE 标准 729-1983 中，软件配置管理包括以下几个方面功能:

配置标识

产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。

版本控制

过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的 修改。例如，它将解决哪些修改会在该产品的最新版本中实现的问题。

状态统计

记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。例如， 它将解决修改这个错误会影响多少个文件的问题。

审计和审查

确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件 集合。例如，它将解决目前发布的产品所用的文件的版本是否正确的问题。

生产

对产品的生产进行优化管理。它将解决最新发布的产品应由哪些版本的文件和工具来 生成的问题。

过程管理

确保软件组织的规程、方针和软件周期得以正确贯彻执行。它将解决要交付给用 户的产品是否经过测试和质量检查的问题。

小组协作

控制开发统一产品的多个开发人员之间的协作。例如，它将解决是否所有本地程 序员所做的修改都已被加入新版本的产品中的问题。

而在另外一个标准 ISO9000.3 中，对软件配置管理系统做了如下要求:

唯一地标识每个软件项的版本;
标识共同构成一个完整产品的特定版本的每一软件项的版本;
控制由两个或多个独立工作的人员同时对一个给定软件项的更新;
按要求在一个或多个位置对复杂产品的更新进行协调;
标识并跟踪所有的措施和更改;
这些措施和更改是在从开始直到放行期间，由于更改请求或问题引起的。

版本管理应完成以下主要任务:

建立项目;
重构任何修订版的某一项或某一文件;
利用加锁技术防止覆盖;
当增加一个修订版时要求输入变更描述;
提供比较任意两个修订版的使用工具;
采用增量存储方式;
提供对修订版历史和锁定状态的报告功能;
提供归并功能;
允许在任何时候重构任何版本;
权限的设置;
晋升模型的建立;
提供各种报告。

二、软件配置管理的解决方案

常用的软件配置管理工具，主要有如下产品:Rational ClearCase，Merant PVCS， Microsoft VSS，CVS。

三、软件文档管理

1.软件文档的作用

(1)管理依据。
(2)任务之间联系的凭证。
(3)质量保证。
(4)培训与参考。
(5)软件维护支持。
(6)历史档案。
(7)销售可能。

2.文档的归类

软件文档大致可分为 3 类:开发文档;管理文档;产品文档。

(1)开发文档。

软件需求、软件设计、软件测试、保证软件质量的一类文档

(2)产品文档。

关于软件产品的使用、维护、增强、转换和传输的信息。

(3)管理文档。

项目开发计划、测试计划;
开发过程的每个阶段的进度和进度变更的记录;
软件变更情况的记录;
相对于开发的判定记录;
开发人员职责定义;
测试报告、开发进度月报;
项目开发总结等。

内部文档包括项目开发计划、需求分析、架构设计说明、详细设计说明、构件索引、构件成分说明、构件接口及调用说明、构件索引、构件接口及调用说明、类索引、类属性及方法说明、测试报告、测试 统计报告、质量监督报告、源代码、文档分类版本索引和软件安装打包文件等。

外部文档主要包括软件安装手册、软件操作手册、在线帮助、系统性能指标报告和系统操作索引等。

3.文档编制计划

文档计划一般包括以下几方面内容:
列出应编制文档的目录;
提示编制文档应参考的标准;
指定文档管理员;
提供编制文档所需要的条件，落实文档编写人员、所需经费及编制工具等;
明确保证文档质量的方法，为了确保文档内容的正确性、合理性，应采取一定的措施，如评审、鉴定等;
绘制进度表，以图表形式列出在软件生存期各阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等。
要编制哪几种文档，详细程度如何;
各文档的编制负责人和进度要求;
审查/批准负责人和时间进度安排;
在开发时期内各文档的维护、修改和管理的负责人，以及批准手续。

4.对文档质量的要求

好的软件文档要求具备如下特征：

(1)针对性。

文档编制前应分清读者对象。对不同的类型、不同层次的读者，决定如何满足适应他们的需要。
管理文档主要面向管理人员。
用户文档主要面向用户。

(2)精确性。

文档的行文应当十分确切，不能出现多义性的描述。同一课题几个文档 的内容应当是协调一致、没有矛盾的。

(3)清晰性。

文档编写应力求简明，如有可能，配以适当的图表，以增强其清晰性。

(4)完整性。

任何一个文档都应当是完整的、独立的，它应自成体系。

(5)灵活性。

各个不同软件项目，其规模和复杂程度有着许多实际差别，不能相同看 待。应根据具体的软件开发项目，决定编制的文档种类。

一、软件质量管理

项目质量管理包括保证项目能满足原先规定的各项要求所需要的过程。

总体管理功能中决定质量方针、目标与责任的所有活动，并通过诸如质量规划、质量保证、质量控制、质量改进等手段在质量体系内加以实施。

1、质量计划

判断哪些质量标准与本项目相关，并决定应如何达到这些质量标准。

在软件质量计划阶段应该完成如下活动:

1.对项目的软件质量活动做出计划。
2.对软件产品质量的可测量的目标及其优先级进行定义。
3.确定软件产品质量目标的实现过程是可量化和可管理的。
4.为管理软件产品的质量提供适当的资源和资金。
5.对实施和支持软件质量管理的人员进行实施和支持过程中所要求的培训。
6.对软件开发项目组和其他与软件项目有关的人员进行软件质量管理方面的培训。
7.按照已文档化的规程制订和维护项目的软件质量计划。
8.项目的软件质量管理活动要以项目的软件质量计划为基础。
9.在整个软件生命周期，要确定、监控和更新软件产品的质量目标。

2、质量保证

定期评估项目总体绩效，建立项目能达到相关质量标准的信心。

质量保证应贯穿于项目的始终，在事件驱动的基础上，对软件产品的质量进行测量、分析，并将分析结果与既定的质量标准相比较，以提供质量改进的依据。

如果属于软件外包，还需要对软件产品的定量质量目标进行合理的分工，分派给项目交付软件产品的承包商。

3、质量控制

监测项目的总体结果，判断它们是否符合相关质量标准，并找出如何消除不合格绩效的方法。

软件质量的控制不单单是一个软件测试问题，评审、调试和测试是保证软件质量的重要手段。

质量控制应贯穿于项目的始终。

项目结果既包括产品结果(例如可交付成果)、也包括项目管理结果(例如成本与进度绩效)。

软件质量控制包括如下活动:
1.对软件产品进行测试，并将测试结果用于软件质量管理活动的状态。
2.高级管理者定期参与评审软件质量管理的活动。
3.软件项目负责人定期参与评审软件质量管理的活动。
4.软件质量保证评审小组负责评审软件的质量管理活动和工作产品，并填写相关报告。

评审目标包括如下部分:
1.发现任何形式表现的软件功能、逻辑或实现方面的错误;
2.通过评审验证软件的需求;
3.保证软件按预先定义的标准表示;
4.已获得的软件是以统一的形式开发的;
5.使项目更容易管理。

二、项目风险管理

事前控制——风险管理规划，事中控制——风险管理方法，事后控制——风险管理报告。

1.项目风险管理的概念

(1)内部技术风险:技术变化和创新是项目风险的重要来源之一。

(2)内部非技术风险:公司的经营战略发生了变化相关的战略风险、涉及公司管理/ 项 目管理人员管理水平等的管理风险，以及与范围变更有关的风险;没有按照要求的技术性能 和质量水平完成任务的质量风险;没有在预算的时间范围内完成任务的进度风险;没有在预 算的成本范围内完成任务的成本风险。

(3)外部法律风险:包括与项目相关的规章或标准的变化，如许可权、专利、合同失效、诉讼等。

(4)外部非法律风险:主要是指项目的政治、社会影响、经济环境的变化，组织中雇佣关系的变化，如公司并购、政府干预、货币变动、通货膨胀、税收、自然灾害等。这类风险对项目的影响和项目性质的关系较大。

2.风险管理的过程

1 风险管理规划，决定如何指导和规划项目的风险管理活动。
2 项目风险识别，找到哪些风险可能影响项目，并记录其特征。
3 定性风险分析，完成风险和环境的定性分析，并按其对项目目标的影响进行排序。
4 定量风险分析，度量风险的可能性和后果，估量其对项目目标的潜在影响。
5 风险应对计划，创建过程和技术来为项目目标增进机会和减小威胁。
6 风险监督与控制，在项目生命周期中监视现存的风险、识别新的风险、执行缓解风险计划及评估其效果。

(1)风险识别。

(2)风险分析。

风险得失值:

指一旦风险发生可能对项目造成的影响大小，说明可能造成的损失。如果 损失的大小不容易直接估计，可以将损失分解为更小部分再评估它们。风险得失值可用相对 数值表示，建议将损失大小折算成对计划影响的时间表示。

风险概率:

它是风险发生可能性的百分比表示，是一种主观判断。

风险值:

风险值又叫风险曝光度或风险暴露，他是评估风险的重要参数，“风险值”=“风险概率” * “风险影响”。如:某一风险概率是 25%，一旦发生会导致项目计划延长 4 周，因而，风险值为25% * 4周 = 1周。

(3)风险应对方法。

制订风险应对策略主要考虑以下 4 个方面的因素:可规避性、可转移性、可缓解性、可接受性。

(4)风险应对计划。

(5)风险监控。

政府信息化是传统政府向信息化政府的演变过程。具体地说，政府信息化就是应用现代 信息技术、网络技术和通信技术，通过信息资源的开发和利用来集成管理和服务，从而提高 政府的工作效率、决策质量、调控能力，并节约开支，改进政府的组织结构、业务流程和工 作方式，全方位地向社会提供优质、规范、透明的管理和服务。

第一，政府信息化必须借助于信息技术和网络技术，离不开信息基础设施和软件产品;

第二，政府信息化是一个系统工程，它不仅是与行政有关部门的信息化，还包括立法、司法部门及其他一些公共组织的信息化;

第三，政府信息化并不是简单地将传统的政府管理事务原封不动地搬到互联网上，而是要对已有的组织结构和业务流程进行重组或再造。

政府信息化的主要内容是电子政务。因此，在大多数情况下，电子 政务可以作为政府信息化的同义语来使用。

一、我国政府信息化的历程和策略

20 世纪 80 年代末期“中国国家经济信息系统”的建设和运行。

国家经济信息系统包括着重为国家宏观经济服务的主系统，以及各部门各行业的专业经济信息系统在内的全国系统。

20 世纪 90 年代

一是以“金”字头为代表的多项信息工程项目取得了突破性进展。金桥、金关、金卡“三金”工程。
二是政府上网工程初具规模，“十二金”工程。第一类是对加强监管、提高效率和推进 公共服务起到核心作用的办公业务资源系统、宏观经济管理系统建设;第二类是增强政府收 入能力、保证公共支出合理性的金税、金关、金财、金融监管(含金卡)、金审 5 个业务系 统;第三类是保障社会秩序、为国民经济和社会发展打下坚实基础的金盾、金保、金农、金 水、金质 5 个业务系统建设。
三是各级政府都加强了电子政务的软件和硬件两方面的基础建设，建成了覆盖广泛的“两网、一站、四库”。“两网”是指政务内网和政务外网，两网之间物理隔离，政务外网与互联网之间逻辑隔离;“一站”，是政府门户网站;“四库”，即建立人口、法人单位、空间地理和自然资源、宏观经济 4 个基础数据库。
四是各地在推动政府信息化方面健康发展，并在全国普遍实行了 政府上网工程。

政府信息化的一个中心任务是实现由传统政务到电子政务的转变。

(1)做好战略数据规划。
(2)面向主导业务流程。
(3)重视资源条件。
(4)以人为本。
(5)设立 CIO。
(6)加强规范化和标准化。
(7)充分利用社会资源。

二、电子政务的内容

(1)政府与政府(Government To Government)

(2)政府对企业(Government To Business)

(3)政府对公民（G2C）

(4)企业对政府

(5)公民对政府

(6)政府对公务员（G2E）

三、电子政务建设的过程模式和技术模式

1.电子政务建设的过程模式

(1)以用户为中心
(2)引进“客户关系管理”技术
(3)政府门户

2.电子政务的技术模式

(1)网络管理模式
电子政务在网络管理上分为政府专网和通用网络两部分，包括专用网络、内部网络和外部网络。
(2)信息资源管理模式
电子政务可以选用的信息资 源管理模式有多种，目前主要有两种，即元数据管理模式和 XML 数据管理模式。
(3)应用开发模式
(4)电子政务的安全体系
电子政务的安全体系包括物理安全、网络安全、信息安全及安全管理等方面。
(5)电子政务的标准化
《国家电子政务标准化指南》共分为以下六个部分。
第一部分:总则。概括描述电子政务标准体系及标准化的机制。
第二部分:工程管理。概括描述电子政务工程管理须遵循或参考的技术要求、标准和管理规定。
第三部分:网络建设。概括描述网络建设须遵循或参考的技术要求、标准和管理规定。
第四部分:信息共享。概括描述信息共享须遵循或参考的技术要求、标准和管理规定。
第五部分:支撑技术。概括描述支撑技术须遵循或参考的技术要求、标准和管理规定。
第六部分:信息安全。概括描述保障信息安全须遵循或参考的技术要求、标准和管理规定。

六项电子政务标准分别如下:
1 基于 XML 电子公文格式规范第一部分:总则，第二部分:公文体;
2 XML 在电子政务中的应用指南;
3 电子政务业务流程设计方法通用规范;
4 信息化工程监理规范;
5 电子政务数据元第一部分:设计和管理规范;
6 电子政务主题词表编制规则。

知识管理是企业信息化发展的高级阶段，而商业智能则是知识管理的实际应用。

一、知识管理

在组织中建构一个人文与技术兼备的知识系统，让组织中的信息 与知识，通过获得、创造、分享、整合、记录、存取、更新等过程，实现不断创新。同时， 这种创新知识又不断回馈到组织之内，从而使得组织的知识不间断地累积和升华，进而转化 为企业的智慧资本。

知识管理应以人为中心，以信息为基础，以知识 创新为目标，将知识看作一种可开发资源。

知识管理工具的分类

1 用于知识生成的工具

搜索引擎、数据挖掘技术、用于知识合成的工具、辅助创新知识的工具。

2 用于知识编码的工具

知识仓库和知识地图。

3 用于知识转移的工具

二、商业智能

商业智能(Business Intelligence，BI)是企业对商业数据的搜集、管理和分析的系统过 程，目的是使企业的各级决策者获得知识或洞察力，帮助他们做出对企业更有利的决策。

商业智能技术并不是基础技术或者产品技术，它是数据仓库、联机分析处理 OLAP 和数据挖掘等相关技术走向商业应用后形成的一种应用技术。

商业智能系统主要包括数据预处理、建立数据仓库、数据分析及数据展现 4 个主要阶段。

数据预处理

数据预处理是整合企业原始数据的第一步，它包括数据的抽取、转换和装载三个过程。

建立数据仓库

建立数据仓库则是处理海量数据的基础。

数据分析

数据分析是体现系统智能的关键，一般采用联机分 析处理和数据挖掘两大技术。
联机分析处理不仅进行数据汇总/聚集，同时还提供切片、切块、下钻、上卷和旋转等数据分析功能，用户可以方便地对海量数据进行多维分析。
数据挖掘的目标则是挖掘数据背后隐藏的知识，通过关联分析、聚类和分类等方法建立分析模型，预测企业未来发展趋势和将要面临的问题。

数据展现

数据展现则主要保障系统分析结果的可视化。

业务流程重组(BusinessProcess Reengineering，BPR)

一、BPR 的内容

BPR 强调 4 个核心内容，即根本性、彻底性、戏剧性和流程。

二、BPR 的作用

(1)BPR 的实施使企业更贴近市场。
(2)BPR 使生产成本成倍压缩。
(3)BPR 使产品质量得到全面提升。
(4)服务质量更趋完美。

三、BPR 遵循的原则

(1)流程中心原则

BPR 注重的是业务流程整体最优，通过理顺和优化业务流程，使得业务流程 中每一个环节上的活动尽可能实现最大化增值，尽可能减少无效的或不增值的活动，并从整 体最优的目标出发，设计和优化业务流程中的各项活动，消除本位主义和利益分散主义。

(2)团队管理原则

首先是设计、重组业 务流程，而后依据业务流程建立或改造企业组织，尽量消除或弱化“中间层”。这不仅降低 了管理费用和成本，更重要的是提高了组织的运转效率及对市场的反应速度。

(3)客户导向原则

利用信息技术能够有效地帮助企业 BPR 得以很好地实施，采用计算机网络、数据库和多媒体等技术 建立的信息网络，能够加快信息传递，实现信息共享，其结果是将传统的串行工作方式变为 并行工作方式，将企业组织结构由垂直型变为水平型，使企业成为协同工作的组织，使得企 业的业务流程，特别是关键业务流程与市场接通，与顾客接通。
另一方面，科学技术的发展和管理模式的日臻完善，也为 BPR 创造了条件。

信息系统的数据环境

马丁在《信息工程》和《战略数据规划方法学》中将信息系统的数据环境分为 4 种类型：

第一类数据环境:数据文件。
第二类数据环境:应用数据库。
第三类数据环境:主题数据库。
第四类数据环境:信息检索系统。

公司的管理活动

一个公司的管理活动可以分成 4 级:战略级、战术级、操作级和事务级。

战略级的信息系统的所有者和使用者都是企业的最高管理层，对于现代公司制企业， 就是企业的董事会和经理班子;

战术级信息系统的使用者一般是企业的中层经理及其管理的 部门;

操作级信息系统的使用者一般是服务型企业的业务部门，例如，保险企业的保单处理 部门;

事务级信息系统的使用者一般是企业的管理业务人员，例如，企业的会计、劳资员等。

信息系统的生命周期

信息系统的生命周期分为 4 个阶段，即产生阶段、开发阶段、运行阶段和 消亡阶段。

1.信息系统的产生阶段又分为 概念产生过程和需求分析过程。

2.信息系统的开发阶段 可分为 5 个阶段，即，总体规划、系统分析、系统设计、系统实施和系统验收阶段。

3.信息系统的运行阶段
四种类型：排错性维护、适应性维护、完善性维护和预防性维护。

4.信息系统的消亡阶段

信息系统建设的原则

1.高层管理人员介入原则
2.用户参与开发原则
3.自顶向下规划原则
4.工程化原则
5.其他原则
创新性原则，用来体现信息系统的先进性。
整体性原则，用来体现信息系统的完整性。
发展性原则，用来体现信息系统的超前性。
经济性原则，用来体现信息系统的实用性。

信息系统开发方法

1.结构化方法
2.原型法
3.面向对象方法
4.面向服务的方法