Q1：软件的概念和特点？
软件的概念：软件=程序+数据+文档
软件的特点：
（1）软件是开发的或者是工程化的，并不是制造的
（2）软件开发环境对产品影响较大
（3）软件开发时间和工作量难以估计
（4）软件会多次修改
（5）软件的开发进度几乎没有客观衡量标准
（6）软件测试非常困难
（7）软件不会磨损和老化
（8）软件维护易产生新的问题
（9）软件生产是简单的拷贝
Q2：软件危机、现状和产生的原因？
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题（效率降低和质量下降）。
现状：
（1）软件成本日益增加
（2）软件技术进步落后于需求增长
软件危机产生的原因：
（1）客观：
软件本身特点：
① 逻辑部件 ② 规模庞大
（2）主观：
不正确的开发方法：
① 忽视需求分析：有一个对目标的概括描述就足以着手编写程序了，许多细节可以在以后再补充。
② 错误认为：软件开发=程序编写
③ 轻视软件维护：软件投入生产性运行以后需要的维护工作并不多，而且维护是一件很容易做的简单工作。
Q3：软件工程的定义、三要素和发展过程？
软件工程的定义：
（IEEE计算机协会的定义）（1）应用系统化的、学科化的、定量的方法，来开发、运行和维护软件，即将工程应用到软件；（2）对（1）中各种方法的研究。
（老师讲的定义）软件工程是一种层次化技术，（自下而上为）质量焦点→过程→方法（结构化方法和面向对象方法）→工具。
软件工程的三要素：工具、方法、过程
软件工程的发展过程：
（1）第一代软件工程-传统的软件工程
（2）第二代软件工程-对象工程
（3）第三代软件工程-过程工程
（4）第四代软件工程-构件工程
Q4：软件的生命周期、软件过程的定义和能力成熟度模型CMM的概念？
软件的生命周期：
可行性研究→需求分析→总体设计→详细设计→实现与组装测试→验收测试→软件使用与维护
软件过程的定义：软件开发中所遵循的路线图（一系列可预测的步骤）。
过程模型：（从大范围到小范围划分）活动→动作→任务
能力成熟度模型CMM（Capability Maturity Model）的概念：
对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。
（1）初始级：有能力的人和个人英雄主义
（2）可重复级：基本项目管理
（3）已定义级：过程标准化
（4）量化管理级：量化管理
（5）优化级：持续的过程改进
Q5：掌握常见的几种软件过程模型，比较各自优缺点。
瀑布模型（经典的生命周期模型）：
（1）特点：
① 最早提出的软件开发模型，使用广泛。
② 阶段间具有顺序性和依赖性。
③ 推迟实现的观点。
④ 以文档为驱动，每个阶段必须完成规定的文档和文档审查。
（2）优点：
① 提供了一个模板，避免了软件开发过程中的随意状态。
② 适用于需求确定、变更相对较少的项目，曾成功进行过许多大型软件工程的开发。
（3）缺点：
① 线性过程太理想化，用户只有等到整个过程末期才能见到开发成果，开发风险大。
② 阶段之间产生大量的文档，增加工作量。
③ 早期错误发现晚。
④ 不适应需求变化。
（4）适用场合：系统需求明确、技术成熟、工程管理较严格的场合。
增量模型（属于增量过程模型）：
（1）特点：
① 是一种非整体开发的模型，是一种进化式的开发过程。
② 结合了原型模型的基本要素和迭代的特征。
③ 每个增量的开发可用瀑布模型或快速原型模型。
（2）优点：
① 不需要完整的需求，只要有一个增量就可以开发，产品能更早投入市场。
② 项目初期不需要投入太多人力资源。
③ 产品逐步交付，软件开发能较好适应市场需求变化。
④ 能够看到中间产品，提出改进意见，降低开发风险。
⑤ 开放式体系结构，便于维护。
（3）缺点：
① 很难根据客户需求给出大小合适的增量。
② 软件必须具备开放式体系结构。（困难）
③ 易退化成边做边改的方式，使软件过程控制失去整体性。
（4）适用场合：需求可能发生变化、具有较大风险、希望尽早投入市场的项目。
原型模型（属于演化过程模型）：
（1）优点：
① 减少需求不明带来的风险。
（2）缺点：
① 构造原型采用的技术和工具不一定主流。
② 快速建立的系统以及连续的修改可能导致原型质量低下。
③ 设计者在质量和原型中进行折中。
④ 客户意识不到一些质量问题。
（3）适用场合：客户不清楚系统具体输入/输出，或开发者不确定算法效率、软件与操作系统是否兼容以及客户与计算机交互的方式。
螺旋模型（属于演化过程模型）：
（1）特点：
① 在原型基础上，进行多次原型反复并增加风险评估。
② 若干次迭代：明确目标和实施方案→风险评估→开发和验证→评价和修正本阶段
③ 结合了瀑布模型和原型模型的特点。
（2）优点：
① 强调原型的可扩充性和可修改性，支持用户需求的动态变化。
② 原型可看作可执行的需求规格说明，作为继续开发的基础，方便用户参与关键决策。
③ 方便及时调整管理决策，降低风险。
（3）缺点：
① 如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间。
② 需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。
（3）适用场合：需求不明确或可能发生变化的大型系统的开发，不适合合同软件。
喷泉模型：
（1）特点：
① 以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
② 软件开发早期定义对象，整个开发过程充实和扩充对象。
③ 模型的各个阶段无缝衔接，开发人员可以同步进行开发。
④ 各个开发步骤多次反复迭代。
（2）优点：
① 各个阶段没有明显界限，可以提高软件项目开发效率，节省开发时间。
（3）缺点：
① 由于各个开发阶段是重叠的，在开发过程中需要大量开发人员，不利于项目的管理。
② 要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
（3）适用场合：面向对象开发。
敏捷模型：
（1）特点：
① 个体交互胜过过程和工具。
② 可以工作的软件胜过面面俱到的文档。
③ 客户合作胜过合作谈判。
④ 响应变化胜过遵循计划。
（2）优点：
① 快速响应变化和不确定性。
② 可持续开发速度。
③ 适应商业竞争环境下的有限资源和有限时间。
（3）缺点：
① 测试驱动开发可能导致通过测试但非用户期望。
② 重构而不降低质量困难。
（3）适用场合：需求模糊且经常改变、商业竞争环境下的项目。
基于构件的开发模型：
（1）优点：
① 软件复用，降低成本和风险，节约时间。
（2）缺点：
① 模型复杂。
② 商业构件不能修改，导致需求折中，进而系统不能完全符合客户需求。
③ 无法完全控制所开发系统的演化。
④ 项目划分的好坏直接影响项目结果的好坏。
（3）适用场合：系统之间有共性。
Rational统一过程模型：
（1）特点：
① 基于面向对象方法学。
② 使用统一建模语言UML（Unified Modeling Language）。
③ 每个增量的开发可用瀑布模型或快速原型模型。
（2）适用场合：大团队大项目。
Q6：需求分析的概念和过程？
需求分析的概念：
确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景。
（需求就是以一种清晰、简洁、一致且无二义性的方式，对一个待开发系统中各个有意义方面的陈述的一个集合。）
需求分析的过程（软件需求管理的过程）：
（1）需求获取：
① 软件需求的来源；
② 软件工程师收集这些软件需求的方法。
（2）需求提炼：
对应用问题及环境的理解和分析，为问题涉及的信息、功能及系统行为建立分析模型。将用户需求精确化、完全化，最终形成需求规格说明书。
（3）需求描述：
需求规格说明书（SRS）（包含功能性需求和非功能性需求）
需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。
（4）需求验证：
① 有效性检查：检查不同用户使用不同功能的有效性。
② 一致性检查：在文档中，需求之间不应该冲突。
③ 完备性检查：需求文档应该包括所有用户想要的功能和约束。
④ 现实性检查：检查保证能利用现有技术实现需求。
Q7：面向过程的分析方法/结构化分析方法（重点：数据流图）？
面向过程的分析方法：
（1）面向数据流进行需求分析的方法。
（2）结构化分析方法适合于数据处理类型软件的需求分析。
（3）具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。
Q8：面向对象的分析方法（重点：用例图）？
面向对象的分析方法：
（1）数据模型（对象模型）：描述系统数据结构的对象模型
（2）行为模型（动态模型）：描述系统控制结构
（3）功能模型：描述系统功能
Q9：面向过程、面向对象需求分析建模三类模型过程中（功能模型、数据模型、行为模型）各包含哪些内容？
面向过程的需求分析：
（1）功能模型：数据流图（DFD）
（2）数据模型：实体-联系图（ERD），数据字典（DD）
（3）行为模型：状态变迁图（STD）
面向对象的需求分析：
（1）功能模型：用例图
（2）数据模型：类图，类关系图
（3）行为模型：活动图，时序图，状态图
Q10：软件设计过程、软件设计的概念和原则？
软件设计的概念：
（IEEE计算机协会的定义）软件系统或组件的架构、构件、接口和其他特性的定义过程及该过程的结果。
设计质量属性：
（1）功能性
（2）易用性
（3）可靠性
（4）性能
（5）可支持性：包含扩展性，适应性，可维护性
设计指导原则：
（1）设计应该是一种架构。
（2）设计应该是模块化的。
（3）设计应该包含数据、体系结构、接口和组件各个方面。
① 应该设计出系统所用的数据结构。
② 应该设计出展现独立功能特性的各组件。
③ 应该设计出各组件与外部环境连接的各接口。
（4）设计由软件需求分析过程中获得信息驱动，采用可重复使用的方法导出。
（5）设计应该采用正确清楚的表示法。
Q11：与设计相关的8个概念？
（1）抽象
（2）体系结构
（3）设计模式
（4）模块化
（5）信息隐藏
（6）功能独立
（7）细化
（8）重构
Q12：系统设计从体系结构、数据、接口和组件四方面进行设计。面向过程和面向对象的系统设计各自包含哪些设计内容？
（1）体系结构设计
数据中心架构，数据流体系架构，调用和返回架构，层次架构，面向对象架构……
（2）数据设计
数据建模：数据字典，E-R图，类图
数据结构：计算机存储、组织数据的方式
数据库：按照数据结构来组织、存储和管理数据的仓库
（3）接口设计（含界面设计）
（4）组件设计
面向过程：函数与模块的设计
面向对象：类与操作的设计
Q13：面向过程的系统设计方法（重点：流程图）？
详细设计工具：
（1）图形设计符号：数据流图转程序结构图，流程图，盒图（N-S图）
（2）表格设计符号：决策表（判定表）
（3）程序设计符号：程序设计语言PDL（Program Design Language）
Q14：面向对象的系统设计方法（重点：顺序图）？
面向对象设计活动：
（1）架构设计：
① 构造系统的物理模型（UML配置图）
② 设计子系统（UML组件图）
③ 非功能需求设计
（2）用例设计
类图中的基本关系包括：关联、聚合、组合、依赖、泛化
分析类图：实体类、边界类、控制类
（3）类设计
（4）数据库设计
（5）用户界面设计
详细设计工具：
（1）架构设计：部署图（UML配置图），组件图（UML组件图）
（2）用例设计和类设计：精化类图
（3）UML顺序图
Q15：编程规范？
（1）结构化程序设计原则
① 尽量使用语言提供的基本控制结构，即顺序结构、选择结构和循环结构
② 复杂结构用基本控制结构组合或嵌套实现，严格控制goto语句
③ 将程序组织成块，每块只有一个入口和一个出口
④ 在详细设计和编码阶段，应当采取自顶向下、逐步求精的方法
（2）程序设计风格
① 基本要求：程序结构清晰且简单易懂，代码精简
② 可读性要求：注释和格式，使用已有的库函数，避免嵌套，模块功能尽可能单一化
③ 正确性与容错性要求
④ 可移植性要求
⑤ 输入和输出要求
⑥ 重用性要求
⑦ 面向对象的程序设计风格
Q16：程序三个结构是哪些？
顺序结构、选择结构和循环结构。
Q17：质量保证相关概念？
软件质量：明确表示是否符合功能和性能要求，明确地记载开发标准和所有专业开发软件的期望的隐性特点。
质量控制：审查产品相关的各个方面质量的过程。
质量保证：系统地监测和评估工程的各个方面，最大限度提高质量最低标准。
（原则：适合用途，一次成功）
质量成本：追求质量过程或履行质量有关活动中引起的费用以及质量不佳引起的下游费用。
软件质量保证（SQA）：遵照一定的软件生产标准、过程和步骤对软件质量进行评估的活动。
（一般活动：审查，监督，审计）
软件评审：一个过程或会议期间进行的软件产品的审核。
（常见形式：同行评审，管理评审，审计评审）
软件可靠性：在给定时间内，特定环境下软件无错运行的概率。（平均失效时间）
软件可用性：在某个时间点上程序能够按照需求执行的概率。（无故障运行的总时间）
Q18：软件测试策略？
软件测试策略为软件开发人员、质量保证组织、和客户提供了一个路线图，规定了测试的主要步骤。
V模型（软件测试的过程模型）：
Q19：单元测试、集成测试、系统测试、验收测试。
单元测试的内容：
（1）模块接口测试
（2）局部数据结构测试
（3）路径测试
（4）错误处理测试
（5）边界测试
集成测试的方法：
（1）自顶向下的集成方法：打桩测试（广度优先，深度优先）
（2）自底向上的集成方法：模拟根模块
（3）SMOKE方法：每天将构造及整个软件产品集成起来进行冒烟测试
系统测试的内容：
（1）功能测试：运行软件系统的所有功能
（2）性能测试：是否满足在需求说明书中规定的性能
（3）压力测试：系统运行环境不正常乃至发生故障（变种：敏感性测试）
（4）恢复测试：克服硬件故障（如停电，断网等）后，系统能否继续正常工作
（5）安全测试：检验系统安全性、保密性措施
（6）其他测试：包括配置测试、兼容性测试、本地化测试、文档测试、易用性测试等
验收测试的形式：
（1）根据合同进行的验收测试：重复执行相关的测试用例
（2）用户验收测试：客户和最终用户
（3）现场测试：α测试（一个用户在开发环境下）和β测试（多个用户在实际使用环境下）
Q20：回归测试的概念？
回归测试是指有选择地重新测试系统或其组件，以验证对软件的修改没有导致不希望出现的影响，以及系统或组件仍然符合其指定的需求。
原因：在修正软件缺陷或增加新功能时，变化的部分必须进行回归测试；对软件的修改可能会导致新的软件缺陷或其他问题，需要进行回归测试。
方式：自动化测试
范围：可以在所有的测试级别执行，并应用于功能和非功能测试中。
Q21：测试技术常见术语的概念？
软件缺陷：
（1）软件未实现产品说明书要求的功能或虽未明确提及但应该实现的目标。
（2）软件出现了产品说明书指明不能出现的错误。
（3）软件实现了产品说明书未提到的功能。
（4）软件难以理解、不易使用、运行缓慢或者最终用户会认为不好。
验证和确认：
（1）验证（Verification）：保证软件特定开发阶段的输出已经正确完整地实现了规格说明。
（我们正确地构造了产品吗？）
（2）确认（Validation）：对于每个测试级别，都要检查开发活动的输出是否满足具体的需求或与这些特定级别相关的需求。
（我们构造了正确的产品吗？）
测试与质量保证：
（1）软件测试：找出软件缺陷，并确保修复。
（2）软件质量保证：创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法。
质量与可靠性：
（1）功能性（functionality）
（2）可靠性（reliability）：MTTF
（3）可维护性（maintainability）：MTTR
（4）可用性（usability）：MTTF/(MTTF+MTTR)
（5）效率（efficiency）
（6）可移植性（portability）
调试与测试：
（1）测试的目标是发现软件缺陷的存在。
（2）调试的目标是定位与修复缺陷。
测试用例（test case）：
测试用例是测试输入、执行条件、以及预期结果的集合，是为特定的目的开发的，例如执行特定的程序路径或验证与指定的需求相符合。
Q22：白盒测试、黑盒测试、静态分析各有哪些方法？
白盒测试（结构测试/逻辑驱动测试）：
（1）逻辑覆盖测试：以程序内部的逻辑结构为基础的设计测试用例的技术。
（2）控制流图覆盖测试：将代码转变为控制流图（CFG），基于其进行测试的技术。
① 节点覆盖：即语句覆盖。
② 边覆盖：包含节点覆盖，也可以实现分支覆盖。
③ 路径覆盖：覆盖程序中所有可能的路径。
④ 基本路径覆盖：把覆盖的路径数压缩，程序中的循环体最多只执行一次。
⑤ 程序环路复杂性：独立路径（基本路径）条数V(G)=e-n+2
黑盒测试（功能测试/数据驱动测试）：
（1）等价类划分：把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。
（2）边界值分析：选取正好等于，刚刚大于或刚刚小于边界的值作为测试用例。
（3）状态测试：建立状态转换图→根据状态转换图设计测试用例
静态分析：
不实际运行程序，通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。
（1）同事审查：适用于初次审查，是要求最低的正式方法。
（2）走查：开发组内部进行的。
（3）审查：以会议形式，由开发组、测试组和相关人员联合进行。
Q23：掌握逻辑覆盖与等价类划分测试方法。
逻辑覆盖：
（1）语句覆盖：使得每个语句至少都能被执行一次。
（2）分支覆盖：使得每个判断的取真分支和取假分支至少经历一次。
（3）条件覆盖：使得每个判断的每个条件的可能取值至少执行一次。
（4）判定/条件覆盖：同时满足判断覆盖和条件覆盖。
（5）条件组合覆盖：使得每个判断的所有可能的条件取值组合至少执行一次。
（6）路径覆盖：使得每条可能路径都至少执行一次。
等价类划分：
（1）划分等价类：
① 规定了输入数据得取值范围或个数，则确立一个有效等价类和两个无效等价类。
② 规定了输入数据“必须如何”的条件，则确立一个有效等价类和一个无效等价类。
③ 规定了一个布尔量，则确定一个有效等价类和一个无效等价类。
④ 规定了输入数据的一组值，则确立一个有效等价类和一个无效等价类（所有不允许的输入值的集合）。
⑤ 规定了输入数据必须遵守的规则，则确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
（2）选取测试用例：
① 为每一个等价类规定一个唯一编号。
② 重复设计测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类。
③ 重复设计测试用例，使其仅覆盖一个尚未被覆盖的无效等价类。
Q24：软件维护的基本概念？
（IEEE/EIA 12207）软件维护是指由于软件产品出现问题或需要改进而对代码及相关文档的修改，其目的是对现有软件产品进行修改的同时保持其完整性。
Q25：软件维护的四个基本类型？
（1）完善性维护（所占比例最大，50%～66%）
含义：为了满足用户对软件提出的新的功能与性能要求，进行修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。
（2）适应性维护（18%～25%）
含义：在使用过程中，外部环境和数据环境可能发生变化，需要修改软件而使软件适应这种变化。
（3）纠错性维护（17%～21%）
含义：在软件交付使用后，因开发时测试的不完全，存在隐藏的错误遗留到运行阶段，需要识别和纠正软件开发时隐藏的错误、排除实施中的误用。
（4）预防性维护（所占比例最小，4%左右）
含义：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。
Q26：可维护性的决定因素？
（1）可理解性
（2）可测试性
（3）可修改性
（4）可移植性
（5）可重用性
Q27：软件维护过程模型、软件再工程和逆向工程的概念？
软件再工程（Re-engineering）指对现有软件进行仔细审查和改造，对其进行重新构造，使之成为一个新的形式，同时包括随之产生的对新形式的实现。
软件再工程模型：库存目录分析→文档重构→逆向工程→代码重构→数据重构→正向工程
软件逆向工程（Software
Reverse Engineering）是分析目标系统，识别系统的构件及其交互关系，并且通过高层抽象或其他形式来展现目标系统的过程。（恢复设计结果的过程）
需要考虑：抽象的层次、完备性、工具与分析人员协同工作的程度、过程的方向性等。
Q28：项目管理四要素？（4P）
（1）人员（People）：招聘、选拔、绩效管理、培训、薪酬、职业发展、组织和工作设计、团队/文化的发展。
（2）产品（Product）：在策划项目前，应建立产品的目标和范围，考虑其他解决办法，以及技术和管理应当被约束。
（3）过程（Process）：软件开发的一个全面计划。
（4）项目（Project）：理解成功项目管理的关键因素，掌握项目计划、监控和控制的一般方法。
Q29：软件度量有哪些方法？
软件生产率估计（LOC/人月或FP/人月）：
（1）直接测量（基于规模的度量）
如在一个特定时间内产生的千行代码（KLOC）。
（2）间接测量（基于功能点的度量）
如一个给定时间内生产出的功能点（FP）和目标点。
FP=UFC×TCF=UFC×(0.65+0.01×∑Fi)
UFC：未调整功能点计数（5个信息量的加权和）
∑Fi：14个因素的复杂性调节值（可取0-5）
工作量度量：
（3）算法成本模型（基于经验的度量）
（4）COCOMO模型（构造性成本模型）
基本COCOMO模型：E=a×(KLOC)b，D=c×Ed
E：工作量（人月PM）
D：开发时间（月）
中间COCOMO模型：E=a×(KLOC)b×∏Fi
∏Fi：15个因素的工作量调节因子（可取0.7-1.66）
Q30：软件工程的7个原则？
（1）使用阶段性生命周期计划的管理
（2）进行连续的验证
（3）保证严格的产品控制
（4）使用现代编程工具/工程实践
（5）保持清晰的责任分配
（6）用更好更少的人
（7）保持过程改进
Q31：敏捷过程是基本原理和开发准则的结合。
（1）基本原理强调：
① 客户满意度和较早的软件增量交付
② 小但有激情的团队
③ 非正式的方法
④ 最小的软件工程产品
⑤ 简化整体开发
（2）开发准则强调：
① 分析和设计的交付
② 开发者和客户之间积极持续的交流
（3）目前的敏捷过程模型主要包括：
极限编程（XP），自适应软件开发（ASD），动态系统开发方法（DSDM）等。
Q32：如何选择过程模型？
（1）选用时不必拘泥与某种模型，可组合多种模型，也可根据实际创建新的模型。
（2）在前期需求明确的情况下，尽量采用瀑布模型或改进的瀑布模型。
（3）在需求不稳定的情况下尽量采用增量迭代模型。
（4）在用户无系统使用经验，需求分析人员技能不足情况下一定要借助原型。
（5）在不确定因素很多，很多东西前面无法计划的情况下尽量采用增量迭代和螺旋模型。
（6）在资金和成本无法一次到位的情况下可采用增量模型，软件产品多个版本进行发布。
（7）对于完成多个独立功能开发可以在需求分析阶段就进行功能并行，但每个功能内部都应该遵循瀑布模型。
（8）对于全新系统的开发必须在总体设计完成后再开始增量或并行。
（9）对于编码人员经验较少的情况下建议不要采用敏捷或迭代等生命周期模型。
（10）增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口原则。
Q33：软件测试的基本原则？
（1）穷尽测试是不可能的
（2）测试无法显示潜伏的软件缺陷
（3）测试活动应尽早进行
（4）软件缺陷具有群聚性
（5）注意“杀虫剂”现象
（6）应尽量由独立的测试团队进行测试
Q34：软件测试的评估准则？
（1）覆盖率：测试集合/测试需求集合
（2）故障插入：在测试前有意地插入一些故障到程序中
（3）变异分值：程序进行两个或更多个变异，然后用同样的测试用例执行测试
Q35：项目计划相关概念？
项目进度计划：对项目进行任务划分，定义任务之间的依赖关系，并进行时间估算和资源分配，确保以最佳的时间与成本输出满足质量要求的产品。
项目进度计划的可视化：甘特图，Project软件
里程碑：项目进展中重大工作完成的标记。
工作分解结构（Work Breakdown Structure，WBS）：是将项目按照功能或过程逐层分解，直到划分为若干内容单一、便于组织管理的单项工作，最终形成的树形结构示意图。
任务网络图：是项目所有任务及其之间逻辑关系的图解表示，从左到右表示时间顺序。
关键路径：在任务网络图中，从项目开始到结束最长的路径（权重之和最大）。
