1、Welcome to the World of Software Engineering！Software EngineeringSoftware EngineeringInstructorInstructor(Course)(Course):Jian ShuJian Shu SchoolSchool of of SoftwareSoftware Phone:Phone:Office hour:Office hour:MonMon.7 7:0 00pm0pm9 9:0 00pm0pm E-mail:540814890 E-mail:InstructorInstructors(Lab)s(Lab
2、):-Jian Shu,Binquan Chen,Fengyu Yang -Jian Shu,Binquan Chen,Fengyu YangTeaching Assistants:Teaching Assistants:-Course StaffCourse StaffLab ScheduleLab ScheduleClassWeek 9Wen.7,8Week 11Wen.7,8Week 13Wen.7,8Week 14Wen.7,8162011D304 舒 坚D304 舒 坚D304 舒 坚D304 舒 坚162012D306 陈斌全D306 陈斌全D306 陈斌全D306 陈斌全1620
3、13D308 杨丰玉D308 杨丰玉D308 杨丰玉D308 杨丰玉nFinal examFinal examnFinal gradeFinal grade：AssignmentAssignment+Lab.+Project+Lab.+Project 4 40%0%exam exam 6 60%0%nAssignment&Lab.don dont wait for the t wait for the last minutes.last minutes.Course GradingCourse Grading第一章软件工程概论第一章软件工程概论第二章软件工程过程模型第二章软件工程过程模型第三章
4、传统软件工程第三章传统软件工程第四章面向对象基础第四章面向对象基础第五章第五章 可行性分析及项目计划制定可行性分析及项目计划制定第六章面向对象分析第六章面向对象分析第七章面向对象设计第七章面向对象设计第八章第八章 软件编码与测试软件编码与测试第九章第九章 软件维护软件维护课程章节课程章节1(1(美美)Frederick P.Brooks,Jr.)Frederick P.Brooks,Jr.李琦注李琦注.人月神话人月神话MM，北京：人民邮电出版社，北京：人民邮电出版社，2007.102007.102(2(美美)Frederick P.Brooks,Jr.)Frederick P.Brooks,J
5、r.王海鹏，高博王海鹏，高博 译译.设计设计原本原本:计算机科学巨匠计算机科学巨匠Frederick P.BrooksFrederick P.Brooks的思考的思考MM，北京：，北京：机械工业出版社，机械工业出版社，2011.012011.013 3 孙家广，刘强孙家广，刘强.软件工程软件工程-理论、方法与实践理论、方法与实践M.M.北京：北京：高等教育出版社，高等教育出版社，2010.112010.114 4 齐治昌，谭庆平，宁洪齐治昌，谭庆平，宁洪.软件工程软件工程(第第3 3版版)M)M，北京：高，北京：高等教育出版社，等教育出版社，2012.052012.05参考书目参考书目5 5
6、许家珆许家珆.软件工程：方法与实践（第软件工程：方法与实践（第2 2版）版）MM，北京：机，北京：机械工业出版社，械工业出版社，2011.122011.126 6 刘伟刘伟.设计模式设计模式MM，北京：清华大学出版社，北京：清华大学出版社，2011.102011.107 7 张海藩张海藩.软件工程导论软件工程导论(第第5 5版版)M.)M.北京：清华大学出版北京：清华大学出版社，社，2012.052012.058(8(美美)Stephen R.Schach.)Stephen R.Schach.邓迎春，韩松邓迎春，韩松 译译.软件工程：软件工程：面向对象和传统的方法面向对象和传统的方法M.M.北
7、京：机械工业出版社，北京：机械工业出版社，2012.012012.01参考书目参考书目9 9 殷人昆，郑人杰等殷人昆，郑人杰等.实用软件工程实用软件工程(第第3 3版版)M)M，北京：清，北京：清华大学出版社，华大学出版社，2010.112010.1110 10 刘超，张莉刘超，张莉.可视化面向对象建模技术可视化面向对象建模技术-标准建模语言标准建模语言UMLMUMLM，北京：北京航空航天大学出版社，北京：北京航空航天大学出版社，2001.032001.0311(11(美美)Roger S.Pressman.)Roger S.Pressman.郑人杰，马素霞，白晓颖郑人杰，马素霞，白晓颖 译译
8、.软件工程：实践者的研究方法（第软件工程：实践者的研究方法（第6 6版）版）M.M.北京：机械工北京：机械工业出版社，业出版社，2007.012007.0112 Jason Baragry.Understanding Software Engineering:12 Jason Baragry.Understanding Software Engineering:From Analogies with other Disciplines to From Analogies with other Disciplines to Philosophical Foundations PhD thesis
9、.Victoria:La Philosophical Foundations PhD thesis.Victoria:La Trobe University,2000.Trobe University,2000.13 13 计算机软件工程规范国家标准汇编（第二版）计算机软件工程规范国家标准汇编（第二版）M.M.中国中国标准出版社，标准出版社，2011.08 2011.08 参考书目参考书目14(14(美美)Robert C.Martin)Robert C.Martin.敏捷软件开发敏捷软件开发-原则、模式原则、模式与实践与实践 MM，北京：清华大学出版社，北京：清华大学出版社，2011.062
10、011.0615 15(美美)Alan Shallowaay,James R.Trott.Alan Shallowaay,James R.Trott.设计模设计模式解析式解析 （第（第2 2版）版）MM，北京：人民邮电出版社，北京：人民邮电出版社，2010.122010.12参考书目参考书目 每人必须做笔记每人必须做笔记 实验必须预习实验必须预习 大作业每人的职责必须明确大作业每人的职责必须明确 教材为主要的参考书教材为主要的参考书 缺课、缺实验按缺课、缺实验按“学生守则学生守则”办理办理 手机打到震动或关机手机打到震动或关机课程要求课程要求第一章第一章 概论概论Software Engine
11、ering 软件 软件工程 软件工程发展历程 软件工程基本原理 软件工程知识体系主要内容1.1 软件开发软件就是编写程序？软件=程序+数据+文档+知识 程序是计算任务的处理对象和处理规则的描述 数据指的是程序能够适当地操作的信息 文档是为了便于了解程序所需的阐明性资料 软件蕴含着“完成特定功能和性能”的知识和经验 软件的特征 软件是计算机系统中的逻辑成分，相对于硬件的有形的物理特性，软件则是抽象的，具有无形性（人脑与智慧）软件是硬件的灵魂，硬件是软件的基础 软件是智慧和知识的结晶 软件不会“磨损”，而是逐步完善 软件分类 按软件功能划分 系统软件 支撑软件 应用软件 软件工作方式划分 实时处理
12、软件 分时处理软件 交互式软件 批处理软件 软件分类（续）按软件规模划分 微型软件 小型软件 中型软件 大型软件 按软件服务对象划分 通用软件 定制软件 软件的发展历程 程序设计时代（汇编语言）程序系统时代（高级语言）软件工程时代 60年代末-70年代中期：结构化程序设计技术 70年代中期-80年代：计算机辅助软件工程 80年代中期-90年代：面向对象语言和方法 90年代以来：统一建模语言 软件从简单到复杂，软件开发从个人行为到大型团队分工合作开发，软件开发工具和开发模式从粗糙到完善的发展历程 1.2 软件危机 1991年海湾战争中，一枚飞毛腿导弹穿过了爱国者反导弹的防御，击中了沙特阿拉伯的D
13、hahran附近的一个兵营，造成28名美国人死亡，98人受伤。这个错误是由累积的定时错误引起的，爱国者导弹每次只能工作几小时，超过这个时间后，系统时钟就会复位。可悲的是新的软件第二天才运到。美国国内税收处20世纪90年代让Sperry公司建立一套联邦税收表格自动处理系统，该系统被证明不适合当前的工作量，花费几乎是预算的2倍。到1996年，共花费了40亿美元，但情况并没改善，原因是“没有充分计划就错误行事”。软件危机的表现 超出预算时间和成本 客户对生产出的软件不满意 软件有残存的错误 软件产品不可维护 文档资料不完整 软件生产率的提高跟不上硬件的发展速度 软件成本比例不断提高软件危机产生原因
14、软件开发无计划性 软件开发进度落后了应该增加人手么？软件需求不充分 满足的是客户的需要，而不是展示个人的技巧 软件开发过程无规范 没有统一的方法和规范，也不重视文档 软件产品无评测手段 提交产品测试；接口测试，整体测试，压力及性能测试 1.3 解决之道：软件工程工程的含义工程是将理论和所学的知识应用于实践的科学，以便经济有效地解决实际问题工程的含义（续）规模上的差异 花园小道vs.汽车高速公路 树上小屋vs.摩天大楼 加法程序vs.医院档案系统 手工（Craft）:小规模的设计与建造 简单问题与单一目标 个人控制与个人技能 工程（Engineering）:大规模的设计与建造 复杂问题与目标分解
15、 多人参与，需要考虑运营、管理、成本、质量控制、安全等工程的特征 平衡与决策 需要进行一系列决策和认真评价，并在每一个决策点做出适当选择，适当与否可以通过平衡成本和利益的分析来判断。度量与验证 应该度量事物，在适当的时候定量工作；需要校正并验证度量，并在经验和实验数据的基础上进行近似。运用工具 工程师需要将工具系统地应用在过程中，因此选用适当的工具是工程的关键软件工程定义（续）Boehm运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。IEEE软件工程是开发、运行、维护和修复软件的系统方法。Fritz Bauer建立并使用完善的工程化原则，以较经济的手
16、段获得能在实际机器上有效运行的可靠软件的一系列方法。软件工程定义 软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来 软件工程基本原理 B.W.Boehm提出的七条原理，最小集合，彼此不能互相替代 用分阶段的生命周期计划严格管理 件开发与维护的漫长的生命周期中，需要完成许多性质各异的工作，应该把软件生命周期划分成若干个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理 软件工程基本原理（续）坚持进行阶段评审 统计资料表明：大部分错误是在编码之前造成的，
17、例如，根据Boehm等人的统计，设计错误占软件错误的63%，编码仅占37%；错误发现与改正得越晚，所需付出的代价也越高。软件工程基本原理（续）实行严格的产品控制 不能硬性禁止客户提出改变需求的要求，而只能依靠科学的产品控制技术来顺应这种要求 采用现代程序设计技术 结构化分析设计技术，面向对象分析设计技术 结果应能清楚地审查 每个阶段的成果如果表现？软件工程基本原理（续）开发小组的人员应该少而精 软件工程基本原理（续）承认不断改进软件工程实践的必要性 软件工程知识体SWEBOK 软件工程知识体SWEBOK(续）软件工程知识体SWEBOK(续）软件工程基础知识域软件工程基础知识域SWEBOK V3
18、(2014)的主要内容变化 SWEBOK V3由15个知识域组成，其中包括11个软件工程实践知识域，分别是软件需求、软件设计、软件构造、软件测试、软件维护、软件配置管理、软件工程管理、软件工程过程、软件工程模型和方法、软件质量、软件工程职业实践；以及4个软件工程教育基础知识域软件工程经济学、计算基础、数学基础和工程基础。与SWEBOK V2相比，SWEBOK V3的主要内容变化有以下几个方面：SWEBOK V3(2014)的主要内容变化 更新了所有知识域的内容，以反映软件工程近10年的新成果，并和CSDA、CSDP、软件工程本科课程大纲SE2004、软件工程硕士课程大纲GSwE2009和软件工
19、程术语SEVOCAB等标准进行了知识体系的统一 新增了四个基础知识域（软件工程经济学、计算基础、数学基础和工程基础）和一个软件工程职业实践知识域 SWEBOK V3(2014)的主要内容变化 在软件设计和软件测试中新增了人机界面的内容；把软件工具的内容从原先的“软件工程工具和方法”中移到其他各知识域中，并对该知识域重命名为“软件工程模型和方法”，使其更关注方法 更突出了架构设计和详细设计的不同，同时在软件设计中增加了硬件问题的新主题，以及面向方面（aspect-oriented）设计的讨论 SWEBOK V3(2014)的主要内容变化 新增了软件重构、迁移和退役的新主题，更多地讨论了建模和敏捷
20、方法 在多个知识域中都增加了保密安全性（security）的考虑 合并了多个标准中的参考文献，并进行更新和遴选，减少了文献数量 软件工程及其相关学科 软件工程是应用计算机科学、数学与管理科学等基本原理，开发软件的工程。它借鉴传统工程的原则和方法，以提高质量，降低成本为目的。计算机科学和数学用于构造软件的模型与算法；工程科学用于制定规范、设计范型、评估成本及确定权衡；管理科学用于计划、资源、质量、成本等管理。软件工程与计算机科学 软件工程与计算机科学的区别 计算机科学 研究构成计算机和软件系统基础的有关理论和方法 举例：数据结构、离散数学、算法分析等 软件工程 研究开发和发布软件的实际问题 举例
21、：飞行控制软件 软件工程的研究与实践包括两个方面，一是根植于计算机科学，二是表现为一种工程学科。软件工程职业道德规范软件工程不仅是技术的应用，还包括许多责任。软件工程人员应当遵循本行业的职业道德规范，否则无法在这个行业中长久立足。分析下面的一些行为：将公司的软件代码随意复制给其他人为了个人的利益作出不切实际的承诺使用盗版软件迫于时间压力交付缺乏严格测试的代码未经允许就在别人的机器上玩游戏和上网IEEEACM 职业道德准则 1.公众 软件工程人员应始终与公众利益保持一致。2.客户和雇主 在与公众利益保持一致的原则下，软件工程人员应满足客户和雇主的最大利益。3.产品 软件工程人员应当确保他们的产品
22、及其改进符合尽可能高的专业标准。4.判断 软件工程人员应当具备公正和独立的职业判断力。IEEEACM 职业道德准则 5.管理 软件工程管理者和领导者应拥护和倡导合乎道德的有关软件开发和维护的管理方法。6.职业 在与公众利益保持一致的原则下，软件工程人员应满足客户和雇主的最大利益。7.同行 软件工程人员对其同行应持平等和支持的态度。8.自我 软件工程人员应当终身学习专业知识，促进合乎道德的职业实践方法。道德的判断有影响的软件工程期刊 Transactions on Software Engineering（IEEE）Software（IEEE）Software Engineering Notes
23、（ACM Special Interest Group）Transactions on Software Engineering and Methodology（ACM）The Journal of Systems and Software（Elsevier）Proceedings of the International Conference on Software Engineering（ACMIEEE）Proceedings of the International Conference on Software Maintenance（IEEE）Software Maintenance:
24、Research and Practice（Wiley）参考文献 1.F.P.Brooks Jr.,“No silver bullet:essence and accidents of software engineering”,IEEE Computer,vol.20,No.4,pp10-19,1987.2.Brooks,F.,The Mythical Man-Month,Addison-Wesley,1975 3.Bourque,Pierre,et al.,“The Guide to the Software Engineering Body of Knowledge”,IEEE Soft
25、ware,Nov./Dec.,pp 35-44,1999 4.Abran,A.and J.Moore,SWEBOK:Guide to the Software Engineering Body of Knowledge,IEEE Computer Society Press,2002,can be download at http:/www.swebok.org/5.IEEE Computer Society/ACM Joint Task Force on Software Engin-eeringEthics and Professional Practices.Software engin
26、eering code of ethics and p r o f e s s i o n a l p r a c t i c e,a v a i l a b l e a t http:/computer.org/tab/seprof/code.htm常见观点辨析 软件开发就是编程？开发进度落后，增加人手就可以了？用户什么都不懂，问他们还不如我自己看书想怎么开发？不要跟我讲什么规范，把程序写完就可以了？能完成开发任务就可以了，不要管我怎么完成的？常见观点辨析（续）我就是喜欢一边想一边写，这样开发速度快 有一种新的开发工具，据说可以提高10%的开发速度，我们应该马上采用 编程高手可以搞定所有的事
27、情第二章第二章 软件工程过程模型软件工程过程模型Software Engineering 软件生命周期 瀑布模型 快速原型 增量模型 极限编程 螺旋模型 RUP主要内容2.1软件生命周期 计算机软件开发规范（GB85668），软件生命周期包含：软件定义、软件开发、软件运行维护三个时期，并可以细分为可行性研究、项目计划、需求分析、概要设计、详细设计、编码实现与单元测试、系统集成测试、系统确认验证、系统运行与维护等几个阶段。软件定义期 要开发什么样的软件？软件任务立项（项目立项报告）项目可行性分析（可行性分析报告）制定项目计划（软件项目开发计划）软件需求分析（软件需求规格说明书）以用户需求为基本依
28、据，从功能、性能、数据、操作等多个方面，对软件系统给出完整、准确、具体的描述，用于确定软件规格 软件开发期 软件概要设计（概要设计说明书）软件系统的结构设计，用于从总体上对软件的构造、接口、全局数据结构和数据环境等给出设计说明 模块是概要设计时构造软件的基本元素，概要设计中软件也就主要体现在模块的构成与模块接口这两个方面，主要以模块的内聚、耦合性两个指标来进行评价 软件开发期（续）详细设计（详细设计说明书）概要设计为依据，用于确定软件结构中每个模块的内部细节（程序算法和模块内部的局部数据）编码和单元测试（带注释的源代码）编码必须按照“详细设计说明书”的要求逐个模块地实现 基本模块的单元测试也往
29、往和编码结合在一起进行 软件开发期（续）软件系统集成测试（测试报告）软件系统组过程中，需要对整个软件系统进行集成测试，以确保软件系统在技术上符合设计要求，在应用上满足需求规格要求 软件系统确认验证（项目开发总结）以用户为主体，以需求规格说明书中对软件的定义为依据，由此对软件的各项规格进行逐项地确认 软件运行与维护期 软件不断进化升级的过程，以使软件系统更加持久地满足用户的需要 改正性维护 适应性维护 完善性维护 2.2建造修补模型 “边做边改”模型 建造修补模型（续）优点 可以用于探索某个函数或类的用法 缺点：不能用于实际的软件开发 对没有规格说明和设计文档的产品进行维护相当困难，而且发生回归
30、错误的可能性也相当大 从整个软件过程来说，特别是考虑到维护阶段的情况，实际上建造修补模型的花费远远大于有正规的规格说明、经过详细设计的产品所需要的花费 2.3瀑布模型 是其它开发模型的源头 瀑布模型将软件生命周期划分为需求分析、规格说明、软件设计、程序实现、软件集成和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落 瀑布模型（续）第一个投入实际开发的有效模型，瀑布模型的成功主要得益于 强制性原则：阶段产品与文档确认之前不进入下一个阶段，每个阶段必须经过软件质量保证（Software Quality Assurance，SQA）小组的评审 文档驱动原则：
31、瀑布模型强调文档必须与产品同步，开发过程中和每个阶段的结束都要求有规范的文档 瀑布模型（续）缺点：由于文档驱动原则，客户只能在整个产品完成编程之后才首次能够看到工作的产品，规格说明文档只存在于纸面上，客户因而不能真正理解产品本身会是什么样子（软件的不可见性）开发过程只能按阶段顺序向下进行，发现错误只能逐级回溯,为避免回溯错误，每个阶段修改后必须重新评审，其进度有可能被严重拖延，最终导致成本和质量的失控 2.4快速原型开发模型 使用瀑布模型，客户与开发人员对于需求的不同理解是造成软件开发失败的最大因素，如果能够在正式开发前在需求方面达成一致可有效地提高客户的满意度和软件的可用性，快速原型开发模型
32、正是基于这样的思想而设计的快速原型开发模型（续）优点 产品的开发基本上是线性的，最大程度避免回溯 开发进度快：正式设计和编程前做了大量的沟通和准备工作，在开发过程回溯较少，因此整体上提高了开发的速度 缺点 需求人员和客户确定的展示性原型可能不利于设计人员的创新（应该只用做需求获取工具，第3章详述）2.5增量模型 产品以一系列增量构件的形式设计、实现、集成和测试，每个构件（Builds）由一些代码块组成，这些代码块来自多个相互作用的模块，完成特定的功能 在增量模型的每一个阶段，编写出一个新构件的代码后，集成到已完成的软件中，作为一个整体进行测试，当产品达到功能目标时，即满足了规格说明后，这个进程
33、停止 举例：文字处理系统的开发 增量模型 优点 增量模型在每个阶段交付一个可用的产品 减少一个全新产品对客户组织所带来的心理上的影响 分阶段交付产品对客户的资金压力较小 客户可以在任何时候停止产品的开发 缺点 每个增加的构件必须能合并到已有的结构中去，而不破坏原来的结构（可扩展性，即插即用）增量模型容易退化成建造修补模型 2.6极限编程 增量模型的一种扩展 主要特征 根据效益分析，确定软件需求 测试驱动 成对编程 每日构建 极限编程 基本要求 极限编程小组的计算机设置在一个大房间中，大房间中有许多彼此相连的小隔间，保证程序员之间能有顺畅的交流 一个客户代表始终和极限编程小组一起工作，为整个开发
34、小组提供业务咨询和指导 不允许连续两周超时工作 没有规格说明，编程小组的所有成员一起完成规格说明、设计、代码和测试过程 建造出各种构件之前没有概要设计阶段 极限编程的十二个最佳实践 Kent Beck等人提出了12个软件开发的最佳实践 现场客户（On-site Customer）代码规范（Code Standards）每周40小时工作制（40-hour Week）计划博弈（Planning Game）系统隐喻（System Metaphor）简单设计（Simple Design）极限编程的十二个最佳实践 测试驱动（Test-driven）代码重构（Refactoring）代码共享（Code s
35、haring）成对编程（Pair Programming）持续集成（Continuous Integration）小型发布（Small Release）极限编程 优点 当客户的需要模糊或经常改动时，使用极限编程可以通过不断地调整而逐渐澄清需求，从而避免到开发的最后阶段才发现需求理解错误 缺点 仅适用于中小型项目，因为在整个项目开始前没有详细的概要设计，对于较复杂的软件系统而言，各部分及部分之间的复杂性最终会导致开发工作陷入无法正常工作的困境 2.7同步稳定模型 也可以看作是增量模型的一种变型 在微软公司内部得到了成功的应用 访问软件潜在顾客，提取的优先特性列表，拟制规格说明文档，将工作分为3、
36、4个构件，第1个构件包含最重要的特性，第2个构件包含次重要的特性；每个构件都由一些小组并行地完成 每日同步，构件稳定即冻结 同步稳定模型（续）优点 同步步骤保证各个组件总能一起工作，部分地构建产品使开发者能尽早深入了解每个产品的工作状态，而且必要时在构件生成的过程中修改规格说明文档，甚至在最初的规格说明文档未完成前都可使用这个模型 缺点 对开发人员要求很高，不仅指技术要求，更重要的是职业素养 2.8螺旋模型 强调软件开发风险分析，特别适合于大型复杂的软件系统 人员风险 硬件风险 测试投入 技术风险 竞争对手 螺旋模型的优缺点 优点 强调可选办法和限制条件能够支持已有软件的再利用，并把软件质量作
37、为特定的目标结合在其中 可以确定何时测试完毕，维护只是另一个螺旋循环 缺点 专门用于内部开发 只适用于大型软件的开发 只有开发小组能够胜任风险分析才能使用螺旋模型 面向对象的生命周期模型 2.10 RUP Rational统一过程（Rational Unified Process，RUP）主要经验 迭代式开发 管理需求 基于组件的体系结构 可视化建模 验证软件质量 控制软件变更 RUP中的用例驱动阶段名阶段名称称阶段任务阶段任务阶段中的用例阶段中的用例初始初始了解项目范围，并且为其创建商业了解项目范围，并且为其创建商业用例，最后决定：继续这个项用例，最后决定：继续这个项目是否有益目是否有益开发
38、出高层用例以帮助划定项目的开发出高层用例以帮助划定项目的范围，如应包含的功能，项目范围，如应包含的功能，项目范围、进度和预算范围、进度和预算细化细化进行需求分析和风险分析，开发出进行需求分析和风险分析，开发出基本的体系结构，并且为构造基本的体系结构，并且为构造阶段创建计划阶段创建计划更细化的用例，用于风险分析和体更细化的用例，用于风险分析和体系结构的建立，创建构造阶段系结构的建立，创建构造阶段的计划的计划构造构造进行一系列的迭代，每一次迭代包进行一系列的迭代，每一次迭代包括分析、设计、实现和测试括分析、设计、实现和测试把用例作为设计和开发测试计划的把用例作为设计和开发测试计划的起点，在迭代的过
39、程中对用例起点，在迭代的过程中对用例进一步细化。进一步细化。交付交付把已经开发的项目完善成产品，包把已经开发的项目完善成产品，包括括Beta测试、性能调整和创建测试、性能调整和创建培训手册、用户指南以及销售培训手册、用户指南以及销售工具等文档，为内部或外部用工具等文档，为内部或外部用户制定相应的产品推广计划。户制定相应的产品推广计划。使用用例来开发用户指南和培训手使用用例来开发用户指南和培训手册册2.11案例引入 图书借阅管理系统第三章第三章 传统软件工程传统软件工程Software Engineering主要内容及重点 结构化方法概述 结构化需求方法 结构化设计方法重点：需求分析 模块及模块
40、独立性 自顶向下，逐步求精 分解与抽象，信息隐藏3.1结构化方法概述 结构是指系统内各个组成要素之间的相互联系、相互作用的框架。结构化开发方法提出了一组提高软件结构合理性的准则，如：分解与抽象、模块独立性、信息隐蔽等 结构化方法起源于结构化程序设计语言 1966年，C.Bhm和G.Jacopini提出了关于程序结构的理论，并证明了任何程序的逻辑结构都可以用顺序结构、选择结构和循环结构来表示 结构化方法概述（续）结构化分析方法强调开发方法的结构合理性以及所开发软件的结构合理性，给出了一组帮助系统分析人员产生功能规约的原理与技术 使用的工具主要有：数据流图、数据字典、结构化语言、判定表以及判定树等
41、 以数据流图、数据字典为主要工具表达需求，在此基础上得到软件的模块结构图，用来表述程序模块之间的关系 结构化设计方法的设计原则 每个模块只执行一个功能，坚持功能性内聚 每个模块用函数方式调用其他模块，不允许在模块间直接跳转 模块间传送的参数只能是模块所使用的数据，不能是控制信息 模块间共用的信息（如全局变量等）应尽量少，坚持局部化原则 3.2 结构化需求分析方法 需求分析是指在新开发一个系统或维护一个现有的软件时通过与客户的交流沟通后确定新系统的功能、性能、界面及操作方式等 需求分析是软件定义的一个阶段，也是整个软件开发的基础，但往往也是最困难的部分 需求分析不是为了知道客户想要什么系统，而是
42、确定客户真正需要什么样的系统 需求分析的重要性 需求分析对系统开发有决定性的影响 需求分析的错误将引起扩散性传播，即水波效应 需求分析生成的文档是后继工作的基础 需求分析的工作量占整个系统开发工作量的30%需求分析的困难 需求人员不仅仅需要技术能力，也需要与客户有良好的沟通和互动能力，即便如此，需求分析的结果往往也是不如人意的，主要原因是：客户需求的动态性 客户需求的模糊性 需求分析的困难（续）问题的复杂性和对问题空间理解的不完备性与不一致性 需求人员如何完全理解客户的业务？需求人员编写的需求分析文档如何让客户能完全理解？需求分析的任务 软件需求阶段的任务就是识别、获取需求与为需求建模 需求分
43、析的任务（续）深入了解软件的功能和性能 确定软件设计的约束以及软件同其它系统元素的接口细节 定义软件的其它有效性需求 准确地表达被接受的客户要求 确定被开发系统的系统元素并将功能和信息结构分配到这些系统元素中 软件需求过程 软件需求可以分成4个阶段，分别是：问题识别、分析与综合、编制需求阶段的文档、需求分析评审。首先建立软件需求小组软件需求过程（续）问题识别 在该阶段，需要确定客户到底需要的是一个什么样的系统，并为这个系统划定相应的范围；为完成预计的系统，需要客户提供什么条件，如现在条件不能满足是否需要增加新的软硬件设备和其他设施，甚至考虑修改原有的规章制度和业务流程。需要多次与客户沟通，交流
44、，最后提出总体方案软件需求分类软件需求分类软件需求含义软件需求含义功能需求功能需求软件应该能做什么？可以为客户解决什么问题？有哪些菜单项？软件应该能做什么？可以为客户解决什么问题？有哪些菜单项？性能需求性能需求在给定的条件下，软件的响应时间最差情况下是多少？在给定的条件下，软件的响应时间最差情况下是多少？环境需求环境需求软件交付后在什么样的系统下运行？对操作员的技能有何要求？软件交付后在什么样的系统下运行？对操作员的技能有何要求？可靠性需求可靠性需求连续工作多长时间不出现问题？连续工作多长时间不出现问题？安全保密需求安全保密需求如何保护数据的安全？如何防止非法入侵？如何保护数据的安全？如何防止
45、非法入侵？客户界面需求客户界面需求主菜单的布局、颜色如何？界面元素（如按钮）的位置，大小，形状是什么主菜单的布局、颜色如何？界面元素（如按钮）的位置，大小，形状是什么样的？客户如何操作软件？样的？客户如何操作软件？资源需求资源需求正常运行程序需要多大的内存、硬盘？为达到最佳效果是否需要使用专用设正常运行程序需要多大的内存、硬盘？为达到最佳效果是否需要使用专用设备？备？成本消耗需求成本消耗需求为保证软件开发的顺利进行，需要投入多少资金和人员？如何分配资源？为保证软件开发的顺利进行，需要投入多少资金和人员？如何分配资源？开发进度需求开发进度需求为软件开发设定期限，并制定相应的开发进度计划，标出相应
46、的里程碑。为软件开发设定期限，并制定相应的开发进度计划，标出相应的里程碑。分析与综合阶段 对资料的分析与综合 保持资料的一致性 用户的要求与现在的技术条件如何契合？结构化分析方法与面向对象的分析方法编制需求分析文档 主要有软件需求规格说明书、数据字典、初步的客户手册、软件开发计划等 按照相应的规范编写，如GB/T 9385-2008 计算机软件需求规格说明规范 需求分析评审 独立的第三方做为评审人员 需求文档和客户的要求是否一致？提供的文档是否完备？文档中的描述是否完整清晰？开发计划是否可行？数据、数据结构和图表的说明是否清楚？开发软件的限制条件是什么？开发过程中可能遇到的风险是什么？软件需求
47、获取 建立需求分析小组 客户组织架构分析 组织构成，分级，谁能做决定 获取资料 资料的来源主要有：单据、报表、管理规定、操作指南、标准规范、业务办理流程、备忘录、会议纪要等 数据采样 面谈 问卷调查 用户行为观察（第6章中详述）结构化分析方法 面向数据流的需求分析方法，该方法适合数据处理类型软件的需求分析，采用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现软件为止 静态分析方法：数据流图，数据词典，数据加工说明 动态分析方法：状态迁移图，时序图，petri网数据流图 数据流图是作为描述“分解”的手段引进的，即将最初概括性的处理过程分解成几个
48、较小的处理过程，再逐层分解，直到最后一层的每个处理过程都可以很容易清楚地描述和处理为止 例：储户到银行取款的业务流程 例：某培训中心业务处理系统 为相关行业人员开设多门课程。有兴趣的人通过来电来函报名选修某门课。培训中心收取一定费用，并开具发票。学员可通过来电来函查询课程计划。该培训中心首先将学员的来电来函分类，然后按不同情况进行如下处理：如学员来报名，将报名数据发给负责报名的职员，他们查询课程文件，检查课程是否额满。如未满，则在学生文件、课程文件上登记，开出报名单给财务部门，财务部门对发票进行复审后通知学员来交费 如学员付款，财务人员在账目上登记，经复审后给学员通知单 如学员查询相关课程，交
49、查询部门查询课程文件后给出答复 如学员想注销某门课程，则注销人员在课程、学生、账目上做出相应的修改，经复审后通知学员 拒绝学员的不合理要求例：某培训中心业务处理系统（续）数据流图的画法可以用一句话来总结：“从外向里，自顶向下”。“从外向里”指的是先找出系统的外部对象，即数据源点和终点，而系统内部是对数据源点传入的数据进行处理后传出给数据终点；“自顶向下”即对问题的从粗略到精细的分解性说明 例：某培训中心业务处理系统（续）分析过程（名词动词法）通过分析可知，四种基本元素中，外部实体、数据流、数据存储文件是名词，数据加工是动词或动宾结构，将对日常工作的描述中的名词和动词找出来，分配到各种基本元素中
50、，就可以得到最初的分析结果 名词：学员、报名数据、职员、课程文件、课程、学生文件、报名单、财务部门、发票、财务人员、账目、通知单、查询部门、答复、不合理要求。例：某培训中心业务处理系统（续）动词或动词结构：报名、发给、查询相关课程、检查、登记、开出报名单、复审、通知、查询课程文件、付款、交查询部门、给出答复、注销、修改、拒绝 对于以上的最初分析结果，必须逐个进行检查，首先排除的是属于培训中心系统操作人员的名词，如职员、财务部门、财务人员、查询部门等；其次，对于某些动词也要进行研究。例如，“报名”这个动词是“学员”这个外部实体的动作，会成生“报名数据”数据流，类似的还有交费、查询相关课程、注销等
