本系统主旨为培训学生.net开发技能，详细演示内容请参看：第一章 建立项目。
软件工程
发布日期：2005年9月21日|更新日期：2005年10月15日
部分内容来源于网络，京胜世纪整理
摘要：本文讲述数据库基本知识。
本页内容：
软件工程简介
软件过程
需求分析
设计
测试
部署
维护
项目管理
软件工程实际上是以工程化的管理方法，实现软件开发成本、进度、质量的控制与管理。
软件工程中的任务
需求分析
设计
编码
测试
部署
维护
软件过程是由若干完成软件工程任务的活动的集合。通过对软件过程的管理，可以实现软件质量的提高。
近年来，“过程成熟度”成为人们关注的焦点，软件工程研究所（SEI）提出了—个综合模型，定义了当一个组织达到不同的过程成熟度时应该具有的软件工程能力。针对开发过程的能力成熟度模型，CMM（Capability Maturity Model）共分五个级别。
五级的过程成熟度级别定义如下：
第一级：初始级——软件过程的特征是无序的，有时甚至是混乱的。几乎没有过程定义，成功完全取决于个人的能力。
第二级：可重复级——建立了基本的项目管理过程，能够追踪费用、进度和功能。有适当的必要的过程规范，使得可以重现以前类似项目的成功。
第三级：定义级——用于管理和工程活动的软件过程已经文档化、标准化，并与整个组织的软件过程相集成。所有项目都使用文档化的、组织认可的过程来开发和维护软件。本级包含了第二级的所有特征。
第四级：管理级——软件过程和产品质量的详细度量数据被收集，通过这些度量数据，软件过程和产品能够被定量地理解和控制。本级包含了第三级的所有特征。
第五级：优化级——通过定量的反馈，进行不断的过程改进，这些反馈来自于过程或通过测试新的想法和技术而得到。本级包含了第四级的所有特征。
根据实际开发的需要，人们针对软件开发过程设计了不同的模型线性顺序模型、原型模型、RAD模型、演化软件过程模型（增量模型、螺旋模型、构件组装模型、并发开发模型）这里简单介绍几种常用的过程模型。
线性顺序模型
软件需求分析：需求收集过程特别集中于软件上。要理解待建造程序的本质，软件工程师(“分析员”)必须了解软件的应用需求求，以及需求的功能、行为、性能和接口。系统需求和软件需求均要文档化，并与用户一起复审。
设计：软件设计实际上是一个多步骤的过程，集中于程序的四个完全不同的属性上：数据结构、软件体系结构、界面表示及过程(算法)细节。设计过程将需求转换成软件表示，在编码之前可以评估其质量。象需求一样，设计也要文档化，并且是软件配置的一部分。
代码生成：设计必须转换成机器可读的形式。代码生成这一步就是完成这个任务的。如果设计已经表示得很详细，代码生成可以自动完成。
测试：一旦生成了代码，就可以开始程序测试。测试过程集中于软件的内部逻辑——保证所有语句都测试到，以及外部功能——即引导测试去发现错误，并保证定义好的输入能够产生与预期结果相同的输出。
维护：软件在交付给用户之后不可避免地要发生修改(一个可能的例外是嵌入式软件)。在如下情况下会发生修改：当遇到错误时；当软件必须适应外部环境的变化时(例如，因为使用新的操作系统或外设)；或者当用户希望增强功能或性能时。软件维护重复以前各个阶段，不同之处在于它是针对已有的程序，而非新程序。
线性顺序模型是最早，也是应用最广泛的软件工程范例。但是，对于该模型的批评使得即使是最积极的支持者也开始怀疑其功效。在使用线性顺序模型过程中有时会遇到如下一些问题：
1.实际的项目很少按照该模型给出的顺序进行。虽然线性模型能够容许迭代，但却是间接的。结果，在项目组的开发过程中变化可能引起混乱。
2.用户常常难以清楚地给出所有需求，而线性顺序模型却要求如此，它还不能接受在许多项目的开始阶段自然存在的不确定性。
3.用户必须有耐心。程序的运行版本一直要等到项目开发晚期才能得到。大的错误如果直到检查运行程序时才被发现，后果可能是灾难性的。
4.开发者常常被不必要地耽搁。传统生命周期的线性特征会导致“阻塞状态”，其中某些项目组成员不得不等待组内其他成员先完成其依赖的任务。事实上，花在等待上的时间可能会超过花在开发工作上的时间！阻塞状态经常发生在线性顺序过程的开始和结束。
这些问题都是真实存在的。但不管怎样，传统的生命周期范型在软件工程中仍占有肯定的和重要的位置。它提供了一个模板，使得分析、设计、编码、测试和维护的方法可以在该模板的指导下展开。传统的生命周期模型仍然是软件工程中应用最广泛的过程模型。虽然它确实有不少缺陷，但很显然它比起软件开发中随意的状态要好得多。
原型模型
常有这种情况，用户定义了软件的一组一般性目标，但不能标识出详细的输入、处理及输出需求；还有一些情况，开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式。在这些及很多其他情况下，原型范型可能是最好的选择。
原型范型从需求收集开始。开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。然后是“快速设计”，快速设计集中于软件中那些对用户/客户可见的部分的表示(如输入方式和输出格式)。快速设计导致原型的建造。原型由用户/客户评估，并进一步精化待开发软件的需求。逐步调整原型使其满足客户的要求，同时也使开发者对将要做的事情有更好的理解，这个过程是迭代的。
理想上，原型可以作为标识软件需求的一种机制。如果建立了可运行原型，开发者就可以在此基础上试图利用已有的程序片断或使用工具(如报表生成器、窗口管理器等)来尽快生成工作程序。
但当原型已经完成了上述目的之后，我们将如何处理它们呐？
在大多数项目中，建造的第一个系统很少是可用的。它可能太慢，太大，难以使用或三者都有。没有其他选择，只能重新开始，虽然痛苦，但会得到更好的结果。建造一个经过重新设计的版本，解决了上述的问题……。当使用了新的系统概念或新技术时，你应该建造一个抛弃型的系统，因为即使是最好的计划也不可能是无所不知的，第一次就能完全正确。因此，管理上的问题不是你是否要建造一个指导系统，然后抛弃它，你必须这么做。唯一的问题是：是否需要事先计划好建造一个抛弃型系统，或是承诺要将抛弃型系统交付给用户。
原型可以作为“第一个系统。但这可能是一种理想化的看法。用户和开发者确实都喜欢原型范型，用户能够感受到实际的系统，开发者能够很快地建造出一些东西。但由于如下的原因原型仍存在问题：
1.用户似乎看到的是软件的工作版本，他们不知道原型只是“用口香糖和打包绳”拼凑起来的；不知道为了使原型很快能够工作，我们没有考虑软件的总体质量和长期的可维护性。当被告知该产品必须重建，才能使其达到高质量时，用户叫苦连天，会要求做“一些修改”，使原型成为最终的工作产品。如此，软件开发管理常常就放松了。
2.开发者常常需要实现上的折衷，以使原型能够尽快工作。一个不合适的操作系统或程序设计语言可能被采用，仅仅因为它是通用的和有名的；一个效率低的算法可能被使用，仅仅为了演示功能。经过一段时间之后，开发者可能对这些选择已经习惯了，忘记了它们不合适的所有原因。于是这些不理想的选择就成为了系统的组成部分。
虽然会出现问题，原型仍是软件工程的一个有效范型。关键是如何定义一开始的游戏规则，即用户和开发者两方面必须达成一致：原型被建造仅是为了定义需求，之后就该被抛弃(或至少部分抛弃)，实际的软件在充分考虑了质量和可维护性之后才被开发。
增量模型
增量模型融合了线性顺序模型的基本成分(重复地应用)和原型的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。例如，使用增量范型开发的字处理软件，可能在第一个增量中发布基本的文件管理、编辑和文档生成功能；在第二个增量中发布更加完善的编辑和文档生成能力；第三个增量实现拼写和文法检查功能；第四个增量完成高级的页面布局功能。应该注意：任何增量的处理流程均可以结合进原型范型。
当使用增量模型时，第一个增量往往是核心的产品，即实现了基本的需求，但很多补充的特性(其中一些是已知的，另外一些是未知的)还没有发布。核心产品交用户使用(或进行更详细的复审)，使用和/或评估的结果是下一个增量的开发计划。该计划包括对核心产品的修改，使其能更好地满足用户的需要，并发布一些新增的特点和功能。这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。
增量过程模型，像原型和其他演化方法一样，具有迭代的特征。但与原型不一样，增量模型强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但它们确实提供了给用户服务的功能，并且提供了给用户评估的平台。
增量开发是很有用的，尤其是当配备的人员不能在为该项目设定的市场期限之前实现一个完全的版本时。早期的增量可以由较少的人员实现。如果核心产品很受欢迎，可以增加新的人手(如果需要的话)实现下一个增量。此外，增量能够有计划地管理技术风险，例如，系统的一个重要部分需要使用正在开发的且发布时间尚未确定的新硬件，有可能计划在早期的增量中避免使用该硬件，这样，就可以先发布部分功能给用户，以免过分地延迟系统的问世时间。
需求分析
需求分析是一种软件工程活动，它在系统级软件分配和软件设计间起到桥梁的作用。需求分析使得系统工程师能够刻划出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束。需求分析允许软件工程师(在这种角色中经常称为分析员)精化软件分解模块，并建造将被软件处理的数据、功能、和行为模型。需求分析为软件设计者提供了可被翻译成数据、体系结构、界面和过程设计的模型，最后，需求规约为开发者和客户提供了软件建造完后质量评估的依据。
软件需求分析可被划分成5个工作阶段：(1)问题分析，(2)问题评估和方案综合，(3)建模，(4)规约，和(5)复审。
初始时，分析员研究系统规约(如果存在的话)和软件项目计划，并在系统语境内理解软件和复审，从而生成计划软件范围的估算。接着，必须建立针对分析的相互通信方式，以使得问题分析得到保证。分析员的目标是对用户/客户认识到的基本问题要素进行识别。
问题评估和方案综合是分析工作的下一个主要关注点，分析员必须定义所有外部可观察到的数据对象，评估信息流和内容；定义并详细阐述所有软件功能；在影响系统的事件的语境内理解软件行为；建立系统界面特征；以及揭示其他设计约束。这些任务中的每一个旨在描述问题，以便可以综合出全面的方法或解决方案。
例如，汽车零件的主要供应商需要一个库存控制系统，分析员发现与当前的手工系统相关的问题包括：(1)不能快速地获得部件的状况；(2)更新卡片文件需要2或3天的工作量；(3)由于没有办法查找相关厂商的部件信息而使得对同一厂商同一货品多次再订货，等等。一旦问题被标识出来，分析员将确定新系统该产生什么信息，以及将提供什么信息给系统，例如，客户希望得到指明什么零件被从库存中取出以及还剩余多少相似零件的日报表。客户指明一旦当该零件离开仓库时库存管理员就该记载每个零件的标号。
通过对当前问题和希望的信息(输入和输出)进行的评估，分析员开始综合一个或多个解决方案。为了便于开始，必须详细地定义系统的数据、处理功能和行为。一旦已经建立这些信息，就该考虑针对实现的基本体系结构。客户/服务器方法似乎是合适的，但是，它确实属于在软件计划中概括的范围吗？似乎需要一个数据库管理系统，但是，该数据库系统真的是用户/客户需要的吗？继续评估和综合的过程，直至分析员和客户均确信针对后面的开发步骤软件确实已被适当地刻划了。
贯穿整个评估和综合过程，分析员的主要焦点是“什么(what)”，而不是“怎么做(how)”，系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会应用什么约束？等。
在问题评估和综合解决方案的活动中，分析员创建系统模型，以便可以更好地理解数据和控制流、处理功能和操作行为、以及信息内容。模型是软件设计的基础，也是创建软件规约的基础。
重要的是要注意，在本阶段要得到详细的规约是不可能的。客户可能并不能精确地肯定需要什么，开发者可能不能肯定可用什么特定的方法来适当地完成功能和性能。由于这些以及许多其他理由，可以采用一种可选择的需求分析方法——原型法。
分析原则
所有分析方法都有一组操作原则：
1.必须表示和理解问题的信息域。
2.必须定义软件将完成的功能。
3.必须表示软件的行为(作为外部事件的结果)。
4.必须划分描述信息、功能和行为的模型，从而使得可以以层次的方式揭示细节。
5.分析过程应该从要素信息移向细节实现。
通过应用这些原则，分析员系统地处理某问题。检查信息域以使得功能可以被更完整地理解，使用模型以使得可以以简洁的方式交流功能和行为的特征，应用划分以减少问题的复杂性。在这些处理过程中软件的要素和视图实现对适当由处理需求带来的逻辑约束和由其他系统元素带来的物理约束是必需的。
针对“需求工程”的指导性原则：
1.在开始建立分析模型前先理解问题。人们通常总存在急于求成的倾向，甚至在问题被很好地理解前，这经常会导致产生一个解决错误问题的优美软件的诞生。
2.开发原型，使得用户能够了解将如何发生人机交互。因为人们一般对软件质量的感觉经常基于对界面“友好性”的感觉，因此，强力推荐使用原型方法(以及相应产生的迭代)。
3.记录每个需求的起源及原因。这是建立回溯到客户的可追踪性的第一步。
4.使用多个需求视图。建立数据、功能和行为模型，为软件工程师提供三种不同的视图，这将减少忽视某些东西的可能性，并增加识别不一致性的可能性。
5.给需求赋予优先级。过短的时限可能使每个软件需求得于实现的可能性减小，如果采用增量过程模型(第2章)，必须标识那些将在第一个增量中要交付的需求。
6.努力删除含糊性。因为大多数需求以自然语言描述，存在含糊性的可能，正式的技术复审是发现并删除含糊性的一种方法。
软件工程师将这些原则牢记在心，则有可能开发出为软件设计提供优秀基础的软件规约。
分析建模
我们创建模型可获得对将要建造的实际实体的更好的理解。当实体是物理的事物时(如建筑物、飞机、机器)，我们可以建造在形式和形状上相同、但在规模上要小的模型，然而，当所建造的实体是软件时，我们的模型必须采用不同的形式，从而使它们能够对软件变换的信息进行建模、对变换发生的功能(和子功能)进行建模、以及对变换发生时的系统行为进行建模。
在软件需求分析阶段，我们创建将要建造的系统的模型，这些模型着重于描述系统必须做什么、而不是如何去做系统。在很多情形下，我们使用图形符号体系创建模型，将信息、处理、系统行为和其他特征描述为不同的、可识别的符号，模型的其他部分可能是完全文字的，可使用自然语言或某特殊的专用于描述需求的语言来提供信息描述。
第二条和第三条操作性分析原则需要我们建立功能和行为模型。
功能模型：软件变换信息，为了达到此目标必须至少完成三个常见功能：输入、处理和输出。当创建应用的功能模型时，软件工程师只关注于问题特定的功能。功能模型从单个的语境层模型(即，将被建造的软件的名字)开始，经过一系列的迭代，将提供越来越多的功能细节，直至得到所有系统功能的完全描绘。
行为模型：大多数软件对来自外界的事件做出反应，这种刺激-反应特征构成了行为模型的基础。一个计算机程序总是存在于某个状态——一种外部可观测到的行为模式(如，等待、计算、打印、投票)，仅当某事件发生时才被改变。例如，软件将保持等待状态直至(1)某内部时钟指明某个时间段已经过去，(2)某外部事件(如，鼠标移动)产生一个中断，或(3)某外部系统通知该软件以某种方式动作。行为模型创建了软件状态的表示，以及导致软件状态变化的事件的表示。
在需求分析阶段创建的模型扮演了一系列重要的角色：
1.模型帮助分析员理解系统的信息、功能和行为，因此，使得需求分析任务更容易实现结果更系统化。
2.模型变成了复审的焦点，因此，也成为确定规约的完整性、一致性和精确性的重要依据。
3.模型变成了设计的基础，为设计者提供了软件要素的表示视图，该表示可被转化到实现的语境中去。
虽然使用的建模方法经常取决于个人(或组织)的喜爱，但对好的分析工作而言，建模活动是最基础的行为。
数据建模经常采用采用实体-关系图方法进行，功能建模和信息流经常采用数据流图，而目前较为流行的是使用UML（统一建模语言）进行分析建模，而其中较为实用是Use case分析。
设计概念
在过去30年中发展起来了一套基本的软件设计概念。尽管对于每一种概念的感兴趣程度在几十年中一直变化着，但它们都经历了时间的考验，每一种概念都为设计者提供了应用软件更加复杂的设计方法的基础。它们可以帮助软件工程师回答下述问题：
1.能使用什么标准将软件划分为单个构件？
2.如何将功能或数据结构与软件的概念性表示分离开？
3.是否存在定义软件设计的技术质量的统一标准？
软件设计处于软件工程过程中的技术核心位置，并且它的应用不考虑所使用的软件过程模型。软件设计开始于对软件需求进行分析和规约之后，它是构造和验证软件所需的三项技术活动—设计、代码生成和测试—之一，每一项活动都最终导致经过验证的计算机软件的方式变换信息。
分析模型的每一个元素均提供了创建设计模型所需的信息。通过数据、功能和行为模型展示的软件需求被传送给设计阶段，使用许多设计方法中的一种，设计阶段产生数据设计、体系结构设计、接口设计和过程设计。
数据设计将分析时创建的信息域模型变换成实现软件所需的数据结构。在实体—关系图中定义的数据对象和关系以及数据字典中描述的详细数据内容为数据设计活动奠定了基础。
结构设计定义了程序的主要结构元素之间的关系。这种设计表示—计算机程序的模块框架—可以从分析模型和分析模型中定义的子系统的交互导出。
接口设计描述了软件内部、软件和协作系统之间以及软件同人之间如何通信。一个接口意味着信息流(如数据和/或控制流)，因此，数据和控制流图提供了接口设计所需的信息。
我们在设计时作出的决策最终将会影响软件构造是否成功，更重要的是会决定，软件维护的难易程度，但是，为什么设计如此重要呢？
软件设计的重要性可以用一个词来表达—质量。设计是在软件开发中形成质量的地方，设计为我们提供了可以用于质量评估的软件表示，设计是我们能将用户需求准确地转化为完整的软件产品或系统的唯一方法。软件设计作为所有软件工程和软件维护步骤的基础，没有设计，我们将冒构造出不稳定系统的风险—稍作改动就会失败；难于测试的系统；直到软件工程过程后期才能评估系统的质量，到那时时间已不够并且已经花销很多经费。
设计原则
软件设计既是过程又是模型。设计过程是一系列迭代的步骤，它们使设计者能够描述要构造的软件的所有侧面，然而，要注意的是，设计过程不仅仅是一本菜谱，创造性的技能、以往的经验、对于什么能形成“良好”软件的感觉、以及对质量的全部责任是设计成功的关键因素。
设计模型和建筑师的房屋设计图是类似的，它首先表示出要构造的事物的整体(例如，房屋的三维表示)，然后逐渐精化事物，以提供构造每个细节(例如，管道布置)的指南，类似地，软件的设计模型提供了计算机程序的一系列不同视图。
基本的设计原则使软件工程师能够为设计过程导航。
1.设计过程不应该受“隧道视野”的限制。一名好的设计者应该考虑替代的手段，根据问题的要求，可用13.4节提到的设计概念来判断完成工作的资源。
2.设计对于分析模型应该是可跟踪的。因为设计模型的单独一个元素经常会跟踪到多个需求上，所以对设计模型如何满足需求进行的追踪是必要的。
3.设计不应该从头做起。系统是使用一系列设计模式构造的，很多模式很可能在以前就遇到过。这些模式通常被称为可复用设计构件，应该总是作为一切都从头开始的方法的一种替代选择。时间短暂而资源有限！设计时间应该投入到表示真正的新思想和集成那些已有模式上去。
4.设计应该缩短软件和现实世界中问题的“智力距离”。也就是说，软件设计的结构应该(尽可能)模拟问题域的结构。
5.设计应该表现出一致性和集成性。如果一项设计整体上看上去象是一个人完成的，那它就是一致的。在设计工作开始之前，设计小组应该定义风格和格式的规则，如果注意定义了设计构件之间的接口，那么，设计就是集成的。
6.设计应该构造以适应修改。
7.设计应该构造以使得即使遇到异常的数据、事件或操作条件时也能够平滑、轻巧地降级。设计良好的计算机程序应该从不“彻底崩溃”，它应该设计为适应异常的条件，并且即使它必须中止处理时，也要采用优雅的方式。
8.设计不是编码，编码也不是设计。即使在为程序构件构造详细的过程设计时，设计模型的抽象级别也比源代码要高，在编码级别上作出的唯一设计决策是描述能使过程性设计被编码的小的实现细节。
9.在创建设计时就应该能够评估质量，而不是在事情完成之后。有许多设计概念和设计方法可以帮助设计者评估质量。
10.应该复审设计以减少概念性(语义性)错误。有时人们在复审设计中倾向于注重细节，只见树木不见森林。在关注设计模型的语法之前，设计者应该确保已经检查过设计的主要概念性元素(忽略、含糊性、不一致性)。
正确应用上述设计原则时，软件工程师创建的设计就会展现出外部和内部的质量因素。外部质量因素是那些用户能轻易观察到的软件特性(例如，速度、可靠性、正确性、可用性)；内部质量因素对软件工程师是重要的，它们能导致技术角度上的高质量设计。要取得内部质量因素，设计者必须理解基本的设计概念。
设计步骤
抽象：
当我们考虑任何问题的模块化解决方案时，可以给出许多抽象级别。在最高的抽象级别中，解决方案使用问题环境的语言来进行概括性的术语描述，在低一些的抽象级别中，会有更加面向过程的倾向。为了描述解决方案，要一同使用面向问题的术语和面向实现的术语，最后，在最低的抽象级别中，用能够直接实现的方式描述解决方案。
求精：
逐步求精是一种自顶向下设计策略，程序的体系结构是通过过程细节的逐步层次精化开发的，层次结构通过逐步地分解功能的宏观声明，直至形成程序设计语言的语句而开发出来。
在(求精的)每一步中，给定程序的一条或几条指令被分解成更详细的指令，这种连续的对规约的分解或求精，直至所有指令都用某种底层的计算机或程序设计语言表达时才中止…。当任务被精化时，数据可能也要被精化、分解或结构化，而且，并行地精化程序和数据规约是很自然的。
求精实际上是一个推敲的过程。我们从高抽象级别定义的功能描述(或信息描述)开始，也就是说，该描述概念性地说明了功能或信息，但没有提供有关功能内部工作的情况或信息的内部结构。求精使设计者去推敲原始声明，并在后续的求精(推敲)活动中提供越来越多的细节。
模块化：
计算机软件的模块化概念已经被采纳了将近四十年，软件体系结构体现了模块化；即软件被划分成独立命名和可独立访问的被称作模块的构件，它们集成到一起满足问题需求。
有人提出“模块化是软件的单个属性，它使程序能被理性地管理”。读者无法简单地掌握单块集成电路式的软件(例如，由单一模块构成的大程序)，控制路径的数量、引用的跨度、变量的数量和整体的复杂性会使对软件的理解接近于不可能。为说明这一点，考虑下面的论据，它们是基于对人解决问题的观察而提出的。
结构划分：
程序结构应该被水平和垂直地划分.
水平划分为每个主要程序功能定义了分离的模块结构分支，控制模块被用来协调程序功能之间的通讯和运行。水平划分的最简单方法定义了三个划分—输入、数据变换(通常称作处理)和输出。对体系结构进行水平划分获得有关她的许多特殊的优点：
1.产生易于测试的软件。
2.产生易于维护的软件。
3.产生副作用更小的传播。
4.产生易于扩展的软件。
由于主要的功能相互分离，修改变得更加简单，对系统的扩展(常见情况)往往变得更加容易完成，且没有副作用。从消极的方面看，水平划分常常通过模块接口传递更多的数据，因而可能会使程序流的整体控制复杂化(如果处理需要从一个功能快速移动到另一个功能)。
垂直划分，常常称作因子划分，要求发生在程序体系结构中(决策)，且工作应该自顶向下分布，顶层模块应该执行控制功能，而少作实际处理工作，在层次结构中位于低层的模块应该是工作者，它们完成所有的输入、计算和输出任务。
软件系统的开发包括一系列生产活动，其中由人带来的错误因素非常多。错误可能出现在程序的最初…，其时目标可能是错误的或描述不完整，也可能在后期的设计和开发阶段…，因为人们不能完好无缺地工作和交流，软件开发过程中必须伴有质量保证活动。
软件测试是软件质量保证的关键元素，代表了规约、设计和编码的最终检查。
测试为软件工程师带来了很有趣的意外。在软件过程的早期，软件工程师试图由抽象概念到具体实现来建立软件，现在来了测试，工程师创建测试用例试图“摧毁”已经建立的软件。事实上，在软件工程过程中，测试可以看成(至少心理上)摧毁性的而不是建设性的。
软件测试的具体内容在相关的章节另外进行描述。
部署是软件开发结束后交付用户使用的一项工作。一般可以由开发者制作安装程序直接交付客户，由客户自行安装。还可以由开发人员上门进行软件的安装与调试后，达到可以使用的目的。另外部署的方式还可以分为本地和远程两种。
一些学者将软件维护划分为主要的三类：纠错性维护（Corrective maintenance）、适应性维护（Adaptive maintenance）和完善性维护（Perfective maintenance）：
1.纠错性维护。
由于前期的测试不可能揭露软件系统中所有替在的错误，用户在使用软件时仍将会遇到错误，诊断和改正这些错误的过程称为纠错性维护。
2.适应性维护。
由于新的硬件设备不断推出，操作系统和编译系统也不断地升级，为了使软件能适应新的环境而引起的程序修改和扩充活动称为适应性维护。
3.完善性维护。
在软件的正常使用过程中，用户还会不断提出新的需求。为了满足用户新的需求而增加软件功能的活动称为完善性维护。
有效的项目管理集中于三个P上：人员（people）、问题（problem）和过程（process）。
人员
软件项目的参与者：
1.高级管理者：负责确定商业问题，这些问题往往对项目产生很大影响。
2.项目(技术)管理者：必须计划、刺激、组织和控制软件开发人员。
3.开发人员：负责开发一个产品或应用软件所需的专门技术人员。
4.客户：负责说明待开发软件的需求的人员。
5.最终用户：一旦软件发布成为产品，最终用户是直接与软件进行交互的人。
问题
在进行项目计划之前，应该首先明确该项目的目的和范围，考虑可选的解决方案，定义技术和管理的约束。没有这些信息，就不可能进行合理的(准确的)成本估算；有效的风险评估；适当的项目任务划分；或是给出了意义明确的项目进度的标志的项目管理计划。
软件开发者和用户必须一起定义项目的目的和范围。在很多情况下，这项活动是作为系统工程的一部分开始的，持续到作为软件需求分析的第一步。目的说明该项目的总体目标，而不考虑这些目标如何实现。范围说明给出与问题相关的主要数据、功能和行为，更为重要的是，它以量化的方式约束了这些特性。
一旦了解了项目的目的和范围，就要开始考虑可选的解决方案了。虽然这一步并不讨论细节，但它使得管理者和开发者可以选择一条“最好的”途径，并根据产品交付的期限、预算的限制、可用的人员、技术接口及各种其他因素，给出项目的约束。
过程
软件过程提供了一个框架，在该框架下可以建立一个软件开发的综合计划。若干框架活动适用于所有软件项目，而不在乎其规模和复杂性。若干不同的任务集合——每一个集合都由任务、里程碑、交付物以及质量保证点组成——使得框架活动适应于不同软件项目的特征和项目组的需求。最后是保护性活动——如软件质量保证，软件配置管理，和测度——它们贯穿于整个过程模型之中。保护性活动独立于任何一个框架活动，且贯穿于整个过程之中。