1.3信息系统基础-软件工程知识
软件工程的6个阶段
一，项目计划阶段。（也可以说是可行性分析阶段）
确定了一个软件以目前的条件可以完成，主要是经济，技术和社会条件，撰写可行性分析报告。需求方和开发方共同探讨项目中的问题的解决方案；需要的资金，人力，物力；社会方面的影响，例如是否符合法律等；对项目的进度和预期效益进行估计。
二，项目需求分析阶段。
对用户需求进行分析。将用户的需求用逻辑的软件工程语言表达出来，设计好功能和数据库模型，编写成软件需求设计书。这个阶段要注意的是行业的术语以及行业规则，开发的软件难免遇到不同行业，我们不是那个行业里面的人，所以对用户所在行业的需求分析的时候要正确理解他们的术语和规则。当需求得到用户确认后记得让用户签字。最后提醒一点，需求的变更在项目中很频繁，必须做好需求变更计划用以项目正常进行。
三，项目设计阶段。
概要设计就是设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每个模块的功能等等。同时，还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。
详细设计阶段就是为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。 概要设计阶段通常得到软件结构图。 详细设计阶段常用的描述方式有：流程图、N-S图、PAD图、伪代码等。
四，编码阶段。
为程序员分配好编码任务，将软件的设计具体为软件代码。这里注意的是编码语言，工具，环境和编码规范。统一，标准的编码规范可让程序可读和易维护。
五，软件测试阶段。
软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出
现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。
测试，目的是以较小的代价发现尽可能多的错误。要实现这个目标的关键在于设计一套出色的测试用例。如何才能设计出一套出色的测试用例，关键在于理解测试方法。不同的测试方法有不同的测试用例设计方法。两种常用的测试方法是白盒法测试对象是源程序，依据的是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。结构错误包括逻辑、数据流、初始化等错误。用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。白盒法和黑盒法依据的是软件的功能或软件行为描述，发现软件的接口、功能和结构错误。其中接口错误包括内部/外部接口、资源管理、集成化以及系统错误。
六，维护阶段。
对软件正式交付使用过程中出现的软件的bug进行修复，调整软件以适应正式环境，编写软件的维护报告。
1、软件需求分析与定义
(软件工程书)
2、软件设计、测试与维护
概要设计就是设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每个模块的功能等等。同时，还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。
详细设计阶段就是为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。 概要设计阶段通常得到软件结构图。 详细设计阶段常用的描述方式有：流程图、N-S图、PAD图、伪代码等。
软件测试
在软件开发的一列活动中，为了保证软件的可靠性，人们研究并使用了很多方法进行分析、设计及编码实现。但是由于软件产品本身无形态，它是复杂的、知识高度密集的逻辑产品，其中不可能没有错误。物理产品在出厂前都要进行严格的检验，软件产品也不例外。软件开发总伴随着软件质量保证的活动，而软件测试是主要活动之一。软件测试代表了需求分析、设计、编码的最终复审。
测试是一项很艰苦的工作，其工作量约占软件开发总工作量的40%以上，特别对一些关系到人的生命安全的软件，共测试成本可能相当于开发阶段总成本的3～5倍。
测试用例
要进行测试，除了要有测试数据（或称输入数据）外，还应同时给出该组测试数据应该得以怎样的输出结果，我们称它为预期结果。在测试时将实际的输出结果与预期结果比较，若不同则表示发现了错误，因此测试用例是由测试数据和预期结果构成的。
为了发现程序中的错误，应竭力设计能暴露错误的测试用例。一个好的测试用例是极有可能发现迄今为止尚未发现的错误的测试用例。一次成功的测试是发现了至今为止尚未发现的错误的测试。
3.测试的原则
基于上述测试目的，我们可以考虑以下有关测试的原则:
（1）确定预期输出结果是测试用例必不可少的一部分。如果只有测试数据而无预期结果，那么就不易判断测试结果是否正确。
（2）程序员应避免测试自己的程序，程序设计机构不应测试自己的程序。这是因为程序中的错误往往是由于程序员对问题说明的误解，由他来测试自己的程序就不易找出因这种误解而产生的错误。此外，开发程序是一项建设性的工作，而测试则是一项破坏性的工作（证明程序有错），这对开发人员或机构来说在心理上是难以容忍的。为了证明自己的程序没有错误或错误很少，他们往往不去选择容易发现错误的测试用例，而选择容易通过的测试用例。当然，这并不意味着程序员都不能测试自己的程序，如单元测试通常就是由程序员自己测试的。
（3）彻底检查每个测试结果。如果不仔细检查测试结果，有些已经测试出来的错误也可能被遗漏掉。
（4）对非法的非预期的输入数据也要像合法的和预期的输入数据一样编写测试用例。
（5）检查程序是否做了应做的事是成功的一半，另一半是看程序是否做了不该做的事。
（6）除了真正没有用的程序外，一定不要扔掉测试用例。因为在改正错误或程序维护后还要进行重新测试。
（7）在规划测试时不要设想程序中不会查出错误。
（8）程序模块经测试后，残存的错误数目往往与已发现的错误数目成比例。实践证明，程序中的大量错误仅与少量的程序模块有关，因此当A模块找出的错误比B模块多得多时，很可能A模块残存的错误仍比B模块残存的错误多多。
白盒测试和黑盒测试
测试的关键是测试用例的设计，其方法可分成两类:白盒测试和黑盒测试。
白盒测试是把程序看成装在一只透明的白盒子里，测试者完全了解程序结构和处理过程。它根据程序的内部逻辑来设计测试用例，检查程序中的逻辑通路是否都按预定的要求正确地工作。黑盒测试是把程序看成一只黑盒子，测试者完全不了解（或不考虑）程序的结构和处理过程。它根据规格说明书规定的功能来设计测试用例，检查程序的功能是否符合规格说明的要求。
测试步骤
软件测试的主要步骤有单元测试、集成测试和确认测试。
1.单元测试（unit testing）
单元测试也称模块测试。通常单元测试可放在编码阶段，程序员在编写好一个模块后，总会（也应该）对自己编写的模块进行测试，检查它是否实现了详细设计说明书中规定的模块功能和算法。单元测试主要发现编码和详细设计中产生的错误，通常采用白盒测试。
测试一个模块时需要编写一个驱动模块和若干个桩（stub）模块，如下图所示。驱动模块的功能是向被测试模块提供测试数据，驱动（即调用）被测模块，并从被测模块中接受测试结果。桩模块的功能是模拟被模块所调用的子模块，它接受被测模块的调用，检验调用参数，模拟被
调用的子模块功能，把结果送回给被测模块。在模块结构图中，顶层模块测试时不需要驱动模块，最底层的模块测试时不需要桩模块。
2.集成测试（integration testing）
集成测试也称组装测试，它是对由各模块组装而成的程序进行测试，主要检查模块间的接口和通信。集成测试主要发现设计阶段产生的错误，通常采用黑盒测试。
集成的方式可分成非渐增式集成和渐增式集成。非渐增式集成是先测试所有的模块，然后把这些模块集成在一起对整个程序进行测试。渐增式集成是将单元测试和集成测试合并在一起，它根据模块结构图，按某种次序选一个尚未测试的模块，把它同已经测试好的模块组合在一起对整个程序进行测试，每次增加一个模块，直至所有模块全部集成在程序中。
渐增式集成又可分成自顶向下集成和自底向上集成。自顶向下集成先测试上层模块，再测试下层模块。由于测试下层模块时它的上层模块已测试过，所以可以用其上层模块作为它的驱动模块，而不必另编驱动模块。自底向上集成先测试下层模块，再测试上层模块。同样道理，在自底向上集成时可用下层模块作为上层模块的桩模块，而不必另外编写桩模块。
3.确认测试（walidation testing）
确认测试的任务是检查软件的功能、性能及其他特征是否与用户的需求一致，它是以需求规格说明书（即需求规约）作为依据的测试。确认测试通常采用黑盒测试。
确认测试首先测试程序是否满足需求规格说明书所列的各项要求，然后要进行软件配置复查，特别是文档是否齐全，各方面的质量是否符合要求等。如果一个软件是为某个客户定制的，那么最后由客户来实施验收测试（acceptance testing），以便客户确认该软件是否他所需要的。如果一个软件是作为产品被许多客户使用的话，那不可能为每个客户进行验收测试。大多数软件生产者使用一种Alpha测试和Beta测试的过程，来揭露仅由最终用户才能发现的错误。
Alpha测试是在开发者的现场由客户来实施的，被测试的软件是在开发者从用户的角度进行常规设置的环境下运行的。Beta测试是在一个或多个客户的现场由该软件的最终用户实施的。与Alpha测试不同的是，Beta测试时开发者通常是不在场的。Alpha测试和Beta测试除了进一步发现程序中的错误外，还能发现使用上的问题。经过确认测试后的软件通常就可交付使用了。
在软件开发完成交付用户使用后，就进入了软件运行/维护阶段。为了保证软件在一个相当长的时期能够正常运行，对软件的维护就成为必不可少的工作了。
- 可理解性
- 可测试性
- 可修改性
- 可移植性
- 编码副作用
- 数据副作用
- 文档副作用
一、软件维护基础知识
维护包括软件交付后对软件的修改（更多是对软件的扩展，而不仅仅是改正错误），维护是改正错误、改善性能或者使产品适应已改变的环境，软件维护阶段开始于初次交付软件系统或组件之后。
主要的维护目标：尽可能长时间地使用软件。
良好软件开发的目标：
a) 在软件交付时，应满足隐含的和直接的需求
b) 如果需求改变，软件必须容易修改
维护阶段本身包括所有软件开发活动（需求分析、系统设计、编码、测试、实施、维护），所创建的软件是本阶段（以及其中各次要阶段）的输入；因为修改软件时必须考虑现有需求，这是一个约束。
维护原因：
a) 改正错误
b) 改正设计缺陷
c) 与其他系统接口
d) 进行扩展
e) 对系统进行必要的变更
f) 变更文件或数据库
g) 改进设计
h) 转换程序，以便能够并入不同的硬件、软件和系统工具软件
维护集中在软件的4个主要方面：
a) 管理系统的日常功能
b) 管理系统的修改
c) 完善现有功能
d) 保持或者提高系统的性能
维护是演化式开发；在演化过程中，系统变得越来越复杂，维护活动也将持续进行。
首先应该思考维护计划，然后设计和开发计划。
考虑维护概念时，要考虑的方面是：
a) 维护的范围是什么？
b) 在交付后的过程中应做那些适应性修改？
c) 谁将提供维护？
d) 生命周期的成本是什么？
二、维护的类别：
改变性：查找和修改用户反馈的缺陷。
适应性：修改应用程序，使其符合外部环境的变化。
完善性：改善软件，以提高性能和可维护性。
三、维护活动
分析：
通常不是开发人员，因此不能充分理解代码的复杂性。
分析可用的工具有：
a) 程序分析工具
b) 软件理解技术
c) 逆向工程工具
d) 软件可视化工具
e) 软件影响分析工具
设计：
维护阶段的设计较受限制，因为设计人员必须受现有系统设计的限制，在当前设计中实现新的需求，软件再造工程指重新设计现有软件，使它能够在满足所有需求的同时，得到很好的维护。
可用的工具：
a) 结构重整工具
b) 单元重构工具
c) 对象恢复工具
编码：
可用工具：
a) 反编译器
b) 翻译工具
测试：
维护阶段只修改了一些组件或软件系统的一部分，通常只测试该部分以及受变更影响的部分。
可用的工具：
a) 比较工具
b) 回归测试工具
部署：
维护完成之后的软件部署与软件开发阶段的部署相同。
可用的工具：
a) 变更管理工具和问题报告、跟踪工具用于报告软件的问题和请求变更。
b) 配置工具
c) 构建管理工具
d) 发行管理工具
其他维护活动：
维护人员从事的与软件开发无关的其他活动（除了支持活动之外）：
a) 配置管理
b) 确认和验证
c) 质量保证
d) 审查
e) 审计
f) 用户培训
维护还包括系统的计划、移植和淘汰。
四、维护过程
应将所有软件构建为“可维护“----易于扩展、改编或改正。
维护工程模型使维护工程标准化：
维护=>分类和标识（检查是要求增加新功能还是修改现有功能）=>分析=>设计=>实施=>系统测试=>验收测试=>交付
五、软件维护问题
a) 多版本
b) 在结构时就遗留下来的问题
c) 有40%-60%的时间用于理解软件
d) 人员配备----争取获得所需要的人力资源
对软件进行反复测试的版本在时间和金钱上都很昂贵；需要完成对已修改的组件的测试—比较难。
六、维护成本
由于系统维护问题，所以维护成本很高，维护成本的高低取决于进行的维护类别，一轮维护过后的维护会更加困难（而且成本增高）。
在20世纪80年代中期以前，大部分的成本用于软件开发；在此之后，维护占用了最大的成本。
维护成本的非技术因素：
a) 团队稳定性
b) 契约责任
c) 员工技能
估计维护成本：将历史数据和经验结合起来。
影响维护成本的技术因素：
a) 软件对运行环境的依赖性
b) 编程风格
c) 测试与改错工作
d) 文档的质量
e) 编程语言
七、再造工程
对系统进行重新改造，重构建现有软件，可能更加耗费资源、需要更长时间。如果把维护比作“修修补补”，那么再造工程就算是“痛改前非”。再造工程并不见得一定比维护的代价要高，但再造工程在将来的利益却要比通过维护得到的多。
再造工程的3种类型：
a) 重构----改造类和算法。
b) 逆向工程----从代码中抽取设计信息（体系结构等），用于理解程序。
c) 前向工程----预防性维护，如同打“预防针”。
八、程序理解工具
根据Hamlen的报告，用于扩展和改错的时间分别是47%和62%，其余的时间都用于阅读文档、扫描代码和理解的变更。
a) 编译器：编译器理解程序，以便将程序翻译为底层机器的语言。
b) 重构器和美化器：通过使相关代码片段局部化和建议更高抽象层次，帮助改善程序的可理解性。
c) 翻译器、向量器和并行器：翻译器是语言对语言的翻译器。向量器和并行器负责产生有效且容易理解的代码。
d) CASE工具：计算机辅助软件工程（CASE）工具提供于制作高层次设计的图形编辑器、用于侦探问题的一致性检查器。
九、总结
维护是软件开发生命周期中重要阶段。
范围：
a) 更新的GUI
b) 扩展了的功能
c) 新的硬件和软件可兼容
d) 旧功能可兼容（DLL、COM、COM+）
软件维护可以定义为：在交付使用之后，对软件产品进行修改，以改正错误、改进性能或者使产品适应以改变的环境。
在软件生命周期中，向用户初次交付软件系统之后就开始了软件维护阶段。
维护有3个类别：
a) 改正性维护：在交付之后，对软件产品进行的响应式修改，以改正发生的错误。
b) 适应性维护：在交付之后，对软件产品进行的修改，以便使计算机在正在变化的或已经变化的环境中继续能够使用。
c) 完善性维护：在交付之后，为改进性能和可维护性而对软件产品进行的修改。
不同的维护活动有：分析、设计、编码、测试和编写文档。
软件维护提出技术和管理上的问题，如有限的理解、重测试、人员配备或获取资源。
维护成本的高低取决于进行的维护类别。
软件再造工程改善了对软件的理解和软件的可重用性和适应性。
程序理解是获得对计算机程序的了解的过程，以便能够进行错误改正、扩展、重用和编写文档等活动。
4.5.1 软件复用的概念
软件复用就是将已有的软件成分用于构造新的软件系统。
从上述定义中，我们知道软件复用是指在构造新系统时使用已有的软件成分，而不是说在一个系统中多次使用一个相同的软件成分，这种情况称为共享。在这里，可被复用的软件成分被称为可复用构件，它可以是从已有软件中提取的，也可以是为了复用而专门开发的。
软件复用不仅仅局限于对程序的复用，它包括对软件开发过程中任何活动产生结果的复用，如项目计划、成本估计、体系结构、需求规格说明、分析模型、设计模型、源程序、技术文档、用户界面、数据结构、测试用例等。
按照抽象程度的高低，软件复用可以分成以下类型：
（1） 程序代码的复用
程序代码的复用包括目标代码和源代码的复用。目标代码复用的早期例子是子程序库的使用，当前大部分编程语言的运行支持系统都提供了连接、绑定等功能来支持这种复用。近年来，一些新技术将程序复用推进到一个新的水平，如OLE技术等，既支持在源程序级定义构件并用以构造新的系统，又使这些构件在目标代码级上仍然是一些独立的可复用构件。
（2） 设计结果的复用
设计结果的复用比源程序的抽象级别更高，一是从现有系统的设计结果中提取一些可复用的设计构件，将其应用于新系统的设计；二是将一个现有系统的全部设计文档在新的软硬件平台上重新实现，即将一个设计运用于多个具体的实现；三是独立于任何具体应用，有计划地开发一些可复用的设计构件。
（3） 分析结果的复用
可复用的分析构件是针对问题域的某些事物或某些问题的抽象程度更高的复用，一是从现有系统的分析结果中提取一些可复用构件用于新系统的分析；二是用一份完整的分析文档在不同的软硬件平台上产生多个设计；三是独立于具体应用，专门开发一些可复用的分析构件。
（4） 测试信息的复用
测试信息的复用主要包括测试用例的复用和测试过程信息的复用，即将一个软件的测试用例在新的软件测试中使用，或者在测试过程中通过软件工具自动地记录测试的过程信息。
一个软件构件只有在多个系统中被使用才能真正称得上是"可复用构件"，因此可复用构件应该具备以下条件：
（1） 独立性
一个可复用构件应该解决一个相对独立的问题，后者解决一个大问题中某个相对独立的饿部分，构件对外的联系或接口应尽可能地少。
（2） 完整性
构件应该对某个问题或者一个问题的某个局部提供完整的解决，不要遗留许多缺口，让复用者做大量的补充。
（3） 可标识性
构件所解决的问题是可以标识的，即可以明确构件到底是解决什么问题的。
（4） 一般性
构件所解决的问题，应该在同类应用中具有一般性。
（5） 适应性
构件的设计应该追求较高的适应性。
（6） 可靠性
可复用构件的可靠性比普通软件有更高的要求，不仅要求它对目前正在使用它的系统可靠，而且要求它对预计将要使用它的系统也是可靠的。
（7） 标准化
标准化对于软件复用是至关重要的，因此，可复用构件必须符合一定的标准，否则将很难在新的系统中被复用。
软件质量保证及质量评价
软件需求定义了软件质量特性，并影响评价这些特性的度量方法和接收准则。
应在软件过程、产品和资源的各个方面进行软件质量管理，软件质量管理过程由许多活动组成，一些活动可直接发现缺陷，其他活动则指出深入的检查是否有价值，前者也称为直接缺陷发现活动，许多活动都可以达到这两个目的。
软件质量管理过程包括：质量保证过程、验证过程、确认过程、评审过程、审计过程等。
1.软件质量保证
软件质量保证过程通过计划制订、实施和完成一组活动提供保证，这些活动保证项目生命周期中的软件产品和过程符合其规定的需求。
软件质量保证计划定义了用于保证为特定产品开发的软件满足用户需求并在项目的约束内具有最高的质量的手段。
2.验证与确认
验证与确认过程使用能够定位缺陷并便于以后改正的测试技术直接处理软件产品质量问题。
验证与确认过程确定某一开发和维护括动的产品是否符合活动的需求，尾终的软件产品是否达到其意图并满足用户需求。验证过程试图确保活动的输出产品已经被正确制造，即活动的输出产品满足前面活动施加的规范说明；确认过程则试图确保建造了正确的产品，即产品满足其特定的目的。
3.评审与审计
评审与审计过程包括：管理评审、技术评审、检查、走查、审计等。
管理评审的目的是监控进展，决定计划和进度的状态，确认需求及其系统分配，或评价用于达到目标适应性的管理方法的有效性。它们支持有关软件项目期间需求的变更和其他变更活动。
技术评审的目的是评价软件产品。以确定其对使用意图的适合性，目标是识别规范说明和标准的差异，并向管理提供证据，以表明产品是否满足规范说明并遵从标准，而且可以控制变更。
检查的目的是检测和识别软件产品异常。一次检查通常针对产品的一个相对小的部分。发现的任何异常都要记录到文档中，并提交。
走查的目的是评价软件产品，走查也可以用于培训软件产品的听众，主要目标是：发现异常、改进软件产品、寿虑其他实现、评价是否遵从标准和规范说明。走查类似于检查，但通常不那么正式。走查通常主要由同事评审其工作，以作为一种保障技术。
软件审计的目的是提供软件产品和过程对于可应用的规则、标准、指南、计划和流程的遵从性的独立评价。审计是正式组织的活动，识别违例情况，并产生一个报告，采取更正性行动。
软件配置管理
软件配置管理是有益于项目管理、开发和维护活动。软件配置管理与软件质量保证活动密切相关，软件配置管理活动可以帮助达成软件质量保证目标。
软件配置管理活动有；软件配置管理过程的管理和计划、软件配置标识、软件配置控制、软件配置状态记录、软件配置审计、软件发布管理与交付。
l、软件配置管理过程的管理和计划
软件配置管理通过标识产品的元素、管理和控制变更、验证、记录和报告配置信息，来控制产品的进化和完整性。为了给项目的软件配置管理制订计划，有必要理解组织结构上下文环境和组织的元素之间的联系。软件配置管理在记录管理和非遵从项（non-conforming）等问题上，可能与组织的质量保证活动交互。软件配置管理也许与软件开发和维护组织的联系最紧密。正是在这个上下文环境中，需要进行许多软件配置控制任务。通常，同样的工具可以支持开发、维护和软件配置管理。
2、软件配置标识
软件配置标识活动标识要控制的项，为这些项及其版本建立标识模式，安装获取和管理受控项时使用的工具。这些活动为其他软件配置管理活动提供了基础。控制变更的第一步就是标识要控制的软件项，这涉及理解在系统配置上下文环境中的软件配置、选择软件配置项、开发为软件项加标签并描述它们之间关系的策略、标识要使用的基线以及获取基线的项的流程。
3、软件配置控制
软件配置控制关注管理软件生命周期中的变更，它覆盖确定要作什么样的变更的过程、批准某些变更的权力职权、支持这些变更的实现，以及与项目需求偏离和放弃这些偏离的概念。
4、软件配置状态记录
软件配置状态记录要记录和报告进行有效的软件配置管理需要的信息。软件配置状态记录活动为在生命周期中捕获和报告必要的信息设计和运行一个系统，同任何信息系统一样，必须标识、收集和维持为进化中的配置要管理的配置状态信息。
软件开发环境
软件开发工具是用于辅助软件生命周期过程的基于计算机的工具。通常可以设计并实现工具来支持特定的软件工程方法，减少手工方式管理的负担。与软件工程方法一样，它们试图让软件工程更加系统化，工具的种类包括支持单个任务的工具及囊括整个生命周期的工具。
1.软件需求工具
软件需求工具包括需求建模工具和需求追踪工具。
2.软件设计工具
软件设计工具用于创建和检查软件设计，因为软件设计方法的多样性，这类工具的种类很多。
3.软件构造工具
软件构造工具包括程序编辑器。
4.软件测试工具
软件测试工具包括测试生成器、能分析工具。
编译器和代码生成器、解释器、调试器等。
测试执行框架、测试评价工具、测试管理工具等。
5.软件维护工具
软件维护工具包括理解工具（如可视化工具）和再造工具（如重构工具）。
6.软件配置管理工具
软件配置管理工具包括追踪工具、版本管理工具和发布工具。
7.软件工程管理工具
软件工程管理工具包括项目计划与追踪工具、风险管理工具和度量工具。
8.软件工程过程工具
软件工程过程工具包括建模工具、管理工具、软件开发环境。
9.软件质量工具
软件质量工具包括检查工具和分析工具。
软件过程管理
软件工程管理集成了过程管理和项目管理，包括以下6个方面。
1.启动和范围定义
进行启动软件工程项目的活动并作出决定。通过各种方法来有效地确定软件需求，并从不同的角度评估项目的可行性。一旦可行性建立后，余下的任务就是需求验证和变更流程的规范说明。
2.软件项目计划
从管理的角度，进行为成功的软件工程作准备而要采取的活动。使用迭代方式制订计划。要点在于评价并确定适当的软件生命周期过程，并完成相关的工作。
3.软件项目实施
进行软件工程过程中发生的各种软件工程管理活动。实施项目计划，最重要的是遵循计划，井完成相关的工作。
4.评审和评价
进行确认软件是否得到满足的验证活动。
5.关闭
进行软件工程项目完成后的活动。在这一阶段，重新审查项目成功的准则。一旦关闭成立，进行归档、事后分析和过程改进活动。
6.软件工程度量
进行在软件工程组织中有效地开发和实现度量的程序。
