软件工程作业

软件工程的学习心得。

一：什么是软件工程。

软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。在现代社会中，软件应用于多个方面。

典型的软件比如有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，比如工业、农业、银行、航空、**部门等。这些应用促进了经济和社会的发展，使得人们的工作更加高效，同时提高了生活质量。

软件工程师是从事软件开发相关工作的人员的统称。它是一个广义的概念，包括软件设计人员、软件架构人员、软件工程管理人员、程序员等一系列岗位，工作内容都与软件开发生产相关。软件工程师的技术要求是比较全面的，除了最基础的编程语言（c语言/c++/j**a等）、数据库技术（sql/oracle/db2等）等，还有诸多如j**a script、ajax、hibernate、spring等前沿技术。

此外，关于网络工程和软件测试的其他技术也要有所涉猎。

软件工程的由来。

二：软件工程的由来。

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

但事过境迁，就像任何人都不会嫌钱多一样，永远都不会有人嫌cpu快的。于是，随之而来的就是硬件的迅猛发展和越来越**的软件。记得以前常去同学家拷游戏，通常几张软盘就可以搞定，而现在的游戏，两三张cd-rom都算少的了。

像如此庞大复杂的怪物，就算你是如何的天才，一个人肯定是搞不定的，否则，等你把程式写出来，人家intel连奔腾n都开发出来了。既要开发大型的软件还要追求速度（这样才能赚钱），于是很自然地，合作的概念被提了出来。

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

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

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

最初提出问题的是dijkstra。他于2024年写给acm的一封题为goto statement considered harmful的信中，指出了goto语句的负面作用，并提出了解决之道，其引发的一系列效应最终带来了软件工程的诞生。

三：软件工程的核心。

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

但对于这些工作，具体怎样做，什么时候做，每个人都有自己的一套方式，甚至有的人有几套方式。这样，当几个人合在一起干活的时候，最终的结果就只能是一片混乱。所以就需要一套规则，大家都按规则来办事，问题就会少得多。

好的规则就叫做规范，规范都是由一些master们根据经验总结的，又经过长时间的历练，不断地被补充修正，可以说都是精华，按照规范来干活，对于提高软件质量和工作效率自然大有帮助。

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

简单来说，就是对于总体的组织和对于局部的实现。

规范只是提供一个好的例子，以描述一种思想，具体到每一个环节怎样实现，对于不同的公司或团体则是各有千秋，因为根本就不可能存在一套放之天下皆可行的标准。就像c++，也只是提供了一套标准，不同的编译器都有各自的实现，对标准的支持程度也互不相同。所以，在不同的公司或团体中，尽管核心思想都是大同小异，但具体到每一个步骤，往往都是不相同的。

我手上就有一份gb8567-88的文档模板，对于那些顶多只有几千行的小程序来说，假如真按上面的要求全写上了，简直就是一种折磨！据说，当前业界最权威的标准是cmm。

四：软件开发过程的实现。

具体到每一步的工作要怎样完成，我前面已提到过，是非常灵活的，只要把握住大体的方向就行。在进行分析，设计，编码，调试，维护这几部分的工作的时候，最核心的就是文档的编写。文档的作用在于以下3个方面：

一是可以帮助整理思路。把要完成的目标，系统的结构，每一个模块的功能等整理一下，然后分门别类地写下来，这样在开发的过程中，就有据可依，在需要回过头来修改设计的时候，也有证可考。二是便于交流。

想象一下开会时的情形。一大帮子人争先恐后，激烈辩论，然后会终人散，思想灵感也就随之散了，结果是开了半天会，什么也没讨论出来。这就是后来会议记录被发明出来的原因。

在脑子里的东西一多，就会散而且乱，用语言表达的时候，很容易会丢三落四，别人也很难把握住你的思想。但经过整理写在纸上以后，则会清晰得多，无论是别人还是自己，看起来都可以一目了然。三是可以作为以后维护时的参考资料。

有一句名言：“笔和纸永远都比大脑可靠”，意思就是说，放在大脑里的东西说不准哪天就忘了，但写在纸上的东西，只要不发生什么意外，一般是丢不了的。当过了一段时间，你需要再回过头来修改你的程序的时候，你就会发现，你以前写下的文档实在太有价值了。

别指望你的源**，对于复杂一点的程序来说，单纯的源**几乎会扼杀掉你所有的时间。

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

以下就是我自己的一份文档模板的概要，麻雀虽小，但五脏俱全。

1.可行性分析。

就是关于当前项目能不能干的分析结果。主要考虑的方面包括：是否能把这个项目开发出来；假如可以的话，预计需要多少时间，能否满足客人的时间要求；需要多少人力和资金的投入；最重要的是，这个项目能否赚钱，能赚多少。

还要对可能存在的风险进行评估，例如，万一项目主管被车撞了要怎么办。当然，这对于我来说毫无意义，我在这里写上只是为了保持完整而已。

2.项目描述。

这是在决定立项以后，对当前项目的一份扼要说明。必须包括以下几个方面：（1）项目的名称或编号；（2）对客户方的描述；（3）对开发人员的描述；（4）工程任务的描述；（5）工程的输入和输出；（6）开发环境；（7）其他的附加条件。

在这里，对工程任务的描述是从整体的角度来说的，例如：能对当前的象棋棋局进行分析并作出最优决策的人工智能系统。而工程的输入输出则可以这样写：

输入当前的象棋棋局的数据描述；输出最优的棋步，包括选择行动的棋子和步法。

3.需求分析。

就是对客户要求的功能的定义。注意这里用了“定义”这个词，这就意味着对客户需求的说明，尽管不一定要是形式定义，但也必须是精确，无歧义的。同时，还要列出程序的功能模块和逻辑流程，。

注意这里所说的功能模块与编码时所说的程序模块的区别。对于客户的一个复杂的功能要求，一般可以用分治法分为一个或多个子功能，每一个子功能对应一个功能模块，而每一个功能模块则可以由一个或多个程序模块来实现。功能模块是建立在设计逻辑上的，而程序模块则是直接面向实现的。

在用oo编程的时候，我通常以类作为程序模块划分的基本单元。综上所述，这个部分的文档必须包括3个部分：（1）客户需求的详细描述；（2）程序功能模块的划分以及其与客户需求的对应关系；（3）功能模块的逻辑流程。

4.软件设计。

这就是对程序的每一个模块的详细设计的说明文档。其由以下几部分组成：（1）程序模块与功能模块的对应关系和相关描述；（2）实现每个功能模块的程序模块的逻辑流程和组织结构；（3）对每一个程序模块的详细描述。

这个部分的文档是改动得最多的，如果与螺旋周期模型结合，甚至需要循环地对每一个模块进行深入设计和细化，所以，为了便于管理，我通常都对每一个较复杂的模块都单独立一份文档。至于模块的流程图或结构图，一直都是我最头疼的问题，那一大堆琳琅满目的画法和符号往往令人无所适从。其实对于个人来说，只要能把意思表达出来，想怎样画都无所谓，关键是自己要有一套标准，别在这个图中，矩形表示过程，而在另一个图中，则是表示i/o。

对每个符号表示的意思进行说明那是必须的，不然别人看起来会一头雾水。假如嫌麻烦的话，就干脆使用那些被大多数人认可的标准，例如uml图。但以后如果进到公司，还是老老实实地按公司规矩办事吧。

5.开发日志。

我一直都认为这是文档中最有趣的部分。开发日志相当于编码阶段的文档，它的形式可以很随意，主要是记录一些在写程序时突然萌发的灵感，或对**的一些微小的修改，或对程序结构的一些微小变动等，还要对上述这些修改变动作些说明，例如，为什么要改成现在的这个样子。别小看这些记录，它往往会成为你以后对程序进行维护时的重要依据。

要知道，人的iq，eq等，是会随着人的生理和心理状态的不同而变化的。在某个时刻，你可能会灵光一闪，做出了一个非常伟大的改动，但过了一段时间，当你再回过头来重新阅读同一段**的时候，你很有可能只记得在这里的改动是非常明智的，可是却无论如何也想不起其明智在**。这时，一份日志就会省却你不少的麻烦。

6.测试分析。

用于指出程序存在或潜在的缺陷和错误，以及程序性能的数字描述。其包括几个部分：（1）对被测模块的描述；（2）测试人员；（3）对该模块每个功能的测试的详细描述；（4）指出当前存在或潜在的问题。

在测试描述中应该包括输入的数据集和输出的结果，还有运行的时间等。对于公司来说，对测试分析的要求是非常严格的。但对于我个人来说，我只是将其作为一份模块测试的文字记录，以防会忽略掉某些已知的缺陷和错误，以及对一些核心模块的时间和空间效率进行简单的测试，以便日后翻查。

四：软件工程目标。

生产具有正确性，可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现以及文档为用户可用程度。

开销合宜是指软件开发、运行的整个开销满足客户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型以及工程方法选取的约束。

软件工程活动是“生产一个最终满足需求且达到工程目标的软件产品所需要的步骤”。主要包括需求、设计、实现、确认以及支持等活动。需求活动包括问题分析和需求分析。

问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。

概要设计建立整个软件体系结构，包括子系统、模块以及相关层次的说明、每一模块接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序**。

确认活动贯穿整个开发过程，实现完成后的确认，保证最终产品满足用户的需求。支持活动包括修改和完善。伴随以上活动，还有管理过程、支持过程、培训过程等。

软件工程作业

软件工程作业

软件工程作业

软件工程作业

其他用户还读了