軟件工程考点小结.doc

第一章 软件工程介绍 软件工程的概念 过程、方法和工具 软件危机与软件工程的关系、产生的原因及其表现 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题 软件危机的典型表现： 成本和进度估计常不准确 用户的满意度常不高 质量往往靠不住 软件通常很难维护 文档资料不完整、不合格 软件的成本高，所占比例逐年上升 软件开发生产率提高的速度慢 产生软件危机的原因： 客观原因 软件缺乏“可见性”，管理和控制其开发过程相对困难 软件大多规模庞大，而复杂性随规模以指数速度上升 主观原因 错误的认识和做法 忽视软件需求分析的重要性—急于求成，仓促上阵 认为软件开发就是写程序—编程只占全部工作量的10%--20%，软件配置主要包括程序、文档和数据 轻视软件维护—维护费用占总费用的55%--70% 第二章 过程综述 软件工程层次图 软件工程是一种层次化的技术 软件工程的根基在于质量关注点 软件工程的基础是过程层，它规定了完成各项任务的步骤 软件工程的方法主要描述如何做的问题 软件工程的工具提供了自动化和半自动化的支持 五个最基本的框架活动： 沟通、策划、建模、构建和部署 沟通： 策划：描述了需要执行的技术任务、可能的风险、资源需求，工作产品和工作进度计划 建模：创建模型（有助于客户和开发人员更好的理解软件需求）和设计（实现需求） 构建：包括编码和测试 部署：软件交付给用户，用户对其进行评测并给出反馈意见 典型的普适性活动 软件项目跟踪和控制；风险管理；软件质量保证；正式技术评审；测量；软件配置管理；可复用管理；工作产品的准备和生产 什么是CMMI，以及5个成熟度等级 CMMI:Capability Maturity Model Integration能力成熟度模型集成，用于预测软件开发组织所开发的系统和软件工程能力 第0级：不完全级 第1级：已执行级 第2级：已管理级 第3级：已定义级 第4级：已定义管理级 第5级：优化级 成熟度模型等级 关注焦点 过程域 优化级 持续的过程改进 组织创新和部署；原因分析和决定 已定量管理级 定量管理 组织过程性能；定量项目管理 已定义级 过程标准化 需求开发；技术解决方案 产品集成；验证；确认；组织过程焦点；组织过程定义；组织培训；集成项目管理；集成供方管理；风险管理；决策分析与决定；组织的集成环境；集成团队建立 已管理级 基本的项目管理 需求管理；项目策划；项目监督和控制；供方合同管理；测量和分析；过程和产品质量保证；配置管理 已执行级 ? ? 第三章 过程模型 瀑布模型；增量模型；RAD模型；原型模型；螺旋模型；协同开发模型；基于构件模型；形式化方法模型；面向方面模型；统一过程 适用范围、特点、优缺点 过程模型 适用范围 特点 优点 缺点 瀑布模型A 通常发生在对一个已有系统进行明确定义的适应性调整和增强的时候 对于一个新的项目，需求必须是准确定义和相对稳定的 阶段间的顺序性和依赖性； 文档驱动性； 严格阶段评估； 开发初期需要清楚全部需求； 开发周期长、风险大。 它提供了一个摸板，这个摸板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。 顺序太严格。 效率可能不高 产品在最后阶段才与客户见面如果产品需要改正。改动量很大 增量模型B 一般来讲最重要的增量放在前面 每次提交的增量都是可用的 适合于功能可以划分并且时间不紧迫的情况 可以规避一定的风险 RAD模型B 适于工期紧张，又可细分功能，还要有合适的构件 瀑布模型的高速变体，通过基于构件的方法快速实现 需要投入更多的人力。 各团队要紧密协作。 只适应于特殊的系统，必须可以合理模块化。 不适于高性能需求（若需调构件接口 ） 系统需求灵活，现有构件不容易轻易满足。 技术风险很高的情况下，不宜采用该模型。 原型模型C 客户也不能给出确切的要求 开发人员对算法的效率、操作系统的兼容性和人机交互的形式不确定 体现主要的功能 提供基本的界面风格 展示比较模糊的部分，以便于确定或进一步明确，防患于未然 原型最好是可以运行的，最少要在各主要功能模块之间能够建立相互连接 能让人（开发者或客户）很快见到产品，有成就感。 能渐进地启发客户提出新的要求或任务。 容易蒙骗客户，也可能由此给自己带来麻烦。 往往只为结果，而不考虑技术手段，为今后埋下隐患。 系统可能考虑不周全。 它与增量模型相比： 增量模型在开发以前基本能确定系统的需求，虽然在以后的过程中也可能不断完善；原型开发适应于预先不太清楚系统的需求。 增量模型的反馈可能较少，而原型开发需要不断的大量反馈信息 螺旋模型C 结合了原形的迭代性质和瀑布模型的系统性和可控性特点 风险驱动，引入非常严格的风险识别、风险分析和风险控制