- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
PAGE2 / NUMPAGES7
试卷结构:
填空题1*20 判断题1*10 简答题8*7 大题1*14(需求设计和分析,用例图和类图)
概述+软件过程 20% 软件工程技术 50% 软件工程管理 30%
平时成绩20% 期末80%
Chapter1 软件工程介绍
软件:指令的集合(计算机程序),数据结构:文档。
软件特性:软件是设计的,而非制造的,不会“磨损”,但会退化;大多数软件还是采用用户定制的方式
软件分类:系统软件、应用软件、工程、科学软件、嵌入式软件、产品线软件、web应用软件、人工智能软件(给定一个软件需要能判断出所属分类)
软件退化:不断的变更是软件退化的根本原因
软件危机:软件的可靠性没有保障、维护费用不断上升、进度无法预测、成本增长无法控制、程序员无限度增加等、形成软件开发局面失控的状态
Chapter2 过程综述
*软件工程定义:(1)将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护、即将工程化方法应用于软件。(2)在(1)中所述方法的研究;
软件工程是计算机科学,工程学,管理学三个学科的综合
四个阶段: 传统软件工程 面向对象软件工程 软件过程工程 基于构件的软件开发
*软件过程:软件开发中所遵循的路线图,可以定义为一系列模式的组合,这些模式定义了一系列的软件开发中所需的活动、工作任务、工作铲平及相关的行为。
*过程定义了一个框架,为有效支付软件工程技术,这个框架必须建立,软件过程构成了软件项目管理控制的基础,并且建立了一个环境以便于技术方法的采用、工作产品的产生、里程碑的建立、质量的保证、正常变更的正确管理。
*框架活动framework activities: 沟通、策划、建模(需求分析 设计)、构建(编码 测试)、部署。好处:每个过程有feedback,更好的控制产品质量.
*伞活动 Umbrella Activities: 软件项目管理 正式技术评测 软件质量保证 软件配置管理 Work product preparation and production 复用性管理 度量方法 风险管理.
CMMI(Capability Maturity Model Integration): 能力成熟度模型集成 四大类过程域(PA) 过程管理 项目管理 工程管理 支持管理
*过程评估和改进:用于过程改进的标准CMMI评估方法,提供了五步的过程评估模型,包括启动、诊断、建立、执行和学习;用于组织内部过程评估的一系列要求;软件的CMMI作为评估的根据,提供了一种诊断方法,用以分析软件或软件开发组织的相对成熟度: ISO/IEC 15504 (SPICE)该标准定义了软件过程评估的一系列要求;软件ISO9001:2000 这是一个通用标准,任何开发组织如果希望提高所提供的铲平、系列或服务的整体质量,都可采用这个标准。
Chapter3 过程模型
软件生命周期:是指从形成开发软件概念起,所开发的软件使用以后,直到失去使用价值消亡为止的整个过程.
分析 设计 编码 维护 / 确定应用需求 规范软件需求 构架设计 细节设计 编码实现 整合 维护
与软件过程的关系 软件生命周期从时间角度把软件开发和维护的复杂问题分解,划分为有相对独立的任务的若干阶段,逐步完成任务.帮助建立软件过程模型.
*瀑布模型:适用于清楚了解问题需求,工作以线性方式进行 优点:为项目提供了按阶段划分的检查点;当前一阶段完成后,只需要去关注后续阶段; 缺点:实际项目很少遵循线性模型;客户常难以清楚描述所有需求;只有在项目接近尾声时,才能看到可执行程序;重大缺陷若在评审之前未被发现会造成惨重损失;容易造成阻塞状态
*增量模型:适用于没有足够开发人员的情况,以迭代方式运用瀑布模型,第一个增量往往是核心产品 优点:若开发前期找不到足够的人员,早起的增量可以由少量人员完成,若核心产品口碑不错,可以为下一个增量投入更多人力;可以规避技术风险 缺点:至始至终开发者和客户纠缠在一起,直到完全版本出来;尽管其灵活性能适应需求变化,但也容易退化成边做边改模型,使软件过程缺乏整体性(与原型不同,侧重于每个增量提供一个可操作产品)
*原型模型:使用于需求模糊的项目,质量不能保证,是为定义需求而服务。优点:在客户提出了软件的一些基本功能但是没有详细定义输入,处理和输出需求;开发人员可能对算法的效率,操作系统的兼容性和人机交互的形式等不确定情况实施最好的解决方法;客户能对实际系统有直观的认识,能根据反馈不断调整以满足用户需求,采用迭代技术,也使开发者逐步清楚用户需求。 缺点:没有考虑软件的整体质量和长期的可维护性;客户不满意的达不到质量要求的产品可能被抛弃,而采用新的模型重新设计;系统可能不是很完美;构建需要的周期不能确定。
*螺旋模型:
文档评论(0)