软件开发模型：
（1） 瀑布模型:waterfall model以软件需求完全确定为前提；“软件生存周期模型”
（2） 原型模型：prototype在软件开发初期阶段只能提供基本需求时采用的渐进方式的开发模型
（3） 螺旋模型：spiral model , 是TRW的 B.Boehm于1988年提出。是waterfall and prototypeModels
的结合。 新提出了风险分析。需求定义；风险分析；工程实现；评审；迭代结果必须尽快收敛到客户允许的或者可以接收的目标范围内。适用于面向规格说明、面向过程、面向对象的软件开发方法，也适用于几种开发方法的组合。
（4） 基于4代技术的模型
（5） 变换模型
（6） 组合模型
软件开发模型给出了软件开发过程中各个阶段之间的关系。
以形式化开发方法为基础的变换模型。
（1） 软件定义：基本任务是确定软件系统的工程需求。分为：软件系统的可行性研究和需求分析两个阶段；
- 软件系统的可行性研究：了解用户的要求和现实环境，从技术、经济和社会等几个方面研究并论证软件系统的可行性。可行性论证包括：技术可行性（当前的技术和工具能否支持实现需求）、操作可行性（用户可否在特定的环境中使用这个软件）、经济可行性（成本问题）；在对软件系统进行调研和可行性论证的基础上还要制定初步的项目开发计划，包括选用资源，定义任务，风险分析，成本估算，成本效益分析，以及进度安排。项目计划应有明确的可供检查的里程碑和检查规范。
- 需求分析：
- 任务：确定待开发软件的功能需求、性能需求和运行环境约束，编写软件需求规格说明、软件系统的验收测试准则和用户手册概要。软件的功能需求应该指明软件必须完成的功能。软件的性能需求包括：软件的安全性、可靠性、可维护性、精度、错误处理、适应性、培训等。
- 需求分析的一项重要任务是建立面向开发者的软件需求规格说明。Software requirement specification
(SRS)应该指明软件系统的功能需求、性能需求、接口需求、设计需求、基本结构、以及开发标准和验收标准。
（2） 软件开发：按照需求规格说明的要求，从抽象到具体，逐步生成软件的过程。
- 概要设计：根据软件需求规格说明建立软件系统的总体结构和模块间的关系，定义各功能模块的接口，设计全局数据库或者数据结构，规定设计约束，制定集成测试计划。概要设计阶段应该提供每个功能模块的功能描述、全局数据定义、外部文件定义。
- 功能模块之间的比较低的耦合度；
- 功能模块内部有较高的内聚度；
- 通常软件系统的设计采用层次结构并用结构图表示。结构图中的节点代表功能模块。
- 概要设计应该提供概要设计说明书、数据库、或者数据结构设计说明书、组装测试计划等文件。
- 详细设计：对概要设计产生的功能模块进一步细化，形成若干个可编程的程序模块，用某种过程设计语言设计程序模块的内部细节，包括算法、数据结构、各程序模块之间的详细接口信息，为编写源代码提供必要的说明。拟定模块测试方案；
- 伪代码；
- Ada
- 结构化英语
- &nb
- 设计应该与软件需求保持一致；
- 软件结构应该能够支持模块化、信息隐藏（低耦合，高内聚）；
- 实现：根据详细设计文档将详细设计转化所要求的程序。
- 集成测试
- 验收测试
（3） 软件使用和维护：发挥社会和经济效益的重要阶段J.
问题分析：
需求描述：以需求模型为基础，考虑到问题的软件可解性，生成需求规格说明和初步的用户手册。需求规格说明包含对目标软件系统的外部行为的完整描述、需求验证标准、以及用户在性能、质量、可维护性等方面的要求。
用户手册包括用户界面描述以及有关目标软件使用方法的构想。
需求评审：分析人员和用户、开发人员一起对需求规格说明和初步的用户手册进行复核。
问题抽象、问题分解、多视点分析：
首先关注一般问题的解决途径，然后指导特殊问题的求解；
注意用户描述所处的不同抽象级别；
问题分解的原则：各个子问题具有较强的独立性，子问题之间具有松耦合性。
需求分析阶段可以使用的视点：系统观点，用户观点，信息观点；功能观点；行为观点等；
在结束需求分析阶段之前，必须形成需求规格说明书。
需求规格说明书：（1）便于用户、分析人员和软件设计人员进行理解和交流；（2）支持目标软件系统的确认：开发目标是否完成不应该由系统测试阶段的人为因素决定，而应该根据需求规格说明书中确立的可测试标准决定。因此，需求规格说明书中的各项需求都应该是可测试的；（3）控制系统进化过程。
需求规格说明书：
- 功能与行为需求描述：描述说明系统的输入、输出及其相互关系，
- 非行为需求描述：软件系统在工作的时候需要具备的各种属性，例如效率、可靠性、安全性、可维护性、可移植性等。
需求评审：
在将需求规格说明书提交给设计阶段之前，必须进行需求评审。
如果在平审过程中发现说明书存在错误或者缺陷，应及时修改。重新进行相应部分的初步需求分析、需求建模、修改需求规格说明书、并再次评审。
（1） 正确性：需求规格说明书中的功能，行为，性能描述必须和用户对目标软件的期望吻合；
（2） 无歧义性：任何语法单位只能有唯一的语义解释；使用标准化术语，并对术语进行显式的、统一的解释。
（3） 完全性：不能遗漏任何用户需求。
（4） 可验证性：存在技术和经济上的可行手段进行验证和确认；
（5） 一致性：各个部分保持一致。
（6） 可理解性：对于非专业用户，少用太专业的词语；
（7） 可修改性；
（8） 可追踪性；
需求评审一般以用户、分析人员、和系统设计人员共同参与的会议形式进行。分析人员要说明软件产品的总体目标，包括产品的主要功能、与环境的交互行为以及其他性能指标。
然后需求评审会议对说明书的核心部分-需求模型进行评估，讨论需求模型以及说明书的其他部分是否具备良好的属性品质，进而决定该说明书是否构成良好的软件设计基础。
然后，评审会议还要讨论出其他的解决方案，并对各种影响软件设计和软件质量的因素进行折中，决定说明书中采用的 取舍是否合理。
最后，评审会议对软件的质量确认方法进行讨论，最终形成用户和开发人员都能够接受的各项测试指标。
数据流图是用来刻画数据流和转换的信息系统建模技术。用简单的图形记号分别表示数据流、转换、数据源以及外部实体。
提供层次结构让分析人员能够方便地表示任意抽象级别上的信息系统或者其子部分，并支持问题分解、逐步求精的分析方法。
随着需求分析活动的逐渐深入，较高抽象级别上的复杂转换可以精化为一系列相互关联的数据流和子转换。
在数据流方法中，对数据的精化是伴随着对转换的精化同步进行的。
在逐层精化的过程中，必须维持层间数据流图的平衡，被精化的转换的输入/输出流必须与精化它的数据流子图的初始输入流和输出流保持严格的一致。
事实上，数据流图必须与描述并组织数据条目的数据字典配套使用。 |
