软件工程思想

缺乏、安全感 2022-05-27 11:50 162阅读 0赞

# 1 软件工程的基本观念 #

## 1.1 软件工程的主要环节 ##

![20180418094902193][]

# 1.2 软件工程基本观念 #

### 1.2.1 复用 ###

复用就是指“利用现成的东西”，但它不是简单的“拿来主义”，我们经常说“站在巨人的肩膀上”大概就是这个道理。

复用的内涵包括提高质量和生产率两者。有经验可知，在一个新系统中，大部分的内容是成熟的，只有一小部分内容是创新的。一般的可以相信成熟的东西总是比较可靠的（即具有高质量），二大量成熟的工作可以通过复用来快速实现（即具有高生产率）。我们要做一个勤劳而且聪明的人。

我们将具有一定集成度并可以重复使用的软件组成单元称为软构件。软构件复用可以表述为：构造新的软件系统可以不必每次从零做起，直接使用自己已有的软构件，即可组装（或加以合理修改）成新的系统。软件复用不仅要是自己拿来方便，还要让别人拿走方便，也就是“拿去主义”，米老师也经常说“教是最好的学”，有异曲同工之妙。

软构件生产应用软件的过程

![20180418103237459][]

### 1.2.2 分而治之 ###

分而治之是指把一个复杂的问题分解成若干个简单的问题，然后逐个解决。软件人员分而治之的时候，应该着重考虑：复杂问题分解后，每个问题能否用程序实现：所有程序最终能否集成为一个软件系统并有效解决原始的复杂问题？诸如：软件的体系结构设计、模块化设计都是分而治之的具体表现。

![20180418105609652][]

### 1.2.3 优化——折衷 ###

软件中的折衷策略是指通过协调各个质量因素，实现整体质量的最优。就像党支部副书记扮演和事佬的角色：“为了使整个组织具有最好的战斗力，我们要重要几个人，照顾一些人，在万不得已的情况下委屈一批人”。但是我们折衷不能一碰到困难，就用拆东墙补西墙的方式折衷，我们要有严正的立场：在保证其他因素不差的前提下，使某些因素变得更好。

## 1.3 一些不正确的观念 ##

观念之一：我们拥有一套讲述如何开发软件的书籍，书中充满了标准与实例，可以帮助我们解决软件开发中遇到的任何问题。

观念之二：我们拥有最好的开发工具、最好的计算机，一定能做出优秀的软件。

观念之三：入股我们落后于计划，可以增加更多的程序员来解决。

观念之四：既然需求分析很困难，不管三七二十一先把软件做了再说，反正软件是灵活的，随时可以修改。

观念一二三我不想多说，我只想说一下我走过的大坑观念之四，做机房收费系统的时候，我没有进行需求分析，直接就进行程序设计了，中间有好几次做不下去了，耽误了不少的时间。所以，对需求把握的越准确，软件的修修补补就越少。有些需求在一开始是很难确定，在开发过程中要不断的 加以改正。软件修改越早代价越少，修改越晚代价越大，就跟治病一样的道理。

## 1.4 一些有争议的观念 ##

争议之一：如果软件运行较慢，是换一台更快的计算机，还是设计一种更快的算法？

争议之二：有最好的软件工程方法，最好的编程语言吗？

争议之三：编程时知否该多使用技巧？

就软件开发而言，技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不能为人熟知。若在程序中用太多的技巧，可能会留下隐患，别人也难以理解程序。鉴于一个局部的优点对整个系统而言是微不足道的，而一个错误可能是致命的。作者建议用自然的方式编程，少用技巧。

争议之四：软件中的错误是否可按严重程度分等级？

在定量分析时，可以将错误分为等级，以便于管理。微软的一些开发小组将错误分成四个等级：一级严重：错误导致软件崩溃；二级严重：错误导致一个特性不能运行并且没有替代的方案；三级严重：错误导致一个特性不能运行但有替代的方案；四级严重：错误是表面化的或是微小的。

# 2 项目计划与质量管理 #

## 2.1 项目计划 ##

### 2.1.1 知己知彼 ###

首先要了解项目的规模、难度与实践限制，才可以确定应该投入多少人力、物力去做这个项目。在可行性分析阶段就要考虑这个问题。但不幸的是，人们在陷入项目不能自拔之前总难以准确地估计项目的规模与难度。这里经验起到了最重要的作用。

项目的时间限制有两类。第一类，项目应该完成的日期写在合同中，如果延期了，则开发方要做出相应的赔偿。第二类是开发自己的软件产品，虽然只确定了该产品大致的发行日期并允许有延误，但如果拖延太久则会失去商机造成损失。

项目的资源分为三类：“人”、“可复用的软件构件”和“软硬件环境”

（1）人是最有价值的资源。项目计划的制定者要确定开发人员的名单，要根据他们的专长进行分工 。（2）可复用的软构件是次有价值的资源。复用软构件可提高软件的质量与生产率。软构件并非一定要用自己的，可以向专业的软件供应商购买。（3）软硬件环境虽然不是最重要的资源，却是必需的资源。原则上软硬件环境只要符合项目的开发要求即可。有些项目可能要用到特殊的设备，则要事先做好准备，以免用时找不到二耽搁了进程。

![20180419201713227][]

### 2.1.2进度安排 ###

有些事件经常会导致项目被延误

（1）上级领导主观臆断，制定了不现实的期限。项目经理与程序员按照不合理的进度表开展工作。

（2）客户的需求发生了变化，但没有对进度表做出相应的修改。

（3）低估了项目的规模与难度，导致投入的人力和物力不足。

（4）并未预见到存在难以克服的技术障碍。

（5）并未预见到开发人员会发生问题，如生病，辞职等等。

（6）开发人员之间不能很好的交流、协作，导致各阶段任务难以如期完成。

真对以上原因，有如下建议：

（1）制定进度表的人最好是项目负责人，他最了解项目和开发人员。进度表要经过开发小组的讨论，在得到大部分人的支持后才能实施。避免出现一厢情愿的局面。

（2）进度安排并不见得一定要符合逻辑顺序。应尽可能地先做技术难度好的事，后做难度低的事。也就是辛苦在前，轻松在后。

（3）开发一个大的软件项目，应该将进度分为若干个里程碑。一个里程碑之内的多个任务可以同步进行。程序员极容易沉迷于技术，要么乐不思蜀，要么焦头烂额。里程碑就像心灵的灯塔，使忙碌的人群不混乱，不迷失方向。

（4）进度中必须留有缓冲时间，并将缓冲时间用到不确定的事情上

（5）如果发现项目应交付的期限非常不合理，就要跟领导或客户据理力争，请求放款期限、调整进度。

## 2.2 零缺陷质量管理的观念 ##

### 2.2.1 高目标 ###

人在做一件事情时，由于存在很多不确定的因素，一般不可能100%地达到目标。假设平常人做事能完成目标的80%。如果某个人的目标是100分，那么他最终成绩可达80分。如果某个人的目标60分，那么他人在做一件事情时，由于存在很多不确定的因素，一般不可能 100% 地达到目标。假 设平常人做事能完成目标的 80%。如果某个人的目标是 100 分，那么他最终成绩可达 80 分。如果某个人的目标只是 60 分，那么他最终成绩只有 48 分。我们在考场上身经百战，很清楚 那些只想混及格的学生通常都不会及格，那些想得高分的学生也常为自己的失误而捶胸顿 足。

做一个项目通常需要多个人的协作。假设项目的总质量（最高为 1）是十个开发人员的 工作质量之积。如果每个人的质量目标是 0.95，那么十个人的累积质量不会超过 0.19。如果 每个人的质量目标是 0.9 分，那么十个人的累积质量不会超过 0.03。只有每个人都做到 1，项目总质量才会是 1。

如果没有高目标，人的堕落就很快。如果没有“零缺陷”的质量目标，也许缺陷就会成 堆。

### 2.2.2可执行的规范 ###

软件是如此的灵活，如果没有规范来制约，就容易因无序的喜好而导致混沌；但规范如 果太严密了，就会扼杀程序员生机勃勃的创造力。制定软件规范是进退两难的事。程序员必 须深入了解软件多方面的质量因素，把那些能提高软件质量因素的各种规范植入脑中，才能 在各个实践环节自然而然地把高质量设计到软件中。

关于软件工程的思想还在每个阶段还有很多，例如软件的质量因素：正确性与精确性，性能与效率，易用性，可理解性与简洁性  ，可复用性和可扩充性等，这些都需要我们在日后的学习和工作中慢慢体会和总结，任重而道远，加油。

[20180418094902193]: /images/20220527/2f83565e242a4f77ada585f8b7729329.png
[20180418103237459]: /images/20220527/5fc87c9586cd4aa281dc1baca4c175fb.png
[20180418105609652]: /images/20220527/bcc512258a294ddc97fd91dcdd1430a3.png
[20180419201713227]: /images/20220527/dd645124de42480086387b7761dde3c9.png