软考-软件工程
系统开发与软件工程
考点分析
软件开发生命周期模型
项目管理基础
软件质量管理基础
需求分析与设计基础
结构化分析与设计
测试及维护
软件过程改进（CMM）
软件开发生命周期
瀑布模型：一步一步下来的，需求分析做的非常好，不做变更。理想的状态
原型法：动态定义需求（不需要一开始有明确的需求） ，做出一个原型出来，给用户看，一点点改进，慢慢演化用户满意的软件产品
螺旋模型：加入了风险分析。瀑布与演化模型结合。
喷泉模型：各活动没有明显边界。（设计好一部分了，就开始把这部分实现）
软件管理
软件项目管理铁三角：质量、成本、进度
软件项目管理六项（启动项目，度量，估算，风险分析，进度安排，追踪和控制）
启动项目：可行性分析，初步需求，计划
度量：管理学：如果不能用数字来描述他，说明你还不够了解。（度量是帮助有效管理的基础）数字化
软件项目成本估算策略（自顶向下估算、自底向上估算）
软件规模估算：LOC 代码行数的估算 FP估算对功能点进行估算
软件工作量估算有IBM估算（经验模型） Putnam模型比COCOMM模型高级
成本估算：由工作量估算乘以人的薪水，管理成本
软件项目组织和计划
软件项目管理中常用的管理开发进度的工具
甘特图：动态的反映出项目的进展
PERT技术：计划评审技术
CPM方法：关键路径法
------------------------------------------
网络图可以纵览全局，突出重点，掌握动态，便于统筹；甘特图则便于管理单项工作的开工与起止日期
进度的监控与计划的修正
EVA分析方法：对现有工作进行阶段性的评价，常用的进度监控方法，任何一天，我这个工程超前了还是滞后了
配置管理（配置管理计划，变更管理，版本管理，发行管理）
配置项：系统配置项、软件项目实施计划、软件需求规格说明书、设计规格说明书、源代码清单、测试计划和过程、操作和安装手册、可执行程序、数据库描述、用户手册
使用配置管理技术，使变更所产生的错误达到最小
其中要实现变更管理需要借助于配置数据库和基线
配置数据库可以分为：开发库，受控库，产品库
基线：软件生命周期各开发阶段末尾特定点，也称为里程碑
版本号：最初做出来应该是1.0，对1.0改版1.1再接下来改版1.2，针对不同用户更新1.21
风险管理
三个活动（风险识别，风险估计，风险驾驭：利用某种技术避开转移风险）
软件质量管理
ISO/IEC9126软件质量模型
MC Call软件质量模型
考点：质量模型某个特性的含义
功能性：与功能及其指定性质相关的
可靠性：维持其正常水平的能力
易实用性：可用不
效率：需要资源多不
可维护性：可理解性--可修改性--可测试性
灵活性：修改困难不
正确性：有没有做该做的事情
完整性：是否安全
复用性：重复使用某一部分
互用性：是否与外部系统连接
软件需求分析与设计
Jackson面向数据结构
结构化分析与设计 面向数据流
需求工程
需求开发：客户需求明朗化清晰化
需求管理：对需求变化进行管理的过程
结构化分析与设计
分析基础：面向数据流额需求分析方法
数据流图、数据字典
设计基础：
详细设计：设计工具（程序流程图、盒图、PAD图、PDL--非正式语言）
结构化设计模块独立性---内聚耦合考点
内聚：通过什么把他们放在同一个方法里
功能内聚：单一功能，各个合作
顺序内聚：顺序执行
通信内聚：数据结构上
过程内聚：特定次序执行
时间内聚：同一时间
逻辑内聚：逻辑上相关
偶然内聚：没有关系
无直接耦合：互相不依赖
数据耦合：数据值
标记耦合：数据结构
控制耦合：开关标志
外部耦合：I/O
公共耦合：全局数据区
内容耦合：直接内部数据
软件测试
测试目的：少时间人力发现更多错误
测试用例：测试数据+预期结果
测试过程：
测试计划（测试内容、进度安排、所需环境和条件）、测试大纲（某个模块的具体细节）、根据大纲生成测试用例、实施测试、测试报告。
测试方法：静态测试、动态测试（白盒测试、黑盒测试）-----跑不跑程序
集成测试计划是在概要设计阶段完成，单元设计计划是在详细设计阶段完成
确认测试计划是在需求分析阶段
α测试：用户在开发环境下测试
β测试：多个用户在实际的环境下测试
黑盒测试：等价类划分（有效等价类，无效等价类）、边界值测试、错误推测法、因果图
回归测试：修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
白盒测试：需要考虑到内部结构
白盒测试逻辑覆盖
语句覆盖：覆盖全部的语句
判定覆盖：每个判定的真假都覆盖
条件覆盖：每个条件真假都覆盖
A>1 and B==0 判定 A>1 条件
判定/条件覆盖：既符合判定又符合条件
条件组合覆盖：条件各种可能性组合至少出现一次
路径覆盖：所有可能路径
判定覆盖 包含 语句覆盖
条件覆盖 包含 语句覆盖
判定覆盖 ≠ 条件覆盖
判定条件覆盖 包含 判定覆盖
判定条件覆盖 包含 条件覆盖
条件组合覆盖 包含 判定/条件覆盖
软件维护
概念：交付使用以后直至淘汰之前，改正错误，新需求修改软件的活动
软件可维护性：理解、改正、改动软件的难易程度。
可维护性指标：可理解性，可测试性，可修改性
维护管理步骤：提出维护和修改要求、领导答复、分配任务、验证成果登记修改信息
软件过程
个人理解：考验软件组织的成熟度
软件开发中所遵循的路线称为“软件过程”
CMM其研究目的是提供一种评价软件承接方能力的方法，同事它可帮助软件组织改进其软件过程。
CMM模型：软件成熟度模型，描述分析软件过程能力的程度
软件成熟度分级：
初始级：杂乱无章，英雄式任务。
可重复级：基本管理体系，重复以往同类项目经验
已定义级：全面采用综合性管理，工程过程管理，都已经定义了标准
优化级：老是考虑优化
CMMI 比CMM 应用范围更广
CMM评估标准，所有内容都是必要的
CMMI作为改进模型出现，罗列了最佳实践，利于改进