学习体会：高教自考软件工程课程概说总结（共五则）

第一篇：学习体会：高教自考软件工程课程概说总结

学习体会：高教自考软件工程课程概说总结

未接触软件工程之前一直都很想学这门课程，因为觉得这门课很NB，是那些有工程师称号的高手才摆弄的东西。但学过之后，最大的感触却是：软件工程方法一定要从娃娃抓起，否则到了后面坏习惯已经养成后再回过头来修正，那绝对是地狱般的磨难。下面就是我在近两个月的学习中一些总结和体会，希望对后来者有所补益。由于是初学这门课程，难免浅薄和有所错漏，还望大家多多指教。软件工程的由来

据说上个世纪60年代的程序员都是天才，写程式就像写日记一样，吃过晚饭没事干随手就可以写几个出来玩，第二天还可以拿去卖钱。所以那时候程序员在大家眼中，跟那些搞美术，音乐的是一类的，被称为“艺术家”。

但事过境迁，就像任何人都不会嫌钱多一样，永远都不会有人嫌CPU快的。于是，随之而来的就是硬件的迅猛发展和越来越变态的软件。记得以前常去同学家拷游戏，通常几张软盘就可以搞定，而现在的游戏，两三张CD-ROM都算少的了。像如此庞大复杂的怪物，就算你是如何的天才，一个人肯定是搞不定的，否则，等你把程式写出来，人家Intel连奔腾N都开发出来了。既要开发大型的软件还要追求速度(这样才能赚钱)，于是很自然地，合作的概念被提了出来。

在开始合作的初期，由于大家都习惯了当很有个性的“艺术家”，结果可想而知，一个是毕加索派的，而另一个是意大利印象派的，再加上一个画泼墨山水画的，要是像这样凑出来的东西都能不出问题的话，那么Bill早就转行了。所以，那时侯的大型软件，据说“蓝屏”比WINDOWS 98还多。

马克思告诉我们，万物都是从量变到质变的。随着问题的不断涌现，一些master们开始尝试去总结经验，并归纳了一些规范去指导软件的分析，设计，实现，测试，维护，人员交流协作，项目预算及时限控制等方方面面，这就是软件工程的前身。

软件工程到现在已发展了30多年，可以说是相当成熟的了。现在开发软件，据说都是一大帮人排排坐，按着一整套的规章制度来干活。于是，软件开发成了“工程”，程序员也就沦为“工人”了。

最初提出问题的是Dijkstra.他于1968年写给ACM的一封题为Goto Statement

Considered Harmful 的信中，指出了GOTO语句的负面作用，并提出了解决之道，其引发的一系列效应最终带来了软件工程的诞生。

软件工程的核心

无论是在上个世纪还是在现在，软件开发所涉及的工作基本上都没有变化，它们都起始于一个实际需要或某个灵感，然后就是分析，设计，编码，调试，维护。这些任务以某种方式动态地结合起来就构成了软件开发的整个过程，这就是所谓的“软件开发周期”。

但对于这些工作，具体怎样做，什么时候做，每个人都有自己的一套方式，甚至有的人有几套方式。这样，当几个人合在一起干活的时候，最终的结果就只能是一片混乱。所以就需要一套规则，大家都按规则来办事，问题就会少得多。好的规则就叫做规范，规范都是由一些master们根据经验总结的，又经过长时间的历练，不断地被补充修正，可以说都是精华，按照规范来干活，对于提高软件质量和工作效率自然大有帮助。

而软件工程，说白了，就是这样一套用于软件的团队开发，以提高软件质量和程序员工作效率为目的的规范。其核心就是，对于软件开发的5个重要组成部分：需求分析，设计，编码，调试，维护，如何组织这5个部分的工作，以及如何完成每一个工作。简单来说，就是对于总体的组织和对于局部的实现。

规范只是提供一个好的例子，以描述一种思想，具体到每一个环节怎样实现，对于不同的公司或团体则是各有千秋，因为根本就不可能存在一套放之天下皆可行的标准。就像C++，也只是提供了一套标准，不同的编译器都有各自的实现，对标准的支持程度也互不相同。所以，在不同的公司或团体中，尽管核心思想都是大同小异，但具体到每一个步骤，往往都是不相同的。我手上就有一份GB8567-88的文档模板，对于那些顶多只有几千行的小程序来说，假如真按上面的要求全写上了，简直就是一种折磨！据说，当前业界最权威的标准是CMM.软件开发过程的组织如何组织软件开发过程中的每一个步骤，就是软件开发周期模型要解决的问题。

其实开发软件，就像是解决一个逻辑问题。想想自己平时是怎样写程序的。首先是要有一个想法，即我写的这个程序是要干什么的；然后就是对要实现的核心功能大概构思一种或多种实现方法，并从中选出一种自认为是较好的；接下来就是将涉及的各种主要或次要功能分成各个模块；最后就是分模块来编码和DEBUG.在我看来，除了第一步外，其余的步骤应该是一个循环的过程。在编码的过程中，你总是需要不断地回过头来修改原先的模块设计，甚至最初选定的实现算法。例如，最简单的情况是，你通常都会突然发现在两个成员函数中有相同的代码，这时，程序员的直觉告诉你，你应该为你的类再添加一个private成员函数并将公共的代码放于其中；又或者是，你突然发现一个模块中的某个功能具有很高的通用性，完全可以提取出来作为一个独立的功能组件，而你也确实应该这样做；要是倒霉一点的话，你很有可能会在最后调试的时候突然发现，你的程序跑得太慢了，连你自己都无法忍受。于是你找呀找，终于找到了80/20中的那段可恶的20，原来是用了一个O(N)的算法，这时你就得老老实实地换一个更好的算法。

总之，除非你是先知，否则，对于一个具有一定规模和复杂度的软件来说，在“设计—编码”这个过程中，实在有太多的不可预知性和变化性，你根本不可能全盘地把握住每一个细节。当然，这是建立在我现时的水平之上的观点。我不知道是否成为高手以后会有所不同，因为我身边没有那样的人。

既然软件开发是一个具有不可预知性和变化性的动态的过程，那么，对其每一个步骤的组织，即周期模型，就必须包容它的这种性质。

现在来看一下最古老，最经典，同时也是最倍受批评的瀑布模型。

瀑布模型是一种线性模型，其最大的特点就是简单直观。它将软件开发过程规划为“分析—设计—编码—测试—维护”的线性过程，也就是说，你必须首先把你的软件要干的每一件工作都分析得彻彻底底，再对每一个模块，每一个接口，事无巨细，都设计得非常完美，然后才开始编码的工作，并且在编码的时候就像在对着图纸砌模型，根本不用再回头作任何修改，当然，是在把所有的代码都写完以后才开始测试的。

整个过程，光想一下就觉得冒冷汗！

瀑布模型完全忽视了软件开发过程的动态变化。恐怕只有那些已经发展得非常成熟，且规模不大的系统，例如：用Access做后台，用VB画前端的数据库应用程序，才有瀑布模型一展拳脚的地方。

相比之下，现在常用的一些周期模型则更接近于人的自然思维，例如螺旋模型就是一种我比较喜欢的模型。

软件开发过程的实现

具体到每一步的工作要怎样完成，我前面已提到过，是非常灵活的，只要把握住大体的方向就行。在进行分析，设计，编码，调试，维护这几部分的工作的时候，最核心的就是文档的编写。文档的作用在于以下3个方面：一是可以帮助整理思路。把要完成的目标，系统的结构，每一个模块的功能等整理一下，然后分门别类地写下来，这样在开发的过程中，就有据可依，在需要回过头来修改设计的时候，也有证可考。二是便于交流。想象一下开会时的情形。一大帮子人争先恐后，激烈辩论，然后会终人散，思想灵感也就随之散了，结果是开了半天会，什么也没讨论出来。这就是后来会议记录被发明出来的原因。在脑子里的东西一多，就会散而且乱，用语言表达的时候，很容易会丢三落四，别人也很难把握住你的思想。但经过整理写在纸上以后，则会清晰得多，无论是别人还是自己，看起来都可以一目了然。三是可以作为以后维护时的参考资料。有一句名言：“笔和纸永远都比大脑可靠”，意思就是说，放在大脑里的东西说不准哪天就忘了，但写在纸上的东西，只要不发生什么意外，一般是丢不了的。当过了一段时间，你需要再回过头来修改你的程序的时候，你就会发现，你以前写下的文档实在太有价值了。别指望你的源代码，对于复杂一点的程序来说，单纯的源代码几乎会扼杀掉你所有的时间。

至于文档怎样写，教科书上大多都是一条一条列得满满的，就像一些地方政府的规章制度一样，其实大可不必，只要能满足需要就行。如果是在公司，则每个公司大多都有一套自己内部的文档模板，个人没有选择的余地。而对于像我这种业余的，写个程序除了练练手艺，无非就是供自己和亲朋好友玩玩，则根本没必要搞得过于复杂。以下就是我自己的一份文档模板的概要，麻雀虽小，但五脏俱全。

可行性分析 就是关于当前项目能不能干的分析结果。主要考虑的方面包括：是否能把这个项目开发出来；假如可以的话，预计需要多少时间，能否满足客人的时间要求；需要多少人力和资金的投入；最重要的是，这个项目能否赚钱，能赚多少。还要对可能存在的风险进行评估，例如，万一项目主管被车撞了要怎么办。当然，这对于我来说毫无意义，我在这里写上只是为了保持完整而已。

项目描述 这是在决定立项以后，对当前项目的一份扼要说明。必须包括以下几个方面：

(1)项目的名称或编号；(2)对客户方的描述；(3)对开发人员的描述；(4)工程任务的描述；(5)工程的输入和输出；(6)开发环境；(7)其他的附加条件。在这里，对工程任务的描述是从整体的角度来说的，例如：能对当前的象棋棋局进行分析并作出最优决策的人工智能系统。而工程的输入输出则可以这样

第二篇：自考软件工程总结

何谓科学，何谓工程？（第一章）

科学是反映自然、社会、思维的发展与变化规律的知识体系。科学（研究）是以发现为核心的人类活动，探索事物的本质和运动规律，追求真理，认识世界，回答“为什么”，体现非物质形态财富。

工程是与生产、建设相关，运用自然科学理论和技术原理得以实现的活动（狭）。以构建、运行与集成为核心的人类活动，遵循社会需求，追求一定条件下的集成与综合优化。

2什么是可移植性（方法）？P347

把一个程序从一个硬件或软件系统环境移植到另一个环境所需的工作量。

3什么是软件生存周期？p7

软件生存周期是软件产品从形成概念，经过开发、使用和维护直至最后退役的全过程。大致分为如下6个阶段计算机系统工程、需求分析、设计、编码、测试、运行和维护

4.什么是可维护性p347

定位和修复程序中一个错误所需的工作量。

5文档功能是记录软件­____开发___活动和阶段成果，能供人和机器阅读，是有永久保存属性。

6.计算机软件是指与计算机系统有关的程序、规则、规程有任何与之有关的文档和数据。包括机器可执行的程序及有关数据；机器不可执行的与软件开发、运行、维护、使用和培训有关的文档。P1 程序：用程序设计语言描述的，计算机能够处理的语言序列。

文档：一种数据媒体及其上所记录的数据。文档（功能/作用）记录软件开发活动和阶段成果，能供人和机器阅读，具有永久保存属性。

7软件开发包括哪些阶段，主要解决什么问题？P19

概念定义，具体包括计划和需求分析阶段，主要解决做什么的问题。

开发，具体包括设计，编码，测试阶段，主要解决怎么做的问题。

使用维护，即运行维护阶段，包括些交付、安装、运行、维护和退役等。

8.软件概念定义包括那三部分，主要解 决什么问题。P4P1

（英文：Software）是一系列按照特定顺序组织的计算机数据和指令的集合。一般来讲划分为系统软件、支撑软件和应用软件。

9软件需求是指用户对目标系统在功能、行为、性能、设计、约束等方面的 期望P48

10.什么是模块？

模块指具有一定功能的可以用名字调用的程序语句集合。

模块化是指把一个待开发的软件划分成若干小的简单部件，每个部件称为一个模块，每个模块完成一个相对独立的一个子功能，所有这些模块集成起来就可以完成软件系统的指定功能，满足问题的要求。P66 模块化的目的是使程序的结构清晰，易阅读、易测试和修改。采用模块化方法，可以控制复杂问题的求解规模，减低问题复杂度和减少求解成本。

11什么 模块耦合度，什么是模块内聚度？P68

耦合是一个软件结构内不同模块彼此之间互相连接（依赖）的紧密程度。

耦合强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。耦合度衡量不同模块彼此间相互依赖的紧密程度。

内聚是一个模块内部各个元素彼此结合的紧密程度。好内聚的模块只做一件事情。内聚度衡量同一个模块内部的各个元素彼此结合的紧密程度。

模块的独立性可以由两项指标来衡量：内聚度与耦合度。.结构图最主要的质量指标是模块的 内聚度和 偶合度。（第五章）

13在设计用户界面（也称人机界面）的过程中，几乎总会遇到系统响应时间，用户求助机制，出错­­信息处理和命令交互方式四个方面的问题。P242

14.什么是系统响应时间？P242

系统响应时间指从用户执行某个控制动作（如按回车键或单击鼠标）到软件做出响应（期望的输出或动作）的时间。

15简答有哪三类人机界面设计指南（黄金原则）？p243

让用户拥有控制权；减少用户的记忆负担；保持界面一致

16.简述什么是编码？第十章P251

编码就是把软件设计结果翻译成用某种程序设计语言书写的程序。

17何谓程序设计风格或编码风格？P255

程序设计风格指一个人编制程序时所表现出来的特点,习惯逻辑思路等.在程序设计中要使程序结构合理、清晰，形成良好的编程习惯，对程序的要求不仅是可以在机器上执行，给出正确的结果，而且要便于程序的调试和维护，这就要求编写的程序不仅自己看得懂，而且也要让别人能看懂。

包括4个方面：源程序文档化、数据说明、语句结构、和输入输出。256

编写规则：文档化、结构化、模块化、节简化、简单化、格式化。

18.为一个开发项目选择程序设计语言时，通常会考虑 项目所属的领域 ；算法和计算复杂性；软件运行环境；用户需求中关于性能方面的要求；数据结构的复杂性，软件开发人员的知识水平因素。P255 19软件测试的目标是什么？P263PPT 第11章

软件测试就是在软件投入生产性运行之前，尽可能多地发现软件中的错误，进而改正错误的过程。发现和改正错误越多，交付的软件就质量越高，后期纠错性维护就越少。测试是一项很艰苦的工作，也是一项“建设性”活动

测试目标1.期望用最少的时间和人力找出软件中潜在的各种错误和缺陷 2.证明软件的功能和性能与规格说明的吻合程度3.为可靠性分析提供依据 4.通常测试每一种可能情况是不现实的5.没有发现程序中的错误，并不能证明软件没有错误

20.基本路径测试的基本思想是什么？P273程序环路复杂性有什么意义？PPT 第11章

基本思想：根据软件详细设计或代码中的控制结构流程确定复杂度，然后以该复杂度定义执行路径的基本集合，并由此导出一组测试用。

程序的环路复杂性确定程序基本路径集合中的独立路径条数。独立路径是指包括一组以前没有处理的语句或条件的一条路径。用流图术语描述，一条独立路径至少包含一条在其他独立路径中从没有过的边的路径。21简析等价类划分法？P277PPT 第11章

等价类划分法是把程序的输入数据集合按输入条件划分成若干个等价类，每一个等价类相对于输入条件表示为一组有效或无效的输入，然后据此为每一个等价类设计一个测试用例。

22.简述驱动模块和桩模块的作用？ PPT 第11章

驱动模块调用被测模块，接收测试输入数据并把这些数据传送给被测试的模块，被测模块调用后，驱动模块接受被测模块的返回数据。

桩模块也叫存根模块，它代替被测试的模块所调用的模块。桩模块使用被它代替的模块的接口，但内部只做少量的数据操作，并且把控制和模拟结果归还给调用它的模块。

23为何要引入驱动模块和桩模块？ PPT 第11章

驱动模块和桩模块是测试使用的软件，它们不是软件的组成部分，但需要一定的开发费用。简单的驱动模块和桩模块不能完成某些模块的测试任务，只能在集成测试过程中同时完成对这些模块的详尽测试。

引用驱动模块和桩模块原则有：单元测试通常与编码工作结合起来，通常，模块本身不是一个独立的程序，因此在测试模块中必须为每一个被测模块开发一个（引用）驱动模块和若干个桩模块。

24．何谓调试？ PPT 第11章

调试,又名排错,它是根据测试出问题的外部现象（又名错误或外错），分析找出问题的内在原因（又名故障或内错）并加以改正的代码执行与人工活动。调试的任务就是确定错误的准确位置（定位错误）、分析引发错误的原因，最终排除错误。

黑盒测试（行为测试）检查程序功能是否符合按照规格说明书的规定，测试只在程序界面上进行。包括等价类划分、边界值分析、比较测试、错误猜测何因果图方法。

白盒测试（结构测试）检验程序中的每条逻辑通路能否都按预定要求正确工作，测试按照程序内部的逻辑进行。包括逻辑覆盖测试、基本路径测试、数据流测试和循环测试。

25旅行社把预定机票的旅客信息，如姓名、年龄、单位、身份证号、旅行时间、目的地等输入预定机票系统，系统为旅客安排航班，打印出取票通知单（附有应交的账款）旅客在飞机起飞前交付票款，系统检查无误后，输出机票给旅客。

试用结构化分析方法描述系统的逻辑模型（系统的功能需求）并建立相应的数据字典，要求数据字典中至少包括一个数据流、一个数据文件、一个加工的详细的定义。

26.为方便储户，某银行拟开发计算机储蓄管理系统，储户填写的存款单或取款单由银行柜台业务员键入系统，如果是存款，系统记录存款人姓名，住址，存款日期，利率等信息，并印出存款单给储户；如果是取款，系统进行取款处理并印出结算单给储户，请用结构化分析方法描述系统的逻辑模型(系统的功能需求)，并建立相应的数据字典，要求数据字典中至少包括一个数据流，一个文件和一个加工的详细定义。

第三篇：自考软件工程笔记总结

第一章 绪论

1.1 软件工程的产生

1.1.1 软件的特点

软件的定义：计算机程序及其说明程序的各种文档 软件的特性：

(1)软件是一种逻辑产品，它与物质产品有很大的区别

(2)软件产品的生产主要是研制，软件产品的成本主要体现在软件的开发和研制上，软件开发研制完成后，通过复制就产生了大量软件产品

(3)软件产品不会用坏，不存在磨损、消耗问题

(4)软件产品的生产主要是脑力劳动，还未完全摆脱手工开发方式，大部分产品是“定做”的

(5)软件费用不断增加，软件成本相当昂贵

1.1.2 软件生产的发展

1)程序设计时代（1946年~1956年）

这个阶段的生产方式是个体手工劳动，使用的工具是机器语言、汇编语言。

开发方法是追求编程技巧，追求程序运行效率 程序难读、难懂、难修改

硬件特征是价格贵、存储容量小、运行可靠性差

软件特征是只有程序、程序设计概念，不重视程序设计方法 2)程序系统时代（1956年~1968年）

这个阶段的生产方式是作坊式的小集团合作生产，生产工具是高级语言

开发方式仍旧靠个人技巧，但开始提出结构化方法

硬件特征是速度、容量、工作可靠性有明显提高，价格降低，销售有爆炸性增长

软件特征是程序员数量猛增，大量其他行业人员进入这个行业，因为缺乏训练，因而开发人员素质差

这时已意识到软件开发的重要性，但开发技术没有新的突破，大量软件开发的需求已提出，但开发人员的素质和落后的开发技术不适应规模大、结构复杂的软件开发，产生了尖锐的矛盾，导致了软件危机的产生

3)软件工程时代（1968年至现在）

这阶段的生产方式是工程化的生产，使用数据库、开发工具、开发环境、网络、分布式、面向对象技术来开发软件

硬件特征是向超高速、大容量、微型化以及网络化方向发展

软件特征是开发技术有很大进步，但是未能获得突破性进展，软件价格不断上升，没有完全摆脱软件危机

1.1.3 软件危机

1.软件危机的产生

软件发展到第二阶段末期，软件开发技术的进步跟不上硬件发展的速度

2.软件危机的表现 1.1.4(1)经费预算经常突破，完成时间一再拖延(2)开发的软件不能满足用户要求(3)开发的软件可维护性差(4)开发的软件可靠性差 3.软件危机的原因

(1)软件的规模越来越大，结构越来越复杂(2)软件开发管理困难而复杂(3)软件开发费用不断增加(4)软件开发技术落后(5)生产方式落后(6)开发工具落后 软件工程

1968年北大西洋公约组织的工作会议上首先提出“软件工程”的概念，要用工程化的思想来开发软件 1.软件工程定义

用科学知识和技术原理来定义、开发、维护软件的一门科学 2.软件工程的性质

软件工程是一门综合性的交叉学科，涉及计算机科学、工程科学、管理科学、数学等领域

计算机科学中的研究成果均可用于软件工程，但计算机科学着重于原理和理论，而软件工程着重于如何建造一个软件系统

软件工程要用工程科学中的观点来进行费用估算、制定进度、制定计划和方案

软件工程要用管理科学的方法和原理进行软件的生产和管理 软禁工程要用数学的方法建立软件开发中各个种模型和各种算法 3.软件工程目标

目的是成功的建造一个大型软件系统 所谓成功，是要达到

付出较低的开发成本

达到要求的软件功能

取得较好的软件性能

开发的软件易于移植

需要较低的维护费用

能按时完成开发任务，及时交付使用

开发的软件可靠性高 4.软件工程内容

主要是软件开发技术和软件管理两个方面

软件开发技术中主要研究软件开发方法、软件开发过程、软件开发工具和环境

软件开发管理中主要研究软件管理学、软件经济学、软件心理学 5.软件工程面临的问题

a)软件费用 b)软件可靠性 c)软件维护 d)软件生产率 e)软件重用

1.2 软件工程过程和软件生存周期

1.2.1 软件工程过程

目的是为各种人员提供一个公共的框架，以便用相同的语言进行交流

(1)获取过程(2)供应过程(3)开发过程(4)操作过程(5)维护过程(6)管理过程(7)支持过程 1.2.2 软件生存周期

指一个软件从提出开发要求开始直到该软件报废为止的整个过程

(1)可行性分析和项目开发计划

必须要回答的问题是“要解决的问题是什么”，有可行的解决办法吗，如果有需要多少费用多少资源时间 明确项目性质 明确项目目标 明确项目规模

确定该问题有没有可行的解决办法 指定项目开发计划(2)需求分析

确定软件系统必须做什么

确定软件系统必须具备哪些功能(3)概要设计

把确定的各项功能需求转换成需要的体系结构 设计软件的结构，明确该结构的模块组成(4)详细设计

为每个模块完成的功能进行具体描述，把功能描述转变为精确地、结构化的过程描述(5)编码

把每个模块的控制结构转换成计算机可接受的程序代码，即写成以某种特定程序设计语言表示的“原程序清单”(6)测试

保证软件质量的重要手段(7)维护

1.3 软件生存周期模型、方法和工具

1.3.1 软件生存周期模型

描述软件开发过程中各种活动如何执行的模型 1.瀑布模型

将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型 包括所有的软件生存周期环节，规定了由前至后、相互衔接的固定次序 1.3.2 缺点：

理想的线性开发模式，缺乏灵活性

开发过程中用户看不到软件是什么样子，造成开发方向错误 2.增量模型

一种非整体开发的模型，软件在该模型中是“逐渐”开发出来的，开发一部分展示一部分，可以及早发现问题。或者开发一个“原型”软件，完成部分主要功能再逐步完善

具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目 缺点：

对于复杂的大型软件，开发一个原型往往达不到要求 3.螺旋模型

将瀑布模型与增量模型结合起来，加入了两种模型均忽略了的风险分析

开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合 每个周期内分四个工作不：制定计划、风险分析、开发实施、用户评估

适合于大型软件的开发 缺点：

需要有相当丰富的风险评估经验和专门知识，使得应用受到一定限制 4.喷泉模型

一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法

克服了瀑布模型不支持软件重用和多想开发活动集成的局限性 是开发过程具有迭代性和无间隙性 5.基于知识的模型

又称只能模型，它把瀑布模型和专家系统结合在一起 还处于研究实验阶段，还未达到实用阶段 6.变换模型

适合于形式化开发的模型 软件开发方法

使用早已定义好的技术集和符号表示习惯来组织软件生产的过程 1.结构化方法

由结构化分析，结构化设计、结构化程序设计构成，是一种面向数据流的开发方法。简单实用，应用较广，技术成熟 2.Jackson方法

面向数据结构的开发方法 3.维也纳开发方法（VDM）

一种形式化的开发方法，软件需求用严格的形式语言描述，然后把描述模型逐步变换成目标系统 4.面向对象的开发方法

90年代主流

基本出发点是尽可能按照人类认识世界的方法和思维方式来分析和解决问题

包括面向对象分析、面向对象设计、面向对象实现

1997年推出统一建模语言UML，是面向对象的标准建模语言

1.3.3 软件开发工具

1． 软件工具的重要性

为了支持软件人员开发和维护活动而使用的软件

项目估算工具、需求分析工具、编码工具、测试工具、维护工具等 2． 工具箱

将各种软件工具简单组合起来就构成工具箱

工具箱的工具界面不同意，工具内部无联系，工具切换由人工操作 3． 软件开发环境

工具系统的整体化及集成化，使之形成完整的软件开发环境 使软件工具支持整个生存周期 4． 计算机辅助软件工程

新的软件工具目的是实现软件生存周期各个环节的自动化，主要用于软件的分析和设计，使用这些工具开发人员可以以对话的方式建立各种软件系统

计算机辅助软件工程可以简单的定义为软件开发的自动化，CASE 结构化方法可以用于瀑布模型、增量模型、螺旋模型进行开发 Jackson方法可以用于瀑布模型、增量模型 维也纳方法只能用于变换模型进行开发

第二章 软件可行性研究与项目开发计划

2.1 可行性研究

目的是用最小的代价在尽可能短的时间内去确定该项目是否能够开发，是否值得开发

在较高层次上以较抽象的方式进行需求分析和设计过程 2.1.1 可行性研究的任务

进行概要的分析研究，初步确定项目的规模和目标，确定项目的约束和限制，列举出来。然后进行简要的需求分析，抽象出项目的逻辑结构，建立逻辑模型，从逻辑模型出发经过压缩的设计，探索出若干种可供选择的解决办法，对每种解决方法都要研究它的可行性

可以从以下三个方面分析研究每种解决方法的可行性

1.技术可行性、技术可行性一般要考虑的情况包括(1)开发的风险(2)资源的有效性(3)技术

(4)开发人员在评估技术可行性时，一旦估计错误，将会出现灾难性后果

2.经济可行性

进行开发成本的估算以及了解取得效益的评估，确定要开发的项目是否值得投资开发 3.社会可行性

要开发的项目时候存在任何侵犯、妨碍等责任问题，要开发项目的运行方式在用户组织内是否行得通，现有管理制度、人员素质、操作方式是否可行

2.1.2 可行性研究的具体步骤

1.确定项目规模和目标

2.研究正在运行的系统

3.建立新系统的高层逻辑模型

使用建立逻辑模型的工具——数据流图和数据字典描述数据在系统中的流动和处理情况。不是需求分析阶段，不是完整详细的描述，只是概括的描述高层的数据处理和流动

4.导出和评价各种方案

5.推荐可行的方案

6.编写可行性研究报告

2.1.3 可行性研究报告的主要内容

1．引言

2．可行性研究前提

3．对象有系统的分析

4．所建议系统的技术可行性分析

5．所建议系统的经济可行性分析

6．社会因素可行性分析

7．其他可供选择方案

8．结论意见 2.2 系统流程图

1．系统流程图的作用

用图形符号来表示系统中的各个元素。表达了系统中各个元素之间的心理流动的情况

2．系统流程图的符号

3．系统流程图的例子

2.3

成本——效益分析

目的是从经济角度评价开发一个新的软件项目是否可行

估算将要开发的系统的开发成本，与可能取得的效益进行比较和权衡 效益分有形效益和无形效益 有形效益的分析 1． 货币的时间价值 2． 投资回收期 3． 纯收入 2.4 项目开发计划

1．项目概述

2．实施计划

3．人员组织及分工

4．交付期限

第三章 软件需求分析

3.1 需求分析的任务

3.1.1 需求分析的概念

开发人员要准确的理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义装换到相应的形式功能规约（需求规格说明）的过程 需求分析的难点：(1)问题的复杂性(2)交流障碍

(3)不完备性和不一致性(4)需求易变性

软件需求分析与说明的方法适用的基本原则：(1)必须能够表达和理解问题的数据域和功能域

(2)可以把一个复杂问题按功能进行分解并可逐层细化(3)建模

结构化分析方法和面向对象分析方法都遵循以上原则

3.1.2 需求分析的基本任务

要准确的定义新系统的目标，为了满足用户的需要，回答系统必须“做什么”的问题。可行性研究和软件计划阶段对这个问题的回答是概括的、粗略的 本阶段主要进行以下几个方面的工作： 1.问题识别

双方确定对问题的综合需求，这些需求包括：

(1)功能需求：所开发的系统必须具备什么样的功能，这是最重要的(2)性能需求：待开发的软件的技术性能指标。存储容量，运行时间(3)环境需求：软件运行时所需要的软、硬件的要求

(4)用户界面需求：人机交互方式、输入输出数据格式等等

另外还有可靠性、安全性、保密性、可移植性、可维护性等方面的需求 2.分析与综合，导出软件的逻辑模型

对获取的需求，进行分析检查，逐步细化软件的功能，划分成各个子功能，以确定系统的构成及主要成分，建立新系统的逻辑模型 3.编写文档

(1)编写“需求规格说明书”(2)编写初步用户使用手册(3)编写确认测试计划(4)修改完善软件开发计划

3.1.3 需求规格说明书主要内容 3.2 结构化分析方法

简称SA，是面向数据流进行需求分析的方法

3.2.1 自顶向下逐层分解的分析策略

对一个复杂问题分析人员不可能一开始就考虑到问题的所有方面及全部细节，对此采取的策略是分解，把一个复杂问题划分成若干小问题，然后分别解决，将问题的复杂性降低到人可以掌握的程度

分解可分层进行，先考虑问题最本质的方面，忽略细节形成问题的高层概念，然后逐层添加细节。顶层抽象的概括整个系统，底层具体画出系统的每个细节，中间层是逐步过渡

这种层次分解使分析人员分析问题时不至于一下子陷入细节，而是逐步的去了解更多细节

依照这个策略，对于任何复杂的系统，分析工作都可以有计划、有步骤、有条不紊的进行

3.2.2 描述工具

SA方法的描述工具是：

(1)数据流图(2)数据字典

(3)描述加工逻辑的结构化语言、判定表、判定树

数据流图描述系统的分解，及系统由哪几部分组成，各部分之间的联系等等 数据字典定义了数据流图中每一个图形元素 结构化语言、判定便或判定树详细描述数据流图中不能被再分解的每一个加工

3.2.3 SA分析步骤

(1)了解当前系统的工作流程，获得当前系统的物理模型(2)抽象出当前系统的逻辑模型(3)建立目标系统的逻辑模型(4)做进一步补充和优化

3.3 数据流图（DFD）

简称DFD，是SA方法中表示系统逻辑模型的一种工具，只反应系统必须完成的逻辑功能，所以是一种功能模型

3.3.1 基本图形符号

数据流图有四种基本图形符号：

(1)数据流。是数据在系统内传播的路径，由一组成分固定的数据项组成，必须有流向，除了与数据存储之间的数据流不用命名，其他用名词或名词短语命名

(2)加工（又称为数据处理）。对数据流进行某些操作或变换。加工用动词短语命名

(3)数据存储（又称为文件）。指暂时保存的数据，它可以是数据库文件或任何形式的数据组织。流向数据存储的数据流可以理解为写入文件或查询文件，流出的数据可以理解为从文件读取数据或得到查询结果

(4)数据源点或终点：软件系统外部环境中的实体（包括人员、组织或其他软件系统），统称为外部实体

在一张图上可重复画同名的源/终点，在方框的右下角加斜线则表示是一个实体。有时数据存储也需重复标识

3.3.2 画数据流图的步骤

按问题的层次结构进行逐步分解，并以一套分层的数据流图反应这种结构关系

(1)首先画系统的输入输出，即先画顶层数据流图。

顶层流图只包含一个加工，用以表示被开发的系统，然后考虑系统的输入输出数据。顶层图的作用在于表明被开发的系统范围以及它与周围化境的数据交换关系

(2)画系统内部，即画下层数据流图。一般将层号从0开始编号，采用自顶向下，由外向内的原则。一般沿着输入流的方向，凡数据流的组成或值发生变化的地方则设置一个加工，这样一直进行到输出数据流。知道每一个加工足够简单，不能再分解为止，不能再分解的加工称为基本加工(3)注意事项

a)命名

b)画数据流而不是控制流

图中不反应加工的执行顺序 c)一般不画物质流

d)每个加工至少有一个输入数据流和一个输出数据流，反映出此加工数据的来源与加工的结果 e)编号

子图的编号就是父图中相应加工的编号，加工的编号由子图号，小数点和局部号组成 f)父图与子图的平衡

子图的输入输出数据流同父图相应加工的输入输出数据流必须一致 保证了数据流图的一致性 g)局部数据存储

h)提高数据流图的易理解性

注意合理分解

为了使数据流图便于在计算机上输入与输出，以下给出了描述数据流图的另一套基本符号

3.3.3 实例——售票管理系统

3.4 数据字典（DD）

简称DD，用来定义数据流图中各个成分的具体含义，它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述 它和数据流图共同构成了系统的逻辑模型，是需求规格说明书的主要组成部分

3.4.1 数据字典的内容及格式

数据字典是为分析人员查找数据流图中有关名字的详细定义而服务的，因此也像普通字典一样，要把所有条目按一定的次序排列起来，以便查阅 数据字典有以下四类条目： 数据流 数据项 数据存数 基本加工

数据项是组成数据流和数据存储的最小元素。源点终点一般不在字典中说明 1.数据流条目

数据流条目给出了DFD中数据流的定义，通常列出数据流的各组成数据项

在定义数据流或数据存储组成时，使用下表给出的符号：

2.数据存储条目

数据存储条目是对数据存储的定义，主要内容举例如下：

3.数据项条目 数据项条目是不可再分解的数据单位，其定义格式及举例如下：

4.加工条目

加工条目是用来说明DFD中基本加工的处理逻辑的，由于上层的加工是由下层的基本加工分解而来，只要有了基本加工的说明，就可理解其他加工

加工条目的内容及举例如下：

数据字典中的加工逻辑主要描述该加工“做什么”，即实现加工的策略，而不是实现加工的细节，它描述如何把输入数据流变换为输出数据流的加工规则。加工逻辑有几种常用的描述方法，结构化语言、判定表、判定树

3.4.2 数据字典的实现

建立数据字典一般有两种形式：

1.手工建立：数据字典的内容用卡片形式存放

(1)按四类条目规范的格式印制卡片(2)在卡片上分别填写各类条目的内容

(3)先按图号顺序排列，同一图号的所有条目按数据流、数据项、数据存储和数据加工的顺序排列(4)同一图号中的同一类条目（如数据流卡片）可按名字的字典顺序存放，加工一般按编号顺序存放

(5)统一成分在父图和子图都出现时，则只在父图上定义(6)建立索引目录

2.利用计算机辅助建立并维护(1)编制一个“字典生成与管理程序”，可以按规定的格式输入各类条目，能对字典条目增、删、改，能打印查询报告和清单，能进行完整性一致性检查。美国密执安大学研究的PSL/PSA就是这样一个系统(2)利用已有的数据库开发工具，针对数据字典建立一个数据库文件，可将数据流、数据项、数据存储和加工分别以矩阵表的形式来描述各个表项的内容，如数据流的矩阵表为：

有的DBMS本身包含一个数据字典子系统，建库时能自动生成数据字典

计算机辅助开发数据字典比手工建立数据字典有更多的优点，能保证数据的一致性和完整性，使用也方便，但增加了技术难度与积极开销

3.5 加工逻辑的描述

加工逻辑也称为“小说明”，描述加工逻辑一般用一下三种工具：

结构化语言

判定表

判定树

3.5.1 结构化语言

介于自然语言和形式语言之间的一种半形式语言

结构可分为外层和内层两层：

1.外层：用来描述控制结构，采用顺序、选择、重复三种基本结构

(1)顺序结构：是一组祈使语句、选择语句、重复语句的顺序排列(2)选择结构：一般用IF——THEN——ELSE——ENDIF、CASE——OF——ENDCASE等关键词(3)重复结构：一般用DO——WHILE——ENDDO、REPEAT——UNTIL等关键字

2.内层：一般是采用祈使语句的自然语言短语，使用数据字典中的名词和有限的自定义词，其动词含义要具体，尽量不用形容词和副词来修饰。还可使用一些简单的算术运算和逻辑运算符号

3.5.2 判定表

在有些情况下，数据流图中的某个加工的一组动作依赖于多个逻辑条件的取值。这时用判定表就能够清楚地表示复杂的条件组合与应作的动作之间的对应关系

判定表由四部分组成，用双线分隔开四个区域：

构造一张判定表，可采取以下步骤： 1.提取问题中的条件 2.标出条件的取值

3.计算所有条件的组合数N 4.提取可能采取的动作或措施 5.制作判定表 6.完善判定表

初始的判定表可能不完善，表现在以下几个方面：(1)缺少判定列中应采取的动作

(2)有冗余的判定列：两个或多个规则中，具有相同的动作，而与它所对应的各个条件组合中有取值无关的条件

判定表能够把在什么条件下系统应做什么动作准确无误的表示出来，但不能描述循环的处理特性，循环处理还需结构化语言 例子：

3.5.3 判定树

判定树是判定表的变形，一般情况下它比判定表更直观，更易于理解和使用

这三种描述加工逻辑的工具各有优缺点

对于顺序执行和循环执行的动作，用结构化语言描述

对于存在多个条件复杂组合的判断问题，用判定表和判定树 判定树较判定表直观易读，判定表进行逻辑验证较严格，能把所有的可能性全部都考虑到，可将两种工具结合起来，先用判定表做底稿，在此基础上产生判定树

经过需求分析，开发人员已经基本上理解了用户的要求，确定了目标系统的功能，定义了系统的数据，描述了处理这些数据的基本策略。将这些共同的理解进行整理，最后形成文档——需求说明书

3.6 IDEF方法

IDEF方法是美国空军在1981年针对集成化计算机辅助制造工程项目中用于进行复杂系统分析和设计的方法。IDEF方法分为三部分：

IDEF0：用来描述系统的功能活动及其联系，建立系统的功能模型 IDEF1：用来描述系统的信息及其联系，建立系统的信息模型 IDEF2：用来进行系统模拟，建立系统的动态模型

3.6.1 IDEF0的图形表示

该方法中，将系统功能称为活动，将表示系统功能的图形称为活动图形

一个活动可以没有输入，但一定要有控制

3.6.2 建立功能模型的基本方法

1.确定建模的范围、观点及目的 2.建立系统的内外关系图——A-0图 3.建立顶层图——A0图 4.建立低层次的图形

分解时，应遵循两条原则：

首先，保持在同一水平上分解（宽度优先），如A1，A2，A3等图，而不是A1，A11，A111（深度优先），可避免较高层次的变化影响较低层次，造成可能的重复工作，同时可较早的查出错误及遗漏

其次，对于同一水平层次上的各个方框，选择难度最大的部分往下分解，其后分解较容易的部分

在IDEF0图中几个活动之间无明确的顺序和时间，要注意分解时箭头表示的上下层之间的平衡关系。

3.6.3 IDEF0方法的特点

1.采用方框和箭头等简单的图形符号描述系统的活动和数据流，描述活动所受到的约束条件及实现机制 IDEF0图宜作为正式文档

2.采用严格的自顶向下、逐层分解的方式建立系统功能模型

因此，IDEF0是建立系统功能模型的有效方法。在开发CIMS——计算机集成制造系统的管理信息系统（MIS）过程中，大都采用此方法建立软件需求分析的功能模型

3.7 结构化分析方法小结

结构化分析方法是软件需求分析中公认的、有成效的、技术成熟、使用广泛的一种方法，它较适合于开发数据处理型软件的需求分析 SA方法的弱点主要表现在：(1)不适合描述实时控制系统(2)

(3)

(4)

(5)为了解决实时软件的需求分析，提出了控制流图（CFD）的定义，也有用描述系统动态行为的状态转换图（STD）代替CFD SA方法使用DFD在分析与描述“数据要求”方面是有局限的

数据库技术使许多大型数据处理系统中的数据都组织成数据库的形式，DFD应与数据库技术中的实体联系图（ER图）结合起来 DFD不适合描述人机界面系统的需求

对于一些频繁的人机交互的软件系统，SA方法往往对这一部分用自然语言做补充，对这类系统可采用其它的分析方法（如面向对象分析方法）不便于实现自动化

SA方法可与形式化方法结合起来，形式化是软件自动化发展的基础 形式化方法典型的有基于模型的Z语言及VDM开发方法 需求分析的质量及效率不够高 可以借助需求分析工具提高

第四篇：自考软件工程问答总结

一.什么是软件

1.满足功能要求和性能的指令或计算机程序集合;2.处理信息的数据结构;3.描述程序功能以及程序如何操作和使用所要求的文档;

二.软件危机以及产生软件危机的原因

1.软件开发生产率提高的速度,远远跟不上计算机迅速普及的趋势.软件产品“供不应求”.2.软件成本在计算机系统总成本中所占的比例逐年上升.3.软件开发人员和用户之间的信息交流往往很不充分,用户对“已完成的”的软件系统不满足的现象经常发生.4.软件产品的质量不容易保证.5.软件产品常常是不可维护的.6.软件产品的重用性差,同样的软件多次重复开发.7.软件通常没有适当的文档资料.产生软件危机的原因可归结为两个重要的方面: 软件生产本身存在的复杂性;软件开发所使用的方法和技术.三.有哪些软件工程方法学及其要素

1.使用最广泛的软件工程方法学是结构化方法学和面向对象的方法学.2.要素:方法,工具和过程.四.什么是软件生存周期 有哪些活动

4.1软件生存周期

一个软件从提出开发要求开始到软件废弃不用的整个过程.4.2 开发活动

可行性分析和项目开发计划,需求分析和定义,软件设计(先后细分为:概要设计和详细设计),编码,测试和运行维护 4.3 各活动阶段主要文档

4.3.1可行行分析和项目开发计划 可性行研究报告 项目开发计划

4.3.2需求分析中的文档 需求规格说明书 初步用户使用手册 确认测试计划

修改完善的软件开发计划 4.3.3 概要设计阶段文档 概要设计说明书 数据库说明书 用户手册

修订的测试计划(测试的策略,方法,步骤)4.4.4 详细设计阶段 详细设计说明书 4.4.5 系统测试阶段 系统测试计划文档

五.有哪些主要生命周期模型

瀑布模型,原型开发模型(快速原型模型,演化模型,增量模型),螺旋模型,喷泉模型,基于知识的模型和变化模型.5.1 瀑布模型

瀑布模型(传统的软件周期模型)严格遵循软件生命周期各阶段的固定顺序:计划,分析,设计,编程,测试和维护,上一阶段完成后才能进入到下一阶段,整个模型就像一个飞流直下的瀑布 优点:可强迫开发人员采用规范的方法,严格规定了各阶段必须提交的文档;要求每一阶段结束后,都要进行严格的评审.与它最相适应的开发方法是结构化方法.缺点:不适应用户需求的改动.5.2 原型模型

5.2.1 快速原型模型

快速原型的用途是获知用户的真正需求,一旦需求确定了,原型即被抛弃.主要用于需求分析阶段.不追求也不可能要求对需求的严格定义,而是采用了动态定义需求的方法,所以不能定义完善的文档.特征:简化项目管理,尽快建立初步需求,加强用户参与和决策.具有广泛技能水平的原型化人员是原型实施的重要保证.原型化人员应该是具有经验与才干,训练有素的专业人员.衡量原型化人员能力的重要标准是他是否能够从用户的模糊描述中快速获取需求.5.2.2 演化模型

在快速原型模型中,原型的用途是获知用户的真正需求,一旦需求确定了,原型即被抛弃.而演化模型应用于整个软件开发过程,是从初始模型逐步演化为最终软件产品的渐进过程.也就是说,快速原型模型是一种“抛弃式”的原型化方法,而演化模型则是一种“渐进式”的原型化方法.5.2.3增量模型

增量模型主要用于设计阶段,把软件产品划分为一系列的增量构件,分别进行设计,编程,集成和测试.新的增量构件不得破坏已经开发出来的产品 5.2.4 原型模型小结

从下面的有关原型化方法的叙述中,选择出正确的叙述:(1)快速原型方法是一种企图克服传统软件周期模型缺点的开发方法.(2)在用户的数据资源没有得到很好地组织和管理的时候,应该使用原型化方法.(3)在用户没有明确地肯定其需求的时候,应该使用原型化方法.(4)在用户不希望把自己的时间花在软件开发过程中的时候,应该使用原型化方法.(5)使用原型化方法时应该使用第三代编程语言.(6)原型化加强了开发过程中用户的参与和决策.(7)原型化方法大致可分为三类:抛弃式,演化式和递增式.(8)原型化方法大致可分为演化式和递增式.(9)采用原型化方法时,软件的开发成本较高.(10)采用原型化方法时,关键的因素是建立原形的速度,而不是原形运行的效率.5.3 螺旋模型

螺旋模型综合了瀑布模型和原型模型中的演化模型的优点,还增加了风险分析.螺旋线第一圈的开始点可能是一个概念项目.从第二圈开始,一个新产品开发项目开始了,新产品的演化沿着螺旋线进行若干次迭代,一直转到软件生命期结束.5.4 喷泉模型

喷泉模型主要用于描述面向对象的开发过程.喷泉一词体现了面向对象开发过程的迭代和无间隙特征.六.软件过程基础知识 6.1 软件过程

软件过程是指人们用于开发和维护软件及相关产品的一系列活动,包括软件工程过程和软件管理过程.6.2 评估工具

软件过程的评估,通常采用软件能力成熟度 模型(Capability Maturity Model,CMM).CMM1.1的5个等级(由低级到高级): 初始级

软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力,管理是反应式(消防式)的.可重复级

建立了基本的项目管理过程来跟踪费用,进度和功能特性.制定了必要的过程纪律,能重复早先类似应用项目取得的成功.已定义级

已将软件管理和工程两方面的过程文档化,标准化,并综合成该组织的标准化软件过程.所有项目均使用经标准,裁减的标准软件过程来开发和维护软件.已管理级

收集对软件过程和产品质量的详细度量,对软件过程和产品都有定量的理解与控制.优化级

加强了定量分析,通过来自过程质量反馈和来自新观念,新技术的反馈使过程能持续不断地改进.七.软件工程项目管理基本知识

软件项目管理开始于任何技术活动之前,并且贯穿于整个的软件生命周期.软件工程项目管理一般分为时间管理,成本管理,人力资源管理,风险管理.7.1时间管理 7.1.1 Gantt图

是一种简单的水平条形图,它以水平线段表示子任务的工作阶段,线段的起点和终点分别对应着子任务的起始时间,线段长度指示完成该任务所需要的时间.甘特图的优点:直观简明,易学易绘,可从图上清楚地标出子任务间的时间对比,但它也有 缺点:

(a)不能显示地描绘各项彼此间的依赖关系;(b)进度计划的关键部分不明显,难以判断哪些部分应当是主攻和主控的对象;(c)计划中有潜力的部分以及潜力的大小不明确,往往造成潜力的浪费.7.1.2 PERT网图与关键路径

PERT网图是一个由箭头(标识任务)和结点(标识事件)组成的有向图.将网络方法用于工作计划安排的评审和检查.开发模块A,B,C模块的任务网络图 PERT图不仅给出了每个任务的开始时间,结束时间和完成该任务所需的时间,还给出了任务之间的依赖关系,即哪些任务完成后才能开始另一些任务,以及如期完成整个工程的“关键路径”.关键路径(Critical Path)是由一连串的任务所组成的链,距离最大的一条路径.软件项目的管理人员应该密切注视关键任务的进展情况.如果希望缩短工期,只有往关键任务中增加资源才会有效果.7.2成本管理

一种常用的成本估算方法是先估计完成软件项目所需的工作量(人月数),然后根据每个人月的代价(金额)计算机软件的开发费用: 开发费用 = 人月数×每个人月的代价

另一种方法是估计软件的规模(通常指源代码行数),然后根据每行源代码的平均开发费用(包括分析,设计,编码,测试所花的费用),计算机软件的开发费用: 开发费用=源代码行数×每行平均费用

估算源代码行数时,可以请n为有经验的专家,每位专家对软件给出3各估计值: ai---最少源代码行数(该软件可能的最小规模)bi---最大源代码行数(该软件可能的最大规模)mi---最可能的代码行数(该软件最可能的规模)然后计算出每位专家的估算期,n位专家的估算期望值的平均值就是代码行数的估算值.7.3 其他管理 人力资源管理 风险管理

风险管理的主要活动有风险识别,风险估算,风险评价和风险控制.八.模块化基本知识

模块是指执行某一特定任务的数据和可执行语句程序元素的集合,通常是指可通过名字来访问的过程,函数,子程序或宏调用等.模块化就是将一个待开发的软件划分成若干个可完成某一子功能的模块,每个模块可独立地开发,测试,最后组装成完整的程序.8.1模块特性 8.1.1 可分解性

如果一种设计方法提供了将问题分解成子问题的系统化机制,它就能降低整个系统的复杂性,从而实现一种有效的模块化解决方案.8.1.2 可组装性

如果一种设计方法使现存的(可复用的)设计构件能被组装成新系统,它就能提供一种不需要一切从头开始的模块化解决方案.8.1.3 可理解性

如果一个模块可以作为一个独立的单位(不用参考其他模块)被理解,那么它就易于构造和修改.8.1.4 连续性

如果对系统需求的微小修改只导致对单个模块,而不是整个系统的修改,则修改引起副作用就会被最小化.8.1.5 保护性

如果模块内部出现异常情况,并且它的影响限制在模块内部,不会影响其他模块,则错误引起的副作用就会被最小化.8.2 模块与模块的耦合性

耦合是对一个软件结构内不同模块之间互连程序的度量.耦合可以分成下列几种,它们之间的耦合度由高到低排列.8.2.1 内容耦合

直接操作或修改另一模块的数据,或不通过正常入口转入另一个模块.软件设计时应坚决禁止内容耦合,应设计成单入口,单出口的模块,避免病态连接.8.2.2 公共耦合

多个模块引用同一全局数据区.例如,C语言中的external数据类型,磁盘文件等都是全局数据区.8.2.3 外部耦合

模块与软件以外的环境有关联.例如,输入输出把一个模块与特定的设备,格式,通信协议耦合在一起.8.2.4 控制耦合

一模块明显把开关量,名字等信息送入另一模块,控制另一模块的功能.8.2.5 标记耦合

两个模块之间通过传递公共指针或地址相互作用的耦合.8.2.6 数据耦合

模块间通过传递数据交换信息.8.2.7 非直接耦合(无耦合)模块间无任何关系,独立工作

原则上讲,模块化设计总是希望模块之间的耦合表现为非直接耦合方式.在以上耦合中,耦合度从高到低,内容耦合度最高,非直接耦合度最低.8.3 模块的内聚性

内聚是指一个模块内各个元素彼此结合的紧密程序,它是信息隐蔽和局部的概念的自然扩展.设计时应该力求高内聚,理想内聚的模块应当恰好做一件事情.1).偶然内聚:一个模块的各成分之间毫无关系.比如:一组语句在程序的多处出现,为了节省内存空间,这些语句放在一个模块中,该模块的内聚是偶然内聚的.2)逻辑内聚:把几种逻辑上相关的功能组放在同一模块中.3)瞬时内聚(时间内聚):一个模块所包含的任务必须在同一时间间隔内执行,例如初始化模块.4)过程内聚:一个模块的处理元素是相关的,而且必须按特定的次序执行.5)通信内聚:一个模块的所有成分都结合再同一个数据结构上.6)顺序内聚:模块的成分同一个功能密切相关,且输出,作为另外一个成分的输入.7)功能内聚:模块内的所有成分属于一个整体,完成单一的功能.在以上的内聚中,内聚度从低到高,偶然内聚度最低,功能内聚度最高.模块的高内聚,低耦合的原则称为模块独立原则,也称为模块设计的原则.8.4 模块的深度,宽度,扇出与扇入 深度:表示软件结构中控制的层数.宽度是软件结构中同一个层次上的模块总数的最大值 一个模块的扇入是指直接调用该模块的上级模块的个数.一个模块的扇出是指该模块直接调用的下级模块的个数.设计原则:低扇出 高扇入 8.5 模块作用域和控制域

软件设计时,模块的作用域应在控制域之内.8.6 模块化基础知识小结

通过模块的合并和分解,降低模块的耦合度.模块的扇入应尽量大,扇出应尽量小.一个模

块的扇入是指直接调用该模块的上级模块的个数.一个模块的扇出是指该模块直接调用的下级模块的个数.扇入大表示模块的重用性高,利用率高.扇出大表示模块的复杂度高.所以要高扇入低扇出.要将模块的作用范围限制在模块的控制范围之内.降低模块之间的复杂性,避免“病态连接”.九.什么是软件开发方法 有哪些主要方法

软件开发方法:使用已定义好的技术集及符号表示习惯组织软件生产的过程.结构化方法,面向对象方法,JACKSON方法,维也纳开发方法(VDM).9.1 结构化方法学

结构化方法学也称为生命周期方法学(瀑布模型方法),是一种面向数据流的需求分析方法.它的基本思想是自顶向下逐层分解.为了在需求改变时对软件的影响较小,结构化分析时应该使程序结构与问题结构相对应.常用工具: 数据流图(DFD),数据字典(DD),实例—关系图(E—R图)及描述加工处理的结构化语言,判定表,判定树.9.1.1数据流图(DFD图)DFD的基本成分

数据流图主要由4种成分组成

数据流(data flow):由一组固定成分的数据组成,表示数据的流向.它可以从源,文件流向加工,也可以从加工流向文件和宿,还可以从一个加工流向另一个加工.通常每个数据流必须有一个合适的名字,一方面是为了区别,另一方面也给人一个直观的印象,使人容易理解这个数据流的含义.但流向文件或从文件流出的数据流不必命名,因为这种数据流的组成部分就是相应文件的组成部分.加工(process):描述了输入数据流到输出数据流之间的变换,也就是输入数据流做了什么处理后变成了输出数据流.每个加工有一个名字和一个编号.编号反映了该加工位于分层DFD的哪个层次和哪张图中以及它是哪个加工分解出来的子加工.文件(file):可以表示数据文件,也可以表示一个数据记录.流向文件的数据流表示写文件,流出文件的数据流表示读文件,双向箭头表示对文件既读又写.每个文件都有一个文件名.源/宿(source/sink):源是指系统所需数据的发源地,宿(也称数据池)是指系统所产生的数据的归宿地.无论源或宿,均对应于外部实体,在框内应加注实体的名字,在一个软件各级软件系统中,有些源和宿可以是一个外部实体,外部实体是指存在于软件系统之外的人员或组织,它指出系统所需数据的发源地和系统所产生数据的归宿地.分层数据流图

一套分层的的数据流图由顶层,底层,和中间层组成.画分层数据流图基本原则与注意事项 a.自外向内,自顶向下,逐层细化,完善 求精.b.保持父图与子图的平衡.也就是说,父

图中某加工的输入数据流中的数据必须与它的子图的输入数据流在数量和名字上相同.c.保持数据守恒.也就是说,一个加工所 有输出数据流中的数据必须能从该加工的输入数据流中直接获得,或者是通过该加工能产生的数据.c.加工细节隐藏.根据抽象原则,在画父

图时,只需画出加工和加工之间的关系,而不必画出各个加工内部的细节.d.简化加工间关系.在数据流图中,加工

间的数据流越少,各加工就越相对独立,所以应尽量减少加工间输入输出数据流的数目.e.均匀分解.应该使一个数据流中的各个 加工分解层次大致相同.f.适当地为数据流,加工,文件,源/宿命

名,名字应反映该成分的实际意义,避免空洞的名字.g.忽略枝节.应集中精力于主要的数据流, 而暂不考虑一些例外情况,出错处理等枝节性问题.h.表现的是数据流而不是控制流.i.每个加工必须既有输入数据流,又有输

出数据流.在整套数据流图中,每个文件必须既有读文件的数据流又有写文件的数据流,但在某一张子图中可能只有读没有写或者只有写没有读.小结:一个软件系统,其数据流图往往有多层.如果父图有N个加工(Process),则父图允许有0～N张子图,但是每张子图只能对应一张父图.在一张DFD图中,任意两个加工之间可以有0条或多条名字互不相同的数据流;在画数据流图时,应该注意父图和子图的平衡,即父图中某加工的输入输出数据流必须与其输入输出流在数量和名字上相同.DFD信息流大致可分为两类:交换流和事务流.9.1.2 数据字典

数据字典是关于数据的信息的集合也就是对 数据流图中包含的所有元素的定义的集合.组成部分: a.数据项条目 b.数据流条目 c.文件条目 d.加工条目

加工条目是对数据流图中每一个不能再分 解的基本加工的精确说明.对于加工的描述是数据字典的组成内容之一,常用的加工描述方法有结构化语言,判定树和判定表.9.1.3 结构化语言

结构化语言实际上是一种半形式化语言, 它的结构通常可分为内外两层.外层接近于形式化语言,而内层近似于自然语言的描述.9.1.4 实体——关系图(E—R图)实体——关系图(Entity-Relabionship Diagram),简称E-R图,包含实体,关系和属性等3种基本成分.通常用矩形框代表实体,并用直线把实体(或关系)与其属性连接起来.E-R图通常用于数据库应用系统.9.2 结构化设计

结构化设计通常可分为概要设计和详细设计,但是主要用于概要设计阶段.概要设计的任务是确定软件系统的结构,进行模块划分,确定每个模块的功能,接口以及模块间的调用关系.详细设计的任务是为每个模块设计实现的细节.9.2.1 概要设计

经过需求分析阶段的工作,系统必须“做什么”已经清楚了,概要设计的基本目的就是回答“概括地说,系统应该如实现 ”这个问题.概要设计的重要任务:

将一个复杂的系统按功能化分为模块,确

定每个模块的功能,确定模块之间的调用关系,确定模块之间的接口(模块之间传递的信息),评价模块的结构质量.1.软件结构图形工具

结构化设计方法(SD)方法采用结构图(Structure Chart),层次图和HIPO图描述软件结构.结构图的主要成分有模块,调用和数据,结构图中的模块用矩形表示,在矩形框内可标上模块的名字.模块间如有箭头或直线相连,表明它们之间有调用关系.层次图用来描绘软件的层次结构.层次图中一个矩形框代表一个模块,方框间的连线表示模块间的调用关系.HIPO图实际上就是层次图加输入/处理/输出图.HIPO图是美国IBM公司发明的“层次图加输入/处理/输出图”,是在层次图里出了最顶层的方框之外,每个方框都加了编号.编号规则和数据流图的编号规则一样.2.概要设计中的信息流

变换流:信息沿着输入通道进入系统,然后通过变换中心(也称主加工)处理,再沿着输出通道离开系统.具有这一特性的信息流称为变换流.具有变换流型的数据流图可明显地分成输入,变换(主加工),输出三大部分.事务流:信息流沿着输入通道到达一个事务中心,事务中心根据输入信息(即事务)的类型在若干个动作序列(称为活动流)中选择一个来执行,这种信息流称为事务流.事务流有明显的事务中心,各活动以事务中心为起点呈辐射状流出.9.2.2 详细设计

概要设计已经确定了每个模块的功能和接口,详细设计的任务就是为每个模块设计其实现的细节.详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统,得出对目标系统的精确描述.1.详细设计阶段的内容

为每个模块进行详细的算法设计.为模块内部的数据结构进行设计.对数据库进行物理设计.其他

详细设计工具主要包括程序流程图(系统流程图),盒图(N-S图),PAD图和伪码(PDL).2.人机界面设计

人机界面的设计质量,直接影响用户对软件产品的评价.界面的美观,灵活和风格都很重要,但人机界面设计中最重要的也是最基本的目标是软件的易操作性.人机界面设计主要包括系统响应时间,用户帮助设计,出错信息处理和命令交互设计等几个方面.9.3 Jackson方法

上面讲的结构化设计方法是面向数据流的,另外还有一种面向数据结构的设计方法, Jackson方法是最著名的面向数据结构的设计方法,而不是面向数据流的设计方法.Jackson方法的基本步骤是:建立系统的数据结构;以数据结构为基础,对应地建立程序结构;列出程序中要用到的各种基本操作,再将这些操作分配到程序结构适当的模块中.9.4 面向对象分析方法(00A)OTM方法的三个模型,分别从三个不同侧面描述了所要开发的系统:功能模型指明了系统应该“做什么”;动态模型明确了什么时候做;对象模型则定义了做事情的实体.对象模型描述了系统中对象的静态结构及对象间的联系,用对象模型图来表示.动态模型描述了与时间和操作次序有关的系统属性.动态模型由多张状态图组成.各个类的状态图通过共享事件组成系统的动态模型.功能模型描述系统内数据值的变化,它由数据流图组成.数据流图说明数据流是如何从外部输入,经过操作和内部存储而得到输出的.十.软件工具

软件工具是指用于辅助软件开发,运行,维护,管理,支持等过程中的活动的软件.通常也称为CASE(Computer Aided Software Engineering,计算机辅助软件工程)工具.按软件过程的活动分为软件开发工具,软件维护工具和软件管理工具等.十一.软件开发环境

集成型开发环境通常可由工具集和环境集成机制两部分组成.这种环境应具有开放性和可裁减性.环境集成机制主要有数据集成机制,控制集成机制和界面集成机制.十二.软件质量管理基础知识 12.1 软件质量

ISO/IEC 9126软件质量模型可从软件功能性,可靠性,可用性,效率,可维护性,可移植性6个方面来衡量.(1).功能性

与功能及其指定的性质的一组软件属性.(2)可靠性

软件在规定的一段时间内和规定的条件下保持其性能水平有关的一组软件属性.也可以称为在规定的条件下和规定的时间间隔内,软件实现其规定功能的概率.(3)可用性

与使用的难易程序及规定或隐含用户对使用 方式所做的评价有关的软件属性.(4)效率

与在规定条件的性能水平与所用资源量之间的关系有关的一组软件属性.(5)可维护性

与软件维护的难易程序有关的一组软件属性.(6)可移植性

软件可从某一环境转移到另一环境的能力有关的一组属性.即软件从一个计算机系统转换到另一个计算机系统运行的难易程度是指软件的可移植性.为了提高可移植性,应注意提高软件的设备独立性.采用表格驱动程序有助于提高设备独立性.为了提高可移植性,还应有完备的文档资料.使用C语言开发的系统软件具有较好的可移植性.12.2 软件质量保证

软件质量保证的主要困难表现在以下几个方面: 1)软件开发的管理人员往往关心项目开发的成本与进度.因为成本和进度是显而易见的,而软件质量则难以度量.如果软件开发的管理人员对交付的软件含有多少隐患并不必负什么责任,他们必定没有太高的热情去控制开发的质量,更不必说保证质量并不容易且代价昂贵.开发人员的习惯一旦形成难以改变,他们的形为也难于控制,而高质量的软件产品,又主要取决于参与开发的人员.复杂的软件项目需要许多技术人员和管理人员参与,对问题的不同认识和误解如不能及时消除必然影响软件质量.软件开发人员的频繁流动,特别是骨干开发人员的流失,也会使软件质量受到一定的影响.软件质量的保证手段: 开发初期制定质量保证计划,并在开发中坚持实行.开发前选定或制定开发标准或开发规范,并遵照实施.从开始就选择分析设计方法和工具,形成高质量的分析模型和设计模型.严格执行阶段评审,以便及时发现问题.各个开发阶段的测试.对软件的每次“变动”都要经过申请,评估,批准,实施等步骤.软件质量特性的度量化.软件生存期的各阶段都要完整的文档.12.3 代码评审技术

常用方法有代码走查和代码审查技术.代码走查

程序员和测试员组成审查小组,通过逻辑运行程序.第一步:小组成员提前阅读设计规格书,程序文本等相关文档;第二步:利用测试用例,使程序逻辑运行,记录程序的踪迹,发现,讨论,解决问题 代码审查

程序员和测试员组成审查小组.第一步:小组成员提前阅读设计规格书,程 序文本等相关文档;第二步:召开程序审查会,开发人员读程序,审查小组讨论,发现,解决问题.两者的区别

代码审查是一种正式的评审活动,而代码走 查的讨论过程是非正式的.十三.成本-效益分析可用哪些指标进行度量

投资回收率:通常把建立系统若干年后所取得的收益折算成现在的价值和开发系统所需的费用进行比较得出投资回收率.投资回收期:就是使累计的经济效益等于最初的投资费用所需的时间.纯收入:整个软件生命周期之内的累计经济效益(折成现在值)与投资之差.十四.第四代语言(4GL)的主要特征

友好的用户界面

兼有过程性和非过程性两种特性 高校的程序代码 完备的数据库 应用程序生成器

十五.软件测试

软件测试的费用已经超过软件开发费用的30%左右.“高产”测试是指用少量的测试用例,发现被测试程序尽可能多的错误.15.1 软件测试经过的步骤

单元测试->集成测试->确认测试->系统测试 15.2 测试与软件开发各阶段的关系

单元测试对程序中每一个程序单元进行测试,检查各个模块是否争取实现规定的功能,从而发现模块在编码中或算法中的错误,该阶段涉及编码和详细设计文档.集成测试是为了检查与设计相关的软件体系结构的有关问题,也就是检查概要设计是否合理有效.确认测试主要是检查已实现的软件是否满足需求规格说明书中已确定了的各种需求.系统测试是把已确认的软件与其他系统元素(如硬件,其他支持软件,数据,人工等)结合在一起进行测试,以确定软件是否可以支付使用.15.3 白盒测试

白盒测试又称为结构测试.可以把程序看成装在一个透明盒子里,测试者(一般为编程者)完全知道程序的结构和处理算法.按照程序内部逻辑设计测试用例,检测程序中的主要执行通路是否能按预定要求正常工作.白盒测试多用于单元测试阶段.逻辑覆盖是主要的白盒测试技术.白盒测试时,确定测试数据应根据程序的内部逻辑和指定的覆盖方式.采用一下几种逻辑覆盖标准: 语句覆盖 判定覆盖 条件覆盖

判定/条件覆盖 条件组合覆盖 路径覆盖

满足条件组合覆盖测试用例,也一定满足判定条件覆盖.因此,条件组合覆盖是上述五种覆盖标准中最强的一种.15.4 黑盒测试

黑盒测试,又称为功能测试.把软件看做是一个不透明的黑盒子,完全不考虑(或不了解)软件内部结构和处理算法,它只检测软件功能是否能按照软件需求说明书的要求正常使用,软件是否能适当的接受输入数据并产生正确的输出信息,软件运行过程中能否保持外部信息(例如文件和数据库)的完整性等.常用的黑盒测试技术包括等价类划分,边值分析,错误推测和因果图等.其中等价类划分和边界值分析法方法最常用.如果两者结合使用,更有可能发现软件中的错误.15.4灰盒测试

灰盒测试介于白盒测试和黑盒测试之间,它把软件看做是一个半透明的灰盒子,结合考虑软件的内部结构和外部功能设计测试用例 15.5 回归测试

纠正了程序中的错误之后,选择部分或全部原先已测试过的测试用例,对修改后程序重新测试以验证对软件修改后有没有引出新的错误,称为回归测试.15.6 单元测试

单元测试(Unit testing)也称为模块测试或结构测试,通常可放在编程阶段(实现阶段),主要采用逻辑覆盖技术,由程序员对自己编写的模块自行测试,检查模块是否能实现了详细设计说明书中规定的功能和算法.单元测试主要发现编程和详细设计中产生的错误.测试一个模块时需要为该模块编写一个驱动模块和若干个桩(stub)模块.顶层模块测试时不需要驱动模块,底层模块测试时不需要桩模块.在进行单元测试时,常用的方法是白盒测试(采用逻辑覆盖的测试技术),辅之以黑盒测试.15.7集成测试

集成测试(integration testing)也称为组装测试,在单元测试的基础之上,把所有的模块组装成一个系统进行测试.主要测试设计阶段产生的错误,集成测试计划应该在概要设计阶段制定.非渐增式集成测试

首先将每个模块分别进行单元测试,再把所有的模块组装成一个完整的系统进行测试.目前在进行集成测试时已普遍采用渐增式集成.渐增式集成测试

又可以分为自顶向下集成和自底向上集成.自顶向下集成先测试上层模块,再测试下层模块,由于测试下层模块时上层模块已经测试过,所以不必要另外编写驱动模块.自底向上集成,先测试下层模块,再测试上层模块.顶层模块测试时不需要驱动模块,底层模块测试时不需要桩模块.软件的集成测试最好由不属于该软件开发组的软件设计人员承担,以提高集成测试的效果.三明治测试

从系统的三个角往中间包围测试的方法.15.8 确认测试

在系统验收测试中,验证测试是在模拟的环境中进行强度测试的基础上进行,主要依据软件需求说明书检测软件的功能,性能及其他特征是否与用户的要求一致,而确认测试是在一个实际环境中使用真实数据运行系统.确认测试计划应该在需求分析阶段制定.α测试

由用户在开发者的场所进行,并且在开发者的指导下进行测试.开发者负责纪录发现的错误和使用中遇到的问题,也就是说α测试是在受控的环境中进行的.β测试是在一个或多个用户的现场由该软件的最终用户实施的,开发者通常不在现场,用户负责记录发现的错误和使用中遇到的问题并把这些问题报告给开发者.也就是说,β测试是在受控的环境中进行的.经过确认测试之后的软件通常就可以交付使用了.15.9 系统测试

系统测试是将已经确认的软件,计算机硬件,外设和网络等其他因素结合在一起,进行信息系统的各种组装测试和确认测试,其目的是通过与系统的需求相比较,发现所开发的系统与用户需求不符或矛盾的地方.包括以下的测试: 恢复测试:监测系统的容错能力

安全性测试:监测系统的安全机制,保密措施是否完善等防范能力.强度测试:测试软件的异常情况的处理能力.性能测试:监测系统是否满足系统设计方案说明书对性能的要求.可靠性测试:从平均失效间隔是否超过了规定的时限,因故障而停机的时间在一年中不应超过的时间来进行检测.安装测试:监测软件在安装过程中是否有错误,是否容易操作等.系统测试计划在系统测试阶段初期制定.十六.软件工程标准和软件文档

GB/T8566-2001,GB/T12504-1990,GB/T12505-1990是我国现阶段最重要的三个软件开发规范标准.国家标准局1988年1月批准并发布的《GB/T8567-1988计算机软件产品开发文件编制指南》规定在一项软件开发过程中应该产生14中文件 可行性研究报告 项目开发计划 软件需求说明书 数据要求说明书 概要设计说明书 详细设计说明书 数据库设计说明书 用户手册 操作手册 模块开发卷宗 测试计划 测试分析报告 开发进度月报 项目开发总结报告

软件运行和维护基础知识

管理人员主要使用:项目开发计划,可行性研究报告,模块开发卷宗,开发进度月报,项目开发总结报告.开发人员:项目开发计划,可行性研究报告,软件需求说明书,数据要求说明书,数据库设计说明书,概要设计说明书,详细设计说明书,测试计划,测试分析报告.维护人员:概要设计说明书,详细设计说明书,数据库设计说明书,模块开发卷宗,测试分析报告,维护报告.用户:用户手册,操作手册.十七.软件维护

用于软件维护的花费约为整个软件生命周期花费的75%(或60%～80%之间)而且还在逐年上升.17.1 软件维护类型

根据引起软件维护的原因,软件维护可分为以下四种类型(1)改正性维护

使用过程中发现了隐蔽的错误后,为了诊断和改正这些隐蔽错误而修改软件的活动(2)适应性维护

为了适应环境的变化而修改软件的活动(3)完善性维护

为了扩充或完善原有软件的功能或性能而修改软件的活动.(4)预防性维护

预防性维护是指为了提高软件的可维护性和可靠性,为未来的进一步改进打下基础而修改软件的活动.17.2 软件的可维护性 通常影响软件可维护性的因素有可理解性,可测试性和可修改性.(1)可理解性

可理解性是指维护人员理解软件的结构,接口,功能和内部过程的难易程度.采用良好的编程风格有助于提高软件的易理解性.(2)可测试性

可测试性是指测试和诊断软件错误的难易程度.(3)可修改性

可修改性是指修改软件的难易程度.怎样提高软件的可维护性

在软件生命周期的各个阶段都必须充分考虑维护问题.结构化设计的几条主要原则,如模块化,信息隐藏,高内聚,低耦合等,对于提高软件的可理解性,可测试性和可修改性也都有重要的作用.书写详细正确的文档,书写源文件的内部注解,使用良好的编程语言,具有良好的程序设计风格,也有助于提高软件的可理解性.使用先进的测试工具,保存以前的测试过程和测试用例,则有助于提高软件的可测试性.十八.软件的可靠性

在给定的时间内,在给定的环境条件下系统完成所指定工作的概率.衡量的标准是:平均失效等待时间MTTF 和平均失效间隔时间MTBF.

第五篇：软件工程课程总结

软件工程课程总结

学习软件工程这门课程已经有一个学期了，整整一个学期下来，应该说还是有许多值得肯定的地方的。其实在我看来，软件工程与其说是一门课程，不如说是一门思想，是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的能够解决问题的思想集合。

学习软件工程能够加强人的整体思维能力，对人的综合素质有所提高，培养良好的分析规划和团队意识。学习了软件工程，我们可以在给定成本、进度的前提下，开发出具有适用性、有效性、可修改性、可靠性、可理解性、可维护性、可重用性、可移植性、可追踪性、可互操作性和满足用户需求的软件产品。追求这些目标有助于提高软件产品的质量和开发效率，减少维护的困难。

在这学期的软件工程课上，我每次都认真听老师讲课，跟着老师的脚步，领悟老师的思想，学习态度还算认真。一刚开始还觉得这门课有点枯燥乏味，但后来静下心来看这本书感觉书上的知识对以后无论是在生活、学习还是在工作上都有很大的好处，对自身也是一种完善，因为这里面的思想博大精深，值得学习。从此我就认真地学习这门课程。尽管在学习的过程中遇到了很多困难，但经过与老师和同学的积极交流终于把问题解决了，从中学到了更深层次的知识，而这些知识又是对书本知识的补充，对学习书本知识有很大的好处。当然，学习理论知识就是用来指导实践的，也只有把理论知识运用到实践才能充分发挥理论的作用。所以在业余时间，我们尝试着把所有知识串起来，并根据自身的实践经验完成了相关的系统分析报告，让知识能更加驻留我心。

在本学期的软件工程课程的学习中，我们学习了十章的内容。第一章软件工程概述，这一章主要讲解的是一些概念性和基础性的内容，例如软件的概念、特性，软件危机的主要表现。了解软件工程的的工作对象、发展背景、内容、目标。还介绍了三个常用的软件工具Microsoft Visio、PowerDesigner和Rational Rose。第二章软件开发过程模式，这一章主要让我们了解软件生存周期，认识到了软件开发过程，熟悉了几种常用的软件过程模式的特点与用途。此章介绍了6种模式：瀑布模式、原型进化模式、增量模式、螺旋模式、迭代模式和组件复用模式。第三章软件项目管理，本章详细介绍了项目管理内容（对项目的管理、对项目成果的管理），让我们学会如何制定项目计划，并学习使用甘特图、任务网络图（由Microsoft Project创建）制定项目计划。第四章计算机系统工程，这一章让我们熟悉如何从全局的计算机系统角度考察软件问题，熟悉如何对软件项目做可行性分析。该章还涉及系统初步建模，其中的系统框架图、系统流程图，可由Microsoft Visio中的基本流程图创建。第五需求分析，这一章重点讲解了需求分析任务及过程，让我们学会如何获取业务需求、建立业务模型、进行需求验证。可通过Microsoft Visio中的组织图创建业务树，通过Rational Rose创建业务用例、业务活动。第六章结构化分析建模，这一章重点讲解了使用变换型映射方法和事务型映射方法生成初始的模块结构以及模块结构的改进。说明了建立分析建模的原因和方法。我们可通过PowerDesigner创建实体联系图，通过Microsoft Visio创建数据流图，通过Rational Rose创建事件状态图。第七章基于UML的面向对象分析建模，本章详细介绍了UML的基本模式、事物、关系及建模时用到的各种图进行了介绍。可通过Rational Rose进行面向对象分析建模。第八章概要设计，这一章主要讲解了概要设计任务及过程，介绍了系统构架、数据结构、程序结构等概要设计内容。第九章结构化设计建模，本章介绍了结构化设计建模的工具，让我们学会如何基于数据流进行程序结构映射和如何对程序结构进行优化。该章中的程序结构图由Microsoft Visio创建。第十章基于UML的面向对象设计建模，本章讲解了面向对象设计建模内容，让我们学习使用UML建立面向对象设计模型（逻辑结构、动态过程、物理装配与部署）。通过Rational Rose进行设计建模。

学习了这门课程之后，我发现无论是在上课，还是在学校里面做学生工作，技术性的工作就好比变魔术。其实原理是非常简单的，甚至可以说简单的可笑，但是当你就是做出这么一个简单的东西出来之后，一些外行们有时候会用崇拜的眼光看着你，觉得你很厉害，很高深莫测。但是制作的过程他们却不知道，也许知道之后他们只是会哑然失笑，原来这个东西的制作过程是如此的简单，这个可以说就是技术的魅力了。就比如说软件工程中所谓的需求获取，从字面上来看好像是一件很难的事，而其实就是一个谈判，辩论，交流的过程，只不过这个交流过程可能针对性比较强。所以说软件工程就是对生活的平凡小事的升华，它来自于生活却高于生活。当我们在毕业之后，软件工程是我们实际要运用的一项非常有用的技能，而且不仅仅局限于软件工程的范畴，即使我们是从事其它行业，不也是要从需求获取开始，一直有条有理地到最后成品的出炉吗？应该说这就是这门课的价值所在，它让我们既学会了管理又学会了技术。

在整个学期的学习过程中，我收获了不少，能够解决一些较为简单的问题，在建模方面的能力有所加强。原来一直以为学好这门课程最重要的是会编写程序，其实则不然。我了解到软件并非是一些代码这么简单，在开发软件的过程中，编写代码的工作量其实只占不到所有工程量的30%，而后期的管理和维护更是占了60%到80%之多。一个完整的项目规划须包括：软件的定义、可行性分析报告、项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、用户操作手册、测试计划、测试分析报告、开发进度报告、项目开发总结报告、软件维护手册、软件问题报告、软件修改报告等多个文档，每个文档都要上级验收审查，而文档数量众多，要做好这点真的不是很容易，而恰恰写好文档正能保证完成软件工程其中一个目的的关键，既研究如何用最小的开销做出生存期较长的软件，再加上各个阶段都要进行周密的策划、详细的分工部署和人员安排，且各阶段要据具体情况不断的反复才能达成，所以代码只是开发软件这个浩大的工程的一个小小的过程。当然自己也有很多的不足之处，比如自己动手操作能力比较弱，实践经验匮乏，思维不紧密，不注重细节，耐心不够，每次遇到问题就去问老师，实战精神不强，所以导致很多知识学得也只是模模糊糊的。所以在以后的学习中我要加强自身综合素质的培养，要注意多看多练要注意结合实际，更要多思考，面对错误不要一范就问，要尝试自己去解决，这样才能学到这门课程的精华。我觉得学好软件工程首先要明白自己的学习目标究竟是什么，根据自己的实际工作出发，有针对性地在相应的学习方向上进行提高，制定出详细的学习规划。还要注意与其他科目的相辅相成，就像我们在学习语言时，要看看与C语言的联系，多思多想，把从各个科目学到的知识融汇贯通。

在本学期我们班每位同学都做了管理信息系统分析报告，其中就用到了软件工程中的不少知识。比如项目来源，项目任务，项目规划，系统需求分析，系统结构设计，系统详细设计，系统测试，系统维护等等。而我做的是酒店客房管理信息系统的分析报告，其中涉及到了以上几个方面，需要明确任务目标，准备相应的项目资源，对项目实施合理的规划，进行业务需求和功能需求分析，制定出数据字典，设计出软件结构，并对其进行详细设计，比如算法设计，数据库设计和界面设计。画出进度安排表，组织结构图，业务流程图，数据流图，利用UML建模画出图形，通过这些图形能更直观地看出各个实体之间的关系，对系统有个比较整体的体现。

总之，在今后的学习中要注意多读书、多思考、多练习、多讨论，不断熟悉书本的基础，并以此为基础将其扩散开来，应用于今后的实践。不断锻炼自己，成为社会的可用之才，回馈社会。