莫等闲

数据规范化 通常用范式定义消除数据冗余的程度。 1）第一范式 2）第二范式 3）第三范式状态转换图 状态转换图通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。 状态： 状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。 事件： 事件是某个特定时刻发生的事情，它是引起系统做动作或状态转换的控制信息。

面向对象设计原则概述面向对象设计原则简介 常用的面向对象设计原则包括7个，这些原则并不是孤立存在的，它们相互依赖，相互补充。 单一职责原则 单一职责原则分析 * 一个类（或者大到模块，小到方法）承担的职责越多，它被复用的可能性越小，而且如果一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作。 * 类的职责主要包括两个方面：数据职责和

过程设计语言（PDL）PDL也称为伪码。 如：if I>0 then 执行订单数据输入模块 else 报告出错信息 end if PDL具有严格的关键字外部语法，用于定义控制结构和数据结构 PDL表示实际操作和条件

软件过程：为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 软件过程（ISO9000）：使用资源将输入转化为输出的活动所构成的系统。输入：如软件需求 输出：如软件产品瀑布模型 1. 阶段间具有顺序性和依赖性 2. 推迟实现的观点 3. 质量保证的观点优点：采用规范的方法；严格规定每个阶段提交的文档；要求每个阶段交出的产品必须经过验证。快速原型模型优点：不

RATIONAL 统一过程 （1）迭代式开发 （2）管理需求 （3）使用基于构件的体系结构 （4）可视化建模 （5）贯穿于开发过程的软件质量验证 （6）控制软件变更敏捷过程与极限编程 1.敏捷过程 具有高效、快速响应变化的开发过程。 （1）个体和交互胜过过程和工具； （2）可以工作的软件胜过面面俱到的文档； （3）客户合作胜过合同谈判； （4）响应变化胜过遵循计划。

实现编码和测试统称为实现。 编码：把软件设计结果翻译成程序,是对设计的进一步具体化。 选择的语言 编码风格 测试：检测程序并改正错误的过程。 单元测试 综合测试编码 选择程序设计语言 计算机程序设计语言基本上可以分为两大类： 1. 汇编语言; 2. 高级语言。 适宜的语言优点： （1）减少测试量 （2）阅读容易，维护方便容易 （3）编码困难减少 考虑重点：

设计模式的诞生与发展模式的诞生与定义 -模式起源于建筑业而非软件业 -模式(Pattern)之父——美国加利佛尼亚大学环境结构中心研究所所长Christopher Alexander博士 -《A Pattern Language: Towns, Buildings, Construction》——253个建筑和城市规划模式 -模式 -Context（模式可适用的前提条件） -Them

可行性研究的步骤 1）复查系统规模和目标； 2）研究目前正在使用的系统； 3）导出新系统的高层逻辑模型（数据流图、数据字典）； 4）重新定义问题； 5）导出和评价供选择的解法（物理解决方案）； 6）推荐行动方案； 7）草拟开发计划； 8）书写文档提交审查。数据字典 数据字典：对数据流图中包含的所有元素的定义的集合；可行性研究阶段，数据流图与数据字典共同构成系统的逻辑模型。数据字典应

GoF设计模式简介 创建型模式 创建型模式概述 - 创建型模式(Creational Pattern)对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。为了使软件的结构更加清晰，外界对于这些对象只需要知道它们共同的接口，而不清楚其具体的实现细节，使整个系统的设计更加符合单一职责原则。 - 创建型模式在创建什么(What)，由谁创建(Who)，何时创建(When)等方

需求分析需求分析的任务确定对系统的综合要求 1.功能需求 2.性能需求 如：相应时间（速度）、主存容量、磁盘容量、安全性、等。 3. 可靠性和可用性需求 4. 出错处理需求 系统发现错误时采取的行动，主要在系统关键部分设置。 5. 接口需求 用户接口、硬件接口、软件接口、通信接口、等。 6. 约束 精度、工具和语言、设计约

测试阶段的信息流单元测试单元测试的一般方法是： 首先通过编译系统检查并改正程序中所有的语法错误； 然后用详细设计模块说明为指南，对重要的控制路径进行测试，以便发现模块内部的错误。 通常，单元测试使用白盒测试方法。 测试重点1）模块接口 应该对穿过模块接口的数据流进行检测，以保证正确的输入和输出。 测试方面：参数数目、次序、属性或单位系统与变元是否一致；是否修改了只作输入

建造者模式——生成器模式 模式动机无论是在现实世界中还是在软件系统中，都存在一些复杂的对象，它们拥有多个组成部分，如汽车，它包括车轮、方向盘、发送机等各种部件。而对于大多数用户而言，无须知道这些部件的装配细节，也几乎不会使用单独某个部件，而是使用一辆完整的汽车，可以通过建造者模式对其进行设计与描述。建造者模式可以将部件和其组装过程分开，一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型就

软件项目管理——Software Management项目管理过程软件项目管理的对象是软件工程项目。它所涉及的范围覆盖了整个软件工程过程。为使软件项目开发获得成功，关键问题是必须对软件开发项目的工作范围、可能风险、需要资源（人、硬件／软件）、要实现的任务、经历的里程碑、花费工作量（成本）、进度安排等做到心中有数。软件项目管理可以提供这些信息。这种管理在技术工作开始之前就应开始，在软件从概念到

CMM模型的内容：管理级的特征 （1）制定了软件过程及产品质量详细而具体的度量标准，软件过程和产品质量可以被理解和控制； （2）组织的能力是可预见的，原因是软件过程被明确的度量标准所度量； （3）具有一致的度量标准来指导软件过程，并作为评价软件过程及产品的定量基础； （4）组织内已建立软件过程数据库，保存收集到的数据，可用于各项目的软件过程。CMM模型的内容：管理级的过程 （1）开始定量地

项目组织管理的评价框架——CMM模型的内容CMM模型的内容：初始级的特征 （1）软件过程杂乱无章，有时甚至混乱，几乎没有定义过程的规则或步骤； （2）过分的承诺。常常作出良好的承诺，如：按照软件工程方式，有序的工程过程来工作，但实际上达不到； （3）遇到危机就放弃原计划过程，反复编码和测试； （4）项目成功完全依赖个人努力和杰出的专业人才； （5）能力只是个人的特性，而不是组织的特性，依靠

软件开发成本估算的经验模型1、静态单变量模型 Effort = f (length of code) 基于LOC/FP （代码行—LOC / KLOC 人月－PM） * 如IBM模型 E ＝ 5.2×L 0.91  L^{0.91} D ＝ 4.1×L 0.36  L^{0.36} ＝ 14.47×E 0.35  E^{0.35} S ＝ 0.54×E 0.6  E^

形式化说明技术按照形式化的程度，软件使用方法： 1.非形式化方法：自然语言描述 2.半形式化方法：数据流图或实体－联系图 3.形式化方法：基于数学技术描述所谓形式化方法，是描述系统性质的基于数学的技术，也 就是说，如果一种方法有坚实的数学基础，那么它就是 形式化的。非形式化方法的缺点 自然语言书写的系统规格说明书可能存在： 1）矛盾：一组相互冲突的陈述； 2）

进度计划 —Software Plan每一个软件项目都要求制定一个进度安排，但不是所有的进度都得一样安排。对于进度安排，需要考虑的是： 预先对进度如何计划？工作怎样就位？如何识别定义好的任务？ 管理人员对结束时间如何掌握？如何识别和监控关键路径以确保结束？对进展如何度量？如何建立分隔任务的里程碑？软件项目的进度安排与任一个工程项目的进度安排基本相同。 首先识别一组项目任务再建

PETRI网 并发系统中遇到一个主要问题：定时问题。定时问题通常是由不好的设计或有错误的实现引起的，而这样的设计或实现通常又是由于不好的规格说明造成的。如果规格说明不恰当，则有导致不完善的设计或实现的危险。概念： PETRI网的组成 Petri网包含4种元素： 1）一组位置P，上例 P＝{P1,P2,P3,P4} 在图中用圆圈代表位置 2）一组转换T，上例 T＝{t1,t2}

人员分配与组织-Personnel1.项目组的角色构成： 在规模化、产业化的软件开发企业中，分工日趋细化，工种及人员角色较为明确。 * 秘书：主要负责维护和管理软件配置中的文档、源代码、数据及所依附的各种磁介质；规范并收集软件开发过程中的数据和可重用软件，对其进行分类并提供检索机制；协助软件开发小组准备文档，对项目中的各种参数，如代码行、成本、工作进度等进行估算；参与小组的管理、协调和软件配

总体设计概要设计任务1．制定规范 2．系统构架设计 3．软件结构设计 4．公共数据结构设计 5．安全性设计 6．故障处理设计 7．可维护性设计 8．编写文档 9．概要设计评审设计原理 模块化 如果一个大型程序仅由一个模块组成，很难被人理解。 设函数C(x)定义问题x的复杂程度，函数E(x)定义解决问题x需要的工作量（时间）。对于两个问题P1和P2，如果：

项目计划 -Project Plan1、内容： * 概 述 一般性地叙述开发项目，描述计划组织，并概述这个文档其余部份的内容。 * 阶段计划 讨论项目开发周期 —— 需求分析阶段、总体设计阶段、详细设计阶段等等。详细说明每个阶段应该完成的日期，并指出不同阶段可以相互重叠的时间等等。 *组织计划 规定从事这个开发项目

启发式规则 人们在开发软件的长期实践中积累了丰富的经验，总结这些经验得到一些启发规则。 常见启发规则： 1. 改进软件结构提高模块独立性（通过模块合并或分解） 2.模块规模应该适中 （一个模块包含的语句超过30条语句，理解程度下降） 3. 深度、宽度、扇出和扇入都应适当 深度：软件结构中控制的层数；（深度和程序长度应有粗略的对应关系） 宽度：软件结构内同一个层次上的模

项目组织管理的评价框架——CMM模型如何评价一个软件组织的软件开发能力、组织管理水平？如何为软件组织指出其改进的方向与措施，以便帮助其提高自己的软件开发能力及组织管理水平？为解决上述问题，美国软件工程研究所（SEI）提出了软件组织的能力成熟度模型（Capability Maturity Model for Software, CMM）项目组织管理的评价框架——CMM概述 人们逐步认识到：软件开发中

详细设计 目标：确定如何具体实现所要求的系统。 不是具体编写程序，而是设计程序的“蓝图”。 详细设计的结果决定最终程序代码的质量。结构程序设计 E.W.Dijkstra 最早提出结构程序设计：程序质量与程序中包含的Goto语句的数量成反比（1965）。1966 ，Bohm, Jacopini ，证明了只用“顺序”、“选择”、“循环”控制结构就能实现任何单入口单出口程序。

软件危机: 60年代中期以前：通用硬件相当普遍，软件却是为某个具体的应用而编写的。 60年代中到70年代中：软件作坊。软件危机：计算机软件的开发和维护过程中所遇到的一系列严重问题。（正常、不正常运行软件都具有这种问题） 软件危机原因： 1）软件本身特点造成； 2）软件开发与维护的方法不正确。 主要表现： （a）忽视软件需求分析； （b）认为软件开发就是写程

过程设计的工具程序流程图（程序框图） 程序流程图：是一种描述程序的控制结构流程和指令执行情况的有向图。 历史悠久、使用广泛、直观描绘控制流程、便于初学者掌握。程序流程图的缺点： 1）程序流程图本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构。 2）程序流程图中用箭头代表控制流，因此程序员不受任何约束，可以完全不顾结构程序设计的精神，随意转移控

大家时常会发现，团队有才能的工程师并不少，但是一群能人聚在一起，却并没有发挥出应有的水准，反而没过多久，团队内部矛盾一大堆。这是怎么一回事呢？所以，今天我结合自己这些年的管理经验，谈谈如何将一个技术团队的战斗力提高到一个新的高度。明确的职责和团队架构对一个技术团队管理者而言，最需要做的一件事就是明确每一个工程师的职责和建立组织架构。职责的关键是：谁负责什么内容；团队架构的关键是：谁在什么位置，一定