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