- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
软件工程教案(理论课程)
教师备课教案本
(理论课程)
系 别:计算机工程系
课程名称:软件工程
教师姓名:段琢华
授课时间:2013-2014学年第 2 学期
电子科技大学中山学院
教师授课计划*
课程名称 软件工程 学分 3 课程类型 1、普通教育必修课( ); 2、学科基础必修课( ); 3、专业方向课( √ );
4、学科基础选修课( ); 5、素质教育选修课( ); 6、专业选修课( )。 学时分配 总学时:48 ;课堂讲授: 32学时; 实践(验)课 16学时 授课
起止周 1-16 授课班级 游戏11,嵌入式11,网络11 班级
人数 56,69,50 授课
总次数* 16 教材名称 《软件工程案例教程:软件项目开发实践 第2版》 作者 韩万江 姜立新 出版
时间 2011年10月13日 章节 基 本 内 容 计划学时 1 软件工程 2 软件开发模型及可行性研究 软件需求4 3 分析建模(领域建模,架构设计) 4 4 软件设计(设计模式的应用, 子系统设计) 8 6 软件编码(编码方法,编码过程) 4 7 软件测试、发布与维护 考核要求 (根据课程实际情况,不做要求的项目可不写):
1、平时成绩的构成比例和考核方式;20% 考勤和读书笔记
2、期中成绩的构成比例和考核方式;
3、期末成绩的构成比例和考核方式;50% 综合课程设计
4、实验成绩的构成比例和考核方式。30% 上机实验。
填表日期: 2014年 02月 25日
教案
时间安排 第 周 ,总第 次课 章节
名称 第一章 总揽(4次课) 教学目的 讲解软件工程三个基本要素,通过比较各种软件工程方法的优缺点来给出面向对象软件工程方法论。同时讲解各种软件过程模型,以及uml建模语言的相关知识。 教学重点与
难点 软件工程的三个基本要素
面向对象软件工程思想,学会以对象的方式来思考问题
UML表示法
教
学
内
容
与
过
程
设
计
教
学
内
容
与
过
程
设
计
软件工程的成果是为软件设计和开发人员提供思想方法和工具,而软件开发是一项需要良好组织、严密管理且各方面人员配合协作的复杂工作。软件工程正是指导这项工程的一门科学。
一、软件工程知识体系
(1)需求定义为解决真实世界问题而必须展示的特性。
(2)设计既是“定义一个系统或组件的体系结构、组件、接口和其它特征的过程”,又是“这个过程的结果”。
(3)软件构造指通过编码、验证、单元测试、集成测试和排错的组合,详细创建一个可以工作的、有意义的软件。
(4)软件测试由在有限测试用例集合上,根据期望的行为,对程序的行为进行的动态验证组成,测试用例是从实际上是无限的执行域中适当的选择出来的。
(5)软件一旦投入运行,就可能出现异常,运行环境可能发生改变,用户会提出新的需求。生命周期的维护阶段从软件交付时开始,但维护活动出现得还要早。
(6)软件配置管理(Software Configuration Management,SCM)是为了系统地控制配置的变更和维护配置在整个系统的生命周期中的完整性和可追踪性,而标识软件在时间上不同点的配置的学科。
(7)软件工程管理知识域处理软件工程的管理与度量,虽然度量是所有知识域的一个重要方面,但在这里涉及的是度量程序的主题。
(8)软件工程过程的知识域涉及软件工程过程本身的定义、实现、评定、度量、管理、变更和改进。
(9)软件工程工具和方法知识域包括软件工程工具、软件工程方法。
(10)软件质量知识域处理跨越软件生命周期过程的软件质量的考虑,由于软件质量在软件工程中无处不在,其它知识域也涉及质量问题,读者可以注意到本知识域到其它知识域的指示器。
考核方式:
组队,通过在整个项目的实施过程中不断贯彻软件工程的思想,达到培养团队开发的目的。
讨论:小组人数最好多于3人,这是基于以下事实:给延期的项目增加人手会使项目进一步延期。因为向项目中增加人手,就必须花时间来进行培训。因此最终结果变成了:新增人员贡献非常慢,即使他们的效率确实很高时,那也只是耗尽了原有程序员的时间和精力。而且,项目中的程序员越多,程序员之间的相互交流就越复杂。
该事实诠释了一部软件工程经典著作的书名,《The Mythical Man-Month》即人月神话。该书指出:虽然我们采用人月(people per month)为单位来安排人手,但是每个人对软件的贡献各不相同,所以这些人月也不尽相同。在项目后期加入的人员更是如此,这些人的贡献几乎可以忽略不计。
文档评论(0)