组织适应新环境或随时间而改变其行为的概念称为“组织学习”。
信息系统可以是手工的，也可以是计算机化的。
业务活动是业务过程的组织元素，是不可再分的最小功能单元。业务活动之间是相对独立的，有清晰的时空界限，每一个业务活动都应是可执行的，结果是确定的且是唯一的。
信息资源规划的需求分析和软件工程的需求分析，分析的业务范围和数据标准的要求都不同。
电子商务的敏感信息（如：银行账号）使用安全套接字层（SSL）通信协议保护。
基于总线结构减少系统互操作时的转换复杂性，并能使系统的结构变得更加清晰。
4. 软件工程
4.1. 逆向工程&再工程
逆向工程（reverse engineering）概念来自于硬件，目的是分析产品，得出设计，是一个设计恢复的过程。逆向工程的抽象层次分为四层，抽象层次越高，完备性越低。抽象层次由低到高分别为： 1. 导出过程的设计表示文档 2. 导出程序和数据结构信息 3. 导出数据流和控制流模型 4. 导出实体关系模型
逆向工程的最高抽象层次/完备性最低是“导出实体关系模型”（例如：UML状
态图和部署图）。
再工程（re-engineering）不仅能从已有程序中重新获得设计信息，而且还能使用这些信息改建或重构现有系统，以改进综合质量。一般软件人员用再工程重新实现已存在的程序，同时加进新的功能或改善它的性能。
4.2. 统一过程UP
统一过程适合于大中型项目的开发。
分为4个顺序的阶段：初始阶段、细化阶段、构建阶段、移交阶段。 ? 初始阶段：为系统建立业务模型，并确定项目边界。该阶段主要关注业
务和需求方面的主要风险。
? 细化阶段：分析问题领域，建立健全的架构基础，淘汰项目中最高风险
的元素。该阶段，必须在理解整个系统的基础上，对架构做出决策，包括其范围，主要功能，和诸如性能等肺功能需求，同时为项目建立支持环境。
? 构建阶段：主要任务是通过优化资源和避免不必要的保费和返工，使开
发成本降到最低，完成所有所需功能的分析、开发和测试；确定软件、场地和用户是否已经为部署做好准备。
? 交付阶段：确保软件对最终用户可用。主要任务是进行β测试，制作产
品发布版本；对最终用户支持文档定稿；按用户的需求确认新系统；培训用户和维护人员；获得用户对当前版本的反馈，基于反馈调整产品。交付阶段结束时还要进行技术评审，评审目标是否实现，用户对交付产品是否满意等。
4.3. 软件需求
软件需求可以分为几个层次：
? 业务需求（business requirement）：反映组织机构或客户对系统、产品高层
次的目标要求，它们在项目视图与范围文档中予以说明。
? 用户需求（user requirement）：描述用户使用产品必须完成的任务，在用例
文档或方案场景（scenario）说明中予以说明。
? 功能需求（functional requirement）：定义开发人员必须实现的软件功能，使
得用户能完成他们的任务，从而满足业务需求。
? 非功能需求（none-functional requirement）：描述系统展现给用户的行为及
执行的操作等。包括产品必须遵循的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件；质量属性。
所有与需求直接相关的活动称为需求工程。
需求工程的活动可分为两大类：需求开发、需求管理。
? 需求开发：目的是通过调查与分析，获取用户需求并定义产品需求。需
求开发的过程有四个：需求获取、需求分析、需求定义（制定需求规格说明书）、需求验证（获取、分析、定义、验证）。4个阶段不一定是线性关系。
? 需求管理：目的是确保各方对需求的一致理解，管理和控制需求的变更，
以及从需求到最终产品的双向跟踪。需求管理包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
质量功能部署QFD确认了三类需求，分别是： ? 常规需求：基本需求，用户提出的明确的需求；
? 期望需求：隐含在产品或系统中，可能由于非常基础以至于用户没有显示说明的需求；
? 意外需求：兴奋需求，出乎客户意料的东西。
QFD的目的是最大限度提升软件工程过程中客户的满意度。
4.4. 软件测试
从测试阶段划分，可分为三类：
? 单元测试：程序员自己测。单元测试计划应在详细设计阶段制定；
? 集成测试：对由各模块组装而成的程序进行测试，集成的方式分为增量式集
成（渐增式集成）和非增量式集成（整体拼装），渐增式集成又分为自顶向下集成和自底向上集成。集成测试计划应在概要设计阶段制定；
? 确认测试：检查软件的功能、性能及其他特征是否与用户需求一致。确认测
试计划应在需求分析阶段制定。
从测试群体、场地来划分：
? α测试：用户在开发者的场所进行测试，并且在开发者的指导下进行测试。
在受控环境中进行。
? β测试：在用户现场由最终用户实施测试过程，非受控。
从测试方法划分：
? 白盒测试：主要用于单元测试阶段，由程序员负责； ? 黑盒测试：用于集成测试、确认测试阶段。
在纠正的程序中的错误后，还应选择部分或全部原先已测过的测试用例，对修改后的程序重新测试，这种测试称为回归测试。回归测试的目的是检验修改引起的副作用。
4.5. 敏捷
2001年，敏捷宣言： 个体和交互胜过过程和工具， 可工作的软件胜过面面俱到的文档， 客户合作胜过合同谈判， 响应变化胜过遵循计划。
敏捷的主要原则：
? 最优先要做的是尽早、持续地交付有价值的软件来使客户满意；
? 即使到了开发的后期，也欢迎改变需求，利用变化为客户创造竞争优势；
? 经常性交付可以工作的软件，时间间隔越短越好，但不要求每次交付的都是
系统的完整功能；
? 团队内部，最有效的信息传递方法是面对面的交谈。
敏捷的四大价值观：
1. 个体和交互胜过过程和工具；
2. 可以工作的软件胜过面面俱到的文档； 3. 客户合作胜过合同谈判； 4. 相应变化胜过遵循计划。
影响较大的敏捷方法论包括： （1） XP极限编程
? 软件开始初期无需做出很多文档； ? 测试先行，测试驱动；
? 四大价值观：沟通、简单、反馈、勇气。
? 12种最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、程序集成、每周工作40小时、现场客户、编码标准。
? 包括规划、设计、编码和测试4个框架活动的规则和实践。
? 极限编程中使用的重要技术是重构，即包括设计技术的重构，也包括构建技术的重构；
? 提倡在基本设计完成后，团队不应该直接开始编码，而是开发一系列用于检测本次发布的包括所有故事的单元测试（测试先行）。 ? 关键概念之一是“结对编程”。
? 极限编程过程中建立的单元测试应当使用一个可以自动实施的框架，支持代码修改后即使的回归测试策略。
（2） SCRUM