麦克斯甜点屋
范文一：软件工程思想—软件工程基本观念
软件工程基本观念
本章讲述软件工程的基本观念，是关于软件工程宏观上的探讨。如果你是软件公司的老板，用不着在第一线工作，那么看这一章就够了。但你一定要让员工们相信不停地工作是人生最大的快乐，并且让他们把本书看完。
1.1节讲述软件工程的目标和常用的软件工程模型。1.2节讲述软件开发的基本策略：“复用”、“分而治之”、“优化——折衷”，有助于指导实践者选择方法和产生新方法。1.3节例举一些不正确的观念，取材于早期软件人员比较幼稚的想法，初学者可以引以为戒。
1.4节探讨一些有争议的观念。
看完本章，要树立这样的信念：软件开发过程中的坎坎坷坷，仿佛只是人脸的凹凸不平，用热水毛巾一把就可抹平。让我们高举程序主义、软件工程思想的伟大旗帜，紧密团结在以Microsoft为核心的软件公司周围，沿着比尔·盖茨的生财之道，不分白天黑夜地编程，把建设有中国特色的软件产业的伟大事业全面推向21世纪。
1.1 软件工程的目标与常用模型
软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。质量是软件需求方最关心的问题，用户即使不图物美价廉，也要求个货真价实。生产率是软件供应方最关心的问题，老板和员工都想用更少的时间挣更多的钱。质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提。如果质量不合格，对供需双方都是坏事情。从短期效益看，追求高质量会延长软件开发时间并且增大费用，似乎降低了生产率。从长期效益看，高质量将保证软件开发的全过程更加规范流畅，大大降低了软件的维护代价，实质上是提高了生产率，同时可获得很好的信誉。质量与生产率之间不存在根本的对立，好的软件工程方法可以同时提高质量与生产率。
软件供需双方的代表能在餐桌上谈笑风生，归功于第一线开发人员的辛勤工作。质量与生产率的提高就指望程序员与程序经理。对开发人员而言，如果非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二。这是因为：（1）质量直接体现在软件的每段程序中，高质量自然是开发人员的技术追求，也是职业道德的要求。（2）高质量对所有的用户都有价值，而高生产率只对开发方有意义。（3）如果一开始就追求高生产率，容易使人急功近利，留下隐患。宁可进度慢些，也要保证每个环节的质量，以图长远利益。
软件的质量因素很多，如正确性，性能、可靠性、容错性、易用性、灵活性、可扩充性、可理解性、可维护性等等。有些因素相互重叠，有些则相抵触，真要提高质量可不容易啊！
软件工程的主要环节有：人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试、维护等，如图1.1所示。
图1.1 软件工程的主要环节
软件工程模型建议用一定的流程将各个环节连接起来，并可用规范的方式操作全过程，如同工厂的生产线。常见的软件工程模型有：线性模型（图1.2），渐增式模型（图
1.3），螺旋模型，快速原型模型，形式化描述模型等等 [Pressmam 1999, Sommerville 1992]。
图1.2 软件工程的线性模型
图1.3 软件工程的渐增式模型
最早出现的软件工程模型是线性模型（又称瀑布模型）。线性模型太理想化，太单纯，已不再适合现代的软件开发模式，几乎被业界抛弃。偶而被人提起，都属于被贬对象，未被留一丝惋惜。但我们应该认识到，“线性”是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的“非线性”问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就
是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如渐增式模型实质就是分段的线性模型，如图1.3所示。螺旋模型则是接连的弯曲了的线性模型。在其它模型中都能够找到线性模型的影子。
套用固定的模型不是程序员的聪明之举。比如“程序设计”与“测试”之间的关系，习惯上总以为程序设计在先，测试在后，如图1.4（a）所示。而对于一些复杂的程序，将测试分为同步测试与总测试更有效，如图1.4（b）所示。
（a） （b）
图1.4 （a）程序设计在先测试在后 （b）测试分为同步测试与总测试
不论是什么软件工程模型，总是少不了图1.1中的各个环节。本书擗开具体的软件工程模型，顺序讲述人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试，以及维护与再生工程。其中程序设计部分以C++/C语言为例。
1.2 软件开发的基本策略
人们都有自己的世界观和方法论，能自然而然地运用于生活和工作中。同样，程序员脑子里的软件工程观念会无形地支配其怎么去做事情。软件工程三十年的发展，已经积累了相当多的方法，但这些方法不是严密的理论。实践人员不应该教条地套用方法，更重要的是学会“选择合适的方法”和“产生新方法”。有谋略才会有好的战术。几千年前，我们的祖先就在打闹之际写下了很多心得体会，被现代人很好地运用于工业和商业。本节讲述软件开发中的三种基本策略：“复用”、“分而治之”、“优化——折衷”。
1.2.1 复用
复用就是指“利用现成的东西”，文人称之为“拿来主义”。被复用的对象可以是有形的物体，也可以是无形的成果。复用不是人类懒惰的表现而是智慧的表现。因为人类总是在继承了前人的成果，不断加以利用、改进或创新后才会进步。所以当我们欢度国庆时，要搞清楚祖国远不止50岁，我们今天享用到的财富还有上下五千年人民的贡献。进步只是应该的，不进步则就可耻了。
复用的内涵包括了提高质量与生产率两者。由经验可知，在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具有高质量），而大量成熟的工作可以通过复用来快速实现（即具有高生产率）。勤劳并且聪明的人们应该把大部分的时间用在小比例的创新工作上，而把小部分的时间用在大比例的成熟工作中，这样才能把工作做得又快又好。
把复用的思想用于软件开发，称为软件复用。据统计，世上已有1000亿多行程序，
无数功能被重写了成千上万次，真是浪费哪。面向对象（Object Oriented）学者的口头禅就是“请不要再发明相同的车轮子了” 。
将具有一定集成度并可以重复使用的软件组成单元称为软构件(Software Component)。软件复用可以表述为：构造新的软件系统可以不必每次从零做起，直接使用已有的软构件，即可组装（或加以合理修改）成新的系统。复用方法合理化并简化了软件开发过程，减少了总的开发工作量与维护代价，既降低了软件的成本又提高了生产率。另一方面，由于软构件是经过反复使用验证的，自身具有较高的质量。因此由软构件组成的新系统也具有较高的质量。利用软构件生产应用软件的过程如图1.5所示。
软件复用不仅要使自己拿来方便，还要让别人拿去方便，是“拿来拿去主义”。面向对象方法，Microsoft公司的COM规范 [Rogerson 1999]，都能很好地用于实现大规模的软件复用。
构件不存在
图1.5 利用软构件生产应用软件的过程
1.2.2 分而治之
分而治之是指把一个复杂的问题分解成若干个简单的问题，然后逐个解决。这种朴素的思想来源于人们生活与工作的经验，完全适合于技术领域。软件人员在执行分而治之的时候，应该着重考虑：复杂问题分解后，每个问题能否用程序实现？所有程序最终能否集成为一个软件系统并有效解决原始的复杂问题？
图1.6 软件领域的分而治之策略
图1.6表示了软件领域的分而治之策略。诸如软件的体系结构设计、模块化设计都是分而治之的具体表现。软件的分而治之不可以“硬分硬治”。不像为了吃一个西瓜或是
一只鸡，挥刀斩成n块，再把每块塞进嘴里粉碎搅拌，然后交由胃肠来消化吸收，象征复杂问题的西瓜或是鸡也就此消失了。
1.2.3 优化——折衷
软件的优化是指优化软件的各个质量因素，如提高运行速度，提高对内存资源的利用率，使用户界面更加友好，使三维图形的真实感更强等等。想做好优化工作，首先要让开发人员都有正确的认识：优化工作不是可有可无的事情，而是必须要做的事情。当优化工作成为一种责任时，程序员才会不断改进软件中的算法，数据结构和程序组织，从而提高软件质量。
著名的3D游戏软件Quake，能够在PC机上实时地绘制高度真实感的复杂场景。Quake的开发者能把很多成熟的图形技术发挥到极致，例如把Bresenham画线、多边形裁剪、树遍历等算法的速度提高近一个数量级。我第一次看到Quake时不仅感到震动，而且深受打击。这个PC游戏软件的技术水平已经远胜于我所见识到的国内领先的图形学相关科研成果。这对我们日益盛行的点到完止的研发工作真是莫大的讽刺。所以当我们开发的软件表现出很多不可救药的病症时，不要怨机器差。真的是我们自己没有把工作做好，写不好字却嫌笔钝。
就假设我们经过思想教育后，精神抖擞，随时准备为优化工作干上六天七夜。但愿意做并不意味着就能把事情做好。优化工作的复杂之处是很多目标存在千丝万缕的关系，可谓数不清理还乱。当不能够使所有的目标都得到优化时，就需要“折衷”策略。
软件中的折衷策略是指通过协调各个质量因素，实现整体质量的最优。就象党支部副书记扮演和事佬的角色：“…为了使整个组织具有最好的战斗力，我们要重用几个人，照顾一些人，在万不得已的情况下委屈一批人”。
软件折衷的重要原则是不能使某一方损失关键的职能，更不可以象“舍鱼而取熊掌”那样抛弃一方。例如3D动画软件的瓶颈通常是速度，但如果为了提高速度而在程序中取消光照明计算，那么场景就会丧失真实感，3D动画也就不再有意义了（如果人类全是色盲，计算机图形学将变得异常简单）。
人都有惰性，如果允许滥用折衷的话，那么一当碰到困难，人们就会用拆东墙补西墙的方式去折衷，不再下苦功去做有意义的优化。所以我们有必要为折衷制定严正的立场：在保证其它因素不差的前提下，使某些因素变得更好。
下面让我们用“优化——折衷”的策略解决“鱼和熊掌不可得兼”的难题。
问题提出：假设鱼每千克10元，熊掌每千克一万元。有个倔脾气的人只有20元钱，非得要吃上一公斤美妙的“熊掌烧鱼”，怎么办？
解决方案：化9元9角9分钱买999克鱼肉，化10元钱买1克熊掌肉，可做一道“熊掌戏鱼”菜。剩下的那一分钱还可建立奖励基金。
1.3 一些不正确的观念
本节例举并分析一些不正确的软件工程观念，可帮助初学者少犯相似的错误。
观念之一：我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。
客观情况：好的参考书无疑能指导我们的工作。充分利用书籍中的方法、技术和技巧，可以有效地解决软件开发中大量常见的问题。但实践者并不能因此依赖于书籍，这是因为：（1）现实的工作中，由于条件千差万别，即使是相当成熟的软件工程规范，常常也无法套用。（2）软件技术日新月异，没有哪一种软件标准能长盛不衰。祖传秘方在某些领域很吃香，而在软件领域则意味着落后。
观念之二：我们拥有最好的开发工具、最好的计算机，一定能做出优秀的软件。
客观情况：良好的开发环境只是产出成果的必要条件，而不是充分条件。如果拥有好环境的是一群庸人，难保他们不干出南辕北辙的事情。
观念之三：如果我们落后于计划，可以增加更多的程序员来解决。
客观情况：软件开发不同于传统的农业生产，人多不见得力量大。如果给落后于计划的项目增添新手，可能会更加延误项目。因为：（1）新手会产生很多新的错误，使项目混乱。（2）老手向新手解释工作以及交流思想都要花费时间，使实际开发时间更少。所以科学的项目计划很重要，不在乎计划能提前多少，重在恰如其分。如果用“**”的方式奔向共产主义，只会产生倒退的后果。
观念之四：既然需求分析很困难，不管三七二十一先把软件做了再说，反正软件是灵活的，随时可以修改。
客观情况：对需求把握得越准确，软件的修修补补就越少。有些需求在一开始时很难确定，在开发过程中要不断地加以改正。软件修改越早代价越少，修改越晚代价越大，就跟治病一样道理。
1.4 一些有争议的观念
本节探讨一些有争议的观念，目的不在于得出“正确”或“错误”的评断，而在于争议会激发更多理性的思考。
争议之一：如果软件运行较慢，是换一台更快的计算机，还是设计一种更快的算法？ 作者观点：如果开发软件的目的是为了学习或是研究，那么应该设计一种更快的算法。如果该软件已经用于商业，则需谨慎考虑：若换一台更快的计算机能解决问题，则是最快的解决方案。改进算法虽然可以从根本上提高软件的运行速度，但可能引入错误以及延误进程。技术狂毫无疑问会选择后者，因为他们觉得放弃任何可以优化的机会就等于犯罪。
类似的争议还有：是买现成的程序，还是彻底自己开发？技术人员和商业人士常常会有不同的选择。
争议之二：有最好的软件工程方法，最好的编程语言吗？
作者观点：在软件领域永远没有最好的，只有更好的。能解决问题的都是好方法或是好语言。程序员在最初学习Basic、Fortran、 Pascal、C、C++等语言时会感觉一个比一个好，不免有喜新厌旧之举。而如今的Visual Basic、Delphi、Visual C++、Java等语言各有所长，真的难分优劣。开发人员应该根据客观条件，选择自己熟悉的方法和语言，才能保证合格的质量与生产率。
程序设计是自由与快乐的事情，不要发誓忠于某某主义而自寻烦恼。
争议之三：编程时是否应该多使用技巧？
作者观点：就软件开发而言，技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不为人熟知。若在程序中用太多的技巧，可能会留下隐患，别人也难以理解程序。鉴于一个局部的优点对整个系统而言是微不足道的，而一个错误则可能是致命的。作者建议用自然的方式编程，少用技巧。
《狼三则》的故事告诉我们“失败的技巧通常是技俩”。当我们在编程时无法判断是用了技巧还是用了技俩，那就少用。《卖油翁》的故事又告诉我们“熟能生巧”，表明技巧是自然而然产生的，而不是卖弄出来的。卖油翁的绝技是可到中央电视台表演的，而他老人家却谦虚地说：“没啥没啥，用熟了而已”。
争议之四：软件中的错误是否可按严重程度分等级？
作者观点：在定量分析时，可以将错误分等级，以便于管理。微软的一些开发小组将错误分成四个等级 [Cusumano 1996]，如表1.1所示。
表1.1 错误的四个等级
上述分类是非常技术性的，并不是普适的。假设某个财务软件有两个错误：错误A使该软件死掉，错误B导致工资计算错误。按表1.1分类，错误A属一级严重，错误B属二级严重。但事实上B要比A严重。工资算多了或者算少了，将会使老板或员工遭受经济损失。而错误A只使操作员感到厌烦，并没有造成经济损失。另一个示例是操作手册写错，按表1.1分类则属四级严重，但这种错误可能导致机毁人亡。
开发人员应该意识到：所有的错误都是严重的，不存在微不足道的错误。这样才能少犯错误。
1.5 小 结
软件工程学科发展到今天，已经有了很多方法和规范，学之不尽。本章只在宏观上讨论了软件工程的一些思想，更具体的内容将在后面的章节论述。无论是什么好方法，贵在理解与灵活运用，而不可当成灵丹妙药，不象“吃了脑黄金或脑白金，就能使一亿人先聪明起来”。
范文二：软件工程的思想
在60年代计算机发展初期，程序设计是少数聪明人干的事。他们的智力与技能超群，编写的程序既能控制弱智的计算机，又能让别人看不懂、不会用。那个时期编程就跟捏泥巴一样随心所欲，于是他们很过分地把程序的集合称为软件，以便自己开心或伤心时再把程序捏个面目全非。人们就在这种美滋滋的感觉下热情地编程，结果产生了一堆问题:程序质量低下，错误频出，进度延误，费用剧增??。这些问题导致了“软件危机”。
在1968年，一群程序员、计算机科学家与工业界人士聚集一起共商对策。通过借鉴传统工业的成功做法，他们主张通过工程化的方法开发软件来解决软件危机，并冠以“软件工程”这一术语。三十年余年来，尽管软件的一些毛病如人类的感冒一样无法根治，但软件的发展速度超过了任何传统工业，期间并未出现真真的软件危机。这的确是前人的先见之明。如今软件工程成了一门学科。
软件工程主要讲述软件开发的道理，基本上是软件实践者的成功经验和失败教训的总结。软件工程的观念、方法、策略和规范都是朴实无华的，平凡之人皆可领会，关键在于运用。我们不可以把软件工程方法看成是诸葛亮的锦囊妙计?—在出了问题后才打开看看，而应该事先掌握，预料将要出现的问题，控制每个实践环节，并防患于未然。研究软件工程永远做不到理论家那么潇洒:定理证明了，就完事。
我在读大学的十年里有八年从事软件开发，尽管编写了几十万行C++/C程序，也经历了若干次小不点儿大的成功和失败，可老感觉只学了些皮毛，心里慌兮兮的。在博士研究生毕业前的半年里，我告戒自己不应该再稀里糊涂地在程序堆里滚爬下去了，于是就面壁反省，做了一阵子木讷的和尚。在“打坐”时，每有心得体会便记录下来，不知不觉凑成了八章经，我就给此经书起名为《软件工程思想》。
经典的软件工程书籍厚得象砖头，或让人望而却步，或让人看了心事重重。请宽恕我的幼稚，我试图用三个问题:是什么、为什么、怎么办，来解释软件工程的道理。所以本书薄得象饺子皮?—用来包“思想”这种有味道的“馅”。
项目计划与质量管理
在可行性分析之后，项目计划与质量管理将贯穿需求分析、系统设计、程序设计、测试、维护等软件工程环节。
项目计划是要提供一份合理的进程表，让所有开发人员任务明确、步调一致，最终共同准时地完成项目。项目计划是要付诸实施的，不象用嘴巴喊政治口号，可以很夸张。软件的项目计划重在“准确”而非“快速”。
提高质量是软件工程的主要目标。但由于软件开发是一种智力创作活动，很难象传统工业那样通过执行严格的操作规范来保证软件产品的质量。世上最小心翼翼、最老实巴脚的程序员未必就能开发出高质量的软件来。程序员必须了解软件质量的方方面面(称为质量因素)，如正确性、性能、易用性、灵活性、可复用性、可理解性等等，才能在进行系统设计、程序设计时将高质量内建其中。软件的高质量并不是“管理”出来的，实质上是设计出来的，质量的管理只是一种预防和认证的手段而已。
3.1 项 目 计 划
做项目计划，如同给一个待出生的婴儿写传记那样困难。如果允许项目结束后再写计划，那就轻松多了，并且可以100% 地准确。
[[ 历史教训让我们明白一个道理:如果一万年以后才会有一条阳光大道通向共产主义，那么现在就不要忙着砸锅炼钢赶英超美，免得在跑步奔向共产主义时把自己累死饿死]]。在做软件的项目计划时，应屏弃一切浮夸作风。只有“知已知彼”才能做出合理的项目计划。这里“知彼”是指要了解项目的规模、难度与时间限制。“知已”是指要了解有多少可用资源，如可调用的程序员有几个,他们的水平如何,软硬件设施如何,
3.1.1 知己知彼
首先要了解项目的规模、难度与时间限制，才可以确定应该投入多少人力、物力去做这个项目。在可行性分析阶段就要考虑这个问题。但不幸的是，人们在陷入项目不能自拨之前总难以准确地估计项目的规模与难度。这里经验起到了最重要的作用。
项目的时间限制有两类。第一类，项目应该完成的日期写在合同中，如果延期了，则开发方要作出相应的赔偿。第二类是开发自己的软件产品，虽然只确定了该产品大致的发行日期并允许有延误，但如果拖延太久则会失去商机造成损失。
项目的资源分为三类:“人”、“可复用的软构件”和“软硬件环境”，如图3.1所示。(,)人是最有价值的资源。项目计划的制定者要确定开发人员的名单，要根据他们的专长进行分工。
(,)可复用的软构件是次有价值的资源。1.2.1节论述了复用软构件可提高软件的质量与生产率。软构件并非一定要用自己的，可以向专业的软件供应商购买。
(,)软硬件环境虽然不是最重要的资源，却是必需的资源。原则上软硬件环境只要符合项目的开发要求即可。有些项目可能要用到特殊的设备，则要事先作好准备，以免用时找不到而担搁了进程。
一个软件系统因能给用户提供价值而具有存在价值，所有的决定都应该基于这个思想。在确定系统需求之前，在关注系统功能之前，在决定硬件平台或者开发过程之前，问问你自己:这确实能为系统增加真正的价值吗,如果答案是不，那就坚决不做。所有的其他原则都以这条原则为基础。 第2原则:保持简洁
软件设计并不是一种随意的过程，在软件设计中需要考虑很多因素。所有的设计都应该尽可能简洁，但不是过于简化。这有助于构建更易于理解和易于维护的系统。这并不是说那些特征甚至是内部特征应该以“简练”为借口而取消。的确，优雅的设计通常也是简洁的设计，简练也不意味着“快速和粗糙”。事实上，它经常是经过大量思考和多次工作迭代才达到的，这样做的回报是所得到的软件更易于维护且存在更少错误。
第3原则:保持愿景
清晰的愿景是软件项目成功的基础。没有愿景，项目将会由于它有“两种或者更多种思想”而永远不能结束如果缺乏概念的一致性，系统就好像是由许多不协调的设计补丁、错误的集成方式强行拼凑在一起…如果不能保持软件系统体系架构的愿景，将削弱甚至彻底破坏设计良好的系统。授权体系架构师，使其能够保持愿景，并保证系统实现始终与愿景保持一致，这对项目开发成功至关重要。
第4原则:关注使用者
有产业实力的软件系统不是在真空中开发和使用的。通常软件系统必定是由开发者以外的人员使用、维护和编制文档等，这就必须要让别人理解你的系统。因此，在需求说明、设计和实现时，经常要想到要让别人理解你所做的事情。对于任何一个软件产品，其工作产品都可能有很多读者。需求说明时应时刻想到用户;设计中始终想到实现;编码时想着那些要维护和扩展系统的人。一些人可能会被迫调试你所编写的代码，这使得他们成了你所编写代码的使用者，尽可能地使他们的工作简单化会大大提升系统的价值。
范文三：软件工程的基本概念
软件工程的基本概念
软件工程的基本概念2010-11-07 12:23
考点(1)软件与软件危机
软件是由盘算机程序演化而构成的一种概念，它是程序及相干文档的聚集，由可执行局部和与程序和过程有关的文档材料两部门组成。
软件危机是计算机在软件的开发和维护过程中遇到的一系列问题，它是跟着计算机硬件的敏捷发展和范围的不断扩展，以及软件自身复杂性的增加而产生的。
软件危机产生的基本原因有两个方面:一是软件生产本身存在着复杂性;二是与软件开发方法和技术有关。软件工程是为战胜软件危机而提出的一种概念及相关的方法和技术。
考点(2)软件生命周期
20世纪70年代提出的软件生命周期的瀑布模型，典型地描绘了软件生命周期的阶段划分，它把软件生命周期划分为8个阶段，分离是问题定义、可行性研究、需求分析、总体设计、详细设计、程序编制、测试和运行与维护。
考点(3)软件开发技术与软件工程管理
软件开发技术包括软件开发方法学、工具和环境，其主体内容是软件开发方法学。软件开发工具和环境是保证软件工程方法学得以实施的必要前提;软件开发环境是方法与工具的联合，以及配套的软件的有机组合。
软件工程管理包括软件管理学和软件工程经济学。
软件工程管理是软件按工程化出产时的主要环节，它要求依照预先制订的筹划、进度和估算执行，以实现预期的经济效益和社会效益。
软件工程经济学是研究软件开发中对成本的估算、本钱效益分析的方法和技术。它应于经济学的基本原理来研究软件工程开发中的经济效益问题。
考点(4)软件开发方法、工具和环境
软件开发方法大体可归纳为3品种型:基于瀑布模型的结构化生命周期方法，基于动态定义需求的原型化方法和基于结构的面向对象的软件开发方法。
软件开发工具是从单项工具的开发逐渐向集成工具的开发发展的，它增进了软件开发的高速度和高质量，同时软件开发方法的有效应用，也必须得到相应工具的支撑，而工具的完美和发展将促进软件开发方法的提高和完善。
软件工程环境是全面支持软件开发工程的软件工具集合，按一定的模式组合起来，支持软件开发生命周期的各阶段和任务的完成。
考点(6)软件需求分析
1.需要剖析的义务
肯定系统必须实现哪些工作，也就是对目标体系提出完全、正确、清楚、详细的要求。需求分析的起点是可行性分析阶段发生的文档和数据流图;需求分析的详细任务是确定对系统的综合要求，分析系统的数据要求，导出系统的逻辑模型，修改系统开发打算，开发原型系统。
2.需求分析常用的工具
(1)数据字典是定义一个利用程序中应用的所有数据元素和构造的含意、类型、数据大小、格局、度量单位、精度以及容许取值范畴的共享仓库。
(2)数据流图。是结构化系统分析的基本工具。一个数据流图确定了系统的转化过程、系统所把持的数据或物资的收集(存储)，还有过程、存储、外部世界之间的数据流或物质流。
(3)状况转换图。实时系统和过程控制应用程序可以在任何给定的时间内以有限的状态存在。
(4)对话图。对话图刻画了系统中的对话元素和它们之间的导航衔接。
(5)类图。类图是用图形方法叙述面向对象分析所确定的类及它们之间的关系。
3.需求分析的方法和步骤
需求分析的方式如下:
(1)理解当前的事实环境。
(2)将当前系统的具体模型抽象为当前的逻辑模型。
(3)分析新系统与当前系统逻辑上的差别，树立新系统的逻辑模型。
(4)确定新系统的人机界面和一些弥补考虑的细节问题,爆笑笑话。
需求分析的步骤如下:
(1)沿数据流图回溯。
(2)用户复查。
(3)细化数据流图。
(4)修正开发计划。
(5)书写文档。
(6)审查和复审。
4.软件需求说明书
软件需求阐明书的内容包括概述、数据描述(包括数据流图、数据字典、系统接口说明和内部接口)、功能描述(包括功能、处理解释和设计的限度)、机能描述(包括性能参数、测二讼类、预期的软件响应和招考虑的特别问题)、参考文献目录和附录等。
考点(7)软件系统设计
1.系统设计概述
系统设计个别分为总体设计和详细设计两个阶段。
2.总体设计
总体设计的任务是确定软件的总体结构。
总体设计的目标是用比拟形象概括的方式确定系统如何完成预定的任务，也就是说应该确定系统的物理配置方案，并且进而确定组成系统的每个程序的结构。总体设计可以分为系统设计和软件结构设计。
总体设计的典范过程是假想供取舍的方案，选取公道的方案，推举最佳方案，功能分解，设计软件结构，数据库设计，制定测试计划，书写文档，审查和复查。
3.软件的结构、过程和模块
(1)软件结构。是软件模块间关联的表现。
(2)软件结构的度量术语如下:
深度:是表示软件结构中控制的层数。
宽度:是软件结构内统一档次上的模块总和的最大值。
扇出:是一个模块直接节制的模块数。
扇入:是有多个上级模块直接调用一个模块。
(3)软件过程。软件过程用于描述每个模块的操作细节，同时也包括一个模块对下一层模块控制的操作细节。
(4)模块独立性。是设计的软件结构使得每个模块完成一个相对独立的特定子功能，并且和其他模块之间的关系很简单。模块独立性是用藕合与内聚来度
量的。藕合:衡量不同模块彼此之间彼此依赖的紧密程度;内聚:衡量一个模块内部各个元素彼此结合的紧密水平。
4.面向数据流的设计方法
面向数据流的设计方法是把信息映射成软件结构，信息流的类型决议映射的方法。
(1)变换流是指信息沿输入通路进人系统，同时由外部形式变换成内部形式进人系统;信息通过变换中央，经加工处理后，经输出通路变换成外部情势输出。
(2)事务流是指数据沿输入通路达到一个处理T，这个处理T依据输入数据的类型在若干个动作序列当选出一个来执行，这类数据流称为事务流。
(3)面向数据流方法的设计过程是精化数据流图，辨别是事务流仍是变换流，根据设计准则精化软件结构，导出接口描述和全程数据结构，复查，进人详细设计。
(4)变换分析指的是将变换流映射为变换结构。变换分析的目的是用一系列设计步骤，把存在变换流特色的数据流按预先确定的模式映射成软件结构。
(5)事务分析。事务分析的设计步骤和变换分析设计步骤大抵类似，差异仅在于从数据流图到软件结构的映射方法不同，它将事务核心映射成为软件结构中发送分支的调度模块，将接受通路映射成为软件结构的吸收分支。
(6)详细设计的任务是为软件结构图中的每一个模块确定所采用的算法和数据结构。
考点(8)程序设计
1.程序设计阶段的任务
编码阶段的任务是为每个模块编写程序，就是将详细设计的结果转换成某种程序语言的源程序，编译程序再将这些源程序转换成依附于具体机器的目标代码。
2.结构化设计的概述
结构化设计的基础请求是在具体设计阶段，所有的模块都只使用次序、抉择和轮回3种根本掌握结构。结构化设计的毛病是目的程序所须要的存储容量和运行时光都有一些增添。
3.程序设计语言的挑选
(l)程序设计语言。程序设计语言是编程者用于求解问题的工具。
(2)程序高等语言通常分为基本语言、结构化程序语言和专用语言。
(3)b5cc5a0c29a5054cd38017a81ceca2cc语言的选择。选择语言的方法是从所要解决的课题动身确定对语言的要求，并同时确定这些要求的绝对重要性。
4.程序设计的方法
(1)模块化。是把一个较大的程序划分为若干个子程序，每一个子程序老是独破成为一个模块;每一个模块又可继承划分为更小的子模块。
(2)自顶向下。是先设计第1层，即顶层，而后步步深刻，逐层细分，逐步求精，直到全部问题可用程序设计语言明白地描写出来为止。
(3)自底向上。是先设计底层，最后设计顶层。
5.程序设计的步骤
(1)分析问题。
(2)建立数学模型。
(3)选择算法。
(4)编写程序。
(5)调试运行
(6)分析成果。
(7)写出程序的文档。
2.3软件测试
考点(9)软件测试的基本概念
测试是为了发现程序中的错误而履行程序的进程。好的测试计划是尽可能地发现至今沿未发现的错误，胜利的测试则是发现了至今尚未发现的错误。
1.软件测试的任务
软件测试的任务主要是防备软件产生错误、发现并改正程序错误和供给错误诊断信息。
2软件测试的步骤
(l)模块测试(单元测试)。
(2)子系统测试。
(3)系统测试(集成测试)。
(4)验收测试。
(5)平行运行。
3.软件测试的方法
软件测试的方法有动态测试、静态测试和正确性证实3种。
动态测试通常指的是上机测试，这种方法是使程序有控制地进行，并从多种角度察看程序运得时的行动，以发现其中的错误;静态测试普通是指人工评审软件文档或程序，借以发现其中的错误，这是一个相称有效的检修手腕，但由于评审人的才能有限，静态测试显然不
可能发现所有的错误。
考点(10)软件测试技巧
1.基本概念
单元:是程序中最小的和最有意思的部分，由数据输入、加工和输出3部分组成，单元是可以正式说明的程序段。
程序/子程序:是由单元组成，内部各单元之间联系最为严密，程序由子程序组成。
拼程序/系统:是由程序/子程序组成，每个程序完成独立的加工，子系统之间相对独立，有独立的数据确认机构。
2.黑箱和白箱测试的实施
(l)黑箱测试法(功能测试)。是把程序看成是一个黑箱子，完整不斟酌程序的内部结构和处置过程。也就是说，黑箱测试是在程序接日进行的测试，它只检查程序功能是否能按照规格仿单的规定正常使用，程序是否能恰当接收输入数据，产生正确的输出信息,爆笑笑话，并且坚持外部信息的完整性。
(2)白箱测试法(结构测试)。是把程序看成装在一个透明的白箱子里，也就是完全懂得程序的结构和处理过程，按照程序内部的逻辑测试程序，测验程序中的每条通路是否都能按预约的要求正确工作。
3.程序排错方法
程序排错是程序测试后开端的工作，它断定测试中发明过错的性质和地位，并修正毛病，排错有良多种办法，重要有简略排错法、演绎排错法、演绎排错法跟反向搜寻排错法等。
4.测试与排错
测试与排错是相互接洽但又是性质不同的两类活动，它们之间的关系是一个好的测试设计有利于排错，从而保障程序的准确性。
5.路径测试
路径测试是结构测试之一，路径可定义为从程序元素的人口开始，到它的出口终止的可执行指令程序。路径测试的目标是通过检验足够多的程序元素的门路来证明程序元素的实际结构同所冀望的程序元素的结构是一致的。
考点(11)软件测试的组成
软件系统的开发过程是一个自顶向下逐步细化的过程，而测试过程是以相反顺序进行的集成过程，软件测试的组成包括单元测试、集成测试、有效性测试、系统测试和验收测试等。
(1)单元测试。是检查模块单元的子程序或过程的实际功能与该模块的功能和接口的描述是否相符，以及是否有编码错误的存在。
(2)集成测试。集成测试是指在组装软件模块的同时进行测试，以查找与接口有关的错误。
(3)有效性测试。是指当软件的运行到达了用户的盼望时，则以为软件是有效的。
(4)系统测试。是将软件系统与硬件，外设与其余系统元素结合在一起，对整个软件系统进行测试，其内容包括功能测试、吞吐量测试、可用性测试、保密性测试、安装测试、可恢复性测试、资料测试和程序测试。
(5)验收测试。是系统测试通过后，由用户进行验收测试，确定系统功能的可接收性。
(6)软件测试的实施。软件测试是一个极为庞杂的过程。一个标准化的软件测试过程通常包含以下基本的测试活动:拟定软件测试规划，编制软件测试纲要，设计和天生测试用例，实施测试，生成软件问题讲演。
2.4软件维护
考点(12)软件维护的基本概念
维护是软件生命周期的最后一个阶段，也是连续时间最长和代价最大的一个阶段。软件工程学的主要目标就是进步软件的可维护性，下降维护的破费。
软件维护通常包括为了改正在使用过程中裸露出来的错误而进行的改进性维护，为了适应外部环境的变更而进行的适应性维护，为了改进原有的软件而进行的完善性维护，以及为了改进未来的可维护性和可靠性而进行的预防性维护。
1.软件保护的基本任务
软件维护是指系统交付使用当前对它所做的改变,爆笑笑话，也是软件生存周期中最后一个阶段。
转变的起因是矫正程序的错误和缺点，改良设计和实用新的软、硬件环境，增长新的运用规模。
2.软件维护的分类
软件维护主要划分为纠错性维护、适应性维护和完善性维护。
(1)纠错性维护。因为前期的测试不可能揭穿软件系统中所有潜在的错误，用户在使用软件时仍将会碰到错误，诊断和纠正这些错误的过程称为纠错性维护。
(2)适应性维护。因为新的硬件装备不断推出，操作系统和编译系统也不断地进级，为了使软件能适应新的环境而引起的程序修改和裁减活动称为适应性维护。
(3)完善性维护。在软件的畸形使用过程中，用户还会一直地提出新的需求。为了满意用户新的需求而增加软件功效的运动称为完善性维护。
考点(13)影响维护的因素
影响软件维护的因素包括人员因素、技术因素、管理因素和程序本身的因素。
考点(14)软件可维护性度量
可维护性度量表示软件系统维护工作的强度或维护工作量的大小。实际中把可维护性试题问题分为对可测试性、可理解性、可修改性、可移植性、可靠性、有效性和可用性的度量。
考点(15)软件维护任务
软件维护的任务包括:检查用户的要乞降说明书，同用户和开发者切磋，检查程序和文档，确定程序错误的性质和位置，研讨程序的修改可行性和修改可能引起的成果，对改变部分进行编码，修改程序言档和程序库、数据库等。
考点(16)维护的副作用
维护的副作用主要表示在:修改程序的副作用，修改数据的副作用和文档资料的副作用等。
考点(17)软件文档
软件系统的文档可以分为用户文档和系统文档。
(1)用户文档。用户文档的目的是使用户了解系统，使用户取得对系统的精确的初步印象。它应当包括功能描述、装置文档、使用手册、参考手册和操作员指南等内容。
(2)系统文档。是指从问题定义、需求说明到验收测试计划等一系列与系统实现有关的文档。
2.5软件质量评估
考点(18)软件质量
软件质量可分解成6个因素，它们分辨是功能性、牢靠性、易使用性、效力、可维修性和可移植性。
我们应从以下3个方面掌握软件质量的概念:
(l)软件需求是权衡软件质量的基本。
(2)划定了的尺度是软件开发必需遵守的准则，假如软件名目未能按标准开发，其质量一定是拙劣的。
(3)软件通常有着一些不做明文规定的隐含需求，如果开发的软件已经知足了明文规定的需求，却不满意隐含的需求，那么软件产品的质量依然是有问题的。
考点(19)软件质量的度量
软件质量的度量主要有以下多少个方面:
(l)与产品有关的特性。与产品有关的特性有正确性、硬朗性、效率、保险性、可用性、危险性和可靠性等。
(2)与产品修改有关的特性。与产品修改有关的特征有可懂得性、可维护性、适应性和可测试性等。
(3)与产品转移有关的特性。与产品转移有关的特性有可移植性、可重用性和互运行性。
考点(20)保证软件质量的手段
复审:是在软件生命周期每个阶段停止之前，都采取必定的标准对该段产生的软件配置成分进行严厉的正式或非正式的检测。
复查:是检讨已有的资料，以判断在软件性命周期某个阶段的工作是否可能开始或持续。
管理复审:是向开发组织或使用部分的管理人员提供有关项目的总体状态、成本和进度等方面的情形，以便他们从管理角度对开发工作进行审查。
测试:包括测试计划、测试过程和测试结果3个阶段。
2.6软件管理
考点(21)软件治理的职能
软件管理的主要职能包括:组织管理、职员管理、资源管理、方案管理和
版本管理。
考点(22)标准化
软件工程标准化波及软件开发程序、软件设计、文档制造和项目管理4个方面。
咱们能够采用以下步骤来实行全面品质把持: (1)实施工程化开发。
(2)实行阶段性解冻与修改控制
(3)实行里程碑式的审查与版本控制。
(4)履行面向用户参加的原型演变。
(5)全面测试。
(6)引入外部监理与审计。
范文四：软件工程的基本概念
软件工程的基本概念
软件工程是指导软件开发、运行、维护的系统方法。软件工程是强调使用生存周期方法
和各种结构分析及设计技术。这些方法和技术适用于软件生存周期的各个阶段。所谓软件生
存周期，是指一项软件从构思起，从经过开发成功投入使用，到停止使用或被另一项软件代
替的全过程。
软件工程采用的生存周期方法就是从时间角度对软件开发的维护的复杂问题进行分解，
把软件生存的漫长周期依次划分为若干阶段，每个阶段有相对独立的任务，然后逐步完成每
个阶段的任务。采用软件工程方法开发软件时，从对任务的抽象逻辑分析开始，一个阶段一
个阶段地进行开发。前一个阶段任务的完成是下一阶段开始进行的前提和基础，而后一阶段
任务的完成使得肖一阶段提出的结果更加具体化。每一阶段的开始和结束都有严格标准，文
档中阶段通信的工具，是阶段衔接的纽带。概括起来，软件工程的基本思想是：
（1） 软件开发划分为若干个阶段，每个阶段的任务相对独立和简单。
（2） 完成各阶段任务是使用系统化技术和方法论。
（3） 适时地建立里程碑，从技术和管理两方面加以严格审查。
（4） 在软件的整个生存周期中编制完整的文档。
根据中华人民共和国国家标准GB8567-88《计算机软件产品开发文件编制指南》规定，
软件生存周期可以分为六个阶段：可行性研究与计划阶段，需求分析阶段，设计阶段、实现
阶段、测试阶段和运行与维护阶段。其中：
可行性研究与计划阶段,主要确定软件的开发目标和总体的要求，进行可行性分析、投
资—效益分析，制定开发计划。
需求分析阶段，重点对被设计的软件进行系统分析，确定对软件的各项功能，性能需求
和设计约束，确定对文档编制的要求。
设计阶段，根据软件需求提出多个设计，分析每个设计能履行的功能并进行相互比较，
最后确定一个设计，包括软件的结构、模块的划分、功能的分配以及处理流程。当软件比较
复杂的情况下，设计阶段可分成概要设计和详细设计两个步骤。
实现阶段，要完成源程序的编码、编译（或汇编）和排错调试，得出无语法错误的程序
清单。
测试阶段，对提出的程序全面进行测试，检查审定已编制出的文档。
运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且
可能的扩充和删改。
总之，采用软件工程可以大提高软件开发的成功率，软件的质量和生产率也会明显提高。
一、可行性研究与计划
软件开发之初必须要搞清楚解决的问题是什么，因此，进行可行性研究与计划是软件
开发的第一步。
明确软件开发目标、研究软件能否实现、提出开发计划就是可行性研究与计划的目的
和任务。
1． 主要任务
首先确切地定义用户要求解决的问题，也就是问题的性质、软件的目标和总的要求，然
后是用最小的代价在尽可能短的时间内确定问题是否能够解决。具体就就是，在澄清了问题
定义之后，要导出系统的逻辑模型，从此出发探索若干种解决办法。对每种解决办法都要认
真仔细研究三个可行性：
（1）技术可行性，即回答现有技术条件能否完成软件。
（2）经济合理性，即回答软件的成本与效益相比是否合算。
（3）实施可行性，即回答软件在实际使用时是否可行得通。
所以说，可行性研究与计划阶段要解决的关键在于对今后的行为提出建议；如果问题没
有可行的解，立刻停止软件开发，以免造成更大的浪费；如果问题值得一解，则要推荐一个
较好的解决方案，并为今后的工作制定一个初步的计划。
2．基本步骤
（1）对用户需求和现实环境进行调查。分析人员要访问有关用户，仔细阅读和分析有
关材料，认真倾听理解用户口头提出的需求，从而确定问题的性质、软件的目标和规模。在
复查确认的基础上，确保要解决的问题即用户要求解决的问题。
（2）提出解决办法。要对现有系统进行认真研究，根据用户需求导出新系统的高层逻
辑模型。一般用数据流图和数据字典表示。然后把新系统的逻辑模型与用户重新交换意见，
复查问题定义、工程规模和目标。从建议的逻辑模型出发，提出若干个较高层次的物理解法
供比较和选择，提出书面材料。
（3）进行可行性研究。根据书面材料和有关资料对欲开发的软件从经济、技术和实施
等方面进行可行性研究，写出可行性研究报告。
（4）评审。根据可行性研究结果，评审和审批决定软件项目是否继续。若项目可行，
则制订初步的软件开发计划。
3．主要要求
（1）实施可行性切不可忽略，技术上、经济上可行，但实施不可行的软件同样行不通。
（2）进行成本/效益分析要提供几种可供选择的解答，要有确切的数据和估算方法，避
免主观臆断。
（3）软件开发计划中要有明确的、可检查的标志。要提交齐全的、可验证的文档。包
括：
① 可行性研究报告；
② 初步的软件开发计划。
总之，可行性研究与计划的关键在于保证软件开发人员和用户目标一致的前
提下，提交供审查批准的行动方案。
二、需求分析
需求分析也叫要求分析，指在准确地解决“软件必须实现什么”的问题。
1．主要任务
（1） 确定对软件的综合需求
包括四方面的需求：
① 功能需求，即要划分出软件必须完成的一切功能。
② 性能需求，包括需要的存储容量、安全性、响应时间等。
③ 运行需求，主要是对软件运行时所处环境的要求。如支持软件运行的系
统软件是什么；采用什么数据库管理系统；需要什么样的外存储器和数据通信接口等。
④ 将来可能提出的需求，即列出那些虽然眼下不属于系统开发范畴，但将
来可能会提出来的需求，以便在设计过程中考虑将来的扩充和修改。
（2）分析软件的数据需求
任何一个软件本质上都是信息处理系统，软件必须处理的信息和软件应该产生的信息在
很大程度上决定着软件的面貌，对软件设计影响深远。因此，分析软件的数据需求就成为需
求分析阶段的重要任务之一。
软件中的数据分析要建立在对软件功能理解的基础上，借助图形工具进行。
对于要长期保存的数据分析，一般要分四个阶段进行：
① 对数据元素进行分组并且规范化，即把软件将要处理的数据元素分组归
并成若干个实体，建立起规范化的关系。
② 画出实体关系图，来描述不同实体之间的关系。
③ 事务分析，包括划分事务的入口点，确定为了满足事务的数据需求所需
要的实体联系数目、实体间的事务流以及需要的访问类型等等。
④ 建立数据模型，来表明事务的类型、具体的通路、重要的加载和周期等。
（3）推到出软件的逻辑模型
一般用数据流图、数据字典和主要的处理算法来表示这个逻辑模型。
（4）修正软件开发计划
即把分析过程中得到的更深入具体的了解，在可行性研究与计划阶段制定的开发计划中修正。
（5）快速产生软件原型
即在较短的时间内将软件雏形呈现在用户面前，使用户可以获得关于未来的软件的更直接具体的概念，从而能够更准确地提出需求。
2．基本步骤
既然软件本质上是信息处理系统，即将输入数据经过处理转变为输出信息的过程，而数据又决定了需要的处理和算法，因此需求分析的着眼点就是数据。
（1）调查开发软件的环境，进一步明确用户需求。首先搞清输出数据是由哪些元素组成的，然后沿数据流图从输出端往输入端回溯，得出输入数据元素，初步明确有关算法，交由用户仔细进行复查。
（2）细化数据流图。通过功能分解可以完成数据流图的细化，即把数据流图扩展到更低的层次，之后得到一组新的数据流图，不同的元素之间的关系变得更清楚了。
（3）编制文档。经过分析确定了软件具有的功能和性能，定义了软件中的数据并简略描述了处理的算法，这时首要任务是编制一份完整、一致、精确且简明易懂的软件需求说明书，此外还要修正开发计划行等。
（4）严格履行审查手续。分析结果产生后，要成立审查小组对分析结果进行审查，待审查通过，鉴定认可之后，方可进行下阶段工作。
3．主要要求
（1）需求分析阶段的工作，主要由分析员承担，用户一方应派负责人代表参加。而分析员通常由研制方业务资历较高的人担任，他处在用户和设计人员之间，沟通彼此的认识和见解。经过充分分析，确定下来的软件需求应该在所编写的软件需求说明书中确切地阐述出来。
（2）需求分析要以运行环境为基础，需求说明书要经过用户确认。
（3）要交付需求说明书和软件开发计划等文档。
需求分析是软件生存周期中的一个重要阶段。软件的功能和性能、软件需求的运行环境都在这阶段确定下来。分析的重点是数据流，需求分析结果的正确性决定软件开发能否成功。
三、软件设计
经过需求分析阶段的工作，建立了由数据流图、数据字典和一组算法描述所定义的软件系统逻辑模型，软件必须做什么已经清楚了，下来就要进行设计阶段解决“怎样做”的问题了。
1．主要任务
对于较大规模的软件，设计阶段也往往再细分为概要设计和详细设计两个阶段。概要设计的主要任务就是根据软件需求说明，建立目标系统的总体结构和模块间的关系，定义各功能模块的接口、控制接口，设计全局数据库/数据结构，规定设计限制，制订测试计划；详细设计的主要任务是对概要设计中产生的功能模块进行过程描述，设计功能模块的内部细节，包括算法和数据结构，为编写源代码提供必要的说明。对于小规模的软件，则要一次设计到底。
应该说，经过概要设计后产生的程序、文件、数据库、处理过程和文档等物理元素仍处于“黑盒子”状态，经过详细设计之后，则得到目标系统的精确描述，软件系统的“蓝图”就基本呈现出来了。
2．基本步骤
（1）建立目标系统的总体结构。从软件需求出发，对于大规模软件系统，可以分解划分为若干子系统，然后为每个子系统定义功能模块及各功能模块间的关系，并描述各子系统的接口界面；对于小规模软件系统，则可按软件需求直接定义目标系统的功能模块及模块间的关系。对各功能模块要给出功能描述，数据接口描述，外部文件及全局数据定义。
（2）数据库设计。针对数据需求进行数据库设计，经历模式设计、子模块设计、完整性和安全性设计、优化等四个步骤。
（3）模块设计。将概要设计产生的构成软件系统的各个功能模块逐步细化，形成若干个程序模块（可编程模块）。采用某种详细设计表示方法对各个程序模块进行过程描述，确定各程序模块之间的详细接口信息，拟定模块测试方案。
（4）制定测试计划。在软件设计中就考虑测试问题，能促使提高软件可测试性。
（5）编制文档并进行审查。要编制完整的文档，并对软件设计结果进行严格的技术审查，审查通过后，有关人员要签字认可。
3．主要要求
（1）在设计目标系统的整体结构时，应力争使其具有好的形态，各功能模块间要相对独立，降低模块接口的复杂性。
（2）模块设计要尽可能按结构化程序设计原则进行。要详细地规定各程序模块之间的接口，包括参数的形式和传送方式、上下层调用关系等，确定模块内的算法及数据结构。
（3）要交付齐全、可验证的文档，包括：
① 概要设计说明书；
② 详细设计说明书；
③ 数据库设计说明书；
④ 模块开发卷宗；
⑤ 测试计划。
总之，软件设计就是把软件需求转化为软件的具体设计方案的过程。首先要
根据软件需求，采用结构化设计技术，导出软件模块总体结构；其次是使用表格、流程图或文字等方式给出软件各个模块的具体过程描述。软件设计的结果是编程实现的直接依据。
四、软件实现
实现阶段亦即软件编程或叫软件编码阶段，是为软件设计阶段得出的每个模块编写程序。
1．主要任务
就是将详细设计说明转化为所要求的程序设计语言或数据库语言书定的源程序。并对编制出的源程序进行程序单元测试，验证程序模块接口与详细设计说明的一致性。
2．基本步骤
（1）选择程序设计语言。大量实践证明，高级程序设计语言优于汇编语言。但选择何种高级程序设计语言，有三条实用标准：
① 高级程序设计语言有本身的特点，不同的语言适应范围有所不同。比如
FORTRAN语言更适合科学计算；VB、PB、Delph则更适合辅助管理；C、ADA更适合于系统和实时应用；LISP更适合于组合问题领域；PROLOG更适合于表达知识和推理。
② 环境因素，如问题性质。要解决的问题是科学计算呢，还是实时应用或
辅助管理？这对程序设计语言选择有一定要求。
③ 用户熟悉程度。
（2）编程。使用所选定的程序设计语言对每个程序模块进行编程。尽管这
步工作十分具体，难度相对不大，但也要配齐必要的人力，以确保程序质量。程序员要掌握结构化程序设计、编程等技术方法，注意抓住程序设计语言或数据库操纵语言的特点，精心考虑程序的结构和文件组织，使编制出的程序易读、易懂、易维护、易移植，执行效率高。
（3）进行程序单元测试。按照事先制定的测试方案产生一批测试数据，按
照规定的方法进行程序单元测试。
（4）编写完整的文档。
3．主要要求
（1）要尽量选择符合国家标准的、适用的程序设计语言，采用结构化的程序设计方法。
（2）为了提高程序的可理解性，要在源程序中加入适当的注解。
（3）尽量采用增加程序可读性的排版格式，即程序内部的良好文档资料、有规律的数据说明格式、简单清晰的语句构造和输入/输出格式等。
（4）利用适当的软件工具辅助编程，以提高生产率和减少程序中的错误。
（5）不仅要考虑对合法的输入产生测试用例，而且要对非法的、非预期的输入产生测试用例。既要对正常的处理路径进行测试，也要考虑对出错处理路径进行测试。程序模块的测试用例、预期结果及测试结果应存档保留。
（6）要提交“模块开发卷宗”。
总结一下，编程是在软件设计之后进行的，程序质量主要由设计质量决定。但编程选用的语言、编程风格和途径对程序质量同样有较大影响。
五、软件测试
任何软件，在开发的各个阶段，由于会遇到极其复杂的情况，加上开发人员的主观认识总不可能那么周密而完美无缺，因而会不可避免地出现错误。测试阶段就是要找出并排除这些错误。
1．主要任务
所谓测试就是为了发现程序中的错误而执行程序的过程。由此定义出发，测试的主要任务就是要发现错误并改正错误，提交高质量的完全符合用户需要的软件。
有人认为测试的目的是为了说明程序的正确，只要随便找几个数据，把程序走通就行了。这种认识不仅不对，而且是非常有害的。因为这可能导致去找那些容易在机器上通过的测试数据，致使隐藏的错误不易被发现。另一方面，个别测试数据走得通并不意味着程序里没有问题。因此，我们测试的目的是立足于找错误，暴露问题。
2．基本步骤
与开发过程类似，软件测试过程也要分步骤进行，每个步骤在逻辑上是前一个步骤的继续。大型软件系统的测试可分为五个步骤：
（1）模块测试。在软件设计中，每个模块要完成一个子功能，模块间是相对独立的。因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确
性的测试方案。通过模块测试可以发现编程和设计中的错误，保证每个模块作为一个单元正确运行。
（2）子系统测试。即把经过测试的模块装配在一起形成一个子系统来测试，重点测试模块间的协调、通信和模块的接口。
（3）系统测试。即把经过测试的子系统装配成一个完整的软件系统来测试。在此过程中不仅要发现编程和设计的错误，还要验证整个软件系统是否达到了要求。如果把模块测试称为单元测试的话，那么子系统测试和系统测试则称为集成测试。
（4）验收测试。验收测试是把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用户积极参与下进行的，而且主要使用实际数据进行测试。这样就可验证软件是否确实能够满足用户的需要。
（5）双轨运行。重大的软件在验收后也不可立刻撤掉原有（手工）系统而投入生产性运行，必须要经过一段时间的双轨运行考验。这样可以使用户对软件更熟悉，验证有关文档，在准生产环境中全负荷测试并验证软件，对所有文件进行整理。
3．主要要求
（1）软件测试要建立独立的测试小组进行，并邀请用户一起参加。程序员应避免测试其本人的程序；程序设计单位在条件允许时应避免测试本单位编制的程序。测试的评审者，可邀请测试专家或其它人员。
（2）要对软件的输入/输出处理进行测试，使其达到设计要求，软件的容量要留有足够的余地。
（3）测试前应仔细研究有关资料，测试中由程序编制者介绍程序算法，参加者随时提出问题，由编制者回答。对数据引用、数据说明、计算、比较、控制流程、接口、输入输出等逐一检查测试。测试过程中应防止审查者和软件制作者之间产生对立情绪。测试用的例子应预先估算输出结果，以便比较。全部预期结果、测试结果及测试数据应存档保留。
（4）要交付完整的文档：
① 测试分析报告；
② 用户手册和操作手册；
③ 项目开发总结报告。
软件测试是保证软件可靠性的主要手段，此阶段的任务是艰巨而繁重的。测
试计划、测试方案和测试结果直接影响软件质量和可维护性，要仔细记录和保存。
六、使用和维护
使用和维护是软件生存周期的最后一个阶段，即在软件交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
1．主要任务
首先，要发现和修改在开发阶段产生、在测试阶段又未发现的错误，即改正性维护； 其次，要针对运行环境的变化修改软件，即适应性维护；
再次，在软件使用过程中，用户往往提出许多的需求，如增加功能或修改已有的功能，对此要进行完善性维护。这部分工作占整个维护工作的大部分；
最后，为了提高软件的可靠性，减少以后的维护工作量，还要时常采取一些预防性措施，修修补补，即预防性维护。
总之，软件使用和维护的过程，也就是软件功能不断扩充和更趋完善的过程。
2．基本步骤
（1）建立维护组织。在使用和维护活动开始之前，就要正式或非正式地建立维护组织，明确责任、任务和维护程序，从而大大减少可能出现的维护紊乱。
（2）维护报告制度化。由软件用户或维护人员根据软件出现的错误、产生的问题或情况的变化向维护管理人员提交“软件问题报告”，然后由维护人员向维护管理人员提交“软件修改报告”。
（3）维护要求审定。由维护管理人员对“软件修改报告”进行评审，并赋予优先级；然后由维护人员分析维护需求，对满足要求所需的工作量和条件进行估计，确定维护实施计划。
（4）实施维护。按照一定的步骤对软件进行修改或扩充，完成后重新测试修改后的软件，修改所有相关的文件。通知用户修改已完成，并将修改以后的版本提交给用户。最后对维护活动进行评价，以便指导以后的维护工作。
3．主要要求
（1） 软件维护必须在严格的管理控制下进行，避免错上加错的情况出现。
（2） 尽量避免出现修改的副作用，在修改前要权衡利弊，全面考虑。
（3） 在有效的管理控制下，有步骤地进行修改，软件修改后要通过测试。
（4） 文档在软件使用和维护中至关重要，要与程序代码同时维护。
（5） 软件使用和维护中要交付两个文档：
① 软件问题报告。
② 软件修改报告。
总结起来，使用和维护是软件生存周期的最后一个阶段，也是最为费时、费
力的一个阶段。由于软件工程的主要目的之一就是提出软件的可维护性，因而软件开发各阶段都要充分考虑软件维护问题。
范文五：软件工程的基本概念
软件工程的基本概念
一、软件(Software)
是指包括程序、数据以及相关文档的完整组合。
国标定义:与计算机系统的操作有关的计算机程序、规程、规则以及可能有的文件、文档及数据。
概念 含义
软件 程序、数据和文档
程序 软件开发人员依据用户需求开发的，用某种程序设计语言描述的，能够
在计算机中执行的语句序列
数据 师程序能够正常操纵信息的数据结构
文档 与程序开发、维护和使用的有关资料
二、软件工程(Software Engineering)
是在20世纪60年代末期提出的。这一概念的提出，其目的是倡导以工程的原理、原则和方法进行软件开发，以期解决当时出现的“软件危机”。
1、软件危机(Software Crisis)
表现:软件需求的增长得不到满足;软件开发成本和进度无法控制;软件质量难以保证;软件不可维护或维护程度非常低;软件成本不断提高;软件开发生产效率的提高赶不上硬件的发展和应用需求的增长;软件通常缺少适当的文档资料。
总之，可以将软件危机归结为成本、质量和生产率等问题 。
2、软件工程的基本概念
(1)软件工程的目的
软件工程是指导计算机软件开发和维护的一门学科，它应用计算机科学、数学和管理科学等原理，以及借鉴传统工程的原则和方法，来创建软件，从而达到提高质量、降低成本的目的。
(2)软件工程
软件工程是研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上。
(3)软件工程的主要研究内容
? 软件开发技术:软件开发方法学、软件开发过程、软件工具和软件工程环境。
? 软件工程管理:软件管理学、软件经济学、软件心理学。
软件工程所包含的内容不是一成不变的，随着人们对软件系统的研制开发和生产的理解。应用发展的眼光看待它。
4)软件工程三个要素——方法、工具、过程 (
? 软件工程必须以有组织的质量保证为基础，全面质量管理和过程改进使得更加成熟的软件工程方法不断出现。
? 软件工程工具为过程和方法提供自动的或半自动的支持。这些软件工具被集成起来，建立起一个支持软件开发的系统，称之为计算机辅助软件工程(CASE，Computer Aided Software Engineering)。CASE集成了软件、硬件和一个存放开发过程信息的软件工程数据库，形成了一个软件工程环境。
? 软件的工业化生产过程应具备的特点:明确的工作步骤、详细具体的规范化文档、明确的质量评价标准。
三、软件生命周期
1、定义(Software Life Cycle)
软件产品从提出、实现、使用维护到停止使用的过程称为软件生命周期。软件生命周期可以划分为软件定义、软件开发和软件运行维护三个时期，每个时期又进一步划分成若干个阶段。
在实践中，软件开发并不总是按照计划、分析、设计、实现、测试、集成、交付、维护等顺序来执行的，即各个阶段是可以重叠交叉的。整个开发周期经常不是明显地划分为这些阶段，而是分析、设计、实现、再分析、再设计、再实现等迭代执行。
2、软件开发的基本策略
(1)复用
? 复用就是利用某些已开发的、对建立新系统有用的软件元素来生成新的软件系统。
? 软构件(Software Component):具有一定集成度并可以重复使用的软件组成单元。
? 软件复用就是直接使用已有的软构件，即可组装(或加以合理修改)成新的系统，而可以不必每次从零做起。
? 复用优点:降低了软件的成本、提高了生产率而且新系统也具有较高的质量。
(2)分而治之
分而治之是指把大而复杂的问题分解成若干个简单的小问题，然后逐个解决。诸如软件的体系结构设计、模块化设计都是分而治之的具体表现。
(3)优化与折中
优化:为了提高软件质量，程序员会不断改进软件中的算法，数据结构和程序组织。优化工作是十分复杂的，有时很难实现所有目标的优化，这时就需要“折中”策略。软件的折衷策略是指通过协调各个质量因素，实现整体质量的最优。软件折中的重要原则是不能使某一方损失关键的职能，更不可以象“舍鱼而取熊掌”那样抛弃一方。
转载请注明出处范文大全网 » 软件工程思想—软件工程基本观
