第一章 信息系统基础知识

1.2 信息系统建设

1.2.1 信息系统的生命周期

分为4个阶段：系统规划阶段、系统开发阶段、系统运行与维护阶段、系统更新阶段。

1. 信息系统规划阶段。

产生阶段/概念阶段/需求分析阶段。分为两个过程：一个是概念的产生过程，根据企业管理需要，提出建设信息系统的初步想法。二是需求分析过程，对需求进行深入调研和分析，并形成需求分析报告。

2. 信息系统的开发阶段。

• 总体规划阶段。系统开发的起始阶段，基础是需求分析。服从和服务于企业的总体目标和企业的管理决策活动。
• 系统分析阶段。目标是为系统设计阶段提供系统的逻辑模型。以企业业务流程分析为基础，规划信息系统的基本架构，是企业的管理流程和信息流程的交汇点。主要内容包括：功能分析+业务流程分析+数据流程分析+系统初步方案。
• 系统设计阶段。设计信息系统的实施方案。主要内容包括：系统架构设计+数据库设计+处理流程设计+功能模块设计+安全控制方案设计+系统组织和队伍设计+系统管理流程设计。
• 系统实施阶段。将设计文本编程能运行的软件系统（开发+部署实施），是对以前全部工作的检验。用户的参与特别重要，从本阶段开始，用户应逐步变为系统的主导地位。
• 系统验收阶段。通过试运行，对于系统性能的优劣，是否做到用户友好等问题都暴露在用户面前，就进入系统验收阶段。

3. 信息系统运行与维护阶段。

通过验收，正式移交用户后，系统进入运行与维护阶段（对应于项目完成竣工验收）。系统维护分为4种类型：排错性维护、适应性维护、完善性维护和预防性维护。系统运行初期，排错性维护和适应性维护比较多。后期则是完善性维护和预防性维护比较多。

4. 信息系统更新阶段

也称为信息系统消亡阶段。普遍存在的问题：重视开发阶段，请示运行与维护阶段，几乎完全忽视更新阶段。让一个信息系统一劳永逸的运行下去是不现实的，不可避免的会遇到系统更新改造、功能扩展甚至是报废重建。所以在系统建设初期要注意系统的更新条件和时机，以及由此而花费的成本。

1.2.2 信息系统建设原则

1. 高层管理人员介入原则。

原因：一个信息系统其建设的目标总是为企业的总体目标服务的，否则这个系统就不应该建设。真正能够理解企业总体目标的人必然是那些企业高层管理人员，只有他们才知道企业究竟需要什么样的信息系统，而不需要什么样的信息系统。也只有他们才知道企业有多大的投入是值得的，而超过这个界限就是浪费。这两个只有是那些身处某一部门的管理人员或者技术人员都无法具备的。

信息系统从概念到运行都必须有企业高层管理人员介入，可以是直接参与，也可以决策或指导，还可以是在整政治、经济、人事上进行支持。

高层介入原则的具体化就是CIO职位的出现。

2. 用户参与开发原则。

“用户参与开发原则”是“用户第一原则”的具体化。

• 用户有确定的范围。除了通常理解的用户单位的领导之外，更重要的用户或者核心用户是信息系统的使用者。用户单位的领导只不过是辅助用户或者外围用户。
• 用户应当参与全过程的开发。特别是核心用户，应当参与从信息系统概念规划和设计阶段到系统运行的整个过程。在系统交接后，他们就是系统的使用者。
• 用户应当深度参与系统开发。参与开发的用户人员，既要以甲方代表身份出现，又应该称为真正的系统开发人员，与其他开发人员融为一体。

3.自顶向下规划原则。

自顶向下规划的主要目标是达到信息的一致性。同时绝不能取代信息系统的详细设计。应鼓励在总体规划的指导下，进行有创造性的设计。

4.工程化原则。

将信息工程、系统工程等工程化的方法引入到信息系统开发过程中，保证系统的可维护性与可扩展性。

1.2.3 信息系统规划方法

1. 企业系统规划方法，Business System Planning, BSP。采用的工具：UC矩阵。也首先强调目标，但是没有明显的目标引出过程。识别企业过程是BSP方法的中心。
2. 战略数据规划方法。
3. 信息工程方法。
4. 关键成功因素法。Critical Success Factor, CSF。通过CSF确定企业业务的关键信息需求。抓住主要矛盾，是目标的识别突出重点。
5. 战略集合转化法。Strategy Set Transformation, SST。将企业战略集合转化为信息系统的战略集合。反应各种人的要求，保证目标比较全面，但是突出重点方面不如CSF。

在信息系统战略规划的实践中，往往将BSP、CSF、SST三种方法结合起来使用，统称为CSB方法，弥补了单个方法的不足，也使得整个方法过于复杂，削弱了耽搁方法的灵活性。

• 首先用CSF方法确定企业目标。
• 然后用SST方法补充完善企业目标，并将这些目标转化为信息系统目标。
• 用BSP方法校核两个目标，并确定信息系统结构。

1.2.4 信息系统开发方法

1. 结构化方法

结构化系统分析和设计组成的一种信息系统开发方法。目前最成熟、应用范围较广的开发方法。假设被开发的系统是一个结构化的系统，基本**是将系统生命周期划分为系统调查、系统分析、系统设计、系统实施、系统维护等阶段。

主要特点：

• 开发目标清晰化。结构化的系统开发遵循“用户第一”的原则，保持与用户沟通，与用户形成共识，是的信息系统的开发建立在可靠的基础之上。
• 工作阶段程式化。每个阶段的工作内容明确，注重开发过程的控制。每一阶段工作完成后，都要根据阶段工作目标和要求进行审查。
• 开发文档规范化。按照要求完成相应的文档，保证各个工作阶段的衔接与系统维护工作的便利。
• 设计方法结构化。采用自上而下的结构化、模块化分析与设计方法，使各个子系统之间相对独立，便于系统的分析、设计、实现与维护。

2. 快速原型法。

根据用户需求，利用系统开发工具，快速地建立一个系统模型并展示给用户，在此基础上与用户交流，最终实现用户需求的快速开发方法。开发过程包括：系统需求分析、系统初步设计、系统调试、系统检测等阶段。

开发周期短、见效快、与业务人员交流方便的优点。适合用户需求模糊，结构性比较差的信息系统开发。

3. 面向对象方法。

传统的结构化设计方法的基本点是面向过程，系统被分解为若干个过程。而面向对象的方法是采用结构模型的观点，在系统开发过程中，各个步骤的共同目标是建造一个问题域的模型。

安装完xampp后，默认配置下，使用mysql存储中文，发现数据库里的中文都是乱码，如下：

在网上搜索了一下，参考http://blog.csdn.net/u012410733/article/details/61619656

1、执行检查代码
show variables like '%char%';

问题在于默认设置下，character_sert_database 与 character_set_server都是latin1，应该都改成utf8才对。

2、执行调整代码并验证
set character_set_server=utf8;
set character_set_database=utf8;
show variables like '%char%';

完成调整。

3、重新验证，发现还是没法进行修改。

4、查阅资料发现，
mysql 设置变量的范围默认是 session 范围。如果设置多个会话的字符集那么需要设置 global 范围:Set [global|session] variables，但是依然无效，重启后还是会恢复。（写下来是防止以后在遇到了又被坑。）

5、终极方案，修改mysql配置文件my.ini，也得注意有坑。
1）备份my.ini，修改my.ini文件。
2）修改位置：
[mysqld]下面，增加character-set-server=utf8
[mysql]下面，default-character-set=utf8
3）因为我原来的表已经创建了，所以在这里还需要去将news这张表的字符集和所有字符列都修改为新的utf8字符集
ALTER TABLE news CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
4）遇到的坑：
https://fanzheng.org/archives/18
这篇文章中说可以取消注释## UTF 8 Settings下面的那些内容，

结果我重启mysql后报错，无法访问。
5）保存my.ini，重启mysql应用。
6）验证可以正常保存中文数据。

TODO：
英文的视频中，经常使用使用英文单词合并作为slug，这个在目前中文方式下无法实现。

第二章 软件工程基础知识

软件工程专家Boehm于1983年提出软件工程的7条基本原理：

1. 用分阶段的生命周期计划严格管理。
2. 坚持进行阶段评审。
3. 实行严格的产品控制。
4. 采用现代程序设计技术。
5. 结果应能清楚审查。
6. 开发小组的人员应该少而精。
7. 承认不断改进软件工程实践的必要性。

2.1 软件需求分析与定义

需求分析需要引起高度重视。原因：Standish Group对23000个项目进行研究，28%项目彻底失败，46%的项目超出经费预算或超出工期，只有26%的项目获得成功。在74%的不成功项目中，有约60%的失败源于需求问题。

2.1.1 软件需求与需求过程

1. 软件需求包括3个方面：功能需求，非功能需求和设计约束。
2. 需求工程，是一个包括创建和维护系统需求文档所必需的一切活动的过程，通常包括需求开发和需求管理两大工作。

这个阶段的需求规格化的工作是编制**《软件需求规格说明书》**。

2.1.2 需求调查与问题定义

常用的需求捕获技术：

1. 用户访谈。
2. 用户调查
3. 现场观摩
4. 文档考古
5. 联合讨论会

2.1.3 可行性研究

进行可行性研究，其主要的目的是回答一个问题，即所提出的项目是否可以完成。需要注意：可行性研究毕竟不是解决问题，而是研究问题的范围，是否值得解决，现有情况是否有能力，是否有成本效益合算的方案。

可行性研究工作的步骤包括：

1. 核实问题定义与目标。对问题定义进行再次核实，是问题定义更为清晰，没有歧义性。
2. 研究分析现有系统。
3. 为新系统建模。 建模的目的是为了活动一个对新系统的框架认识、概念性认识。常用的几种技术：

• 系统上下文关系范围图。系统与外界实体（可能是人，可能是外部系统）的关系（主要是数据流和控制流）体现出来。
• 实体-关系图（E-R）。系统的数据模型，找到主要的实体，以及实体之间的关系。
• 用例模型。系统的一个动态模型，以Actor和use-case整理出系统的主要功能框架，勾画出系统的雏形。
• 域模型。采用OO**，找到系统中的主要实体类，说明主要特征和之间的关系。
• IPO表。采用传统的结构化**，从输入、处理、输出的角度进行描述系统。

这个阶段的所有模型都是不够精确的，只是一个框架，要达到一个宏观的角度，否则将陷入无休止的工作中。

4. 客户复核。
5. 提出并评价解决方案。
6. 确定最终推荐的解决方案。
7. 草拟开发计划。
8. 以书面形式提交**《可行性分析报告》**并进行审查。

2.1.4 需求分析

1. 需求分析的工作任务，包括以下七个方面：

• 绘制系统上下文范围关系图。

2.1.5 流行的需求分析方法论

2.2 软件设计

2.2.1 软件设计基本原则

2.2.2 结构化设计方法

2.2.3 用户界面设计

2.2.4 设计评审

2.3 软件测试

2.3.1 测试用例设计

2.3.2 软件测试策略

2.3.3 软件测试类型

2.3.4 面向对象的软件测试

2.4 软件维护

2.4.1 软件的可维护性

2.4.2 软件维护的分类

2.4.3 软件维护的工作量

2.4.4 软件维护作业的实施和管理

2.4.5 软件再生工程

2.5 软件开发环境

2.5.1 软件开发环境概述

2.5.2 软件开发环境的功能与分类

2.5.3 软件开发环境的结构

2.5.4 软件开发环境的发展