四川大学软件工程导论.docVIP

四川大学软件工程导论.doc

此“教育”领域文档为创作者个人分享资料,不作为权威性指导和指引,仅供参考
  1. 1、本文档共8页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
四川大学软件工程导论 PAGE PAGE 1 ———————————————————————————————— 作者: ———————————————————————————————— 日期: 1.2软件的特性: ①软件是设计开发的,而不是传统意义上生产制造的; ②软件不会“磨损”; ③虽然整个工业向着基于构件的构造模式发展,然而大多数软件仍是根据实际的顾客需求定制的 1.4.1遗留软件的质量 2.1软件工程 软件工程是:将系统化、规范的、可量化的方法应用于软件的开发、运行和维护,即将工程化的方法应用于软件。 2.2过程框架 沟通:与客户之间大量的交流和协作,还包括需求获取以及其他相关活动 策划:为后续的软件工程工作制定计划 建模:包括创建模型和设计两方面 构建:包括编码和测试 部署:软件交付到用户,用户对其惊醒评测并给出反馈意见 在通用的过程框架中,建模活动包括分析和设计两个动作。 2.3能力成熟度模型集成(CMMI) 2.6.1个人软件过程(PSG) 个人软件过程强调产品以及产品质量的个人测量。 2.6.2团队软件过程(TSP) TSP的目标是建立一个能够“自我管理”的项目团队,团队能自我组织惊醒高质量的软件开发。 3.2瀑布模型 瀑布模型,又被称为经典生命周期,它提出了一个系统的、顺序的软件开发方法,从用户需求规格说明开始,通过策划、建模、构建和部署的过程,最终提供一个完整的软件并提供持续的技术支持。 v-mod:瀑布模型的改进。 3.3增量过程模型 ①增量模型以迭代的方式运用瀑布模型。 ②运用增量模型的时候,第一个增量往往是核心产品。 RAD模型 快速应用程序开发(RAD)是一种侧重于短暂的开发周期的增量软件过程模型。 3.4.1使用原型开发的情况 ①客户提出了软件的一些基本功能,但是没有详细的定义输入、处理和输出需求; ②开发人员可能对算法的效率、操作系统的兼容性和人机交互的形式等情况不确定。 当需求很模糊的时候,原型开发范型帮助软件工程师和客户更好地理解究竟需要做什么。 3.4.2螺旋模型 螺旋模型是一种风险驱动型过程模型的生成器,对于软件集中的系统,它可以指导多个共利益者的协同工作。 它有两个显著的特点: ①采用循环的方式逐步加深系统定义和实现的深度,同时降低风险; ②确定一系列里程碑,确保共利益者都支持可行的和令人满意的系统解决方案。 3.6统一过程 “用例驱动,以架构为核心,迭代并且增量” 它建立了一种迭代的、增量的过程流,提供一种演进的特性。 4.1敏捷是什么 敏捷不仅仅是有效地响应变化,它还鼓励能够在组员之间、技术和商务人员之间、软件工程师和经理之间进行更便利沟通的团队结构和协作态度,强调可运行软件的快速交付而不是中间产品,将客户作为开发组成员以消除持续、普遍存在于多数软件项目中的“区分你我”的态度,意识到在不确定的世界里计划是有局限性的,它必须是可以调整的。 4.3敏捷过程模型 4.3.1极限模型 5.4建模实践 在软件工程中,要创建两类模型:分析模型和设计模型。 分析模型通过以下三个不同域描述软件来表达客户的需求:信息域、功能域、行为域。 设计模型表述了可以帮助开发者开发软件的特征:架构、用户界面、构建细节。 5.4.1分析建模原则 ①必须描述并理解问题的信息域; ②必须确定软件所要实现的功能; ③必须描述软件的行为; ④描述信息、功能和行为的模型必须以一种能揭示分层细节的方式分解开来; ⑤分析人物应该从本质信息转向实现细节。 5.4.2设计建模的原则 ①设计可追溯到分析模型; ②经常关注特建系统的构造; ③数据设计与功能设计同等重要; ④必须设计接口; ⑤用户界面设计必须符合最终永华要求; ⑥功能独立的构件级设计; ⑦构件之间以及构件与外部环境之间松散耦合; ⑧设计表述应该做到尽可能易于理解; ⑨设计应该迭代式进行,每一次迭代,设计者都应该尽力简化。 5.5构造实践 构建活动包括一系列编码和测试任务。 5.5.2测试原则 软件测试的目标: ①测试是一个以查找程序错误为目的的程序执行过程; ②一个好的测试用例能最大限度地找到尚未发现的错误; ③一个成功的测试能找到那些尚未发现的错误。 5.6部署 部署活动包括三个动作:交付、支持和反馈。 6.5.2 UML系统建模 7.1连接设计和构造的桥梁 理解问题的需求是软件工程师所面对的最困难的任务之一。 需求工程是一个软件工程动作,开始于沟通并持续到建模。创建用户的信息、功能、行为模型。 7.2.2导出 为什么导出需求这么困难? ①范围问题:系统的边界不清楚,或客户/用户的说明带有多余的

文档评论(0)

panguoxiang + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档